1.2 早期职场的一些痛苦记忆
1.2.1 职场中的玻璃格子
我的大学生活算是比较幸福的，我学习计算机专业，自己又喜欢编程，因此大学课程应付起来相对轻松容易，又因为学校推荐，找工作也比较容易，收入还不错，但刚入职，职场就给我了一个下马威。
我喜欢编程，渴望能从事编程类的工作，但第一年加入的一个项目组，分配给我的工作基本就是整理各类图纸和打杂，甚至直到最后被迫离开这个项目组时，我都没能看一眼这个产品的真实运行代码。
在网络上同很多初入职场的人员交流，发现很多人都会碰到类似的困局。学校教育是喂食模式，而职场工作是抢食模式，在资源有限的条件下，老员工可能会把着一部分工作不让新人接触，这是职场的潜规则。实际上，有时候单纯的不教还算好的，故意给你使绊子，或者通过斥责新员工来凸显自己所谓水平的，林林总总，让很多初入职场的新人无所适从。
如何克服这一点呢？后来我又新加入了一个项目组，该负责人的做法让我很欣赏，也是我职场路上最值得敬佩的几位良师益友之一。
该负责人身上最大的特点就是一直保持着强烈的求知欲，对很多新技术保持着跟踪，且勇于去尝试和学习。在领导人的带领下，整个项目组成员都在努力追赶着，不经意间，大家会发现自己已经站上了山巅。
后来，自己在带领团队时，也会有意且努力的保持着这个节奏，努力提升着自己的格局，将更多的机会让给跟随自己跌打滚爬的兄弟们。写这本书最初的目的，不仅希望能够系统化的思考整理自己多年的工作经验，也是期望能够培养出多个自己出来。而且，我相信如果真有这一天，我个人会获得更大的价值。
如果你不幸碰上了一个保守的领导，怎么办呢？良禽择木而栖，如何找茂盛高大的树木，你心中或许已经有了答案。同时，也希望本书能撑开你的格局。
1.2.2 走弯路的入职学习
我大学毕业后加盟的第一家公司，其主要产品是电力系统微机保护，是一种适用于电力行业的嵌入式设备。为了能够参与具体的产品研发，有两个关键的拦路虎，一个是电力系统知识，另一个是motorola（后改名为freescale，又被nxp收购）的68k芯片及其相关汇编指令。而为了突破这两个拦路虎，公司内流转着两本经典教材，一本是贺家李老师的《电力系统继电保护原理》，另一本是《MC68332位单片机结构与应用》。
我记得那可真是一段灰暗的日子，每天硬着头皮阅读这两本书，经常是看不了几页脑袋就晕晕乎乎的了，抬头看看周边的同事，大家都在忙忙碌碌的，想问既不好意思，更无从问起，低头看看时间，哇塞，刚过去半小时，这一天咋熬啊。
那段时间网络上流行论坛，我曾将自己的苦恼发表在网络上，一个同样被逼疯的家伙分享了他的遭遇。他们公司使用c语言（那时的我相当羡慕，因为我们还在使用68K汇编），但他自己C语言水平不高。为了提升C语言水平，他领导给他推荐了一部大名鼎鼎的《C Primer Plus》，然后他就经常痛苦的面对着一本大部头发呆，经常是看着后面忘着前面，好不容易耐着性子看上几页，也常常是依旧稀里糊涂的状态。
磕磕碰碰，反反复复，时间就像一把筛子，会将熬不下去的人淘汰掉，也会给坚持者以奖励。当我好不容易将两本书勉强读完，将产品的主要代码完整阅读一遍并标上注释，终于对产品有了一种熟悉感后，内心才缓了一口气，感觉自己跨过了入职阶段，但也狠狠的记住了那种“在泥泞中挣扎，看不到前方”的难受感觉。
职场是残酷的，绝大部分的企业是小企业，不要指望有专人手把手的教你。实际上，在我的职场生涯中，见到过太多因入不了门，最终被迫换岗或离职的朋友了。
时间的威力是无穷的，很久很久之后，《C Primer Plus》已经成为自己偶然翻阅查询的几本C语言书籍之一，常见的嵌入式芯片架构已经了然于胸，而且可以很顺畅的同电力专家交流电力产品时，我接触到大公司的培训体系，理解了“最小知识原则”和“深度学习原理”，才明白自己曾经走过了多少弯路，而那些不幸的朋友是多么的冤屈。
期望本书，能让你的入职过程走的更顺畅一些。
1.2.3 重复的代码碎片
除了少数幸运儿，我们大部分人都会进入小公司，而小公司的产品研发模式一般是这样的：
- 刚开始规模比较小，大家集中精力群殴一款产品。
- 随着市场的推广，需求增加，产品开始逐步系列化。为了做新产品，一般会从原团队分裂出一个小团队。
- 各团队刚开始还能保持着沟通，互通分享代码，但随着时间的推移会越发独立起来。同时，原有的一个代码模块可能也会修改成了N多个版本。
为了后续描述方便，我将这种研发模式称为“拷贝粘贴”研发模式，这种模式最初表现出来的问题就是代码维护困难，人员效率低下且浪费严重。如我曾经就职的一家企业，我发现在整个公司范围内，仅电力系统的基础104规约，大概就有不同项目组不同人员实现的十多个版本，不仅人力资源浪费严重，而且整合维护困难，一处出问题，很难即时同步到其他版本。
一些公司会意识到了这个问题，然后会尝试进行整合，整合的策略大多是通过宏定义。这种策略会随着产品种类和工程改造的增加，用不了多久，整个代码就被层层叠叠的宏定义分割的支离破碎，给代码阅读、维护、调试等带来诸多困难。
#define aaa ……
#define bbb ……
#define ccc ……
#ifdef （aaa == ……）
……
#ifdef （bbb == ……）
……
#elif （bbb == ……）
……
#endif
#elif （aaa == ……）
#ifdef （ccc == ……）
……
#elif （ccc == ……）
……
#endif
#endif
目前工控类企业研发人员流动频繁，也会从另外一个侧面加剧这种现象。一个企业引入一个牛人，很可能是看上了他曾经的工作经验，但极有可能引入了新的芯片，新的OS，新的程序架构。
不仅仅是维护困难，“拷贝粘贴”研发模式真正的危害是会桎梏一家企业或团队的研发能力和上升空间。我工作中接触过很多企业都存在一个现象，做一些入门级的产品，质量能把控的非常好，但产品一旦复杂到一定程度，就有一种hold不住的感觉，各类质量问题频发，按下葫芦浮起瓢。
为什么呢？如我接触过的一家公司，他们一直眼馋某高端产品的利润率，因此老板下狠心，集中了公司所有的优秀技术人员开始封闭攻关。因为优秀人员的抽离，没多久其他项目组就开始频繁的冒红灯。好不容易熬到将样机做出来了，赶快恢复原有人员组织关系，仅留下了几人继续优化维护。遗憾的是，该产品的专业知识已经超出了这几个的能力范围，用户现场问题频出，销售人员怨声载道，最后花了大力气做的产品竟然慢慢走向了末路。
高端产品，很多时候是需要在诸多细分领域长期积累的，靠临时突击的策略顶多徒有其表，最后依然是竹篮打水一场空。一个企业如果不想仅停留在低端产品的红海中厮杀，可能首先要想办法跳出“拷贝粘贴”陷阱了。
1.2.4 工作腻烦情绪
1945年，当富兰克林·罗斯福第四次连任美国总统时，《先锋论坛报》的一位记者去采访他，请总统先生谈谈四次连任的感想。罗斯福没有立即回答，而是很客气地请记者吃了一块“三明治”。记者得此殊荣，便高兴地吃了下去。总统微笑着请他再吃一块，他觉得这是总统的诚意，盛情难却，就又吃了一块。
当记者刚想请总统谈谈时，不料总统又请他吃第三块，他有些受宠若惊了，虽然肚子里已不需要了，但还是勉强把它吃了。这时，罗斯福又说:“请再吃一块吧!”这位记者赶忙摆手:“实在是吃不下了。”
这时罗斯福微笑着对记者说:“现在，你不会再问我对于这第四次连任的感想了吧!因为你刚才已感觉到了。”
你瞧，连当总统这么光荣的工作都有腻烦的一天，更何况我们整日面对电脑累的腰酸背疼头晕脑胀的码农工作呢。实际上，大部分职场工作，熬过了入职，并进入相对无聊的平淡期后，多少都会有职场腻烦情绪。
我记得自己刚开始工作时，不仅激情澎湃，而且还有很宏伟的职场规划，或者成为产品负责人，或者成为技术大能，然后就可以赚取很多很多的钞票，并过上幸福美满的生活。
可惜的是，理想很丰满，现实很骨感，自己每天大多数的日常工作是无休止的维护程序、开不完的会议、走不完的流程、做不完的测试，没多久，就开始产生腻烦情绪了。我暗中观察身旁比自己年长的一些同事，他们做的也是同自己类似的工作，工作经历的增加好像并没有在他们身上留下太多的印记，年底总结时大家会一起发愁没内容可写，聊天时已经不在像年轻人一样喜欢技术话题，而更喜欢家长里短。
记得那些日子，自己内心经常隐隐有点恐惧感，难道自己以后也是这样子吗？网络上铺天盖地讨论程序员40岁以后不转行就要下岗，而自己并不擅长营销或管理工作，以后是否会沦落街头呢？
为了改变现状，我有段时间我对技术管理工作特别上心，也期望自己手下的几个新人能快速成长起来，自己好有机会去做一点“高级”的工作。为了能让新人快速上手，我曾费劲的逐行逐行给新人讲代码，可惜，经常事与愿违。让新人几个现场问题修改下来，不仅做的慢，而且漏洞百出，外加工程现场一般都特别着急，自己因此多次被营销人员和领导骂的狗血喷头，只好继续亲力亲为。
新人上不了手，老人脱不了身。新人会感觉面对铺天盖地的代码，总隔着一层纱掌控不了，而老人又好似被牢牢的按在了当下。总有一天很多人会熬不下去，或者转营销、或者转后勤，留一堆乱摊子给别人，公司的产品也越维护越烂。
直到很久很久以后，我才终于弄明白了自己写的程序为啥总也交不出去，也终于了解到如何帮助自己和他人构建从入职到架构师的阶梯。
你在工作中有没有莫名其妙心烦的感觉呢，期望你在本书中能找到答案。
1.2.5 一次风雨中的现场救急
只要在职场工作久了，大家或多或少都会碰到需要灭火的时候。
记不清是哪年哪月哪日了，仅记得当时快下班时，我突然被领导叫到了办公室。原来某个用户现场，我们的设备出现了不定时的异常复位现象，用户非常恼火，放出狠话，如果不尽快处理，就要上报国家电网。
当时，我就职的那家公司主要产品是面向国家电网的，而国家电网设备采购经常采取统一招标的模式，因此，一次用户投诉，就有可能影响后续几次招标成绩。公司领导非常着急，我连同其他两名倒霉蛋被一起派往现场。
从出发那一刻开始，我内心就异常忐忑，因为我不知道能否解决该问题，甚至都想不出该如何下手。屋漏偏逢连夜雨，老天竟然也来凑热闹，我们一行人刚踏上开往现场的长途汽车，倾盘大雨就瓢泼而至，自己所在的小城竟然也能堵车堵的一趟糊涂。
记得当时自己的内心颇为矛盾，既希望交通赶快恢复，别影响到用户现场问题处理，又希望时间能像堵车一样静止下来，这样就不用面对现场棘手的问题了。风雨中，经历了堵车、爆胎，我们终于在凌晨两点到达用户现场，原本仅有四个小时的路程，竟然磨叽了九个小时。
这个现场问题最后被我们很侥幸的处理掉了，但也让我真正体验了一把救火的经历。遗憾的是，这不是终结，仅仅是开始。
一次，我按照用户的要求谨慎的修改完程序，又谨慎的打包测试后，将程序发往用户现场。内心原以为自己这次够认真了，问题应该处理掉了吧，没想到没多久现场就打来了电话，现场的埋怨、用户的责骂、领导的不信任，诸多烦恼涌上心头。
一次，用户怀疑我们设备出了问题，但我们的服务人员认为大概率是其他厂家设备出的问题。用户要求我们写保证书保证100%不出问题，但写了N多个版本，不是用户不满意，就是其他厂家不满意。折腾了N久，用户也不提报告了，侧面了解才知道其他厂家已经改正了问题。
一次，用户某领导指责我们没按照设计方案施工，想交流又不配合，我们被迫无奈开始小心翼翼的处理用户端复杂的人际关系。
一次，我带着几个小伙已经连续奋斗二十余天了，看到大家都疲惫不堪，我决定让大家都好好休息一天，巧的是那一天用户大领导去参观现场，然后一纸投诉寄到了公司。
一次，现场工期催的紧，用户嫌我们安装调试进度太缓慢，要求我们晚上加班到十二点。记得那一天，施工现场还处于土建施工中，江南的阴冷能透到骨头里，当晚就放倒了三个人。
……
一次次救火的痛苦经历，经常让人疲惫不堪。有一次，一个工程片区负责人离职，我请客并给他践行，他发出一句感慨：“我再也不用担心凌晨会接到用户电话，感觉轻松多了。”
好不容易混个领导或技术能手，为啥最后都混成了灭火队员了呢？行业内有句名言，或许能道出了其奥秘：“你在现场受罪，你陪客户喝酒，是因为你做产品时没有流汗。”
“拷贝粘贴”式研发模式，会导致代码维护困难，质量问题频发，会割裂了新老员工之间的技术传承，让新人不容易接手，老人没法继续提升。最终，大家都成了灭火队员，整日，紧张兮兮的努力熬着，熬着……
如何打破这个怪圈，如何将质量控制体系有机融入产品中，如何能在工程施工中不总当关键节点，可以喝着咖啡颐指气使的催促他人，又如何能在出问题时，摆出切实证据然后让其他公司去头疼呢。
希望，您在本书中能够给你答案。
1.2.6 所有的经历都是财富
前面描述了我自己职场中的一些痛苦经历，是否会让大家产生一种不想长大，不想工作的情愫呢？幸好，真实世界也是多姿多彩的，套一句网络鸡汤，我们所有的经历都会成为人生的财富。
长期面对电脑，经常腰酸背痛，空余时间我喜欢打羽毛球，出一身臭汗，不仅浑身舒畅，肩膀也能好受很多。有一次，一朋友指出，我的握拍挥拍动作都不正确，这样不仅会打的很累，而且用还不上力。
同理，大家是否能意识到，上面所提及的“拷贝粘贴”模式，不管是对于个人，还是对于企业，如果没有经历专门化的训练，本来就是一种自发的下意识的研发模式。或者换句话说，这是我们个人或企业成长所必须经历的初级阶段。
人不轻狂枉少年，我们总要经历青春，总要吃上一些苦口，才能迈入成熟的中年。而且，如果你能思考这些痛苦经历的底层逻辑，并尝试着去克服他们，砥砺前行，你总有鲲鹏展翅的那一天。
实际上，如果能有这样的一段经历，会更好的理解大公司的研发模式和管理理念，反而是那些一直在很规范的大公司工作的朋友们，容易被束缚在一个很小的专业范围内，以后一旦离开了平台的支撑，反而会变的举步艰难。额外，有这段经历的朋友们，会具备一个很大的优势，更容易成长为优秀的架构师，而这类人物几乎是所有公司的核心竞争力。
现实世界是残酷的，如果没人指导，我们想迈过这一步并不容易，大多数人会被环境所裹挟，最后浑浑噩噩一生。机缘巧合之下，我个人很幸运的完成了从入职到架构师的跨越，本书会带着你重温这个过程，也期望对你的成长有帮助。
返回目录
——————————————
我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如感兴趣可加个人微信号nzn_xiaomaer交流，需备注“异维”二字。