The Laziest Programmer In The Room

There are lot of blog posts on how laziness is a quality of a good programmer but you’ve gotta be a developer to find those blogs sometimes. I want to talk about evaluating the laziness of a programming consultant and how it can be a good or bad thing.

If you know anything about building software, you learn very quickly that it’s a whole lot of trial and error. You make a change, refresh the browser, and see if it worked.

Rinse, repeat. Sometimes for every. freaking. change. (Those of you who’ve built software for Internet Explorer have been there.)

Being a software developer consists of a whole lot repetitive tasks and that’s where laziness comes in. A developer who gets frustrated quickly with repetitive tasks will be the first to build a tool to automate it. They’ll figure out how to refresh their browser automatically with every code change. They’ll make a tool to clear the database and test the file import again for them automatically. If it has a pattern, they’ll realize it and automate it.

A lot of times, I’ll see clients who need software built but they’ve been running this manual repetitive process for so long they have kind of forgotten that it was a problem. It’s inefficient and it’s wasting time and money.

Enter the lazy programmer

If you hired a software developer you could explain the process and, if you’re really lucky, he could whip up a quick solution in a couple hours. Sometimes it is more complicated, but forcing your workflow into Excel isn’t usually the best solution in the long term.

Ruby on Rails is the framework of choice for a lot of software developers who want to prototype solutions to business workflows like these. It’s got all the tools you need to build a quick and dirty automated process within a few hours. You can get straight to business and seeing the fog clear. Your optimized business workflow is going to make you and your customers happier people and it’s probably going to make you a whole lot of money in the process.

I sometimes say that the lazier a developer is, the better. That’s not to say that taking shortcuts in code is the right solution. A lazy developer will know that shortcuts often don’t play out well in the long term. Planning up front will save him time in the long term. A lazy programmer plays long ball. He works towards the long term. He also knows when to take shortcuts. If an idea is not fleshed out well or is based upon assumptions, then a lazy programmer will be the one to argue that we try something new, test it, measure the feedback, and make a decision based upon the results. It’s more work and money if we build software upon assumptions that needs to be redone later. Nobody wants that.

When changes need to be made in the future, the lazy developer can make them with ease because he planned properly. The developer who over engineered the problem is usually the one who worked himself into a box. He built a box with a thousand features in the beginning. It was maginificent. Or so he thought. It turns out that the box he designed isn’t able to be reshaped along with the business.

So if you hear me say that laziness is a virtue, well now you know. Lazy is no longer a bad four letter word. It’s a blessing.