A lever is always better than a lone coder

Team Geek authors Brian Fitzpatrick and Ben Collins-Sussman on coding myths and collaboration.

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 FitzpatrickBrian 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-SussmanBen 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:

tags: , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • NNM

    I’m so offended I don’t know how to express it without cursing.
    “advanced software cannot emerge from the mind of one programmer”

    I have developed, alone, a whole range of webapps that are being used by thousands, daily. Some of these manage values of billions.

    Alone. Advanced. Works. Users happy.
    Alone. Advanced. ONE MIND.

    Bring more coders? No way. They are gonna mess it up. Go away, let me code.
    The databases are HUGE.
    Alone. Advanced.
    AND…
    Much better than the competition. MUCH… BETTER. Also cheaper, because it only took ONE coder.
    GOAL: no bugs. Achieved. X BRowser: achieved. User friendly: achieved.

    Bloggers and wannabe team managers, blinded by the mainstream words such as “agile”.
    My software beats yours, in quality, speed, flexibility. I don’t need to wait for anyone for changes. One user suggestion usually results in a visible, working, change within an hour. Can a team do that?

    • Sparkkkey

      Completely agree.

      I meet with the users. I develop specs and prototypes. I code the app from beginning to end. It is what an experienced programmer can do.

      No one needs to hold my hand.

      Some people can deliver an entire product. Only about 5% of the software developers that I know can achieve this, but they are all very successful.

      The end product has fewer bugs and has no compromise in design.

    • https://launchpad.net/~kjcole Kevin Cole

      Um. NNM… I think there’s a typo in your message… s/BRowser/Browser/

  • http://radar.oreilly.com/mslocum Mac Slocum

    @NNM: Just want to clarify that the line you have a problem with is mine. Brian and Ben did not say that, specifically. That’s my conclusion.

  • http://petdance.com/ Andy Lester

    One user suggestion usually results in a visible, working, change within an hour. Can a team do that?

    Yes. Not only that, but a team can do that when one of its members is on vacation. A single programmer can’t. Truck-sensitivity is a big deal.

    NNM’s conclusions are based on the premise that he/she is the single best programmer there is, with superhuman powers and code that cannot fail, and that could not possibly be improved by input from others. That may be the case for the company fortunate enough to hire NMM, but the rest of us out here deal with mortal programmers, who make mistakes, who produce better work when we work together with others.

  • zwetan

    @NNM: I’m also offended, but by your stupidity.

    here the list:
    – your claim of no bugs achieved is hilarious as this does not exists in real life
    – thinking that only you can program and other gonna mess it up is insulting every other dev
    – cheaper because only one coder is false, you should documente yourself about Total Cost of Ownership
    – “my software beat yours” are we 13yo playing in a sandbox ?

    now I think ultimately you misunderstood the original quote, it is about “advanced software”,
    wich you think you are doing and I’m betting you’re far from it

    seriously, not a single bug ? arf please come back on planet earth

  • Tony Taylor

    Personally, I think this article is amazing. I have been developing database applications since ’99 and I cannot tell how many times I have been discussing projects with others and someone makes a simple comment about, “Why don’t you just….” and I look at them dumbfounded.

    I view working with others as so much more beneficial than working with others. Sharing knowledge and ideas can expedite a great end product.

    The best section? Ben Collins-Sussman’s reply to the question, “Why is isolation harmful for developers?” I would say I just have one thing in which that I would disagree.

    “A programmer would never write 10,000 lines of code and then hit the “compile” button for the first time…”

    I think it should read “A GOOD programmer…” (emphasis mine).

    I have come behind enough developers that I would have to make that clarification.

    Cheers!

  • https://launchpad.net/~kjcole Kevin Cole

    Sometimes programmers work for companies… Sometimes companies only hire one programmer… Sometimes that one programmer has very little control over management’s hiring practices… (That said, I do ask a LOT of questions on mailing lists and forums.)