抛弃学生思维
工作不是学习，并没有预习的概念
工作不是学习，并没有预习的概念，很多时候并不允许你先学再做，更多时候是边学边做，你的需求不会在你完全准备好之后才来找你。
亲手做过的也不一定是自己的
你亲手做过的，也不一定是你的，不要沉迷于重复发明轮子，同时也不要把你写得轮子放到生产中（猛人除外）。
我上家公司，一个工程，三四个重复功能的ORM工具，我看代码的时候的感觉是
不用强迫完全独立完成任务
做题的时候老师总会强调，这个题必须是你独立完成才算是完成，但是工作不是做题，工作是追求效率的，当遇到困难的时候，思考过后没有答案，就应该向搜索引擎求助了，再不行，就要问导师/同事了，寻求方向性的指导
寻求方向性指导，比别人直接告诉答案会更有利于自己成长
耐心听别人给自己的建议
工作久了就会发现，如果有人愿意给自己一些建议去改进一些点，朝某个方向发展，这些建议是非常非常珍贵的，所以如果有人在给自己建议的时候，一定要耐心听完，如果觉得对方说得没有道理，或者不合适自己，笑笑就过去了，千万不要抱着一种“你在教我做事”的态度面对这些建议，否则很容易被人锤的！
刚进公司，多看多做少说话
刚进公司可能会有一腔热血忍不住想要喷出来，但是请你忍住，真的要忍住！！
即使你可能已经幻想到你在这家公司加班到凌晨五点半的样子，即使你可能快进到你在那里指点江山的场景，但你真的要忍住，忍住！！
刚进入公司的时候应该多看多做，自以为的一腔热血很有可能人家曾经吐出的一口老血，先摸清楚规则，站稳脚跟，先看明白，理解它为什么存在，边干活边理解，慢慢来，多看多做多理解，总有机会让你施展心中的抱负。
学会问问题，在讨论中进步
问问题是一个非常考验表达能力的活，能够向别人清楚地阐述一个问题，已经是成功的一半了。
我觉得要表达好一个问题，需要这几点：
- 在哪里（环境，账号）
- 什么问题
- 期望值（达成什么）、实际值
- 你的思路是怎样的（别人有没有更好的思路）
举个例子：
- 测试环境，数据库工单正常执行后无法查询到更新后的数据，是我的工单执行数据库的地址填写错了吗？还是工单执行到从库里面去了？
一个好的问题可以引起讨论，讨论的过程可以慢慢得出解决问题的思路
学会知识付费，但不要随便付费
学习是需要付出代价的，要投入充足的精力与金钱。现在有挺多不错的知识付费平台（比方说我常用的**时间）
但是知识付费本身就是购物，既然是购物，就会有不理性的时候
“这个课程很便宜噢，我先买，以后再看”，这种情况下通常都不会有以后
需要摆脱下单时候的快感，要学会从学习课程本身获得快感
并且，不是所有的课程都是自己需要的，我一般把课程的内容划分为三类：
- 入门类型，讲概念，讲demo（可能照着官网），有可能再加一些自己的理解（比方说：xx天入门xx语言这种）
- 实战（干项目）类型
- 设计类、实战类的经验总结
如果第一类占据了课程的大部分内容，这种直接pass，入门最好的选择就是官网，讲概念，讲demo，官网上的快速入门和手册是最清楚
如果第二类和第三类占据了课程的大部分内容，此时根据工作中是否涉及这个技术的使用以及自己的兴趣，来决定要不要入手
总的来看，我认为知识付费主要的目标是学习别人积累的实战经验以及设计经验，基础入门的这种，看官网的快速入门和文档就可以了
忍受坐冷板凳的日子，默默努力
高并发、海量数据的项目每个程序员都想干，但是就算是大公司，这类的项目也不一定会很多，坑位就那么几个
大概率自己拿到的项目就是几十QPS，几十万或者百来万的数据（甚至可能都没有）
没有入职即C位的机会也不要感觉到失望，先坐坐冷板凳，从身边项目入手，不停地挖掘一些点（比方说代码规范，编码技巧，项目有没有OOM的风险，定时任务有没有必要改成实时，同步有没有必要改成异步等等），多挖掘项目一些点，熟悉这个项目，先把本职的工作做好，增强自己的知识储备，然后等机会
当然如果等不到机会的话，也可以跑，年轻，试错成本低，只是不要太频繁就是了
写代码从注释出发
从毕业到现在，我都一直保持着一个编码习惯，写代码之前先写注释，将关键步骤先写到注释中，然后再写代码
func receiveAward(userId int64) {
// 超管角色
// 基础版套餐
// 是否跨级领取
// 是否重复领取
// 创建订单领取奖励
}
虽然这个编码习惯不一定很高级，很酷炫，甚至看起来有点像小学生，但是我还是挺喜欢的并且觉得这对我理清编码思路很有帮助
单元测试真的是个好东西，必须重视起来
我记得以前的leader跟我讲过，他在XXX干活的时候，写代码写得最多的就是单元测试
其实刚开始我是不相信的，正经人谁写单元测试？
我当时想，有测试验证功能没问题，那不就完了吗？
直到，我接手一个旧项目写单元测试（提高单测覆盖率）的时候，我就明白我之前的想法是错的，而且错的很离谱
在写单测的过程中，我发现了不少的代码漏洞（包括越权风险、事务使用不当，不必要的代码逻辑等等）我当时就震惊了，这可是一个通过了测试验证，正在生产环境稳定提供服务的应用，而且QPS和数据量还挺大的
后来我再复盘一下这个事情，我总结了两点：
- 测试的职责并不是发现所有的问题，而是尽可能发现问题，毕竟写代码的不是他们（开发硬是要在代码里面骚，测试是拦不住的）
- 写好单元测试，可以提前规避一些连测试都发现不了的问题，提高代码健壮性
