Google I/O 2009 – The Myth of the Genius Programmer 技术大拿的传说

Categories: Development Notes; Tagged with: Development Notes • Google; @ May 4th, 2013 0:19

Fitz(Brian W. Fitzpatrick) 与 Ben(Ben Collins-Sussman) 是Google的两位技术大拿, 这是他们在09年Google IO上的演讲:https://www.youtube.com/watch?v=0SARbwvhupQ

摘录/翻译一点我觉得挺有意思的部分:

How many people in this room write code entirely by themselves only. Never with other people? or how many like writing code by yourself.
这是一个问题. 很少有人完全独立编程, 但有很多人希望能够独立编程;
How many people in this room do code reviews as part of development process?
多数人举手. 所以, 如果所在的团队没有code review, 是不是该考虑开始code review 或是离开?
Who is afraid of look stupid in front of people?
多数人都不希望在别人面前犯二.
Bus factor is the number of people on your software project that have to get hit by a bus that are gonna leave you in a world of hee.
Lose the ego 放低自己
Criticism is not Evil 批评不是恶魔
At Google, actually, we’re not allowed to submit code into our version control system until there’s code review
在Google, 在提交代码之前必须进行代码审查
When failure does happen, be ready for it, don’t freak out, document what happened, what did you learn from it? what are you going to do different next time? write it up and learn from it
Iterate Quickly: The faster you can fail and the faster you can iterate, the faster you can learn and get better.
Practice is Key
To be a small fish: If you were the senior developer on a team or in a company or something, and everyone looks to you and you’re sort of the teacher, or the king, queen whatever, if you’re only working with people junior to you, you are going to learn things from them, but it’s gonna be harder to improve your skills.
When you are a big fish in a pond, it’s very comfortable, but you’re not really learning very much. you feel safe, but you don’t get much better. and when you are a small fish in a huge pond, it’s very scary.
Be Influenced: the more that you’re open to the influence of other people, who might have a really good idea,
Be Vulnerable: If you can show yourself to be open to change and willing to admit mistake
Case Study: Subversion
It started out with three guys in an office writing a design doc together, just the three of them. Took up maybe two weeks or three weeks, to actually get it right. two or three is best. If you travel with more than six people, you can’t go anywhere…
After we got design doc, we brought it to a larger forum, invited comments, put it up on a web site, and began to get feedback. and then we just started coding, amazingly, about a month or two later, we had some working, very basic working code, and suddenly, as soon as we had working code, suddenly all these people started showing up. we didn’t even advertise, but somehow, it was like we crossed the magic threshold. ( 9 years ago, it was only CVS)
If you do all these things, people will Think You’re a Genius.

JIRA: How to get all issues related to a user 列出用户参与的所有条目 <-> JIRA: Select Estimate and Actually Spent (Logged) Hours