The Compulsive Coder, Episode 4: You Create, It Assigns

roomba long exposure
Image courtesy Chris Bartle. License.

Some languages are destined to be always overly verbose. One feature I’d hoped for in later versions of Java was implicit typing. In C#, for example, you can declare:

var customer = new Customer("Jose Cañusi");

It’s not too hard for the compiler to figure out that customer is of type Customer.

Java still has no implicit typing. Any time you need a non-specific Customer instance, you need the following code:

Customer customer = new Customer("Elmer Sklue");

I’m out of breath doing all that typing! Well, not really: I didn’t do all that typing. But I’ve suppressed a scream too often pairing with folks who do type the word customer three different times.

We have computers to compute for us. Never mind that the Java language is a cranky old uncle, you at least have a Generation Z development environment if you’re using Eclipse or IDEA.

I’m pretty sure I first saw J.B. Rainsberger demonstrating the following tip at least a dozen years ago.

Type the instantiation (right-hand) side of things first:

new Customer("Anne Teak");

Do not type the left-hand side! Instead, press Cmd-1 (Quick Fix; the corresponding keystroke is Alt-Enter in IDEA). Select Assign statement to new local variable and press enter. If you’re young enough to store away another shortcut, use the slightly more effective Cmd-2-L key combination instead.

Unnecessary typing represents distraction, waste, and risk.

Previous Compulsive Coder blog entry: Typing Isn’t the Bottleneck
Next Compulsive Coder blog entry: Extract Method Flow

Pairing Hell

pair hell
Image courtesy Chris Martin; altered from original. License.

“Pairing is hell. Okay, it’s also fun. But it’s also hell.” —Alex Harms, on pair programming.
Over fifteen years of pairing, and I too am similarly ambivalent about it. Don’t think I’m making a case for not pairing, however. I’ve written numerous times in support of pairing:

At least 16 more blog entries on this site discuss pairing, as do many at the Agile in a Flash blog.

So “hell,” really? Seems strong. Let me explain what I find to be a few serious problems with pairing cultures that can make it hell.


As an introvert, I have a limit on the number of hours I can interact with people before I need to recharge (i.e. on my own). I regularly stretch this amount, which is ok. It doesn’t mean I’m not enjoying the interaction–particularly if it’s going well. It is heavily draining, however, which demands more recharging.

Pair programming was never meant to be the only thing you do all day. And yet I’ve done regular stints of 9-10 hour pairing days (at HEB in San Antonio for 7 months), or 7-8 hour days (remote at Outpace for the past few years). Trust me, those aren’t 100% fun hours for an introvert, no matter how well it’s going.

Sensible pairing shops set a limit on pairing. Six hours is plenty: three hours in the morning, three in the afternoon, a break in each. One shop I’ve helped mandates such a schedule to positive effect–no one feels pressured to stretch beyond reasonable amounts.


Some people either never learned to play well with others or are incapable of it (i.e. it’s not their fault). Still, I believe most individuals are capable of learning how to interact effectively as a pair.

Having said that… there are definitely a (very small) number of pair-holes: people who should just not pair. Ever. Again. And I hope to never have to pair with these folks again. Fortunately for them and me, plenty of shops don’t mandate pairing, and shops that pair usually have other non-pairing things to do.

What makes a pair-hole? Mostly it’s someone who’s “always right,” or worse, someone who wants to argue (and not code) just for the sake of arguing. A keyboard dominator can sometimes be a pair-hole.

Many bad pair habits (inattentiveness, timidness, loud, etc.) can be corrected or overcome. A pair-hole is someone who doesn’t care enough to do so.

I’m not talking about people who want to think through problems on their own instead of with a pair. I think just about everyone feels that way some of the time, including me. I find that exploring things on my own is necessary as a regular thing. I find time regularly to do so–that’s one reason I seek slightly less than a full day’s pairing.

Poor Practice

Other than pairing too long, I’m mostly talking about pair marriages. We promote pair switching to increase coverage on everything. A pair can go down a rathole, just like a solo dev can. I suggest all shops incorporate a rule that says “at least 3 sets of eyes review every story,” whether through pairing or some other mechanism.

That’s the practical concern regarding pair marriage. The painful part: Being stuck with the same person day after day–or even all day long–can be a big pairing turn-off, like long walks down the beach can be (because you know you have to walk back). Switching at lunchtime can work well.

Pairing is a Tool

Pairing can be a highly entertaining, effective tool. For me, it’s often joyful. But it can at times be painful. The more you understand the extreme feelings and concerns people have with respect to pairing, the more you’ll learn how and when to effectively employ the tool.

If you’re not actively coaching your pairing and not continually adjusting your pairing practice (perhaps as a result of retrospectives), chances are good that you have the above dysfunctions.

The Compulsive Coder, Episode 3: Typing Isn’t the Bottleneck

As Mike Hill says, “the hard part of programming is the thinking,” and not the typing. And yet in this Compulsive Coder blog series, I’m focusing on the very little things, things that might save you as few as milliseconds in some cases:

  • Auto-generated comments that you can simply delete in a quarter second.
  • A color scheme that might trigger slightly faster recognition about something important.
  • And in this post, I’ll implore you to delete lines (like those auto-generated comments) in one keystroke instead of three.

Is all this a waste of time? Shouldn’t we be focusing on bigger, headier things that *are* the bottleneck–such as ways to ensure your code stays clean, so that you don’t waste monstrous amounts of time on code comprehension? Sub-optimization goes against the lean software edict to “optimize the whole.” Why bother?

I’ll offer a few reasons:

  • Less typing ==> fewer opportunities to screw up. Let the computer do the work, it’s rarely wrong! Jeff Bay, via Twitter: “fixing obscure bugs because of obscure f-ing types is a major bottleneck.
  • Wasted time adds up. A mere hundred unnecessary movements across the course of a day add up to half a million across a twenty-year career.
  • RSIs are real, and unnecessary movements similarly add up.
  • Moments you spend on mechanical operations–hunting and clicking, or sequencing together operations–are things that distract from your thought process.

To me, it’s about having the craftsman mentality of caring, more than anything. A craftsman is always seeking better individual approaches to building software. They seek to optimize frequent operations by minimizing the waste involved. They don’t tolerate regular inefficiency.

So, my nit. Real small, real short.

We delete lines often enough in programming. I watch some programmers do so by first navigating to the beginning of the line (if needed), highlighting the text to the end of the line, and then cutting the text (Cmd-X, e.g.). Ridiculous.

In Eclipse, it’s simply Cmd-d (by default). In IDEA, it’s Cmd-Delete. If you have Vrapper (a VIM plugin), it’s dd. One operation, not three.

Previous Compulsive Coder blog entry: Syntax Coloring
Next Compulsive Coder blog entry: You Create, It Assigns