There are two types of laziness. The good one and the bad one. The good one drives us towards innovation, because we are too lazy to repeat something over and over, and we create a new, simpler way of doing it. The bad one pulls us down, slows us down, and in the worst case, it stops us.
A lot of people say that geniuses are lazy, and that’s true. They are too lazy to do something over and over, and they often come up with something new that changes people’s lives. Sometimes, these things do not change lives all over the world, but they can change the lives of people involved in some project. On the other hand, there are people who are too lazy to spend their time doing something thoroughly, and they give it a lick and a promise. That attitude also influences people’s lives – but in a negative way.
What is good laziness for me? It’s predicting likely changes that might happen in the requirements of your feature. It’s creating a method which can be used many times but might seem too simple to create it as a separate one. It’s using IDE in your work not to focus on creating new files or creating getters for your objects.
Let’s have look at some examples of good laziness.
The first thing that comes to my mind is (not) to reinvent the wheel. Let’s assume that you are dealing with a time schedule app so you are working with dates, a lot. And you need to know if a certain date indicates a weekday, or the past, or a Saturday. You could write all the features using a built-in date-time object – after all, who would do this better than you? But you could also use a package which someone has already created – for example Carbon. The creators of Carbon prepared methods for almost everything. You want to add seconds to your date objects? They’ve got it. You want to check if a certain date is a weekday? They’ve got it. You want to check the difference in seconds/minutes/hours/days? They’ve got it as well. They have predicted the possible usages of the package and created a lot, really a lot of methods to help the users dealing with time. The time you could devote to writing the code, you must devote to searching for the package, you might say. Of course, but you only do it once and after that you can use this package for every project that has some operations on dates.
Another example of good laziness is Continuous Integration and Continuous Development. I bet there was a time in your career when you needed to sync your repo’s changes with your production environment. What would you do? You would probably connect through the SSH to the server, clone the changes and hope that everything works as expected. But there was some lazy guy who said “That’s enough, I don’t need to do it over and over. I’ll make a computer do it for me”. And that’s how CI/CD was invented. True story. But let’s be serious. I can’t imagine getting back to the times when deploying to production was done manually. With Continuous Development it’s safer, faster and is done “in the background” so that you can focus on other, more creative work.
I would like to point out one more example – design patterns. Four people noticed at some point in their careers that there are concepts repeatable across projects and domains. They described these concepts in the book Design Patterns: Elements of Reusable Object-Oriented Software. That may actually not be laziness, because I can imagine how hard it is to write a book – even writing this post is hard. It is laziness though to learn them or at least be aware of them. Once you realize that there is a strategy pattern out there you will be too lazy to think how to solve a problem on your own. You’ll just use the Strategy design pattern and move on to the next task.
What are the examples of bad laziness then?
The one I notice most often is writing all the code in one place. Either it’s an if you need to add or a whole feature. We have some fear to create new methods or classes. It’s easier for us to add an if to an existing method. But after several additions, the method may become really large and unreadable.
It’s even worse when it comes to classes – we are afraid to extract some functionalities to another class and instead add everything to the existing one and finally we may end up with code smell called God Object. It’s a code smell that is described as “an object that knows too much or does too much”.
Another thing about separation and creating new “files” is to create simple objects which carry some information and sometimes behavior. I often see classes where the return parameter is an array containing multiple indexes, because someone needed to return more than one thing, and often – if not always – related things. Instead of returning arrays, you can create an object called DTO (Data transfer object) to transfer the data through the layers of your application. We tend to operate on primitives as they are objects – it often requires some hacks from us to be able to “add some behavior” to a primitive or a set of primitives. But maybe it would be better to create a dedicated object that will encapsulate the primitives and provide us with methods representing expected behavior?
The last thing about bad laziness I would like to mention is quick fixing. So, your colleague wants you to add some index to the response or change the date format? Yeah, no problem. It’s just one line of code, there’s no need to check if it works. It has to work. Well, it often doesn’t. You save 5 minutes on not testing it – either running your unit tests or clicking the functionality – but if it doesn’t work your colleague will have to get back to you, and he/she will be frustrated. You will need to check the code again and a 5-minute fix turns into an hour of going back and forth. If you had only tested it the first time…
A quick sum up:
Laziness can be good. Beware of the bad laziness, otherwise it can get ugly
Reinventing the wheel is almost always a bad idea. Just use packages someone has already created. 30 minutes of research can save you many hours of bug fixing and you can also use the package in your other projects
Automating your work will help you to focus on a problem that you need to solve. You will have more time to be creative.
Design patterns are good.
Don’t be afraid to create small methods or even classes that have just one method and one field. If it’s reasonable, of course.
Test your code before you push it to repo.