TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: Bad programmer producing good code

16 pointsby feddabout 4 years ago
What do you think, can it be that some type of bad programmer would write a quality code?<p>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.<p>Their bad part is mostly the speed. Lacking experience, they have to consult with stackoverflow, refactor every now and then and eventually burn out.<p>While the good and fast coder will deliver the working code in hours and days to the manager&#x27;s satisfaction, though not as universal and forward looking (in terms of configuration and integration hooks).<p>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.<p>So what do you think, does this classification make sense, who would you hire and what does the first category need to do?

12 comments

100011_100001about 4 years ago
I&#x27;ve met two types of good programmers.<p>Fast programmers that write something dirty first, and iterate it until it&#x27;s working well. John Carmack is like that.<p>Slow programmers that think about a problem and then write code that covers all scenarios they want to cover.<p>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&#x27;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&#x27;s not going to work within of a few minutes of writing ten lines of code.<p>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&#x27;s not even a good design.<p>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.<p>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&#x27;s in my nature to want to think about solutions over writing dirty code.
评论 #27151482 未加载
camhenlinabout 4 years ago
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 &quot;would I hire this person?&quot; the answer is a &quot;yes, but...&quot; where we need to be very aware of the person&#x27;s limitations and groupings<p>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&#x27;t need a lot of training or hand holding. Generally great to work with unless they are cocky.<p>2. Pilots who are good and they don&#x27;t know it. Pilots in this category have everything going on from the first category, except they don&#x27;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&#x27;s very rare to get one with a lot of ego.<p>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&#x27;re seeing in the OP here.<p>4. Pilots who are bad and they don&#x27;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 &quot;good and know it group&quot;, but they&#x27;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
jf22about 4 years ago
This doesn&#x27;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.
andreareinaabout 4 years ago
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.
评论 #27128041 未加载
matt_sabout 4 years ago
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.<p>As a manager observing people&#x27;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&#x27;t really matter if someone is faster than someone else.<p>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.
GianFabienabout 4 years ago
Perhaps &quot;bad&quot; is not adjective you should use. From your description I would say such a programmer is &quot;slow&quot; and hopefully getting &quot;faster&quot; as they learn and gain experience.<p>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.
评论 #27128302 未加载
评论 #27128066 未加载
aristofunabout 4 years ago
Good programming is not about writing perfect chunks of code or following best practices.<p>Its about making good design decisions. Period.<p>And this is something you can’t google, only accumulate through experience.
评论 #27138793 未加载
评论 #27134217 未加载
sdevonoesabout 4 years ago
Good programmers are slow programmers. We are not in a sprint (no pun intended) but a marathon.
评论 #27128375 未加载
sloakenabout 4 years ago
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.
deeteeceeabout 4 years ago
Your explanation was a bit unclear in the beginning but I think I got the point. From my perspective, you&#x27;re describing two skilled coders (neither bad) but asking about the speed tradeoff, neither being bad.<p>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.<p>Who would I hire?<p>The ideal programmer if I can find it but otherwise, I&#x27;d just hire a mix of both.
dave_sidabout 4 years ago
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.<p>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.
bjourneabout 4 years ago
Why are they bad if they create good code? :) Personally, I don&#x27;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.
评论 #27139558 未加载