Amateur Software Engineering
I would never call myself a software engineer - I don't have any qualifications in the field, I don't have any current training, and I do have respect for those who do. I learned to write code far too long ago, and never really got the hang of object oriented code. That's why I call myself an amateur.
But we all do sometimes have to do what we're not trained to do, regardless. And with luck, learn useful things along the way. Particularly when it is the relationship between the software and people (either those who originally wrote it, or the users) that makes solving the problems interesting.
I seem to keep on fixing other people's stuff
When I was writing about my 2025 adventure Fix our laptop, I finally realised that I have done quite a few projects which were in some ways similar. What I mean is, originally setting out to only get the old software running again, but ending up finding that it was better to either fix or modernise a whole lot of other things along the way.
A few of the times that I'd done that before were updating the installer, and stopping the old software from locking up on a new operating system.
Realising that does hurt a bit, because a few decades ago, I had a Performance Improvement Review where I was told that what's wrong with me is that I had spent my entire career fixing other peoples' mistakes (which isn't true), and that I needed the experience of working on a project myself from the start so that I could design it properly (which I still don't agree with, because the reality is, I would just end up fixing my own mistakes instead).
A few years later, as we were winding up a large software project, I was told that "we've left a few things there for the maintenance programmers to find". Uh oh, sounds like a gotcha. That eventually became two life lessons for me:
Lesson 1: So maintenance programmers are apparently some kind of lower lifeform? Since then, I have learned a whole new level of respect for them, because they have to learn how programming was done back then, not just the latest trend. They also usually have to reverse-engineer how the software was originally written, and too frequently, without adequate documentation of the design.
So my view now is that there is nothing inferior about your job being to fix other peoples' mistakes, it is just a different skillset.
Lesson 2: Years later, I ended up becoming the maintenance programmer myself for whatever gotchas those people had left behind. I had been tasked to do the investigative work but not write any code, because real software engineers would be hired to do that, once I had found out what to do. I didn't like it. I realised that without actually trying out potential fixes, I would just end up designing a whole heap of things which would eventually turn out to not work. That's why there is this concept in software called "prototyping", which is where you try it out first to find out if what you've come up with will actually work. So that's what I did, and it was interesting that I never did find any of the gotchas, yet everything worked properly once I had fixed the actual mistakes.
You have probably already guessed how that turned out, which is that we never did hire any software engineers, we simply shipped the updated software with all of my prototype fixes in it. Time to smirk.