It’s time to abandon some old notions about programming.
For starters, advanced software cannot emerge from the mind of one programmer. There are simply too many pieces and too many needs that must be addressed. And that vision of the “lone coder” conjuring brilliance in a dark room? It simply doesn’t map to the realities of modern development. Programming is largely team-based — either in-person or virtual, official or ad hoc — and that means people need to communicate to get things done.
Brian Fitzpatrick (@therealfitz) and Ben Collins-Sussman (@sussman), authors of Team Geek and speakers at next week’s OSCON, discuss the intricacies of software collaboration and communication in the following interview. They also explain the difference between “leaders” and “managers” and they consider how the learn-to-code movement will shape future development teams.
In the introduction to the book, you note that a project’s success is equally dependent on writing great code and collaborating. When you initially arrived at that conclusion, what was your view on collaboration? Was that a pleasant realization?
Brian Fitzpatrick: It was something that we were doing, but not really giving a lot of thought to because it came naturally to us. We just saw collaboration merely as a part of getting things done. But when we started to think about it and discuss it, we realized that understanding how to work with people makes you a more efficient and more effective programmer. We understand that there are cases where you can brute force something through technical acumen alone, but there are many other situations where even that isn’t sufficient.
Think of collaboration skills as a lever — there are many occasions where you can lift something heavy by sheer strength, but if you use a lever and fulcrum, you can accomplish the same thing with considerably less effort. We see collaboration as another tool that’s as important as your compiler or text editor.
Are some of the communication issues developers face born from a history of “lone coders”?
Ben Collins-Sussman: We believe that the “history of lone coders” is really an elaborate mythology in our industry. Linus Torvalds didn’t write Linux — he wrote a prototype kernel and then spent the next 19 or 20 years coordinating volunteers to write the other 99% of the OS. Bill Gates wrote a BASIC interpreter for early home computers, but he didn’t create MS-DOS by himself; he coordinated a whole company to expand, sell, and support it. No matter how great your initial idea is, there isn’t a single piece of widely-used software out there that wasn’t created by a team of dozens (or hundreds) over many years. So, the upshot is that modern developers need to shake off the myth of the “lone genius” and embrace the maxim that software development is a team sport, and always has been.
Why is isolation harmful for developers?
Ben Collins-Sussman: Working in isolation is an extremely high-risk activity. In the early stages of a project, it’s really easy to go off the tracks without realizing it. A programmer would never write 10,000 lines of code and then hit the “compile” button for the first time; he or she writes a bit, compiles, writes a bit more, compiles. A software project has to develop the same way — in a tight feedback loop with trusted collaborators that are sanity-checking each step forward. People working in a cave almost always make a bad design choice early on and discover far too late that it’s unfixable. Or often, they just end up reinventing wheels without realizing it.
In your view — and this is generalizing, I know — how do programmers perceive non-programmers?
Brian Fitzpatrick: Many programmers perceive non-programmer jobs as easy or trivial because they don’t require deep technical knowledge to perform. This is often exacerbated when they meet non-programmers who aren’t very good at their jobs, are overconfident, or just plain treat programmers poorly. The most common example of this is the “crappy salesperson,” and many programmers base their opinions of non-technical people off of these encounters. Beyond that, many programmers look at these roles and think “anyone can do that; that’s easy” because on the surface, no “hard” technical skill is required as part of the job. The truth is often that not only is there a lot of skill and effort required to do these jobs well, but that many programmers can’t do these jobs well — or in many cases, at all!
We’ve been fortunate in our careers (and especially at Google) to work with some of the most amazing, brilliant, skilled and friendly non-technical people. When you’re surrounded by amazing salespeople, lawyers, PR folks, and managers, it’s hard for even the most jaded programmer to continue thinking that these non-technical jobs don’t require skill or effort.
Can the communication techniques used within a group of developers also be applied to colleagues outside of that group?
Ben Collins-Sussman: In our book, we talk about effective tools for communication within a programming team. Some of these tools are specific to software engineering — such as how to effectively use chat rooms, bug trackers, write documentation, etc. But many of our recommendations are useful for communicating “outward” from the team. We talk about how to run effective meetings, gain agreement on project goals, how to structure emails to get exactly what you need from VPs. Collaboration is a skill that needs to be actively practiced at all levels.
Even if someone doesn’t aspire to a management position, they’re likely to move into a leadership role if they hang around long enough. How should these reluctant leaders handle this situation?
Ben Collins-Sussman: This is a common scenario we refer to as the “accidental manager.” Some people are naturally charismatic and end up leading a group unintentionally (often pulled in by a power vacuum). The most important thing to do is not panic. “Manager” has become a dirty word among programmers. We instead advocate leadership — and by “leader,” we mean someone who clears roadblocks for the team. A manager tries to tell a team how to do its job, which is almost always a bad idea, while a leader worries about what the team is working on and how easy it is for the members to be productive and happy. Be a leader, not a manager.
There’s a movement to introduce coding to more people. How will this shape development teams down the road? Will diversity naturally improve communication?
Brian Fitzpatrick: I think it will if both technical and non-technical people are open-minded about it. In my experience, learning more about another job often leaves me with a lot more respect for the skill and effort involved in doing that job well. Having spent the last four years restoring my 100-year-old house, I’ve tried my hand at a lot of do-it-yourself projects as well as hired people to do even more projects. The one universal truth that I’ve found is that after spending a few days doing something myself (whether it’s painting, wood-stripping, drywall, or carpentry), I have a much greater respect for the work that the pros do because I begin to understand that there are many techniques and nuances that make it “look easy” to people who don’t do that line of work.
I’d like to see a movement to introduce non-technical jobs (e.g. legal, sales, communications) to more technical people as a means to give them a greater understanding of just how hard it is to do those jobs well.
This interview was edited and condensed. Associated photo on home and category pages: Big red lever by moonlightbulb, on Flickr
Team Geek: A Software Developer’s Guide to Working Well with Others — 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.Related: