Hacker News

10 days ago by spyckie2

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 understanding of the domain (in which you can move through pitfall areas freely and see where frameworks fall short)

Hedgehogs are at stage 2. You move from stage 1 to stage 2 by adopting frameworks; hence, hedgehogs are seen as "thought leaders" because they teach the frameworks that lead MOST people to more mastery. Except when you're at stage 3, in which case frameworks lead you to more inefficiencies compared to your own understanding.

All good decisions must be made by stage 3 persons, but ironically, training is most efficiently done by stage 2 persons. Hedgehogs get more limelight because 90% of the population is at stage 1 and values the knowledge of stage 2 (and can't grasp the complexities and nuances of stage 3).

Many hedgehogs struggle to touch stage 3, and instead see stage 2 as mastery. This is compounded by the positive feedback loops of success - the frameworks save time, it gives them reputation, it allows them to save stage 1 persons from their ignorance, and it's the foundation of their current level and achievements. Frameworks are also convenient and broadly applicable to many problems; detailed domain mastery in contrast is difficult, time consuming, and highly contextualized.

All of this makes it hard to move beyond stage 2 into stage 3.

10 days ago by bombcar

To be a good X you must follow the rules. To be a great X you must have followed the rules so well as to learn why they’re there and when they should be broken.

Works for almost any X - writer, programmer, driving, etc.

10 days ago by wnevets

> To be a good X you must follow the rules. To be a great X you must have followed the rules so well as to learn why they’re there and when they should be broken.

In my experience slavishly following the "rules" or "best practices" can actually be worse than never following them. Not understanding when it's good to deviate usually means of a lack of understanding of why the "rules" or "best practices" exist in the first place. So much attention is spent following the letter of the rule rather than what problems it was meant to solve.

Look no further than modern day "Agile" vs the actual Agile Manifesto

10 days ago by taberiand

At the extremes, this is known as cargo-culting. People who have only the most shallow understanding of the rules in my experience also push back the hardest against anyone who "breaks the rules", and get locked into the 'one right way' even when it's actively harming the delivery of a project.

10 days ago by methodsignature

"Rules" often contradict each other. For example, in software development, "keep it simple" often directly conflicts with "dont repeat yourself" as it takes increased complexity to achieve reuse of code. I often see keeping it simple take a back seat in newer developers as they slavishly follow the don't repeat yourself trail. The end result is routinely a brittle, rigid, and overly complex solution.

10 days ago by austincheney

Most people agree with this. The actual challenge is to discern real rules from superficial bullshit. That is a level of criticality many people do not possess and some find hostile or disgusting.

10 days ago by dralley

Raymond Hettinger talks about this in "Beyond PEP8", which is one of my favorite conference talks


10 days ago by kqr

Another challenge is that it's very easy to think you understand the rationale behind the rules well before you actually grok them.

10 days ago by quetzthecoatl

especially when there are too many such rule lists often contridicting with each other. Finding the right list becomes the key for someone (beginner to a domain) who has to follow the rules. That's just luck.

10 days ago by asoneth

Reminds me of a quote from the Mustard Seed Garden Manual of Painting:

"Some consider it noble to have a method; others consider it noble not to have a method. Not to have a method is bad; to stop entirely at method is worse still. One should at first observe rules severely, then change them in an intelligent way. The aim of possessing method is to seem finally as if one had no method."

10 days ago by vitro

Applies really nicely to music. First you learn the rules so you know when you can break them. But if you start breaking the rules from the start, people will think you have never learned them in the first place.

10 days ago by avindroth

Also the social benefit of staying in stage 2 is strong. Stage 3 folks don’t mingle together easily, not just because there are less of them, but also because they have in some ways become themselves. It’s much easier for people to stick together when they believe in something together, whether it’s imperfect or not.

And then some stage 3 folks make a new stage 2 thing and the cycle continues. But I think people don’t want stage 3 attainment by giving up the social buffer (which is very reasonable, as being a social animal in most cases is better life path than a lonely scholar/innovator).

EDIT: I think what I am talking about applies better to spiritual/philosophical/psychological attainment, rather than technological. The effect is probably still there for less spiritual things like tech or writing, but probably less so.

10 days ago by hef19898

I can subscribe to that.

10 days ago by tomxor

> Hedgehogs are at stage 2. You move from stage 1 to stage 2 by adopting frameworks; hence, hedgehogs are seen as "thought leaders" because they teach the frameworks that lead MOST people to more mastery. Except when you're at stage 3, in which case frameworks lead you to more inefficiencies compared to your own understanding.

While interviewing recently, I've found a similar anti-correlation between general competency and people who focus on teaching frameworks and libraries.

The more competent candidates basically don't do any teaching based on frameworks/libraries (but they might have experience mentoring individuals); whereas the candidates who focused on teaching frameworks specifically (often to groups) were the least competent - the more they focused on teaching the less competent they seemed to be! I found this kinda surprising and worrying, though my sample size is fairly small. To clarify, I know only so much can be evaluated in an interview, this is basic competency.

10 days ago by breckenedge

There’s an old pithy quote about this that I won’t repeat here. I’ve seen the same results, but I also know that I may be totally underestimating their competency in an interview: I am not always competent to judge someone’s competency. Keep an open mind —teaching can become a skill trap like any other and it may take time for people to readjust if that’s no longer their primary responsibility.

10 days ago by mattgreenrocks

Frameworks are not domain knowledge. They look good on a resume, but you're being hired to deliver software, not play with React all day.

10 days ago by iainmerrick

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

10 days ago by spyckie2

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 think it comes about. It's not really a universal theory, more my own digestion / explanation on the interrelation around hedgehogs vs foxes and my own interpretation of the issues that the articles describes.

10 days ago by iainmerrick

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.

10 days ago by agarden

A universal theory is not the same thing as universal advice. What would one universally do just because one knows the universal theory?

...Now that you bring it up, the OP is offering a piece of universal advice. The irony seems stronger there. Not sure if that invalidates his advice or not. Probably just invalidates taking it as a hard and fast rule.

10 days ago by httpsterio

No, they just taught you, a person with a level 1 understanding of domain expertise, about how domain expertise works ;)

10 days ago by bendbro

I'm sure there are contingencies that can make contingent advice worse than universal advice.

8 days ago by mtrower

Sure —- in situations where time is critical, for example, fast, suboptimal decisions can be more effective than slow, optimized decisions. So having something general drilled into your head can, in those cases, be preferable.

10 days ago by anw

It's cathartic to read other people who have to go through this.

I'm fighting red tape for my team as we build out a dashboard.

Outlook is packed with 1–2 hour meetings for the next 3 months where so far I'm:

* being asked to load test our system to make sure it can handle the load (of 3 people?)

* being asked to integrate with various analytics platforms so we can alert some poor schmuck at 3 AM in case the API goes down then (it's not a vital part of any platform)

* told to have this run in k8s since everything runs in k8s

* other pedantic tasks by Sys Ops who think everything is a nail and love to argue their points ad exhaustium (or worse, argue why their fav stack is the golden child)

I understand the need for standards and making sure they're followed, but there really needs to be a human element of, "is this truly needed for what I'm trying to do?". So many engineering departments are all about automation, but don't truly think through how much automation is needed, rather than a 1 size fits all approach.

I appreciate that this article comes to the conclusion that the more correct an answer will be, the more complicated it tends to be. I wish more people in decision making positions would understand this.

10 days ago by catlifeonmars

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.

10 days ago by SamBam

> 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 concept of prioritization of features, and of saying "if I stopped dead at some arbitrary point in this list, would you have been happy with your order?" seemed so eye-opening to people at the time.

10 days ago by anchpop

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.

10 days ago by jerf

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 Need It at the microlevel after decades of experience and can save some time at that level, but at the project roadmap level anything you can trim is getting the product out generating value sooner.

(Obviously one can go too far, blah blah blah. But just as with code, we have a much larger problem in practice grabbing too much from the project feature buffet than too little.)

10 days ago by AstralStorm

And then some to level priorities shift and you look at the backlog thinking "if only we have done x before that".

Usually when your unfinished prototype ends up in production. That's the danger of reporting progress to people who think you can go to space on a paper glider.

Probably half of more of start-ups end up failing like this as their quickly delivered prototype fails to capture the market due to not being actually better enough, or crumble under the initial success.

Good for investors and managers who bail out early enough, very bad for users.

10 days ago by madeofpalk

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

10 days ago by wayoutthere

This is it. I do a lot of consulting work around this problem, and the roadmap is where the business and technology meet. It’s where you convert sprints into calendar boxes. It’s also the part most companies do poorly because nobody likes to spend money on good project/program managers (hint: hire product managers instead even though they’re ~25% more expensive because everything in 2021 is a product in some way).

When you do it this way, you can decide well ahead of time if you need to bring in a contractor to build a must-have feature your team won’t have bandwidth for. It flips the narrative and puts the responsibility on the business side (which usually controls the budget anyway).

10 days ago by omoikane

This works especially well when you set and own those priorities, or if your management supports those priorities. Everyone who wants their feature will need to justify to you that their feature deserves a better placement on your roadmap.

It does not work if you can not defend your priorities.

10 days ago by runawaybottle

I’ll add to the list:

- Ceremonial unit tests for every little thing. The whole system is buggy as hell and we don’t have any confidence that the unit tests are truly covering critical parts of the app. But alas, test coverage, the god damn Pope that can never be bemoaned.

- I’m not making this one up: A/B testing for an internal enterprise app.

10 days ago by teddyh

Test coverage is almost the perfect illustration of Goodhart’s law. Good programming practices do result in high test coverage, coverage is very easy to measure, but very easy to fake with useless “tests”. So, when the coverage is measured, the coverage goes up, but stops being meaningful.

10 days ago by onorton

> but very easy to fake with useless “tests”

While it doesn't alleviate the problems entirely, you can also run things like mutation tests that check that your unit tests actually test conditions, rather than just execute all the code.

10 days ago by nickcox

High coverage isn't enough but, in my experience, it's a great place to start.

I've written an depressingly high quantity of code in my career that blows up literally the first time it runs. I'd much rather that happen in a unit test than in production.

Any test that exercises a given branch is better than nothing.

10 days ago by oxfordmale

I have seen bad unit test being introduced when engineering management starts enforcing a threshold (80% coverage). Often developers will scramble to test trivial methods, such getter and setters, but will not write any suitable tests that actually cover the business logic. It is even worse when management only enforce a 80% coverage for new changes. In those scenarios developers go out of their way to encapsulate changes in a separate class to avoid having to test the original codebase in a meaningful way.

10 days ago by bennyelv

I think most people, including the managers are aware of the problem you've highlighted. What's the solution?

10 days ago by zdragnar

Back when I was struggling to develop features in overengineered hell, I commented to my friends what a breath of fresh air updating a personal site with scp was.

They all gave sighs and shudders of disgust, but then again, they had normal programming jobs, so I suppose it seemed quite backwards to them.

10 days ago by hedora

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.


Seriously though, rsync is your friend. :-)

10 days ago by zimpenfish

> Seriously though, rsync is your friend. :-)

Even rsync might not be atomic enough for some situations[1] since it'll update files as it goes rather than in one huge transaction at the end.

[1] I worked on the World Cup 2006 site for Yahoo! and we had this issue - solved with 'rsync --link-dest' and swapping symlinks.

10 days ago by zdragnar

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.

10 days ago by darkwater

The other side of the coin you are not telling is: let's ship this small project to production without all those useless bells and whistles, and then fast-forward 12 months, suddenly everybody is using it and it starts failing spectacularly, and now all those teams that complained in the beginning have a fire to extinguish. I've been too many times on this other side of the coin.

10 days ago by ChrisMarshallNY

I enjoyed that read. I suspect that it probably pissed off a few folks.

I'm a grizzled, scarred old codger that spent most of his career, saying "Are you sure that's a good idea?", only to be ignored, and then put in charge of mopping up the blood.

I have learned that "I told you so." is absolutely, 1000% worthless. It doesn't even feel good, saying it.

What I have learned, is that, when I see someone dancing along a cliff edge, I quietly start figuring out where the mops are kept. If that person has any authority at all, I'll never be able to stop them from their calisthenics.

One of my favorite quotes is one that pretty much describes "hedgehogs":

    "There's always an easy solution to every human problem; Neat, plausible and wrong."
There's another one, by the same chap (H. L. Mencken):

    "The fact that I have no remedy for all the sorrows of the world is no reason for my accepting yours. It simply supports the strong probability that yours is a fake."
Of course, the issue is that for every 10,000 appalling, messy, featured-on-rotten-dot-com failures, there's one spectacular success. Since humans are biased to think of successful outcomes as more likely than they actually are, the ingredients for that success become a "recipe," and are slavishly reproduced, without any critical thought, or flexibility.

It's like a witch doctor's formula for headache cure is bat urine, dandruff from the shrunken head of a fallen warrior chief, eye of newt, boiled alligator snot, and ground willow bark. The willow bark is what did it, but the dandruff thing is the most eye-catching ingredient, so it gets the credit, and everytime the chief gets a hangover, they start a war.

Somewhere down the road, a copycat substitutes hemlock for the willow bark, and headaches become a death sentence.

10 days ago by moksly

I’ve found that management and decision making is much more of a social thing than anything else. Which is probably why your “I told you so”’s feel so worthless. I don’t think think quietly making people crash into a wall is the best way to handle it either, but having worked in the same political organisation for a decade I can certainly see why it’s easier to end up in that category.

I prefer to drive into the wall with people instead, working at it together, when that’s what is going to happen despite any concerns I have. Usually when you end up being right, people will listen to you more the next time if you’ve stood there with them.

It also helps a lot when your prediction turns out to be wrong. When RPA became a big thing in the Danish public sector a few years back I was one of the stronger voices against it in most of our national ERFA networks. When we got the clear message from the top that we were going to do this, however, I jumped right in and helped us chose and build what is now the leading RPA setup in any Danish municipality aside from Copenhagen. I still think RPA is really terrible from a technical perspective, but I can also see the merit in how it’s currently saved us around 90 years worth or manual case-work at the price of a few months of developer- and support-time in total. Because I was quick to jump aboard what I still thought was going to be a sinking ship when it was going to sail no matter what I did or thought, people don’t hold how wrong I was against me but instead lovingly tease me or sometimes cheer me up with other times where I’ve been right.

You have to want to do this of course. If your workplace doesn’t have the sort of people you’ll want to drive into a wall with, the your way is probably better than mine.

10 days ago by ChrisMarshallNY

> When we got the clear message from the top that we were going to do this, however, I jumped right in and helped us chose and build what is now the leading RPA setup in any Danish municipality aside from Copenhagen.

That sounds almost exactly like traditional Japanese consensus.

Everyone argues for their opinion during the planning meeting, but once The Big Boss does the "chopping motion" with his (it's always a "he") hand, then everyone is expected to fall in line, and commit to the team effort.

They actually despise "I told you so." It's not smart to do that, in a Japanese corporation.

9 days ago by valand

Things may be a lot better if there's an official mechanism in an organization for delivering the "I told you so" message, because as hurtful as it might be there are a lot to learn from those kind of people.

In the Japanese corporation, japanese culture seems to drive old experienced people's pride high. It's not a wrong or a right thing. It's just the social mechanism, and once we know that we might be able to leverage from it.

In the end, the game in every organization is not just about being right or doing the right thing, it's also about power, authority, influence.

Back to the great-grand-parent comment, I assume, being a grizzled, scarred old codger, along the way you may have found a method to identify people that thinks like you. If you have, I would appreciate it much if you share about it here!

10 days ago by Siira

All dictators despise being hold accountable.

10 days ago by sn41

I see myself in the same role in my organization, except that I think in terms of a different bodily (semi) fluid.

I even have had crises of confidence, thinking that "I told you syndrome" is a psychological issue with me. I do tend to be overcautious, and tend to underachieve because of it.

But I get a grim satisfaction in knowing that when the next time the bodily fluid hits the air circulator, my pail and mop will make it liveable again.

There was some dedication which I thought came from a John Le Carre novel, "For those who served and stayed silent". I can't find the source now, but that's my spirit.

(I am not in the IT area, I am in academia.)

10 days ago by VoodooJuJu

I'd rather be the guy that sells the mops. These people won't respect you until you take their money.

10 days ago by ChrisMarshallNY

I believe those are called "Security Consultants."

10 days ago by beckingz

Sometimes people will insist that sticking beans in their nose is absolutely necessary.


10 days ago by ChrisMarshallNY

I love that! Thanks!

10 days ago by closeparen

My leadership is constantly pushing for “hedgehog” style advice to be depersonalized, encoded in policies, and handed over to bureaucrats or automation to enforce.

Trying to empathize with their position, I think they think failure happens because the right hedgehogs didn’t show up to the design review that day, or forgot to harp on whatever point that time. They are never satisfied with the “it depends, there’s no hard and fast rule, you have to let the experts think about it in context” responses I give them when pressed for policy. This is limiting my advancement. But worse, someday someone will join the team and will write those hedgehog policies, and then I’ll have to live under them too.

Software engineering is a thinking person’s game. I get that management wishes it weren’t, but it is.

10 days ago by JMTQp8lwXL

Leaders rarely want the nuance. 99% the answer is always "it depends" or you have to ask follow-up scoping questions. They just want to be handed a decision without the color or limitations. Sometimes that leads to future uncomfortable conversations where they assumed they would get Capability X but you only gave a "yes" or "no" because that's the preferred level of detail, leaving the rest to assumption.

10 days ago by undefined


10 days ago by LegitGandalf

You are so right and I'm so sorry. It is truly miserable at so many companies for exactly what you wrote here:

"Software engineering is a thinking person’s game. I get that management wishes it weren’t, but it is."

10 days ago by agbell

Author here, thanks for sharing this. Let me know what you think. I'm trying to connect the dots on research on expert advice and our fields 'thought-leaders'.

The connection is a bit tenuous but I think contingent advice can be shown to be better than non-contingent advice. I also think people are too confident in their opinions.

Also another submission here: https://news.ycombinator.com/item?id=27462255

10 days ago by Ozzie_osman

Great read.

One thing I've found (as a person who advises engineering managers and startups) is that recipients of advice seem to value non-contingent advice more. They just want simple answers that don't make them think.

When someone asks me a question like "how should I interview candidates?", my default answer is "it depends". Tell me about the role. The company. The culture. The product. Remote or in-person? What's the team like. Then i can give a framework that gives you the answer. But people want answers like "use take-homes" or "do 2 behavioral interviews and 1 coding interview".

Same for technical decisions. They don't want to hear "it depends". They want to hear "use Rails and MySQL hosted on Heroku".

So I naturally find myself being pushed to give non-contingent advice.

10 days ago by BeFlatXIII

I personally find that I want opinionated advice in two scenarios: either all the options look indistinguishably similar or they are very different sets of trade-offs that leave no clear winner. At that point, the advice is more a tool for breaking decision paralysis than a choice between options with noticeably different outcomes.

10 days ago by Ensorceled

Good point. I find outlining the two (or more) possible scenarios as explicit options and asking "I'm on the fence, which would you do?" is the best way to get that type of opinionated advice from "the foxes". Otherwise you quickly get the "it depends" answer.

10 days ago by agbell

Yeah, I think that could be true in general. Tetlock found the hedgehogs were more famous and more wrong and I got the idea from him that that was because simple advice is more sticky and works better in sounds bites but it could also work the opposite way -- ie. the more people ask you for advice the more you learn to tell them what they want which might be oversimplified. So you get trained to be more of a hedgehog over time. Interesting idea.

10 days ago by lostcolony

So consider the position the people asking the questions are in. They're facing a problem; they need it solved.

All of us, when we're in that position, desire a solution. I'm not sure what differentiates those who want to fully understand the whole solution space, and all the context that dictates -why- a particular solution may be the 'best' (given a specific set of tradeoffs), but certainly, whether we are like that or not, we all desire the right solution ASAP.

I'd be super interested in how you respond to those who ask such questions; do they seem interested in explaining their problem in detail? If you, rather than say "it depends", instead immediately launch into questions, are they engaged in answering them? Can you then finish with a "given what you describe, because X, Y, and Z, I think (solution) would be the best fit for you. It has the downsides of A, B, and C, but those don't apply to you", or whatever. I.e., basically change the tone to always be focusing on solving their problem, while also allowing you to inform them, rather than "it depends" which could imply "there isn't a clear-cut solution to your problem".

10 days ago by nradov

Do managers who accept contingent advice from you tend to produce better outcomes?

10 days ago by webel0

This is a good question. As much as I find them hard to stand, there are cases where having an ideologue in the back of your mind (or one on each shoulder) makes it easier to play out a situation in one’s mind.

In other words: I don’t need a rule per se, just an argument. I’ll work out the contingencies on my own.

10 days ago by anguslmm

This is pure gold for fresher developers, and something of which more experienced devs could use a reminder.

Every fad and every champion of every technique or framework has something to teach you, and they are often very happy to teach it to you at the wrong time. Trying to please everyone at the start of the project is tantamount to design by committee, and is a sure way to kill a project.

To a hammer, everything looks like nails.

Well written.

10 days ago by agbell

Thanks for reading it. It was one of the those ideas bouncing around in the back of my head for a while but hard to put into words then I read something about Tetlock and the dots sort of connected for me.

Software advice isn't totally a prediction, but it sort of is.

10 days ago by E14n

I think this is generally good advice for software engineering, accept when its not. The problem is that some bad ideas become better ideas by virtue of being popular ideas. Write a shitty framework/language/technology and you have nothing, convince a million people to use it and it becomes compelling because it has a lot of users working with it and solving problems.

Its the classic stone soup story[1]. You see this especially with software and tools that focus on front load new users making it really easy to do trivial things but failing catastrophically when you need more.

You also see the reverse of this, great ideas that don't get bye-in failing by virtue of being too niche.

1. https://en.wikipedia.org/wiki/Stone_Soup

10 days ago by megameter

There is a very similar problem in advice-giving for technical questions, the problem of "Why do you want to do that? You should do this instead." I've seen others recommend trying to ask binary yes/no questions ("I think it's like this. Yes/no?") or to turn an open-ended question, when asked, into a set of binaries rather than guess at the intent.

The property that seems to be common in addressing both is benchmark-setting. The advice of "kick the can down the road" for less productive advice is premised on knowing that it doesn't fit your success benchmarks, but not wanting the confrontation(since a hedgehog benchmark is going to boil down to a single-issue attachment). Likewise, a battery of narrow binary questions that have a definite pass/fail characteristic constructs a form of fox knowledge - it's pragmatic in how it describes the "potential shape" of the outcome, so it makes for a better holistic benchmark than asking "what's the best way to do this?"

10 days ago by devchix

> the problem of "Why do you want to do that? You should do this instead

IIR, there's a word or idiom that describes this kind of solution, I can't think of it and now it's going to bother me until I do. It's a stackoverflow issue, someone asks "How do I do X?" Someone will counter, "Why do you want to do X?" and upon receiving additional information, answer, "You don't want to do X, or this other thing you're doing before doing X. You want to start this way and go down this path and that way you don't have to do X." Maddening!

4 days ago by devchix

I remember now! It is called the XY problem.


10 days ago by gumby

A side point: the hedgehog/fox analogy originated with philosopher Isaiah Berlin.

10 days ago by zimpenfish

Technically, I suppose, it was Archilochus: "The fox knows many things; the hedgehog one great thing."

Tetlock seems to have a slightly different interpretation to Berlin - (paraphrased from [1]) "hedgehogs have one grand theory; foxes are skeptical about grand theories".

[1] https://longnow.org/seminars/02007/jan/26/why-foxes-are-bett...

10 days ago by unhammer

I was immediately reminded of the fable of the Fox and the Cat (in which the Cat wins because following its one heuristic takes no time while the Fox has to deliberate to find the best of its many smart solutions – and the dogs are coming fast). Apparently the tales are related https://en.wikipedia.org/wiki/The_Fox_and_the_Cat_(fable)#Th...

(while Aesop's https://aesopsfables.org/F89_The-Fox-and-the-Hedgehog.html is completely unrelated, though also interesting!)

10 days ago by FriedrichN

One thing to note is that Berlin does not consider the fox as all around better than the hedgehog. Usually you'll see that people have a preference for the fox but Berlin considers some great people as hedgehogs such as Plato, Nietzsche, and Dostoevsky. He also stresses the fact that it's merely a metaphor and shouldn't be applied strictly.

The book is absolutely worth a read if you're into the subject.

10 days ago 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.

10 days ago by peter_l_downs

Found this to be a straightforward and interesting article. Not sure I've ever seen someone connect Tetlock's research to engineering planning before; I certainly hadn't made the connection myself. I also appreciated the tip that instead of saying no to something, you can just add it to a "future work" section of lower-priority but definitely-still-very-important-i-promise-really-i-mean-it tasks and everyone will end up happy.

10 days ago by Nition

From How to Talk So Kids Will Listen & Listen So Kids Will Talk (1980):

> My husband and I took Jason and his older sister, Leslie, to the Museum of Natural History. We really enjoyed it, and the kids were just great. Only on the way out we had to pass a gift shop. Jason, our four-year-old, went wild over the souvenirs. Most of the stuff was overpriced, but we finally bought him a little set of rocks. Then he started whining for a model dinosaur. I tried to explain that we had already spent more than we should have. His father told him to quit his complaining and that he should be happy for what we did buy him. Jason began to cry. My husband told him to cut it out, and that he was acting like a baby. Jason threw himself on the floor and cried louder.

> Everyone was looking at us. I was so embarrassed that I wanted the floor to open up. Then—I don’t know how the idea came to me—I pulled a pencil and paper out of my bag and started writing. Jason asked what I was doing. I said, “I’m writing that Jason wishes he had a dinosaur.” He stared at me and said, “And a prism, too.” I wrote, “A prism, too.”

> Then he did something that bowled me over. He ran over to his sister, who was watching the whole scene, and said, “Leslie, tell Mommy what you want. She’ll write it down for you, too.” And would you believe it, that ended it. He went home very peacefully.

> I’ve used the idea many times since. Whenever I’m in a toy store with Jason and he runs around pointing to everything he wants, I take out a pencil and a scrap of paper and write it all down on his “wish list.” That seems to satisfy him. And it doesn’t mean I have to buy any of the things for him—unless maybe it’s a special occasion. I guess what Jason likes about his “wish list” is that it shows that I not only know what he wants but that I care enough to put it in writing.

10 days ago by tonyedgecombe

I do this to myself. Every time I want to buy something I stick it on my Amazon wish list. Then I forget about it. I almost never actually buy things on the wish list.

10 days ago by buzzwordninja

I have now added this book to my Amazon wish list.

10 days ago by Jemaclus

That's a great idea. I've unwittingly used similar techniques in the past. Now that I know it's a "real thing," I may have to start using it more. Thanks for sharing this!

10 days ago by lanstin

That book is full of such incredibly pragmatic tools for dealing with children ina respectful way without giving up on your own values.

10 days ago by rukuu001

Same, except now it's taking photos of the things kids want, instead of writing it down.

(If it's customers, I just write it down)

10 days ago by IlliOnato

This is just brilliant!

10 days ago by tomnipotent

The book is a must-read. I keep multiple copies to give away to anyone receptive. It has aged very well.

10 days ago by hvacarchivist

> administrative process and formalism is just a stratagem to make people feel like they have a say when they really don't. Almost everyone falls for it.

Democracy in a nutshell.

10 days ago by Jemaclus

I've done this trick fairly often. Like many "tricks" in people management, it works until people figure it out, so you have to be a little careful with it. Nobody likes to feel manipulated.

However, I've found that being really open and collaborative with people helps mitigate the manipulation factor by a significant margin. In other words, you get them to agree that the project is not the highest priority or the highest ROI thing to be working on. You ask: "Given the list of W, X, Y, and Z, and keeping in mind that we only have enough resources to tackle two of these at a time, do you think X is the most important?" and they say "Well, X would be cool but yeah, W and Z would give us the most ROI, so let's hold off on X and Y until we have more time and resources."

The key is to be (or appear) really genuine with this. If it's obvious that you're kicking the can down the road because you don't want to do it, you won't win any friends or influence people. But if you can approach it with "I'd love to do X but the realities of our situation mean that we can't" in an authentic way, then you stand a much greater chance of having both sides walk away with a sense of accomplishment. They feel heard and valued, and you don't have to waste resources on something you don't think is a good idea.

If you can't be authentic about that, then I would just go the truthful route of "This isn't going to happen" and try and just be honest about the realities of the situation. They might feel hurt and rejected, but it's better than them feeling manipulated, IMO.

10 days ago by lostcolony

I take it one further. "Okay, let's sit down together and write out a story that fully defines what you're asking me to do".

Half the time they won't bother. -Your- effort is free, but -their- effort has a cost.

The other half of the time they will, because they care about it, and so it goes into the backlog, and they get to see what stuff takes precedence (and it's a legitimately good faith effort on my part to see it ranked appropriately, and that they feel informed as to what is coming ahead of it and why).

10 days ago by ianmcgowan

Aka "The Wally Reflector". https://dilbert.com/strip/2005-07-10

Even a small task is usually enough to filter out requests where the requestor is basically trying to move a task from their list to your list..

10 days ago by kfarr

Absolutely, I love this technique when the ask is clearly more complicated than they realize. I say let's schedule an hour to write out a spec, my calendar is open. Similar technique is to say yes I can do that but let's do it together on a screen share call and you can guide me through it. It's always a positive outcome -- either they withdraw the request or we collaborate positively together to make it happen and appropriately prioritize.

10 days ago by AnimalMuppet

In a sane situation, you usually have a "product manager" or someone who owns the feature set and the priorities. (If you don't, if the engineers have to answer to multiple people with conflicting desires and demands, that's the first problem.)

But if you have a product manager (and they're doing their job), then all you have to do is tell them the truth. Let them figure out which features are priority, or will lead to the most revenue, or whatever. That's their job.

I was in an Extreme Programming estimating session one time. A particular story came up for our consideration, and several people groaned. Nobody wanted us to do the story, because it was going to be a bear to implement. I said "Just tell them the truth. They'll figure out why this is a bad idea." We estimated six months, and they decided that they didn't want the feature at that price.

10 days ago by Woodi

> Like many "tricks" in people management, it works until people figure it out [...]

"Good strategy works even when you know it's coming" - something like this from "Sanctuary for all" :) One example of that was mentioned here few times: features need money. And resources and time.

But sometimes features can be crammed into project without bigger investment - just talk to devs and and often they will find a way. Sometimes it works perfectly, when overall architecture is good or extendable. And often it make total mess in codebase. But cost nothing ! ;)

10 days ago by agbell

Thanks for reading!

Yeah, the future trick is kind of interesting because it solves the immediate problem and it allows people to feel like you heard their concerns and valued their advice. If that is what they are looking for then its a great solution. If they have spotted legit problems then you need to actually reassess things.

I guess like everything it is very contingent on the environment. It worked in this specific context.

10 days ago by kbenson

Then you take a vacation, and find that one or more of the shadow banned feature requests have actually been started...

10 days ago by etempleton

I simply call hedgehogs ideologues. These people have a lens they see the whole world through and that tints everything a single color. It is a mental short-cut.

Some people like to call these mental models or lens, and that you should add as many as possible—switch out the green lens for a red lens and see if that makes things look better. And I agree, but I think if you have to consciously make “mental models” you are probably going to struggle to think critically about what the problems are anyway.

The truth is we probably all are a hedgehog at various times without realizing it. The only solution is to be as widely read as possible so that you do not short-cut to a few ideas that may or may not fit the challenge you are trying to solve.

Daily digest email

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.