明白了掌握“终极技术”的意义，那“终极技术”究竟是什么？会是C/C++、Java、Objective-C或Go等编程语言吗？当一个只精通C/C++编程语言的人加入到以Objective-C为编程语言的项目上时，显然他必须重新学习编程语言。由此看来编程语言因为对不同的项目并不具备普适性，难以拥有“终极技术”之名。对于网上不少为编程语言而打口水仗的人，我真怀疑他们将编程语言当作是“终极技术”了。一旦知晓了“终极技术”的存在，你一定会发现，其实所谓的编程语言“优劣”跟本就不是业内的大问题。如果某种语言直接导致了项目的失败，那该语言早就绝迹了；反过来，如果某种语言直接导致了项目的成功，那世界上估计也只会有这一种语言了。因此，选择编程语言的重点不是考究其“优劣”，而是其适用性。过分计较编程语言的“优劣”其实是不成熟的一种表现。这类人还容易犯的一个毛病是 — 生怕落后，热衷于学习新的编程语言。请别忘了，编程语言我们无论如何也学不全，即使真有人学全了，我也怀疑他所学的只是皮毛。
“终极技术”又会是Linux或Windows这样的操作系统平台吗？由于它们同样不具普适性，所以不可能有“终极技术”之实。同样地，.Net、ACE、QT等都不可能是“终极技术”。
真正的“终极技术”一定具有一定的普适性，能让我们将之运用于各种不同的软件项目。正因如此，“终极技术”具有一定的抽象性。对于软件行业来说，真正掌握“终极技术”意味着：深刻地理解软件（开发）的复杂性本质，并拥有有助于实现高质高效工作的行为（意识、工作习惯等）、能力（思维、业务、沟通）和方法（流程、工具、复用）。
由于“终极技术”过于抽象，使得我们不得不通过一些问题来间接感知。比如：
1）编程好习惯对于软件产品的质量重要吗？如果重要，如何让团队形成良好的编程习惯？哪些编程习惯算是好的？
2）软件质量的根本是什么？是设计，抑或测试？高质量的软件对工程师的工作与生活又意味着什么？
3）软件架构师重要吗？还是只是个虚职？如果重要，软件架构师需要掌握哪些技能？
4）在软件行业具有很大影响力的CMM（软件成熟度模型），其倡导用软件过程的成熟度来度量组织的软件开发能力。那为什么通过CMM最高级别认证的组织仍会开发出质量一塌糊涂的软件？如果你身临其中，能发现导致这种糟糕结果的关键因素吗？
5）软件平台与框架被广泛地认为是高效开发高质软件的方法，但为什么企业运用这一方法后，平台与框架最终却成了一个包袱？困境的表现是什么？什么因素造成了这种困境？有方法避免进入这种困境吗？
6）业内大量使用“最佳实践”这一词汇。真正存在最佳实践吗？为什么有的“最佳实践”在组织中却无效？
7）……
这些问题大多是开放性的，而且不少问题既涉及管理域，又涉及技术域。面对这些问题的关键不在于其是否有标准答案（或许根本没有标准答案），而在于我们是否为之痛苦过、思考过，并形成了自己的想法。要知道，这些想法就是我们在工作中面对选择时用作决策的依据。如果从来没有这类苦恼，很难想象我们真正掌握了“终极技术”。值得一提的是，这些问题只是基于我自己肤浅的认识所提出的，我相信读者还有很多类似或其他的问题。
如果将软件（开发）的复杂性比喻为一头大象，那么我们每一个人或许是正在摸象的又瞎又聋的人，我们穷一生通过“摸”的方式，在头脑中构建“象”的模样。这个比喻间接地告诉我们，“终极技术”并非是某种一成不变的内容，其中更涵盖有每个人根据自己的阅历所总结出来的在高质高效工作道路上成功应对困境的方法和信念。
“终极技术”一定是通过掌握象编程语言等非“终极技术”而最终掌握的，也需要我们通过经受软件项目的痛苦磨砺去沉淀。在没有掌握“终极技术”之前，请不要停留在编程语言专家、Linux内核专家、.Net专家这样的光环之下，继续探索，前面还有更大的舞台等着你！在掌握“终极技术”的职场旅途中，我们得先认识到一点：就技术内容而言，职场首先比拼的并不是智商，而是我们的坚持与良好的工作习惯。工作中的很多道理我们都懂，但就是不能坚持做到深究，也难以通过坚持克服陋习去形成更多的好习惯。在掌握“终极技术”的道路上，我们一定会看到很多不尽人意的内容，也会面临不少困难与挫折，即使理智上悲观，但我们在行动和意志上一定要保持乐观（注：Antonio Gramsci的原话是“理智上悲观，意志上乐观”）。
