Last time we talked about the first type of gumption traps - setbacks. Setbacks are external issues that occur when the relationship between a craftsman and the material he is working with breaks down. Hang-ups are the internal ones.
Before we start listing the hang-ups, let me give you a tip that will avoid most or all of these. You see, when you sit down to work on a piece of code, or a lump of clay, or a motorbike, there will be things you don’t know. In fact, the very reason why you sat down in the first place is that you don’t know what’s wrong and how to fix it. There is a very small subset of bugs and tasks that you immediately know how to tackle - these are trivial and, if you do your job right, very rare.
It is important not to be discouraged by the lack of knowledge, but rather embrace it and start fishing for facts that will further your understanding of the problem. Once you learn one thing, others will timidly raise their heads and look around, as if waiting to be discovered.
With that knowledge in mind, let us begin investigating hang-ups, and more specifically a subset of them called “value traps”.
Value rigidity
The story of the South Indian Monkey Trap is probably one of my favourite engineering parables in existence.
Do you know how to catch a monkey? All you need is a hollowed out coconut affixed to a post. Fill the coconut with a little rice and leave a rectangular slot large enough for the monkey to put its hand inside but not large enough for it to retract its clenched fist. The trap works pretty much as you would expect - the monkey comes up and puts the hand in, grasping the rice in its clenched fist. And it realises it is trapped just as it tries to pull out the clenched fist with the rice.
The trap works because the monkey is caught in the other, invisible, trap of value rigidity. In other words, it is unable to reconsider the value of facts once new ones present itself. In this case, even after realising that it is unable to take out the rice, it still values it more than its own life.
As programmers, especially ones working with external clients, we have to understand that value is not rigid. The importance of various features or bugfixes changes depending on the circumstances. The importance of having 90%+ test coverage is diminished when there’s a critical bug discovered in production.
Remember that the code is not the most important thing in programming. In fact, code is probably one of the least important things in programming and as a general rule you want to write as little of it as possible. Consider your surroundings and the perspective of the people around you, the client, your teammates, and make the right choices on what to work on next.
As an aside, I find that the agile model already helps a lot with this, as it encourages decomposition and reduction of tasks into as small components as possible. When your units of work are very limited, it’s easy to evaluate them. And even if you focus on something that is not important in a given moment, the small size of tasks means that the cost of wrong evaluation is small and you’ll have the opportunity to adjust your thinking.
Ego
The gumption trap of ego is dangerous and quite often leads to value rigidity. The difference is while conventional value rigidity often deals with the material (code, clay, the motorcycle), ego is like the value rigidity of self.
If you have a high evaluation of yourself then your ability to recognize new facts is weakened. Your ego isolates you from the Quality reality. When the facts show that you’ve just goofed, you’re not as likely to admit it. When false information makes you look good, you’re likely to believe it.
The thing about code is that it has a way of revealing your actual nature. Most programmers I know are usually rather modest and quiet, especially when they’re working. Sometimes they are annoyed and tend to mumble or shout expletives, but I find they are less aimed at the code or the machine and more at themselves. The machine is a reflection of your own nature.
There’s no other way to approach programming than with modesty and if you are not naturally inclined towards that, it’s good to fake the modesty anyway. It’s easy to feign your way into looking good on a coding job, but that only works for people who don’t know what you’re doing. The clients will most often be such people - it’s imperative that you do everything to deflate that image.
Anxiety
The gumption trap of anxiety is kind of like the opposite of ego. You fall into it when you are sure of your own inadequacy and think that whatever you’ll do will go wrong. Very often it is this, rather than “laziness”, that causes you not to know where to start with a particularly difficult task.
The good thing is, programmers rarely work alone and the agile mindset already has tools that deal with anxiety. Pair programming is one of the best ways to do it.
It’s good to prepare before you start coding though. Poke around the module that you will most likely have to modify, read its tests and docs if they exist. Start fixing something small, maybe just the UI at first — because then you’ll start discovering the facts that will help you with the rest of the task.
And also, remember that everyone has these moments. Everyone messes up from time to time and everyone tends to find himself in a situation where he does not know what to do.
It’s important to not let that paralyse you.
Boredom
This one is tricky, because it often goes hand in hand with ego. How often are we bored when working on code? Sometimes a module that is not reusable or an unintended convention of copy-pasting code can lead to a task that in theory should take twenty minutes but actually in a messy codebase will be more like twenty hours.
Robert C. Martin in The Clean Coder pointed to a similar concept and he called it “focus-mana”. Focus-mana is a substance that affects alertness and attention. Coding consumes it, so do worries and distractions. Oftentimes situations which are not related to our work at all can reduce our focus-mana.
Take a few minutes to recharge. Look out the window. Go for a fifteen-minute walk. Go to the kitchen and make a cup of tea and talk to your colleagues. Sleep properly after work.
Once the focus-mana is gone, you can’t force the focus. Coding is a creative exercise, and while you can still do it when the mana is gone, most likely you will have to throw out everything you had done while not focused out of the window. When you’re bored, you stray off the path of quality, and that’s when the big mistakes happen.
It’s also worth noting that when you are bored, you are more susceptible to revelations — unrelated facts spontaneously “clicking” together in your head — and when you stimulate that with poking around the code without any particular goal, you might find solutions that you hadn’t considered previously.
Impatience
The final trap under consideration today, and the last of the value traps, is impatience. This is what happens when you greatly underestimate the amount of time something would take and you start rushing through the process in order to speed it up.
Impatience is extremely dangerous in programming, and given the prevalence of deadlines in this job and clients who oftentimes desire estimations made with certainty, it is very common that we fall into this trap.
The best rule of thumb that you can use when asked about estimates or any expectations about how long something would take is to refuse to put any concrete number on it when working with unfamiliar technology. Whenever you’re doing something that you haven’t done before, avoid giving concrete estimates because they will most often be wrong. Once you give an estimate, even if you explicitly state that it’s just a guess, you will in your mind be committed to it and will want to get your job done in time. You want to give yourself indefinite amount of time when working with unfamiliar technologies.
Another good way of dealing with impatience is to follow the best practices to the letter. If you do TDD, that’s when TDD shines. Scale down and be meticulous, that way you’ll avoid any big mistakes that will cause your gumption to leak out even more.
The Pragmatic Programmer lists many ways of working with incomplete information, especially when the client asks for estimates. But there is only one correct, bulletproof answer to all of those questions.
“I’ll have to get back to you on that.”
Conclusion
And so, as not to fall into the impatience trap that I have just described, I’m going to finish this essay here and ask you to join me next time for, hopefully, the last post in the series where we’ll describe the rest of the internal gumption traps.
