21 ms·

Don't Feed the Thought Leaders

• agbell 5y ago
  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 https://news.ycombinator.com/item?id=27462255
  • anguslmm 5y ago
    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.
    • agbell 5y ago
      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.
      • E14n 5y ago
        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 https://en.wikipedia.org/wiki/Stone_Soup
  • Ozzie_osman 5y ago
    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.
    • nradov 5y ago
      Do managers who accept contingent advice from you tend to produce better outcomes?
      • webel0 5y ago
        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.
    • agbell 5y ago
      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.
    • lostcolony 5y ago
      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".
  • rch 5y ago
    Get article. I really appreciate how you were able to incorporate Tetlock's findings. I've been surprised by how reluctant sales and marketing people are to Brier Scores when it comes to their forecasting, given their interest in delivery estimates from engineering.
  • Muley 5y ago
    Great article Adam, fyi the LinkedIn link on your website is broken. Was trying to look up your history. Also Ctrl F: "beleive" -> "believe"
    • agbell 5y ago
      Thanks - I'll fix that. There aren't too many Adam Gordon Bell's out there though.
  • gumby 5y ago
    A side point: the hedgehog/fox analogy originated with philosopher Isaiah Berlin.
    • zimpenfish 5y ago
      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-better-forecasters-than-hedgehogs/ https://longnow.org/seminars/02007/jan/26/why-foxes-are-bett...
      • unhammer 5y ago
        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)#The_Hedgehog_and_the_Fox 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 https://aesopsfables.org/F89_The-Fox-and-the-Hedgehog.html is completely unrelated, though also interesting!)
    • FriedrichN 5y ago
      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.
  • megameter 5y ago
    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?"
    • devchix 5y ago
      > 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!
      • devchix 5y ago
        I remember now! It is called the XY problem. https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem https://meta.stackexchange.com/questions/66377/what-is-the-x...
  • nyczomg 5y ago
    Great read. Also, it inspired someone to post this super interesting comment: https://news.ycombinator.com/item?id=27468654 https://news.ycombinator.com/item?id=27468654 I'd be interested to hear your thoughts on that take since I thought it was very insightful.
  • lhorie 5y ago
    Nice article, very relatable to my experiences. Having been on both sides of these types of discussions, I have a few thoughts: Advice isn't always unconditionally uncontingent. An infra person saying that something should probably be done in some overly specific preachy "best practice" way is sometimes thinking of things that a product person may not. For example, maybe the data guy told you to use WebScaleDB because scaaale, and you chose to use a simple YourSQL thing instead. But it turns out that in the next semester, a metal team you had never heard of is working on chaos testing and they're making sure WebScaleDB handles datacenter failovers properly (but they don't know about your snowflake YourSQL instance silently chugging along in a forgotten corner of one DC). This sort of stuff can be very tricky to anticipate, especially in large companies with siloed teams. I've found it useful to fully embrace the idea of leveraging technical debt: yes maybe YourSQL won't scaaale and maybe it'll die horribly and without explanation when failovers start happening, but if it can carry us to the next point in the evolution cycle, then we can reevaluate our options then, instead of being trapped in analysis paralysis and getting nothing done for the entire duration of time. As a person giving advice, I feel that I fall in the contingent camp (looking at specifics before giving suggestions), but over the years, I've started to try to be mindful of cognitive overload: saying "it depends because X, Y, Z" often goes over people's heads especially when they're already trying to soak up advice from a million different directions. Sometimes, it's better to just take a stance and spit out the TL;DR. If the stance happens to align with "best practices", you can just point at them and people are usually satisfied; if it doesn't align, you can often sway people to understand that there is nuance with a clever enough soundbite: "no, actually you don't want to enforce 100% coverage, full coverage tells you nothing about test quality, uncovered code is what tells you what you're lacking" (or "you don't need WebScaleDB; a billion db rows can be binary-searched in 10 comparisons"). Even if your dumbed down advice now lacks nuance, there's always the opportunity to course-correct as the team builds more experience on top of that advice. Sometimes, you have to be the thought leader and drive the change you want. At my company, for the longest time, every team was suffering the pains of Jenkins. You can't do X because otherwise Jenkins will not be able to handle it, they'd say. We've invested a lot in Jenkins, they'd say. A scaling solution is coming soon, they'd say. My team couldn't wait anymore and we took the initiative to bring in an off-the-shelf 3rd party solution that had all of the pain points figured out (and then some). This turned out to be a really good call because just a week after we deployed the new solution, our Jenkins cluster - shadowing at this point - completely gave out due to scale limits. This third party solution is now what other teams in the company are adopting - including teams that were investing in jenkins integrations before.
  • Ensorceled 5y ago
    This a good framework for identifying a particular type of bad, or useless, feedback. I've added "non-contingent" to my vocabulary. For example, another type of useless feedback is so general as to be insulting; "this needs to scale" or "it needs to be high quality". "too general" vs "non-contingent" are nice distinct buckets.
  • mikehollinger 5y ago
    You captured this well. I genuinely thought this was just something that happened in my company, which has been around for a bit. ;-) I accidentally stumbled upon your technique independently! A) I’d love to have a coffee with you. Virtual or otherwise! B) What do you think about alignment of priorities -within- a team? I’ve seen some interesting behaviors and misbehaviors in a team, where initiatives that are both trivial and non trivial die a death of a thousand cuts because of various and sundry plausible reasons. If I peel back the onion on it, it seems like those situations are ones that arise because of a fundamental lack of trust. Would you challenge or support that premise? If supported would you consider external stakeholders’ objections to stem from the same root lack of trust? It seems like we get more “hedgehog” like behavior when we don’t trust each other, and more “fox-like” behavior when there’s better trust and communication.
• peter_l_downs 5y ago
  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.
  • agbell 5y ago
    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.
  • Nition 5y ago
    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.
• RcouF1uZ4gsC 5y ago
  Glossary: Springy Search - ElasticSearch beetleDB - CockroachDB bongoDB - MongoDB StopLang - GoLang IronOxide - Rust YourSQL - MySQL
  • Conlectus 5y ago
    Warble - Twitter
  • exac 5y ago
    Iron Ore - also Rust
    • ph0rque 5y ago
      Thanks, for some reason I was thinking RubyMine.
  • l0b0 5y ago
    The article was great, but this was an annoying set of substitutions. There's a perfectly cromulent way of creating technology-agnostic content: metasyntactic variables like "Foo" and "Bar". Instead, the simple substitutions made half the article a meta-meta-guessing game, first working out which technology the word translates to, and then trying to work out whether the author meant to rag on those specific user groups (some communities have a reputation for being more fanatic than others), whether they were meant as metasyntactic variables, or whether there was some other point in there. I couldn't work out which it was.
    • AussieWog93 5y ago
      In my eyes, the substitutions he used really embiggens the audience of the article. I come from a EEE background, and "Foo" and "Bar" just don't make sense to me in the way that i, n or f do. Sometimes Foo is a function, sometimes it's a variable, sometimes it's a whole framework. BeetleDB, on the other hand, is clearly a DB client. It's on par with "Alice" and "Bob" in terms of clarity and minimal mindfucks.
• JetAlone 5y ago
  The observation of "foxes" and "hedgehogs" is interesting to me. If it's to be believed, trepidatious granular investigation beats blanket ideological perception in predictive power... I think we're tempted to use our broad lenses to predict things, because we find our worldviews can help us decide how to live in the chaos of our world. The sheer relief of believing "Oh, what I have to do is X," or "I sincerely think the world would be better if Y" gets overextended to fuel a source of pathological comfort. We can lose the present context in it, even if our ideology is actually broadly quite correct.
  • bckr 5y ago
    > because we find our worldviews can help us decide how to live in the chaos of our world Simple answers conserve brain power. I think we can keep using simple answers, we just have to apply different simple answers to different situations. Maybe one way we can do this is to collect simple principles in big lists and, when we feel like we might need to change our perspective on something, look through our list and choose a hypothetical principle to apply. This is basically the I Ching / Book of Proverbs, but you have to compile it yourself.
• labrador 5y ago
  1996: OOP all the code! 2000: XML all the data! 2004: AJAX all the websites! 2008: JQuery all the browser code! 2012: Nodejs all the website backends! 2016: TypeScript all the JavaScript! 2018: Rust all the system code!
  • rfrey 5y ago
    OMG it's in four year cycles. We have six months to sell our startups and get out.
    • dsr_ 5y ago
      You can see it coming, so you can pivot your startup to be buzzword compliant with the new thing instead of the old thing, or you can make your startup into a consultancy to help people do the old thing that they now feel very behind on.
      • tonyedgecombe 5y ago
        I remember visiting a potential client who ranted about their existing solution before we started talking about replacing it. I didn't tell them I'd implemented the existing system whilst working for their previous supplier.
    • BeFlatXIII 5y ago
      US presidential elections were about technology fads all along!
  • Sammi 5y ago
    The first half of that list were just the best options available at the time (in any practical sense). After that you start listing things that aren't nearly universal.
    • labrador 5y ago
      Functional programmers would like to have a word with you...
• duxup 5y ago
  The "we saw this problem at X place" always brothers me. I'm old, I could come up with endless such stories that would require epic solutions, but in not sure there would be much gain. Tell me why we will hit that issue and why we can't fix it any other way... not just the vague notion of a problem someone else had for who knows what reason... And the reason I want that level of detail is because I've failed to accurately predict such issues time and again too ;)
  • pbourke 5y ago
    There’s no one as dangerous as a new hire from “X,” where “X” is a well-known/esteemed company (FAANG, etc), in their first 3 months at a new firm.
    • colechristensen 5y ago
      It doesn’t even have to be somewhere notable, beware of the engineer trying to recreate their previous environment (and in yourself too).
      • void_mint 5y ago
        In my career I've found this to be a huge huge huge red flag as well. If you can only build software one way, you don't really understand how to build it. If moving to a new employer means replicating a previous employer's practices exactly, I don't think you really lack the knowledge or reflectiveness to understand what was good or bad about it.
        • void_mint 5y ago
          * I don't think you really have the knowledge or reflectiveness to understand what was good or not Really wish I could just edit my comment.
  • void_mint 5y ago
    At my last job, my boss was very guilty of "At ____, we found x to always cause us problems", but he never really connected that "x" was a problem because of the context surrounding it, not inherently. We went through this really awful process of: Manager either demands or rejects an idea based on a totally different company -> I spend days/weeks proof of concepting/documenting/testing/validating for or against his mandate -> He says something like "oh, great!", and then continues to spread the mantra that x would never work for us because of previous experience. It was really tiring. Having to constantly document why a piece of technology for a startup in a totally different industry would yield totally different results than when he'd used it at a top 5 company with insane scale and a 500 person engineering team. Especially because most of his understanding was just overhearing people say certain things, so he just said them too, but didn't really know why.
• codingdave 5y ago
  > Preventing the raising of objections was called ‘reaching alignment.’ Sounds like they had the wrong idea of what alignment means. It should mean making sure everyone knows what problem is being solved, and focuses all feedback and concerns solely towards whether or not the project is on track to solve it. See the quote later in the article: > The problem with all the bad advice was that it was unrelated to the problem we were trying to solve. Yup, there's your problem. There was no true alignment on a goal. Their solution to punt all objections downhill works, and in many places it might be the easiest answer. But the better answers is to wrestle objections as soon as they arise, focusing on whether or not they are relevant to the problem at hand. It is harder, but has a better result on all counts.
  • pm90 5y ago
    Hmm, maybe. If someone is making a “universal” suggestion though, I think it would be hard to “wrestle objections”. These individuals probably know all the reasons why you should do X (since that’s their go to advice). Trying to get them to drop their suggestion could possibly backfire. So when you get a suggestion from such an individual, it seems like an attractive option just to humor them and go build what you wanted to build.
• ineedasername 5y ago
  Tetlock also found that foxes were less likely to be famous because contingent advice is harder to explain in a sound bite. Yep. Occasionally there will be a complex problem with a simple solution. More often, complex problems have difficult solutions. And unfortunately, If you're in a room discussing the problem and one person gives a simple solution and you try to start a conversation about the complexities involved and resolving sub-problems... Well, you could be the one who is wrong, but in my experience that's often not the case, though unfortunately people favor the easy answer. That said I have also occasionally seen the simple solution proven right. There's just no one size fits all approach. Personally, I've been wrong both ways and right both ways in my career. When I get it wrong and I'm fortunate, I also come up with the better solution too. Regardless, I've learned to be skeptical of my own simple solutions too.
  • GeneralMayhem 5y ago
    >Occasionally there will be a complex problem with a simple solution. Whenever this has happened in my experience, it's come with the monkey's-paw irony that while the solution is simple, the reason why it's a solution, or at least a complete solution, is not. That almost makes it worse - people who aren't intimately familiar with the problem will see the simple solution, think the problem must have been similarly easy to understand, and then think that there must be something wrong with the solution.
  • l33t2328 5y ago
    > one person gives a simple solution and you try to start a conversation about the complexities involved and resolving sub-problems A simple “that solution doesn’t seem to address $subProblemA or sufficiently handle $efgeCaseB” would do the trick, eh?
    • ineedasername 5y ago
      You would think so, and sometimes it does. Sometimes you get looked at as being too negative and people decide well let's give the easy option a shot. If it's wrong we'll adjust." That actually isn't a bad way to go either, as long as there's nothing time/resource critical at stake and an incorrect "easy" solution doesn't make things worse. I've managed to head off some of those. Had a CEO who favored simple solutions, but would listen to options. And I had a good manager who brought me along to important meetings. The CEO would hear me out. Sometimes they agreed.l, and things worked out. Sometimes the opposite. Once though I did see them cut a Gordian Knot in a very simply way-- though for some rather painful. I still think it was a drastic oversimplified solution to a problem where there were better options, but others had had a chance at those better options and dropped the ball (basically ignored it), and the problem did have to get solved...
• josephg 5y ago
  The struggle here is that in software, sometimes hedgehog thinking is correct. The discernment challenge isn't in spotting hedgehog thinking and choosing fox thinking instead. The challenge is in figuring out in what domains hedgehogs are right and in which domains foxes are right. Unlike in the arena of politics, in software hedgehogs reap the benefits of deep expertise. When are hedgehogs right? In the "obvious" stuff: - You should always use correct indentation in your code - Document your architecture decisions. Have conversations in your team to get feedback and buy in. - When practical, try and keep down the number of languages and databases you use. It'll make onboarding easier and it allow the team to build deeper expertise And so on. The "relational database advocate" usually isn't making an argument that relational databases are better all the time. They're making an argument that relational databases are the right default, and this particular use case isn't weird enough to justify the cost of learning and deploying something else. They might be right - its extremely difficult to know without taking into account the task at hand and the skills of the team. My personal take is to think about the values of a piece of software before writing it. How much should your project care about maintainability, or scalability, or accessibility (ie onboarding)? Then make your technology choices with that in mind. If actually, short term team velocity is the most important thing, skip automated UI testing. If your team's ability to hire developers in 5 years is really important, use React and not the javascript framework of the week. Bryan Cantrill gave an excellent talk on this a few years ago, talking through the values different and systems encapsulate. Its an excellent talk: https://www.youtube.com/watch?v=2wZ1pCpJUIM https://www.youtube.com/watch?v=2wZ1pCpJUIM
• ninetax 5y ago
  Great advice, if every project followed these recommendations I predict we'd see a 200% increase in successful completion of software projects in our industry
• anw 5y ago
  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.
  • catlifeonmars 5y ago
    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.
    • jerf 5y ago
      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.)
• spyckie2 5y ago
  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.
  • wwweston 5y ago
    This is pretty brilliant.
  • catlifeonmars 5y ago
    This is a useful way to frame it. I would add here that stage 2 is the likely the most comfortable and that the migration from stage 2 to 3 has an embedded disincentive structure.
  • bombcar 5y ago
    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.
• LordHumungous 5y ago
  The art of saying no without saying no.
• mathattack 5y ago
  Oh boy do I hate the term “alignment”. I get the concept of people operating in alignment but giving people veto power (“I’m not aligned”) versus decision power is a disaster.
• etempleton 5y ago
  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.
• etaioinshrdlu 5y ago
  One thing that can happen is that you have more control and say over your own work than you realize. Not in every job, but people might be expecting you to be more authoritative than you’re behaving. You don’t have to go along with your peers ideas all the time. It takes courage to exercise this.
• catillac 5y ago
  This is a really good piece. I’m sorry that my comment doesn’t add that much to the discussion, but I just wanted to say that I really enjoyed reading this and seemed to confirm or put into words things I was on the periphery of thinking.
• AndrewKemendo 5y ago
  This is a bang on article and I would say that more people should be less confident in general. I also love his technology substitutions: springy search = Elastic Stoplang = Go IronOre = Rust BeetleDB = CockroachDB
  • daveevad 5y ago
    Good decoding > That was our number one secret to scaling when I was at warble warble = google ?
    • AussieWog93 5y ago
      I would think "Twitter" is a closer synonym.
    • psidebot 5y ago
      I would guess twitter
  • adsharma 5y ago
    You forgot bongoDB
  • samplatt 5y ago
    YourSQL = MySQL. It's so simple but it made me chuckle for a sold five seconds.
    • syntheticnature 5y ago
      Amusingly, the "My" in MySQL is a person's name.
      • CRConrad 5y ago
        Probably the sister of Maria or something; presumably named for Little My: https://en.wikipedia.org/wiki/Little_My https://en.wikipedia.org/wiki/Little_My . (Most people named that in Finland are, directly or indirectly.)
• closeparen 5y ago
  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.
  • LegitGandalf 5y ago
    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."
  • JMTQp8lwXL 5y ago
    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.
    • deleted 5y ago
      [deleted]
• slumdev 5y ago
  Sounds like the company where I work. Extreme lack of leadership.
• bumby 5y ago
  I think I agree with the main thrust of the article but I view it from a different angle. >they are always talking about a thing, that is the most critical thing in every case. Yes, the quality person will always advocate for more tests. The safety person will always prioritize safety. The person managing the schedule will always prioritize deadlines. The cost manager will always prioritize the budget. It’s intent to human biases. However, unlike the author I think “reaching alignment” is actually pretty important. But I don’t think alignment is about “the thing” central to the domain experts focus, but rather about reaching alignment about acceptable risk. “What’s really at risk if we don’t meet the standard for test coverage?” “What’s really at a safety risk if we don’t implement that testing strategy?” “What’s the risk to the schedule if we miss this deadline because we implemented that extra safety?” “What’s the risk to the budget if we miss schedule?” In each of these, if you can reach alignment on acceptable risks it does a lot for the effort. It doesn’t mean any one “thing” has to be a priority in every instance but rather put in the context of overall risk profile. Conversely, if you avoid reaching alignment I’ve worked on teams that will actively subvert the effort because they don’t believe you agree with their “thing” as a priority in any case. Standards aren’t written in stone but are there to partly guard you against biases. Are you not meeting them because the risk changed to be more acceptable? Or are you just v rationalizing some unconscious bias? Explicitly defining risk helps here. I will say for that to work you need to have people who are willing to openly accept risk. I’ve also worked on teams where that wasn’t the case and alignment could never be reached because nobody wanted to be on the record accepting risk because if they didn’t make a decision they still had some plausible deniability.
• _Nat_ 5y ago
  The article defines "thought leader": > Uncontingent advice is what I think of when I hear the term thought-leader - someone has a single solution that seems to fit every problem. Apparently it's a reference to folks who always confidentially advocate the same go-to strategies, regardless of context.
• mmaunder 5y ago
  These aren’t thought leaders. They’re insecure employees trying to justify their existence. You see it in most tech companies, particularly after employee 100 joins. As a leader of an early stage high growth biz, it’s critical to prune the team as these folks emerge. It’s not a happy event, but not everyone is the perfect fit for their current role and sometimes tough changes need to be made. Not making these changes leads to A players - the innovators who ship - having exactly the experience described in the post. And they tend to leave as a result.
  • l33t2328 5y ago
    > it’s critical to prune the team as these folks emerge How do you identify them?
• theteapot 5y ago
  Collaborator: "Evidence across our organization shows when test coverage is above 80% software quality is typically improved." This Guy: Shutup THOUGHT LEADER!!
• genmud 5y ago
  I am going to disagree with the author here, while the end result might have been successful for the author, the though process to get there was flawed. Ironically, the concept he talks about is right on the money, but with incorrect conclusions. In the example he brings up, that people with subject matter expertise predict events with more accuracy (Foxes) than those who make confident forecasters (Hedgehogs). The thing is that the questions/predictions are all around specific/measurable outcomes (I believe that $X will happen if $Y, I believe that $X will happen due to $Z). Asking someone "What do you think of Iraq?" will yield significantly different answers than "What predictions do you have with regards to Iraq over the next 5 years?". I have noticed one common thing, which will cause scope creep in projects with almost 100% certainty: The shitty question. In my mind a shitty question when building software can be a number of things: - Something outside someone's subject matter expertise - Open ended - Without timeframes - No context I would argue that the problem is not that people are getting feedback from Hedgehogs/confident forecasters and that they should discount/ignore their advice. The problem is people keep asking shitty questions, or questions outside the Foxes scope of expertise. I think that product/engineers actually need to be asking more questions of people with experience, not less, but they need to be good questions. This is a skill that requires more effort than most people think. Sure, there are Hedgehogs/people who blab on about the newest tech, but not having a feedback loop is how you get disconnects between your users and the product. I have seen this play out in so many different ways and its amazing how quickly a product team can become disconnected from reality, even in a small company.
  • sombremesa 5y ago
    > one common thing, which will cause scope creep in projects with almost 100% certainty Isn't this a very confident broad stroke forecast of the very type TFA rails against?
• jimmyed 5y ago
  beetleDB is mongoDB clearly.
  • CRConrad 5y ago
    Don't you think it's "bongoDB" that represents Mongo, and "beetleDB" references Cockroach? If not, why not; why should "beetle" be Mongo?
• dasil003 5y ago
  This is an awesome article. Related phenomenon: platformization of a solution before even the first instance of the problem is properly solved. There are a lot of incentives for this in large tech companies for both engineers and managers to show broader impact, but in practice it often results in ill-fitting solutions that impose a tax on everyone else. A good rule of thumb I'd propose would be to require solving a problem three ways before anyone can propose a platform, then extract the best of each approach to build your platform out of and have the three owning teams all sign off that it is the right solution for their specific problem. Of course it's easy to argue against this in the name of redundant effort, but I think it's a small price to pay to avoid over-ambitious but under-qualified architecture astronauts imposing half-baked mandatory indirection whenever they can corner a gullible director.
  • antipaul 5y ago
    Makes sense, and a good extension of the Rule of Three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
  • deleted 5y ago
    [deleted]
• jollybean 5y ago
  I have a harder time empathizing because I can see how the QA guy is literally trying to project what he's been given as mandate. And maybe the DB guy has the expertise to know better? Especially if there are company standards, there is value in that. Does the Devops team really need to have to support 'yet another db' when they've been building tools and support for a standard? I guess it depends on context.
• RandyRanderson 5y ago
  About once a year I come across a really great, well written article (IMO). This is one of them. Highly recommend reading this if you are a sr dev or above technologist.
• rukuu001 5y ago
  Best advice I've read all year.
• puchatek 5y ago
  Good article, but needs more blockchain.
• asplake 5y ago
  Along a lot of other good things, achieving the appropriate level of nuance is well covered in Adam Grant’s recent book Think Again. Highly recommended, and the author-narrated audiobook is excellent.
• franzwong 5y ago
  Start a new project with technologies you are familiar with. Try new technologies on projects you are familiar with. Don't start a new project with new technologies.
  • nxpnsv 5y ago
    Learning is fun though, don't forget to learn new stuff...
  • mercora 5y ago
    i would say try new technologies on problems you are familiar with and focus on the problem space itself otherwise. that is independent of if this is a new project or not. if my goal is to learn something new i try to find a project in a problem space i am very familiar with, where i know the pitfalls and rough edges that make things harder than they should be. this gives me a much better understanding of whatever that new technology is about and if i really want to buy into it... i.e i learned some programming languages by implementing a simple binary Usenet reader/client. i know pretty well by now what it encompasses to build that thing why it is harder to do with some paradigms then others and immediately see value whenever something turns out to be more elegant then previously. and if the task gets unpleasant i can usually state if that is because of the task or the technology or in this case the language i am using....
• jsilence 5y ago
  To me this article is less about not feeding them but more about smart expectation management. Hear every one out and then prioritize their recommendations in a way that no one feels neglected or ignored. That roadmaap trick is really a good way.
• thargor90 5y ago
  hominem unius libri timeo - I fear the man of a single book
• TuringTest 5y ago
  > "The more specific and contingent the advice - the more someone says ‘it depends’ or ‘YourSQL works well in a read-heavy context with the following constraints’ the more likely they are to be leading you in the right direction. At least that’s what I have found" This pretty much summarizes it.
• dgb23 5y ago
  When I started programming professionally I relatively quickly became something worse than a hedgehog. I was so excited about opinionated thought leaders, there was so much to learn and there were all these experts leading the way. But I was basically an overconfident parrot who didn't know what he was talking about. Then I got experience and deeper insight so I became a hedgehog, because that seemed the thing to aspire to. However not for long, because I started to suffer from the lack of nuance that hedgehogs sometimes have. Now I'm a confused wannabe fox. I want to be a fox, or rather I cannot be a hedgehog or parrot, but I'm in a continuous state of confusion and doubt and have an impatient urge to know more about everything. When it is required of me I can be pragmatic and clear, but those are snapshots given the circumstance. One could also say I'm a curious and critical thinker. But that would be an euphemism. I wish I could be a hedgehog and act on it, while having a peace of mind.
• hansor 5y ago
  Interesting topic but terrible written article. Article is impossible to understand without knowing some TV series and cartoons(!), and some pop culture trivia from US :/ It could be done right with some kind of explanation of trivia...
  • mkl 5y ago
    I've never watched either of the two shows mentioned and I understood the article just fine. I'm not American either. The cartoon trivia is explained in the same single paragraph it's mentioned in, and the office trivia is explained in the single sentence that mentions it.
• lbriner 5y ago
  I despise the title "Thought leader" because it is often artificial and as the author wrote, it doesn't necessarily mean very much. It is also used by conference organisers to make their speakers sound more impressive! Anyway, I think this scenario sounds very much like the "pigs and chickens" metaphor in agile development. An external thought leader is a chicken. They have no skin in the game and their ideas are easy to communicate without really understanding the context. In many of these scenarios, multiple product teams are supposed to exist specifically to allow you to use whatever the hell DB engine makes sense to your team. The question isn't then "is squeaky better than bongodb" but which is suitable in this scenario? Will it perform well for this project, can it be supported by this team etc. Perhaps engineering leadership likes the idea of homogeny across the entire company "we use MySQL exclusively", but is that really necessary? Let's ask the Thought Leaders!
• romesmoke 5y ago
  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.
• rdsubhas 5y ago
  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.
• marredpally 5y ago
  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.
• Arch-TK 5y ago
  I agree that there are usually no general solutions but I think there are generally bad solutions out there. Regardless of what you think of OOP (I think it's overused) ORMs are genuinely a terrible idea for a multitude of reasons even if a lot of people seem completely oblivious to other options (and as a result think it's a great option because if you can only imagine one option it's automatically great, at least that's how a lot of people seem to think).
• deleted 5y ago
  [deleted]
• Ensorceled 5y ago
  My favourite personal example of this was a "big project" I was working on in the early 2000's. There were two QA reviewers for my project plan: One raised "serious objections" to the QA section, saying it wasn't detailed enough, we needed a full test plan, and demanding TDD be used for all development. They cc'ed the CEO with their review. The second QA reviewer said the test plan was a "good high level approach" and that only thing they wanted to see was an explicit "design for testability" requirement for one of the critical, and hairy, modules.
• ChrisMarshallNY 5y ago
  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.
  • goodpoint 5y ago
    > I have learned that "I told you so." is absolutely, 1000% worthless. This is proof of bad company culture. Doing post-mortems is important to learn what went wrong in the decision process and how to prevent it.
    • ChrisMarshallNY 5y ago
      Different thing. "I told you so" is a smug, nasty statement. It wins no friends, and closes the ears of those most in need of it. A postmortem is a clinical, reasoned, and scientific review. Everyone is on board, and agrees to abide by the results. I worked for a Japanese company, for a long time. I made some colossal mistakes, during my tenure, and was told "That was, indeed, a mistake. We expect you to mitigate it, and not repeat it." Often, I would actually get more trust and responsibility, afterwards.
• lincpa 5y ago
  You need it:-) The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
• j_wtf_all_taken 5y ago
  > He found that experts could be split into two broad categories, the first of which he called Hedgehogs. A Hedgehog had one big idea like free-market capitalism (or nordic model capitalism or demand-side economics), which they used as a lens to look at many issues. They applied this big idea to every situation, which resulted in noncontingent and straightforward advice. You always need more freedom, nutmeg, and unit tests. Hedgehogs are “Confident forecasters”. > When all the predictions were added up and scored, hedgehogs lost out to his second category: Foxes. Foxes were the opposite of hedgehogs. They had complicated advice and were skeptical of even their own predictions. Tetlock also found that foxes were less likely to be famous because contingent advice is harder to explain in a sound bite. This explains so much - unfortunately, because there's no fingers to point and no quick solution. Its just all of us and our stupid brains that always fall for the hedgehogs.
• CGamesPlay 5y ago
  This fox/hedgehog distinction seems to be a label that you apply to a person post-hoc, based on if you think they did a good job of predicting? I watched the talk linked in the article and it didn't seem to help. If somebody says something about, say, TDD and you don't agree, you mentally just say "oh, this person is a hedgehog about TDD" and then write them off? Doesn't seem like a useful mental framework.
  • wccrawford 5y ago
    Reading the other comments, hedgehogs look at everything through a single lens. Foxes look at it in multiple ways. I've definitely met people who look at everything from their own position, and can't imagine how someone else would see the same situation from a different position. Programmer vs user vs manager, for instance. "This is so much easier to code like this!" vs "This is so much easier for the user to use like that!" vs "This way meets our goals for the quarter!" They are simply unable to see the other points of view.
• unyttigfjelltol 5y ago
  Definitely true that confidence is inversely correlated to accuracy. I personally have derived this truth from my own personal interactions, and it's demonstrated by different scenarios and theories. Confidence (and its cousin, charisma) being dead-ends-- that's a profound thought shift from the dominant perspective that confidence is a modern leadership quality.
• OhNoMyqueen 5y ago
  Great article. The only nuance it misses is that not everybody is aligned with the "desired project outcomes". From a business (and often management) point of view, the "desired project outcome" is a product that works according to the company's established standard, delivered in a timeframe that is reasonable according to the company's standard. There are some other outcomes' properties that are hidden by that, such as: How better could the product work? How faster could the product be delivered? How satisfying is it for people to create the product? All those people with their wishes and throughts which bloat one single project usually have precious insights on how to unbloat the overall processes of creation and maintenance. It's of course impossible to fix it all in the span of a single project, but managing every project with the "it works and was delivered on time" mindset is the best way to tank the overall productivity of the company and lose developers, because you missed the insights they had about to improve what they do, and do it well, and do it efficiently.
• tootie 5y ago
  This is an organizational failure and one that has been known for decades. If your entire org isn't oriented around the same goal of shipping value to customers, then they will just end up defending their own limited horizontal viewpoint. The testing team wants test coverage? Why do you have a testing team? QA should be embedded in your product team. QA should want to ship customer value in the most responsible way. Security should want to ship customer value. Even your content and marketing teams. They can express opinions, but the product manager can take it or leave it in terms of how it affects the actual value of the product. And quality, security and scalability are definitely components of value. CYA is not.
• birthday 5y ago
  Surely the problem here is the author taking every piece of advice as a requirement?! The person in charge of a project should not owe anyone an explanation for not committing to their advice nor be forced to implement all advice given to them. Other than this, good article - I'll forever be more conscious of how I give advice going forward!
• stevage 5y ago
  What is beetleDB a reference to?
  • CRConrad 5y ago
    Cockroach, someone suggested. Feels plausible to me.
• aryehof 5y ago
  Something I like to do when given “non-contingent advice” about a project, is to ask the person making the suggestion to review the published current requirements (functional and non-functional) and constraints, and submit a recommended change. In decades of projects, I have yet to receive one. When receiving offhand hedgehog like suggestions from someone important, e.g. the CEO, I tend to ask if they insist we pause and consider it, given that to do so would likely affect the cost and progress of the project. In decades of projects, I have never been asked to do so.