For the sake of laziness!

Sebastian MalacaJanuary 25th, 2017Last Updated: January 24th, 2017

0 173 3 minutes read

I like well written code. I like to reach out for perfection. I like to look for the most suitable design and solution. I’m doing it not because I treat software development as a kind of art and myself as an artist. I never looked at this in this way. I’m doing it, because I know it pays off. And one of my greatest motivators is my own laziness.

You should be a lazy developer!

Have you ever had a problem with the name of the class/method/field/etc.? If yes, then you know how hard it may be to come up with a well descriptive and self-explanatory name. You can struggle with such problem. After a while of fruitless thinking the new idea appears in your head – maybe I will just leave it as it is? Well, at the end it is only the name, isn’t it?

Don’t go this direction my fellow developer. If it is so hard to come up with a good name right now, when you are in the context and you understand this mystery code try to imagine how hard it will be to understand this code without proper names in a month from now! You don’t want to read tons of lines. You don’t want to look for the “whys”, “whats” and “hows”. You don’t want this effort. You should be too lazy for that. It’s better to spend one additional hour right now rather than days in the future.

You should be a lazy developer!

You are reading code. There are things you can understand pretty fast. However, there are some in a little worse shape and finding out what is going on with them is much harder. But you have to understand this functionality because your team will work on the change (feature? bug fix? whatever) that require modification in here. So you are reading. Finally you know more less what this code is about. What will happen under specific circumstances.

What would be your next step? Happy development? If yes, then you should stop for a moment. Maybe it would be good time for quick refactoring?

I know that refactoring requires some time. Can you estimate how much? How much is it in comparison to the time you spend on “real” work? I assure you it is not as much as you can imagine. Why am I so certain about it? Because you already did the hardest job. You understood the code. And what is refactoring about? About increasing descriptiveness of the code!

Use knowledge you already gathered! You know what was hard to understand. You know the places that were problematic. What is more important – now you understand these parts of the code! Simple renames and private methods extractions would be enough if you don’t have a time for more. But believe me, these renames and extractions will make understanding the code less painful.

If you are still not convinced, just remind yourself how much effort and time you put into understanding this code. Do you want to experience this ever again? You should be too lazy for that!

You should be a lazy developer!

Developers read far more code than they write. That’s well known and pretty obvious truth. Have you ever been in a place where you really could not understand justification for the part of the code? You were going through every business scenario you could imagine and you still didn’t know why this code was written in the first place! After some time you were almost certain that this code is useless and not needed and you almost decided to remove it, but… maybe there’s a magic place where it’s used through reflection? You are just scared a bit. What if?

You don’t want to be in that place. You don’t want to feel that fear. You don’t want to be forced to imagine every scenario. There’s always a chance that you miss a one or two or even more. It always an additional effort. Sometimes huge. What would make it easier? What would let you forget about the fear? Tests for the code would be useful for that. Well written tests may be used as a pretty good documentation, don’t you think?

Don’t let yourself skip the testing part during development. You have to be too lazy for that!