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

A Few Rules

collaborativefund.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: A Few Rules

#31

Post by cobbzilla »

watwut wrote: post #11
themodelplumber wrote: post #5

Behaviors and outcomes rarely change, but history is driven by surprising events...? I admit that this juxtaposition of the listed rules confuses me. The first part/rule would seem to indicate that history is driven by predictable, probable, or otherwise bell-curvy events.

Civil rights movement was started by Rosa Park sitting on the bus. It was surprising big event. Most characters in that story kept going by same scripts as before, with only slight variations and only little bit of learning from previous experiences.

Claudette Colvin [1] did “the bus refusal” nine months earlier. Alas Claudette was not a sympathetic public figure (she had an affair with a married white man), so the NAACP engineered a re-enactment with Rosa.

I think what Colvin did took much more bravery. And in providing inspiration for Parks’s actions, she’s an under-appreciated hero of the civil rights movement.

[1] https://en.wikipedia.org/wiki/Claudette_Colvin

Re: A Few Rules

#32

Post by codr7 »

powersnail wrote: post #21
narag wrote: post #17

Earlier quoted context omitted.

Most fields have only a few laws. When I've had the opportunity to talk with true experts in different fields, I was surprised to find that they tend to focus in very few factors, unlike books or other practitioners. Wasn't Karate Kid training something like that? The master was only interested in a few exercises that were done doing repetitive tasks apparently unrelated to fight.

That’s probably because the experts are focused on their current task at hand, and most easily recalled the few things that are relevant to the task. Movies and stories don’t portray real life experience, as they cannot juggle all the relevant factors of an expertise without confusing the audience. I don’t know about martial arts. But at least in the few professions I do understand, you cannot just do a few exercises…

What about code katas?

I have five or so software designs that I've implemented several times for practice. A database, a bytecode VM, a serverside web framework etc.

I'm not so much porting them, rather trying my best to reimagine them in a new context. It helps me see similarities and differences between languages/platforms and find better ways to solve problems.

I've been practicing software for 35 years, martial arts for 25; every day I become more convinced that mastery is a journey, not a goal.

Re: A Few Rules

#33

Post by CapitalistCartr »

infogulch wrote: post #15
gonzo41 wrote: post #13

Earlier quoted context omitted.

Worth thinking about with that rule on scarcity. It can also be about what you'll do that others will balk at. Plumbers being a great example of this.

A scarcity of willingness one might say.

My favorite subject to teach is electrical. No one is ambivalent; they're either completely on board or want no part of it. And students pay rapt attention. Well, at least if they don't, it's only once.

Re: A Few Rules

#34

Post by k__ »

"The only thing worse than thinking everyone who disagrees with you is wrong is the opposite: being persuaded by the advice of those who need or want something you don’t."

Also, the things you or they want don't have to be right.

Take software choices.

Their users all got their own reason why they prefer one over the other and all could be wrong.

Which leads us to another rule.

"Logic is an invention of man and may be ignored by the universe"

If everyone of them can be doing things for the wrong reason; arguing if their choice does or does not support their reasoning doesn't help.

Re: A Few Rules

#35

Post by ThePadawan »

ChrisMarshallNY wrote: post #9

Reminds me of this great Non Sequitur[0], and this one[1], [0] https://www.gocomics.com/nonsequitur/2020/08/10 [1] https://www.gocomics.com/nonsequitur/2018/10/26

Reading [0], then [1] directly after is very pleasing.

Thank you for putting them in that order!

Re: A Few Rules

#36

Post by ZephyrBlu »

Very thought provoking, they remind me of the 48 Laws of Power.

A lot of these are intuitive or things I've experienced/seen before, but I've never seen them formalized.

My favourite three, though I think almost all of them are great:

- The person who tells the most compelling story wins. Not the best idea. Just the story that catches people’s attention and gets them to nod their heads.

- Henry Luce said, “Show me a man who thinks he’s objective and I’ll show you a man who’s deceiving himself.” People see what they want to see, hear what they want to hear, and view the world through the lens of their own unique life experiences.

- Simple explanations are appealing even when they’re wrong. “It’s complicated” isn’t persuasive even when it’s right.

Re: A Few Rules

#37

Post by karl11 »

Morgan Housel consistently writes great essays. Crazy to me how much he puts out at such a high quality level. I have submitted a few and upvoted a few but think this is one of the first ones to make it to the front page.

Re: A Few Rules

#38

Post by powersnail »

codr7 wrote: post #32
powersnail wrote: post #21

Earlier quoted context omitted.

That’s probably because the experts are focused on their current task at hand, and most easily recalled the few things that are relevant to the task. Movies and stories don’t portray real life experience, as they cannot juggle all the relevant factors of an expertise without confusing the audience. I don’t know about martial arts. But at least in the few professions I do understand, you cannot just do a few exercises…

What about code katas? I have five or so software designs that I've implemented several times for practice. A database, a bytecode VM, a serverside web framework etc. I'm not so much porting them, rather trying my best to reimagine them in a new context. It helps me see similarities and differences between languages/platforms and find better ways to solve problems. I've been practicing software for 35 years, martial…

I don't have 35 years of experience in software development, yet, so I may be totally out of depth here.

In this case, I think it's not the re-implementation that matters; rather, you have learned some new things and you applied the new knowledge into practice. You're actively comparing different contexts and tools. That's kinda different from what the original comment said about doing it the Karate Kid way.

Secondly, implementing a database/VM/frame work is not something I'd call practicing a skill. It's a pretty sizeable project, at least one semester worth for an undergraduate course. It takes a multitude of skills and knowledge to complete it.

Personally, I think my software development has benefit mostly from solving (real, not hypothetical) problems and reading how others have solved problems. I've hardly used repetition intentionally, except when I'm learning a new language/framework and need to get over the unfamiliarity.

I also practice the violin every day, but it's so much more than repeating of a few exercises. I can say confidently that no one can learn the violin by rote, to any level of success.

Re: A Few Rules

#39

Post by alexpetralia »

ZephyrBlu wrote: post #36

Very thought provoking, they remind me of the 48 Laws of Power. A lot of these are intuitive or things I've experienced/seen before, but I've never seen them formalized. My favourite three, though I think almost all of them are great: - The person who tells the most compelling story wins. Not the best idea. Just the story that catches people’s attention and gets them to nod their heads. - Henry Luce said, “Show me a…

Regarding the last: always provide an interface!
Post reply on HN