最近看到一个很有意思的诉讼案例，让我对程序员这个群体所处的境地又有了新的认知：

具体案例我简略说一下

某公司以36K月薪招聘了一位算法工程师，然后该公司在其试用期内，以编程能力不足、代码写得太少为由开除此程序员。

依据就是在职72天的代码量只有422行（还有70行代码因质量太差而被弃用）， 去除9天样本训练时间，平均每天7行代码。

当然最后的结果也算是大快人心，以该公司赔偿员工违法解除劳动合同赔偿金36000元告终。

**

只是这场看似闹剧的诉讼最后虽然以员工胜诉，但却也让人感受到中国程序员的处境究竟有多尴尬!

1、任正非的寒气是否吹向了每个行业我不知道，但互联网行业倒是寒冬凛冽，每位身处于其中的程序员更是如履薄冰。

2、网上早已流传盛久的说法：报计算机专业是穷人的最佳选择。

3、更有此案例中的行业顽疾–以代码量来评估一位程序员的业务能力是否达标。

**这是最直观但也是最无效的方法。**对于程序员而言，代码想要实现注水不要太简单。最简单的复制粘贴源码，或者可以用一个赋值语句作出的结果，干脆来一个循环语句，水代码的花招多的很。

但这完全违背了在保证可读性的原则下，尽量精简代码的原则。毕竟还有的程序员一个星期的代码量可能为负，删掉无用的代码比添加无用的代码难度高多了。

在我国大部分的IT部门是作为支持业务部门而存在，无法直接创造收益，也就导致这种畸形的考核方式。但既然你处于这个环境之中，如果你没有办法去改变，那就只能在这种环境中找到自己最舒服的姿势----譬如主动拥抱业务。

要知道技术一定是基于实际业务场景来讲的。有业务才催生技术，不懂业务会技术的大概率连自己的技术解决什么场景有什么优缺点都讲不清。

那么程序员如何高效熟悉业务？
网上的建议有很多，这里我就注重讲述下我实际下来非常高效的一个方法----通过行业解决方案熟悉业务。

首先成熟的行业解决方案能够指出一个行业链路的大部分甚至所有问题，把它称为业务解决方案也不为过，你所处公司的业务除了极个例，几乎已经囊括其中，通过问题去熟悉业务，不比你大海捞针分不清重点强？

其次行业解决方案一般给出的解决方法已经是经过市场认证的行之有效的方法，如何通过技术手段去解决这些问题更是专业，对应着去精进技术，才更为高效。

最后，分享一些我从业多年以来收集整理的行业解决方案，涉及财务、采购、生产、供应链、人力资源、销售等多个领域，回复“素材包”即可无偿获取。

对于程序员而言，与提升技术相比，积累业务技能真的比较简单，而且更容易出成绩，当你懂些业务后，往往更有机会带领几个人一起搞开发，才能更快的实现财富增长不是吗？