祖传的代码。

这几天老板开会，聊到某块业务，发现组里没一个人熟悉这块逻辑。问了下当初谁写的，后来发现那个人已经离职了，老板顿时痛心疾首，下次让我们一定要保证至少两个人极其熟悉某一部分代码可见，技术是可以培养的，经验是可以学习的，但唯有自己写的祖传代码，才是在同事间建立起的护城河，但为什么这老哥这样还是被裁了，因为需求变更，这个项目就直接废弃了，大概半个月后就不再用了。所以互联网的护城河，并没有那么的牢固，无论是从技术上还是需求上但如果是QQ那种级别的祖传代码，估计混个几十年不成问题

做程序员两年，刚开始觉得基本功要扎实。算法，操作系统这些要深入研究。后来发现这些真的只是基本功。在职场上形不成核心竞争力和不可替代性。公司看中的还是业务能力和解决问题的能力。

一个程序员，如果能深入了解业务，识别到方案中的风险，提前通过测试用例的设计去验证。进而尽可能减少代码合入后的问题单。或者测试出现问题后，可以快速定位问题，并输出后续规避改进方案。能做到这些，都是业务能力很强的表现。这些是公司看中的。此外，还要看你是否掌握公司或者领导层规划中，使得业务能力提升进化的那些技能。比如，如果公司规划通过在单板仿真软件上的投入，使嵌入式代码验证不再依赖实体单板，进而提高软硬件开发的并行度，提高开发效率，那么你精通仿真的话就是一个大亮点。

如果公司想提高硬件和底层软件，底层软件和应用层软件的解耦程度，进而提高代码通用度的话，你了解软硬件架构，可以写出通用的接口代码或者调用架构，就是核心竞争力。

总之，站在岗位或者行业上，深入了解你的业务，能解决问题。或者掌握公司战略方向上需要的技术栈。才是一个程序员的护城河。这个比编码基本功或者计算机基本功要具体的多。

对于刚入行的年轻程序员来说，本回答其实更有参考意义。你可能是计算机科班出身，题目刷到飞起，算法数据结构都不在话下。但是到了企业里，你也许会发现实际的业务里其实没那么多算法，更多的是一些重复性的套路，保证代码的鲁棒性。一些经典的算法比如递归，甚至是要限制使用的，因为会影响代码可读性。

另外，你也许会发现业务逻辑，方案，比编码能力更重要。因为大家都会编代码，但是一个新产品的业务逻辑，方案设计是否有问题，才是最难解决最难评估的。方案其实更重要，方案就是业务。还是要理解业务，理解你们在开发一个什么产品，要达到什么效果，之后才是具体实现。

最后，程序设计这个技能，本身是一项通用技能。所以实际工作中，不妨把注意力多放在选择什么行业上，多放在了解行业的重要业务上。你是准备搞互联网了，还是准备搞工业软件，还是金融。不同的行业，有不同的特别重要的业务点，吃透这些业务才能成为行业专家。才能成为市场上身价高，流通性好的程序员。