这么说吧，我的团队里软件，逻辑，算法都有
基本会有这几种情况需要leader协助解决问题：
1.需求和方案是leader做的，成员实施，因为我写的方案会非常详细，基本可以认为是代码的中文版，细节都有，遇到问题大多是没有严格按方案来干，找到差异点纠正就好
2.需求和方案是成员自己搞的，leader不熟悉，这种情况其实去插手具体代码没有意义，没准还成为了捣乱。这种情况做方案的那个成员一定是最懂的，leader主要是通过跟成员一起分析原理和底层逻辑，协助找到他的思维不严谨的地方，找到疏漏，问题自然就解决了，去直接参与代码是没啥用的
3.问题发生在不同成员或者不同专业的边界处，这种一般是接口没定义好或者相互没配合好，并且成员一般只限定在自己的思维和视角内，看不到全局，迟迟不能解决，这种时候leader是负责拉通，规范接口处的定义和行为，把各部分需要修改的内容归属到具体的责任人。
4.以上都不太需要参与代码，有一种特例需要参与代码，主要是FPGA逻辑设计人员如果经验不丰富，他的代码写的不规范或者掩藏了问题，他自己都说不清楚，这种确实得帮忙看。软件设计人员因为debug手段太丰富了，一般只要你给他理顺了，代码的问题他自己就搞定了
【 在 xeagle 的大作中提到: 】
: 但如果项目delay了几周呢，问题特别多，你也不亲自解决一两个问题？只给简单建议大部分情况没有多少帮助啊，因为是代码细节特别多的那种
: 发自「今日水木 on iOS」
--
FROM 219.145.32.*

team leader写代码是最低优先级的事情，他的最主要工作是给team争取资源，拉人拉项目，给你们升职加薪，搞不定了到处甩锅，一群coder老以为自己干的活是最重要的，纯纯的自我感动。不只是码农行业，所有的行业都是这样。往上走都会脱离业务一线
--
FROM 61.171.199.*

大小不是问题，选个头出来就不是让他单纯写代码的，得发展
【 在 z16166 的大作中提到: 】
: 三四个人的team太小了
: 还不如军队里的一个班。班长也是要拿枪打仗的
:
--
FROM 61.171.199.*

“不是单纯写代码”，和“完全不写代码”，不一样

你好像被绕进去了，哈哈。仔细想想你说的“不是让他单纯写代码”是啥含义


【 在 skywalker222 的大作中提到: 】
: 大小不是问题，选个头出来就不是让他单纯写代码的，得发展
: :
--
修改:z16166 FROM 61.51.229.*
FROM 61.51.229.*

碰到难搞的，直接说一堆专家，领导各种O不处理大问题，让底层码农处理，钱怎么没见多给。养那么多只说不做的高级员工有什么用。

【 在 xeagle 的大作中提到: 】
: 加上leader一共3-4人的小组。leader几乎不写代码，只是review和根据对代码的一些理解(我感觉没有深入研究过代码逻辑)和自己的经验给一些简单的建议。即使项目严重delay了，也不会参与代码开发和bug fix.
: 这种情况正常吗
:
: --
:
: FROM 221.222.20.* [北京–西城区 联通]

--发自 ismth(丝滑版)
--
FROM 180.98.91.*