paint-brush
Procrastination From a Remote Programmer's Perspectiveby@shepelev
7,093 reads
7,093 reads

Procrastination From a Remote Programmer's Perspective

by Alexey ShepelevDecember 6th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Ruby on Ruby on Rails Developer Alexey Shepelev writes about procrastination and motivation. Why is this problem usually less acute in other professions? Why are programmers so special? It's all about the specifics of programming (systemic solutions to complex problems). You cannot program half-heartedly – such work is slim to none. A code with one insignificant error will not work properly, even if the other 99.99% are correct. Writing a bad code is an absolute waste of time and effort – this will not speed up fixing it.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Procrastination From a Remote Programmer's Perspective
Alexey Shepelev HackerNoon profile picture

I've read many articles on procrastination and motivation, but I've always found in them a complete or partial misunderstanding of the problem. Or just inconsistency with my realities – after all, people are different. I'm going to describe what I know from my own experience and what helps me personally. Maybe it will help someone else.

What causes procrastination? Why is this problem usually less acute in other professions? Why are programmers so special?

It's all about the specifics of programming (systemic solutions to complex problems). You cannot program half-heartedly – such work is slim to none. A code with one insignificant error will not work properly, even if the other 99.99% are correct. What's more, even if the code works, but it is quite ugly, most often it will have to be rewritten from scratch – this will be easier than trying to fix it. In fact, writing a bad code is an absolute waste of time and effort – this will not speed up fixing it.

Writing a good code requires a certain mood. Regardless of a competence level, a programmer can be writing a good (from his point of view) code only for a few hours a day (maybe even less). If you think you can be writing a good code all day long, every day, you've probably outgrown your current work and it’s time to take on more serious tasks (for example, learn how to automate it).

There is no such thing in most other jobs. "Drawing molds", talking on the phone, writing letters and documents – all this can be done half-heartedly all day long. The result, of course, will be worse than you would like, but not a zero one. And small defects can be fixed later.

This is part of procrastination that all programmers suffer from – both office and remote. But two things are unique to remote work – flexible schedule and lack of direct communication.

As for the flexible schedule, everything is clear – if a person's ability to have fun is in no way limited, he will have to use his willpower so as not to spend the whole day on entertainment. But here, as with homework when studying, most people develop the necessary skills and priorities over time.

However, the lack of communication has a much greater effect than it seems. The main thing here is the effect of presence. Why do pupils and students learn materials better and do laboratory works with greater enthusiasm in the presence of a real teacher? Why do teachers read the same lectures over and over again by voice whereas audio recording and broadcasting technologies have existed for decades? The answer is human psychology. It is much easier to focus on information when everyone around you also focuses on it, and when it comes from a person (real, physical) endowed with authority.

But let's go back to work. The programmer may give up writing a complicated code to go and help his wife hang out the laundry. He won’t even think of how absurd his decision is. Since the problems of a distant foreign customer are perceived much less real than the problems of a person nearby. It is much harder to concentrate on a problem when you need to actively imagine it in order to believe in its existence.

To summarize: to start working, a remote programmer first needs to make an effort and use his imagination to convince his brain of the existence of a "virtual problem", then make an effort again to reduce the time for entertainment, and the remaining energy should be enough to write an error-free and quality code. And if it is not enough, then it is better not to start writing, it is still in vain. Doesn’t seem like a simple problem of laziness anymore, does it?

So, we've figured out "who is to blame". Now let's move on to the question "what to do".

If you've found out that you keep procrastinating and continue to waste your time, ask yourself the question "what is my next task and when can I complete it". Do not leave it until you can clearly, in words, formulate an answer. In such a case, "when" is not time, but a state. Maybe even condition. Depending on the answer, evaluate what you are doing – how much it brings you closer to your goal.

My internal dialogue usually goes like this:

  1. "I need to create feature X. When can you do this?"
  2. "When I get enough sleep/when I feel good" – do something that brings this state closer. Eat. Go to sleep. Feel sick? Get some treatment. Right now. Not "when I finish the episode", not "when I finish playing the game", not "when I finish my coffee" – all these actions do not bring you closer to your working state.
  3. "When I'm in the mood" – do something that improves your mood. But do only what actually works. If you're watching a TV series and catch yourself thinking "when this episode, damn it, is over", turn it off and never return to it again. Look for something that is guaranteed to work. And remember what doesn’t work (only spoils your mood) and what should be avoided.
  4. "When I figure out what exactly needs to be done" – it means that your next task is not "to do", but to "figure it out". Deal with it. Ask the customer/manager (ask again if you have already asked and have not received an answer), or try to dig into the problem yourself. If you’re not trying to figure it out right now, you’re just wasting your time.
  5. "When I deal with some other matters" – it means that your current task is among these "other matters". Yes, now it is a work task. From the outside, it may seem that other matters have nothing to do with work, but this answer shows they do.
  6. "Well, I could probably do it now" – do it.

The basic principle is "since you're not working right now, then at least make sure that you are doing something that is guaranteed to bring your working state closer".

In fact, anything that affects the effectiveness of your work also becomes part of the work and should be taken seriously. This is purely a matter of perception. If you need some sleep for productive work, then "get enough sleep" from now on is the customer's requirement (albeit implicit). If you need to be in a good mood for work, then even "playing some game" to improve your mood is already part of the requirements.

There is nothing more senseless than self-recrimination for what is actually inevitable and required for work. Of course, each person will have his own needs. The main thing is to honestly admit them.

Hardly anyone can lift a load weighing a ton and move it to another room, even if it takes a month. But to move a hundred 10-kilogram loads is already doable. You should do the same with work – divide it into small parts and do it whenever possible.

That's all trivial, but I have an additional lifehack – leave some of the pleasant and easy work for the beginning of the working day. Just make it a habit to stop working only when you already know which lines you need to add to the code next. Believe me, a slight discomfort from the feeling of "incompleteness" is then fully compensated by how easy it is to get into work again.