Heads is Often Better Than one

Heads is 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 have been giving a-to-a more col-laborative approach, which, I would argue, IM proves quality, productivity, and job satisfaction for programmers. This approach have developers working more closely with one another and also with nondevelopers-business and systems Analys TS, quality assurance professionals, and users.
What does this mean for developers? Being The Expert technologist is no longer sufficient. You must become effective for working with others.
Collaboration is isn't 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 he or her experience. When I am stronger in some aspect, I learn more about what I know and don ' t know by have to explain myself. Invariably, we both bring something to the table and learn from each of the other.
When pairing, we are 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 most experienced participant invariably learns so Mething 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 a-to-get up-to-speed.
?? Things every Programmer should Know
?
??????????????? Pair programming is popular with, though not exclusive to, proponents of agile software development. Some who object to pairing ask, "Why should I pay for the work of one?" My response is so, indeed, you should not. I argue that pairing increases quality, understanding of the domain and technology, and techniques (like IDE tricks), and mitigates the impact of lottery risk (one of the your expert developers wins the lottery and quits the next day).
What is the long-term value of learning a new keyboard shortcut? How does we measure the overall quality improvement to the product resulting from pairing? How does we measure the impact of your partner not letting you pursue a dead-end approach to solving a difficult problem? One study cites an increase of 40% in effectiveness and speed.* what is the value of mitigating your "lottery risk"? Most of these gains is difficult to measure.
Who should pair with whom? If you're new to the team, it's important to find a team member who's is knowledgeable. Just as important, find someone who has good interpersonal and coaching skills. If you don't have much domain experience, pair with a team member who's an expert in the domain.
If you is not a convinced, Experiment:collaborate with your colleagues. Pair on an interesting, gnarly problem. See how it feels. Try it a few times.

Heads is Often Better Than one