[HN Gopher] Move fast, but understand the problem first
___________________________________________________________________
Move fast, but understand the problem first
Author : d4rkp4ttern
Score : 163 points
Date : 2021-06-30 17:59 UTC (5 hours ago)
(HTM) web link (jacobobryant.com)
(TXT) w3m dump (jacobobryant.com)
| cbsmith wrote:
| I don't understand how people take "move fast" and interpret it
| as "move fast with no understanding". The whole point is to "move
| fast towards understanding". If understanding isn't the goal
| here, that leaves all the activity as little more than stirring
| your mixture to accelerate Brownian motion. It seriously
| undermines the mystique about intelligence being in any way
| involved with the tech industry.
| doytch wrote:
| Self-selection bias. Clearly those who love the saying are
| predisposed to move fast. But they move so fast they haven't
| had a chance to understand the saying!
| cbsmith wrote:
| > Clearly those who love the saying are predisposed to move
| fast.
|
| I don't think that's clear at all. Many "loved" sayings are
| "loved" because they help spur one into behaviours one
| otherwise would not partake. If you think about it, sayings
| about predisposed behaviour can often seem unremarkable. It's
| like corporate values: the published corporate values are
| ultimately as much aspirational as actual, because the purely
| "actual" values are assumed. (For the same reason, if you ask
| someone what is most important to them, no one says
| "breathing" or "air".)
|
| > But they move so fast they haven't had a chance to
| understand the saying!
|
| Iterating on NOOP can be done a lot faster, and at much less
| expense, than iterating on something; I'd like to think the
| eventual steady state of such folks will be to do absolutely
| nothing very, very quickly. ;-)
|
| Hey, human reasoning can take you to some dark places, so I
| don't begrudge people where they end up. I'm just confused by
| how... broad? the phenomenon is. I'd expect some kind of
| Darwinian forces/selection bias that would eventually
| relegate such thinking to a quite corner of the universe.
| im_down_w_otp wrote:
| When your KPIs are "velocity" and your measurements of that KPI
| are duly myopic, then all your local incentives are best served
| by the fastest random walk to nowhere in-particular.
|
| I've observed this most pathologically at organizations running
| the "hyper growth" playbook.
| tehlike wrote:
| This is a good read on the topic:
| https://commoncog.com/blog/action-produces-information/
| runawaybottle wrote:
| The key to this approach is basically pacing. If we think about a
| birthday cake and apply 'measure twice, cut once' to the actual
| cutting of the cake, this would be a waste of time. However,
| 'measure twice, cut once' for getting the ingredients right
| before baking is critical.
|
| This is usually a critique of younger star athletes where they
| only have one gear when they first come into a league (usually
| that gear is just pedal to the metal). It takes a little bit of
| time to understand how to adjust pace so as to be able to move
| quickly in some phases, and slowly in others.
| lmilcin wrote:
| It is ok to cut corners as long as you spend a little bit
| understanding what would be the correct solution and what is it
| going to cost/benefit you.
|
| I have a notebook with all corners we cut at my current project.
| Also a bunch of other stuff (like various types of problems). The
| new designs are getting evaluated against my notebook.
|
| I know it sounds funny but I just can't get into agreement with
| other people on how to make notes of technical debt and so, not
| wanting to spend too much effort on it, I just made it a notebook
| which I am diligently filling whenever I hear something that I
| would like fixed.
| andreacavagna wrote:
| I just lived this on my skin.
|
| My team and I, 4 engineers, we focused for about 2 years only on
| moving fast, and moving on doing a feature battle with the
| competitors.
|
| After all this this we stopped and restarted a new journey
| focusing on things that really matter: - Why - How - What Are we
| doing it, and it changed everything for us.
|
| My teammate has posted the story of the last 7 years of my team
| today, i give you the link if you are interested in knowing more:
|
| https://medium.com/leapp-cloud/road-to-noovolari-89df7704e31...
| lapp0 wrote:
| Absolutely riveting and insightful article, this one.
|
| Who'da thought it that to get stuff done quickly but correctly,
| ya gotta move fast, actually do things, but also think about what
| you're doing. Mind = b l o w n!
| didibus wrote:
| > to get stuff done quickly but correctly, ya gotta move fast,
| actually do things, but also think about what you're doing
|
| As much as this seems self-evident, I think it's worth saying
| it explicitly, because I do think a lot of people skip the
| thinking and sometimes even the doing, and end up just moving
| helplessly in urgent nonsense that takes you nowhere, doing
| nothing more than panicking.
| SN76477 wrote:
| It is how we are wired. To be honest, deep thinking is hard,
| like really hard.
|
| Only though experience do we know what is and is not worth
| our time (and thinking)
| 29athrowaway wrote:
| There is no "one size fits all" problem solving approach that is
| optimal for every problem.
|
| Sometimes "measure twice cut once" makes sense, sometimes it
| doesn't.
|
| My standard is that by the time you finish, you should understand
| the problem as well as how your solution works.
| legitster wrote:
| I get the sentiment, but 9/10 you won't actually understand the
| problem until you actually work on it. Work leads to
| understanding but understanding usually doesn't lead to work.
|
| The counter to this are stories like Stripe. Collison has
| famously said they never would have started the company if they
| actually knew how hard the problem was when the started. They
| identified the problem and committed to solving it. But jumping
| in blind increased their chance of actually making something
| unique instead of just another credit card gateway.
| areichert wrote:
| re: Stripe, it feels like what was more important was that they
| understood that what they were working on truly _was_ a problem
| -- I don't think the point of the article is to say that you
| need to completely understand every nuance of the problem
| you're solving before you can move fast, but that there's a
| base level of understanding you need to have in order to be
| effective (which is probably less common in founders/startups
| than most people think) -\\_(tsu)_/-
| gmfawcett wrote:
| Not sure it counters the story, it just sounds like selection
| bias -- for every Collison that won big, there must be a
| hundred shadow Collisons who jumped in blind but failed. I
| totally agree with your first point, though.
| cbsmith wrote:
| A hundred would be understating it. Thousands easily.
| cbsmith wrote:
| > I get the sentiment, but 9/10 you won't actually understand
| the problem until you actually work on it.
|
| Yes, but the "work on it" should be designed so that you
| progress in that understanding. Too often it does not.
| throwawayboise wrote:
| Usually the people asking for the solution don't even really
| understand the problem. How often are your probing questions at
| a requirements-gathering meeting met with "we'll have to get
| back to you on that"
| thom wrote:
| I think it's very easy to make folksy intuitive sounding rules
| from almost any angle here, and none of them are really
| definitive because the world is infinitely complex. Move fast,
| but not too fast. Think, but not for too long. Do, but not too
| early or too late. I don't think there is a one size fits all
| answer for any person or organisation.
|
| I think the correct fundamental framework, which is compatible
| with all sides of the argument, is that you must be mindful of
| your learning rate. Some approaches are depth first - perhaps
| that depth is satisfactory to learn what you need to solve real
| problems. But perhaps what you actually need is breadth. There is
| no way to say which is right - you literally have to just stress
| it out, it's not fun. Some problems only yield information when
| you have skin in the game - there's no way to reason out the
| right approach, you need to push at real boundaries and see what
| happens. Some of the boundaries, all of the boundaries, keep
| pushing, take a pause... again, you can't know for sure what's
| right. All you can do is constantly ask yourself - am I learning?
| Am I generating hypotheses, testing them, proving at least some?
| The framework is different for everyone, and it's _work_.
| tomrod wrote:
| "In the words of the ancients, one should make his decisions
| within the space of seven breaths. Lord Takandobu said, "If
| discrimination is long, it will spoil." Lord Naoshige said,
| "When matters are done leisurely, seven out of ten will turn
| out badly. A warrior is a person who does things quickly.
|
| When your mind is going hither and thither, discrimination will
| never be brought to a conclusion. With an intense, fresh and
| undelaying spirit, one will make his judgments within the space
| of seven breaths. It is a matter of being determined and having
| the spirit to break right through to the other side."
|
| - From the Hagakure
| catwind7 wrote:
| it seems to come from the same place of wanting a simple rule
| to pattern match against some problem space so we don't have to
| think too hard about it every time.
|
| also ... the author cites sam altman as evidence that his
| thinking is on the right track, but can you really argue
| against a statement like "Almost everyone I've ever met would
| be well-served by spending more time thinking about what to
| focus on"? that's about as close to a one size fits all
| statement as "almost everyone who succeeds thinks"
|
| i sometimes wonder if this comes from a place of fear. Maybe
| we're scared of really listening to customers / users /
| colleagues / stakeholders and so we invent these rules to hold
| ourselves accountable for what's probably pretty obvious from
| the outside
| kthejoker2 wrote:
| I'm a consultant, been on thousands of calls with customers,
| partners, colleagues ... after all this time it is still
| truly astounding how many people wait to talk instead of
| listen, and cannot or will not exhibit professional empathy
| and curiosity.
|
| It truly is just not in our nature.
| didibus wrote:
| To me, the secret is being okay with failure, learning from it,
| than trying again.
|
| I've heard this called the Feynman technique before. Pretend as
| if you know what you are doing and what to do, than start doing
| it as if you knew how, and each time you fail or realize you
| don't know how to proceed, stop, go learn only as much as you
| need too unblock your next step, rinse and repeat.
|
| It's a really good way to eventually learn and succeed, while
| wasting as little time as possible.
|
| The issue is that, when it comes to software development, where
| you need to build upon what you've done before to keep moving
| forward, the risk is that all your prior steps weren't
| considering your next ones, and at the time you built them you
| didn't really look further, you were focused on figuring out
| only the next move pretending you knew it all.
|
| So in a startup setting, it kind of means that if you follow
| this technique, you'll quickly learn and figure out what and
| how to do things, but you'll also fail a lot, and those
| failures will pile up, and all you built during that process
| might not end up being usable in the end, as it could be a
| monster of tech dept, limitations and bad decisions.
|
| That's where a lot of startup have a "big rewrite" phase
| normally.
|
| This still works if you are okay with having that big
| rewrite/refactor phase, and as long as your monster was still
| good enough to carve you a big customer base or investor
| interest, that'll be patient enough to wait for your rewrite.
|
| I'm not sure how to summarize this, but there are some problems
| that each step you take you've now advanced closer to the
| solution, so it's fine to not think holistically about it all,
| but focus one thing at a time. While there are other problems
| where that only take you so far, and at some point you have to
| think holistically, do I need to do anything about this
| foundation in planning of what I'll later build upon it? That
| kind of thing.
|
| But I think often what happens is people are too afraid to
| fail, and they start thinking holistically, except they
| actually are not expert enough to be doing so. So they start
| thinking all hypothetical, imagining the problems that will
| come, and that all ends up a waste of time.
|
| If they'd tried, tried and tried some more, then they'd
| actually have learned a lot, and now would possibly be on a
| place to actually think holistically.
|
| I heard a pretty good saying on that:
|
| "The difference between the master and the beginner, is that
| the master has failed more time than the beginner has tried".
|
| I think it's by Stephen McCranie
| MaxBarraclough wrote:
| > To me, the secret is being okay with failure, learning from
| it, than trying again.
|
| But that's just what thom's talking about. Sometimes you need
| to know when to quit.
|
| I'm not normally one to link to Dilbert, but:
| https://dilbert.com/strip/2012-11-20
| dalbasal wrote:
| The wisdom of folksy statements is usually a distillation of a
| morality tale of some sort. Reasoning about them in the
| abstract is missing the point. It isn't a pure logic kind of
| exercise.
|
| Anyway, discussing the wisdom rally cries, 15 years later...
| Most business wisdom is temporal. What applies to a >10 person
| startup hoping to raise $4m by the end of 2006 may not be the
| applicable wisdom today.
| karaterobot wrote:
| I don't think this is advising you to spend _all_ your time
| understanding the problem. Clearly, you can 't ever have
| perfect information, and you can waste your time in analysis
| paralysis.
|
| I read this post as saying that, given how product development
| is path-dependent, most people should do a lot more up-front
| discovery work than they are today.
|
| What I mean is, it's empirically very rare for people to just
| throw away a bad idea: they're more likely to modify it, pile
| more features on to it, or just delude themselves into thinking
| it will work eventually. But, usually it doesn't.
|
| We can say "be willing to throw it all away and start over when
| you learn new information", but in practice people don't do
| this. So, it might be more effective for most people to do,
| say, 50% more up-front work than they're already doing to de-
| risk their ideas before committing anything to them. It's
| clearly not a guarantee of success, just a way to improve your
| chances and save your own time.
| bsder wrote:
| I would distill startup advice down to: "Survive. Period."
|
| You win the startup game by being in the right place at the
| right time. The longer your survive, the higher your odds of
| being "at the right time".
|
| Most "overnight successes" were 10+ years in the making.
| skeeter2020 wrote:
| How about make lots of mistakes, but (a) don't repeat them and
| (b) nothing fatal?
| thom wrote:
| You could probably poke holes even then, because something
| that's a mistake _now_ might not be a mistake later.
| capnorange wrote:
| most problems in startup like environments(particularly from my
| experience in social networks), "understanding the problem" is
| not as easy. That's why trial and error, moving fast works.
| _wldu wrote:
| Great advice. Anytime you do things quickly, it's best to
| carefully understand the details of what you are doing, otherwise
| mistakes are made and/or accidents occur.
| civilized wrote:
| Do everything that is good to do, but first do every other thing
| that you need to do before.
| swframe2 wrote:
| (maybe off topic; these questions are highly subjective) I wanted
| to get your opinion on this situation. In the group I work in,
| almost all the high impact projects are assigned to foreign
| educated coworkers partly due to their faster execution pace. Do
| you think foreign educated engineers in your group/company
| execute at a faster pace than engineers educated in the US? I've
| wondered if the highly competitive educational paths foreign
| educated coworkers have had to take is a "filter" so those who
| eventually "make it" to the US are a very unique subset.
| Basically, do you think there are issues (for non-foreign
| educated engineers) with project assignment and performance
| ranking because of this at your company?
| areichert wrote:
| As a programmer-turned-founder, this is something I have to
| remind myself all the time... it's often very hard to resist the
| urge to just keep coding and launching and throwing things at the
| wall until something sticks, because that's what I'm "good at"
| and it creates an illusion of productivity and "moving fast".
|
| It seems like some people are commenting that the advice in the
| article is common sense, but I think when your mindset is to move
| fast, it can be easy to delude yourself into thinking you
| understand a problem when you're really just married to an idea
| but too scared to go out and discover whether it's actually
| solving something real or not.
___________________________________________________________________
(page generated 2021-06-30 23:00 UTC)