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

81–90 of 289 posts

Re: Don't Feed the Thought Leaders

#81

Post by IlliOnato »

Nition wrote: post #20
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…

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…

This is just brilliant!

Re: Don't Feed the Thought Leaders

#82

Post by E14n »

agbell wrote: post #6
anguslmm wrote: post #3

Earlier quoted context omitted.

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

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.

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

Re: Don't Feed the Thought Leaders

#83

Post by dralley »

austincheney wrote: post #75
bombcar wrote: post #57

Earlier quoted context omitted.

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.

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.

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

https://www.youtube.com/watch?v=wf-BqAjZb8M

Re: Don't Feed the Thought Leaders

#84

Post by dasil003 »

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.

Re: Don't Feed the Thought Leaders

#85

Post by lhorie »

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

Re: Don't Feed the Thought Leaders

#86

Post by samplatt »

AndrewKemendo wrote: post #45

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

YourSQL = MySQL. It's so simple but it made me chuckle for a sold five seconds.

Re: Don't Feed the Thought Leaders

#87

Post by catlifeonmars »

daveevad wrote: post #50
catlifeonmars wrote: post #38

Earlier quoted context omitted.

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

> Create an extended product roadmap and put those items at least a year off into the future “and as long as they don’t seem relevant, you can just keep pushing them into the future.” That actually seems to me like the root cause of all the calamity in the article, a culture of lying.

I don’t see it as lying in any meaningful way. Specifically in the article the problem was that there was technical feedback from many parties that have very little, if any stake in the matter. I’d be willing to bet that none of them even bothered to look at the product roadmap to check on the progress or status of their suggestions.

Rather, the “cause of all the calamity” in the article seems to be the fact that the business has a culture of requiring feedback from random individuals who have very little stake in the project or product delivery.

Re: Don't Feed the Thought Leaders

#88

Post by antipaul »

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…

Makes sense, and a good extension of the Rule of Three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

Re: Don't Feed the Thought Leaders

#89

Post by zdragnar »

hedora wrote: post #48
zdragnar wrote: post #44

Earlier quoted context omitted.

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.

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

You know, I think I might have switched to rsync at one point- I haven't had the site in a few years now, so my memory is a bit hazy.

It was sufficiently small enough (no heavy media files) that I didn't mind if I left some unused files up there. Pretty much the only thing that I had to do was make a copy of the sqlite database each time just in case.

Re: Don't Feed the Thought Leaders

#90

Post by JMTQp8lwXL »

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 ES5), but most of these folks don't seem to develop in environments requiring older browser support, but in either case, the nuance always seems missed. It's a caricature of the depth that we sometimes need to dig into.
Post reply on HN