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

Don't Feed the Thought Leaders

earthly.dev

Post reply on HN
Print view View original

91–100 of 289 posts

Re: Don't Feed the Thought Leaders

#91

Post by JMTQp8lwXL »

closeparen wrote: post #51

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 h…

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.

Re: Don't Feed the Thought Leaders

#92

Post by [deleted] »

dasil003 wrote: post #84

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…

[deleted]

Re: Don't Feed the Thought Leaders

#93

Post by asiachick »

JMTQp8lwXL wrote: post #90
spyckie2 wrote: post #35

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

So frequently do I see the hottest new ECMAScript feature presented by one these folks on Twitter, and I'm thinking how out of the box, older browsers won't support it, and most junior developers don't have a great grasp on polyfills or transpilers. So the first thing I'm seeing is limitations in how I might use it in a production environment (or the small but non-zero work to update my tooling to properly support ES…

For the stuff I work on, if the user's browser can't handle it then it's 99% sure they are not my target market in the first place. Of course YMMV.

Re: Don't Feed the Thought Leaders

#94

Post by jollybean »

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.

Re: Don't Feed the Thought Leaders

#95

Post by wnevets »

bombcar wrote: post #57
spyckie2 wrote: post #35

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

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.

> 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

Re: Don't Feed the Thought Leaders

#96

Post by AnimalMuppet »

Jemaclus wrote: post #30
peter_l_downs wrote: post #4

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…

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 hi…

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.

Re: Don't Feed the Thought Leaders

#97

Post by void_mint »

duxup wrote: post #19

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 accur…

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.

Re: Don't Feed the Thought Leaders

#98

Post by AnimalMuppet »

Ozzie_osman wrote: post #5
agbell wrote: post #2

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

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…

And in software engineering, the answer is almost always "it depends".

Re: Don't Feed the Thought Leaders

#99

Post by Woodi »

lhorie wrote: post #85
spyckie2 wrote: post #35

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

> detailed domain mastery in contrast is difficult, time consuming, and highly contextualized In its defense, it's also extremely intellectually gratifying

Also: often good knowledge allows to see similiarities in other domains - feels like mastery/intuition/domain inteligence :) - it allows to instantly grasp new concepts in new domains. Works like isomorphism in math.

Re: Don't Feed the Thought Leaders

#100

Post by void_mint »

colechristensen wrote: post #60
pbourke wrote: post #34

Earlier quoted context omitted.

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.

It doesn’t even have to be somewhere notable, beware of the engineer trying to recreate their previous environment (and in yourself too).

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.
Post reply on HN