到一家不太大的公司，业务能够持续发展，公司目标明确，不要持续更换方向。

像一些“今天区块链火，号召技术人员钻研区块链；明天芯片火了，举全公司之力进军芯片行业……”这样的公司是不行的。我说的有些夸张，但确实是有些公司为了找到市场的爆点，频繁更换小方向，打一枪换一个地方。

从个人发展考虑，如果用到的技术栈不一样，对技术的积累是不利的。因此，如果一家公司能够在某个领域的技术上做持续的投入，并且这个领域的发展对公司是至关重要的，你才能够跟着公司一点点的成长。从一开始的明确需求，到技术调研、设计、开发测试、产品上线。随着产品上市，这一个领域的技术需要不断深入以满足各种需求，这样你获取的技能都会实打实的从实战中获取，才不会纸上得来终觉浅。只有这样的公司对你的积累才是有利的，你的绩效也不会低。

说到这里，我们需要考虑几个问题：绩效和技术积累能兼得吗？

说到绩效，它是和公司挂钩的，你技术再牛，写出来的代码没有给公司带来效益，那你的绩效也好不到哪去。

你说你算法特别牛，能够通过算法把执行效率提升n倍，这的确是见程序员功力的地方。但对不起，公司的这个项目用不到这么高深的算法，数据量也没这么大，两个for循环就能解决了，为了代码的简洁易懂，最终还是选择了两个for循环。

在这个项目上，for循环比你的牛逼算法值钱。但是如果你在这种项目里待久了，给公司创造了效益，绩效也还可以，自身的水平能提高么？

这里只是一个例子。事实上，大家应该也多少会有自己的感觉：绩效和自身技能发展在某些时候，或者说是大多数情况下都是矛盾的。

大多数小型公司不会让你在一个方向上做自己的工作，今天有后端的需求，让你去做后端了；明天前端人手不够，拉你去前端支援；后天测试缺人手，说你去做测试吧；某天又做了一款视频应用，上线后效果不理想，就转而去做一款游戏看效果怎么样……在这种情况下，还有可能在公司里实现技术的积累和沉淀么？

再说下大公司。大公司的业务和产品基本上都已经定型，各种软件的架构和基本功能也都已成型，所以在这样的公司中你的确可以在一个领域中积累技术，但做的基本上是维护（Bug修复）或者在原有架构基础上实现一些新的功能的工作。

在这样的公司中做技术积累和提升，完全靠自觉学习，因为你不可能去参与技术架构了，项目的核心问题也都已经被前人攻克，你要做的就是完成一个功能。但千万不要认为做完一个功能就可以了，要趁这个机会把功能相关的代码都捋一遍，只有这样边写代码边学习，理解才会更加深刻。第一次会非常痛苦，但第一次熟悉之后，后面再遇到这些相关代码的问题回信手拈来。

同时，你也要从不同方面来理解代码，学习如何设计优秀的代码，学习这些代码是如何组织起来的、用到哪些设计模式。如果代码让你感觉很清晰，可以看一下别人是如何写出clean code的，等等。

理想情况下，能做到这些当然更好，但现实往往事不如意，为了赶时间，想一蹴而就，了解代码的表面意思以后就立刻动手写代码，写完觉得没问题就交给测试了。这也就不奇怪为什么绩效与自身技能发展之间会存在矛盾了。

既然绩效和自身积累不能兼得，那如何才能有效的做到技术的沉淀，从而成为某一领域的技术专家？

是的，那就只能靠业余时间了。

工作中的有些地方有可能是自己不愿意做的，因为对自己的技术提升没有任何好处，是为了工资不得已而为之。下了班的业余时间你就可以自由的支配了。

学习的方法有很多：

• 选择一个感兴趣的方向，找到几本大牛权威的书籍，找到几个相关的、流行的、开源的项目，边学边练。选择的大方向还是要和自己的工作相关，如果你工作是区块链相关的，就不要尝试去深入学习芯片相关的知识，因为你会发现即使学了，没有实践，时间久了还是和没学一样。这对工作也没有帮助。

• 找书籍。网上一搜，好书多的很，还可以去豆瓣看书评，找真正高质量书籍来学习。

• 看代码。做技术的不读写代码是纸上谈兵，看一些优秀的开源项目，自己尝试动手写一些项目或者参与一个项目会让你的知识消化的更快。你离10万行代码的距离还差多远？

最后我想说的是，如今IT行业热门方向有很多：人工智能、区块链、大数据……诱惑实在太多。我们不能今天看到某某技术多好，工资多高，就头脑发热买一堆书籍去学习，要抵得住诱惑，耐得住寂寞，心中有定力，选定一个方向坚持下去。

做技术的靠得就是两个字，踏实。