Ask HN: Bad programmer producing good code

#1

Post by fedd » Wed, May 12, 2021, 5:14 AM UTC

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?

Re: Ask HN: Bad programmer producing good code

#2

Post by andreareina » Wed, May 12, 2021, 5:36 AM UTC

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.

Re: Ask HN: Bad programmer producing good code

#3

Post by chaganated » Wed, May 12, 2021, 6:18 AM UTC

I think this is kind of a jumble. For example, these are all hallmarks of very good programmers:

> 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.

Next one is more of an IQ issue than good/bad. If my situation isn't time sensitive, and the slow guy is careful, and I can get him at a much lower rate...

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

This part is loaded with combinatorics. How well does the manager understand his market? His product? Is it a feature, or a misfeature? I think we all have stories of managers signing off on time-bombs, and missing the mark on where the market's at. Having the good programmer take a few hours implement a feature sounds great, until the better programmer comes along, and takes five minutes (and no code) to prove that the feature was a mistake. The only true measure of performance, is performance.

> While the good and fast coder will deliver the working code in hours and days to the manager's satisfaction

I think following part is a credit rather than a demerit. Read up on second system syndrome, or anything Chuck Moore has to say about programming. Solve the real problems, not the hypothetical ones (which may never materialize).

> though not as universal and forward looking (in terms of configuration and integration hooks).

Here is where I would use the word bad rather than mediocre. When they resort to empiricism out of an aversion or inability to think things through, it will never be right -- even if it passes all of the tests.

> 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.

I'm not a big fan of meta and abstractions. A lot of good signal gets thrown away. I like demos.

Re: Ask HN: Bad programmer producing good code

#4

Post by GianFabien » Wed, May 12, 2021, 8:03 AM UTC

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.

Re: Ask HN: Bad programmer producing good code

#5

Post by fedd » Wed, May 12, 2021, 8:27 AM UTC

andreareina wrote: post #2

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.

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

Re: Ask HN: Bad programmer producing good code

#6

Post by fedd » Wed, May 12, 2021, 8:31 AM UTC

GianFabien wrote: post #4

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…

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

Re: Ask HN: Bad programmer producing good code

#7

Post by sdevonoes » Wed, May 12, 2021, 8:37 AM UTC

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

Re: Ask HN: Bad programmer producing good code

#8

Post by username90 » Wed, May 12, 2021, 9:15 AM UTC

GianFabien wrote: post #4

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…

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.

Re: Ask HN: Bad programmer producing good code

#9

Post by username90 » Wed, May 12, 2021, 9:29 AM UTC

sdevonoes wrote: post #7

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

Marathon runners are really fast though.

Re: Ask HN: Bad programmer producing good code

#10

Post by mattbrewsbytes » Wed, May 12, 2021, 11:58 AM UTC

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.