The Three ‘Virtues’ of Programming
Coding culture is a curious thing. There is seldom a thing within our subculture that every developer agrees upon.
Here are some contradictions:
Some say coders should be lazy and some say the opposite.
Some say that coding makes the world a better place.
A few developers think stealing code is perfectly acceptable.
Yet when one of the grandparents of coding speaks, oftentimes people sit up and listen (unless it is obvious nonsense).
Today I found out that Larry Wall claimed back in 1996 that there are three virtues of programming: Laziness, Impatience, and Hubris.
This got me thinking. could these be genuine, or are they the tech world’s deadly sins masquerading as virtue?
Laziness
“The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.”
If laziness is the quality that makes you go to great lengths to reduce overall energy expenditure there is something wrong with the world. This is because software developers I’ve worked with have taken this principle to the extreme and used a not my job attitude to avoid work (and/or thinking).
There’s a thin line between automating repetitive tasks and avoiding responsibility. I don’t trust my fellow software developers to avoid crossing it.
Impatience
“The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.”
As a virtue this is a driver for performance optimization, pushing developers to make programs run faster and more efficiently.
However, in the wild, this often translates into a toxic rush (Danny Kahneman we miss you), skipping proper tests, and a frantic push to meet deadlines that are as realistic as finding a full-stack developer who knows the BE and FE to any degree. The “pretend” part of this quote is illuminating, as many devs “pretend” to adequately test their work and they certainly do write programs that “pretend” to meet user needs. I’ve had enough of this vice.
Hubris
“The quality that makes you write (and maintain) programs that other people won’t want to say bad things about.”
In reality, we know that documentation is seldom completed. “It works, why explain it?” is a refrain repeated by the software development choir. I’ve seen same care taken when writing code.
Perhaps this is because the software developers I’ve worked with like to blame the previous developer for working in a way that isn’t compatible with delivering their current features
Bringing it home
In the grand tradition of programmers everywhere, each virtue can also be a vice. Things taken to an unnatural extreme are likely to end up damaging our software quality or the product hitting rock bottom due to sheer egotism and avoidance of basic work.
The real question is — how does one balance these so-called virtues in the daily grind of software development?
This should be the domain of competent senior developers. Whether your team chooses to embrace these virtues or treat them with a healthy dose of skepticism, remember that the path to coding excellence is seldom paved with shortcuts.
Conclusion
I’m always on the lookout for ways to genuinely improve our craft without sacrificing the soul of good teamwork and robust, understandable code…I hope you are too.
Now please go and write good (tested) code, for the sake of good maintainable software.