31 ms·

Working quickly is more important than it seems (2015)

513 points by cal85 3y ago

ed 3y ago
https://web.archive.org/web/20230602051336/http://jsomers.net/blog/speed-matters https://web.archive.org/web/20230602051336/http://jsomers.ne...
snapcaster 3y ago
Site not loading for me :(
- havnagiggle 3y ago
  Have you tried loading it faster?
- tobr 3y ago
  Which is a little ironic considering this quote from the article: > It’s now well known on the web that slow server response times drive users away. A slow website feels broken.
  - paulddraper 3y ago
    I was just about to give up when it finally loaded
- michalstanko 3y ago
  I guess the author did the website too quickly.
bredren 3y ago
(2015) https://archive.is/2019.08.06-012000/http://jsomers.net/blog/speed-matters https://archive.is/2019.08.06-012000/http://jsomers.net/blog...
xrd 3y ago
Nice article. This is basically in the article when they talk about email responses back and forth, but not explicitly called out: if you are fast, people that interact with you get faster, too. Toyota figured this out with kanban (https://en.wikipedia.org/wiki/Kanban https://en.wikipedia.org/wiki/Kanban) and revolutionized process thinking. So, if you are thinking about how to get your team to work faster, focus on what is making slow team members go slowly.
deleted 3y ago
[deleted]
garrickvanburen 3y ago
From my perspective - speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome. Over my career, I've been surprised multiple times when I presented early draft to a stakeholder and they said, "oh, that's great, I've got what I need now"...and this was maybe 1/3 of the effort I was planning for. The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important. Along these lines, in my work with stuck startup founders, I often ask, "if we were going to demo a prototype to a customer (in 2 days | at the end of the week), what would it be?"
- Zetice 3y ago
  I cannot possibly emphasize this more strongly. It's so important to deliver complete and working products quickly and regularly, that it's worth the cost of the occasional lost customer who leaves because all of their needs aren't met immediately. A) they're rarer than people seem to think and, B) the people you gain due to this incremental approach more than cover the losses. That said, some devs interpret "quick" to mean "sloppy", which is not correct. When you can cut releases hourly the cost of some kinds of bugs does go down, but fewer bugs is better, and as always some categories of bugs are, "never, ever" (e.g. data corruption/leak, security bugs, outage inducing bugs).
  - afarrell 3y ago
    To go fast, stay humble and use boring technology.
    - j45 3y ago
      .. in a simple and flexible way.
  - andai 3y ago
    I agree completely. That sounds much better than my current strategy of delivering incomplete and broken products at unpredictable intervals.
sublinear 3y ago
As the article states, this only works for stuff that can be broken up into low effort chunks. Not everything is like that such as maintaining legacy systems or working with large teams. :)
- commandlinefan 3y ago
  > Not everything is like that In fact, almost nothing that's actually _useful_ is. Anything that can be broken up into predictable low effort chunks is something that can be automated away.
  - 0xbadcafebee 3y ago
    If you can automate away programming, there's some people who would like to give you a lot of money.
    - CatWChainsaw 3y ago
      I doubt whatever severance they get can last them the rest of their lives.
      - hgsgm 3y ago
        It's not 1 severance, it's 1 million.
        CatWChainsaw 3y ago
        Unless one person is getting one million severances, they'll outlive it.
    - sublinear 3y ago
      I don't think that's what the parent to your comment was about. You can't automate away programming, but you can write one program that behaves equivalent to many that accepts configuration from people who don't know how to program.
gen_greyface 3y ago
related: Some reasons to work on productivity and velocity https://news.ycombinator.com/item?id=28882043 https://news.ycombinator.com/item?id=28882043
alexfromapex 3y ago
Compensation plays a big role in how fast I'm willing to get something done
- ukuina 3y ago
  Doesn't compensation follow good/fast work, not precede it?
  - TinyRick 3y ago
    That has not been my experience in modern corporate America.
  - AA-BA-94-2A-56 3y ago
    Sometimes, but not always.
jmclnx 3y ago
When it comes to business (corporate), you hear "do it right". But in reality that means "do it fast even if wrong". If mistakes are made, what happens depends upon management. In most cases, I have seen people who do a project 100% correct, sometimes slightly slower get ignored. Other people who get it done fast, even with many blaring mistakes, get rewarded. Usually the people who worked on it end up working 24/7 to get it fixed. That is looked upon by most managers as very good work. If your projects go live without issues, it is usually forgotten, people who fix their own issues by putting in fixes after go-live by working 24 hours, get noticed and rewarded.
- inconceivable 3y ago
  graphic designers sometimes ship their draft deliverables with 1 or 2 obvious bugs, and allow the customer to recommend these 'changes' on their own for final delivery. and if they don't, they're just fixed for final delivery anyway. i read about it before i had this done to me for the first time, and i played along with it. it's a neat trick because it's plausibly deniable for everyone involved and the outcome is good while minimizing the bullshit work in favor of a sacrificial final word.
  - politician 3y ago
    There is a concept of a sacrificial feature to prevent customers from becoming fixated on other aspects of the design that would actually create problems if changed. I prefer to avoid that sort of dark pattern though because it erodes trust.
    - CrazyStat 3y ago
      "The Queen's duck" https://bwiggs.com/notebook/queens-duck/ https://bwiggs.com/notebook/queens-duck/
  - garrickvanburen 3y ago
    I’ve also done this, with both visual design and software. It’s a deliberate canary - if the client didn’t comment on the obvious mistake/bug, I know they didn’t actually look at it.
Slower-McSlower 3y ago
[flagged]
allenu 3y ago
Speed is underrated. I've worked on a lot of side projects and for a long time I couldn't get them done. I spent too long "perfecting" baseline things like folder structure (really) and overall system design. This made things slow-going and I tended to abandon them. Over time, I started just hacking things together and shipping them, worrying less about perfecting those initial things. (I used YAGNI a lot in my decision-making.) What I learned is that there were so many more things I had to do and had to learn to do to ship. I could only get to those tasks and learn those skills by "skipping" through the earlier tasks. Working quickly helped. I started thinking of projects as this vertical stack of work that you move up from bottom to top. If you could look holistically at absolutely everything you needed to do to ship a project, you could mark some as having a larger impact on the success of the project than others. Those are things that require more time and energy. When you move slowly, you have a very small scope of the overall project, just stuff at the bottom, and predictions about the future. You may not really know what's ahead. If you go slowly and try to do everything perfectly down there, you spend a lot of energy on a small subset of tasks which may actually have smaller impact than something in the middle or towards the end. Speed allows you to move through those early tasks move towards a more holistic view of the entire system so that you can determine which are high impact and which are not. You might need to double-back on an earlier task if you misjudged something as low-impact and ended up spending less time than you should on it, but at least you're not pouring energy into low-impact tasks on average. It's not quite the same thing, but building a prototype is a good example of learning the end to end of a system without worrying too much about quality. It gives you an initial idea of what's possible and you use that to get a better picture of what's high and low impact in a project.
- hot_gril 3y ago
  This is all true. The SWEs I work with in a corporate environment don't get it, but the managers do.
- deely3 3y ago
  Am I right that you are talking only about quick creation of something new and not about long term support of created system?
deleted 3y ago
[deleted]
andai 3y ago
https://archive.ph/jl4oc https://archive.ph/jl4oc
0xbadcafebee 3y ago
From a DevOps perspective, speed is often the indicator that you're doing things right. If you integrate code quickly and often, if you deploy quickly and often, if you patch and upgrade software quickly and often, if you detect, diagnose and fix issues quickly and often, those are all indicators of a high-performing team. Quality isn't always correlated, but high-performing teams tend to care about quality, so it's not uncommon to add quality improvements to the list if you're doing everything else.
- tstrimple 3y ago
  We tend to get better at the things we do often. Companies which have annual release cycles are almost always terrible at actually shipping software in my experience. One of my first goals in any new organization is improving iteration / feedback cycle speed.
- mobiuscog 3y ago
  I think that part of the problem is companies/executives/manager who think that teams need to 'do' that in order to become high-performing rather than, as you stated, it's an indicator. There needs to be a suitable environment, skills/training, support framework and everything else around to enable the team to become high-performance over time, that when starts showing that indicator. Correlation not Causation. All too often these are mixed by those who read the books that offer 'Acceleration' and think that enforcing these processes will somehow make the team fit.
dmbche 3y ago
Just a note : I've noticed that when working with management, they often have issues "grokking" the issues they are asking for you to solve. By offering an imprefect, quick solution, it lets them understand the issue and readjust their needs in consequence - and often, the quick imprefect solution is good enough/enough work to show it's a bad idea and to move on. When starting project I have 2 steps : vomitting and touching up. You puke out a solution(minimum viable product), without thought about optimisation. When that exists, you change hats and optimise. Works wonders.
- Culonavirus 3y ago
  Except the reality often looks like: > You puke out a solution(minimum viable product), without thought about optimisation. And that's where it ends, because unless your employer vastly overhired, there's already a dozen (or more...) of tasks in the backlog just waiting for you to vomit them out as well. After a year or two of working like this, you have a mountain of technical debt and no time work on it all. The entire system slowly disintegrates under its own weight. There needs to be a balance between fast and correct, and it is only up to the developer to resist the pressure from management to work fast (at the expense of correctness). I would go as far as to say that it is one of your main non-technical duties as a developer to resist and manage this pressure as best as you can. Maybe you're a genius who can analyze problems and implement solutions both fast AND correctly, but that is very rare. The truth is that complex problem solutions can have complex, messy implementations. They can also have simple, beautiful implementations. Or anything in between. But what they almost invariably require is complex investigations... which take time to conduct properly. Most (not all!) "fast" programmers I've worked with over the last 15 years produced output of questionable quality, often stemming from the "what you don't know you don't know" part of the knowledge pie chart, instead of some deeply thought out cost/benefit calculation.
  - georgeburdell 3y ago
    IME fast programmers are great at externalizing their QA
    - 3y ago
agentultra 3y ago
I wonder how the author thinks about this now, 8 years later. Way back in 2016/2017 I saw this video on prototyping where the programmer whipped up a snake clone in around 4 minutes. I deliberately practised programming in this way: how fast can I go from idea to working prototype? Code style, organization, testing, best practices be damned: you have about how long it takes to run a load of laundry, how much can you get done? I did this for a few months. I focused on games. I roughly tracked how much time it took to get from empty file to the first interaction with the game. I tried to focus my practice on getting to that first interaction. And the overall time I spent and how far I got with the idea. The thing with going that fast is... the code sucks. You're not writing it for an audience, for your future self, to make it possible to extend and compose; when you want to go fast and prototype in this way you're deliberately not going to use this code for anything later on. You just want to get the idea out there to see, "is this even fun? Would it even work at all?" ... before you go ahead and spend the next 6 - 12 months spending your limited time on something. Because finding out your game isn't actually fun after all of that effort is demotivating. In this sense speed is useful. It's useful in certain contexts when doing programming on the job. Especially at startups where the runway is limited and you don't know if you even have customers yet. However! Be prepared to throw it out. Once you find some traction for a feature or process; throw out the prototype/MVP code. Make sure it's cheap to do that: you can write software that is loosely coupled, you can write a better API that uses the MVP code underneath, write good tests against the new interface, remove the old code paths piece by piece, etc. If it's a core part of the product and there are customers for it get rid of that prototype/MVP code some how (it's easier to plan for this and not get too attached to the first iteration if you do it intentionally).
- syntheweave 3y ago
  Agreed - There's a certain thing about greenfield development in particular(which is quite fully the realm of startup coding) where you have to approach the first, second, maybe third iteration as one that will be thrown away, so when it does get thrown away, you make it easy to do so. And that leads towards some pretty dumb code, often "copy-paste-modify, sort it out later" code. A lot of "best practice" ideas that get made into blogposts impose a structure that hinders disposability in favor of a certain aesthetic goal: to do the thing with less repetition and slightly cleaner abstractions. The goal is often not unreasonable, but it conflicts with the action of rapid iteration. So I tend to write now with an eye towards trying to keep the code disposable until I face a certain class of error to eliminate, that needs the more abstract method. Often part of the disposability is in not actually solving the entire problem, but cheating and returning a wrong answer, e.g: Instead of fancyAlgorithm() being written in a way that creates any dependencies I write a skeleton "function fancyAlgorithm() {return true;}" and then later upgrade it to a lookup table, and then to the algorithm. Because most of the code that matters to the app won't be in the algorithm, but in how all the other data is being passed around. The sooner I can get that piece to return a wrong answer with known error, the sooner I can arrive at a complete but wrong app, which can be corrected into a higher quality one. When not all the pieces of the app are there, it's not clear what error you need to be solving for, which leads to squeezing effort onto code that isn't important.
divbzero 3y ago
Related: Speed matters: Why working quickly is more important than it seems - https://news.ycombinator.com/item?id=10020827 https://news.ycombinator.com/item?id=10020827 - Aug 2015 (139 comments) Speed matters: Why working quickly is more important than it seems (2015) - https://news.ycombinator.com/item?id=20611539 https://news.ycombinator.com/item?id=20611539 - Aug 2019 (172 comments)
tabtab 3y ago
The CRUD IDE/Stacks of the late 90's were closer to the domain and that was a large reason for the productivity I used to see: more done with less key/mouse-strokes and less code. Web stacks make one waste time fiddling with janky stack parts & layers instead of domain logic, where it SHOULD be spent. It's hard to match their productivity with current web stacks, often requiring specialists and/or big learning curves. (Sure, the 90's IDE's had their warts, but were getting better with time, until web murdered them. And I'll limit this to small-and-medium apps rather than enterprise/web-scale.) It's usually assumed the features that made them productive are mutually exclusive with web-ness. I'm not convinced; the industry just stopped experimenting. What would help is a state-ful GUI markup standard so that GUI's don't have to be re-re-reinvented via HTML/DOM/JS, which is inherently ill-suited for rich CRUD GUIs. Having your language/tools/standards being a close fit to the domain matters. It's why COBOL lives on despite being even older than me. I'm not saying we should mirror COBOL as-is, only that it still carries important lessons, including FDD: Fit the Damned Domain.
bern4444 3y ago
Speed matters when the thing being built is isolated. If you're building a new feature/product whatever, and the business views that both as a standalone feature, but also as a stepping stone to support another product or feature then the code you get when writing quickly is going to slow you down in that next step. Scale that up a few levels and you end up with 'enterprise code' that no one wants to touch for fear of breaking all the parts that depend on the pieces below it. So write code quickly when its isolated and not planned for use in additional products, features, capabilities. It is very difficult to convince management to prioritize tech debt and the only successful way is in the frame of enabling additional product capabilities.
- hot_gril 3y ago
  If you're building a stepping stone, you still have to figure out how to make it isolated in a way then do it quickly. Like if it's a software service, spend the extra time figuring out a good API then speed through the initial implementation.
maerF0x0 3y ago
When folks speak hypothetically about speed, they almost always assume identical outputs. Which is pretty contrary to at least my experience, if not reality. Apple is the worlds most valuable company, and they're first and fastest in essentially nothing. So it really depends on the market you're going after. Anecdotally, (and backed by language learning research iirc), when learning is involved iterations are important. Learn a little, practice a little, get feedback a little, repeat frequently. But afaik it all comes down to the cost of failure. Public iteration on your encryption algorithm that's guarding billions of dollars is probably a bad idea.
painted-now 3y ago
Being fast and iterating reminds me so much of the EM algorithm. Probably a bit of a stretch but still: You start with an initial estimate of the hidden variables (solution), check what the consequences are by implementing it, and apply the knowledge about the right consequences to improve the solution.
Sharlin 3y ago
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails. > It is a truism, too, in workplaces, that faster employees get assigned more work. Maybe there's irony I'm failing to perceive, but how exactly are these supposed to be good things from the fast worker's viewpoint? The truism is that working quickly is only rewarded by being assigned more work that's expected to be done even faster, which is a vicious circle if ever there was one!
perlgeek 3y ago
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails. This is why I intentionally wait before answering emails that aren't related to my core responsibilities. I want fewer of these, so I best not establish a reputation as somebody who quickly provides an answer to everything. Got other things to do :-)
heisenbit 3y ago
> Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon. You aren’t “using them up” by giving them work. Well that is not always true. Producing results is one thing, making sure you learn enough in that process is another. Managers eager to cram down one micro manage task after another will use up a persons knowledge without restocking it. Yes faster can be better as lot‘s of people agree here with but there are limits.
lars512 3y ago
I think about this another way. If you're fast enough, you can afford to do the gardening you need to keep your codebase in a good way without having to schedule it all in. If you're fast enough, when doing data analysis, you earn the space to ask the next question, and the next, and to do a deeper analysis. But... as a lead, I've struggled to train speed before. Some people I've worked with have had it, junior or senior, and some have not. Has anyone had good experience helping others become faster at their work?
- iamcasen 3y ago
  No. I think humans are all unique. Just like a pro basketball coach, you are looking for the right talent for your particular team and your particular context. I have had extremely smart, talented, thorough engineers who are slower than whale shit in an ice flow. For a startup, those engineers are a death sentence. It doesn't matter how good they are, if they aren't fast, they hold everyone back. Are you building the roman empire, or are you building a small group of bandits that move swiftly through the night? Each case has it's corresponding strategy.
karaterobot 3y ago
This is kind of conflates the idea of a person doing a job quickly, and the idea of tools having low latency/quick response, which confuses the issue if what you care about is working quickly — the bottleneck for work is usually the speed of our thinking, or the limits of our motivation to work. But, it's usually not the speed of our tooling. You wouldn't become a better programmer with a faster computer, and usually not a more effective one either. I'll ignore the second definition. In my opinion, you want to spend about as much time as ever, but spend more of your time working on something that is close to a solution. So, you want to work on the first draft as quickly as possible, so you can either refine it, or toss it out and do another iteration. The advantage is overall quality and confidence in your solution. For reasons mentioned in the article, I do not prefer to be thought of as working quickly and well, since that often means someone sees your first draft and says "great, looks like you're done, now let me give you something else to work on". Better to have a reputation for taking about as long as most people, but producing better results.
- epolanski 3y ago
  > You wouldn't become a better programmer with a faster computer, and usually not a more effective one either. Disagree, any time I have to wait for tools is a tragedy. I've definitely became much more productive at each computer upgrade.
cosmiccatnap 3y ago
I always see arguments for working faster. Never arguments for taking your time to get solutions correct even if it doesn't produce something immediately visible. ...I'm sure there is no economic correlation
- hgsgm 3y ago
  Being more productive is more valuable and profitable. "Correct" doesn't sprout fully grown from your head like Athena from Zeus
  - mobiuscog 3y ago
    Valuable and profitable for investors, or society ? Because absolutely not both.
0x6461188A 3y ago
I agree with his points. The question is: what are some ways of working fast without being sloppy? Would be interested in how people here do it.
- hgsgm 3y ago
  1. Slow is smooth and smooth is fast. Don't rush and crush. 2. Practicing to get faster at the nitty gritty boring details, relying less on your reference materials, is as important as the big ideas.
sashank_1509 3y ago
Consistently I see this advice from everyone who I consider has achieved outside success in their field. Greg Brockman (OpenAI Cofounder) : Developer Speed is the most important thing I care about: (https://www.youtube.com/watch?v=CqiL5QQnN64 https://www.youtube.com/watch?v=CqiL5QQnN64). I believe he said more about this topic but I can't find it now. Frank Slootman (Snowflake CEO): In his book Amp It Up, he stresses why pushing people to move fast is extremely important Elon Musk (Let's not get into a debate about Elon and just agree that he has helped setup 2 100bn+ companies) : "I believe in maniacal sense of urgency, if you can implement something right after the meeting, do that", upon his work philosophy when taking over twitter. In my personal experience one of the most impressive coders I met, worked extremely fast while also being very accurate, almost indicating that no tradeoff even exists.
- deleted 3y ago
  [deleted]
byteware 3y ago
"If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more." well if it is work that I know I can do quickly I'm just gonna procrastinate the hell out of it, if it is something I enjoy doing I am already inclined to do it
tasuki 3y ago
A good post overall, but the final paragraph is particularly great: > Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.
m463 3y ago
To a point. burnout matters too. If creating emails quickly leads to quick replies and more emails, before you know it you've emailed to your exhaustion point. this is a tactic and strategy matters too. speed matters on things that matter.
szczepano 3y ago
When I read about speed of doing things this always reminds me a tale of two programmers https://news.ycombinator.com/item?id=677655 https://news.ycombinator.com/item?id=677655, archive link https://web.archive.org/web/20121226223216/http://mail.linux.ie/pipermail/social/1999-October/000483.html https://web.archive.org/web/20121226223216/http://mail.linux... I'm not against or in favour of speed. History showed us many times that most people don't care about truth and correct solutions, people care about efficiency and moving things fast. Just look at gaming industry and preordering. Agile project management. This is what is called taking risks and making a jump into abbyss before we look what is underneeth. Taking risk is always praised. Question is which jump will be last one and will kill us all?
lancebeet 3y ago
This reminds me of Steve Yegge's classic blog post "Programming's dirtiest little secret"[0]. Yegge's post is of course about touch-typing, but it essentially makes the same argument. Doing things slowly is a liability, not primarily because it consumes more time, but because it makes you opt out of doing certain things because of their perceived cost. [0] http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html http://steve-yegge.blogspot.com/2008/09/programmings-dirties...
- neom 3y ago
  "You'd be absolutely astonishedly flabbergasted at how many programmers don't know how to READ. I'm dead serious. You can learn to speed read even faster than you can learn to type, and yet there are tons of programmers out there who are unable to even skim this blog. They try, but unlike speed readers, these folks don't actually pick up the content." Heh!
ChildOfChaos 3y ago
I'm very slow at doing things, because I consider things too much, I very much believe this is the main skill I need to work on, because the quicker you do something, the quicker it goes wrong, so you can course correct. The book Creativity INC by Ed Catmul talks about this and they actually studied it at Pixar and they discovered the teams that moved faster were the best, the teams that considered everything for much longer, were wrong just as much as the teams that moved quickly, the only difference is because the other team moved quickly they could course correct sooner and also they were less tied into there original idea, so happy to drop it and go the other direction, were as the team that was slower and more considered took longer to drop the non-working idea, as they dug deeper and tried to make it work, since they were more invested in it.
- DoesntMatter22 3y ago
  I worked at a company where the team was asking for an internal dashboard to see real time metrics from these events we handle. My boss was like "Yeah, we are gonna need 6 months and a team of 5, and we need to plan this out right for once". I went and wrote a version of it in a weekend and it ended up being what they needed. They had a few minor requests which took an hour or two but not much overall. My boss was pretty mad at me that I made him look bad though lol. I could have handled that part better I guess, but I hate when people want to spend forever planning especially when you can get something out real quick.
rglover 3y ago
The best solution I found to this logjam was this quote: > "Make haste slowly." - Baltasar Gracian
- littlekey 3y ago
  We can go older: "festina lente" in Latin. (https://en.wikipedia.org/wiki/Festina_lente https://en.wikipedia.org/wiki/Festina_lente)
tempestn 3y ago
> Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years. And, amusingly, it currently loads really slowly too.
hot_gril 3y ago
When I got my first big corp job at a FAANG company, in the first week a senior dev gave me the worst work advice I've ever received: "Always write code as if you expect it to be around for at least 10 years." I think that's how that dept was doing things, and it was paralyzing. This was business logic that needed flexibility, not something like an OS kernel. Not only did new features not get shipped, but the pedantic approach actually caused tech debt because better solutions were seen as too hard. Code really did sit around for 10 years, and not because it was good code (it wasn't).
npilk 3y ago
In addition to the many great points made in the article, I would add that speed does a couple of other things for you: - The faster you finish work, the more time you have to make your work better - The faster you are even at things like browsing HN or Reddit, the more value you get per hour (e.g. seeing more new ideas, reading more blog posts, etc)
flkiwi 3y ago
Aside from this post ultimately seeming like a bit of a joke given its conclusion, I found myself reflecting on a few things: - Prompting people to send me MORE email is a horrifying thought and set me right off thinking this would be a parody piece. - He's write that writing quickly can lead to more ideas. But if I'm writing for someone else, "quickly" can have multiple meanings: I can write one thing quickly, then have to rewrite it several times quickly to remedy all the assumptions and missing concepts even a competently, cleanly, and professionally written piece of text will have, OR I can slow down, answer all those questions as I go, and effectively write once well. Slowing down has been the best writing skill I've ever found for professional writing. - Having a straight brain-to-Google interface appropriate for 2015 described as permitting almost impulsive thought is ... scary. Discipline benefits even creativity. - I couldn't help thinking that this piece could have been simply "Work at a comfortable pace, and work on a single item, and don't get distracted by the world" and been more beneficial than "work quickly" (though, again, defining "quickly" is tricky).
- __anon-2023__ 3y ago
  I agree with the email point. Who wants people to send them more emails?
littlekey 3y ago
Great post, the summary for me being: speed is not just speed. There seem to be many other benefits aside from just maximizing productivity. It's a change in mindset that reduces decision paralysis/fear of starting, as well as encouraging experimentation. As an aside, I was originally not going to post this comment as it doesn't really say anything not present in the article itself. But then I decided that going for it instead of overthinking or reworking it counts as an exercise in working quickly :).
EGreg 3y ago
In my experience, after you've finished 90% of the work, there's the other 90% ... in the other aspects. Like, you finished your software? Great. Now you have to make a sales funnel, do PR, push news about it, etc. Slack off on anything and it is a flop. In short, if you're dreading work, chances are you need partners!
j7ake 3y ago
Tinkering and iterating is key to progress. The more “volume” of work you can do per unit time, the more you can be ruthless in culling work that don’t meet your standards. From the outside observation, it will look like the person consistently outputs quality work, when in reality it is just a harsh selection process.
5350-uiop-1130 3y ago
make it work, then make it right (if time permits) your job isn't writing code, it's fixing someone's problems
hzay 3y ago
Eh. Anyone who observes small children will see that they learn very slowly, but constantly. And they are extremely good at it - better than nearly all adults - at a minimum they pick up language, gross motor skills like walking, running, climbing, any number of fine motor skills, within 2-3 years. They don't work quickly, they display no haste or concern for efficiency. In fact, they're quite inefficient.
lcedp 3y ago
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails. That's funny: when I learnt this, I have encouraged myself to reply with a delay so that give people a chance to resolve problems on their own and generate less emails for future me to handle.
junglistguy 3y ago
[dead]
x3874 3y ago
'Haste makes waste'. I see this with coworkers all the time.
zzbn00 3y ago
I don't know, this is good advice perhaps for things which are not important. But, if you are writing an email to a person whose time is valuable, better not to do it quickly. Save a draft, come back to it tomorrow, read again, then send. If you are writing a legal document, don't do it quickly. Write it, come back to it again to review. Is it still a good idea? If you are doing something completely new, do it slowly and step by step -- if it is new you don't know if it is right without checking each step. If you have an idea, read the literature, patents, see what is out there first.
agumonkey 3y ago
I think this effect is due to a cost of brain plasticity. You brain likes to close stuff regularly. Any new theory should be met with a kind of categorization, conclusion or a new idea to try later.

513 points by cal85 3y ago

ed 3y ago

https://web.archive.org/web/20230602051336/http://jsomers.net/blog/speed-matters https://web.archive.org/web/20230602051336/http://jsomers.ne...

snapcaster 3y ago

Site not loading for me :(

havnagiggle 3y ago
Have you tried loading it faster?
tobr 3y ago
Which is a little ironic considering this quote from the article: > It’s now well known on the web that slow server response times drive users away. A slow website feels broken.
- paulddraper 3y ago
  I was just about to give up when it finally loaded
michalstanko 3y ago
I guess the author did the website too quickly.

bredren 3y ago

(2015) https://archive.is/2019.08.06-012000/http://jsomers.net/blog/speed-matters https://archive.is/2019.08.06-012000/http://jsomers.net/blog...

xrd 3y ago

Nice article. This is basically in the article when they talk about email responses back and forth, but not explicitly called out: if you are fast, people that interact with you get faster, too. Toyota figured this out with kanban (https://en.wikipedia.org/wiki/Kanban https://en.wikipedia.org/wiki/Kanban) and revolutionized process thinking. So, if you are thinking about how to get your team to work faster, focus on what is making slow team members go slowly.

deleted 3y ago

[deleted]

garrickvanburen 3y ago

From my perspective - speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome. Over my career, I've been surprised multiple times when I presented early draft to a stakeholder and they said, "oh, that's great, I've got what I need now"...and this was maybe 1/3 of the effort I was planning for. The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important. Along these lines, in my work with stuck startup founders, I often ask, "if we were going to demo a prototype to a customer (in 2 days | at the end of the week), what would it be?"

Zetice 3y ago
I cannot possibly emphasize this more strongly. It's so important to deliver complete and working products quickly and regularly, that it's worth the cost of the occasional lost customer who leaves because all of their needs aren't met immediately. A) they're rarer than people seem to think and, B) the people you gain due to this incremental approach more than cover the losses. That said, some devs interpret "quick" to mean "sloppy", which is not correct. When you can cut releases hourly the cost of some kinds of bugs does go down, but fewer bugs is better, and as always some categories of bugs are, "never, ever" (e.g. data corruption/leak, security bugs, outage inducing bugs).
- afarrell 3y ago
  To go fast, stay humble and use boring technology.
  - j45 3y ago
    .. in a simple and flexible way.
- andai 3y ago
  I agree completely. That sounds much better than my current strategy of delivering incomplete and broken products at unpredictable intervals.

sublinear 3y ago

As the article states, this only works for stuff that can be broken up into low effort chunks. Not everything is like that such as maintaining legacy systems or working with large teams. :)

commandlinefan 3y ago
> Not everything is like that In fact, almost nothing that's actually _useful_ is. Anything that can be broken up into predictable low effort chunks is something that can be automated away.
- 0xbadcafebee 3y ago
  If you can automate away programming, there's some people who would like to give you a lot of money.
  - CatWChainsaw 3y ago
    I doubt whatever severance they get can last them the rest of their lives.
    - hgsgm 3y ago
      It's not 1 severance, it's 1 million.
      - CatWChainsaw 3y ago
        Unless one person is getting one million severances, they'll outlive it.
  - sublinear 3y ago
    I don't think that's what the parent to your comment was about. You can't automate away programming, but you can write one program that behaves equivalent to many that accepts configuration from people who don't know how to program.

gen_greyface 3y ago

related: Some reasons to work on productivity and velocity https://news.ycombinator.com/item?id=28882043 https://news.ycombinator.com/item?id=28882043

alexfromapex 3y ago

Compensation plays a big role in how fast I'm willing to get something done

ukuina 3y ago
Doesn't compensation follow good/fast work, not precede it?
- TinyRick 3y ago
  That has not been my experience in modern corporate America.
- AA-BA-94-2A-56 3y ago
  Sometimes, but not always.

jmclnx 3y ago

When it comes to business (corporate), you hear "do it right". But in reality that means "do it fast even if wrong". If mistakes are made, what happens depends upon management. In most cases, I have seen people who do a project 100% correct, sometimes slightly slower get ignored. Other people who get it done fast, even with many blaring mistakes, get rewarded. Usually the people who worked on it end up working 24/7 to get it fixed. That is looked upon by most managers as very good work. If your projects go live without issues, it is usually forgotten, people who fix their own issues by putting in fixes after go-live by working 24 hours, get noticed and rewarded.

inconceivable 3y ago
graphic designers sometimes ship their draft deliverables with 1 or 2 obvious bugs, and allow the customer to recommend these 'changes' on their own for final delivery. and if they don't, they're just fixed for final delivery anyway. i read about it before i had this done to me for the first time, and i played along with it. it's a neat trick because it's plausibly deniable for everyone involved and the outcome is good while minimizing the bullshit work in favor of a sacrificial final word.
- politician 3y ago
  There is a concept of a sacrificial feature to prevent customers from becoming fixated on other aspects of the design that would actually create problems if changed. I prefer to avoid that sort of dark pattern though because it erodes trust.
  - CrazyStat 3y ago
    "The Queen's duck" https://bwiggs.com/notebook/queens-duck/ https://bwiggs.com/notebook/queens-duck/
- garrickvanburen 3y ago
  I’ve also done this, with both visual design and software. It’s a deliberate canary - if the client didn’t comment on the obvious mistake/bug, I know they didn’t actually look at it.

Slower-McSlower 3y ago

[flagged]

allenu 3y ago

Speed is underrated. I've worked on a lot of side projects and for a long time I couldn't get them done. I spent too long "perfecting" baseline things like folder structure (really) and overall system design. This made things slow-going and I tended to abandon them. Over time, I started just hacking things together and shipping them, worrying less about perfecting those initial things. (I used YAGNI a lot in my decision-making.) What I learned is that there were so many more things I had to do and had to learn to do to ship. I could only get to those tasks and learn those skills by "skipping" through the earlier tasks. Working quickly helped. I started thinking of projects as this vertical stack of work that you move up from bottom to top. If you could look holistically at absolutely everything you needed to do to ship a project, you could mark some as having a larger impact on the success of the project than others. Those are things that require more time and energy. When you move slowly, you have a very small scope of the overall project, just stuff at the bottom, and predictions about the future. You may not really know what's ahead. If you go slowly and try to do everything perfectly down there, you spend a lot of energy on a small subset of tasks which may actually have smaller impact than something in the middle or towards the end. Speed allows you to move through those early tasks move towards a more holistic view of the entire system so that you can determine which are high impact and which are not. You might need to double-back on an earlier task if you misjudged something as low-impact and ended up spending less time than you should on it, but at least you're not pouring energy into low-impact tasks on average. It's not quite the same thing, but building a prototype is a good example of learning the end to end of a system without worrying too much about quality. It gives you an initial idea of what's possible and you use that to get a better picture of what's high and low impact in a project.

hot_gril 3y ago
This is all true. The SWEs I work with in a corporate environment don't get it, but the managers do.
deely3 3y ago
Am I right that you are talking only about quick creation of something new and not about long term support of created system?

deleted 3y ago

[deleted]

andai 3y ago

https://archive.ph/jl4oc https://archive.ph/jl4oc

0xbadcafebee 3y ago

From a DevOps perspective, speed is often the indicator that you're doing things right. If you integrate code quickly and often, if you deploy quickly and often, if you patch and upgrade software quickly and often, if you detect, diagnose and fix issues quickly and often, those are all indicators of a high-performing team. Quality isn't always correlated, but high-performing teams tend to care about quality, so it's not uncommon to add quality improvements to the list if you're doing everything else.

tstrimple 3y ago
We tend to get better at the things we do often. Companies which have annual release cycles are almost always terrible at actually shipping software in my experience. One of my first goals in any new organization is improving iteration / feedback cycle speed.
mobiuscog 3y ago
I think that part of the problem is companies/executives/manager who think that teams need to 'do' that in order to become high-performing rather than, as you stated, it's an indicator. There needs to be a suitable environment, skills/training, support framework and everything else around to enable the team to become high-performance over time, that when starts showing that indicator. Correlation not Causation. All too often these are mixed by those who read the books that offer 'Acceleration' and think that enforcing these processes will somehow make the team fit.

dmbche 3y ago

Just a note : I've noticed that when working with management, they often have issues "grokking" the issues they are asking for you to solve. By offering an imprefect, quick solution, it lets them understand the issue and readjust their needs in consequence - and often, the quick imprefect solution is good enough/enough work to show it's a bad idea and to move on. When starting project I have 2 steps : vomitting and touching up. You puke out a solution(minimum viable product), without thought about optimisation. When that exists, you change hats and optimise. Works wonders.

Culonavirus 3y ago
Except the reality often looks like: > You puke out a solution(minimum viable product), without thought about optimisation. And that's where it ends, because unless your employer vastly overhired, there's already a dozen (or more...) of tasks in the backlog just waiting for you to vomit them out as well. After a year or two of working like this, you have a mountain of technical debt and no time work on it all. The entire system slowly disintegrates under its own weight. There needs to be a balance between fast and correct, and it is only up to the developer to resist the pressure from management to work fast (at the expense of correctness). I would go as far as to say that it is one of your main non-technical duties as a developer to resist and manage this pressure as best as you can. Maybe you're a genius who can analyze problems and implement solutions both fast AND correctly, but that is very rare. The truth is that complex problem solutions can have complex, messy implementations. They can also have simple, beautiful implementations. Or anything in between. But what they almost invariably require is complex investigations... which take time to conduct properly. Most (not all!) "fast" programmers I've worked with over the last 15 years produced output of questionable quality, often stemming from the "what you don't know you don't know" part of the knowledge pie chart, instead of some deeply thought out cost/benefit calculation.
- georgeburdell 3y ago
  IME fast programmers are great at externalizing their QA
  - 3y ago

agentultra 3y ago

I wonder how the author thinks about this now, 8 years later. Way back in 2016/2017 I saw this video on prototyping where the programmer whipped up a snake clone in around 4 minutes. I deliberately practised programming in this way: how fast can I go from idea to working prototype? Code style, organization, testing, best practices be damned: you have about how long it takes to run a load of laundry, how much can you get done? I did this for a few months. I focused on games. I roughly tracked how much time it took to get from empty file to the first interaction with the game. I tried to focus my practice on getting to that first interaction. And the overall time I spent and how far I got with the idea. The thing with going that fast is... the code sucks. You're not writing it for an audience, for your future self, to make it possible to extend and compose; when you want to go fast and prototype in this way you're deliberately not going to use this code for anything later on. You just want to get the idea out there to see, "is this even fun? Would it even work at all?" ... before you go ahead and spend the next 6 - 12 months spending your limited time on something. Because finding out your game isn't actually fun after all of that effort is demotivating. In this sense speed is useful. It's useful in certain contexts when doing programming on the job. Especially at startups where the runway is limited and you don't know if you even have customers yet. However! Be prepared to throw it out. Once you find some traction for a feature or process; throw out the prototype/MVP code. Make sure it's cheap to do that: you can write software that is loosely coupled, you can write a better API that uses the MVP code underneath, write good tests against the new interface, remove the old code paths piece by piece, etc. If it's a core part of the product and there are customers for it get rid of that prototype/MVP code some how (it's easier to plan for this and not get too attached to the first iteration if you do it intentionally).

syntheweave 3y ago
Agreed - There's a certain thing about greenfield development in particular(which is quite fully the realm of startup coding) where you have to approach the first, second, maybe third iteration as one that will be thrown away, so when it does get thrown away, you make it easy to do so. And that leads towards some pretty dumb code, often "copy-paste-modify, sort it out later" code. A lot of "best practice" ideas that get made into blogposts impose a structure that hinders disposability in favor of a certain aesthetic goal: to do the thing with less repetition and slightly cleaner abstractions. The goal is often not unreasonable, but it conflicts with the action of rapid iteration. So I tend to write now with an eye towards trying to keep the code disposable until I face a certain class of error to eliminate, that needs the more abstract method. Often part of the disposability is in not actually solving the entire problem, but cheating and returning a wrong answer, e.g: Instead of fancyAlgorithm() being written in a way that creates any dependencies I write a skeleton "function fancyAlgorithm() {return true;}" and then later upgrade it to a lookup table, and then to the algorithm. Because most of the code that matters to the app won't be in the algorithm, but in how all the other data is being passed around. The sooner I can get that piece to return a wrong answer with known error, the sooner I can arrive at a complete but wrong app, which can be corrected into a higher quality one. When not all the pieces of the app are there, it's not clear what error you need to be solving for, which leads to squeezing effort onto code that isn't important.

divbzero 3y ago

Related: Speed matters: Why working quickly is more important than it seems - https://news.ycombinator.com/item?id=10020827 https://news.ycombinator.com/item?id=10020827 - Aug 2015 (139 comments) Speed matters: Why working quickly is more important than it seems (2015) - https://news.ycombinator.com/item?id=20611539 https://news.ycombinator.com/item?id=20611539 - Aug 2019 (172 comments)

tabtab 3y ago

The CRUD IDE/Stacks of the late 90's were closer to the domain and that was a large reason for the productivity I used to see: more done with less key/mouse-strokes and less code. Web stacks make one waste time fiddling with janky stack parts & layers instead of domain logic, where it SHOULD be spent. It's hard to match their productivity with current web stacks, often requiring specialists and/or big learning curves. (Sure, the 90's IDE's had their warts, but were getting better with time, until web murdered them. And I'll limit this to small-and-medium apps rather than enterprise/web-scale.) It's usually assumed the features that made them productive are mutually exclusive with web-ness. I'm not convinced; the industry just stopped experimenting. What would help is a state-ful GUI markup standard so that GUI's don't have to be re-re-reinvented via HTML/DOM/JS, which is inherently ill-suited for rich CRUD GUIs. Having your language/tools/standards being a close fit to the domain matters. It's why COBOL lives on despite being even older than me. I'm not saying we should mirror COBOL as-is, only that it still carries important lessons, including FDD: Fit the Damned Domain.

bern4444 3y ago

Speed matters when the thing being built is isolated. If you're building a new feature/product whatever, and the business views that both as a standalone feature, but also as a stepping stone to support another product or feature then the code you get when writing quickly is going to slow you down in that next step. Scale that up a few levels and you end up with 'enterprise code' that no one wants to touch for fear of breaking all the parts that depend on the pieces below it. So write code quickly when its isolated and not planned for use in additional products, features, capabilities. It is very difficult to convince management to prioritize tech debt and the only successful way is in the frame of enabling additional product capabilities.

hot_gril 3y ago
If you're building a stepping stone, you still have to figure out how to make it isolated in a way then do it quickly. Like if it's a software service, spend the extra time figuring out a good API then speed through the initial implementation.

maerF0x0 3y ago

When folks speak hypothetically about speed, they almost always assume identical outputs. Which is pretty contrary to at least my experience, if not reality. Apple is the worlds most valuable company, and they're first and fastest in essentially nothing. So it really depends on the market you're going after. Anecdotally, (and backed by language learning research iirc), when learning is involved iterations are important. Learn a little, practice a little, get feedback a little, repeat frequently. But afaik it all comes down to the cost of failure. Public iteration on your encryption algorithm that's guarding billions of dollars is probably a bad idea.

painted-now 3y ago

Being fast and iterating reminds me so much of the EM algorithm. Probably a bit of a stretch but still: You start with an initial estimate of the hidden variables (solution), check what the consequences are by implementing it, and apply the knowledge about the right consequences to improve the solution.

Sharlin 3y ago

> I’ve noticed that if I respond to people’s emails quickly, they send me more emails. > It is a truism, too, in workplaces, that faster employees get assigned more work. Maybe there's irony I'm failing to perceive, but how exactly are these supposed to be good things from the fast worker's viewpoint? The truism is that working quickly is only rewarded by being assigned more work that's expected to be done even faster, which is a vicious circle if ever there was one!

perlgeek 3y ago

> I’ve noticed that if I respond to people’s emails quickly, they send me more emails. This is why I intentionally wait before answering emails that aren't related to my core responsibilities. I want fewer of these, so I best not establish a reputation as somebody who quickly provides an answer to everything. Got other things to do :-)

heisenbit 3y ago

> Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon. You aren’t “using them up” by giving them work. Well that is not always true. Producing results is one thing, making sure you learn enough in that process is another. Managers eager to cram down one micro manage task after another will use up a persons knowledge without restocking it. Yes faster can be better as lot‘s of people agree here with but there are limits.

lars512 3y ago

I think about this another way. If you're fast enough, you can afford to do the gardening you need to keep your codebase in a good way without having to schedule it all in. If you're fast enough, when doing data analysis, you earn the space to ask the next question, and the next, and to do a deeper analysis. But... as a lead, I've struggled to train speed before. Some people I've worked with have had it, junior or senior, and some have not. Has anyone had good experience helping others become faster at their work?

iamcasen 3y ago
No. I think humans are all unique. Just like a pro basketball coach, you are looking for the right talent for your particular team and your particular context. I have had extremely smart, talented, thorough engineers who are slower than whale shit in an ice flow. For a startup, those engineers are a death sentence. It doesn't matter how good they are, if they aren't fast, they hold everyone back. Are you building the roman empire, or are you building a small group of bandits that move swiftly through the night? Each case has it's corresponding strategy.

karaterobot 3y ago

This is kind of conflates the idea of a person doing a job quickly, and the idea of tools having low latency/quick response, which confuses the issue if what you care about is working quickly — the bottleneck for work is usually the speed of our thinking, or the limits of our motivation to work. But, it's usually not the speed of our tooling. You wouldn't become a better programmer with a faster computer, and usually not a more effective one either. I'll ignore the second definition. In my opinion, you want to spend about as much time as ever, but spend more of your time working on something that is close to a solution. So, you want to work on the first draft as quickly as possible, so you can either refine it, or toss it out and do another iteration. The advantage is overall quality and confidence in your solution. For reasons mentioned in the article, I do not prefer to be thought of as working quickly and well, since that often means someone sees your first draft and says "great, looks like you're done, now let me give you something else to work on". Better to have a reputation for taking about as long as most people, but producing better results.

epolanski 3y ago
> You wouldn't become a better programmer with a faster computer, and usually not a more effective one either. Disagree, any time I have to wait for tools is a tragedy. I've definitely became much more productive at each computer upgrade.

cosmiccatnap 3y ago

I always see arguments for working faster. Never arguments for taking your time to get solutions correct even if it doesn't produce something immediately visible. ...I'm sure there is no economic correlation

hgsgm 3y ago
Being more productive is more valuable and profitable. "Correct" doesn't sprout fully grown from your head like Athena from Zeus
- mobiuscog 3y ago
  Valuable and profitable for investors, or society ? Because absolutely not both.

0x6461188A 3y ago

I agree with his points. The question is: what are some ways of working fast without being sloppy? Would be interested in how people here do it.

hgsgm 3y ago
1. Slow is smooth and smooth is fast. Don't rush and crush. 2. Practicing to get faster at the nitty gritty boring details, relying less on your reference materials, is as important as the big ideas.

sashank_1509 3y ago

Consistently I see this advice from everyone who I consider has achieved outside success in their field. Greg Brockman (OpenAI Cofounder) : Developer Speed is the most important thing I care about: (https://www.youtube.com/watch?v=CqiL5QQnN64 https://www.youtube.com/watch?v=CqiL5QQnN64). I believe he said more about this topic but I can't find it now. Frank Slootman (Snowflake CEO): In his book Amp It Up, he stresses why pushing people to move fast is extremely important Elon Musk (Let's not get into a debate about Elon and just agree that he has helped setup 2 100bn+ companies) : "I believe in maniacal sense of urgency, if you can implement something right after the meeting, do that", upon his work philosophy when taking over twitter. In my personal experience one of the most impressive coders I met, worked extremely fast while also being very accurate, almost indicating that no tradeoff even exists.

deleted 3y ago
[deleted]

byteware 3y ago

"If you work quickly, the cost of doing something new will seem lower in your mind. So you’ll be inclined to do more." well if it is work that I know I can do quickly I'm just gonna procrastinate the hell out of it, if it is something I enjoy doing I am already inclined to do it

tasuki 3y ago

A good post overall, but the final paragraph is particularly great: > Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.

m463 3y ago

To a point. burnout matters too. If creating emails quickly leads to quick replies and more emails, before you know it you've emailed to your exhaustion point. this is a tactic and strategy matters too. speed matters on things that matter.

szczepano 3y ago

When I read about speed of doing things this always reminds me a tale of two programmers https://news.ycombinator.com/item?id=677655 https://news.ycombinator.com/item?id=677655, archive link https://web.archive.org/web/20121226223216/http://mail.linux.ie/pipermail/social/1999-October/000483.html https://web.archive.org/web/20121226223216/http://mail.linux... I'm not against or in favour of speed. History showed us many times that most people don't care about truth and correct solutions, people care about efficiency and moving things fast. Just look at gaming industry and preordering. Agile project management. This is what is called taking risks and making a jump into abbyss before we look what is underneeth. Taking risk is always praised. Question is which jump will be last one and will kill us all?

lancebeet 3y ago

This reminds me of Steve Yegge's classic blog post "Programming's dirtiest little secret"[0]. Yegge's post is of course about touch-typing, but it essentially makes the same argument. Doing things slowly is a liability, not primarily because it consumes more time, but because it makes you opt out of doing certain things because of their perceived cost. [0] http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html http://steve-yegge.blogspot.com/2008/09/programmings-dirties...

neom 3y ago
"You'd be absolutely astonishedly flabbergasted at how many programmers don't know how to READ. I'm dead serious. You can learn to speed read even faster than you can learn to type, and yet there are tons of programmers out there who are unable to even skim this blog. They try, but unlike speed readers, these folks don't actually pick up the content." Heh!

ChildOfChaos 3y ago

I'm very slow at doing things, because I consider things too much, I very much believe this is the main skill I need to work on, because the quicker you do something, the quicker it goes wrong, so you can course correct. The book Creativity INC by Ed Catmul talks about this and they actually studied it at Pixar and they discovered the teams that moved faster were the best, the teams that considered everything for much longer, were wrong just as much as the teams that moved quickly, the only difference is because the other team moved quickly they could course correct sooner and also they were less tied into there original idea, so happy to drop it and go the other direction, were as the team that was slower and more considered took longer to drop the non-working idea, as they dug deeper and tried to make it work, since they were more invested in it.

DoesntMatter22 3y ago
I worked at a company where the team was asking for an internal dashboard to see real time metrics from these events we handle. My boss was like "Yeah, we are gonna need 6 months and a team of 5, and we need to plan this out right for once". I went and wrote a version of it in a weekend and it ended up being what they needed. They had a few minor requests which took an hour or two but not much overall. My boss was pretty mad at me that I made him look bad though lol. I could have handled that part better I guess, but I hate when people want to spend forever planning especially when you can get something out real quick.

rglover 3y ago

The best solution I found to this logjam was this quote: > "Make haste slowly." - Baltasar Gracian

littlekey 3y ago
We can go older: "festina lente" in Latin. (https://en.wikipedia.org/wiki/Festina_lente https://en.wikipedia.org/wiki/Festina_lente)

tempestn 3y ago

> Now, as a disclaimer, I should remind you of the rule that anyone writing a blog post advising against X is himself the worst Xer there is. At work, I have a history of painful languished projects, and I usually have the most overdue assignments of anyone on the team. As for writing, well, I have been working on this little blog post, on and off, no joke, for six years. And, amusingly, it currently loads really slowly too.

hot_gril 3y ago

When I got my first big corp job at a FAANG company, in the first week a senior dev gave me the worst work advice I've ever received: "Always write code as if you expect it to be around for at least 10 years." I think that's how that dept was doing things, and it was paralyzing. This was business logic that needed flexibility, not something like an OS kernel. Not only did new features not get shipped, but the pedantic approach actually caused tech debt because better solutions were seen as too hard. Code really did sit around for 10 years, and not because it was good code (it wasn't).

npilk 3y ago

In addition to the many great points made in the article, I would add that speed does a couple of other things for you: - The faster you finish work, the more time you have to make your work better - The faster you are even at things like browsing HN or Reddit, the more value you get per hour (e.g. seeing more new ideas, reading more blog posts, etc)

flkiwi 3y ago

Aside from this post ultimately seeming like a bit of a joke given its conclusion, I found myself reflecting on a few things: - Prompting people to send me MORE email is a horrifying thought and set me right off thinking this would be a parody piece. - He's write that writing quickly can lead to more ideas. But if I'm writing for someone else, "quickly" can have multiple meanings: I can write one thing quickly, then have to rewrite it several times quickly to remedy all the assumptions and missing concepts even a competently, cleanly, and professionally written piece of text will have, OR I can slow down, answer all those questions as I go, and effectively write once well. Slowing down has been the best writing skill I've ever found for professional writing. - Having a straight brain-to-Google interface appropriate for 2015 described as permitting almost impulsive thought is ... scary. Discipline benefits even creativity. - I couldn't help thinking that this piece could have been simply "Work at a comfortable pace, and work on a single item, and don't get distracted by the world" and been more beneficial than "work quickly" (though, again, defining "quickly" is tricky).

__anon-2023__ 3y ago
I agree with the email point. Who wants people to send them more emails?

littlekey 3y ago

Great post, the summary for me being: speed is not just speed. There seem to be many other benefits aside from just maximizing productivity. It's a change in mindset that reduces decision paralysis/fear of starting, as well as encouraging experimentation. As an aside, I was originally not going to post this comment as it doesn't really say anything not present in the article itself. But then I decided that going for it instead of overthinking or reworking it counts as an exercise in working quickly :).

EGreg 3y ago

In my experience, after you've finished 90% of the work, there's the other 90% ... in the other aspects. Like, you finished your software? Great. Now you have to make a sales funnel, do PR, push news about it, etc. Slack off on anything and it is a flop. In short, if you're dreading work, chances are you need partners!

j7ake 3y ago

Tinkering and iterating is key to progress. The more “volume” of work you can do per unit time, the more you can be ruthless in culling work that don’t meet your standards. From the outside observation, it will look like the person consistently outputs quality work, when in reality it is just a harsh selection process.

5350-uiop-1130 3y ago

make it work, then make it right (if time permits) your job isn't writing code, it's fixing someone's problems

hzay 3y ago

Eh. Anyone who observes small children will see that they learn very slowly, but constantly. And they are extremely good at it - better than nearly all adults - at a minimum they pick up language, gross motor skills like walking, running, climbing, any number of fine motor skills, within 2-3 years. They don't work quickly, they display no haste or concern for efficiency. In fact, they're quite inefficient.

lcedp 3y ago

> I’ve noticed that if I respond to people’s emails quickly, they send me more emails. That's funny: when I learnt this, I have encouraged myself to reply with a delay so that give people a chance to resolve problems on their own and generate less emails for future me to handle.

junglistguy 3y ago

[dead]

x3874 3y ago

'Haste makes waste'. I see this with coworkers all the time.

zzbn00 3y ago

I don't know, this is good advice perhaps for things which are not important. But, if you are writing an email to a person whose time is valuable, better not to do it quickly. Save a draft, come back to it tomorrow, read again, then send. If you are writing a legal document, don't do it quickly. Write it, come back to it again to review. Is it still a good idea? If you are doing something completely new, do it slowly and step by step -- if it is new you don't know if it is right without checking each step. If you have an idea, read the literature, patents, see what is out there first.

agumonkey 3y ago

I think this effect is due to a cost of brain plasticity. You brain likes to close stuff regularly. Any new theory should be met with a kind of categorization, conclusion or a new idea to try later.