One of the interesting challenges about software development is how non-linear the work can be.
Sometimes you can rathole on a problem for hours or days only to find you have chased a dead end, or even worse, discovered that work you have already done is suddenly useless.
Welcome to the world of negative work.
Negative work is one of the most frustrating parts of software development. We talked previously about the importance of planning your work, as if you were building a bridge.
Preventing negative work is really hard. Most of the time it is due to incorrect assumptions which may also include random things like language constraints or possibly even deployment security issues.
I do not have many silver bullets for preventing negative work—sometimes it just happens. The most I can do is to counsel patience when you discover it and try to understand how you got to where you are. If you are lucky, it is something you can add to your leadership playbook as a preventative tool in the future.
The most important thought I have about negative work is to realize when you have avoided it. There have been times when I was making software that I narrowly dodged negative work, but actually did not accomplish meaningful forward progress. While it is frustrating to have zero forward momentum, it is nice to avoid creating an engineering deficit.
Sometimes the best you can do in those situations is to share this discovery with your team and then say “Hey we did not move forward, but at least we did not do negative work!”
I am going to give the salty signoff a pass today with the hopes you spend some time examining the times you have created negative work, or narrowly avoided it. The better you are at identifying it and preventing it, the more effective you will be as an engineering leader in your career.
