Virtues of a Programmer

Larry Wall once said that the three virtues of a programmer are Laziness, Impatience and Hubris. This saying has become legendary tidbit of software development humor. And as all good jokes, this one is funny because it is mostly true.

I think we can all agree that laziness can be most definitely a virtue when it comes to programming. Writing software is not about working hard, as it is about working smart. This always reminds me of the tenacious, hard working students I used to encounter when I was a TA for the introductory Java classes back in grad school. There were few of those each semester, usually coming from Math/Science background taking CS the low level courses to fulfill some curriculum requirements. They were usually type A personality types: organized, ambitious, very eager to do well in class. They were also the students that would do crazy stuff like copy and paste the same statement six hundred times in their code instead of using a simple loop. Whenever they saw tedious busy work it didn’t ring the usual alarm bells in their head. They would jump right into it, and plow ahead never slowing down to think there might be something wrong with their approach. It felt boring, tedious and hard and therefore in their heads it felt right – this is how work is supposed to feel, right?

But that’s not how you program. When you write code, anything that seems tedious or boring and repetitive busywork usually means you are doing it wrong. There is always an easier, more elegant way. The whole point of creating software is to off-load the repetitive stuff onto the machine. A good programmer always finds a way to avoid doing too much work by abstracting it away.

Same can be said for impatience. When you are writing code, most of the time the important thing is to get it working as quickly as possible. You don’t want to sit there and reinvent the wheel. When your goal is to build software that does X you don’t want to spend weeks or even months solving problems Y and Z that deal with sorting and searching for example. Especially since those problems have already been solved and encapsulated into modules and libraries. There is usually no good reason to build things in house if you can pull in a third party library or module as a dependency and get same results.

Naturally, if you set out to improve search algorithm, then more power to you. Or when the built in library turns out to be a bottleneck then it may need to be re-implemented. But a lazy, impatient programmer will by default look for existing solutions before writing something on their own. And that’s usually a good thing. Rather than re-inventing the wheel every day, you build on the shoulder of giants.

But there is more to this than just using existing code. It is also about building things incrementally. I’m not going to preach Agile here, but the general idea of getting things to work quickly in small increments is generally a good one. It creates a positive feedback loop – you can see your project taking shape and becoming functional quickly, and then you iterate on top of it. You create mockups and dummy models for the stuff that is not implemented yet, and focus attention on components that need to be fleshed out avoiding potential clusterfucks.

Hubris is where Larry looses me though. Hubris is actually a terrible vice – whether you are a programmer or not. There is this myth of the so called “cowboy programmer” – a genius who walks into the room, sits down and makes miracles happen. He fixes the code-base that no on ever understood; he makes that slow app run blazing fast; he saves the project during the crunch time. Too bad that guy actually doesn’t exist. Every single superstar programmer I have ever encountered was just a plain old jerk whose code was just as shitty (if not shittier) as everyone else. Their stardom was not a result of skill but of personal charisma. These guys could sell themselves well and would take every opportunity to brag about their code.

But you know what their secret was? They cut corners. They didn’t test. They made intuitive decisions that were usually only partially correct. They wrote sloppy code and optimized prematurely. All because of overconfidence and hubris. You actually don’t want that guy on your team. Do you know who you want on your team?

You want guys who lack confidence in their skill. Do you know why? Because they will test their code. A cowboy programmer makes decisions based on hunches – he believes in the validity of his code and plows forward. A cowboy programmer does not stop to fix mistakes, or worry about edge cases or special conditions. Someone who is not as confident in their skill will write unit tests to ensure they are are not introducing instabilities or bugs to the code. Hell, they might even work out a mathematical proof to show their solution is going to work.

When you are building a team you want people who ask questions. You want people who view code reviews as an opportunity to learn and improve their craft, and something necessary to improve the product: not as a face-off they must win to preserve their reputation as the top dog. You want people who won’t just re-write a critical piece of an application over the weekend because it was “wrong” but will actually try to understand why it was written this way, and what are it’s quirks. People who will track down the developers who wrote the code and actually ask them for advice and guidance rather than rip out the foundations from underneath your project and replace them with something they deem better based on a hunch and a feeling.

I guess when Larry Wall was writing Perl the times were a little bit different. The software industry was still young and still wild. There was a place there for overly confident code cowboys who could get the job done. But those times are gone, and software development has matured. We now have best practices, patterns and various competing methodologies that help us structure our work. Hubris is no longer a chief virtue of a programmer.

This entry was posted in programming. Bookmark the permalink.



8 Responses to Virtues of a Programmer

  1. Mitlik UNITED STATES Mozilla Firefox Windows says:

    I think I am going crazy, your main banner looks different. </random>

    Reply  |  Quote
  2. Luke Maciak UNITED STATES Google Chrome Linux Terminalist says:

    No, you’re right. I’ve been messing around with web fonts. Just tweaking the layout a bit. I should probably ditch it and just go with modern twenty-whatever-year-it-is version but I’m lazy. :P

    Reply  |  Quote
  3. Jason *StDoodle* Wood UNITED STATES Google Chrome Windows says:

    Well, “hubris” can also apply to pride, not just arrogance, despite the latter usually being the one that’s meant. There’s nothing wrong with that definition; a good programmer should be able to take pride in the work they do.

    Also, the font works well for the main blog / page title, but not so much for headings.

    Reply  |  Quote
  4. astine Mozilla Firefox Windows says:

    Hubris
    Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer.
    – Programming Perl

    I also got the impression that it meant a willingness to take on challenges that might be seem impossible, as a willingness to do those sorts of things is how progress is made.

    Reply  |  Quote
  5. Athanor UNITED STATES Google Chrome Windows says:

    He said it was about writing code ‘…people won’t want to say bad things about’. While hubris could mean what you talk about, lazyness and impatience can also apply to bad behavior. If you write bad code, no test, etc. then it’s not what he meant.

    Reply  |  Quote
  6. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    @ Jason *StDoodle* Wood:

    Thanks. By headings do you mean post titles or subheadings within posts?

    @ astine:

    Right. But that only applies in situations when you want to make progress. Sometimes you want to meet the deadline and deliver something concrete, and the guy on your team decides it’s “progress tiem”. And then it turns out it might be a bad thing. ;)

    @ Athanor:

    Ok, you might be right. Maybe I’m indeed stretching his words a bit too much.

    Reply  |  Quote
  7. Jason *StDoodle* Wood UNITED STATES Google Chrome Windows says:

    It appears to look bad on “h series” tags, thus far. I’m guessing it’s just one of those fonts that looks poopy when bold. ;)

    Reply  |  Quote
  8. gogi-goji Google Chrome Mac OS says:

    Just a heads up, something seems to have gone wrong when you did some of your latest changes to the site. When individual posts are viewed in a mobile browser (at least in the stock Android browser and Opera Beta), your related posts plugin is generating a bazillion results. It looks like it keeps on generating them indefinitely. This also makes it essentially impossible to look at the comments in a mobile browser.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>