When I was a child I didn’t enjoy puzzles. They were laborious and boring. Puzzles required what felt like an infinite amount of patience. I was certain:
Puzzles are for people who are themselves boring, who have too much time, and are sticklers for details without seeing the eventful world surrounding them.
Imagine my shock when I learnt that I like puzzling. The puzzle was a Christmas present meant as shared family activity during holidays. Strangely, I found myself doing a third of the puzzle, even though there was other things I could have done.
Analog to this, I noticed that with increasing software development experience I gradually started to enjoy “code puzzles”, by which I refer to surface-level boring, tricky, laborious code work whose result - if successful - is often unnoticeable. That’s tasks like fixing long-standing bugs, and maintaining complex systems so that they operate smoothly. There’s a thrill of running into unique unknowns every time, a gratification knowing that persistence and deep research are required to uncover the inner workings.
Contrast tricky bug fixing to whipping out a new iterative UI feature: Creating and wiring up components can feel too routine. It’s not that that’s not demanding enough when setting a high quality bar - there’s multitude of deep topics like web standards, styling, accessibility, performance - each of which I have tons to learn. But these are known unknowns.
It’s my luck that my newfound preferences are unpopular in many teams: I get to gravitate to “tough nuts”, while other team members are thankful that they get to avoid the cruft. Instead they get to earn the glory that comes with developing shiny new features. Whereas I am certain that in many situations new additions are luxurious fluff, and that working quality software is a pre-requisite for any value.