孙秀楠的网站

博客

  • recommend some books

    It’s time to recommend some books, for we should prepare some soft skills to become an agile developer and work more effective and efficient. All three books don’t have code, and will not explain the programming technology, they focus on engineering practices, people in development process, etc. I have finished book 1) and 2), and I am reading 3).

     

    1)      <The Pragmatic Programmer: From Journeyman to Master>, 5 stars in Amazon.

    Customer review:

    Hunt and Thomas vastly exceeded my expectations. This book is never dry, often humorous, and always educational. They don’t always say what you expect them to say (e.g., about commenting code), and I didn’t always agree with them, but every sentence is full of thoughtful analysis.

    One of the best features is their incredibly practical advice — while yes, this book does teach philosophy and encourages thought, it also provides many immediately-implementable suggestions.

    Chinese version: http://www.amazon.cn/%E7%A8%8B%E5%BA%8F%E5%91%98%E4%BF%AE%E7%82%BC%E4%B9%8B%E9%81%93-%E4%BB%8E%E5%B0%8F%E5%B7%A5%E5%88%B0%E4%B8%93%E5%AE%B6-%E4%BA%A8%E7%89%B9/dp/B004GV08CY/ref=pd_sim_b_2

     

    2)      <Practices of An Agile Developer: Working in the Real World>, 5 stars in Amazon

    Customer review:

    In my own work, I am struggling with various agile vs. non-agile practices, but sometimes it can be hard to see why a non-agile practice is worse in the long run than an agile practice. This books goes a long ways toward identifying the problems with non-agile practices by identifying an agile practice, then showing the benefits of following it as well as the result if it isn’t followed. Throughout the book, a little angel and a demon show up-the angel illustrating a “good” practice, and the demon illustrating a “bad” practice. This makes the book a fun read and I think really helps in illustrating the authors’ points.

    Chinese version: http://www.amazon.cn/%E9%AB%98%E6%95%88%E7%A8%8B%E5%BA%8F%E5%91%98%E7%9A%8445%E4%B8%AA%E4%B9%A0%E6%83%AF-%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E4%BF%AE%E7%82%BC%E4%B9%8B%E9%81%93-%E8%8B%8F%E5%B8%95%E6%8B%89%E9%A9%AC%E5%B0%BC%E4%BA%9A%E5%A7%86/dp/B0033WSFAO/

     

     

    3)      <Team Geek: A Software Developer’s Guide to Programming Well with Others>, 5 stars in Amazon

    Customer review:

    Brian Fitzpatrick leads Google’s Data Liberation Front and Transparency Engineering teams. Ben Collins-Sussman is one of the founding developers of SVN and now manages the engeneering team for the Google Affiliate Network. The Book has a clearly defined goal – to help programmers become more effective and efficient at creating software by improving their ability to understand, communicate with, and collaborate with other people.

    And that is the essence of this book. It explains why each relationship (not only related to Software projects) should be based on Humility, Respect and Trust (HRT).

    Chinese version: http://www.amazon.cn/%E6%9E%81%E5%AE%A2%E4%B8%8E%E5%9B%A2%E9%98%9F-%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E5%B8%88%E7%9A%84%E5%9B%A2%E9%98%9F%E7%94%9F%E5%AD%98%E7%A7%98%E7%AC%88-%E8%8F%B2%E8%8C%A8%E5%B8%95%E7%89%B9%E9%87%8C%E5%85%8B/dp/B00BLZMG8W/

  • 如何当好软件开发小组长（一）

    软件开发企业中，所谓小组长team lead，也叫一线经理，大多数是控制一个项目的开发、发布、质量控制、过程管理、人员分配等等各种事情。我在现在单位就是一个小小的team lead，做的事也是这些事情。本篇博文就我自身经验体会，讲讲如何做好一个小组长。

    1）如何考察组员的绩效？

    这其实是小组长最大也最困难的一部分工作，相对而言，完成项目进度不算是大事。绩效考核关系到组员接下来的工资水平，级别提升，是真正与个人利益挂钩的部分。现有的绩效考核依然是以长期观察为主，以产出结果为主，以努力程度为主。有没有那种天才，一周工作三小时即可呢？也许有，但是我看到的大多数根本没有努力到拼天赋的地步。有的人想法就是过得舒服开心，有的人是要努力挣钱养家，不同的想法决定了不同的工作态度。但是，有一部分人既想着少干活，又想着干俏活，只干出彩的部分。那这时候就要给他们足够复杂的任务，把压力提升一点，让他们从60分的结果提升到80分的产出。

    考察绩效很重要几点，一是跟自己比较，相比去年这段时间，应该有所提升，比如去年还是engineer，今年已经是senior engineer，从job description的描述上，工作能力工作范围都应该有变化，独立工作能力以及辅助其他人工作的部分都要大大增强。二是跟同级别的其他组员比较，当然这只是小组长自己观察的结果，同样级别的同样工作经验的，相比结果如何如何。三是看长期的努力，因为绩效考核基本上是半年或者一年一次，如果这个人只是在考核前努力工作，这种工作态度很不可取。另外要通过数据说话，比如任务的复杂度，完成工作的百分比，可以通过每周状态报告跟踪记录。

    2）如何沟通？

    作为小组长，最重要的工作不是自己去干活，而是给组员创造条件或者阻挡风雨，产出更多的结果。沟通相比编码来说，要更为重要。沟通包括与上级manager的沟通，与美国的高级经理的沟通，与PM的沟通，与其他项目组（或者测试组）的沟通等等。

    由于是外企，英语是沟通的最基本语言。现在拿起电话，基本上就是英语随口就来（吼吼），参加英语会议也不紧张了。其实人就是锻炼出来的，大学生的英语四六级通过，加上一两年的逼迫锻炼，基本上听说都不会有太大问题。

    最快捷的方式就是打电话，打完电话再发一封邮件确认重点。如果有视频，那么会效果更好。其次是通过sametime这种即时聊天，信息量要差一些，但是对于写强于说的中国人来讲要更顺手。最后当然也是最常见的就是发邮件，时效性差，信息量大，而且可以配图加附件。具体哪种方式适合，要看具体的问题和紧急程度。

    如果与组员的沟通，现在大多数是找个小屋子，聊上十几二十分钟。但是软件开发人员一般不愿意直接表达想法，拐弯抹角的，这时候我一般是不管他的内心想法，而是就事论事，讲讲自己的看法，应该怎么做比较好，然后让他说说为什么有什么不同的意见。

    现在项目多了以后，会有几个项目leader，负责各个具体的项目开发，我这里基本上算是救火队员和总控制台。这些项目leader以前也是开发人员出身，没有项目管理经验，没有沟通经验。举个简单的例子，某次单独聊天，我说要给你这项目加个任务，这位leader立刻就说我做不了，人手不够。排除掉真正的人手不够，作为小组长其实很难与manager说我做不到。我于是解释给他听，首先一点作为manager发任务一定是事先考虑过，相信这个项目组能完成这个任务，这是大前提。在这种情况下，草率的说“我做不到、做不了”其实是项目leader不成熟的表现。为什么做不了，从manager这里有什么可以帮忙协调的，比如说手头几个任务，是不是可以排排优先级推迟一两个，都可以商量讨论。

    没错，team lead最重要的日常工作就是商量讨论，而不是下命令。哪些有问题，哪些很紧急，排出优先级，找不同的人商量开会定结果要资源等等。另外作为项目leader和team lead最重要是有独立工作能力，不能“等、靠、要”。等，是指任务到手上，就是自己的事情，不能说“我发邮件给某某了，现在这事是某某的了”，而应该一直追踪事情进展状态到有结果为止；靠，是说自己业务上技术水平上有依赖思想，我做这个你得给我什么培训你得教我什么，不是说有培训不好，在培训的同时或者没有培训的情况下，尽可能从现有代码文档中找到线索，这时候我们问出来的问题就比什么都不知道强很多，而且对方也会感觉我们的问题在点上；要，是指需要美国的技术经理或者更高一级的经理下决定，否则事情就没法进展下去，不知选择哪个方案了，或者是你让我做什么我就做什么，不多做一点，这种独立思考和决策能力其实是大连这种地方最缺少的特质。

    先写到这，有时间继续写下一篇。

    另外在豆瓣创建了一个豆列“软件开发小组长必读”，http://book.douban.com/doulist/2429763/ 供大家参考。

  • 到公司第一件事是什么？

    This is email to whole team about “how to work better”

    当你到公司打开电脑后第一件事是什么？

    如果你的答案不是检查outlook今天的Calendar，建议把这件事作为首要任务，尤其是上午要做什么，更是很重要。比如我今天安排，上午一个面试，一个与performance review有关的培训，一个与lead的会议，这几件事都很重要。

    另外我们要注意与onshore的会议时间，会议电话id，有没有sametime会议链接，需不需要电脑。如果需要电脑，我建议有一个人提前15到20分钟去配置一下。如果是视频会议，那可能就要提前30分钟。另外相关人员准备一下材料，不要到时候临时去电脑里搜索，都拷贝到桌面，直接可用。如果这个人在线，可以ping他一下打个招呼。

    然后就是查看邮件，有的需要回复，有的只是参考。需要回复的一定要记下来，比如立即回复或者下班前给出结果。对于负责某个项目或者某整个项目的人来说，收到重要的邮件要立即与我沟通协商，该如何回复，如何make decision。

    邮件也最好用OneNote分分类放到不同类别下。

    看完邮件，没什么需要立刻回复的，这时候可以去泡茶喝水，稍微放松一下，然后开始一天的工作。像我基本上早上十到二十分钟会浏览一遍邮件，然后再找时间仔细看。

    最后很重要一点，注意身体健康，要吃早饭，可以到x号楼，稍早一点，既不用担心压车，又是一个很好的习惯。

  • 开始办公室里咖啡生活

    花了几天时间研究咖啡机，终于选择了飞利浦 (Philips) HD7450/20 咖啡机，在京东商城220拿下，另外买了一个量极大的国产云南咖啡粉“爱伲咖啡”，500克才42块，全当是玩玩。 http://www.360buy.com/product/1006742289.html 今天都到了，下午在办公室的茶水间试水煮了两壶。不过真是不如以前在罗克韦尔时候用全自动咖啡机出来的效果，不醇。不过怎么说，都要比雀巢速溶喝起来舒服多了。终于可以从普通青年晋级到文艺青年了，下午来一壶咖啡，这生活简直是。

    在咖啡沙龙http://www.coffeesalon.com论坛泡了几天，稍微了解了一下，法压壶貌似好玩，但是不太适合办公室。下一步准备买个磨豆机，然后买豆子试试能不能更好一些。灿坤的电磨很便宜，但是评价一般。有一个豆叔在网上口碑很广，淘宝店里也有一些手磨电磨推荐http://horstcafe.taobao.com/

    另外一个比较人多势众的讨论咖啡的地方就是百度咖啡贴吧 http://tieba.baidu.com/f?kw=%BF%A7%B7%C8 也在里面学了不少有意思的。

    全自动家用型的这个貌似不错 “机器是我最喜欢和推崇的Saeco喜客odea giro型号，这款喜客Saeco odea Giro全自动宝马橙色款是迄今为止我最喜欢的家用咖啡机，外观与功能搭配完美，透过上部磨砂塑料盖，豆仓的咖啡豆余量一目了然，豆量和水量旋钮位于正面，调节简单而直接，杯架高度可上下手工调节，磨豆时刀头声音清脆悦耳，总之，一部完美的好机器。”

    另外搜到大连有家店卖咖啡机咖啡豆，八点咖啡公司dl8icoffee.taobao.com。不知道如何，有机会试试

  • 大连开发组开发流程及注意事项 – 2012-12-19

    1，Desktop大连开发组的开发流程如下，没有例外。
    开始阶段：风险评估，技术难点研究，通过邮件或者会议，确定需求分析。项目Lead需要确定我们得到明确的截止时间，需要保证我们能在预定时间内完成。
    设计阶段：研究设计文档，小组设计评审，具体任务分派，应该保证项目中有新老人员搭配；
    编码阶段有：项目进度报告，每日代码审查。
    收尾阶段应该有： 小组代码审查；需求验证；正式测试；项目总结。产生结果：项目代码发布，小组代码审查文档，测试结果。

    2，每个项目要确保至少有一个Senior成员参与到需求，设计，编码，测试过程当中，保证新老搭配。这个Senior不需要具体编码，但要负责保证从头至尾跟随项目，保证流程按预期进行，指导开发人员，及时发现问题解决问题。

    3，每个项目，SA以及Senior成员应该作为第二测试人员出现，从用户角度测试，不需要遵循测试计划订好的测试方案。

    4，每次正式的小组代码评审，必须有XX, XX和我其中一人参与。

    5，如果任务比较复杂，问题比较棘手，研究了半天时间没有解决方案。请马上联系我或者项目Lead；如果大连组内解决不了，再求助Onshore team。先发邮件说明问题，紧急任务应该马上开会保证及时沟通得出结论。

    6，项目流程方面，如果需要有例外情况，比如不写什么文档，不做测试不评审，请事先通知我或者项目Lead。

    7，在开始阶段对最后整体实现效果有大致理解，可以预估技术难点所在，并且实现进行研究和求助。对于项目可能有的需求变化有一定的预估和计划。在项目开始阶段或者空闲阶段应该研究技术难点。

    8，每项工作应该有结果产出，代码或是文档，或者是周五做一次技术分享。学习应该有文档总结，项目有流程设计文档，代码或测试文档。

    9，代码review不要在下午三点半以后还checkin代码（可以留到第二天上午），如果有例外，应该通知代码审查人员，保证能预留出审查时间。代码应该直观易懂。代码格式应该符合英语常用语法格式，或者跟随onshore同事样式。我们写的每行代码必须能解释清楚，根据哪个需求来的。对于代码审查中发现的问题，必须逐条回复（改或不修改），确保没有遗漏，Group review需要填写正式review结果文档。