半年来忙于他事而未更新博客，想来已经毕业十年，正好趁着假期闲暇就结合自己的过往经历闲话几句。
“野生”程序员在哪里？
“野生”相对“专业”而言是个戏称。在软件开发从业者中有这么一群人，非计算机专业科班出身、有着不同的教育背景、却因为各种缘由而进入了软件开发行业，遍布各大中小企业，很巧我就是这其中是一员。我没有查阅过详细的行业数据，所以没啥权威性，仅是一家之言。
从业多年，我面试过的求职者应该比我参加的面试多很多，所以只能从自己的接触的身边人来讲。大概是我所在的公司作为小微企业的属性，体量、待遇自然无法与BAT这些行业巨擘相比，985/211院校计算机专业毕业的求职人员我们是无福遇见的，有半数左右的求职人员来自于普通本科院校计算机相关专业（比如软件工程、通信工程、自动化等），剩余部分的求职人员则是来自各类院校各类专业，就我自己面试过的有商务英语、教育学、物流工程等。
我所在公司从事的是传统行业的信息化，接触的客户企业和伙伴企业有一大部分都是中小型企业，一些是有自己的信息化部分（人数可能不多），一些也是从事传统行业的信息化（当然跟我们不是一个行业）。每家企业也都以自己的方式活的有声有色，大家的技术人员组成情况也都基本类似，都有几个比较资深的技术负责人，但不见得都是名校计算机专业出身的，不过基本上都有工科背景，有传统行业的专业基础；广大的技术人员也是背景各异，普通本科、专科的技术人员也有相当的比例。
实话来讲，软件开发行业的门槛确实不高，高中毕业生去上几个月培训班也是能敲几行代码、解决一些问题的，加之近些年毕业生人数增长和软件行业薪酬优厚的宣传（我个人是觉得没享受到），大量年轻人涌入软件开发行业，然而行业头部企业就那么多同时也早早的锁定了各大名校的优质资源，剩余份额中有那么一小部分非重点院校非计算机专业的“野生”程序员分布于各个行业的各类企业中。
做工程师不做编码员
程序员入门门槛极低，然而上限极高。最近看吴军老师的《计算之魂》很有感触，他将工程师划分成了五级，又根据实际情况增加了六级和七级。
一级：能够开创一个产业，或者奠定一个学科的基础。
二级：能够提出重要的计算机理论的实践中的新问题。
三级：能够解决前人未解决的问题，并且能独立设计和实现产品。
四级：能够用已知的最优方法解决问题，并指导和带领其他人一同完成更具有影响力的工作。
五级：能够独立解决问题，完成工程工作。
六级：能在他人指导下完成计算机工程师的工作。
七级：本科毕业自水平不错的大学的计算机专业，但没有参加过六个月以上实习的学生。
借鉴吴军老师的论点，大概只有六级、七级的人员才是真正的“码农”，也就是编码员，五级及以上的人员自称“码农”只能算是自嘲。自我膨胀一下觉得自己应该接近四级了，这辈子能达到的高峰估计也就是三级了。为什么像我这样的“野生”程序员能够广泛存在于各类企业中？一个容易被人忽视的原因是部分传统行业或企业的信息化程度之低、计算机软件需求之简单，以致于有点计算机软件开发经验的人就能够利用成熟的编程语言和工具解决客户的问题。中国有大量的中小微企业，有很多行业甚至是你接触之前从未听说过的，“竟然还有干这个的？”，就是这些企业的简单需求却拥有巨大的市场规模，顺便养活了另一批中小微软件企业。
有些问题从计算机工程师的角度看简单的令人发指，比如几个人的小仓库、几十个客户的小公司，什么算法分析、分布式计算、弹性扩展、大数据等根本派不上用场，高并发场景几乎不存在，用很多人的话来讲就是“闭着眼睛都能搞定”。
我也曾拜读过某位专家关于某个传统领域信息化的巨著，发现里面关于计算机科学技术相关的内容都是计算机软件行业再普通不过的一些技术，甚至连“科学”的深度都用不到，只是“技术”就够用。而据说这位专家就是靠着这本著作背后的课题评上了中科院院士，在行业领域也有不小的发言权。并不是说专家的水平太低，而是这些领域太传统、太小众，能从计算机软件工程的角度提出问题并能解决一部分就是很了不起的成就了，而且这类问题往往并不是单纯的技术问题。
言归正传，“野生”不见得能力低，然而若不自省进取则往往会遇到隐形的天花板。市场给了这类技术人员生存空间，但如果能进入这个行业就能自称“工程师”却不见得能行，最低标准起码是要能解决问题吧。工程师与编码员的区别在于工程师能创造性的解决问题，而编码员只是机械性做重复工作。所以能够进入软件开发行业就不要自怨自艾，也不要自骄自傲，认清自己的短板，至少不要做编码员，要做工程师。
怎样成为更好的工程师？
在很多公司的职位上都有前端开发工程师、Java开发工程师、Net开发工程师、测试工程师等一堆工程师的头衔，但不见得有这个头衔就有这个能力，成为一个合格的工程师之前仍有漫漫长路。我见过不少“野生”程序员，辗转于各中小软件企业，有一定能力，却始终达不到一定高度，大体上都是在某些方面有所欠缺。下面就是自己在工作经历中的一些心得。
分治思想
这里的分治不是要讲算法，而是一种思想或者说是解决问题的思路。工程师是要解决问题的，如果连问题都理解不了，又何谈解决问题呢？这其中核心是怎么把一团看似复杂的问题分解成多个简单问题。比如我们在工作中曾遇到过一个大量数据查询处理缓慢的问题（当然数据量肯定比不上淘宝或者12306），分析后发现数据里包含两个重要属性：地区和年份，因此我们在数据存储时就按照地区和年份分别存放，首先按照特定地区和年份进行查询，再将得到的数据进行处理，所需时间大概是原来的百分之一。
类比思维
类比思维在理解自己从未遇到过的问题时很有用处。有时候面对新的领域或者新的需求，我们往往会无所适从、不知从何处下手，如果能从自己熟悉的领域或者事物进行类比，就能帮助自己理解问题根源所在。打个比方，疫情防控和抗洪抢险的两种情况如何类比，很多人没有经历过抗洪抢险（最好不要经历，仅作示例，不要介意），但基本上每个人都在经历疫情防控。由于疫情防控和抗洪抢险作为重大公共安全事件的共性，没有经历过抗洪抢险的人可以类比疫情防控来了解抗洪抢险的上层组织指挥体系、人员调配、资源调配、基层组织、应急预案、信息传递等。如果能有这样的了解，如何从工程师的角度去解决一些具体问题也就有了方向。
黑盒模式
“黑盒”只是借用，并不是指黑盒测试，算是一种结构化编写代码的方法或工作习惯。我见过不少程序员拿到需求、接到任务后就开始写代码，写完发现漏了、错了，再改就要花更多时间。缺乏整体性的规划就让更多的时间浪费在修改BUG上。黑盒模式是这样一种工作习惯：以后端开发人员常见的WebAPI接口为例，接口是要提供给前端开发人员调用的。对于前端开发人员而言，他只需要按照约定的参数请求接口，就能得到想要的数据，至于API接口里有多少行代码、调用了多少个函数他并不关心，这是后端开发人员编写的API接口代码就是黑盒。再进一步的讲，API接口的功能也许比较复杂，涉及到多张表的查询处理和多个中间类的计算，利用分治思想将逻辑过程划分成多个连接的黑盒，先考虑每个黑盒的输入输出，确保从数据流的角度达成闭环，再考虑每个黑盒中如何将输入处理后转化为输出。在这个过程中自然的将业务流程和代码逻辑划分成不同的功能块，提取公共类、公共方法和逻辑分层也就清晰可见了。
表达能力
程序员如果技术能力很强但是不能清晰流畅的用语言或文字表达自己的想法是很难在现有层次上更上一层的。有些人也许会说自己本就不善言谈、文字功底也不咋地，然而大多数人都赞同计算机软件开发是需要清晰的逻辑的，如果靠语言或文字描述很难将自己的逻辑描述清楚，那么就很难让人相信逻辑的正确性。计算机软件开发中有大量的技术文档，往往有些人会嗤之以鼻，觉得自己的代码就是文档，等到自己看别人的代码时，又愤愤道：“这是谁的代码，怎么连个文档也没有？”。除了常见的技术文档，表达能力的另一个重要体现就是画草图，毕竟“一图胜千言”，当一大堆文字理解起来要费些时间时，一个简单清晰的示意图或者草图也许就能把意思直观的表现出来。然而不论是使用语言、文字还是图画的前提都是有清晰的思路和逻辑，对问题有着结构化的认知。
一家之言，不具代表；个人愚见，仅供参考；知彼知己，百战不殆。