程序员工作两年后的感受
大家好，我是3y。
不知道你们还是学生的时候，是否好奇工作两年的人，究竟在公司学了些什么东西。我当年还是比较好奇的，但却不好意思去问，因为这样会显得我很呆。
我现在工作已经两年了，我想来简单讲讲这两年我的工作体会，给还在大学读书的同学一些微小的参考。
在开篇之前，首先你们需要降低下预期，不要想着我经常写博客，就以为我懂得很多，其实不然。
技术和项目
在实习之前，凭借着我大学时期的"努力"，当年我找实习的简历技能清单如下：
看起来还是很丰富很牛逼的，对吧？
其实很多只是用过，里边好多技术栈都是没有真正理解它的思想和实现原理。
在大学期间自己动手做了两个小项目，从前端到后端到服务器部署都是自己搞的，往简历贴了下在线地址。面实习，小公司一般不成问题，毕竟还是能从简历看出，我是能干活的（：
面大公司？基础、基础、还是TM的基础
“当年只是自己用了下Git命令把代码push到Github，就敢写熟练应用了
当年只是自己用Maven的打包命令工具打个包，就敢写熟练应用了
当年只学会了几种设计模式，就敢说自己熟悉常见的设计模式了
当年连AQS的源码都没看懂，就敢写自己熟悉Java基础了
当年
....唉，年少轻狂
回过头来，我认为学生时期，没有必要学习这么多"乱七八糟"的框架。因为面试官一看简历就知道，你简历写的大多数技术栈，只是懂得如何使用罢了（：
很有可能面试官也没用过各类你在简历上列出的框架（别想着坐你对面的面试官是多么地牛逼，或许几年之后，你也变成了面试官，你拿到简历时，一样会发现，存在很多自己还没接触过技术框架）
当然啦，大厂的面试官都是有几把刷子的（我认识的大厂同学，大多数下班之后都会自主学习，提升自己）。
在简历上只要有其中一二，面试官是了解的，他就可以问针对某个框架一直问原理了（比如Spring这种常见的）。这样一来，你写在简历上写着各种了解某某某框架，意义也就没那么大了。
面试是双向选择，放平心态吧
回到现在，像Shiro、Activiti这种框架，两年后的我，只大概记得知道它们是干什么用的，细节都忘光了。
即便我大学时没学过，以目前的经验，花点时间撸会文档我还是能快速入门一把。
工作以后，校验一个人是否真正有过项目经验。我自认为看他会不会用Maven和Git是一个很好的校验方式（如果他简历上写了这两项工具的话）。比如：
“1.先说下你日常使用的Git命令有哪些吧
2.假如我写完项目代码，没切分支直接push到master分支了，怎么解决？
3.说一下你日常使用的Maven姿势呗？日常升级jar包版本的姿势是怎么样的？
4.现在项目起不来了，怀疑是各种依赖出现了版本问题，导致失败了，怎么排查？
因为工作了以后，一般来说都会大量用到这两个工具，而在没工作之前是比较少机会深度使用的。
自然地，两年后的我对部分工具的使用熟练度就日益提升了。
在技术方面，舍弃了很多还是学生时所了解过的技术，而转向于在工作项目中实际使用到的技术。
很多人曾经问我怎么提升自己的技术，感觉自己所负责的项目太挫了。工作了以后应该学什么东西，往往我给出的建议是：学工作中能用到的技术。
“比如，你用到了Kafka消息队列，你就可以去学习Kafka的原理是怎么样的
比如，你用到了Redis内存数据库，你就可以去学Redis的原理是怎么样的
比如，你用到了Flink流式处理框架，你就可以去学Flink的原理是怎么样的
比如，你用到了HBase数据库，你就可以去学HBase的原理是怎么样的
比如，你就只用到了Spring，你都可以去学习Spring对Bean生命周期的管理，以及各种日常使用注解其原理是如何实现的
....
在刚工作的时候，我对项目中使用到的技术都感兴趣，想了解他们的实现原理是怎么样的，又或者说想了解这些框架诞生的过程。我觉得这是一件在技术成长过程中很有趣的事。
“了解框架诞生的思想说白了就是：在学习这个框架之前，知道为什么要使用该类型的框架，假如没有该类型的框架以前是怎么样的，而它的设计理念又是怎么样的，为什么它能从同类型的框架脱颖而出，在项目里为什么又用到它。
从零学习一项能在生产环境中落地的技术的思想和原理，是幸福的。
由于老东家的技术还可以，所以基本市面上流行的Java后端技术我都浅尝辄止地撸了一遍，这两年很大程度上提高了我的技术广度，在这个过程中，就可以真正体会到：很多技术的思想是互通的。
比如各个技术框架(中间件)对待「持久化」这件事上，思想几乎都是WAL（预写日志）：一边写内存（缓存），一边顺序写日志。
精于基础，广于工具
除开技术之外，还想说的就是项目能力了。
曾经，我归属于某个leader下，他找我要了一份现在我所负责的系统文档。我不知道他啃了多久，再后来有新的业务需求找到他时，他就给我画了下技术方案，并问我这样做是否可行，是否合理。
当他跟我对方案的时候，我懵圈了（：原来我的老板是有读过我所负责项目的代码的啊，原来还有人不靠着我的描述就能把系统的架构给弄懂的啊，我这老板强啊...
项目能力我认为是需要时间积累的，5年经验和2年经验的人理解同一个新事物的速度是不一样的（：
如果是新入职进公司，不了解业务系统很正常。我认为最快熟悉系统的方式就是：
首先去找系统负责人聊下业务背景：包括系统功能、系统架构、系统日常问题、系统上下游负责人等等... 刷历史文档和代码，梳理系统运行流转核心链路 排查问题/Debug/写需求
不仅技术
我在大学的时候，选修过一门课程，课程名我忘记叫什么了。
印象比较深刻的是：当时那老师在聊到职业发展的时候，她提及到：”绝大部分的职业都需要有良好的沟通和表达能力“
随后补充：“但，除了有个职业，程序员。感觉他们就坐在电脑前一直敲敲敲...”
大家都听着，也没人反驳。
工作了以后，才发现这是外行人对程序员的刻板印象。
我们需要面试进入公司，面试不单单考察的是你技术能力，还得在这过程中需要表现你的沟通能力。可能技术知识点你都了解，但你没办法清晰表达出来，那面试官是不清楚的。 在工作中，我们需要跟产品聊需求是否可靠、跟同事聊业务背景、跟业务方聊细节等等，这些都需要自身去跟他人沟通，让对方能快速get到你的问题 在工作中，我们有技术分享，一场好的技术分享是需要让大部分观众都能听懂你在讲述什么 在晋升中，我们需要在晋升会议上在十分钟左右表述自己过去为公司做了什么贡献。领导是不会想听你修复了多少BUG，用了多少的设计模式编写了多少行的代码...
沟通表达(演讲)能力对程序员来说，是很重要的，这是能够让你在同一个环境中脱颖而出的重要技能
大多数公司都会执行KPI/OKR制度，每个季度都需要填写绩效（甚至可能每个周都需要写周报），晋升/转正需要写PPT来简述自身的工作。人人都在笑阿里味（赋能、聚焦、抓手、闭环...)
但很多的时候，你不得不承认，这东西写PPT/绩效，确实有一手，这的确也是一种能力。
我历届的leader或者学长，曾经都是技术大牛，都专研过行业内技术各种方案和原理。但是，他们的现在的心思都不会只放在技术上。
我上一任leader曾经跟我说过：”技术对于程序员来说，是最基本的基础。我认为每个程序员都应该去了解现在热门的技术，不能偏离掉程序员的根本。但同时，希望你们多发展些软技能，这对职业发展是很有帮助的。不能只会写代码，写代码对于大多数程序员来说都太简单了。“
我第一任学长曾经跟我说过：”可能你们刚毕业的都喜欢专研技术，我能理解，我当年毕业的时候也是这样的。但是现在，我更去想要成为一个「业务专家」，技术这条路专研下去我认为可能受益没那么高。但不是说你们就可以不专研技术了，只是重心我希望你们不仅仅只有技术，可以多考虑考虑未来的路怎么走“
在告别杭州前，也找了我第二任学长约过饭。他给我分享经验就是：”我觉得，我们这种搞互联网的，优势就在于对数据比较敏感。你说我们如果不写代码了，要干什么去，也不好说啊。“然后给我分享了个成功案例，靠着对现有数据的分析以及对互联网流量的看法，是怎么一步一步创业的...
技术是硬技能，软技能也很重要
当我向上一任leader提出离职的时候，leader表示能理解，并表示：如果能早点回到自己的家乡打拼，未尝是一件坏事。
我第二任学长也表示：离开一个城市转到另一个城市的风险就在于，所维护的圈子和人脉可能就要重新认识了，这成本可是很大的。
当我的学长或者同事离职后去新的去处之后，他们都会发出邀请：”要不你来我这边试试呗？“
包括我现在写公众号，也是有自媒体的圈子。
一个好的圈子，一定是会给你带来正收益的反馈
工作两年后，技术相较于以前有明显的提升，圈子发生了变化，思想也发生了变化。
以前觉得一个月拿很高工资的人牛逼，但后来发现，他们大多活得都不那么容易（老板给你多少钱，一般是需要你付出多少代价的）。
以前觉得技术很重要，后来觉得在职业道路上技术好像又没想象中那么地重要。
以前觉得很多事情没那么简单，后来发现只要给我时间，也没这么困难。
以前觉得网上的大神很牛逼，后来自己写了文章才发现，原来也就这么一回事，他们也未必做到了如文章所写的事。
向阳而生，好好生活
我是3y，我们下期技术干货见吧