An engineer relies on his best tools to carry out tasks which are repetitive, error-prone, or time consuming. For a software engineer, an advanced language tool can improve his life. One of the immediate impacts of using the right tool is the reduced amount of mistakes.
The following picture is something I have shown to some people, including when I did my EmpireJS talk some weeks ago. It looks rather cryptic and I think my 30-second explanation never conveyed the real message of the diagram. Hopefully the following description is easier to understand.
The charts basically show the contour lines of the mistake probability as a function of application complexity (vertical axis) and developer skill (horizontal axis). The zone where the mistakes are less produced is where the happy cat is located. The opposite of this is obviously the disaster area where there is nothing but mistake, one after another. When a tool is used to reduced coding mistakes, the contour map is transformed from the left chart to become something like in the right side. In other words, the tool is successful if it enlarges the area where mistakes are low.
We can imagine a situation where a genius programmer, perhaps also a coding ninja, does not really need an advanced tooling to build an application. Yet, as the complexity of his application increases, he will become more and more vulnerable to mistakes. There is a physical limitation of human brain, at one point something will crack. I don’t know about you but I have witnessed seasoned developers making stupid little mistakes, sometimes when using their own framework (ironic, isn’t it?). Heck, even a chess champion may enjoy a serious blunder from time to time.
Granted, when the developer is not as skilled, he is at a disadvantage compared to his ninja-grade coworker. Even if the application does not really get too complicated, he will be exposed to various traps, the ones which someone usually manage to avoid based on the past experiences. For a really really newbie, the collection of rookie’s mistakes is waiting patiently in that dark corner, ready to jump at any moment of weakness. For this group of developers, a proper development tool is very valuable so that their destiny becomes something like the one depicted in the right contour map. Mistakes might still happen, but the overall situation is not as bad as in the left chart.
The fact that a tool might improve the development workflow is often forgotten if one sees it only from a one-dimensional point of view. For example, a veteran hacker can have a knee-jerk reaction “I don’t need a stinking IDE, I live and die with my Vim” because he projects the value of such an IDE in his own skill axis. Even then, if we enlarge that particular skill corner, people with different Vim skill can use a variety of scripts to improve their life. For example, plain vanilla Vim is useful yet many developers become more productive with additional time-saving functionalities, anything from a fast file navigation to an easy-to-use syntax validator. The same goes for the common phenomena when a new stuff is announced (whether it is a programming language or a development paradigm): a lot of snarky comments. While some of the them are just random short-term poking fun or a show of passionate analysis, a few other opinions are dangerously in the border between militant and passive-aggresive.
The key is here is simple, let us think about other people. Take a look at JavaScript, an expressive language which is easy to learn. Nothing is more rewarding than making a little JavaScript application which does a simple task. Yet, there are gotchas and latent pitfalls in many places. We may not be able to help those who do not posses basic computer science skills, but there are many programmers out there who are capable enough to carry out complex web development even though they don’t have rockstar-esque expertise. This is of course not a question of intelligence (again, another overrated one-dimensional axis). Your mentor at the local chess club isn’t always a grandmaster and your physics professor didn’t always have his internship at CERN. Not everyone has a photographic memory and remembers everything from the 258-page ECMAScript 5.1 specification.
Next time someone steps up and promotes a way to improve someone’s coding quality, think about the beyond-the-horizon implication. Like Jason Fried once wrote, give it five minutes, because the right idea could start out life as the wrong idea.