SDE分级
微软的SDE分级大致有这么一种说法
- SDE I: solve easy problems in difficult ways.
- SDE II: solve easy problems in easy ways.
- SDE III: solve difficult problems in easy ways.
- Senior SDE: remove the problems.
但SDE越往上走其实对于「代码本身的能力」不是过于看重了，而更多的是
rm/del - 从源头掐灭产生错误的可能
- hg大叔曾经在demo前夕一不小心删光了repo，心急火燎才重写了一波。从此他坚决不给自己使用rm的机会，他用的所有机器都用alias把rm变成了del，这样起码还能从trash里拯救回来。
- 即便究极巨大的错误也有可能再犯，因此最直接的办法就是从源头掐掉。
制造噪音
- nice的人对周围都很满意，但这样并不吃香，反而会让人觉得「这人很slient，满足于现状，没有改变的动力」。
- 对于别人的做法如果不合适，有意见/建议就需要提出来，而不是总把自己当成「初学者」要「虚心」接受/学习别人的做法。
Ownership
- 当一个task交给你，你就需要从开始到deploy全程把关，保证你的feature最终成功在prod上运行。如果没有办法全程follow，至少也要transfer给其他人，不可以lose the visibility.
- 干过最扯的一个任务，PR过程中韦恩提出是否是DB映射本身出了问题，这样这个code fix就治标不治本了，之后就一直拖沓等待biz回复，拖拉了两三个月。正确做法是当提出这个任务之后立刻和他们多讨论，事实上这个scope已经超出了这个ticket本身，完全可以先治标，开另一个ticket再来治本。
- 另一个比较好的tracking方式是，所有repo不留无效的open PR，这样可以保证该有的feature都能及时进入master。在将ticket标记为done之前，如果不能deploy，也要保证在master中，同时需要让其他人知道这个feature需要和xxx的一起deploy.
- 对于senior SDE来说，他们往往还会比「分配给他们的」更进一步，做一些额外的工作，例如完善documentation, refactor, clean-up, commenting, etc.