一个人的成长输入一般来源于三部分:工作,学习,交流。能力提升讲究"知行合一",工作是"行"很重要的部分。剩下的两个是丰富了我们"知"的部分。
在工作中对于程序员来说不停的做项目是主要工作,所以通过项目成长是最快的一种方式,很多工程师也很享受这个过程。但如果一年到头一直在做项目,你可能在一家外包公司。
对于一家做产品的公司,如果你同样一年到头的做项目,有可能这是一件初创公司,确实很多系统需要补,很多基建需要搭。如果是在一家成熟的公司,一直在做项目,可能是大家在一起陪着PM试错,这两种情况都不属于很理想的状态。
所以并不是做的项目越多越好,重复的项目不会给工程师带来新的成长,不停的做项目首先缺少了学习新知识的机会和时间,也会让工程师大脑养成习惯性的浅度思考,而不是深度思考。
正常的理想状态应该是在项目空闲期间做一些非项目的事情,同时沉下心来去思考下之前做的项目本身解决了什么问题,他们组合起来对于业务有什么价值。
任何项目都有一个目标,当项目完成后,目标就算基本达成了。但是,客户真的满意了吗?系统的可用性、可靠性、可扩展性、可维护性已经做到极致了吗?
这几个问题的答案永远是否定的。所以,任何一个有价值的项目,都可以一直深挖。深挖项目,深度思考还可以锻炼工程师的创造力。期望不停地做项目的人,就像一个致力于训练更多千里马的人是发明不出汽车的。锻炼创造力也不是一蹴而就的事情,需要长时间地思考。总之,工程师们应该总是觉得时间不够用,毕竟时间是最宝贵的资源。
当然对于一个团队来说,如何帮助团队成员成长,更多是团队leader的事情。从技术发展的角度来说,技术管理者应该关注自己所能把控的活跃项目的数量,并致力于提高活跃项目的影响力和技术深度。团队人数要与个人管理能力、规划能力和需求把控能力相适应。一份工作让多个人来干,每个人的成长都受限。每个人都做简单重复的工作,对技术成长没有任何好处。团队管理和项目管理需要循序渐进,不要“拔苗助长”。
当然团队中的TL也存在一些问题,这些问题主要是出现在一些新进的leader身上,他们刚从一线的个人贡献者升级成TL,技术习惯还没有改过来,同时由于变为了TL,工作时间投入到技术之外的时间就多了,他们对于技术开始出现了不安全感,也就造成了某种"成为技术老大"的形象。
想要通过证明自己技术是团队最牛B的,捍卫自己的技术权威。我个人认为这种思路是不正确的。首先很难做到"技术第一",技术这件事本身就是范围很大的事情,有的人擅长架构,有的人擅长算法,有的人适合做业务架构,有的人喜欢搞基础底层。如果一个TL不能转变这种思路,变为成长型思维,那他往往就是团队的天花板。
甚至有些TL为了保障自己在团队内部的技术权威,认为的制造一些沟通比例,通过创造信息不对称性,体现自己权威。比如不向下传达上面的OKR,让下面人做一些事情,最后说你这个目标不服务于团队OKR,进而否定你的技术产出,我觉得这种人不应该成为leader,没有任何价值。
对于一个技术能力一般,发展潜力一般的团队而言,如果你是技术最强者,这与其说是幸运,不如说是悲哀。这种场景被称之为“武大郎开店”。团队里的技术顶尖高手不是不能做,但为了能够持续成长,需要满足如下几个条件:
1. 首先你得是行业里面的顶尖专家了——实在很难找到比你更强的人了!
2. 其次,你经常需要承担对你自己能力有挑战的任务,但同时你拥有一批聪明能干的队友。虽然你的技术能力最高,但是在你不熟悉的领域,你的队友能够进行探索并扩展整个团队的知识。
3. 最后,你必须要敏而好学,不耻下问。
否则,加入更强的技术团队或许是更好的选择,最少不是什么值得骄傲的事情。
技术圈总部缺乏一些新的热点,微服务,分布式,云原生,中台、平台化。也就造成了很多同学拿着锤子找钉子,用自己当时当下学到的一个东西想要去解决眼前需要解决的问题,这是很错误的,不同的问题有其对应的解,没有银弹。
出现这种问题的同学往往是那些团队中还算比较上进,对于技术有一定热情的同学,平时会接触很多新的概念,也喜欢把概念放在嘴边。比如平台化算得上是“高大上”的代名词了,很多工程师挤破头就为了和“平台化”沾点边。
然而和其他业务需求相比,平台化需求并没有本质上的区别。无论是平台化需求还是普通业务需求,它的价值都来自于客户价值。不同点如下:
1. 很多平台化需求的客户来自于技术团队,普通需求的客户来自于业务方。
2. 产品经理不同。普通业务需求来自于产品经理,平台化需求的产品经理可能就是工程师自己。
3. 很多平台化的关注点是接入能力和可扩展性,而普通业务的关注点更多。
归根结底,平台化就是一种普通需求。在实施平台化之前,一定要避免下面两个误区:
1. 平台化绝对不是诸如“统一”、“全面”之类形容词的堆砌。是否需要平台化,应该综合考虑:客户数量,为客户解决的问题,以及客户价值是否值得平台化的投入。
2. 平台化不是你做平台,让客户来服务你。一些平台化设计者的规划设计中,把大量的平台接入工作、脏活累活交给了客户,然后自己专注于所谓“最高大上”的功能。恰恰相反,平台化应该是客户什么都不做,所有的脏活累活都由平台方来做。
本质上讲,平台化的价值来自于技术深度。真正体现技术深度的恰恰是设计者能够轻松把所有脏活累活搞定。
所以平台化的最佳实践是:投入最少的资源,解决最多的问题。平台解决一切,客户坐享其成。
以我做中台和平台的经验来讲,做中台其实是在"业务后面",也就是我们的需求来源于前台业务的rd,他们给到我们的需求往往是确定的,变化是来源于多个前台的确定的业务到中台系统之后造成的"不确定性"。
所以做中台并不代表着高并发,因为更高的并发场景已经在前台业务自己处理了,前台业务和中台的业务可能通过mq,或其他异步方式衔接就可以了。所以中台系统更多的挑战可能是来源于"业务复杂度",是需要一些程序员的通用能力的。
对于我个人来说,当一个程序员积累了一定的通用技术能力之后,反而需要走到前台去,因为只有前台你才能更近的接触到业务本身,知道用户的痛点,才对于你积累业务能力有所帮助,因为程序员的发展归根结底是解决问题,解决业务问题,离问题越近,问题解决的越好。
除了中台系统还有就是中间件了,经常听到人表达对基础技术部同学的敬仰之情,而对搞业务技术的同学表示轻视,认为存储、消息队列、服务治理框架、Hadoop 等才能被称为真正的技术。事实并非如此,更基础的并不一定更高深。
比如下面这个流传很久的段子:越高级的语言就越没有技术含量。但真是这样吗,就拿 Java 和 C 来说,这是完全不同的两种语言,所需要的技能完全不同。C 或许跟操作系统更加接近一点,和 CPU、内存打交道的机会更多一点。但是为了用好 Java,程序员在面向对象、设计模式、框架技术方面必须要非常精通。Java 工程师转到 C 方向也确实不容易。
基础技术和业务应用技术必然会有不同的关注点,没有高低之分。之所以产生这种误解,有两个原因:
第一,基础技术相对成熟,有比较完整的体系,这给人一种高大上的感觉。业务应用技术相对来说,由于每个团队使用的不一样,所以成熟度参差不齐,影响力没有那么大。
第二,基础技术的门槛相对来说高一点,考虑到影响面,对可靠性、可用性等有比较高的最低要求。但是门槛高不代表技术含量高,另外成熟技术相对来说在创新方面会受到很大的约束。但是最先进的技术都来自活跃的创新。
对比下来,业务技术和基础技术各有千秋。但真正的高手关注的是解决问题,所有的技术都是技能而已。
当然我个人认为,如果你搞过中间件,对你技术基础是有一定砸实的作用的,对于技术基本的原理和类库使用更加熟练一些,但是可以做好基础架构和做好业务架构是两回事。我见过一些公司的技术负责人是以前基础架构的负责人,比如搞分布式MQ的,搞分布式存储的。
这些不一定可以做好一个电商的的商品架构或是一个电商的供应链架构,虽然技术相通,但因为业务才造就了不同的系统,在架构师这个层次上对于业务的理解大于对于技术的理解。
在做一个架构之前讲究调研,看公司里面相同业务团队怎么搞,看业界相同业务怎么搞,看公司对于团队什么定位,有哪些资源可以集成,最终决定了你的方案的可行性。做可行性调研要避免如下情况:
1. 把可行性调研做成不可行性调研,这真的非常糟糕。不可行性的结论往往是:因为这样或者那样的原因,所以不可行。
2. 避免“老鼠给猫挂铃铛”式的高风险可行性方案。可行性调研一定要细致入微,避免粗枝大叶。
3. 避免调研时间过长。如果发现调研进展进入到指数级复杂度,也就是每前进一步需要之前两倍的时间投入,就应该果断停止调研。
可行性调研的结论应该是收益与成本的折衷,格式一般如下:
1. 明确预期的结果,并按照高中低收益进行分级。
2. 阐述达成每种预期结果需要采取的措施和方案。
3. 给出实施各方案需要付出的成本。
如何获得更好的成长除了技术的硬实力之外,软技能也很重要,当然人与人之间差别不大,造成这些差别的主要原因是做问题的方式方法造成的,有的时候我们需要找到一个最合适的方式,不一定是最完美的方式。不管是业务迭代还是架构迭代,老板关注的是:效率与落地。
经常看到有些同学给自己的绩效评分是 100 分——满分,原因是在过去一段时间太辛苦了,但最终的绩效却一般般。天道酬勤不错,但是天道更酬巧。工程师们都学过数据结构,不同算法的时间复杂度的差距,仅仅通过更长的工作时间是难以弥补的。为了提升工作学习效率,我们需要注意以下几点:
1. 主要关注效率提升。很多时候,与效率提升所带来的收益相比,延长时间所带来的成果往往不值得一提。
2. 要有清晰的结果导向思维,功劳和苦劳不是一回事。
3. 做正确的事情,而不仅仅正确地做事情。
做架构类似,架构永远不是理想态,在方案评审时需要考虑落地成本和可行性,落地永远比高大上的方案重要,你的产出也主要是看落地,不好落地代码在完美,方案选型在牛B也没用,架构永远是不完美的技术,遵循"简单,合适,可演进"即可,解决问题最重要。