“Engineering is easy. People are hard.”
Life is full of unexpected twists, and the two of us never imagined we’d someday write a book about software engineering.
Like most computer geeks, we discovered that our hobby and passion—playing with computers—was a great way to make a living after graduating college. And like most hackers of our generation, we spent the mid-1990s building PCs out of spare parts, installing prerelease versions of Linux from piles of diskettes, and learning to administer Unix machines. We worked as sysadmins, and then at the dawn of the dot-com bubble, became programmers in smaller companies. After the bubble burst, we started working for surviving Silicon Valley companies (such as Apple) and later were hired by a startup (CollabNet) to work full time on designing and writing an open source version control application called Subversion.
But something unexpected happened between 2000 and 2005. While we were creating Subversion, our job responsibilities slowly changed. We weren’t just writing code all day in a vacuum; we were leading an open source project. This meant hanging in a chat room all day with a dozen other volunteer programmers and paying attention to what they were doing. It meant coordinating new features almost entirely through an email list. Along the way, we discovered that 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.
In 2005 we started Google’s Chicago engineering office and continued our careers as programmers. At this point we were already deeply involved with the open source world—not just Subversion, but the Apache Software Foundation (ASF) too. We ported Subversion to Google’s BigTable infrastructure and launched an open source project hosting service (similar to SourceForge) under the banner of Google Code. We began attending—then speaking at—developer-centric conferences such as OSCON, ApacheCon, PyCon, and eventually Google I/O. We discovered that by working in both corporations and open source projects we had accidentally picked up a trove of wisdom and anecdotes about how real software engineering teams work. What began as a series of humorous talks about dysfunctional development processes (“Subversion Worst Practices”) eventually turned into talks about protecting teams from jerks (“How Open Source Projects Survive Poisonous People”). Larger and larger crowds gathered at our presentations in what can only be described as “group therapy” for software developers. Everyone could relate to the sorts of problems we talked about and wanted to gripe about these problems as a group.
And so here we are, six years later, with a pile of standing-room-only talks about the social challenges of software development. Our editor at O’Reilly Media, Mary Treseler, pointed out that we should convert these talks into a new book. The rest is history.
This book is squarely written for software developers—for those who are trying to advance their careers and ship great software. It’s not particularly aimed at CEOs, psychologists, “management,” computer science theoreticians, or people soldering breadboards (though those folks may enjoy it too). As our reader, we’re assuming two important things about you:
You work on a team with other programmers. Either you work in a corporate environment, or perhaps you’re part of an open source or school project.
You enjoy software engineering and believe it should be a rewarding and fun activity. If you’re only turning 1s into 0s and 0s into 1s in order to pay off the debt collector, you probably aren’t interested in self-actualization or career fulfillment.
In the process of discussing how engineers best “play well with others,” we end up touching on a number of subjects that (superficially) may seem to be out of a programmer’s job description. At different points we discuss how to lead a team effectively, navigate an organization, and build a healthy relationship with the users of your software. On the surface these chapters may seem specifically directed toward “people managers” or “product managers”—but we assure you that at some point in your software engineering career you’ll find yourself accidentally wearing those hats. Suspend your disbelief and keep reading! Everything in this book is ultimately relevant to software engineers.
Before we start, we need to set your expectations. Motivated programmers love to read books that lay out domain-specific problems in a perfect mathematical presentation; each problem is typically paired with a prescribed procedural solution.
This is not such a book.
Our book specifically investigates the human side of software development, and humans are complex things. As we like to say in our talks, “People are basically a giant pile of intermittent bugs.” Both the problems and solutions we discuss are messy and difficult to place into perfect logical boxes. This book reads as a series of essays, because that’s what it essentially is. In each chapter we’ll discuss a slew of related problems (often as anecdotes), then move on to discuss a group of solutions relevant to the overall topic. To fully absorb everything you may need to lengthen your attention span to cover multiple pages, engage your right brain to make connections, or just plain sleep on it!
We should also make a couple more disclaimers. As we like to joke in our talks, “These opinions are purely our own and are based on our experiences. If you disagree, you’re welcome to get your own talk.” Just as with our oral presentations, we encourage any and all discussion that arises from the topics in this book. We’re happy to chat about feedback, corrections, new opinions, and disagreements: you can find us at http://www.benandfitz.com/. Everything in this book comes from our own trials by fire and the lessons that came out of our numerous mistakes.
You should also know that every name used in our examples has been changed to protect the innocent (or guilty).
Most of the software engineers we know have spent anywhere from four to 10 years in school learning about computer science and software engineering. At press time, we’re not aware of any curriculum that actually teaches you how to communicate and collaborate in a team or a company. Sure, most students are required to participate in a group project at some point in their academic career, but there’s a big difference between teaching someone how to successfully work with another person and throwing him into a situation of forced collaboration. Most students end up jaded by the experience.
Being a successful programmer isn’t just about learning the latest languages or writing the fastest code. Professional coders almost always work in teams, and it turns out that one’s team directly affects that individual’s productivity and happiness more than many people would like to admit.
The basic idea of this book is simple: writing software is a team sport, and we posit that the human factors involved have as much influence on the outcome as the technical factors. Even if they’ve spent decades learning the technical side of programming, most people haven’t really focused on the human component. Learning to collaborate is just as important to success. If you invest in the “soft skills” of software engineering, you can have a much greater impact for the same amount of effort.
 We’ve read PeopleWare by Tom DeMarco, and it’s a great book, but it’s not so much a book for engineers to learn how to work more efficiently with humans, as it is a book for managers to learn how to make teams more successful.