Learning Hack: Use Your Down Time

As it turns out, human beings cannot concentrate constantly on writing code. Sometimes we need a break. In this week’s post, I’m going to suggest a few ways that you can use your down time somewhat productively.

Suggestion 1: Podcasts

Stuck on a train? Have a long commute? Going for a long walk? I really suggest listening to podcasts about computer programming. Now, podcasts are not a great way to learn specific syntax or algorithms or anything. If someone started reading code out loud on the radio, they probably wouldn’t have a very big following, and their listeners would have car wrecks trying to remember how deep the curly braces were nested. But, podcasts are awesome for a few things.

Continue reading “Learning Hack: Use Your Down Time”

Explaining Names

I’m adding a new section to the blog. It’s called “Explaining Names.” In it I explain names.

Why bother explaining names? I explain names because names are rarely accidents. The name of a thing is what it’s discoverer, or author, or publicist or whoever thought would be a good way for everyone in the world to remember the thing. When we explain names, we guess what this originator of the name was thinking, which, because the originator of the name presumably understood what he or she was naming, tells us a lot about the thing.

Continue reading “Explaining Names”

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

Continue reading “The Right Little Thing”

Learning Hack: Recognize and Interrupt Wheel Spinning

When  I first started at my current job, I lost a lot of time spinning my wheels.

(image source)

Spinning wheels, in the literal, automobile-stuck-in-mud usage, has two characteristics: The wheels are spinning, and the car is not moving. For programming, this means frantic action, but without forward progress.

Here’s an example of wheel spinning: Method A in project B threw an exception. That’s probably because it called Method B, which got some data from a database, and that data was weird. Was the data weird, or is Method B wrong? What about Method A? Maybe Method A is broken, and the data was right? Is one of the more senior developers busy? Maybe if I step through Method A six more times, I can just figure it out? (For best effect, please read this paragraph aloud four times without inhaling.)

Here are the symptoms of wheel spinning for programmers. You are stuck in a loop where:

  1. There are multiple causes to a problem, or multiple related problems.
  2. You have considered each of these problems more than once.
  3. Your last time through this loop, you did not either decompose the one of the possible causes, prove that one of the possible causes was irrelevant, or find someone to ask. 

And here’s why you’re spinning your wheels: If you consider the same problems, without decomposing, eliminating, or asking about them, you will be stuck in this loop forever, because you will always have the same amount of information about the same set of problems. When you are here, the only wrong answer is to stay stuck in the loop. 

Instead, you have to make some progress. Pick one possible cause, and temporarily ignoring the others, either:

  1. Figure out that it is composed of other possible causes, and recur OR
  2. Prove that your problem still exists in its absence, so you can stop looking at it OR
  3. Decide that you need to ask someone about it.

“Obviously,” you might object, “but you just told me to break out of the loop by breaking out of the loop. What do I do?”

Here are some specific things that work for me:

Heuristic approach: the most recently changed, most specific code is probably the problem. My first week at the new job, I was stepping through some method, and a security exception was thrown in the middle of our most general purpose, most widely used library. Did I find a bug in the database access code that a bunch of client projects depend on? Of course not. If that code were broken, everything would be broken. Instead of suspecting old, reliable code of suddenly failing, I should look up the call stack for the most specific or most recently changed code, and start there. (Or maybe, you know, check the credentials. It was a security exception, after all.)

Algorithmic approach: make a “what else must be true” graph. I list the possible causes on a piece of paper, choose one, and start finding facts that it would imply if true. “If Method C retrieves the wrong data, either the query it executes is wrong or the data itself is wrong.” This procedure makes a tree where the root is the original problem, the inner nodes are hypotheses about its cause, and the leaves are things I should test. After making the graph, I look at each leaf. If I can determine its truth value on my own, I do so and update the graph. If not, I mark it as something to ask about and continue processing the other leaves. At the end, I have either solved the problem on my own, or proved to my own satisfaction that I need to ask for help.

Surrealistic approach: try “rubber duck debugging.” Put a rubber duck on your desk. Explain the code to the duck as through to a child or a person completely unfamiliar with your technology; justify every line of code. Rubber duck optional. (I believe this technique comes from The Pragmatic Programmer: From Journeyman to Master.)

I hope this post gave you a push out of the mud. Till next week, happy learning!