Work Together
Explore key teamwork strategies for programmers including understanding personality types, dividing tasks based on strengths, using pair programming, and balancing focused work with collaboration. Learn to navigate interruptions and enhance team productivity while building your credibility on software projects.
We'll cover the following...
In most cases, we’ll be one programmer among several, and like rowing a boat, the sum of efforts depends on everyone rowing in the same direction. This is trite and easy to say. In practice, coordinating a programming effort is less like rowing a boat and more like herding cats.
Generally, good programmers are opinionated and strong-willed. If we ask any two programmers to solve a problem, they’ll solve it differently. Yet, the product depends on several (or many) programmers working together and creating a cohesive whole.
Divide and conquer
The average product requires many talents, and every programmer has unique skills, interests, and expertise. Understanding what you bring to the table is essential to contributing the most to the product.
When we’re just starting out, our industry programming experience is zilch, but we have enthusiasm. Let’s work with that. Is there a part of the product nobody else has experience in, either? This is usually in the messy parts; a common example is software packaging and field upgrade. It’s a hairy mess, and nobody wants to touch it. It sounds like a good place to dig in and earn our stripes.
Taking on critical problems is how we build our expertise and credibility within the team. Sticking with easy parts of the project doesn’t. (Balance this, however, with some early wins, as discussed in the lesson, Be Visible.
Look for credibility builders when the team is divvying up work; where is an unmet need that you can tackle? Consider the following group planning meeting:
Manager: Any volunteers for the 3D flying icon rendering tool?
Dave, Emma, Frank (in unison): Me.
Manager: Now, what about the part that imports 1986-vintage DXF files and convert them to our current format? (Crickets chirping)
You: If I take the lead on this one, can someone back me up if I get stuck?
Frank: I wrote some DXF stuff a long time ago, but I should be able to help.
You: Okay, I’ll take it.
Now you have a gnarly project and also saved others—who would have gotten the assignment otherwise—from a tough assignment.
Pair programming
Sometimes we set out to tackle a problem, and it tackles us instead. No worries, it happens to all of us. We can pair up with another programmer and try again. Often, a second set of eyes and a fresh perspective are all it takes to make the breakthrough we need.
Pair programming is effective enough that some teams always pair, one typing and the other observing and commenting. Other teams work individually and pair only when someone gets stuck. We can sometimes do a hybrid, with each person on a laptop in a common area, each attacking a different aspect of the problem.
If our team doesn’t have an established practice for pairing, it’s usually easy to get some time from a co-worker. Here are a couple of tips:
-
Try to find someone with experience in the area we’re working in. (“Frank, I heard you know a thing or two about DXF. Could you watch over my shoulder for a bit and advise me on this gnarly part of the DXF importer?”)
-
If we need more than a few hours of time, run it by the manager. (“Can I borrow some of Frank’s time? I’m in a tough spot and could use his help.”)
The only unacceptable practice is floundering on your own, not asking for help. Yes, some problems require tedious investigation that takes a long time. Recognize, however, when we’ve gone past the point of diminishing return, and it’s time to get another set of eyes on the problem.
Concentration and interruption
Collaboration necessarily involves both dividing works between individuals and working together. This is a fluid thing in most teams, with unpredictable mixing of alone time and collaborative time. It’s where those meet that can cause friction.
In programmer-speak, the “context switch overhead” required to flip between modes can be very high, depending on the person and the task at hand. Programming often requires intense concentration, and getting into that state—the flow or zone—takes time. This is why some companies give programmers offices to minimize interruptions.
On the other hand, the collaboration also requires interruption. This is why other companies put programmers in a large, open room to maximize collaboration. Both philosophies have worked for them, but we need to be conscious of the interplay between concentration and interruption to perform well in either environment. First, when another team member is working try not to bug them. Closed office doors or headphones are a good clue. When we need some in-the-zone time, turn off email, instant messaging, and cell phones. If our company culture allows it, work from home or a coffee shop.
Second, get used to interruptions. There’s tremendous value in collaboration, and shutting our office door shuts us out of the interactions going on around us. There are a number of productivity techniques we can use to minimize the impact of interruptions; Getting Things Done: The Art of Stress-Free Productivity by David Allen is an excellent place to start.