This is something I really love about my job. It’s a small company, and we don’t have any of these kinds of process overheads.

It’s accepted that people fuck up (and in most cases that’re relevant to me, I’m the people in question) but if I can reproduce the problem, I can often get the fix in the users’ hands the next day. Generally the positive effects of a quick turnaround and feeling like they matter outweigh the negatives of the problem being there in the first place.

Not to say I don’t have stuff in the “tech debt” bucket, but having the autonomy to just fix the low-hanging fruit makes for a satisfying work environment.

Every company I worked for is like this. I sneak small improvements into daily work. If I call an old function, I’ll often fix it while I’m there. Don’t raise tickets. Don’t ask. Just fix it.

I also have a shelf of a hundred fixes that I never merged. I’ve done the work, but the real hurdle is PR and and testing. It takes days of effort to push code that took an hour to write.

At a previous company, I got in trouble for fixing a bug because the company made a significant portion of their revenue from paid customer support fixing data related to the bug.

It’s a big company problem. Here’s why even obvious bugs like this one slip through the cracks:

1. The Tyranny of “Requirements”
   In large organizations, everything revolves around the roadmap. If a bug fix isn’t tied to a specific requirement or feature, it gets labeled as “tech debt” and shoved to the bottom of the backlog. And let’s be honest: “tech debt” is corporate-speak for “we’ll deal with this never.”

2. The Rotating Door of Ownership
   Over eight years, developers and product managers come and go. The person who originally filed the ticket? Long gone. The person who understood the issue? Moved on to another project. Institutional memory fades, and the ticket becomes a relic of the past. Even if the problem is still very much alive.

3. The Myth of “Quick Fixes”
   A 13-line patch might seem trivial, but in a legacy codebase, even small changes can have unintended consequences. Without proper tests or documentation, developers are often hesitant to touch old code. The risk of breaking something far outweighs the reward of fixing a non-critical bug.

4. The Invisible ROI
   Let’s be real: improving load times doesn’t directly impact the bottom line. Selling Shark Cards (GTA’s virtual currency) does. Companies optimize for metrics that show up on quarterly earnings calls, not for goodwill or user experience, until it’s too late.

I always tell perspective employers that I don’t want to be management. I care too much for the user. And I tell current employers that they don’t want me in charge of priorities, because I prioritize tech debt.

1-money 2-incompetence 3-the senior prgrammer left somewhere and is uncontactable, or was sacked by a powertripping manager with the IQ of a cinder block and no one can work out what the hell they wrote.