November 5, 2020
Henry ‐ Software Engineer
The aim of the article is not to put forward the idea of deletion for deletion's sake. Sometimes solutions to things are large, this approach aims to simplify as much as possible.
A large part of my love for this job feels similar to exploring an open world game. There’s the opportunity to create, discover and cause chaos in more directions and spaces that I know exist.
You are over encumbered and cannot run…
However, this ability to ‘create’ leaves behind a path of waste. Why keep the level one pistol you got at the start of the game, when you now have a level 35 blaster rifle? More and more, I’ve found links between this and the world of software creation. Your level one function that did the job you needed it to do on day 1 of the project may lay dusty and unused. Oh, and how about those todo comments/tickets you made, for the improvements you wanted to make?
Delete something at the end of every day
It’s great that those things were made, especially if they were broken down into small, easily traceable bits of work, but why not view deletion in the same way?
Humans love destruction
Find yourself five minutes at the end of every day, and delete something! It doesn’t need to be a big job. Perhaps one of the tickets you made to improve the function that you no longer use, or the entire function.
Make a habit of this! It should lead to a point where you can’t find something to delete and you spend the entire time searching. More than once, this search has ended in me learning something.
Don't be afraid
A well taken care of to-do list is a powerful tool. It can provide a great source of 10 minute tasks, to pick up in-between other work. However, when full of no longer relevant items, work that’s planned prematurely, and duplicated items, it’s near impossible to find something to pick up.
If it’s needed, it won’t last.
Top priority tickets will be completed before you have a chance to have a problem with them. Humans are much better at focusing on short term goals, so don’t plan for the work that sits a year in the future. Just have a general idea of where you’re heading.
One area I’ve been cautious about applying this idea is around security based work. It may be that a piece of work was completed with security features that need improving before releasing to the public etc. and it scares me that I might delete something I need. My brain tells me that there should be an easy way around this and that I’m being incredibly blind… Experimenting with manual canary builds could be a way forward.
Clear the noise
This approach is applicable to problem solving too.
Sifting through error messages in an attempt to find those relevant to your issue is insanely annoying. We live in the beautifully powerful world of source control, don’t be afraid to totally destroy easily recoverable things.
Be brutal and remove entire parts of code that get in your way. If it stops something irrelevant to your issue from throwing an error then great, you’re one step closer to seeing the problem you’re actually solving.
If your tests fully outline the functionality that something has to provide, you could even view this as a chance to rewrite it. You’ll either find out your tests didn’t outline something they should have, or you’ll end up with cleaner code.