A Quick Look At Programmer Productivity Pitfalls

Feb 23, 2016 Tools

I tweeted a couple of things within a few hours of each other this past weekend. It wasn't until Monday morning that I realized how connected they are:

Play the animation. At first glance, it seems like utter chaos doesn't it?

But in fact it is controlled - every part interacts with every other part, and that is where the comparison to object oriented programming comes from.

Spend a few minutes watching it. See if you can get a handle on how all the actions affect each other.

If you had to make a change to any one part of the sequence, do you know how it would impact the animation as a whole?

What if every third figure coming out of the castle on the upper right had to be blue instead of yellow? It seems like a small change, but how would it affect the rest of the sequence? Does this change touch only a small part of the animation? Where would its impact be felt? Those little figures all persist into the rest of the animation. Some are carried away and dropped back into the castle tower, some cross the river and walk back into the castle, some head off-screen (and probably come back in at another side).

You almost need to memorize the entire sequence as you're making your small change, to keep tabs on the impact you're going to have as you switch animated people from yellow to blue.

Let's say you've been watching the animation for a while, and you've got a pretty good idea of what's happening. Maybe you could even describe it in detail if you watched a little longer and took a few notes.

What if someone were to walk in right now and ask you a question? What if you had to get on a phone call and were forced to focus on something else for five minutes? How much of the precise sequence of events in this animation would you remember when you came back? How long do you think it would take you to watch the animation and get familiar with its actions again?

That's analagous to the experience of working on object-oriented software. A programmer must be mindful of the impact of their code changes as they're working, and that often means remembering a complex set of interactions, carrying those interactions around in their head until the work is done.

This illustrates why even small interruptions can be a disaster to a developer. A clear calendar is a programmer's best friend, and day strewn with meetings an hour apart can guarantee that nothing useful will be accomplished in between (what's the point of immersing yourself in a program when the next interruption is just around the corner?). Schedule your standups for early in the morning or late in the day, keep all of your agile planning to one day of the week, and use email instead of IMs whenever you can. Your team will thank you.