I know many a poor programmer. The consistent thread between them is that they don't appreciate the fact that they don't know everything. You may be very well versed in a tech stack, but there are undoubtedly architectural implementations or design choices or algoritms which you simply don't know or haven't considered. A good programmer recognizes the situations where they cannot come up with the best solution and makes the necessary safety changes so that when the best solution does reveal itself, it's easy to swap out the old solution.

Another trait is the belief that they either never need to touch their code after they write it, or worse, only they will ever touch their code. It fires me up to see code that was written with the complete intention of never coming back to it again, despite the fact that it has to be maintained to keep the business running - reports have to use the data it generates, other applications have to use it's services because we can't afford to keep re-implementing everything. I also really hate seeing code that seems like the dev locked themselves up in their basement for a decade to write it. All sorts of custom switches, hardcoded configuration values, experimental tech embedded so deep the only graceful way to relieve that debt is to nuke it.

Why should being aware of how lacking you are as a programmer have much bearing on whether you're good or not?

When I started programming seriously I had a mentor who gave me a long list of my shortcomings. It's taken years of hard, dedicated work to rectify most of those problems and I still have a huge distance to cover to be as good as I want to be.

Being a good programmer is a skillet acquired with hard, concentrated effort over time; not just a good attitude with some self-awareness.

In general, people tend to be overconfident in their beliefs and too slow to incorporate new information. There is experimental evidence to back this up (pdf warning: http://www.researchgate.net/profile/Baruch_Fischhoff/publica...). I think this applies to engineers as well as anyone else.

It is somewhat semantics but there is a big distinction between being aware and unaware of your failings that has a real impact on your output.

OP said "probably not" not "certainly not". Most people do not have a mentor to tell them everything they are doing wrong so they are probably not aware.

> Why should being aware of how lacking you are as a programmer have much bearing on whether you're good or not?

Being aware of what you are lacking allows you to improve on those things, work around those issues and accept when collegue is actually good at stuff you are not good at.

> Poor programmers do things like allowing an incoming request to spin up unlimited concurrent threads. Poor programmers erroneously throw exceptions on any operational deviation - even it if can be handled without error.

All of these examples make sense in the context of your business, but in some environments these might be best practice ;)

There's different levels of concern for a public API and an internal interface. If you control all publishers and subscribers, then you don't need to worry quite as much about sanity checking inputs or making every possible workable input produce a valid result.

> but in some environments these might be best practice

What are those environments? Can you be more specific?

There are plenty of environments where deviating from spec (even when fixing an apparently trivial bug) would not be ok without assessing the situation for potential unintended behaviors.

High-risk systems where a software bug could result in loss of life - aviation, submarine tech, defense, medical etc. Edit: This is for throwing exceptions on undefined behavior.

For unlimited threads I imagine scenarios exist particularly when scalable computing is so popular. Large high traffic web stores such as Amazon/Ebay, financial institutions, etc. Either way, the problem shouldn't be solved by an individual developer on a project making things up as they go - its a problem that probably needs to be defined at a framework layer, and discussed within the team of developers and requirements definers.

I don’t know what they had in mind, but certainly Erlang encourages those sorts of approaches.

Awareness is one important part of self-improvement, but taking the initiative and doing something about it is another thing.

A poor programmer wouldn't be on HN and the point about never learning anything new reinforces that. Most of the article reads like satire.

That's a major assumption. Many get curious when a plumber or other blue collar worker talks on an hn thread. This isnt a secret clubhouse, its a new forum. Just...tech focused.

Getting to that thread regardless of the subject assumes some level of intellectual curiosity (however low that may be). That seems to be the thing lacking among all the worst devs I've had the misfortune of working with.