Team Geek (豆瓣)

作者: Brian W. Fitzpatrick / Ben Collins-Sussman
出版社: O'Reilly Media
副标题: A Software Developer's Guide to Programming Well with Others
出版年: 2012-7
页数: 194
定价: $ 28.24
ISBN: 9781449302443

豆瓣评分

8.1

42人评价

5星

35.7%
4星

38.1%
3星

23.8%
2星

0.0%
1星

2.4%

评价:

内容简介 · · · · · ·

As a software engineer, you're great with computer languages, compilers, debuggers, and algorithms. And in a perfect world, those who produce the best code are the most successful. But in our perfectly messy world, success also depends on how you work with people to get your job done. In this highly entertaining book, Brian Fitzpatrick and Ben Collins-Sussman cover basic patter...

(展开全部)

作者简介 · · · · · ·

(展开全部)

Brian Fitzpatrick co-founded Google's Chicago engineering office in 2005, and currently leads several of Google's Chicago engineering efforts, including the Google Affiliate Network. He also started and leads Google's Data Liberation Front, a team that systematically works to make it easy for users to move their data both to and from Google. Lastly, he serves as internal advisor for Google's open source efforts. Prior to joining Google, Brian was a senior software engineer on the version control team at CollabNet, working on Subversion, cvs2svn, and CVS. He has also worked at Apple Computer as a senior engineer in their professional services division, developing both client and web applications for Apple's largest corporate customers. Brian has been an active open source contributor for over twelve years. After years of writing small open source programs and bugfixes, he became a core Subversion developer in 2000, and then the lead developer of the cvs2svn utility. He was nominated as a member of the Apache Software Foundation in 2002 and spent two years as the ASF's VP of Public Relations. He is also a member of the Open Web Foundation. Brian has written numerous articles and given many presentations on a wide variety of subjects from version control to software development, including co-writing "Version Control with Subversion" (now in its second edition) as well as chapters for "Unix in a Nutshell" and "Linux in a Nutshell." Brian has an A.B. in Classics from Loyola University Chicago with a major in Latin, a minor in Greek, and a concentration in Fine Arts and Ceramics. Despite growing up in New Orleans and working for Silicon Valley companies for most of his career, he decided years ago that Chicago was his home and stubbornly refuses to move to California. Ben Collins-Sussman is one of the founding developers of the Subversion version control system, co-authored O'Reilly's "Version Control with Subversion" book as well as chapters for "Unix in a Nutshell" and "Linux in a Nutshell." Ben co-founded Google's engineering office in Chicago, ported Subversion to Google's Bigtable platform, and now leads Google's Project Hosting team. Prior to joining Google, Ben was a senior software engineer on the version control team at CollabNet. He has been an active open source contributor for over twelve years, contributing to numerous open source projects, mostly revolving around version control and online gaming. Ben collects hobbies which tend to explore the tension between art and science. He has given numerous talks about the social challenges of software development and Subversion. He writes interactive fiction games and tools, and was the co-winner of the 15th Annual Interactive Fiction Competition. He has co-authored at least five original musicals and received multiple Jeff Awards for musical theater composition. He has an Extra class FCC license for amateur radio, and also spends time learning DSLR photography and playing bluegrass banjo. Ben is a proud native of Chicago, and holds Bachelor of Science degree from the University of Chicago with a major in Mathematics and minor in Linguistics. He still lives in Chicago with his wife, kids, and cats.

豆瓣成员常用的标签(共29个) · · · · · ·

软件开发 Team 软件工程管理 Geek 计算机 programming O'Reilly

喜欢读"Team Geek"的人也喜欢 · · · · · ·

: Being Geek

: DSLs in Action

: Seven Languages in Seven Weeks

: High Performance Browser Networ...

: The Effective Engineer

: 你就是极客

: 软件人才管理的艺术

: How Google Tests Software

: Soft Skills

: 软件加密与解密

我来说两句

短评 · · · · · · ( 全部 14 条 )

Team Geek的书评 · · · · · · (全部 20 条)

做一个关心团队的程序员

juvenxu 2014-09-13 15:23:17

这是一本讲团队的书，当然团队不是一般的团队，而是一帮子Geek组成的团队。这帮人坐在一个屋子里可以当面无话可用IRC聊得热火朝天。书的结构很清晰 1. 团队很重要，为人要HRT 2. 建设团队文化 3. 怎么做个好老大 4. 对付害群之马 5. 公司政治学 6. 关注用户。其实最后一章和...

4有用 / 0没用人民邮电出版社2012版

真的很烦这些五毛啊！

Bryt 2013-04-03 16:21:35

书中的观点应该是很好的，不过这些推荐评论看得让人真恶心！还有，我一直很怀疑这些真正的技术极客们有时间、精力和兴趣（重点是兴趣！）去写这种文采飞扬、煽动人心的团队管理方面的论述性文章.....窃以为多半还是枪手代笔，当然并不妨碍观点的正确性 (2回应)

2有用 / 2没用人民邮电出版社2012版

老外也有办公室政治的

朝雾之归乡 2014-01-20 23:23:45

其实这本书给自己的收获并不多，原因有二：一是自己看了不少介绍软件工程师团队如何工作的书；二是自己在工作中也在不断思考如何才能更有效率地工作，更好地与同事和领导相处；因此，这本书中介绍的内容对于自己来说没有太多的新意。新意没有太多，但是倒是有... (3回应)

6有用 / 0没用人民邮电出版社2012版

Career Improvement的敲门砖

丸子(^.^)v 2013-06-06 04:19:11

New Google employees (we call “Nooglers”) often ask me what makes me effective at what I do. I tell them only half-jokingly that it’s very simple: I do the Right Thing for Google and the world, and then I sit back and wait to get fired. If I don’t get ... (1回应)

6有用 / 0没用

极客与团队 -- 读书笔记连载

samuel 2013-03-25 23:29:02

第一章：天才程序员的传说现今的代码工作再也不是早年个人英雄主义的工作，没有一项伟大的产品不是团队的结晶，没有一位IT天才不是身后站着一个伟大的团队。所以成功的程序员必须是一个依赖团队、帮助团队、成为团队重要分子的人。而在团队合作中我们却经常会犯致命的错误，...

2有用 / 1没用人民邮电出版社2012版

> 更多书评20篇

读书笔记 · · · · · · (共37篇)

我来写笔记

按有用程度
按页码先后
最新笔记

展开收起
Chapter 5 The art of organizational manipulation

siyunxp (生活没有捷径)

Most software engineers work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively.... We call it organizational manipulation. As companies grow, they develop bureaucracy and processes in an effort to manage profit, reduce risk, increase predictability, and support the massive weight of the organization itself. You need to ...
2016-07-25 08:19

Most software engineers work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively.... We call it organizational manipulation.
As companies grow, they develop bureaucracy and processes in an effort to manage profit, reduce risk, increase predictability, and support the massive weight of the organization itself.
You need to underpromise and overdeliver whenever possible.
As an engineer, try to focus your energies on launching products over just about everything else.
As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled.
"Perception is nine-tenths of the law"
We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
Friends come and go...enemies accumulate.
If you can't change the system, there's no point in continuing to put energy into changing it. Instead, put energy into leaving it.
If you don't put the effort into understanding how to navigate your organization, you're leaving a huge part of your destiny to chance.

推荐

回应 2016-07-25 08:19
展开收起
Chapter 4

siyunxp (生活没有捷径)

Chapter 4 When a team is started by a group of angry jerks, the effort tends to attract more and more individuals of the same sort. Certain projects that we won't mention here (like the Linux kernel community) are keen examples of this -- endless bickering, chest thumping, and sniping. lol.... You much protect your team's attention and focus. Ironically, years later, this person's pred...
2016-07-18 09:52

Chapter 4
When a team is started by a group of angry jerks, the effort tends to attract more and more individuals of the same sort. Certain projects that we won't mention here (like the Linux kernel community) are keen examples of this -- endless bickering, chest thumping, and sniping. lol....
You much protect your team's attention and focus.
Ironically, years later, this person's predictions turned out to be correct on many levels, but that didn't stop Subversion from becoming wildly successful anyway -- at least in corporate software development. The point here isn't about who is right or wrong, but whether a disagreement is guaranteed to come to a conclusion and whether it's worthwhile to keep a debate going. ... at some point you need to decide when it's time to cut your losses and move on.
not let "the perfect be the enemy of the good"
The stronger your emotions are, the more likely you are to waste hours or days writing passionate replies to someone who doesn't deserve such attention.
Choose your battles carefully and keep calm.

推荐

回应 2016-07-18 09:52
展开收起
Chapter 2 & 3

siyunxp (生活没有捷径)

--- Chapter 2 --- Five simple rules for running a meeting: 1. Only invite people who absolutely need to be there. 2. Have an agenda and distribute it well before the meeting starts. 3. End the meeting early if you've accomplished the meeting's goals. 4. Keep the meeting on track. 5. Try to schedule the meeting near other interrupt points in your day (e.g., lunch, end of day) If the disc...
2016-07-05 07:58

--- Chapter 2 ---
Five simple rules for running a meeting:
1. Only invite people who absolutely need to be there.
2. Have an agenda and distribute it well before the meeting starts.
3. End the meeting early if you've accomplished the meeting's goals.
4. Keep the meeting on track.
5. Try to schedule the meeting near other interrupt points in your day (e.g., lunch, end of day)
If the discussion didn't happen on the email list, then it never really happened.
Maintaining a uniform style and following conventions means that we can more easily use "pattern matching" to infer what various symbols are and what invariants are true about them.
Today, however, many people may touch a particular piece of code, and the issue of name attribution in a field is the cause of much discussion, wasted time, and hurt feeling.
Code is ultimately about communications with people, not just with a machine.
--- Chapter 3 ---
"Hope is not a strategy."
Don't confuse friendship with leading with a soft touch: when you hold power over someone's career, he may feel pressure to artificially reciprocate gestures of friendship.
Remember that you can lead a team and build consensus without being a peer of your team (or a monumental hard-ass). Likewise, you can be a tough leader without tossing your existing friendships to the wind.
Certainly possible, but what about the costs of having a workforce that behaves like children? Surely that's more expensive than the price of a few pens and USB drives.
As an engineer, you likely developed an excellent sense of skepticism and cynicism, but this can be a liability when you're trying to lead a team.
It's OK to fail, but fail as a team and learn from your failures. If an individual succeeds, praise him in front of the team. If an individual fails, give constructive criticism in private.
When you step into a leadership role, the first thing you'll usually discover is that outside your team is a world of chaos and uncertainty (or even insanity) that you never saw when you were an individual contributor.

推荐

回应 2016-07-05 07:58
展开收起
第92页

怀孕的老鼠要吃猫

The Subversion project had a notable episode in which an intelligent programmer showed up on the email list one day and declared that the entire product was ill-designed. He had seen the light, had radical ideas about how things should work, and insisted that the entire project start over from scratch. He even helpfully volunteered to lead the reboot himself. Without his leadership, he procla...
2013-07-30 18:25

The Subversion project had a notable episode in which an intelligent programmer showed up on the email list one day and declared that the entire product was ill-designed. He had seen the light, had radical ideas about how things should work, and insisted that the entire project start over from scratch. He even helpfully volunteered to lead the reboot himself. Without his leadership, he proclaimed that complete failure was looming just around the corner.
第一反应是这个人是Linus

推荐

回应 2013-07-30 18:25

展开收起
第1页

Siva (在刺激和回应间,我是积极的)

the social perils of software development.
2012-11-21 10:43

the social perils of software development.

推荐

回应 2012-11-21 10:43
展开收起
第3页

[已注销]

所谓的genius就是写出第１个软件原型的人吧
2012-07-25 14:41

所谓的genius就是写出第１个软件原型的人吧

推荐

回应 2012-07-25 14:41
展开收起
第4页

[已注销]

insecurity？是不是应该翻译为“不信任”？？？鲁迅所说过，要不惮以最大的恶意揣测别人的，啊哈
2012-07-25 14:49

insecurity？是不是应该翻译为“不信任”？？？鲁迅所说过，要不惮以最大的恶意揣测别人的，啊哈

推荐

回应 2012-07-25 14:49
展开收起
第5页

[已注销]

Hiding Is Considered Harmful 作者的幽默感。。。
2012-07-25 14:51

Hiding Is Considered Harmful
作者的幽默感。。。

推荐

回应 2012-07-25 14:51

展开收起
Chapter 5 The art of organizational manipulation

siyunxp (生活没有捷径)

Most software engineers work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively.... We call it organizational manipulation. As companies grow, they develop bureaucracy and processes in an effort to manage profit, reduce risk, increase predictability, and support the massive weight of the organization itself. You need to ...
2016-07-25 08:19

Most software engineers work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively.... We call it organizational manipulation.
As companies grow, they develop bureaucracy and processes in an effort to manage profit, reduce risk, increase predictability, and support the massive weight of the organization itself.
You need to underpromise and overdeliver whenever possible.
As an engineer, try to focus your energies on launching products over just about everything else.
As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled.
"Perception is nine-tenths of the law"
We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
Friends come and go...enemies accumulate.
If you can't change the system, there's no point in continuing to put energy into changing it. Instead, put energy into leaving it.
If you don't put the effort into understanding how to navigate your organization, you're leaving a huge part of your destiny to chance.

推荐

回应 2016-07-25 08:19
展开收起
Chapter 4

siyunxp (生活没有捷径)

Chapter 4 When a team is started by a group of angry jerks, the effort tends to attract more and more individuals of the same sort. Certain projects that we won't mention here (like the Linux kernel community) are keen examples of this -- endless bickering, chest thumping, and sniping. lol.... You much protect your team's attention and focus. Ironically, years later, this person's pred...
2016-07-18 09:52

Chapter 4
When a team is started by a group of angry jerks, the effort tends to attract more and more individuals of the same sort. Certain projects that we won't mention here (like the Linux kernel community) are keen examples of this -- endless bickering, chest thumping, and sniping. lol....
You much protect your team's attention and focus.
Ironically, years later, this person's predictions turned out to be correct on many levels, but that didn't stop Subversion from becoming wildly successful anyway -- at least in corporate software development. The point here isn't about who is right or wrong, but whether a disagreement is guaranteed to come to a conclusion and whether it's worthwhile to keep a debate going. ... at some point you need to decide when it's time to cut your losses and move on.
not let "the perfect be the enemy of the good"
The stronger your emotions are, the more likely you are to waste hours or days writing passionate replies to someone who doesn't deserve such attention.
Choose your battles carefully and keep calm.

推荐

回应 2016-07-18 09:52
展开收起
Chapter 2 & 3

siyunxp (生活没有捷径)

--- Chapter 2 --- Five simple rules for running a meeting: 1. Only invite people who absolutely need to be there. 2. Have an agenda and distribute it well before the meeting starts. 3. End the meeting early if you've accomplished the meeting's goals. 4. Keep the meeting on track. 5. Try to schedule the meeting near other interrupt points in your day (e.g., lunch, end of day) If the disc...
2016-07-05 07:58

--- Chapter 2 ---
Five simple rules for running a meeting:
1. Only invite people who absolutely need to be there.
2. Have an agenda and distribute it well before the meeting starts.
3. End the meeting early if you've accomplished the meeting's goals.
4. Keep the meeting on track.
5. Try to schedule the meeting near other interrupt points in your day (e.g., lunch, end of day)
If the discussion didn't happen on the email list, then it never really happened.
Maintaining a uniform style and following conventions means that we can more easily use "pattern matching" to infer what various symbols are and what invariants are true about them.
Today, however, many people may touch a particular piece of code, and the issue of name attribution in a field is the cause of much discussion, wasted time, and hurt feeling.
Code is ultimately about communications with people, not just with a machine.
--- Chapter 3 ---
"Hope is not a strategy."
Don't confuse friendship with leading with a soft touch: when you hold power over someone's career, he may feel pressure to artificially reciprocate gestures of friendship.
Remember that you can lead a team and build consensus without being a peer of your team (or a monumental hard-ass). Likewise, you can be a tough leader without tossing your existing friendships to the wind.
Certainly possible, but what about the costs of having a workforce that behaves like children? Surely that's more expensive than the price of a few pens and USB drives.
As an engineer, you likely developed an excellent sense of skepticism and cynicism, but this can be a liability when you're trying to lead a team.
It's OK to fail, but fail as a team and learn from your failures. If an individual succeeds, praise him in front of the team. If an individual fails, give constructive criticism in private.
When you step into a leadership role, the first thing you'll usually discover is that outside your team is a world of chaos and uncertainty (or even insanity) that you never saw when you were an individual contributor.

推荐

回应 2016-07-05 07:58
展开收起
第92页

怀孕的老鼠要吃猫

The Subversion project had a notable episode in which an intelligent programmer showed up on the email list one day and declared that the entire product was ill-designed. He had seen the light, had radical ideas about how things should work, and insisted that the entire project start over from scratch. He even helpfully volunteered to lead the reboot himself. Without his leadership, he procla...
2013-07-30 18:25

The Subversion project had a notable episode in which an intelligent programmer showed up on the email list one day and declared that the entire product was ill-designed. He had seen the light, had radical ideas about how things should work, and insisted that the entire project start over from scratch. He even helpfully volunteered to lead the reboot himself. Without his leadership, he proclaimed that complete failure was looming just around the corner.
第一反应是这个人是Linus

推荐

回应 2013-07-30 18:25