Artyom Kazak/Posts/The syndrome of subtle and persistent lack of motivation when coding

The syndrome of subtle and persistent lack of motivation when coding

The problem

Here's a tweet about software engineers slacking off. It got my attention:

software engineers be like "it is literally impossible to estimate how long it takes to do something, a fundamentally flawed question forced onto us by the Unenlightened PMC types" and then slack off for 4 days because they know their project will only take 8 hours tops

— @powerbottomdad1, Jun 15, 2021

I don't know why software engineers in general slack off, but I think I know why I personally slack off. This is related to 21-03-13: I'm not getting anything out of it — I have a very hard time doing something when I don't know whether I will get anything out of it.

Here are some examples.

  • I am implementing a feature. I think "I should write tests". At the same time, I don't think the tests will catch anything or help in any way. Emotionally, the combination of "I should do X" and "X is useless" easily slows me down by 10×.
  • I think "I should write in chat that I am going to work on X". At the same time, I don't expect that warning others will be useful to me in any way. In fact, it might even be harmful if somebody starts asking "wait, shouldn't you work on Y" or "by the way I still don't think we should even do X" or whatever.
  • I think "I should write documentation for the feature I'm writing". At the same time, I think nobody will ever look at that documentation. Or maybe it will go out of date very soon.

Software engineering is full of such things. I've listed a few small ones; in addition to them, the biggest one I can think of is "nobody will ever use the thing I am helping to build". I feel this especially strongly when I don't interact with the customers. Examples from my own jobs:

  1. At my first job, I was building a backend for a static website hosting. I don't think it even got deployed, ever. The project just died.
  2. At my second job, I was on a team building a cryptocurrency (Cardano). The project was fun and the team was cool — but I never interacted with anybody actually using the cryptocurrency. I quit a year later.
  3. At my third job, I was on a team building a backend for a secure messenger (Wire). I felt like it wasn't particularly useful and didn't have any benefits over existing messengers. I quit a year later.

My current job — rewriting a large codebase from one language to another — is literally the first job I've had where I can clearly see the benefit: the company will save a ton of money. I know how much money. I know exactly how the money will be saved. I know that I in particular can make it happen, and I know that without me it might not happen. Boom — I am enjoying this job like none of my previous jobs.

The solution?

It is possible to experience the subtle and persistent lack of motivation almost all the time, and not know that it can be fixed.

I think it can be fixed. It is possible to deliberately teach yourself that things you are doing are useful. My preferred method for teaching yourself things is "aggressively notice everything" (see The best self-improvement trick so far: a giant board for more details on this).

Let's look at the three examples above. 

  • Writing tests:
    • keep track of all the times a bug was found in code that obviously couldn't contain bugs;
    • keep track of all the times a bug was introduced later (and could've been caught if tests were in place);
    • keep track of all the issues caused by those bugs (missed deadlines, loss of trust, data loss, etc).
  • Warning others about your plans:
    • keep track of all the times your plans have actually clashed with others' plans;
    • keep track of all the duplicate work that could have been avoided if you had warned others, or if others had warned you.
  • Writing documentation:
    • ask people whether the documentation you wrote has helped them;
    • keep track of all the instances when you felt good that a certain piece of documentation was available (oh, and it will work much better if you also go and explicitly tell the person who wrote the documentation "hey, it was useful");
    • keep track of all the instances when a problem was avoided because somebody took the time to write a warning in documentation / a error message / etc.

Finally, one more piece of advice: if you preach all of this, it will help you believe in it. A perverse pyramid scheme of learning: teach X to three people and then you will believe it yourself.