Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoid blundering: 80% of a winning strategy

longform.asmartbear.com

Post reply on HN
Print view View original

91–100 of 228 posts

Re: Avoid blundering: 80% of a winning strategy

#91

Post by sjducb »

janalsncm wrote: post #57

> the player who committed more blunders lost 86% of the time In some sense this is almost tautological. While finding an exact definition for a chess blunder isn't straightforward, here is one example from the Lichess UI: https://github.com/lichess-org/lila/blob/b527746b179cdde6438... Basically, if you make a move which decreases your winning probability more than 14% over the best move, that's a blunder. But winnin…

The point is that you are in control of whether you blunder or not. It’s more important to avoid obvious mistakes than to have a good strategy.

Re: Avoid blundering: 80% of a winning strategy

#92

Post by CuriouslyC »

otterley wrote: post #31
Jensson wrote: post #18

Earlier quoted context omitted.

This leads to analysis paralysis. Building things helps you think clearer.

I’ve learned at Amazon that writing about what you want to build, and why, and why not do something else - in a way that others can clearly comprehend, and before ever touching a line of code - helps you think even more clearly.

While I disagree with this approach in general - manually executing a task and following the data flow is the best way to understand a new system - I will say that with the rise of LLMs, writing documentation, stubs and comments first may be the fastest way to bootstrap a new project.

Re: Avoid blundering: 80% of a winning strategy

#93

Post by AnimalMuppet »

chplushsieh wrote: post #53
ycombinatrix wrote: post #6

Earlier quoted context omitted.

link please

Not GP, but perhaps this is the post: https://longform.asmartbear.com/two-big-things/

That doesn't say they're avoidable blunders. It says that they cost time and energy, and therefore preclude other opportunities.

But is having a good marriage a blunder compared to having a great career? I don't think he's saying that.

Re: Avoid blundering: 80% of a winning strategy

#95

Post by marklar423 »

exceptione wrote: post #63
otterley wrote: post #31

Earlier quoted context omitted.

I’ve learned at Amazon that writing about what you want to build, and why, and why not do something else - in a way that others can clearly comprehend, and before ever touching a line of code - helps you think even more clearly.

I am interested, is there some public material about this method?

It's basically just writing a design document; Google has a similar culture.

I suppose if you're not actually showing it to anybody it becomes rubber ducking via design document.

Re: Avoid blundering: 80% of a winning strategy

#96

Post by AnimalMuppet »

ikekkdcjkfke wrote: post #12

So it's not "ok to fail" this week?

I think that's "fail" in a way that's different from "blunder".

Let's say I'm a programmer. I try an approach. It doesn't work. I realize it doesn't work and back out my changes. That's a failure.

Let's say instead I try an approach. It' doesn't work. I keep trying to force it to work, distorting the overall architecture and still leaving an unreliable, unmaintainable mess. That's a blunder.

Re: Avoid blundering: 80% of a winning strategy

#97

Post by gizmo »

The author seems to be at Elo 1100. At this level players don't think even a single move ahead and blunder their queen every other game. Slightly better amateur players realize that they should trade pieces once they're ahead to get to a winning end game.

Avoiding blunders only works at chess at the lowest levels. It's the same for tennis. Complete amateurs can win just by returning the ball but at higher amateur levels you will have a bad time if you try this.

Re: Avoid blundering: 80% of a winning strategy

#98

Post by taneq »

otterley wrote: post #31
Jensson wrote: post #18

Earlier quoted context omitted.

This leads to analysis paralysis. Building things helps you think clearer.

I’ve learned at Amazon that writing about what you want to build, and why, and why not do something else - in a way that others can clearly comprehend, and before ever touching a line of code - helps you think even more clearly.

Maybe it does for some people but based on all of the functional specifications I've implemented over the years, they are by far the exception. Maybe designing and documenting first is OK if it's done by people who've already learned how systems work by building and maintaining a lot of them, though.

Re: Avoid blundering: 80% of a winning strategy

#99

Post by ambicapter »

Jensson wrote: post #18
none_to_remain wrote: post #13

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.

You can build a ton of things and not put them in production (to then pay the price of what you built). Practice makes perfect then.

Re: Avoid blundering: 80% of a winning strategy

#100

Post by gadders »

Eric Sink from Source Gear made a similar point in a 2005 (I'm so old) essay explaining competition and business topics to developers via sports/game metaphors:

https://ericsink.com/articles/Game_Afoot.html

"The thing I find most interesting about Ping Pong is that you can often win without doing anything fancy or aggressive. A lot of players think the way to win is to slam the ball really hard. The problem with this strategy is that a slam is a high-risk/high-reward shot. If you do it right, you almost certainly score a point when your opponent fails to return the ball. If you do it wrong, you give your opponent a point.

Modesty aside, I consider myself a "pretty good" Ping Pong player. I can slam the ball when necessary, but I hardly ever do. I can beat most other players by simply returning every shot with a little backspin. Hitting the ball hard simply isn't necessary. All I need to do is wait for the other player to make 21 mistakes.

How software is similar

You can beat a lot of competitors by simply not beating yourself. Most companies go out of business because of their own stupid mistakes, not because of the brilliance or strength of their competitor. Stay conservative, and stay in business. Watch the years go by, and you'll be surprised how many of your competitors come and go."

Post reply on HN