From my perspective - speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome.<p>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.<p>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.<p>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?"
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.<p>In most cases, I have seen people who do a project 100% correct, sometimes slightly slower get ignored.<p>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.<p>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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>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.<p>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.
I wonder how the author thinks about this now, 8 years later.<p>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?<p>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.<p>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?"<p>... 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.<p>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.<p>However!<p>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).
Related:<p><i>Speed matters: Why working quickly is more important than it seems</i> - <a href="https://news.ycombinator.com/item?id=10020827">https://news.ycombinator.com/item?id=10020827</a> - Aug 2015 (139 comments)<p><i>Speed matters: Why working quickly is more important than it seems (2015)</i> - <a href="https://news.ycombinator.com/item?id=20611539">https://news.ycombinator.com/item?id=20611539</a> - Aug 2019 (172 comments)
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.<p>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.<p>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.
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.<p>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.
When folks speak hypothetically about speed, they almost always assume identical outputs. Which is pretty contrary to at least my experience, if not reality.<p>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.<p>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.<p>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.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.<p>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 :-)
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. :)
Speed matters when the thing being built is isolated.<p>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.<p>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.<p>So write code quickly when its isolated and not planned for use in additional products, features, capabilities.<p>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.
Aside from this post ultimately seeming like a bit of a joke given its conclusion, I found myself reflecting on a few things:<p>- 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.<p>- Having a straight brain-to-Google interface appropriate for 2015 described as permitting almost impulsive thought is ... scary. Discipline benefits even creativity.<p>- 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).
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.
A good post overall, but the final paragraph is particularly great:<p>> 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.
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."<p>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 <i>did</i> sit around for 10 years, and not because it was good code (it wasn't).
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.<p>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.)<p>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.<p>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.
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.<p>this is a tactic and strategy matters too. speed matters on things that matter.
I don't know, this is good advice perhaps for things which are not important.<p>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.<p>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?<p>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.<p>If you have an idea, read the literature, patents, see what is out there first.
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.<p>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 :).
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.<p>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.<p>Has anyone had good experience helping others become faster at their work?
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.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.<p>> It is a truism, too, in workplaces, that faster employees get assigned more work.<p>Maybe there's irony I'm failing to perceive, but how exactly are these supposed to be <i>good</i> 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!
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.<p>They don't work quickly, they display no haste or concern for efficiency. In fact, they're quite inefficient.
> 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.<p>And, amusingly, it currently loads really slowly too.
When I read about speed of doing things this always reminds me a tale of two programmers
<a href="https://news.ycombinator.com/item?id=677655">https://news.ycombinator.com/item?id=677655</a>,
archive link <a href="https://web.archive.org/web/20121226223216/http://mail.linux.ie/pipermail/social/1999-October/000483.html" rel="nofollow noreferrer">https://web.archive.org/web/20121226223216/http://mail.linux...</a><p>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?
In addition to the many great points made in the article, I would add that speed does a couple of other things for you:<p>- The faster you finish work, the more time you have to make your work better<p>- 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)
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.<p>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 <i>less</i> emails for future me to handle.
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.<p>[0] <a href="http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html" rel="nofollow noreferrer">http://steve-yegge.blogspot.com/2008/09/programmings-dirties...</a>
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 (<a href="https://en.wikipedia.org/wiki/Kanban" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Kanban</a>) 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.
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.<p>...I'm sure there is no economic correlation
> 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.<p>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.
related:
Some reasons to work on productivity and velocity<p><a href="https://news.ycombinator.com/item?id=28882043">https://news.ycombinator.com/item?id=28882043</a>
In my experience, after you've finished 90% of the work, there's the other 90% ... in the other aspects.<p>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.<p>In short, if you're dreading work, chances are you need partners!
"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
Tinkering and iterating is key to progress.<p>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.<p>From the outside observation, it will look like the person consistently outputs quality work, when in reality it is just a harsh selection process.
Being fast and iterating reminds me so much of the EM algorithm.<p>Probably a bit of a stretch but still:<p>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.
Consistently I see this advice from everyone who I consider has achieved outside success in their field.<p>Greg Brockman (OpenAI Cofounder) : Developer Speed is the most important thing I care about: (<a href="https://www.youtube.com/watch?v=CqiL5QQnN64">https://www.youtube.com/watch?v=CqiL5QQnN64</a>). I believe he said more about this topic but I can't find it now.<p>Frank Slootman (Snowflake CEO): In his book Amp It Up, he stresses why pushing people to move fast is extremely important<p>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.<p>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.