This is a mobile version, full one is here.

Yegor Bugayenko
17 April 2018

How to Be Lazy and Stay Calm

What frustrates me most in my profession of software development is the regular necessity to understand large problem scopes before fixing small bugs, especially if the code is legacy and not mine. Actually, it’s even more frustrating when the code is mine. The “deep thinking,” as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how.

I wrote about this a few years ago in this blog post: How to Cut Corners and Stay Cool. However, in our Telegram group, where we talk about Zerocracy, some programmers keep asking me the same question over and over again: What should I do when the project is absolutely new to me, I have just 30 minutes, and the bug is very complex?

One of the core principles of Zerocracy is #NoAltruism. This literally means that you should always and only think about yourself and your personal profit. You should not try to improve the project, to increase its quality, to fix the code, or to refactor anything… unless you are paid for it.

First of all, when the task, which you are going to be paid for, is in front of you and you can’t understand how to solve it, don’t blame yourself. You are not supposed to be an expert in the legacy code you just opened up. Strictly speaking, you are not supposed to be an expert in anything. A project, unlike your mom, doesn’t expect you to be intelligent or tech-savvy. It needs you to close tickets.

Who do you blame, if not yourself, when the bug is serious, the code is messy, and you have no idea how much time it will take just to understand it, let alone fix it? Well, you can blame everybody around you, but first of all you should blame the code base itself. How do you blame it? You report its low quality by creating new tickets, which may sound like this:

However, don’t make the mistake many programmers are making when we tell them that tickets are the only right way to solve problems. They start asking questions and seeking help in the tickets, just like this:

The project is not a school, it’s not interested in making you smarter or more of an expert in its code. Nobody will explain anything to you, because it’s a waste of money and time. What the project will do instead is fix its code base so that it becomes cleaner and more obvious for you and everybody else. Thus, never ask for explanation or help, ask for documentation and source code fixes.

What do you do next? You sit and wait, until those tickets are resolved. Who will resolve them? You don’t care. That’s a problem for the project manager. Maybe he/she will even assign those tickets back to you and it will be your problem to resolve them. But if that happens, the scope of work will be different for you. You won’t need to fix the bug anymore, you will have to document some functionality or refactor some module.

You will have other problems in this new and smaller scope. You will create new tickets, blaming everybody around you, and they also may come back to you. And so on and so forth. Ultimately, the scope of a ticket will be as small as it’s possible to fix in 30 minutes.

See the algorithm? I’m sure you do, but it’s very difficult to apply it to real life and real software projects, for a few obvious psychological reasons:

Software development is perfect territory for cutting corners, being lazy and remaining calm, because our work is often discrete and can be very incremental. Very occasionally it might not be possible to blame the project and put the ticket on pause until all your complaints are addressed. I can’t imagine such a situation though. If you can, please let me know.