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

Don't Feed the Thought Leaders

earthly.dev

Post reply on HN
Print view View original

171–180 of 289 posts

Re: Don't Feed the Thought Leaders

#171

Post by iainmerrick »

spyckie2 wrote: post #163
iainmerrick wrote: post #154

Earlier quoted context omitted.

Your response to this article about how contingent advice is usually better than universal advice is to propose a universal theory?

I did notice the irony myself :) The article talks about contingent advice being better than universal advice only in stage 3. If you're not then universal advice is helpful. I think that holds true for most people and most subjects, including myself. Originally, I thought the article did a great job describing a common scenario that occurs usually in decision making and I wanted to describe my intuition on why I thi…

That makes sense!

I just realised my reply may have come across as mean-spirited rather than the light joke I intended. Sorry about that.

Re: Don't Feed the Thought Leaders

#172

Post by deepstack »

spyckie2 wrote: post #35

Being a hedgehog is useful on the journey to domain mastery because sticking to frameworks saves you time and headache compared to not having any frameworks at all. The 3 stages of domain mastery: Stage 1 - No knowledge or structure to approach a domain (everything is hard, pitfalls are everywhere) Stage 2 - Frameworks that are useful to approach the domain (Map to avoid pitfall areas) Stage 3 - Detailed understandin…

This is an excellent break down. Remind me a lot of the mithril comparison page: https://mithril.js.org/framework-comparison.html

Definitely at stage 3, could also be the reason not as many people using it.

Re: Don't Feed the Thought Leaders

#173

Post by romesmoke »

Instead of 'contingent' v. 'non-contingent' advice, a more helpful distinction IMO is Taleb's notion of skin in the game: don't trust people that have nothing to lose in case your decision leads to a mess. Contingent-sounding (or hedgehog-born) advice can be viewed from a less biased place then.

Of course, non-contingent and fox-originating ideas retain their value, even when given by uninvolved Saints.

Re: Don't Feed the Thought Leaders

#174

Post by rdsubhas »

If you are in a meeting where "thought leaders" are debating idea vs idea – STOP. Don't engage. You will be pulled in, some words or false statements will be very tempting to prove or disprove.

Sometimes you may even be asked to take a decision or commitment on the spot to just an "idea". STOP right there and don't fall into their trap. They just want their "idea" to win, and then they'll disappear in the execution, leaving you holding the bag. Worse still, in case the idea was flawed, they'll refuse to admit. They'll come back and reinforce the idea, not allowing you to pivot or learn from mistakes. That's the nature of thought leadership – the "thought" matters more than everything else.

All ideas are open and welcome, but you don't take commitments based on just ideas. Ask them to show a spec or concrete doc, and start discussing spec vs spec, detail vs detail, plan vs plan, data vs data or anything concrete. You'll find many of these thought leaders silently disappear into the background then.

They will come back and try to abstract-ify the discussion again before decisions are taken. That's why you set ground rules before the meeting begins, and not when it's happening.

Thought leaders are all nice and fancy, until rubber hits the ground. 100% agree with just this title alone: Don't feed them.

Re: Don't Feed the Thought Leaders

#175

Post by marredpally »

One way to filter out people whose input you can safely ignore, is to see who stands to lose the most if you do what they ask you to do. People who've been through what you're trying to do are more likely to have their skin in the same game, and are more likely to give you useful, actionable input.

Not everyone who has opinions on your problem is a stakeholder.

Re: Don't Feed the Thought Leaders

#176

Post by quanticle »

anchpop wrote: post #67
SamBam wrote: post #58

Earlier quoted context omitted.

> to convert unconditional advice into contingent advice, by encoding a priority This is one of the most important things I've learned as a developer, and one that I thought I invented myself, before I knew about agile, by keeping a whiteboard near my desk with yellow sticky notes ordered by property: "Yes, I get that it's a must-have feature, but where do you place it in relation to these other features?" The concep…

Sometimes, the features are really must-haves though. Let’s say it’s march 2020 and your boss wants you to design a mass-market covid vaccine. You have three requirements: it needs to be safe for human use, it needs to be effective at preventing covid, and it needs to be possible to manufacture. If any one of these is missing, your design is useless. I think a similar dynamic is visible in many software projects.

Even there, drug companies often go through the features in a particular order. You start with a range of formulations which you suspect will be safe for human use, you test them to see which are effective, and then you hand them off to a different set of chemists and chemical engineers whose job it is to figure out how to manufacture the doses at scale.

Every part is necessary, but that doesn't mean that there isn't an ordering. Finding something that's easy to manufacture is pretty useless if it turns out later that it kills the patient. On the other hand, a drug that's safe and effective, but is difficult to manufacture is still a viable drug; worst case, you do what drug companies do all the time and charge obscene prices per dose until you figure out how to scale the process.

Re: Don't Feed the Thought Leaders

#177

Post by madeofpalk »

anchpop wrote: post #67
SamBam wrote: post #58

Earlier quoted context omitted.

> to convert unconditional advice into contingent advice, by encoding a priority This is one of the most important things I've learned as a developer, and one that I thought I invented myself, before I knew about agile, by keeping a whiteboard near my desk with yellow sticky notes ordered by property: "Yes, I get that it's a must-have feature, but where do you place it in relation to these other features?" The concep…

Sometimes, the features are really must-haves though. Let’s say it’s march 2020 and your boss wants you to design a mass-market covid vaccine. You have three requirements: it needs to be safe for human use, it needs to be effective at preventing covid, and it needs to be possible to manufacture. If any one of these is missing, your design is useless. I think a similar dynamic is visible in many software projects.

A manager once brought up "there are three levers - scope, time (deadline), money (people)", and while it's probably not revolutionary, it did stick with me.

Add more "must have" scope, and something else has to give.

Re: Don't Feed the Thought Leaders

#178

Post by madeofpalk »

jerf wrote: post #49
catlifeonmars wrote: post #38

Earlier quoted context omitted.

The minor conclusion of this article was the more interesting (and perhaps more practical) of the two: Hide concessions to various leaders in the project roadmap. This isn’t just a “bureaucratic trick” as the OP suggested, it’s actually a way to convert unconditional advice into contingent advice, by encoding a priority.

Yeah, that's not so much a "nifty bureaucracy hack" as a core skill to completing any project. It doesn't even have to be 20 unrelated people's feedback... it's my own priorities quite often that I mercilessly stuff on the backlog. YAGNI isn't just at the micro code level, it's a core project design skill. In fact I probably YAGNI my roadmap much harder than my code since I often have a good idea that I will in fact…

> Yagni originally is an acronym that stands for "You Aren't Gonna Need It"

Re: Don't Feed the Thought Leaders

#179

Post by tonyedgecombe »

zdragnar wrote: post #89
hedora wrote: post #48

Earlier quoted context omitted.

Oh, but scp won’t update it atomically, so you should switch to a scheme that will. Then all you need to do is set cache policies correctly, coordinate with your CDN, and maybe do a staged rollout, just in case. /s Seriously though, rsync is your friend. :-)

You know, I think I might have switched to rsync at one point- I haven't had the site in a few years now, so my memory is a bit hazy. It was sufficiently small enough (no heavy media files) that I didn't mind if I left some unused files up there. Pretty much the only thing that I had to do was make a copy of the sqlite database each time just in case.

--delete-after will delete files on the destination after everything else has synced so you can be sure you aren't linking to a non-existent asset.

Re: Don't Feed the Thought Leaders

#180

Post by tonyedgecombe »

AstralStorm wrote: post #161
fctorial wrote: post #143

Earlier quoted context omitted.

Write a script. 1. stop service 2. copy files 3. start service

Now you have two problems, because for high availability you need a failover or better yet, shadow secondary service. Hot patching wins, but needs good design to work in the first place.

You just need to decide how appropriate that is for your situation.

As an industry I suspect we tend to over-engineer rather than under. There is a huge spectrum between my single person business with a brochure site and what Google or Apple needs. I'm willing to bet most programmers are working closer to the first than the second.

Post reply on HN