The programming world heralds laziness as one of the virtues of a programmer.
Larry Wall, the creator of Perl, says – Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.
What no one tells you is that this laziness does not come for free; one has to work hard to imbibe this trait.
In practical terms, what does being lazy translate to?
- Doing as little as possible, never more than needed.
- Instead of doing things yourself, delegating to well-established tools, libraries, and frameworks.
Let us work with some concrete examples.
You want to parse a CSV file.
You think: let me load the file, parse it line by line, and split each line on a comma. You roll up your sleeves and code this. You feel smug having solved the problem yourself without anyone’s help.
Trouble starts when the CSV you parse has a header. Now you add an if condition to detect the first line. Later, someone uploads a CSV separated by a tab instead of a comma. You add another if condition to accommodate this. Another person uploads a CSV which has quoted fields. You start doubting yourself and ask how many such “unknown unknows” are there when it comes to parsing a CSV?
Unknown unknowns are risks that come from situations that are so unexpected that they would not be considered.
CSV parsing might have a lot of “unknown unknowns” for you – a person who is not well versed with the intricacies of CSV format. But there are experts out there who know the CSV format and have written libraries to handle all the edge cases and surprises that it might throw. You hedge your “unknown unknown” risk by delegating the CSV parsing to one of these libraries.
In short, be lazy, do as little as possible, and delegate to well-established libraries.
“Fools say that they learn by experience. I prefer to profit by others experience.”
― Otto von Bismarck
Let us consider another scenario.
You want to store a counter in a database. One approach is: when you want to increment the count, you get the current count from the database, add one to it and store the new count back in the database.
Do you see the problem with this approach?
What if many threads are doing this in parallel? You will end up with a wrong count. A better approach is to delegate the task of incrementing the count to the database by leveraging SQL’s arithmetic operators. This approach makes the counter increment atomic. Many threads trying to increment the count is no longer a concern.
By doing less yourself and delegating the task of incrementing the counter to the database, you have saved yourself from bugs.
Why is this hard work?
This sort of thinking does not come easy; you have to work hard to identify where what and to whom you can delegate the work.
Dunning-Kruger effect might have a role to play in this. We believe we are the experts and best suited to do things.
In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people assess their cognitive ability as greater than it is. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability.
While coding, most of the time, you are solving a problem that someone else has already solved, probably in a different context. Be aware of your biases and always question: Is this something I have to code myself, or can I offload this to an already written, well established and well-tested library or framework?
“Learn from the mistakes of others. You can’t live long enough to make them all yourself.”
― Eleanor Roosevelt
Follow @abhyrama
Image by Clker-Free-Vector-Images from Pixabay
Abhirama's Blog 