The Right Little Thing

There’s a wonderful textbook on writing (and thinking) by Richard Mitchell called The Gift of Fire. In it, Mitchell says that teachers sometimes say “the right little thing.” This thing is a short saying that makes the students begin to think differently, that permits them to start to learn in a direction previously closed to them.

I have often noticed, in my own studying, that sometimes a quote from a book, or a lecture, or a blog, turns out to be such a “right little thing.” The whole course or whole book is worth it just because it contained this little, eye-opening quote.

So welcome to the new blog post category! I will share some of the right little things that have helped me learn.

Here is the first Right Little thing:

“The only way to go fast is to go well.” – Bob Martin

Robert “Uncle Bob” Martin, renowned for his advocacy of writing good code, and for some excellent books, gave a wonderful talk at hack.summit() this year. You can watch his talk here. Somewhere in the middle of it, he uttered those great words. “The only way to go fast is to go well.”

What does that mean?

Consider two developers. (Actually, both developers are me, on different days, but I have given myself pseudonyms to make the story funnier.)

Frantic Freddy: Frantic Freddy is really in a hurry. He was supposed to only take 4 hours to implement this feature, and he’s already spent 6. He knows there’s a bug, somewhere in the code that drives these three forms where people are paying for Widgets (also a pseudonym). He says to himself, “Die, bugs!” And just starts typing. Methods appear. Every ten minutes, he presses F5, which in his IDE rebuilds and launches the application. He then spends 3 or 4 minutes confirming that the bug in fact still exists. Stop the debugger. Back to editing. Type type type! And repeat. An hour later, there are probably now two or three bugs in the code.

Scrupulous Scandleigh, or “Scan” to his friends. (Note: This name is apparently “not widely used”). Scan is very careful. His favorite debugging tool is a pen and legal pad. When he knows there is a bug in some software, he writes down what methods the bug could be in. Then he writes down what arguments those methods are called with, and what he thought there return values would be. After 10 minutes of not typing, (or maybe 2 hours of not typing much), Scan has a very good idea about where the bug is. Actually, Scan has a testable hypothesis about where the bug is. He makes a tiny code change, like changing a less-than to a less-than-or-equal-to, rebuilds, and tests his hypothesis. He might accept the hypothesis, check in the code, and move on to the next bug. Or he might have to repeat the process. But because he only makes small code changes, and he knows what they all are, he won’t introduce new bugs. And because he only needs to test each hypothesis once, he is guaranteed to finish. (Scan would be even happier if everything were unit tested. Then he could write a failing unit tests that detects the bug, and proceed carefully until the test passed.)

So, to recast Uncle Bob’s quote in more immediate terms: Always be Scan. Or, rather, “acting like Frantic Freddy considered harmful.” (Update: Jeff Atwood rightly points out that using “considered harmful” in titles is unnecessarily provocative; I wanted you, dear reader, to be in on the joke, but please don’t use this phrase to go start flame wars.)

The problem is that there’s a constant temptation to be Freddy. His name is frankly less awkward, and he definitely makes more lines of code per hour, but also, he feels like he’s working faster. He types so many more things. He gets this emotional feedback like he is sprinting. But actually  Scan will finish sooner.

These are the reasons Scan will finish sooner:

  1. He only needs to test each hypothesis once, so there is very little duplication of testing efforts.
  2. His code changes are small, easy to undo, and well understood, so he will not make more bugs.
  3. When he is finished, Scan will have a clearer understanding of the codebase, while Freddy will have muddied the understanding of other people on his team, by typing too much.

That quote from Uncle Bob goes in the giant pile of “haste makes waste,” and “measure twice, cut once,” and “don’t move fast and break things” quotes that get repeated over and over again because we always need to be reminded of them, and because they are apparently true in a variety of professions. 

So why did this make, much less introduce, the Right Little Thing category? What new avenue of learning did this open up?

It opened up the “your behavior while you’re developing affects how well you develop” avenue. It started me thinking: being a good developer is not merely a set of knowledge (big O notation, quicksort being fast, what a hash table is), but also a set of behaviors (Not being Frantic Freddy, having good commit messages in source control, flossing). So I encourage you to pay attention not just to the knowledge that you need, but also to the behavior that you need.


Till next week, happy learning.



1 thought on “The Right Little Thing”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s