Ask HN: Bad programmer producing good code

I've met two types of good programmers.

Fast programmers that write something dirty first, and iterate it until it's working well. John Carmack is like that.

Slow programmers that think about a problem and then write code that covers all scenarios they want to cover.

There are advantages to both styles. Both styles have disadvantages as well. Fast programmers sometimes have the tendency to not deal with details, so their code works but it's not bug free. On the other hand slow programmers might spend a long amount of time thinking about a solution and then realize it's not going to work within of a few minutes of writing ten lines of code.

In a way, bad programmers as also fast or slow, but the disadvantages of those approaches outweigh their programming ability. So they either write really dirty code or take ages to finish something and it's not even a good design.

Due to agile and probably human nature fast programmers seem better. You know, the dev that did the thing in one weekend. Think about Linus Tovarlds writing git in a week or two. Sounds amazing, yet it had to be iterated a lot and it still suffers from some of the decisions made in those two weeks of initial development.

For the record I am a slow programmer, but I have devised systems to help me speed up to appear like a fast programmer when it's in my nature to want to think about solutions over writing dirty code.

This doesn't make any sense to me. I know fast coders who need to consult Stackoverflow and good coders who refactor all the time. You set up several false dichotomies.

I had a pretty good buddy who was a retired helicopter pilot in the Marines, and he, many times, told me there are 4 groups of helicopter pilots that most people fit into. I think that there are strong parallels in software dev (and other fields!) and it might be useful to chat about here. One thing to note is that through training people can move between these categories, nothing is permanent. I think if you look at any of these groups from the perspective of "would I hire this person?" the answer is a "yes, but..." where we need to be very aware of the person's limitations and groupings

1. Pilots who are good and they know it. These are people who are naturally good pilots: memorizing the checklists, failure states, what to do in bad conditions, etc come very naturally to these people and they don't need a lot of training or hand holding. Generally great to work with unless they are cocky.

2. Pilots who are good and they don't know it. Pilots in this category have everything going on from the first category, except they don't realize how good they are. Often times, these can be the best pilots to work with, because they stick to all the checklists, procedures, manuals, policies, and so on, because they know that they might not know what they are doing, and on top of that they can shine in tough situations because they are in fact good pilots. These pilots are great because it's very rare to get one with a lot of ego.

3. Pilots who are bad and they know it. These are people who are aware that they are not naturally strong pilots, and their awareness leads them to following checklists, spending lots of time reading manuals, procedures, policies, to a T. In most situations, these are very good pilots to work with because they are aware of their own limitations although they may need more training for bad situations. Again, there is often very little ego here. I think this is the level of awareness that we're seeing in the OP here.

4. Pilots who are bad and they don't know it. This is the worst group of pilots to work with, but they can be fixed with training and guidance from senior pilots. Often times if you asked a pilot in this group, which group they fit into, they would tell you they fall into the "good and know it group", but they're wrong: they might be skipping checklist items, missing key policies, or just generally be a bad team mate. I would liken this to a junior or mid level dev who thinks they know everything. Often times there can be a lot of ego in this group

Why are they bad if they create good code? :) Personally, I don't think classifying developers as you do works. I think it is very one dimensional.. Like ELO ratings in chess. Good coders are good at everything, bad coders are bad at everything.

I consider it a part of experience process