Team Geek: A Software Developer's Guide to Working Well with Others - excerpt from new book

Here's an excerpt (PDF file) from the new O'Reilly book, Team Geek: A Software Developer's Guide to Working Well with Others, by Brian Fitzpatrick and Ben Collins-Sussman.

In a perfect world, software engineers 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 patterns and anti-patterns for working with other people, teams, and users while trying to develop software. This is valuable information from two respected software engineers whose popular series of talks—including "Working with Poisonous People"—has attracted hundreds of thousands of followers.

Writing software is a team sport, and human factors have as much influence on the outcome as technical factors. Even if you’ve spent decades learning the technical side of programming, this book teaches you about the often-overlooked human component. By learning to collaborate and investing in the "soft skills" of software engineering, you can have a much greater impact for the same amount of effort.

Read excerpt (PDF)

Buy Team Geek on Amazon

• [Sanjaya Kumar]

  The excerpt link takes you to a different book (“running lean”).

• [oldtaku]

  You can follow the Amazon link and click on the book cover on the top left to get the excerpt for the correct book (once you scroll through all the intro crap).

• [Mark_Frauenfelder]

  Sorry about the wrong excerpt. I’ve fixed it. Here it is: http://d.pr/f/OpQa

• [LikesTurtles]

  Please tell me this isn’t yet another ‘pretend that software developers are by nature extroverts and those who aren’t can be forced to become one’ book.

  • [founddrama]

    @boingboing-8a936e001125f2c3d261ecb0e7ce378e:disqus - It isn’t like that at all. I just finished reading on Friday, and they acknowledge several times that many engineers are introverts and need the down-time. It reads more like a survival guide — how to interact with your team, and help make it a great team, while still acknowledging your introverted nature. And as an added bonus, they list Susan Cain’s “Quiet” in their “Essential Reading” list.

• [Charlie B]

  Most of the best software I’ve written has been solo.  Working with a team always involves compromising, which surprisingly often degrades quality, and working alone brings opportunities for elegance that are rarely available to teams.

  • [nfojunky]

    That’s what program managers are for. Today’s software is too large and too complex to be written by a single programmer. And that’s not to say that a solo coder couldn’t do it, it would just take too long.

• [Calvin Jae]

  I feel mixed about the excerpt. While it is useful advice for people aiming for a particular definition of success, on the other hand, both a) to argue for playing along with the system and b) presenting a plausible but unproven foundational model for values and behaviors come across as a little dogmatic and sloppy. I think what people really need in this day and age is something a little deeper, self-critical, philosophical, even and especially in the context of professional culture, because we all sense that there are systemic problems with society that need resolving.

  • [keighvin]

    Sorry, it looks like it turned my reply to your comment into a new comment instead – see contents below.

• [Daemonworks]

  “In a perfect world, software engineers who produce the best code are the most successful.”

  I wouldn’t want to work in an environment which rewarded people based solely on their ability to produce code (or anything else) and ignored little things like being able to get along with their co-workers.

  • [CH]

    Yea, not to mention that it might be the code of the gods, but still not do what the user needs it to to. I’ve seen way too many times where the coder decides that he/she knows best, and the program is a usability mess that nobody would want to work with… but as that is all they got…

    Working with the user to get out of them what the program needs to be able to do, and making a program that is actually usable by the user, is not an easy task. Coders need to eat humble pie and realize that all our “good ideas” might not be good ideas from the user’s point of view.

• [keighvin]

  To fill in the dogma with a good, rational foundation that’s less squishy, try “Tribal Leadership” and “How NASA Build Teams.”

  The social, soft side of things is an absolute necessity, and can be quanitified and managed objectively. Unfortunately, that means nothing if “the boss” is not also on board with the same concepts (which I saw as both a boss, and a recipient/victim of both good and bad bosses over the years myself).

• [Mitch_M]

  Does it address these important teamwork issues?
  - Turn the goddamned headphones down.
  - For heaven’s sake stop farting in the office.
  - If you take the last cup make a new pot. Well.

• [Zandy]

   I just added this book to my Amazon wish list & it has displayed as ‘Bestsellers in related categories’ “Fifty Shades of Grey”