There's very much almost a meme of those programmers who tell us all how everyone else is doing it wrong ... but their whole idea about who is doing it wrong seems to be entirely driven by how often they're inconvenienced by other people's code, but never account for how often others are inconvenienced by their code.

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.

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?

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.

> developers forget that the goal is to ship software and instead focus on doing everything the most correct

I'm far, far more frustrated by developers who focus only on shipping software and making dates by cutting corners wherever they can and leave everybody else to deal with their gigantic mess later.

That is squarely and fully leadership issues. I means this 100%. The way to avoid this are fully in management and leadership hands.

Agreed. I think many of us realize the futility of getting our leadership to change, and instead hope that our coworkers will change.

And the people claiming to be in the top 20% are going to medium and post a blog post about it.

I mean, he's not wrong.. but I always get suspicious if somebody is making up percentages. You know 90% of percentages are made up? (Yes I just made that up)

I see this as a false dichotomy - the real most correct way is less expensive, it's just that quite often people who think they're aiming at perfection are instead actually experimenting with different approaches at random with no clear benefit.

You don't need to cut corners to achieve cost effectiveness and tech debt is just that - debt, which always has to be paid eventually - either through expensive bugfixing, a rewrite or bad user experience.

The project's I've been in that went over budget usually had one or more of the following:

-Too large of a scope vs budget.

-Bad or no architecture whatsoever.

-Increasing personnel instead of reducing scope.

On the other hand projects with an architecture, a set of clear conventions and flexible scope fared much better.

It's also possible to try to strike a balance and to get it wrong. It is also possible to strike the right balance proportionally but be in a business environment where your best effort results in failure.

https://www.youtube.com/watch?v=t4A-Ml8YHyM

"It is possible to commit no mistakes and still lose. That is not a weakness. That is life."

Maybe I'm weird but I think I am pretty average at programming. Not great, not terrible. I get things done, more slowly and with more bugs than some, more quickly and with fewer bugs than others.

Of course most employers probably aren't looking for an "average" programmer, but I haven't found that they usually ask me to rank myself relative to others.

Their idea of average is going to be unique to that company. If they've got some objective test that ranks you accurately, they've got a multi-billion dollar process on their hands. If we had this test, we'd know what to train for, and we'd all become the average developer but write less bugs and better code. It'd become the standard test for developers.

In many cases, companies just want you to sell yourself and hear the right things. Most companies know they can't hire a senior FAANG developer for $110k.

I disagree, solid programmers should be the core of the team. That's how you make solid progress and deliver projects on time.

Programming is about doing the fundamentals well and consistently delivering

Yeah, I think it’s dangerous to try and say that there are 2 groups of people here. Instead, just say we are all amateurs and there’s no reason to take off the training wheels.

I am one of those that can’t get started because perfection and peer review is in my head. I blame it on Stackoverflow making me feel like a moron every time I ask something.

Its a toxic, anti-enlightenment culture, if any question or request for information is perceived as a attack on the self-worth of the author of that piece of information. I think at the root of this perfectionism, are loads of damaged individuals, whos whole identity and self-worth is defined via their work, their code, their child of mind.

There are so many of these, that they can become a culture majority and bring whole projects to a stop. When i encounter these, i tend to isolate them, link up with other reasonable people (who usually also work around them. If they have grown to powerful, you build two versions, one with their "architecture" (which they will inevitable grab and sink years of time into) and one that will be actually shipped, as a emergency solution.

If discussion is not possible, double the project estimate, cause there are two now.

The Dunning–Kruger effect basically. I think we overestimate our ability to judge who, besides us, is a good programmer as well.