自己思考的一些码农需要关注的点（写代码除外）

自己最近这段时间在帮助公司海外扩展业务，现在同时tech lead日本和美国三个团队，虽然仍然还写代码，但是有一些自己的心得，感觉可以分享出来
- 写代码只是软件流程中的非常小的一部分，相比写代码，上游的需求管理和下游的交付其实是更加重要的东西
-- 上游的需求管理这部分能够拿到，那么就有很大机会去锻炼自己的技术选型能力
-- 下游的交付其实也非常重要：普通的互联网公司，如何快速deploy代码到数千台机器同时又不需要大量的人工干预，chaos engineering是一个非常重要的思考点。
- 英语非常非常重要，这点就不说了，Lv1-2的时候可以不管不顾每天和组员简单交流做好任务就行，senior、staff和principal之后，撕或者交涉的能力是非常重要。
- 日常仍然需要写代码，但是速度会降下来，推荐如果不是特别赶工期的话，写一遍之后再思考一下如何能够将来重用这段代码
-- 代码写多是经验活，写少是技术活 （YAGNI、KISS）
- 如果是一个不错的组的话，在一个组尽量多呆3年+，这样有助于建立自己的reputation和technical muscle。尤其是到3年以后的时候，人就会开始有一些非常有意思的想法，reputation也足够让自己在组里面推动下去。

自己最近思考了这些东西，感觉整个技术生涯中，组织能力以及领导能力，其实是远远要重要于技术能力的
PS：要是支持markdown就好了…

感谢楼主分享，非常同意！

可以在工作中切实感受到，如何能够帮助一个小团队高效运转，比多写几行代码还要重要，一个团队的高效产出所带来的impact是远远大于个人的。
上游的需求管理，就包括了 1）upper management，对老板、客户的manage能力；2）产品的sense，需要多从客户的角度，置换位置思考问题；3）沟通和谈判能力，表达能力。切身感受是，能够清晰的讲清楚一个问题，讲清楚逻辑，可以大大提高所有和你对接团队的效率。
下游的的交付：个人感觉主要是 1）整合资源的能力。能不能找到有资源的人和团队，并且能够从他们这里拿到需要的资源和人力，来帮助你完成你们团队的任务，大家一起Win-Win。2）执行力，自己和团队能不能快速的简化问题，迅速执行，并且根据反馈，不停的迭代并改进思路。3）解决Blocking的能力，总有问题或者成员，因为种种原因Block了团队的执行，能不能在最短时间里用最小的代价和最高的优先级，解决block团队的问题。

和朋友一起交流，以前觉得印哥哥里面很多特别能讲的，但是工程能力不突出的，反而最终很多成为了较高的管理层，以前很不理解。现在觉得，他们身上很多值得我们学校的优点，比如leadership（以前对这个词嗤之以鼻，现在越来越体会到这个词的重要性），沟通能力。这个确实值得我们学习。

感谢楼主分享！

作为lower level说一下对于lower level的individual contributer认识吧，虽然写代码是工作中很小的一部分甚至是最简单的部分，是因为基本所有的沟通交流设计等等都是围绕implementation来做的。代码占得比重小不代表不重要。只有清楚了问题，设计好才可能又快又好的完成任务。

而面试的过程，虽然都是leetcode style problem。但是面试的重点并不是你能不能像考试一样解出这个问题，而是通过问题作为媒介，看看你有没有很快的适应能力，解决问题的思路是什么样的，是不是会沟通会简化问题等等的一系列的能力。Senior的面试过程，我相信，能通过短时间准备出来的系统设计能力也并不能真正通过45分钟的一道系统设计问题就能体现出来的。平时的积累，对软件开发的认知，解决问题的思路这些看不见摸不着的能力实际上会通过一系列面试过程中的细节，被更senior的面试官看的一清二楚。

希望大家像楼主说的一样，不要很功利的去刻意准备面试呀跳槽呀这些，package oriented去干一些事情，而是沉下心来把手头事情做好，做深，锻炼各方面的能力，更不能忽略自己的代码能力。当你真的想去换一份工作的时候，这些能力会自然而然的显现出来。

gongchen 发表于 2019-7-21 11:45
感谢楼主分享

现在西海岸互联网公司的风气和楼主说的是相反的。我基本没见到过面试会*专门*考察面试者如 ...

我觉得这个和组之间有关，it depends. 有的组面向外部客户，偏重business 需求，那有的组就是纯service team或者infrastructure team。我现在自己的组基本上就是platform as a service, 基本上就是我们自己搭建好data platform，让下游的组来用，他们自己发挥服务他们的客户。如果类似外部产品的组，确实很多需求和上游交流，下游交付。不过anyway，什么组都是需要有效沟通，把自己的idea和外面表述表达清楚。我们组的国人TPM也鼓励我们这种国人多说，不能被其他人霸占话语权。

swufejun 发表于 2019-7-22 05:36
我觉得这个和组之间有关，it depends. 有的组面向外部客户，偏重business 需求，那有的组就是纯service t ...

同意external customer facing的组和internal的组在需求管理的流程上不太一样。我的观察是internal的组获得的来自engineer的需求一般都比较清晰。

可能也和一个组的新旧有关系。即使是external customer facing的组，如果非常成熟，没有大的product/feature要从头做起的话，我觉得需求管理的压力其实也是很小的。

补充内容 (2019-7-22 05:59):
我觉得这其实可以解释为什么现在北美互联网公司的面试其实并不侧重楼主说的“需求管理”。因为北美大型互联网公司在做崭新产品的组少之又少。成熟的组新入职的engineer先会花大量时间读codebase，这和grind lc很像

swufejun 发表于 2019-7-22 05:36
我觉得这个和组之间有关，it depends. 有的组面向外部客户，偏重business 需求，那有的组就是纯service t ...

其实PaaS的话也很注重需求管理

可能不是你说的那种业务需求，但是可以考虑，或者大而化之，内部组也是业务需求呀。
是不是其他组有什么需求你们能够提供，但是现在没有提供呢？这个都是要靠聊出来的。没准你们和几个组一拍即合就能聊出一个还不错的项目？

“让下游的组来用” 这里面可以做太多文章了，例如下游的组用的好不好？怎么调查怎么知道？要不要Build up a metric regularly measuring it? 没准在让下游的组用的happy这快还能做出很多意想不到的东西

需求拿到了就可以选型自己心水的技术了

gongchen 发表于 2019-7-22 05:45
同意external customer facing的组和internal的组在需求管理的流程上不太一样。我的观察是internal的组获 ...

旧组的话technical stack比较旧，更新technical stack也是算是一个需求，这个时候如果能够非常清楚地跟老板陈述利弊，把这件事情deliver出来，也是一个很不错的事

我觉得技术的重要性是看领域的，当你说“技术选型”的时候，实际上已经是“下游客户”了。而你所选的那些“型”，例如各种语言DSL、前后端框架、分布式框架、数据库系统，才真正是技术竞争激烈的领域。

打个比方，一个食品公司引进机器做产品，对于这家公司来说，至关重要的当然是产品好不好吃、包装好不好看、广告打得怎么样能不能吸引到客户来买。当然，生产车间里有些老师傅对机器特别熟悉，操作起来也很熟练，他们使用同样的原料可以生产出更好更多的产品。甚至有些人对机器本身颇有研究，自己可以对其进行一点改造以优化效率甚至扩展一些新功能 —— 这些技术上的东西好不好呢？当然是好的。但就这个食品公司而言，管理者当然不觉得这些技术上的东西有多重要，有时甚至会觉得带来了反作用 —— 员工净想着鼓捣一些机器相关的东西、不好好干活生产产品、不想着用户的体验怎么办？—— 但如果是上游设计制造机器的公司，那重点就完全不一样了。组织管理要不要？当然还是必不可缺的。但此类企业的生存之本必然是围绕着技术竞争力来的，技术上有短板甚至被别人拉开了代差，那就很难生存。

在软件行业，由于开源的存在，上游技术的存在感被淡化了（对应的，想想芯片制造以及航空发动机），使得你现在可以很舒服的从一大堆开源组件中“选型”并宣称“写代码只是一小部分” —— 这是一件好事，也是开源倡导者的初衷所在。但我觉得另一方面也要有critical thinking，知道这些便利从何而来，因为世界并不一定会一直这样运转。另一方面，即是是现在，对于很多大公司以及正在成长壮大的公司来说，“free lunch”早已不够用了，使得这些公司必须自造轮子以应付高并发、海量数据、机器学习等各种拓展性的领域并提高程序员在这些领域下工作时的劳动生产率。对于这些领域来说，没有技术你就做不成事情。

magicsets 发表于 2019-7-22 15:34
我觉得技术的重要性是看领域的，当你说“技术选型”的时候，实际上已经是“下游客户”了。而你所选的那些“ ...

另一方面也要有critical thinking，知道这些便利从何而来，因为世界并不一定会一直这样运转

这个是的，知其然且知其所以然，所以我觉得技术选型是一个很重要的能力，知道什么场景用什么。

当你说“技术选型”的时候，实际上已经是“下游客户”了

下游客户并不一定不好，需求管理的同时需要和上游密切合作。

员工净想着鼓捣一些机器相关的东西、不好好干活生产产品、不想着用户的体验怎么办？

我比较倾向于去主动发现需求，去主动调查用户的体验，发现需求，然后尝试掌控整个流程deliver用户的需求，也同时带着我们组的人这样做

gongchen 发表于 2019/07/22 00:45:19
感谢楼主分享

现在西海岸互联网公司的风气和楼主说的是相反的。我基本没见到过面试会*专门*考察面试者如何做好“上游的需求管理”，就更别提特别考察“下游的交付”了。

junior基本是纯lee...

到一定级别才能看见楼主说的这些。你没见过不代表没有啊

以前觉得面试leetcode不好都是刷的题 现在觉得真是很好 工作中碰到的老油条多数都是学不会东西不怎么干活但是死命抢credit写email想办法坑别人的货  刷题是能把这些老油条挡在外面的有效办法之一   让这些老油条也不至于一门心思专研坑人抢功劳   

感谢楼主分享

现在西海岸互联网公司的风气和楼主说的是相反的。我基本没见到过面试会*专门*考察面试者如何做好“上游的需求管理”，就更别提特别考察“下游的交付”了。

junior基本是纯leetcode style coding problem。面试比较用心的公司会在其中考察一些“上游的需求管理”，但是我的观察是大部分不会。

senior基本再加上system design。

如果optimize for TC的话，两到三年跳一次槽。

我同意楼主强调的这些点都是重要的。但是为什么现实情况里，追求更大的tc和scope要做的事却不是这样的呢？

本文被提升为 全站置顶话题：凡是在前三页回复里参与讨论，提供言之有物、切中主题的高质量回复，管理员会积分奖励，干货越多奖励越多。好的回复，往往会得到50-100积分奖励。

看到好回答，请加分、请顶上去。对认真码字、热心分享的同学表示感谢，今后大家也会看到更多精彩分享。
说明：给别人加分不会扣除你的积分。

刚进职场**觉得这些都很虚啊，连组好不好都还看不出来。希望过段时间能体会到楼主写的点。

感谢lz分享。虽然现在的工作年限还不足以完全切身体会到lz说的每一条感受，但是我觉得很快就会全部感同身受。常说一句话，能用技术和钱解决的问题，一般都不是问题。而更多你无法很快解决的往往是一些与人打交道的事情，就像lz提到的上游需求管理，下游交付，英语交流等等这些。刚入行，写代码就是工作的全部，千万不要急，后面想要的领导力和组织力，还是需要有扎实的技术和业务功底才行的，不然楼盖的太快，地基不牢。随着工作时间越来越长，写代码的占比就会越来越小，这时候就可以把更多精力和时间用在组织力和领导力的培养上。

需求也是要懂技术的，没有技术做根基，提的需求就会很傻逼，有技术，你作为管理者提需求可以更多方面的考虑，可实现度，可拓展性，需要的bandwidth，复杂度，分配多少人来完成。交流是很重要，但是不能过分重视交流，5分钟应该说清楚的事情，用了15分钟，但最后事情干的漂亮，比净说漂亮话管用