TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Bad programmer producing good code

16 点作者 fedd大约 4 年前
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 条评论

100011_100001大约 4 年前
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 未加载
camhenlin大约 4 年前
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
jf22大约 4 年前
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.
andreareina大约 4 年前
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_s大约 4 年前
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.
GianFabien大约 4 年前
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 未加载
aristofun大约 4 年前
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 未加载
sdevonoes大约 4 年前
Good programmers are slow programmers. We are not in a sprint (no pun intended) but a marathon.
评论 #27128375 未加载
sloaken大约 4 年前
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大约 4 年前
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_sid大约 4 年前
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.
bjourne大约 4 年前
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 未加载