In my experience, this is highly subjective.

One of my employees was probably the best coder I’ve ever known. His code was well-structured, well-documented, clever, efficient, bug-free, and a total bitch to comprehend. He would regularly produce miraculous results. We worked together for almost 27 years.

I guarantee that a lot of folks here would call him a “bad coder,” because they would have difficulty easily understanding his code.

I find that when people talk about “good,” they emphasize traits that they, themselves, have, and disparage traits that they don’t have.

In the aggregate, results matter, and “results” are more than just getting today’s goals accomplished. It would be nice if that were the only concern.

For example, I ran a shop, where we maintained a huge legacy codebase of C++ image processing code. We had to maintain it, ourselves, as well as train others to work on it. This meant good documentation, good code structure, and good foundational substrate.

Introducing new coders to our codebase meant immersive training. Japan regularly sent folks over for months, to learn our code. These were top talent. Just about every one of our Japanese engineers had at least a Master’s degree in Engineering. It was a marquee corporation, and employed top-shelf engineers.

That’s quite different from hiring bootcamp-trained JS programmers, and expecting them to maintain Swift code. I know many people that insist that “any good engineer” can learn any language in a couple of weeks.

I’ve been at this game for a while, and have worked in quite a few languages. I’m smarter than the average bear, and have made fearful messes, because I didn’t understand the tools completely.

I have found that I can learn about 75% of a language quite quickly.

That other 25%, though, could take years, and languages seldom stay static, so I’m constantly catching up on the latest stuff. It also includes style, which is often an artifact of understanding how to use the language properly.

Also, learning a language is only part of it, as the APIs and SDKs are even more important. Learning those can be difficult, and I have often had to throw away years of work, when an SDK is swapped out. I’ve been writing Apple software since 1986, so I’ve had to do that a number of times. My first Apple code was in procedural Pascal and 68000 ASM. Adobe Photoshop is probably one of the oldest codebases still in use, and it started off as object Pascal, using MacApp 0.9 beta.

Tom Knoll was definitely top-shelf, and I was tasked with adapting some of his code for use in a different context, back in the 1990s. It wasn’t easy, but I did it, and learned to be a better coder, as a result.

Over the years, I have changed my opinions and points of view; frequently by screwing up, and also, by taking the time to understand code -and not just code, but also the reasoning-, of talented predecessors.

I remember once, hearing someone say “That ‘cruft’ you’re complaining about, is what I call ‘bug fixes.’”

I love coding, because I’m constantly challenged and humbled. I stand on the shoulders of giants, and am grateful for their example.