《Team Geek: A Software Developer's Guide to Working Well with Others》读书笔记（一）

《Team Geek: A Software Developer's Guide to Working Well with Others》

Brian W. Fitzpatrick ，Ben Collins-Sussman

 

这是本讲软件开发团队建设的文章，作者有着丰富的开源软件开发及在Google工作的经验。

 

在Introduction中提出了“Engineering is easy. People are hard.”的基调，强调软件开发的成功关键不仅在于写出色的代码，还在于人们朝着目标努力而进行协作的方式。

the key to a project’s success wasn’t just writing great code: the way in which people collaborated toward the end goal mattered just as much.

 

Chapter 1 The Myth of the Genius Programmer

 

软件开发是一项团队运动，成员在行为上要遵守humility, respect, and trust，这三个核心原则，即谦逊、尊重和信任。

software development is a team sport. And in order to succeed on an engineering team, you need to reorganize your behaviors around the core principles of humility, respect, and trust.

 

人们天生有一种不安全感insecurity，害怕别人的批评，所以倾向于将自己所从事的东西隐藏起来，直到有结果的时候才愿意向外公布。

工程师们都希望自己是genius，相信Genius Myth，但genius也会犯错误，同样需要与他人进行合作才能成功。

But even if you are a genius, it turns out that  that’s not enough. Geniuses still make mistakes, and having brilliant ideas and elite programming skills doesn’t guarantee that your software will be a hit. What’s going to make or break your career is how well you collaborate with others.

 

这种Genius Myth使人更倾向于隐藏自己所从事的东西，不愿与人进行交流，怕别人发现自己的错误后会破坏自己的形象。

It turns out that this Genius Myth is just another aspect of our insecurity.

 

如果工程师将所有时间都用在了单独工作，不与人交流，则增加了失败的危险。这种行为无异于赌博，埋头忙自己的工作，而不顾其他，有可能到头来是重复别人已经完成的工作，重新发明轮子。

If you spend all your time working alone, you’re increasing the risk of failure and cheating your potential for growth.

you need to make sure that you’re working on the right thing, you’re doing it correctly, and it hasn’t been done before.

 

所以，越早得到反馈，风险就越低。如果要失败，就早点失败，不要在最后投入了更多后才发现失败是唯一的选择。

Remember the tried-and-true mantra of “Fail early, fail fast, fail often”

“Failure is an option.” It’s widely recognized that if you’re not failing now and then, you’re not being innovative enough or taking enough risks. Failure is viewed as a golden opportunity to learn and improve for the next go-around.

 

分享工作也降低了项目的运行风险，即降低了所谓的Bus factor。如果有人由于某种原因离开了团队，由于没有进行工作的分享，其他人不了解他的工作，会导致项目的重大损失。

Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed.

 

分享工作，与他人沟通协作，可以为工作带来不同的视角。

you often find yourself needing a second pair of eyes.

 

及时得到反馈，及时进行修正，从而保证工作是朝着目标进行的，且提高工作质量。

This is how we keep code quality high and make sure our software is evolving correctly bit by bit.

Projects run into unpredictable design obstacles, or political obstacles, or simply discover that things aren’t working as planned.
Requirements morph unexpectedly. How do you get that feedback loop so that you know the instant your plans or designs need to
change? Answer: by working in a team.

 

三根支柱

Humility
You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement.
Respect
You  genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and  accomplishments.
Trust
You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.

 

丢掉自我Lose the Ego。 不要表现出自己像是最优秀的人物，要保持谦逊。要承认自身的不足，不要表现得know-it-all，好像自己全知全能。工作的目的不是为了表现自己，而是为了团队的成绩。

rather than worrying about whether you’re personally awesome, try to build a sense of team accomplishment and group pride.

 

对于出色的工作成果而言，批评是工作中必不可少的一部分，它使我们的工作变得更好。关键是要分清建设性批评和个人攻击间的差别。

Criticism is almost never personal in a professional software engineering environment—it’s usually just part of the process of making a better product. The trick is to make sure you (and those around you) understand the difference between constructive criticism of someone’s creative output and flat-out assaults against someone’s character.

 

要学会礼貌地提出建设性批评，对事不对人。

Learn to respect your peers and give constructive criticism politely.

 

另一方面，要学会接受别人的批评，改进自己的工作。

On the other side of the conversation, you need to learn to accept criticism as well.

 

对工作进行记录，便于以后跟踪。写下得失与各种想法。

A proper postmortem should always contain an explanation of what was learned and what is going to change as a result of the learning
experience.