I like maintaining code. I think it’s funner than starting something new. I remember I had a job interview where someone was trying to get a sense for whether I like starting new things or maintaining old things; turns out the job was a prototyping gig so I didn’t say the right thing.
But a lot of people don’t like maintaining old code and I think that’s because they end up being fire fighters. I’ve been there and it sucks. It’s demoralizing and the reason I’ve left jobs. It can happen when you are a startup selling a b2b product and the clients paying you the most have asks of your software and you need to make them happy so you build the one off thing and no one says no and you end up with a Frakenstein app a year later that no one wants to touch until the amount of queries they’re running brings your site up in flames and you need to figure out how to get it running again.
There are a lot of different kinds of maintenance tasks though and I think it depends on what percentage of the time you are doing each of these various tasks.
I decided to break down what tasks I have found myself doing on the job (maintenance and additional work) in order of things I really enjoy doing to things I do not enjoy doing:
Changing code based on new requirements (adapting/refactoring)
I love making code that is flexible enough to change based on new requirements. It’s like making classes that see into the future; you can’t predict changing business requirements and asks but you can write code that handles changing constraints gracefully. I love gradual iterations and refactoring code so that the next feature ask makes sense in the current architecture.
Optimizations (perfecting user experience or addressing a performance metric)
This is an opportunity to hone my craft and focus on having the highest quality contribution. It’s also an opportunity for me to try to make the best decision possible given current data and leave that good decision in the code base. These are exciting to do.
Fixing bugs (correcting the system)
I love fixing bugs and it makes me feel like I’m making something better and it can be rewarding to find them and learn from them. But it can be demoralizing if you have to do this too often, so I hope I don’t have to do it that much.
Addressing technical debt (achitectural redesign)
This is also a really great learning opportunity, but it’s sometimes hard for a company to prioritize and it usually means you have more bad decisions in one part of your system than good decisions. This can be tiresome but at the end of the day you can say you made existing code better! I love doing that.
Feature work without dealing with legacy systems
I am not as excited about this because I always feel that there are parts of our product that could be better than they are, and building new things from scratch makes me feel like we’re sacrifying resources that could be making current things better. Though I have to admit this can be fun because it can be a learning opportunity to try a new technology or leave your legacy in the code base with a set of initial code decisions for this particular feature.
Greenfield projects as proof of concept
This is akin to pushing out a feature as soon as possible/testing out the market for viability before building something that lasts. I do not like this at all. I can see how this can be fun (growth hacking/engineering is in a similar vein) but building a throw away feature to test viability doesn’t do anything for me.
Doing chores/writing one off scripts because you haven’t exposed a particular workflow to a non-technical team in your company.
I don’t like doing this but I also can really empathize with client support teams/non-technical teams and I love empowering others with knowledge. So I am okay doing this every once in awhile but if I have to do it often there’s a problem.
Doing whatever it takes to just keep the system working (emergencies)
I see this as a symptom of a long standing cancer that has affected your code base and you are left with being in perpetual firefight mode instead of iteratively participating in the care and feeding of your app. I love clean code and I love cleaning up code, so I am proud of the title of code janitor in doing the latter. I respect those who can do the former without getting too stressed or risking their quality of life.