Speed matters: Why working quickly is more important than it seems

From the comments, I think readers are generally failing to take an opportunistic attitude toward this article. Dig out useful ideas and ignore what doesn't help.

Yes, there are situations where working too quickly will bite you, so you can't always do it. But the key idea here is that by working quickly you reduce your expectations of how costly a new effort is. Then you'll actually start it. Inertia is a powerful adversary. Any weapon you can put on your belt to fight it is worthwhile. I'm keeping this idea.

I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection.

But one good counter example does come to mind - designing a database schema.

I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes where the future state depends on a prior state, are relevant.

Maybe we could say tasks are either "strongly Markvoian", that is, how well we do them now will influence our future work and hence we should really think them through, e.g. designing a schema. Weakly Markovian, in which case there may be some future impact but not much, and so we exercise caution but "done is better than perfect". And finally non-Markovian - e.g. throwing out the garbage, cooking dinner, most emails - getting the thing done is simply a pass/fail and so we just have to do it, quality is relatively unimportant.

I think what I'm saying is, most tasks will be weakly or non-markovian, so we should "move fast and break things", but every now and then there'll be something we need to do that is strongly markovian. For such things we should be prepared to take a step back and give ourselves a little extra time, so things don't blow up further down the track.

Yes and no.

Do things fast when the cost of doing them wrong is low. If you're learning something, or doing something with low risk, then doing it as fast as possible is a really good idea (for all the reasons set out in the article).

But...

Do things slowly if the cost of getting it wrong is so high that you'll have no opportunity to try again. For example, don't pack a parachute quickly.

The key is recognising that there's more than one way to approach soemthing; selecting the right method for the problem at hand is the winning strategy.

Speaking as one who is laid back in a personality sense, I could imagine nothing worse than a life lived non-stop frenetically under the imagined need to speed up all activity in the name of productivity.

Take time to pause, reflect, think, and enjoy your life experiences.

Even when it comes to work-related activity, there are times and places to do things quickly and there are times and places to do them deliberately. If nothing else, just for sanity's sake, it is important to pace yourself through a day, through a week, through a month, through a year, through a career. Even if speed were exactly correlated with maximum productivity and effectiveness, it is vital that you have times when you simply feel you can enjoy being at work, being with people, doing your activities, without everything feeling you have to work like a machine that will be evaluated by engineering standards only.

Even more, we all have different personalities and some people do not work well if they feel they are forced to work at some arbitrarily quick pace as opposed to one that suits their style.

Finally, even speed as a factor can vary with your activities as you develop skills in those activities. When I began years ago to try to write things, I was agonizingly slow about the process. I felt I had a quick mind but the process of getting what was in my mind down on paper made me feel plain stupid. Whatever I did, it would never come out right. Through a very tedious process of writing and re-writing, it would eventually become passable and that was it. It might take me a week in such cases to write something expository of modest length. Yet, realizing this was a weakness, I worked damned hard to fix it and, through a process of many years and countless hours of effort, I reached a breakthrough point where I could do "walls of text" (in the phrasing of some) in 10-15 minutes and produce quality stuff. I now write very quickly and effectively. But had I tried to do so years ago with my limited abilities at that time, all I would have produced was hash.

So, lighten up and do it in your own style. Yes, speed does matter. But it is only one of many factors that will determine how you do at work or, even more important, at life itself. By all means, apply yourself well - be diligent, hard-working, etc. but do it fast or slow as suits your needs and your own style. At least that is how I view it.

Perhaps this applies more to shooting than software development, but...

Slow is smooth. Smooth is fast.

If I take 20 minutes more to code a module because I'm thinking about it, but spend 30 minutes less debugging problems with the module, that's fast.

If I take a day to respond to an email, but the person I'm conversing with gets the info they need, avoiding three more days of back and forth, that's fast.

If I take a week longer to iterate through a project idea, but nail the implementation, then I can know that I'm pivoting because the idea was wrong, not the implementation.

How do mere mortals become wizards to their peers? They take the time to read documentation and code and really understand the tools that they are working on. What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly. Of course there's a balance, and our current system of financing software projects rewards fast and loose, and there will always be a place for fast prototyping to help understand the problem, but to create something truly amazing takes a lot of time.

There are actually three lessons here:

* Momentum - To stick with something and finish it, you need to use momentum. Lacking momentum, projects languish. Quoting author Steven Pressfield: "Second only to habit, momentum is a writer’s (or artist’s or entrepreneur’s) mightiest ally in the struggle against Resistance."

* Waiting is painful. That's the point behind the examples in the middle section (waiting for an email reply, waiting for Google, waiting for an employee to finish a task). One thing this article makes me more aware of is the concept of getting impatient with yourself. Part of you is the boss or client that wants things accomplished, and it is sizing up the worker part of you, wondering if it assigns a task whether that task will get done quickly or require a lot of waiting, and there's a relationship to manage there. (Perhaps this dynamic underpins the phenomenon of momentum?)

* Quantity Always Trumps Quality - There's a blog post by Jeff Atwood with this title. The point is, if you want to get better at something, do a lot, and don't worry about quality while you're practicing.

Focusing on "speed" is probably a good mental trick for a couple reasons. First, it validates and acknowledges that we hate to wait. Second, it helps overcome perfectionism and the tendency to think and judge instead of doing and creating, by giving us something to measure that is not about quality but is instead correlated with action and progress.

Speed matters and there are more ways to make things faster other than doing them often.

1. If you are coding ensure that your debugging environment is good (simplest example would be if you write HTML how long does it take to see the output or is it auto-refresh itself int the second monitor when you change the file?).

2. If you are building a project how long does it take to deploy? Do you have CI with a one button push to production environment? If you have then you'll deploy faster and more often there is no overhead. If not you won't want to deploy often due to the overhead of the deploy.

etc.

The most important lesson I've learned about speed is that "design your environment and build for speed and remove the repetitiveness" then you can be fast. You can apply this rule to many things. Blogging, ensure that your blog tool makes it easier (how easy to link stuff, find images, does it really necessary to add an image to all posts, do you FTP upload, or do you just copy&paste and image to the editor, what happens if it crashes, do you lose data or does it just recover?)/

> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.

An alternative explanation would be that if you don't take your time to understand people's mail and just rush to answer them as quickly as possible, things that would take two mails to communicate now end up being a thread of ten mails, two phone calls and an in-person meeting.

Nothing is more infuriating than a person that replies 30 seconds later with a message that suggests they didn't read past the first sentence.

I don't know the author or his ways of responding to emails, but in my experience the above often applies to people that value speed above all else.

I see a lot of responses that seem to reflect what I consider a misunderstanding of the real advantage of speed.

It's not to get the same amount of work done in a shorter time (the management fallacy referenced in some of the comments).

The point of speed is to increase the number of feedback opportunities. Each feedback datum allows for slight course corrections / confirmation of original hypothesis.

By analogy, think of it like sample size. If you accept time as a primary constraint, then faster iterations (even if you accomplish less!) tend to give you more samples. More samples mean less variance.

Making decisions on a better model (less variance) is very appealing to me.

Before anything, the obsession with speed seems like a management fantasy that tries to squeeze more out of workers in less time. We shouldn't forget that we're all human, and there are myths and facts related to working fast.

Working "fast" is tricky. The ironic conclusion part of the article is an example to that. People will miss the point and screw up more while trying to be "faster". However if a task becomes more automatic, it will become faster, which means that actually doing something "fast" would consume less energy, since it is more or less automated and unconscious, while "trying" to be fast would consume more energy.

The key here seems to be that just do something "a lot", and it will become faster by itself through time by being more and more "automated". But take your time, and stop worrying about speed. Speed is just pressure which will bring more pressure as you do stuff faster. Don't create unrealistic pressure.

Another key is garbage collection. Just get stuff "done", and get rid of the old tasks, or treat your long to-do items as "later" lists. If something really matters, you will do it anyway. You won't even need a to-do list to keep track of your "important tasks".

I believe the author has mistaken speed with efficiency. What's the benefit of being fast if you're sloppy and have to redo things often?

Entrepreneurs would say that speed is the signal of mature markets: more and more effort for less and less return. Mobile games were very profitable in 2009-10 (low effort, high return), balanced in 2012 (speed was important at that stage), unbeatable and unbearable as a business in 2015 (however fast you are, you're just playing a lottery).

not so long ago... https://news.ycombinator.com/item?id=9952875

Some other reasons why speed can be good:

- You can only hold so many details in your head at once, and you can only sustain that collection for a limited duration. Holding those details there can be crucial for doing good work and the faster you work the more you make use of them.

- Doing good work often requires a lot of experimentation and iteration. In a number of circumstances this may only be practical if you can do them fast enough

I am reminded of the story of how Leonardo da Vinci took three years to paint The Last Supper and produced only a small number of paintings, generally considered masterpieces, during his life.

Working quickly is important because it's the better method to survive and thrive. Quickly producing 100 deliverables with qualities ranging from shit to pretty good, will probably on average always defeat carefully crafting one deliverable in the same time frame.

Speed lets you try many alternatives, experiment with many different even opposite options, and draw out creativeness.

Another possible reason is that speed is the strength of the younger generations. In human history, if new comers want to beat the current authority (in business or politics) who have already mastered the intricacies of the current game, one have to propose and experiment large quantity of new alternatives, new rules of new games, even though most of experiments might have low quality results judging by the established rules. But it's the better way to compete and survive.

The author rests his entire argument on illusions to "the mind" that are untested and impossible to test. For example, "If you work quickly, the cost of doing something new will seem lower in your mind." Not sure how we get into someone's mind to measure the "cost of doing something."

We could not confirm or disconfirm this as truth, say in the context of an experiment. This phenomenon is better described by the concept of immediacy of reinforcement. As one decreases the delay to reinforcement, the strength of behavior maintained by that reinforcer increases [0].

0: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1332712/

As a developer, what this means to me is:

For every piece of code you write, there should be a unit test covering it that you can run fairly instantly with 1 keypress which catches at least internal-consistency errors. (Integration tests would cover external-consistency errors, but when you're refactoring/adding/deleting code, internal-consistency is violated far more often than external consistency, in my experience.)

Once you experience this for yourself, you will NOT want to go without it. It allows you to IMMEDIATELY get back to coding without waiting for test runs to finish and without creating bugs unknowingly that you only catch much later.

One apparent counter-example is that when practicing the piano, some common advice is to play pieces much slower than you think is necessary, but play them correctly. Then speed up once you have the right habits.

But the overall goal is to learn new pieces as efficiently as possible. Someone who is efficient at practicing will make much more progress (and have more fun doing it) than someone who isn't.

High speed alone is not so good if it comes without quality.

I feel like there's a bunch of data over-fitting going on here. The examples here are merely the ones that fit with the author's model, are they not? I'm sure I could have had a theorem that points to the idea that "fast work is catastrophic", gone back in time, and shown how the slow individuals / components of a system were significantly more effective than the fast ones.

It's funny that they include google as a fast example. On my Nexus4 and Nexus7 Google search is the slowest thing you can do on the internet. Youtube HD videos are way faster than a google search and fail less often when on the train/bus. I always wonder how sending a String and getting back a list of Strings can be so much more expensive than a HD video but who am I to judge, right?

Not using flyspeck grey fonts on light gray background in a tiny column on a vast screen is more important for readability than it seems.

I am not sure if the writer has thought out the drawbacks to working quickly but there is probably some benefit to deciding quickly.

The writer mentions that faster employees have more work assigned to them. Woo hoo, but what happens when the work queue fills up faster than it can be emptied? Then the once-fast employee now seems slow.

I find myself really, tangentially curious now: what editor is he using that has a slow undo feature?

There is a big unasked question here - is your final work product the same or better quality when working fast?

If you can honestly answer "Yes" to that question, by all means, speed it up.

Move as quickly as possible while maintaining a high level of accuracy/quality. Some people underestimate themselves, moving too slowly!

I can see the benefit of making progress quickly. Haven't seen frenetic/"quick" working lead to that result.

Never mind the quality, feel the width :)

The article reminds myself when I was younger when I was 27. Now I am 28, and I have grown wise and old in this year to know that working quickly does exactly that, produce quick results without much quality. It works well in cases where you need a result or just something to build momentum, but it's not at all sustainable. Just like coding, if you speed without thinking through the steps you end up with a mountain of technical debt, instead, it's actually faster to think slowly and careful and doing the right things instead of your ego which gets a huge kick out of doing more in higher quantity than quality in short period of time. Again, it works well in some scenarios which I can't think of right now but not at as important as this young buck has written.

so inspiring. this person is generous, admitting to being the slowest.

-=in defence of taking your sweet time=-

the arguments for speed and the arguments for quality are not either or. they both contribute to a product that works.

to introduce the case for slowness a natural precedent is appropriate. the development phase for human beings was on the order of 2 billion years.

and in that time a whole lot of nothing happened. all those evolutionary competitors at every level of the tree of life were more rapidly produced than humans. and now humans rule the world and in 200000 years have used that comprehensive development period to move rapidly and adapt so effectively to the world that we have changed it to support 7 billion of us and tripled our life spans. the hockey stick curve of our technology speaks to the benefits of long development, and the long tail of non-adaptive more-rapidly developed ideas that come to nought.

those practising rapid development and launch save costs during the development stage and increase costs during the much longer operating stage by code that has more bugs, takes more to maintain, is more brittle, and these things constribute to being slower to adapt to customers and competitors when it counts, that is, when you have customers, are burning operating costs, and competing.

it works better to develop comprehensively when it is cheap to and build the most efficient product to be really useful when you run with it. longer development, then move faster in operations.

otherwise you end up solving your terrible code base by hiring more brains, and those brains could be better put to use creating improvements for your customers and not fixing the consequences you shipped in a sprint.

pre launch development is cheap, so it works to take your time and not optimize that __process__ prematurely. everything is more expensive after launch when the stakes are real and where an advantage can be moving fast -- if the code you crafted creates that you can adapt quickly, then you've minimized costs over the operating period, and your brains can work on growing and retaining, rather than building an ozymandius of monkey patches.

the time when speed is important is after launch not before it. if you rush your pre launch development, you will be a slow operator, and this will cost you exponentially more than the linear increase in cost from a longer development time.

also the more robust the system you build is, the slower ( as in slow thinking ) you can create your decisions in the operating period to really consider strategy.

let your competitors ship first and watch the things they miss. let them pay for the experiments you now decline to run. if someone seems to be capturing the market through their business model then you are too slow anyway and the high order bit for you isn't code anymore. if that is not your market, then it is filled with competitors who are mimicing each others sub-monopoly strategies. so you can step in, be the last mover, and take the market. invest time during development to make code and tools that work, grasp your business plan, and have the possibility of thinking strategically about the business, in the operation phase, once you have launched.