
Speed matters: Why working quickly is more important than it seems (2015) - zt
http://jsomers.net/blog/speed-matters
======
koonsolo
40 year old here. Speed doesn't matter as much as WHAT you deliver. First of
all, people do not know how much time something takes. And secondly, they will
forget how much time it took, but not how well it was made.

Responding fast to emails is just crazy. I lost count on how many urgent
problems got resolved automatically. "Hey can you help me with this". 15
minutes later "Nevermind, found it".

I'm in the "Slow is smooth, smooth is fast" camp.
[https://www.lesswrong.com/posts/4FZfzqMtwQZES3eqN/slow-is-
sm...](https://www.lesswrong.com/posts/4FZfzqMtwQZES3eqN/slow-is-smooth-and-
smooth-is-fast)

~~~
erik_landerholm
This sounds like people who quote "slow in, fast out" in racing. Just like
here it's not true. It's a "rule of thumb" for beginners. It has use in that
context. The way to win a race is fast in, fast out, same with software.

edit: I'm 42, if the matters.

~~~
ska
I think there is a different connotation to "slow is smooth, smooth is fast",
but agree it isn't really a great analogy for production, because it is about
learning.

What they mean is that you can't be fast (on a track) without being smooth,
and that typically beginner-to-intermediate drivers/riders are trying to be
fast in ways that make them _less_ smooth, and ultimately (and counter-
intuitively) makes them slower. So the advice is to forget about being fast
and concentrate on being smooth. The speed will come.

I do think this has value as an analogy for software, but it is in
concentrating on your tooling and methodology - smoother operating will
deliver real value faster than just trying to type fast.

------
ThalesX
For me, after years producing software, I've set myself up to be able to say
no.

I disregard urgency when it exists for urgency's sake, coming out of business
despair or a gut feeling. I will gladly work for 2 - 3 months on hyper mode,
giving away my mental and physical health for a feature that will actually
provide business value and for which the business can make a good case for why
it's needed yesterday.

Working with multiple companies on executive and / or consulting levels, I
feel like a lot of business rush is done because business 'needs it now' in
the _hope_ that it will improve the bottom line because it's easier to expect
a miracle than it is to take a good look at your fundamentals.

The businesses with the most solid foundation I find are the ones that rarely
need to rely on speed and instead rely on quality and produced value... once
in awhile, a feature idea comes up that can propel the company - especially in
the face of competitors - and it needs to be done as fast so that the producer
can get as much value out of it before the competition catches up. That's a
good reason to expect speed.

Today's society expects hyper growth, hyper speed, hyper scale, but that is
because this is what is mostly advertised and we as humans have a tendency to
expect the world to work as is advertised, when in reality, there are a lot of
smaller companies that don't create anxiety filled working days for their
employees.

~~~
ChuckNorris89
_> I will gladly work for 2 - 3 months on hyper mode, giving away my mental
and physical health for a feature that will actually provide business value
and for which the business can make a good case for why it's needed
yesterday._

I feel sorry for you.

As some who's been around the block a few times, I will never, EVER, give away
my mental or physical health for someone's business.

My health is more important than their quarterly targets.

~~~
vorpalhex
In defense of the parent, I can imagine a situation where I'm excited and
truly bought into a product as improving peoples lives and am willing to
expend the energy to dramatically improve that product in meaningful ways. I
think this is something a lot of folks in our industry want, and that's not
per se bad though it can lead to negative outcomes.

~~~
SomeOldThrow
This is giving money to the rich. Don’t put in any more time than you need to;
no product is worth that.

~~~
invalidOrTaken
It's not a war. The rich are to be feared and pitied, like all humans.

~~~
romwell
>It's not a war. The rich are to be feared and pitied, like all humans.

Fear and pity them all you want, but _your health is not theirs_. Don't give
away the only thing you truly have, and the only thing you can never really
get back.

------
jillesvangurp
Don Reinertsen has been making this point and uses economical arguments to
back it up:
[https://www.youtube.com/watch?v=L6v6W7jkwok&list=FL6P7ZzM6GT...](https://www.youtube.com/watch?v=L6v6W7jkwok&list=FL6P7ZzM6GT554-6xA_3lvjg&index=3&t=5s)

I love this presentation because it adds strong economic arguments to a lot of
practices that are quite common in software engineering but typically lack
good argumentation as to why they are good. He covers a lot more ground in
this presentation. Well worth your time if you are involved in any way in
planning software development. I love his notions of option value and cost of
delay. Cost of delay is exactly the economic argument why working quickly is
important. Once you get it, is obvious that you should do agile, release
early, and avoid embarking on long/uncertain refactoring/redesign efforts
unless you can justify the payoff.

In short, any development that ships early maximizes the useful economic life
on the market. If you ship something new earlier than your competitors, you
get to charge a premium until they catch up. At some point your new thing
becomes a commonality and the value drops. In some case, OSS just gobbles it
up and the value becomes 0$.

So shipping 3 months earlier means you get to earn revenue for 3 months extra
when it is still most lucrative. If you instead delay for 3 months because you
are doing some thing that make things better in some way, you have to consider
the cost of doing that AND the cost of missing out on that early revenue.

Don Reinertsen suggests you simply do the math consider the cost of delay when
e.g. deciding on a big refactor vs. a lets get this to market ASAP type
strategy. You don't even have to do a particularly good job at doing the math
to out-compete gut feelings here.

------
danielecook
Efficiency is also more important than it seems. You can have lots of low
quality, half-baked output. How much forethought do we put into what we will
work on to begin with? Some projects and ideas are not worth the effort. Or an
alternative solution to a problem is preferable over one you’ve been hammering
away at for days, and would be easier to implement.

And in the realm of programming, it’s often easy to take shortcuts even though
later on they wind up costing more time for you or others involved: omitting
documentation, not making something reproducible, poor code quality, etc.

Having spent most of my career in academia I see a lot of the work makes this
trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution.
You need to find a balance and think through problems, considering not only
what is immediately in front of you but also what you’ll be doing in a month
or year. Otherwise you’ll wind up with a project or codebase that begins to
drag your productivity and output with it.

~~~
sejtnjir
Not every product is maintained for years. In many cases it's good to be able
to choose between a quick solution and a good solution, as long as these are
concious decisions and some record of accrued technical debt is kept.

~~~
illuminati1911
Rarely if ever in the beginning of the project it's 100% sure or guaranteed
how long the project will be maintained. There might be some estimates, but in
the long run upper management might change their minds at any time and then
you are fucked if you didn't build robust architecture from the start.

At least according to my experience and everyone I know in the industry.

~~~
skohan
But there are so many counterexamples to that too. I worked on a project
following CI practices with a release every two weeks, and I can think of
plenty of examples where we developed a feature, tested it with users, and
scrapped it within a month. That team leaned toward strict practices, and we
wasted so much time on code review and documentation of small details which
only existed for a couple of weeks.

I also thing it is vastly overstated how difficult it is to incrementally
refactor a project which is "fucked". It's always possible to break it into
smaller pieces, and gradually improve the codebase until it is manageable and
easy to work with.

~~~
rooam-dev
The question is, if the project you worked would be a mess from the beginning,
would it allow your company to test and scrap features fast?

Yes, it's possible, but at what cost? E.g. long hours, unhappy devs,
implementation taking too long.

~~~
skohan
The point is there's a balance. I think it's perfectly reasonable to allow a
certain amount of technical debt to accrue, especially when prototyping new
features, and treat it as a priority to clear this debt by the time said
features become a dependency to other parts of the project.

It takes a bit more nuance to get a team to work that way rather than just
enforcing _Best Practice(tm) always_ , but in my experience it can be much
more productive overall.

~~~
stcredzero
_I think it 's perfectly reasonable to allow a certain amount of technical
debt to accrue, especially when prototyping new features, and treat it as a
priority to clear this debt by the time said features become a dependency to
other parts of the project._

The point of code quality is to enable the company to change its mind or add
new features. Over-perfectionism that gets in the way of this is going too
far. At one company I worked for, the policy was not 100% strict DRY. Instead,
we waited for 3 uses of the same idiom before we put it in the library. This
prevented the collection of too many trivial methods, while still giving the
benefits of DRY.

~~~
sejtnjir
Smart devs know they probably get the abstractions wrong until the third
iteration. This sounds like a sane policy.

------
lewisjoe
When I do dev stuff with a slight sense of urgency, the probability of my mind
wandering somewhere else goes down drastically.

At this mode, my mind uses all available time slots to make the best of them.
For example, by the time my program compiles, my brain visualizes possible
breakage scenarios and possible solutions, in case the compilation fails.

I could be on confirmation bias here, but this seems to be a neat trick to get
more things done.

~~~
amelius
Yeah, but could it also increase risk of stress, anxiety, burnout?

~~~
lewisjoe
True. Too much of anything is bad. I keep this mode on for as long as I don't
get mentally tired. Usually, that's a span of 2-3 hours.

Surprisingly, at the end of the day (typically after two/three of these zones)
I feel more fresh, satisfied and productive. But that's just me.

~~~
EGreg
Too much multitasking and producing software for years has made me feel this
weird thing:

Which is that all accomplishments are meaningless in the end. And we are just
getting older. Once a person dies they aren’t experiencing any stuff that came
as a result of their effort. They may as well have just messed around and had
a family sooner, or traveled, or not. It’s all meaningless anyway.

I can’t shake it. Anyone felt this way all the time? Any advice?

~~~
late2part
I used to feel this way, a little bit. Then I had a family and was glad to
have the financial security to provide for my family compared to so many
others.

So, consider your heirs, and work long enough to build a nest egg cushion the
devote time to having a wonderful spouse, making babies and enjoying them.

~~~
meowface
Note this advice won't apply for people who aren't interested in starting
families. Even for those in happy marriages, not everyone feels that
biological itch to have kids. And not everyone even feels the itch to marry.

~~~
late2part
Same here. It's not a biological itch for me, it's a desire to leave/change
something for this world. In my case, it's [adoption|stepkids|nieces|nephews].

------
skybrian
It seems like this should work the other way too? If you want to break a
habit, add a delay.

This seems like a good idea for a browser extension. Maybe sometimes you want
to undo the work that the website did making things go faster?

~~~
monsieurbanana
That might be a really good idea. Over the years I've tried multiple website
blockers, but I keep turning them off (no judgment please...).

Artificially slowing down those time waster websites instead might do the
trick. Not so slow it becomes unusable (or I'll turn it off) , but slow enough
that over time I start associating it with a bad experience.

~~~
adhdbrain
Try LeechBlock ([https://addons.mozilla.org/en-US/firefox/addon/leechblock-
ng...](https://addons.mozilla.org/en-US/firefox/addon/leechblock-ng/)).

It's been a lifesaver in tackling my internet addiction. It has the useful
'delay option' and other nifty features that helped wean me off social media
sites.

Personally, I have it installed on all my desktop browsers and Firefox on
Android. I give myself half an hour quota per day for the time waste websites
(Youtube, Twitter, FB, Insta, etc) after which a 60 second delay rule kicks
in. I've found that my monkey brain almost never bothers waiting for a minute
for the page to load unless it's absolutely necessary.

------
_____s
This is one of my favorite blog posts of all time. It's applicable not only to
just work work but a lot of other things, if you can shorten the feedback
loop, you get a much better chance to improve the end result. It affects
_everything_ else too.

~~~
hi41
You make a good point. How do you compare your idea to the one that we need to
take time to smell the rose? I think that idea suggests that we need to slow
down and watch the world more closely. Just wanted to know what you think of
that.

~~~
_____s
That's a great question! If I'm understanding it right, I think the two ideas
can complement each other. For broader goals or when you're totally clear what
you want to do and how you get there, it's fine to take time. Even then, you
can use shorter feedback loops to make the process more efficient.

Say you want to become a better writer. That's a broad goal and there are
several approaches you could take towards that goal. On one extreme, you could
read a lot about writing, write little, try to perfect things, and get
something out once or twice a month. On the other extreme, you may write every
single day and get it out in front of some people, get consistent feedback,
learn, and improve. Both of these approaches will take time… the second
approach, with the shorter feedback loop, can probably get you there faster
though.

~~~
hi41
Thank you for your thoughtful answer.

------
karmakaze
A counterintuitive thing I've discovered us that working fast let's you solve
more complex problems. At first it seems that you should try to go slow to
make sure that all the cases are properly treated. Proceeding this way can
result in nearly endless refinements as you go and losing sight of the main
goals from time to time and repeatedly forgetting exactly where you are in the
grand plan and which direction/step you were headed.

Going fast doesn't allow for secondary concerns and produces a single simple
solution. Of course you can now do everything else it needs that you think of
but code written this way with a clear core path is so refreshing from bottom-
up generation where every detail has equal importance.

I even recall a time where I was performing a cascade of rebases and merges
across three git branches and 4 or more submodule branches. Each feature
update/sync took so many tries to get right. I eventually got fed up and just
brute-powered through it without prethinking it. Because it was a short time
from start to finish I was able to clearly see each commit in each tree I was
working on without a pause wondering where I was or doing next. It was also
less error prone than going slow. It fact I just did the whole process twice
in a fraction of the careful time and compared results. No diffs were taken as
correct and any diffs were examined and the correct variant used.

~~~
stcredzero
_Going fast doesn 't allow for secondary concerns and produces a single simple
solution._

That doesn't sound like going fast, so much as "the simplest thing that could
possibly work." Once you have that running, you can see where the shortcomings
are and start to fix those. That will often proceed faster than trying to
envision the whole complex thing up-front. (And that often results in a
complete, but illusory vision, which ignores something which only becomes
apparent once it's realized.)

~~~
karmakaze
This is absolutely true. I'll usually have mulled over a problem for a long
time before writing any code so have a sense of some of those other areas and
have imagined mechanisms to handle some things. When it comes time to
implementation, going fast focuses on the key ones.

------
rb808
Actually this is great advice, I should do it more. I already found it was
great writing essays back in school - instead of painfully trying to be
perfect, just knocking something out becomes a first draft. Same with getting
kids to tidy the room, making it a fun race instead of slowly considering each
piece gets chores done more quickly.

------
alimbada
Work fast, don't think things through, make mistakes, pay for your haste by
spending more time fixing your mistakes than you would have had you thought
things through.

~~~
avip
Measure once, cut twice, earn one to throw away.

~~~
skohan
This is a bad analogy for software. One of the unique properties of software,
compared to other crafts, is that the material cost of iteration is virtually
zero. We should use that to our advantage instead of pretending we're
carpenters.

~~~
kdelok
Even using the carpentry analogy, I suspect the point is to avoid ruining
something on which a lot of time was spent. The material cost of most raw
materials isn't very high, but ruining something you've already spent hours
crafting is extremely costly.

The other thing to bear in mind is that there is always more work to be done
than time to do it. You have to factor in opportunity cost. As many other
commenters have said, ultimately it's a balance which depends on your
company's particular situation.

~~~
skohan
> The material cost of most raw materials isn't very high, but ruining
> something you've already spent hours crafting is extremely costly.

Thanks to version-control software it's also incredibly cheap to experiment
freely with an existing code-base in a completely non-destructive fashion. I
see no reason to treat existing code as fragile or precious.

------
IanCal
> But it does mean, push yourself to go faster than you think is healthy

I really disagree with this. Aiming for something you _actually think is
unhealthy_ means you either think you should be working unhealthily ( :( ) or
you don't trust your measure of healthy (in which case recalibrate that).

~~~
munificent
I wouldn't read too much into the word choice there. "Uncomfortable" is
probably a better way to say it.

------
mnort9
Speed derived from managing scope is the real value IMO. It's not about
working faster, but rather minimizing scope constantly to ship faster and
collect feedback.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=10020827](https://news.ycombinator.com/item?id=10020827)

------
username90
My view is that all programmers produce roughly the same amount of bugs per
hour, it is just the bugs per feature which differ. Of course bad programmers
can spend a lot of time fixing bugs as they go making the end result have few
bugs, but still the main time-sink is fixing all of those bugs.

So to become fast, learn to write code which is very easy to verify that it
works. If you get surprised when things work the first time you try then you
are not fast.

------
hinkley
Meanwhile there are martial arts and other physical disciplines where you go
slowly to make sure you train the muscles along the entire movement instead of
going in jerks and starts (which is how you damage yourself).

Fast iteration isn't about doing things faster. It's about requesting
_feedback_ more frequently. Which often means doing less, not more, and then
evaluating the _effectiveness_ of that small amount of work. Then adjusting
your plans.

In writing, doing an entire book before your editor can tell you you're
accidentally stealing a storyline from another author is bad. His analogies
seem to be equating to this sort of behavior but missing the cause.

------
piyush_soni
Oh please. Our whole product is a side effect of "working quickly", and it's
anyone's guess how difficult it is to make any change in that now.

~~~
lnsru
I have a different experience. I did lots of well thought work, that after
management decision ended in the thrash. I prefer “working quickly” now, if it
doesn’t end in the thrash, I can fix it later.

~~~
skohan
Yeah the farther I have gotten in my career, the more I ascribe to a
disposable code philosophy. Of course it doesn't mean that it's a balance, and
there's a time and a place for structure and thinking about design, but that
is almost always done better when you have a working prototype than when
you're starting something from scratch.

~~~
beat
If your code doesn't kinda suck, you're putting too much effort into the code
and not enough effort into the problem. It's weird, but important to learn.

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

And I thought they wanted argue for faster replies...

But I think there is some truth to that. If a task seems overwhelming, it can
sometimes help to look back at something you already completed.

I don't have that impression for programming at work, since I have a set
schedule anyway, but for projects outside of that the kick-off seems to be the
hardest part in awe of all the work before you. But then there is all the
projects you already completed, which were mostly labor intensive as well.

~~~
skohan
I think timing is so important with communication. Even sending a message like
"got it, I will get beck to you tonight" within a couple minutes makes you
seem a lot more responsive than a more detailed message an hour later.

------
mellosouls
For anybody reading the comments here without reading the article, and
assuming some toxic-management-friendly nudge to burn-out style working (as
implied by some of the comments); it's actually a very useful and thought-
provoking self-help essay that may help as a tool against procrastination.

------
kstenerud
"when you punch someone you need to pull your arm back, before you launch it
forward. If you don’t your hit will be weak."

It's a cute way to think in opposites, but unfortunately as punching advice,
it's untrue. Punch force comes from body mass x acceleration, not arm mass x
acceleration.

~~~
onion2k
Bruce Lee taught a martial arts technique that relied on _not_ pulling back
first - [https://en.wikipedia.org/wiki/One-
inch_punch](https://en.wikipedia.org/wiki/One-inch_punch)

~~~
kstenerud
It's also the basic premise of punching in Western boxing.

~~~
User23
It’s almost as if it were basic lever physics

------
spineboy
Speed matters in other fields as well. I'm a former academic surgeon, now in
semi private practice.

I would a always tell my residents that to start a medical practice, the 3
"A"s are important, and in this order. Availability, affabilty, and then
ability.

People have a problem, and they want it taken care of. If you can be that guy,
or company, that's there for them, then you'll get there business in the
future, as long as you do a good job.

------
vikingcaffiene
This post is so wrong headed and misguided that it borders on parody.

Some choice quotes from the post:

> It is a truism, too, in workplaces, that faster employees get assigned more
> work.

> 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.

> push yourself to go faster than you think is healthy.

Dude that’s not a feature. It’s a bug.

------
andy_ppp
I always think together with do stuff faster, "do the simplest thing you
possibly can" and "write less code" both allow you to develop, iterate and
feedback faster overall. Without the other two you'll eventually hit the wall
of too much complexity to keep going fast.

------
lootsauce
Delivering on time is good, having expectations set properly in the first
place is better.

Working fast can be good, solving the right problem at any speed is better.

Personally I have not found my speed matters so much as my mental state. When
all the things come together, I know what problem I'm solving, I know how to
solve it, I have time to focus on it for many hours... That is when I can
enter a state of flow and build a great head of steam productivity-wise.

Finally I think continued long-term attending to something can trump speed and
overcome all kinds of obstacles that prevent progress at all let alone
progress at some arbitrary sense of fast.

------
AtlasBarfed
What is "speed"? What is "quickly"? What is "fast"?

As Carlin said, any person driving faster than you is a maniac. Anyone driving
slower is a moron.

------
pdsouza
I think we can all agree that we want to maximize the quality of our work,
where quality is defined as how well our work satisfies our goal. Typically,
the discussion is around speed vs. quality, but I think quality itself
encompasses speed (time_to_market below):

quality = w_0 * time_to_market + w_1 * correctness + w_2 * performance + ...

The weights w_n vary across domains. As with most things, it's about finding
the right balance.

------
rossdavidh
Interesting post (esp loved the ending), but it missed two key points: 1) if
you want less of something (e.g. email), you don't always have to say 'no', if
that's a problem somehow you can also just deliver slowly 2) the best way to
do things quickly is not to hurry, it's to break it into smaller pieces
whenever possible, so that each piece is delivered quickly

------
EGreg
When I was a teenager I realized a good puzzle that’s a metaphor for this
trade-off. Can someone solve it and generalize it?

1\. Suppose you want to draw a line N pixels long. It costs X to draw a pixel,
Y to copy and Z to paste. What is the cheapest (fastest) way to build the line
as a function of N?

2\. So I think in general, you may start slow, but them exponentially speed
up, overtaking the spaghetti architecture guy.

------
submeta
Responding to emails quickly may make the other person happy, but it will
create a mechanism that will interrupt you regularly. Peter Drucker - an
author who has written many books about management - says that you need large
amounts of uninterrupted time to get work done.

------
playing_colours
Mind a situation and consequences.

Working quickly helps you validate your idea fast and iterate.

Working quickly can also mean not putting enough thoughts into planning and
researching, so you just waste your money, your time, or your credibility
faster.

Working quickly can get you promoted.

It can also ruin your health and personal life.

------
awaaz
In the context of startups, speed definitely does matter. Reminds me of
something PG used to say at YC - "if at some point you don't feel ashamed of
what you released, then you released it too late" (paraphrasing).

------
scelerat
Ugh. Agree with caveats: I’m often put in the position of being the “slow” guy
because I have to fix all the stuff the “fast” guy did, but I have to do it
while everything is up and running with paying users.

------
gatestone
Now I just need to know how to become fast. The article did not tell.

------
zuhayeer
Crazy, the power law exists even in speed

------
andrewstuart
That's why the thing about "premature optimisation is the root of all evil" is
mistaken and wrong in these modern times and yet many people still quote it
and take it to heart and as a result don't prioritise speed when building
software.

"premature optimisation is the root of all evil" is a saying that came from
1974 when computers were slower, languages were less effective and development
processes immature. Today you should make your software fast.

~~~
codegladiator
Wouldn't modern times make it more relevant ? I would choose "don't worry
about speed, make it happen first".

~~~
andrewstuart
No I think speed is a primary feature, not a secondary one. As the article
says, users relate completely differently to a responsive application.

~~~
codegladiator
The point remains that modern hardware is already super fast. Besides,
avoiding "premature optimization" is to avoid efforts to speed up parts of
your code which were never a bottleneck. No one is arguing for writing slow
code.

