Tools we use matter! If you ever had to cut down a tree, you may have noticed how much easier the task is if you have a sharp axe. It's just the same with other tools.
This advice seems pretty solid. If you ever had to cut down a tree, you may have noticed how much easier the task is if you have a sharp axe. But this is not an article about chucking wood. You may ask what the connection with programming is. To explain that, I’ll start with a story:
A man, let’s call him Jim, walked through a forest one morning. The sound of an axe reached his ears, and soon he found a lumberjack. The lumberjack was cutting down a tree with an obviously blunt axe. Jim watched him for a while and then asked him: “Why don’t you sharpen that axe?”
“I can’t!” the lumberjack snapped without taking his eyes off the tree. “The village is over an hour away, and I need to cut this tree down as soon as possible. I don’t have time to travel to the village and back for hours and then spend another hour at home. I must cut this tree quickly!”
Jim didn’t question the lumberjack. He just wished him good luck and then continued on his journey. In the evening as he was walking back through the same forest, the same sound reached his ears. Curious, he followed the sound, until he found the lumberjack he met in the morning. The tree was cut hardly halfway through. The lumberjack still continued cutting the huge trunk with the blunt axe.
The moral of this story is obvious. If the lumberjack spent those three or four hours travelling into the village and sharpening the axe, he would have cut the tree in the next two hours. This way, however, he spent twice as much time without getting half the work done.
This became my mantra: “Don’t use a blunt axe. Sharpen it.” What does it mean to a programmer? That depends on the job they have to do, but the basic rule is: prepare tools that will make you work faster and better. Sounds simple until one realises that there is no simple solution. What tools fall under this rule?
The first category is anything that is automating manual processes. The human brain is really bad in repetition of steps. We’re not like computers. We quickly make mistakes, because our minds start to wander. So replace anything repetitive with an automated process. The only trouble with this rule is figuring out when the task is repetitive enough to be automated. If you need to check seven users, it’s easier to make this manually. With seven hundred, you need an automated process. But what number is the reason to automate? Eight? One hundred? Five hundred? Sometimes even those seven would be easier if the first one was part of a creation of an automated process. There is no rule here; you just have to follow your gut feeling. The more times you go through these processes, the easier it becomes to figure out when and how to automate.
The second category contains anything that is error sensitive: tasks where errors can cause too much trouble, which is basically anything that you or your superiors consider serious. This though can differ in various companies. A two hour outage of an intranet of a company selling kitchens is no big deal (though it’s annoying), because they can enter the data two hours later. On the other hand, with an online game, such as we create at Pixel Federation, a two hour outage is a huge problem. Missing a deadline by two days when releasing a new feature into a game is no big deal. Missing a deadline by two days when creating a system for sending tax forms is a serious problem (you really don’t want to pay late fees for your tax returns). There are many tools that help you to find and eliminate errors quickly. Pair programming, code reviews, code inspections, or automated tests are just a few.
The third category is about productivity. This one is simple: we should use tools to improve our productivity. If the tools require more work for their operation than they provide advantages, we are no longer productive. But though many tools first require a set up that is difficult and time consuming, the productivity improves significantly afterwards. To figure out if the tool is helpful, you need to look at more parameters at once. The number of words that you can write is not the only thing that determines your productivity. If you have to rewrite the code a hundred times, it doesn’t matter that you wrote it in two hours instead of four. There are many editors out there that allow you to find parts of the code quickly, that inform you if parsing is incorrect, and many other useful things. Many contain additional tools that fall into the first and second categories. Don’t try to learn to work in seven different editors, master the one you’re using the most.
The fourth and last category contains everything that feels like it could be improved. We can do everything better. The level of quality may differ significantly, but no one can write a code that can’t be improved. Why? Because we’re humans. The improvement we’re talking here can be significant, but more often than not it’s just a tiny improvement. Look at your current workflow, at your current tools, and ask yourself: what can I improve? Can I use different text colouring? Can I install a tool that finds typos immediately? Can I turn on switching between database mapping and entity classes? Even a slight improvement can deliver huge results in the long run. Don’t underestimate the effectiveness of improvement.
So remember. Using tools is necessary for your work. Being a programmer is not only about writing code. It contains so much more. Tools help us to be the best we can be. Use them wisely. Don’t be like the lumberjack.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
