1.选哪一种医生
有趣的问题，可以作为日后与团队成员分享的好例子。想到我的小时候，爸爸出差，妈妈上夜班，我就跟着他去了科室（手术室），然后她要上手术台了，我一个人害怕，就跟着去手术间，一个人坐在角落的转椅上，看着一群熟悉的白大褂医生护士们一起给病人做手术。大部分医生在手术台上还是很谨慎，很严肃，不过当他们成功完成一些最关键的环节之后，便时不时自信的跟我开起玩笑。那时虽然对这些叔叔伯伯们很不爽，但是打心里对他们的手术技术真的是相当信任啊。
关于软件职业证书的必要性，那就要看所谓的证书的“含金量”了。证书是如何获取，会考核哪些基本的知识和技能。大学毕业证，其实也算是证书；外部的培训证书也是，但是面试的时候，这些原则都不一定是筛选项，大家总是会说我们更看重的是“能力”。那么问题是，如果我们没有足够的精力去建立“能力识别”的面试模型，那么只能比较粗的靠学校、学历这些“证书”进行一种所谓的“比例化”的筛选。这里谈到了“人才招聘”的问题，目前有一个团队也面临着人才流失、团队平均水平逐步下降的状态。
2.歌唱家的演唱
歌唱家的演唱是艺术，艺术的展现形式会带个人精神上的满足，重复唱那一首经典老歌，经常会让人回忆起过去的某个场景某个画面，亦或者那个曲风那个韵味，就让人神往让人陶醉。而软件工程师需要关注到自己创造的价值是什么，如何让这个价值最大化，包含如何让产品开发周期变得更可控、如何让维护费用支出变少（维护难度降低），毕竟这是一门“工程”。
3.绞刑架的故事
这个故事凸显了一个很现实的问题，从业人数的上涨，带动了软件行业的整体发展，最终也会逐步达到一种饱和。观察到供需关系的变化并结合公司对工程师的要求，公司就会逐步“降低”工程师的待遇（可能就是无法跑赢全行业的平均值）。个人发展的启示（缺）
4.小飞同学的案例
如果选择按原计划继续做，时间是消耗到集成上了，但是团队最终一定是可以发现到这个问题的根源。而及时的、敏捷的纠正自己的错误，这个勇气首先就应该值得肯定，另外团队应该对小范围的错误和失败有一个相对宽容的态度。当然说的这些都是理想情况。现实很残酷，个人会有私心，犯了错误可能会想着要怎么隐瞒，还会想着万一大家没发现呢？另一方面团队在宽容度上，也不一定能够接受，毕竟目标有可能就因为这无法达成了。做为项目管理，对于前期小飞同学的坚持，就应做为风险项，进行必要的监管，一旦尽早的发现问题后，能够及时的执行纠正措施。如果项目太紧，那前期对小飞同学的另类提议就应该予以否决，毕竟整个团队承担不起这样的风险。如果没那么紧，本着鼓励大家创新的原则，是没问题的，而小飞同学自己埋下的隐患，自己也应该把失败的风险主动承担起来，在纠正的过程表现出更大的主动性。另外一点，如果小飞同学成功了，也可以拿来当正面教材来分享。
5.成长与代码量的关系
代码量越大，原则上同时重复性工作也越多，所谓“熟能生巧”；涉及到的问题的类型就越多，所谓“见多识广”。但是如果机械的去写，少了思考，少了归纳总结，恐怕写再多代码，也最多只能停留在熟能生巧，而达不到见多识广了。