前言

从2018年毕业之后，到今天2020年9月19日，不知不觉间我已经工作了两年零三个月了。先后入职了两家公司，在这两段工作经历中，能够感觉自己获得了极大的成长，这个成长不仅仅是技术上的，更多的是学习到了一个职场人应具备的心理素质和软实力。

初出学校时的学生气

刚毕业那会，别人一眼就能看出我是一个初出学校的人，当时还沾沾自喜，觉得自己长得还挺年轻的，哈哈哈哈。

可是，“像是一个学生”真的是对你的褒奖吗？其实不然，尽管这只是别人随口说说，可是“学生”这个词对于一个职场人而言，恰恰说明了这个人的专业性不足。给别人的第一印象就是“这人刚毕业，没什么经验，还不能独当一面。”

其实大多数刚毕业的人，身上都带着一股学生气。和有着一两年工作经验的人，除了衣着打扮上的区别外，这种“学生气”更能体现两者的区别。

何为学生气？就是仍保持着学生的思维来思考与做事。举个简单的例子，当一个学生遇到一个Bug之后，第一时间想到的就是询问老师，这是在十几年的学生生涯中被养成的习惯。作为学生，我们总是被鼓励着去问，老师也乐意解答。可是，在职场中，不是不能问，而是不能像学生一样去问。

什么叫“不能像学生一样去问”呢？

在我加过一些技术群里，经常看到里面有很多技术小白在提问，但是他们的提问往往得不到解答，或者说得到的都是相同水平的人的解答。为什么呢？因为他们的问题要么太笼统，要么太简单，要么就直接贴个报错上来问这个报错时怎么回事。这就叫不会问问题。

比如这样：

正确的提问应该是在自己经过思考，有了一定的见解，并排除了一些可能后，仍无法解决问题时，将自己的排错过程与猜想以及结果抛出来。

比如，我在之前的一份工作中遇到了一次openstack集群多个虚拟机文件系统损坏，如果是刚毕业的时候可能会这么问：“x哥，集群虚拟机好多机器都开不了机了，不知道什么情况，帮我看看呗。”

工作了一个月之后可能会这么问：“x哥，集群虚拟机开不了机了，报错好像是文件系统损坏了，怎么修复文件系统呀？”

工作了三个月之后可能会这么问：“x哥，集群虚拟机文件系统损坏了，修复文件系统之后能够开机了，可是关机之后又报出文件系统损坏，尝试过将这部分虚拟机备份快照，并从快照中重建虚拟机，这个问题就解决了，但是不知道为什么会这样？”

当能够独当一面时：“x哥，集群虚拟机文件系统损坏了，修复文件系统后尝试排错，查看集群运行日志，发现前阵子有一台主机由于网络波动脱离集群，但是没有宕机，经过对ceph和openstack的排查，发现不是存储的问题，而是部分虚拟机同时运行在了两个节点上，估计是在那台主机脱离集群之后，集群触发了热迁移，将原先运行在那台节点上的实例在其他节点上启动了，但是启动后，脱离集群的节点恢复正常，但是虚拟机实例没有被kill掉，导致一个虚拟机在两个节点上同时运行，同时读写磁盘，所以将文件系统写坏了。目前已经修改了热迁移触发的间隔时间，修改后可能会导致节点宕机后虚拟机的恢复时间边长。”

从一个人提问的问题就可以看出这个人的水准，过于低级的问题或者未经思考就提问的问题，很容易引起别人的反感，而且也未必有人愿意回答。所以，在向别人提问前，先做两件事：一、尝试自己解决。二、将问题描述清楚。

责任感与成长

在我刚工作的时候，常常因为一些事情没有解决完，而不吃午饭。最长的一次是一个人通宵一晚上，仍不耽误第二天上班。如此忙碌不仅仅是因为工作任务重，更多的原因是当时确实菜，一个问题要解决好久。

随着自己能力增长，现在已经不怎么需要加班了，但是每天仍然很忙碌，不仅仅是因为工作，而是为了自己。

现在每天晚上基本都会再学习两三个小时，有时是翻译一下一些框架的官方文档，有时是看一两本书（技术性或非技术性），有时是看看最新技术的应用，有时是刷一两道力扣题，通常上床睡觉的时候已经是12点了。

我一直认为，工作的过程，不应该仅仅是对公司的输出，也要有对自己的输入。

在工作初期，往往没有工作经验，人的成长和对公司的产出是成正比的，此时做了什么，就学到了什么。可是大部分工作的内容往往是重复单调的，除了少部分工作外，其余的无论什么工作，只要找个靠谱的人教上半年左右，都可以胜任。在适应了工作之后，就很难再在工作中继续学到什么东西了。而随着工作能力提高，在工作上的压力会有所减少，对于如何安排自己的业余时间，就是如何对自己负责。

都说程序员吃的是年轻饭，其实是吃学习能力的饭。在我毕业之初，很多公司的JD上写的只有hive、spark，要求再高点就加个Hbase，而现在hive已经不怎么用了，spark是基础，高点的要求也变成了Flink、ClickHouse、Kudu、Hudi、Impala等等。。。短短两年半，对于大数据开发的技术点要求多了这么多。所以如果想保持自己的职场竞争力，不断的学习新技术是不可或缺的。

但是，由于程序员的两大职业特点：接触的人少，思维固化。没错，就是思维固化，一个对技术沉迷到极致的程序员，其思维必然固化，变得死板。他可能在编程上可以编出花来，贪心算法，DFS，分治法，回溯法，线性规划网络流。。。等等算法可能掌握的如火纯青。但是，让他说服一个不懂技术的人来使用他的产品时，你可以看到他在眉飞色舞地侃侃而谈，然后对面的表情可能是这样的：

所以，业余时间学习是必然的，但是也不能只学技术，一个优秀的好青年，必定是德智体美劳全面发展的。

如何看待自己的价值

大多数程序员都有一种优越感。确实，大部分程序员朋友们也都有这个优越的资本：学历高、薪资高、能力高。

现在大部分公司的门槛都是本科学历，目前全中国本科学历的人大概在5%左右，尽管现在每年都在扩招。也就是说，大部分程序员朋友们在学历上已经打败了全国95%的人了。

今年年初，某人说全中国还有至少六亿的人月薪在1000元左右，2019年上海的平均薪资是9580，而大部分程序员的薪资都是过万的，也就是说，程序员的薪资至少在上海能够在平均数以上。

作为业务部门与服务器之间的翻译官，程序员在工作中能够实现业务部门提出的种种需求，还要好言好语（不要BUG）地将这些需求说给机器听，至少在这方面的能力不能说低。

可是，这三高真的是程序员优越感的本质吗?

非也。

就拿大数据这门技术来说，数据是企业的重要资产，但是数据的价值是通过赋能业务体现的。比如，长久以来，很多企业的重大决策都是基于领导的经验和直觉做出的，而有了大数据技术之后，领导者可以通过数据进行理性客观地决策；又比如，通过对手机到的每个客户的数据挖掘出他们的喜好和诉求，将对消费者的触达从过去的“大水漫灌”到以“千人千面”为代表的精准营销。这些都属于数据的价值，而非大数据开发工程师的价值。作为一个大数据开发,是SQL难学？还是框架难以理解？都不是。那为什么大数据开发的工资要高于其他开发？是因为数据的价值高于其他开发所带来的产业价值。

所以，作为一个程序员，我们的价值是体现在能为业务带来多大帮助，而不是技术本身。轻业务而重技术的程序员是走不远，走不高的。

如何看待35岁危机

正如之前所说，程序员是一个吃学习能力的职业，而随着年龄的上升，学习能力也会下降，业内盛传的三十五岁危机也不是空穴来风。

其实我也只是刚毕业两年多的小毛孩子，对于三十五岁危机，其实没有多大话语权，因为暂时还不能切身领悟到。

可是在我身边的架构师、项目经理、技术总监们，没有一个是三十岁以下的；三十五岁左右的开发工程师也见过，薪资也可观；但是也确实有些公司在招人的时候明确表示要求年龄在三十岁以下，且能够接收长时间加班。

所以对于三十五岁危机，我不发表太多意见，只能说提前打算，未雨绸缪吧。在三十五岁之前多学习技术知识，过几年转岗架构师或其他技术性管理岗位；要么扎根某一行业，学习业务知识，结合技术，在这个行业做一个技术应用专家；要么回老家拿着这几年的积蓄创业搏一搏。

如何与PM相处

在两年工作中，遇见过三个PM：

第一个是刚毕业时的领导，不懂技术，但是对于项目管控了如指掌，对我说的最多的一句话就是“你先放手去做，如果在dead line前几天觉得完成不了再跟我说，我来安排。”但是一般我都能够完成。对于这样的PM，基本能够工作地很顺利。

第二个和第三个是在现在公司里的，准确来说是一个架构A，和一个项目经理B。两人性格和风格完全不同。

A做事不紧不慢，一个预计三个月周期的项目，可能他会到最后半个月的时候才安排任务。和这种PM合作，必须自己管控好项目的进度，不然项目极有可能无法按时完成。

B做事相对A来说就显得很急躁了，比如她提一个需求，你预估三天完成，她会催一催你，让你两天完成；你预估明天完成，她就会让你今天下班前做完。对于这种喜欢讨价还价的PM，必须在预估时间时尽量宽松一点，比如你认为三天能完成的任务，就预估五天，反正都会被压缩周期，最后还是三天完成。当然，这不是在划水，恰恰相反，这是对项目负责，一个被无故压缩周期完成的开发，要是出了BUG，就要花更多的时间去解决，从效率上来说，就得不偿失了。

总的来说，PM的风格各不相同，但是PM不是敌人，而是和程序员一起完成项目的伙伴，与PM相处时，要保持良好的沟通，如果对于确实无法相处的PM，也不要撕破脸皮，重要的是完成项目，有时耍耍心眼也是必须的。