04.程序员职场心得

目录介绍

01.程序员功力修炼
02.技术人商业头脑
03.技术程序员思维
04.技术生涯的困惑
06.要有Owner意识

01.程序员功力修炼

1.1 哪些是程序员基本功

技术方面：计算机技术基础知识、优秀的编码实践、系统设计、设计模式、定位问题的能力等等。

非技术方面：对业务的理解能力、抗压能力、表达能力等等。

1.2 如何修炼基本功

不断学习，提升自己的认知。

不要单纯为了完成需求而完成需求，还要考虑代码质量比如可读性、bug数量、能否对扩展友好等等

经常总结复盘。

理论+实践并行+经常总结。

1.3 提高表达能力

一直以来，很多人对程序员的主观印象就是：不爱交流、表达能力不行。

不善于沟通交流、表达能力不行的话，你面试的时候都吃亏的不行（相信你的身边也有很多技术虽然一般，但是比较会说的小伙伴找的工作比那些真正编程能力强的人都要好很多）。

做好本职工作是我们的分内之事，如果你能偶尔抽出一些时间，多和你的同事、上级或者 leader 交流问题的话，你所能得到的肯定是远远超过你所付出的那一会时间。

1.4 要经常回顾总结

做程序员这一行，很多人最喜欢抱怨的就是：“我每天都是在做重复的CRUD工作啊！没啥意思。”，“这个公司的项目不行，没用到某某高大上的技术”

听到别人这样抱怨的时候，一般都会首先觉得这个人有点浮躁，不知道如何学习提升自己。

很多时候，我们做一个项目，做完了之后就感觉自己就和这个项目没有关系。项目上学到的一些东西或者可以改进的地方，完全不想花时间总结。

以至于，很多年之后，你学到的东西还是比较零散的，不成体系。别人询问你“有没有从上个项目学到点什么？”的时候，自己却没法回答。

不会进行思考总结，你做再多的项目，了解再多的技术又如何？可能就只是表面上好看而已，有些东西永远都成为不了自己的。

1.5 技术生涯的思考

1.工作不是学术，企业也不是学校，需要的是投入与产出。

所以从学习的优先级上，项目需求>公司愿景>个人爱好：项目需求是最根本的需求，也是保证你工资、绩效的基础；

在项目的基础上，自己的技术要结合公司的发展与技术愿景，也只有与公司的发展上一致了，你才有机会能够爬上管理层；最后才是个人的兴趣爱好。

2.在关注技术的同时不要忽略了业务和管理。

对于大多数人来说，技术是吃不了一辈子饭的，走到一定程度，需要做转型，所以在这个过程中你需要做相关知识的储备，不过也不排除一些天赋异禀的人，可以不用走平常路。

以时间来说，以5年为期：第一个5年，需要进入技术积累到专家这个角色，第二个5年，是你业务积累的时间。

3.除了关注技术发展的同时，也多关注行业的动态。

你不能不知道大家在做什么，技术的行业的需求和发展方向又是什么，这些对于你的技术没有太多的帮助与提升，却对你的发展大有帮助。

4.学习的方式可以分为两种：自己看书、查资料学习和跟别人沟通、请教学习。

两种方式没有优劣，收获的内容也大不相同。我们常说常说：读万卷书不如行万里路，行万里路不如高人指路，所以，只要有机会，多约出来聊聊，一起吃吃饭，聊聊天，是大有好处的。

1.6 优秀程序员该如何思考

1.提醒自己不断学习，是刻意学习，而不是漫无目的应付学习……不要认为自己懂得最多，哪怕是做的时间长。问自己是懂了还是深入理解原理？知其然也会知其所以然吗？

2.代码仅仅可以工作不是自己止步不前的借口。代码是否可以更加简单健强？代码是否可以复用，能否提高效率？

3.好的代码需要写三遍，心态感受会不一样。第一步，让它工作起来；第二步，让它完善起来；第三步，写三遍，力求再深入知识原理！

4.将阅读代码作为一个挑战，阅读大量源代码。阅读代码理解思路而非复制粘贴代码，日常项目或者开源项目能否借鉴源码好的设计模式或者思路，理清代码整体工作原理，而非拘泥于细节而无法自拔。

5.遇到难题首先是自己尝试去解决，如果请教别人，学习别人解决问题的思路而非拘泥于解决办法。遇到难点，卡在什么地方？从哪方面着手去解决，方案对比总结？别人解决思路是什么？

6.拥有自己开源或者长期维护并且不断改进的项目。开源项目或者开源库旨在提高技能，若收到同行肯定star或者反馈，十分有助进步。尝试重构自己项目，或者看过去的代码，与今日有何区别，改进再改进。

02.技术人商业头脑

2.1 先看下背景介绍

工程师要不要具备商业头脑呢？对于这个问题，答案众说纷纭，不过可以肯定的是，有商业头脑的技术人，通常都会判断技术和业务之间的关系。

而公司的发展离不开业务，技术人拥有商业头脑更有利于自己的职业发展。

2.2 具备四个特点

在产品经理眼中，有商业头脑的技术人大致有四个特点：

理解业务。具体一点讲，明白当前业务的现状、目标和方向，清楚为什么要做以及做了以后能给业务带来的价值。

了解技术实现的细节。比如当前的业务产品在系统中是怎么实现的，有哪些能力和局限，与上下游的关系是怎样的？如何能够快速实现目前的产品需求？很多时候同一个问题可以有多种技术实现，每种实现都有自己的优缺点。优秀的技术同学能够基于对当前业务问题的理解，做出最恰当的选择。

能给到产品有效的输入。对产品设计不合理的地方提出挑战和有建设性的意见。对产品设计遗漏的地方给予补充，对稳定性、安全性，以及资损、舆情、PR 等潜在的风险给予意见和建议。

积极地沟通和推动项目落地。帮助产品一起管理好业务的预期，也能够换位思考，理解业务面临的压力，管理好项目的风险，保持信息的透明，想尽办法帮助业务实现需求。

2.3 培养商业头脑

培养商业头脑需要一个过程，以及可借鉴的培养方法。

第一，要了解业务，最快最有效的途径就是通过和你对接的产品同学。多和对方交流，认真参与每次 PRD 评审、产品规划、总结分享。并且要多提问，你会逐渐成长为领域的业务专家，至少可以和产品平等对话。商业头脑更多的是一种思维方式和习惯，多与产品讨论业务，业务思考的角度就会自然形成。

第二，培养数据意识。学会用数据来说话，首先从业务核心的 KPI 入手，牢记它。并学会问自己，项目的目标是什么？与业务 KPI 有什么关系？如何埋点、如何追踪？数据如何变化，变化背后的业务含义是什么？

第三，深入了解自己的业务领域。这包括以下几点：对自己负责的业务领域，有基本的业务框架认知；了解业务发展的前景、现状和痛点；对业务单元的主要角色有深入了解；

第四，拓展自己的知识边界。包括日常的财经新闻、评论、重要的商业事件、互联网公司的上市财报、竞争对手的动态、朋友圈动态等等。

第五，补充专业知识。要想真正成为一名业务专家，那么，基本的经济学常识、行业知识、商业分析的模型和框架等都开始变得重要。跨学科的知识往往能够帮助你拓展思维方式和思考深度，带来创新。

03.技术程序员思维

3.1 什么是程序员思维

也许你会问，什么是程序员的思维。就是凡事都从技术的角度去思考，遇到问题就想这个比较难实现，或者技术成本太高想着换一种思路，或者觉得自己的技术很牛逼而难以被替代。

在公司老板眼里，他眼里根本看不到技术。技术是偏下游的东西，上游决定下游。具体来说，技术的上游是产品，产品的上游是战略。

技术从来不是公司的第一要务，当然技术是基础，公司没有成熟的营收模式，早晚会难以坚持下去。或者某些业务部门没有实现营收，再牛逼的程序员也可能会被裁。

可笑的是，每个程序员都觉得自己对公司很重要，都觉得自己给公司做了很大贡献，这个是需要反思的。

如果可以思考一下：如何能够帮公司挣到钱呢？“如何提高研发效率从而降低研发成本呢？”

3.2 管理是种软实力

优秀的管理能力，可以整合资源，克服阻力，推动项目按时的朝正确的方向前进，对于老板一般只会关心大的方向，而管理者则是合理分配任务协调资源，以达到完成最终的目标结果。

一般在大型企业中，管理序列和技术序列是分开的。用军队的组织架构来类比，管理序列对应于军官，技术序列对应于军士长。

受人尊敬的、屈指可数的一级军士长，技术水平堪称一流，而且做出过重大贡献。但那也属于士兵，必须服从将军的指挥。将军的职能毕竟是战争的胜利，而不是军舰修的快。谁敢说将军容易当？

管理可以从更高和更宏观的角度看问题。举个例子，用户数量的增长导致系统的性能不足，加载变慢。

如果从工程师的角度看，估计大部分的技术员，会想到那就是要优化逻辑，重构代码，重新设计架构，在技术上深挖，这样我的技术才能有所成长，才能有助于爬梯子。

如果从管理上看，首先是评估加载变慢有多少危害，会不会大幅影响用户体验？与其他功能的开发相比是不是优先级更高？如果确实需要解决这个问题，那么是进行软件上的改进，还是简单粗暴的加机器？最后通过对时间、成本、失败的概率、其他工作排期的优先级等众多因素的综合考虑，确定一个性价比最好的方案。在管理者看来，主要矛盾是解决问题，解决方法要全局最优，技术是次要的。不管白猫黑猫，抓住耗子就是好猫。

业务和问题驱动IT和技术，是从单纯技术思维开始转变的一个重点。

06.要有Owner意识

6.1 什么叫有Owner意识

什么叫有 Owner 意识呢？我举几个例子大家应该就明白了。

某天客户突然在群里询问了一个问题，你及时在群里回应了客户。这就叫有 Owner 意识。
觉得项目某个模块的设计有问题，自己私下进行了深度思考，并给出了优化方案，之后找到技术 Leader 说明了自己想法。这就叫有 Owner 意识

6.2 什么叫没Owner意识

什么叫没有 Owner 意识呢？我举几个反例大家应该就明白了。

某天客户突然在群里询问了一个问题，你看到了问题，但是觉得自己的工作还没做完或者觉得这事不重要，干脆就假装没看见。这就叫缺乏 Owner 意识。
觉得项目某个模块的设计有问题，自己就直接找到 Leader 开始抱怨：“这特么设计的什么鬼啊！代码架构一团糟”。这就叫缺乏 Owner 意识。
觉得项目某个模块的技术方案有问题，自己睁一只眼闭一只眼，没有找技术 Leader 沟通，技术方案确定之后，却经常抱怨技术方案设计的不够好。这就叫缺乏 Owner 意识。

6.3 保持有 Owner 意识

并不是说让大家都去当“奋斗逼”，故意在上级面前多表现一下。而是说，希望自己能够对工作更加负责，更加积极主动地参与项目的建设。