Good laziness, bad laziness
I remember once reading an article in the early 2000s with the same title as this post. The article was about software development and it focused on two types of laziness. The first type of lazy was ‘bad’. It was a caricature of a developer who hacked around trying to make something work. The developer never checked his code into the source code repository. He had no structure to his project. He had no tests.
But, he built a working solution super quickly and got something into the market which started earning some revenue. The last bit sounds good, so where’s the problem? The problem is that the product now being used by customers was unmaintainable. It was unmanageable. No-one could figure out how it worked. It took a team months to unpick it, re-writing it and re-crafting it so that it could be effectively built on. There was a lot of hard work from a lot of people to make it usable.
The article then went on to describe a form of laziness that was considered ‘good’. That is, all of the right steps were taken upfront to organize the work properly, build the deployment and test scripts, and make sure the architecture was documented. The project went a bit slower at the start, but it was built on a firm foundation. The person who wrote this article suggested he was lazy and that’s why he did all these things. He didn’t want the hassle of unpicking the mess later on.
Consider
Are there ways you can introduce some ‘good lazy’ techniques into your day-to-day work?
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
