If you have gotten yourself into that correct mindset, read on, you lazy bastards.
The Virtue of the Good Programmer - Impatience
Why is impatience "good", while laziness is merely "adequate"? Because automating tasks is only the first step. Having your solution work is the minimum acceptable outcome. That makes you adequate. In order to ascend to the next level, in order to be considered "good", your code should not just work. |
| Work harder, slave! |
Impatience drives the programmer to further improve his work. The code does not merely run; it has to fly. It cannot only solve that problem; it must solve that problem in spectacular fashion. The impatient programmer always wants more out of his code. Impatience is what you have when you work tirelessly for several nights in a row just to shave off a few milliseconds from the execution time of your code. It's personified by the developer who relentlessly idiot-proofs his system so that all user input is validated and in some cases, even anticipated.
There's a great deal of irony in the fact that in order to exercise impatience where his work is concerned, the programmer has to very patiently improve on his solution.
How not to be Impatient
Testing the solution is often a very tedious process. In order to be done properly, multiple scenarios and edge cases have to be drawn up. Every moving part in the code is a new potential point of failure. Is it any wonder that some people make their living on testing alone? Because not every programmer can do it. Of course, there are those who are so impatient that testing is a waste of time for them. Take note; that is the wrong way to be impatient. In fact, that isn't even being impatient - just stupid.The wrong brand of impatience can also cause developers to cut corners during the development process - not in terms of quality, but in terms of communication. There have been times during my career where things were moving too slowly for my liking - I badgered colleagues for specifications, took things into my own hands and generally jumped the gun. This resulted in systems that sometimes did not function as expected, and sometimes deviated wildly from user expectation. My mistake was not taking the extra time to check with the users that I had understood their intentions correctly. This resulted in work they couldn't use, and a waste of company time. Sure, I leveled up in the process. Sure, I had fun doing it. But the company wasn't paying me to level up, or entertain myself on their time. It was paying me to get work done. And on that count, I failed. An employer once described me as a race car achieving great speed, but in the wrong direction. That wasn't a compliment.
It probably should also go without saying that the wrong brand of impatience can hurt a programmer who gives up too easily. Things rarely make sense right away, and if a problem isn't yielding a solution right away, approach from another angle. Time spent on understanding something is rarely time wasted.
No comments:
Post a Comment