Ask HN: Bad programmer producing good code

[fedd]

What do you think, can it be that some type of bad programmer would write a quality code?

They will never try to reinvent the wheel, they will google up the best practices, write in small understandable chunks, thoroughly follow naming conventions in order to not confuse themselves in the future, document everything in comments etc.

Their bad part is mostly the speed. Lacking experience, they have to consult with stackoverflow, refactor every now and then and eventually burn out.

While the good and fast coder will deliver the working code in hours and days to the manager's satisfaction, though not as universal and forward looking (in terms of configuration and integration hooks).

And the coder that I classify as mediocre knows and employs all the programming patterns which makes their quickly written code standard and understandable, but not always working as expected until several testing iterations pass.

So what do you think, does this classification make sense, who would you hire and what does the first category need to do?

[100011_100001]

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.

[enchiridion]

My favorite way to program is a bit like "applied science". Lots and lots of small quick and dirty experiments to test hypotheses, followed by a slower integration period.

[camhenlin]

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

[jf22]

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.

[andreareina]

Speed, readability, function are independent axes of performance and what you prioritize (after reaching some minimum) depends on your current needs. JPL and a consultancy delivering line of business apps are going to want different people.

[fedd]

Thanks! And what's JPL? Do you mean NASA?

[AnimalMuppet]

JPL is Jet Propulsion Laboratory in Pasadena, California. They are a part of NASA, but are a distinct sub-entity.

[afarrell]

Having done consulting for JPL, they do also need people producing line-of-business apps.

But not every role within JPL needs the same approach.

[mattbrewsbytes]

Your question is who would you hire... which is invalid unless you are handing out timed coding assignments as part of your hiring process. That would be absurd and a huge red flag for a candidate in my opinion.

As a manager observing people's work, people work at different paces and come up with different solutions. No two employees are the same. As long as someone is progressing their skills and getting work done in a quality manner, it doesn't really matter if someone is faster than someone else.

In my opinion, someone that thinks they are better because they are faster also has a higher possibility to have an attitude problem on the team which is a bigger issue.

[GianFabien]

Perhaps "bad" is not adjective you should use. From your description I would say such a programmer is "slow" and hopefully getting "faster" as they learn and gain experience.

As @andreareina points out, rate of completing work and the quality of that work are unrelated factors. In my experience many fast programmers turn out low quality work when you consider the amount of re-work their work requires over a period of time.

[username90]

You can't just say that a developer is producing X quality and Y speed. Everyone can go faster by sacrificing quality or improving quality by going slower. I've never seem one of those "slow but writes good code" people, if you code slowly you will have less experience delivering products and therefore most likely produce shoddier work in the end. I have seen "really fast but reduces their pace to produce quality" though.

[100011_100001]

I am one of those slow programmers that writes good code. My manager used to say that any dates I give him, he has to multiply by 2 or 3. However he knows that any code delivered has no bugs whatsoever. I just checked and I had 4 defects found against my code for the entire last year. I completed about 70 features of varying complexity.

Here is the kicker, I completed the most features out of anyone of my team. What happens to them is they finish a feature and within a few sprints they have at least a couple of defects they have to address from their own code. So their feature + defects ends up taking longer than my feature coding speed.

Having said that in 2020 I started to try to devise strategies to iterate faster, mainly because I felt I could optimize my thinking process since I knew that I had mental loops I would get stuck in trying to solve a problem.

Of course this is just my personal experience.

[fedd]

Yes, though in my experience managers never ask programmers to work slower to increase quality... :)

[aristofun]

Good programming is not about writing perfect chunks of code or following best practices.

Its about making good design decisions. Period.

And this is something you can’t google, only accumulate through experience.

[fedd]

I would agree but I am adding the people that pay for the coders work into this equation ("managers"), and they need function in time. Some (most?) of them seem to consider the design decisions the coders problem. It's in the coders interest to make the code easily expandable, integrable, reusable, readable, to make the coders life easier, to allow them to easily meet the business goals.

Of course every programmer would like to make the best design, but sometimes there's no time for it, and that's when slow/fast/experiensed characteristics come into play

[afarrell]

> only accumulate through experience

You need both experience and also reflecting on that experience —-- usually in a social process.

[fedd]

You say "usually", so I assume googling forums for similar design decisions and having internal discussion within myself can count, without having a crowd of fellow programmers physically beside you? If you're capable to hold such an internal reflection, then basically you can "google for experience"

[aristofun]

“Internal discussions with myself” can be helpful. But on their own they will never get you very far.

Unless you’re already very experienced and talented to build your own unique path.

[afarrell]

It depends on the quality of the conversation

[aristofun]

I consider it a part of experience process

[afarrell]

Which is reasonable. I’m making it explicit for the sake of the perplexed.

I’ve found myself previously asking, “how do I learn to estimate?” Only to hear, “by experience”. It left me thinking for many years that I couldn’t also learn by having conversations about people’s experiences.

[sdevonoes]

Good programmers are slow programmers. We are not in a sprint (no pun intended) but a marathon.

[username90]

Marathon runners are really fast though.

[sloaken]

I think it is a multi dimensional problem. You have programmers who are insightful, and those that need insight provided. You have fast and slow. Ones who document their design and code, and those I have a name I do not use in polite company. You have ones who do a great job exploring a customers detailed needs. Others who are good at debugging other peoples stuff. I am sure there are more aspects that you can rate people on. As to which to hire, depends on availability, money, and need. Do not hire a super star if you need a help desk techie.

[deeteecee]

Your explanation was a bit unclear in the beginning but I think I got the point. From my perspective, you're describing two skilled coders (neither bad) but asking about the speed tradeoff, neither being bad.

I try to be that ideal programmer that switches between being both the fast or slow programmer and situationally adapts depending on the climate of the product and the company.

Who would I hire?

The ideal programmer if I can find it but otherwise, I'd just hire a mix of both.

[dave_sid]

To equate slow as bad right off the mark is a bit of an odd premise. I’d rather have a slow surgeon work on me that was meticulous and precise than a fast one that got the job done quickly but left in a few bugs.

It might be that the slow programmer more than makes up for the time by saving hours, days or weeks of tester’s and support team’s time further down the line.

[bjourne]

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.

[fedd]

Because they miss deadlines. Of course we can characterize the developers differently. I am considering the employer perspective

[bjourne]

Then you are using a metric that doesn't tell you much about the quality of the programmers.