Posts for 2016

Larry Wall, creator of Perl, is also the author of Programming Perl. In it, he said something that has inspired me profoundly as a web developer.


Now, there have been numerous interpretations of these virtues. But we're not going to bother with those; I'll be providing my own take on this. (What? Last time I checked, this is my blog.)

So the burning question - why are these virtues? In most other contexts, they would be considered sins. However, not just any lazy, impatient and arrogant SOB can be considered a great programmer. In fact, it takes a special kind of lazy, impatient and arrogant SOB to be a programmer at all. And I humbly submit that these three virtues are stated in that order for a good reason - they separate the adequate from the good, and the good from the great.

The Virtue of the Adequate Programmer - Laziness

If you remember nothing else about programming, remember this: minimum input, maximum output. All programming is about solving problems and automating tasks. Whatever fancy new gimmicks and technological advances the next twenty years throws at you, philosophically, programming does not change. This has been, is, and will always be; the one truth about programming. Whatever languages you use, whatever platform you swear undying loyalty to, it all goes back to this in the end - minimum input, maximum output.

The ultimate aim of any program is to make life easier. Because the awful alternative is more work. Not just more work - more boring and repetitive work which would be better done by machines.



Programmers are always looking for the shortest, most direct route from Point A to Point B. They are always looking for a way to reduce that repetitive, monotonous task into a series of processes and outsourcing them for a dumb machine to execute. In other words, programmers are the taskmasters, and computers are the slaves. If that's not lazy, I don't know what is. The question is invariably "can this be automated?" followed by "how much can this be automated?".

Human beings get distracted. They get bored. They get frustrated. Machines don't. And therefore machines are the perfect candidates as slaves to carry out all that mindless work and in the process make life easier for the programmer. Notice how I said "make life easier" twice?

This is virtue numero uno for a good reason - not all programmers have the other two virtues (and therefore not all programmers are good, or great). But all programmers (and their cousins, the web developers) have to embrace this virtue at their core.

How not to be Lazy

Laziness comes in various forms. Not every form of laziness is admirable. If that laziness leads to more work down the road, it's counter-productive.

Copy-pasting code blindly without checking for relevance and room for improvement - that certainly qualifies. It's something I actively avoid.

If the code is going to be reused in the foreseeable future, invest a bit of time abstracting it into methods and subroutines so that it's easy to reuse and maintain. The Don't Repeat Yourself (DRY) principle is applicable here.

Sloppy code, lax security measures, incomplete test cases are all good examples, cases where the programmer couldn't be arsed to close that last loophole. Guilty as charged. Sometimes reality demands that I have to cut corners. It's not an excuse, but sometimes people have to choose between being a bad programmer who delivers, and being a great programmer who's out of a job.

In an age where many great programmers have paved the way for us by writing systems that automate even programming tasks, it's very easy to be lazy in the wrong way. Plenty of developers I know don't bother with the basics because that newfangled framework takes care of it for them. I'm guilty of this too. For instance, garbage collection and memory management is not exactly something I like to concern myself with - though in my defence, as a web developer, my priorities lie elsewhere.

Mastered laziness yet? Or at least gotten the correct attitude down? If not, keep at it until you do.

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.



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.

Hubris is probably the most misunderstood of all the programmer virtues. But you're in luck - I'm Teochew, and if anyone understands arrogance, it's us.

The Virtue of the Great Programmer - Hubris

Developer ego is more commonplace than you'd expect. Any developer with some experience under his belt is going to be rather opinionated about how things should be done. Programming is about bending the will of a machine to our own, and making it churn out the results we want. It is about creating usable objects out of virtually nothing. It is about dealing in languages many people are too intimidated by to even attempt. And getting paid for it. Why wouldn't we be arrogant? Consider the quote below from Robert C Martin, in his book The Clean Coder.


Robert C Martin seems to be a bit of an extremist in his views, and more than a little verbose. But in this case, he hit home for me right there.

But... but, but.



In order for hubris to be a virtue, it has to work for you. It has to help you in your development. It has to drive you.

It has to spur you on to create products that people can only praise. Any code attributed to your name has to achieve great things. That arrogance manifests itself as pride in your work.

It has to inspire you to go boldly where no one has gone before. "A hundred programmers have failed? Well, I'll be the hundred and first." "Better men have tried and failed? Bitch, there ain't no better man." In fact, I believe that it is this same audacity to try something different, something unthinkable, that separates great programmers like Bill Gates (daring to succeed despite dropping out of university? The sheer gall.) and Linus "I'm always right" Torvalds from the rest.

How not to be Arrogant

Some forms of arrogance manifest as a belief that one has already learned all that is worth learning, and there is no need to keep exploring. That's arrogant, sure... it's also foolish. Dangerously so. Technology is constantly evolving. As I type this, a few million hackers around the world have figured out newer and more insidious ways to breach web security. New frameworks are threatening to render the ones you use obsolete. New features in your favorite programming language are causing older features to be deprecated. Going down this path is a sure route to ruin. There's a place for arrogance. Not so for complacency.

Refusal to listen to feedback is another dangerous manifestation of arrogance. Sure, not all feedback is created equal. If, for example, you haven't written a line of code your entire misbegotten life and have the audacity to comment on my professionalism, be prepared to be very firmly put in your place. On the other hand, working too close to the product can lead to blind spots, and sometimes - just sometimes - fresh perspectives are helpful even if they are from laypeople. There's also a tendency for a developer's ego to lead to defensiveness - such as refusing to concede an argument or admit that someone else knows more than you do. That is insecurity. If you're confident enough in your own abilities and value, you don't ever need to travel that rocky road.

Then there's the Not Invented Here syndrome. The pragmatic developer understands that there is no shame in collaboration or leveraging off someone else's work. "Real devs code from scratch"? What kind of egoistical rubbish is that? No matter what you do, you're leveraging off the work of Ada Lovelace, mother of the modern computer. Want to be a "real dev"? Go re-invent algorithms!

So...

Are you an adequate, good or great programmer?

This is, as you may have suspected, just my opinion. There are many ways to interpret the words of Larry Wall. In fact, I have no real business telling anyone how to achieve greatness in programming - after all, I'm just about adequate myself, on some days anyway. Like many people, I have my moments. Some days I feel like I'm Neo from the Matrix, and some days I wonder why I'm even employed.

But in general, yes, most developers fall around the "adequate - good" axis, with only the top echelons making it into the "great" category. Still, "adequate" is a good goal, and "good" is a respectable one.

Be virtuous!