关于

特别提示:本文说的工作泛指工程方向,这里特指软件研发。没有对其他行业做调研,也不太了解,所以不要全信,也不要不信!

种类(按工作内容)

  • 日常工作:按部就班的作业
  • 应急工作:自己负责的模块出问题后要做的作业(跟日常工作质量密切相关)
  • 研发工作:前两种作业完成后。独立或共同研讨的对策、规划、调研等,不一定是编码

以上是当年刚入职小米时,某总监在一次晨会上提到的。作为已经工作好几年的人,当时听到这个话还是挺激动,所以我就深刻的记下了。一直一来,工作上我都参考这个规则来展开,尽可能避免一直处于日常工作当中的状态。

在软件开发领域,我们常常听到两种岗位:开发工程师和研发工程师,其实想想区别也倒简单,根据以上看哪个做的更多罢了。

思考

算了一下,到今天为止已经满载满荷的工作8个年头了。其中前些年主要还是以写代码为主,近两年开始专职带团队做事。当然工作内容发生了很大变化,所以我觉得有必要有个思考。这篇文章只是一个开始…..

几乎每个技术人也都会面临这个问题,即到某个时间开始带人做事,随着团队规模越来越大,自己写码的时间越来越少,然后出现两个明显的问题:

  • 没更多时间和精力专心撸码,担心技不如人(下次找工作尴尬)
  • 不适应新经理角色,也很难一下做好。随之而来的挫败感大大降低了工作的幸福程度(不如编码实在)

难道对于技术和管理,就没法二者兼得了!?其实不然,关于这个话题的讨论网上有很多。这里不再赘述……

之前在某档管理课程学习的结论直接分享出来:

  1. 专业线解决专业问题,管理线解决业务目标达成。后续并非一定存在高低,更多看个人发展。
  2. 用目标来带动能力的提升(对于管理岗的患得患失)

时间问题

按每天有效时间6小时(2 + 4)算,一周只有30小时,编码如果20%,那就是整整一天…..对于管理8+的一线Leader来说,最好不要超过这个阀值,长期如此大概率会害人害己……

另外几个重要的关键词:惜时主动深度思考

我全要