说下我的工作经历，我大学不是学计算机专业的，当时Java 基础差，除了 CRUD，其他都不太行，妥妥的菜鸟一个。
下班之后，我主动留在公司恶补，蹭着公司的网、空调，泡 CSDN 论坛，没完没了的刷 Java 版块的问题和答案代码，只要是我不会的，都照着撸一遍代码。慢慢的攒了一堆工具类、例子。
后来经理非给我非常小的项目——做一个内容发布系统，经理把这个项目交给了我自己，准确的说是还有一个美术帮忙作图。
这个项目我干了 3 个月，提前交付了，做的非常辛苦。有点增删改查的底子，所以后端Java代码写能凑合写写，前端的 Html、Javascript 真的是从头开始学。白天上班干活，下班之后在公司学习。有时候太晚没公交车了，就趴在桌子上凑合睡一宿。
真的，那段时间自己能明显感觉在提高，Java 的入门基础、常用的类越来越熟。虽然还不太懂啥是面向对象，一些高级的编程还不会，但是能凑凑合合的干活了。
后来是看各种 Pet Store 的源码，作为当时程序员的必读开源程序之一，我并不是随随便便的看。看完之后，我会刻意尝试背着写出来。写出来再和源码对比，看自己写的哪里不对，思考源码为什么那么写。
随着不断的练习，慢慢就有编程的感觉了。
编程的感觉是什么？不太好解释，就好像是你可以熟练的打字，但是你很难说出ABCD……XYZ 在键盘什么位置。
再后来又给我了一个项目，是给天津的一个手机销售连锁店做个 CRM 系统，这个系统除了 UI 找的外包，剩下的还是我一个人做的。那个年代还没出现前后端分离这种高级概念，主流用的 Java、Servlet、JSP、JS 我自己现学现用，咬咬牙还能应付。
公司小，也没有专门的测试，这其实还好，自己开发自己测试呗，系统也没有多复杂，自己测试细心点就行了。
最头疼的就是出差去天津客户那里，从初期的调研需求，到中期的汇报演示，到最后的部署上线、给客户培训，都是我一个人去的，前前后后去了很多趟。
每次客户问起来“这个项目是不是就是你一个人做的啊？”，我都努力镇定的说“不是，我们有 3 个人一起做”（这是老板提前教的回答）。
在小公司那几年，虽然我干的事情很杂、不规范，但是现在回过头来看，那段经历也挺珍贵：
一个人干多个人的事儿，真的很锻炼人。做事高效，有啥事情，一扭头就可以和老板商量了。气氛好，大家经常一起出去吃喝玩。可能也是因为公司人少钱少，根本没有拉帮结伙去争的必要。
后来随着跳槽，我经历过几百人、几千人、上万人的公司。
程序员这条路初期会坎坷一些，这也是正常的，别太在意大家怎么看你，努力提高自己就完事了。
我身边不少大厂程序员，平时经常和他们一起交流，交流过程中尝试总结了他们的一些好习惯，也分享给大家，希望大家能早日开始养成好的习惯，早养成早收益。
1. 引入新的技术栈的时候，要以官方文档为主在项目里，无论使用新的 jar 包，还是用新的中间件，一定要去看官方文档。
现在网上的技术文章鱼龙混杂，再加上国内那个不咋地的搜索引擎，所以在网上搜靠谱的技术文章，就相当于在屎坑里捞金子。
比如，如果你想要对 SpringBoot2 写的代码进行单元测试
，JUnit 版本你可能已经是 5 了。但你搜到的网上文章很可能会告诉你测试用例需要注解:
@RunWith(SpringRunner.class)
但是官方文档说了，其实如果你用 JUnit5，就不用加这个注解了，加了反而可能引起不必要的冲突。
所以，官方文档对新技术的引入是唯一的参考金标准。
2. 一定要悄悄地把代码测的没问题了再交付在职场上，什么样的人才能快速成长、快速得到重用？答案是可靠的人。
那就程序员来说，什么样的人才算是可靠的人？答案是交付可靠的技术产品。
那可靠的产品第一评估标准就是 bug 少。这个 bug 少是别人评估的，而不是自己评估的。
无论咱们自己代码实现成什么样子，哪怕是代码写的还不完美，但是，只要咱们通过自测，在提交之前尽可能把问题解决掉，让别人少发现你的错误，尤其是低级 bug，那么你才是一位可靠的程序员。
所以，交付任务前，一定要自己把代码全方位地测试一遍，保证自己有着优秀的口碑才好。
3. 打日志的时候尽可能把输入、输出以及耗时都打印出来我们打日志的目的是什么？是为了定位问题的。
问题有哪些？其实大体就两种，逻辑问题和性能问题。
逻辑问题，我们如果打印了输入和输出，那么根据业务规则，这么一对照就能很容易定位到问题。
性能问题，我们无论是通过像 grep、sort 等 shell 命令去直接对日志做个过滤加排序，还是通过日志搜集加日志搜索等工具，都能很容易的发现到问题。甚至还可以和监控系统联合起来，直接做预警。
所以，打日志的时候，我们要记得把输入和输出以及时间都打印出来。
4. 学好 GitGit 这东西太重要了。现在的团队开发，用 Git 管理各种代码版本，代码分支。如果你用不好 Git，很容易就会因为合并代码、升级版本等情况，产生出许多没必要的 bug。
一个用不好 Git 的团队，可能每次上线，都会带来那么几个莫名其妙的问题。
5. 优先实现功能，性能问题或许没那么着急我在带团队的时候，经常发现有些刚入行的同事，会边写代码边纠结自己写的代码性能是否有问题。其实真的不必这样。像我们这些老程序员，都知道过早优化有时候可能白花费功夫。
像咱们如果写一个批处理的定时任务，这个任务要求只要在凌晨运行，在大家上班前任务完成就行。那么，这个任务从凌晨两点运行到六点和运行到四点，有什么区别吗？
优化代码一定要适度，要在写完功能之后，看功能会怎么被使用，根据实际的要求，去优化真正需要优化的地方。
6. 先实现最确定的需求，不确定或者模糊的需求先往后放实现需求的先后顺序，注意一定要以需求的可靠程度为准。
在分配给我们的需求里一般分两类：
有的需求是我们和产品经理都非常明确的需求；也有的需求比较模糊：开会讨论时大家都觉得没什么问题，但是一到代码实现的时候，就发现还存在很多问题。
这时候，咱们应对的技巧是，先对这些需求搭一个统一的架子，把已经非常明确的需求先开发出来。
由于架子搭建出来了，这时候再和产品经理讨论那些模糊的需求，很容易就能让产品明白困难的地方，这样就可以把沟通难度降到最低。
7. 主动找项目里的问题并给出解决方案问题是什么？问题就是在实践过程中需要解决的东西。
把这些问题一个个找出来，解决掉，这些解决问题中产生出来的方案，全会形成推动项目前进的推动力。那么产生这些推动力的你自己，一定会从中获益良多。
8. 评估开发周期，要留出冗余时间留出冗余时间的目的很明确，在咱们开发的时候，遇到的意外情况太多了：
需求又双叒叕变了团队人员有变化当初估算的时间乐观了这个功能需要动老代码需要跨团队合作开发 - 领导说“加个小功能”，领导认为这个小功能不影响开发周期（此处省略二百字）……
所以，冗余时间是要留出来的。
留出的冗余时间不等于摸鱼时间，开发还是按照正常的节奏干，早做完早交付。
9. 不要光看书去学习技术，要把感兴趣的技术通过代码实现出来咱们程序员最重要的就是实践，能把学到的知识转化为实践用到工作上。
光看书学习技术，很可能只会让咱们产生出已经学会的错觉。只有通过代码把感兴趣的技术实践练习了一遍，咱们才真正能明白这技术实际用起来是什么样子，需要注意什么。
顺便在这里说一下，我目前是在职Java开发，如果在学习Java的过程当中有遇见任何关于学习方法，学习路线等方面的问题，你都可以 点击 Java技术讨论，这里面聚集了很多正在学习Java技术的初学者，也有不少从事Java开发岗的大佬，与Java相关的问题都可以随时发出来讨论。
10. 英语还是挺重要的你不得不承认，IT 这行，基本所有的创新都诞生于英语的世界。
比如 k8s，就我所知就是国内英语好的技术人员从英语社区逐渐在国内推广开来，而这些推广了 k8s 的先驱也自然掌握了 k8s 的话语权。大家可以看看 k8s 在市场上的流行程度，也可以看看一位 k8s 专家的工资大概是多少。
而且，我前面说过，大家引入新技术一定要看官方文档，官方文档百分之八十都是英语的，所以英语确实重要。
如果英语不好，是不是就没机会了？没这么绝对。
就说我吧，不瞒大家，我英语四级没过，但还是照样能看英语资料，照样和别人一起翻译了国内的第一本 Hibernate 技术书。
当初我用 Hibernate 在国内算是比较早的一批程序员了，也经常去论坛回答问题，所以后来就有人找我一起翻译书。我最开始是抗拒的，觉得自己英语太烂了，翻译不好。后来我又想，既然我能看着英语文档学 Hibernate，要不就试试。于是就这么着干了一把。
作为一个过来人，我想说的是，技术文档
没有特别复杂的语法、生僻单词，而且现在还有翻译软件、插件可以帮我们阅读。即使英语基础一般，也没什么大不了的。
最后再给大家分享一些程序员经常逛的网站，大家没事也多去看看，对自己成长有好处。
