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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Should you code well or code fast?

15 点作者 andyford超过 11 年前

13 条评论

jdlshore超过 11 年前
This wasn&#x27;t a very good essay. The closing line sums up its problem: &quot;We need to complete quality work in the shortest amount of time possible.&quot; Why, yes, I would like a double helping of pablum! Thank you for offering. You know, before now, I thought it was best to complete quality work in the <i>longest</i> time possible.<p>Sarcasm aside, the most telling line was this one: &quot;If the project is for a three-month campaign that must be completed next week, the shortest path to the finish line is probably best. I&#x27;ve only been a developer for five years, and 95 per cent of my professional projects are [like that].&quot;<p>This essay was written by a developer at BKWLD, an &quot;independent digital agency.&quot; They do a lot of advertising work. Of <i>course</i> code quality doesn&#x27;t seem important! Code quality matters when you have a team of people developing and maintaining software over a long period.<p>Here&#x27;s a more nuanced view: speed matters, and you can be really successful developing important, business-critical software by emphasizing speed over quality. If it&#x27;s a problem domain you&#x27;re particularly familiar with, especially if you have a lot of tools, frameworks, and libraries to help you, you can get an impressive amount of work done.<p>As you continue to work, you&#x27;ll slow down. At some point—about six weeks is my guess—you&#x27;ll actually be going slower than someone who&#x27;s focused on quality. They&#x27;ll speed up over time (asymptotically), and you&#x27;ll continue to slow down (also asymptotically). You&#x27;ll still be ahead of them, though, because you got so much done in that initial burst of energy. Your life will start to suck, though, and you&#x27;ll be looking forward to when the project is done.<p>Eventually—about three to six months, I&#x27;d guess—you&#x27;ll fall behind. You&#x27;ll be going so slow that your initial advantage will have been erased. Luckily, you now get to hand the project off and start a new one. Win!<p>Three to seven years later, your code will be thrown away. It will be so expensive to change that it no longer makes economic sense to maintain. If it&#x27;s still relevant, it will be rewritten at great expense and even greater opportunity cost.<p>So, does quality matter? Depends on who you ask... and who ends up paying for it.
评论 #6902178 未加载
评论 #6900145 未加载
davesims超过 11 年前
Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code.<p>Words like &#x27;clean&#x27;, &#x27;elegant&#x27;, &#x27;well-structured&#x27;, even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death.<p>Here&#x27;s an example from this essay:<p>&quot;There is a reason good code is considered to be a form of poetry. It&#x27;s elegant, clean, easy to read, and fun to write. These are all exceptional qualities that we should strive for every single day.&quot;<p>Try telling a product manager or CEO or other stakeholder how &#x27;clean&#x27;, &#x27;easy to read&#x27;, or -- God forbid -- &quot;fun!&quot; your code is, and watch their eyes roll back in their head. (I exaggerate for effect.)<p>These ideas make sense to us as developers because that&#x27;s what we spend our entire day doing: considering, reflecting and thinking about code. But I think what we should be talking about is the inherent <i>speed</i> of the codebase. I&#x27;m not talking about my velocity as a developer, or the velocity of the team and how many story points they deliver per sprint, but the inherent velocity of the codebase as a function of its technical debt. Codebases, from a business standpoint, should not be &quot;clean&quot; or &quot;dirty&quot;, but rather &quot;fast&quot; or &quot;slow&quot;.<p>Technical debt should be surfaced to the stakeholders using language that conveys the dollar value, the fiscal liability, of technical debt. The most accurate way to describe that and show how debt is slowing your team down, is to talk about its inherent speed.<p>&quot;Our codebase is getting slower&quot; makes business sense to a Product Manager. &quot;Refactoring this will make our codebase faster&quot; is a phrase that conveys the worth of initiatives that otherwise seem to have no immediate effect on the bottom line.<p>All of the tools and agile methods we have talk about velocity in terms of what a team is delivering, and can parse that down to the sprint and developer level. But in my experience, the most significant contributor to a team&#x27;s relative speed is the (intertia|speed|velocity|momentum) of the codebase itself, as a function of its technical debt. I think we need to start using language that intuitively and constantly surfaces the dollar value of technical debt to the stakeholders, so that &quot;just ship it!&quot; no longer sounds like a sound business strategy.
评论 #6902496 未加载
评论 #6901846 未加载
jinxedID超过 11 年前
Slow is smooth and smooth is fast
评论 #6899663 未加载
评论 #6900276 未加载
评论 #6899749 未加载
redact207超过 11 年前
Answer: learn to do it the right way and you&#x27;ll end up coding faster.
评论 #6900575 未加载
DrinkWater超过 11 年前
When a question asks whether to do A or B, you know the answer is: &quot;it depends&quot;<p>Just use your brain, use your judgement on the result, make a decision, iterate.
评论 #6900959 未加载
mpermar超过 11 年前
The best way to code fast is to code well.<p>When your code sucks or you intentionally code fast you end up adding tons of things that will drag you over and over again. And unavoidably you&#x27;ll end up asking yourself &quot;why didn&#x27;t I code well. I would have ended up much faster&quot;.
wafuru超过 11 年前
The best developers I know have the experience to know when each is required. Getting the right balance between speed and quality is one of the things I find hugely valuable in a developer, usually more so than their maximum coding speed or maximum output quality.
评论 #6900923 未加载
JackMorgan超过 11 年前
I give some actual advice and suggestions on learning to become a faster programmer here: <a href="http://deliberate-software.com/quality-is-future-speed/" rel="nofollow">http:&#x2F;&#x2F;deliberate-software.com&#x2F;quality-is-future-speed&#x2F;</a>
ndhoa超过 11 年前
I think code visibility is more important (intention revealing). It allows you to move forward (with proper abstraction) while still provides a chance to refactor later. DRY and Boy Scout Rule should always be honoured.
Teapot超过 11 年前
&#x27;Release early, release often.&#x27; This suggests quick and dirty code is better than slow and mature code.<p>Though worse code benefits the most by having well-enough made Comments.
alexrson超过 11 年前
My favorite pithy insight on this subject is from McConnel&#x27;s code complete (mangled, most likely):<p>&quot;Code is usually read more times than it is written.&quot;
amagumori超过 11 年前
por que no los dos?
samnardoni超过 11 年前
Yes.