One of the best experiences I had that humbled me was getting irritated by the inconvenient/obscure code I was dealing with. It was clever as hell, but impossible to understand and even harder to work on. It wasn't buggy but we needed to add a new feature and it clearly didn't anticipate that. I spent hours cursing the bastard who wrote it. Finally after I was done and checked in the changes, I looked to see who had written the original code. It was me.

Oh yeah, I’ve done that one a few times. However! I’ve also had a couple of cases where I was really happy with whoever had written something only to find out it was also me. Very rewarding.

Indeed, that has happened to me as well. I chalked it up to me just liking my own style though. But yeah it's awesome to work on code I wrote and think, "wow, what a thoughtful design!"

>I looked to see who had written the original code

Oh man that guy is the WORST.

> I get inconvenienced by other people's code all the time, but it's so easy to assume when you're looking at the bug "they should have known this was going to happen / tested for this" when you started your investigation knowing the trigger for the bug.

When I was a junior dev I had a tendency to want to rewrite everything. I remember thinking that most the code I was working on at the time was overly complicated and could be done with far fewer lines of code. Recently I realised I might now be the guy that now overengineers and writes overly complicated code. I think this is common trend for devs too, as you mature you get really good at anticipating future problems so tend to write code that doesn't just meet the current requirements, but can scale into likely future requirements.

I feel like I've kind of gone full circle and now and I'm starting to question if there is a middle ground between the simplicity of writing simple code to solve a very specific problem and the extra time required in writing code that scales. The reason I say this is because I realised devs working on my code often don't fully understand the reasoning behind what I've written anyway and I and the devs working on my code often don't have the time to read / produce documentation explaining the code in detail. I also can't guarantee I'm always available to review PRs and ensure the code quality is maintained, so perhaps most of the time it's wasted effort.

Also often you just don't know what kind of constraints devs are working under. I know for a few projects with tight time constraints I've been asked to do the bare minimum to patch certain bugs or add some functionality so we can ship ASAP. I'll normally push back on this if I feel it's a bad idea, but code quality isn't always the most important consideration.

I realise I'm much more open minded when reading code now because after 15 years as a dev I'm still not sure I always do things right myself.

> Anecdotal story: I had a bug a few weeks ago that all sorts of people thought was really dumb / obvious / shouldn't have happened. I checked... the code hadn't been changed for FIVE YEARS. Nearly every customer we had ran this code for five years. Maybe I feel that they should have had a catch for the situation that occurred, but whomever wrote it wrote code that lasted bug free for five years ... maybe they weren't dumb and they knew something I didn't?

I've seen this. Huge big O complexity but on a dataset that fits in cache? Runs fine. As soon as the dataset gets bigger, you get systematic timeouts.