(^170) 97 Things Every Programmer Should Know
Two Heads Are
Often Better
Than One
Adrian Wible
PROGRAMMiNG REqUiRES DEEP THOUGHT, and deep thought requires soli-
tude. So goes the programmer stereotype.
This “lone wolf” approach to programming has been giving way to a more col-
laborative approach, which, I would argue, improves quality, productivity, and
job satisfaction for programmers. This approach has developers working more
closely with one another and also with nondevelopers—business and systems
analysts, quality assurance professionals, and users.
What does this mean for developers? Being the expert technologist is no longer
sufficient. You must become effective at working with others.
Collaboration is not about asking and answering questions or sitting in meet-
ings. It’s about rolling up your sleeves with someone else to jointly attack work.
I’m a big fan of pair programming. You might call this “extreme collaboration.”
As a developer, my skills grow when I pair. If I am weaker than my pairing
partner in the domain or technology, I clearly learn from his or her experience.
When I am stronger in some aspect, I learn more about what I know and don’t
know by having to explain myself. Invariably, we both bring something to the
table and learn from each other.
When pairing, we each bring our collective programming experiences—
domain as well as technical—to the problem at hand and can bring unique
insight and experience into writing software effectively and efficiently. Even
in cases of extreme imbalance in domain or technical knowledge, the more
experienced participant invariably learns something from the other—perhaps
a new keyboard shortcut, or exposure to a new tool or library. For the less-
experienced member of the pair, this is a great way to get up to speed.