31–40 of 228 posts
Earlier quoted context omitted.
Creating code is the lowest level of programming. Deleting code is much more refined. Preventing code is sublime.
This leads to analysis paralysis. Building things helps you think clearer.
Earlier quoted context omitted.
Creating code is the lowest level of programming. Deleting code is much more refined. Preventing code is sublime.
Is this true? I find creating, then deleting to be more grounding. Explore a couple paths and pick the good one, don’t just stay home.
Sadly, I failed at preventing it, so the team spent more than twice as long as (they) predicted to build something half as functional and surprise, no v2 will happen.
So it's not "ok to fail" this week?
I think this is very true, I've found the same thing in e.g: - Simracing: getting faster doesn't make you win races. Getting more consistent does. - Squash: getting stronger and faster doesn't make you win games, getting less exhausted does, because you make less mistakes. These are surely not true when you're at a high level, but for most people it's the right focus. The corresponding insight for building software i…
I don't know what you mean by high level, but I suspect that avoiding mistakes continues to be very important regardless of level in most things.
I play Marvel Snap in the top 1000 and at that level most of the games comes down to whoever makes a mistake first loses.
Few startups fail due to #1-3 after achieving #4. So many startups blame #1-3 because they couldn't find #4. If you don't have PMF, you're burning cash, pivoting, arguing (founder disputes) to figure out your way there. All #1-3.
PMF is incredibly hard and don't let anyone fool you.
I think this is very true, I've found the same thing in e.g: - Simracing: getting faster doesn't make you win races. Getting more consistent does. - Squash: getting stronger and faster doesn't make you win games, getting less exhausted does, because you make less mistakes. These are surely not true when you're at a high level, but for most people it's the right focus. The corresponding insight for building software i…
It is trivially true at all levels - anything that leads you to lose a game can be construed as a mistake, so if you make no mistakes and you lose then the game has been solved (which Chess has not been) or was unwinnable. The mistakes just get smaller and fewer and fewer people can recognise them.
this is the greatest article i ever read on HN in the past 12 years i been coming here
Earlier quoted context omitted.
if no one is competing with you, it doesn't matter too much how good you are. Temporarily. Once people see you're doing well with no competition the competition will spring forth, no matter how good you are. If you're also doing things badly those competitors will eat your lunch. That isn't a reason not to launch when your product is very basic and scrappy. You don't need to make it good, and definitely not perfect.…
Unless your first mover advantage lets you just stay there for decades. See: PayPal they have only now been dethroned as the default credit card processor despite being awful to work with when I tried to integrate their API circa 2010
Setup was harder, and the integration wasn't the same, but it was before PCI, so integrating with CyberCash meant you could own the whole payment flow, and have a better experience than PayPal, where you send the user off, and when they come back, PayPal may not have confirmed payment yet.