Comment by thom | Hacker News Reader

Comment by thom | Hacker News Reader

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

“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

Works well for a warrior (where 7 breaths is a long time) - but not so much most business leaders/managers. After witnessing it so many times, I'm guessing the standard playbook they teach at business schools is "Don't bother taking time to understand a situation - just make a decision unnecessarily quickly and over-confidently, and then stick to your guns no matter what".

So much wasted effort results... but, hey, at least I got paid for it. And now I make sure I don't work anywhere where they run this playbook anymore!

Every set of aphorisms contains these contradictions, eg "Look before you leap" and "He who hesitates is lost".

Maybe some bosses think of themselves as warriors.

They act fast and self assured to assert dominance. The one who speaks loudest first wins.

This behavior can be observed in chimps too, often the most dominant male performs the most amazingly loud and aggressive acts.

In environments that are more collaborative and less hierarchical it’s different. Ideas, not humans are competing and different approaches merge.

I don’t want to bash on chimps here. That would be unfair.

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

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.

By nature we choose the path of least resistance. Because it’s easier if possible. It costs less.

We are also always trying to navigate the world constantly, and talking is a way to test our world view against other people. This is why we talk.

So; Talking (articulating the world view) and hopefully getting a affirming response to that is less expensive to our system than throwing away that paradigm and learning a new one.

I agree with the first part of what you said, but I don't think plain listening is a "new paradigm", albeit I'll grant that it's probably a skill that can be improved.

to circle back to the original topic of understanding the problem, a big part of that is being observant and attentive to the needs of users. In that context and using your framing of this in terms of cost and resistance, I agree that simply talking and stating opinions is far easier than shutting up, talking to users, and gathering real information about what they actually want

it really sucks and I feel it's gotten worse with zoom. Sitting in retro meetings in the past year I've definitely noticed an uptick in people just talking and not actually responding to what someone just said. very frustrating.

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.

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.

Yes, and I’d add that the best rule of thumb is to make decisions based on optionality; minimum costs/risks with relatively large upside.

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

> 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

I think the point is that people focus too much on the tech solution and not enough on the system into which the tech solution will be introduced.

There's this idea of "problem holder" that Walt Beleyer at Sandia National Laboratory talks about. Holding the problem and deeply understanding is sometimes neglected in the rush and joy of building. Fwiw, I wrote a post about that here:

https://vonnik.substack.com/p/a-building-complex

I've found the multiple contradictory sayings ("don't force it", "where force doesn't work, more force will", "doing nothing is better than doing the wrong thing" and its reverse) useful as a way of characterizing the problem space. ie in positions of uncertainty, figuring out which proverb applies is a great framework for approximation.

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.

Agree, or I would just say “just never give up trying” because they might be working on something stupid and they should sometimes pivot/give up this one but not all together. That’s really the only universal advice imo.

How about make lots of mistakes, but (a) don't repeat them and (b) nothing fatal?

You could probably poke holes even then, because something that's a mistake _now_ might not be a mistake later.

observe–orient–decide–act

Reply on news.ycombinator.com