We continue our journey of exploring gumption traps. In part one we talked about setbacks — external traps that cause our gumption, the relationship between the programmer and the code, to break down. In part two, we discussed hang-ups — external traps, and in detail considered a subset of them called value traps.
Today I would like to definitively wrap up our discussion of gumption traps by speaking of the last two types: truth traps and psychomotor traps. We’ll also wrap up with a description of the most destructive trap of them all, and one that is very difficult to get out of once you’re inside.
Truth traps
It’s difficult to come up with organised groups of examples of truth traps, because they all are fairly individualistic in how they come about. However, in general, truth traps pop up when you find yourself in an “invalid state”. You fall into a truth trap when your preconditions are such, that finding truth in your current situation is impossible.
This sounds quite cryptic, however in another post we discussed The Tomato Game. It describes one scenario of a truth trap: when you are asked a binary question to which neither “yes” nor “no” are adequate answers.
Zen and the Art of Motorcycle Maintenance approaches this concept in a different, orientally-flavoured way of the Japanese “mu” (which, in essence, is the same thing as the Central-European-flavoured tomato, except in a more sophisticated, Eastern philosophical veneer. We Poles tend to be more down-to-Earth.) “Mu” means “no thing”.
Knowing when you are in a “mu”-state is difficult to figure out, however there is one surefire way to both recognise you might be in one, as well as potentially avoid (inadvertently, always inadvertently!) putting your interlocutors in the same uncomfortable situation. It’s very simple, too: avoid “why” questions.
“Why”, as every eight-year-old with relatively strict upbringing knows, implies an accusation, and accusations are dangerous. “Why“‘s place is in a court of law, against someone who is defiantly hostile towards you. In a partnership, when both parties are trying to cooperate and work on a common goal, it is best avoided.
The nice thing about truth traps, though, is that once you recognise you are in one, you can get yourself out of it fairly easily, as long as you put yourself into a habit of having a paper trail.
I’m using the expression “paper trail” here as an inferior substitute of a Polish word that I’m not going to quote for reasons of decorum, however it loosely translates to “butt-cover”. The basic definition of that word is “evidence that supports you in case of a potential accusation”. Note the “potential”. Having a fallback will give you gumption and courage to pursue the path of quality, even if the accusation never comes.
An example that comes to mind immediately is when a client asks about a feature she did not request previously, or requested it in a different way. She might be upset that you did not implement it they way she wanted, but as long as you have a paper trail of her initial description, you can nip the accusation in the bud, oftentimes before it even comes.
It goes without saying that you must be careful and courteous when pointing out to someone else that he or she has put you into a “mu”-state. It’s not an occasion to grandstand — it’s a polite pointing out of a breakdown in communication, something that you both must work on, because you both failed to communicate. Neither party wants to find themselves in a “mu”-state. You failed to ask for the right things, she failed to tell you the things she wanted.
When you find that you are in a “mu”-state, rephrase the question, look for a way out. It’s probably not that far away.
Psychomotor traps
Psychomotor traps in programming aren’t quite the same as the ones in motorcycle maintenance, however, in general, they pertain to your tools and your environment. You can think of a psychomotor trap when you realise that, first of all, your process of programming is not comfortable or pleasant, or, more broadly, when you find yourself spending more time doing chores rather than solving problems.
When I am talking about “tools” and “environments” here, for once, I don’t mean libraries. I don’t even mean code - but rather your operating system, your text editor, your test runner, your source control, your continuous integration setup, your chair, your office lights. Everything that is not code but influences what you write.
I talked about this before, but I’m going to repeat it because it is very important: know your tools. More than that, use the best tools possible.
I think the best programmers underappreciate the impact of a good environment, mostly because they implicitly work towards reducing the unpleasantness. But when you’re just starting out, or you are already quite experienced but still feel that something is not quite right, you might be a victim of a psychomotor trap.
Unfortunately, unlike value traps, psychomotor traps are not at all easy to get out of because they mean you did not put in the work to learn the motor skills of programming. Touch typing seems like something obvious, until you pair program with someone who can’t touch type. Text manipulation at the speed of thought is natural if you’ve used Vim for three years, until you look at someone using VS Code and pressing the down arrow thirty times to go down thirty lines. I’m exaggerating here, but not by as much as you might think.
There are technical limitations, too. I once heard of a team who had their environment set up in virtual machines on computers across the world. They would log into the virtual machine in the morning, code for roughly eight hours with breaks for coffee, meetings and profuse complaining about the code quality, and then log out, presumably questioning their life choices. They managed to survive like that only for a couple of months. They quit, citing “poor code quality” and “difficult atmosphere”, but I guarantee that the clunkiness of the environment was at least what a scientist would call a “significant contributing factor”.
I faced a similar situation when first switching to macOS. The default choice of a terminal emulator on macOS is called iTerm2. A very feature-complete (or, depending on your point of view, “bloated”) application, it is used by nearly everyone in my company. However, working mostly in Vim with quite a few plugins, I found the terminal emulator to be slow. For me it was “very slow”: a few milliseconds of delay too much upon each keypress doesn’t seem like much, but it adds up when your normal typing speed is around 110 words per minute. Switching to Alacritty solved the issue, however it left me wondering how many people have these nigh-invisible gripes that are impeding their work, but are not nearly annoying enough to do anything about them.
Psychomotor traps is why I encourage every developer to at least attempt using Vim for an extended period of time. Initially, it’s slow, awfully so, but the modal style of editing allows you to jump around text files far faster than you would in your clunky IDE. And once you can edit text fast, you remove a psychomotor trap that incrementally will yield gains. Granted, you will not notice them until you sit down to code with someone who has yet to remove that trap.
You might have heard professionals say that typing speed is not important in programming, because coding is just a minor part of programming. While I generally agree (because I claim that as well), the reason why it’s not important for them (or us) is because they type fast enough or move around their IDE fast enough for it to not be an issue.
If you’re a good piano player, finding the keys on the keyboard allows you to focus on the broader picture of the piece you are playing, not figuring out where middle C is. For a professional pianist, finding the middle C is muscle memory.
If it’s not muscle memory for you, you’re in a psychomotor trap. Learn touch typing. Learn fast touch typing. Learn Vim (or learn to move around your IDE if Vim doesn’t cut it for your language (it rarely doesn’t)).
The worst trap
The final trap that I’d like to talk about is something Pirsig calls the “funeral procession”.
I watch the cars go by for a while on the highway. Something lonely about them. (…) Something about the car drivers too. (…) They all look like they’re in a funeral procession. (…) The driving is different too. The cars seem to be moving at a steady maximum speed for in-town driving, as though they want to get somewhere, as though what’s here right now is just something to get through. The drivers seem to be thinking about where they want to be rather than where they are. (…) Folks, I just forgot the biggest gumption trap of all. The funeral procession! The one everybody’s in, this hyped-up, f**k-you, supermodern, ego style of life that thinks it owns this country.
The emphasised sentence is key. There are many names for this feeling. Psychologists sometimes have to deal with a condition termed, rather more poetically, “destination addiction”. However, there is little place for poetry in modern corporate environment, so the funeral procession analogy seems to fit much better.
You are in a funeral procession when you have lost the feeling of purpose in what you’re doing. When you feel like the code you’re working on is not going to solve anything, or, worse, it’s going to do harm. When you long for some kind of improvement in the future but without hope of getting there. When the process of creation feels like going through the motions. Funeral procession poisons everything else you do.
And the worst part is that we are rarely able to do anything about it. Funeral procession happens when the ratio of agency and accountability tilts heavily towards the latter and away from the former. It’s a natural state of frustration for craftsman programmers — and something we’ve been able to avoid due to the organisational structure of “software houses”. Because a “software house”, really, is just a modern re-imagination of a medieval trade guild.
The structure of a guild — a loose association of craftsmen in a particular trade — stands in a very stark contrast to a modern corporation, which has different aims and different focuses. However, due to the very common business partnerships between software houses and corporations, the rigid hierarchy of the latter tends to bleed into the loose, quite informal, association of the former.
Conclusion
This wraps up our walk through the gumption traps in Zen and the Art of Motorcycle Maintenance. I hope this series brought you a bit closer to understanding how to persevere in the programming environment and excel in your craft.
