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

241–250 of 289 posts

Re: Don't Feed the Thought Leaders

#241

Post by wayoutthere »

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

Earlier quoted context omitted.

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

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

Then you do what the drug companies did: you hire consultants to do it for you. I did architecture work for one of the major covid vaccines for most of 2020 and that’s exactly what they did.

The overall tone of the program was “we basically have infinite money, just get it done and the government will pay us back”. So they had a fucking army of consultants to accelerate a process that normally takes 5+ years down to 6 months and they were building down multiple roadmaps just in case they hit a block on one of them.

Re: Don't Feed the Thought Leaders

#242

Post by beckingz »

methodsignature wrote: post #192
wnevets wrote: post #95

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. 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 fi…

"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.

http://thecodelesscode.com/

Re: Don't Feed the Thought Leaders

#243

Post by ChrisMarshallNY »

moksly wrote: post #238
ChrisMarshallNY wrote: post #206

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…

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…

> 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.

Re: Don't Feed the Thought Leaders

#244

Post by beckingz »

ChrisMarshallNY wrote: post #206

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…

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

https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...

Re: Don't Feed the Thought Leaders

#245

Post by ludamad »

kqr wrote: post #133
austincheney wrote: post #75

Earlier quoted context omitted.

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.

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

At work I learned a theoretical set of best practices for the software we integrate with. I was very enthusiastic about applying them. This caused me to learn the real set of best practices, mostly leaning on the stuff that works most robustly (even to recreate other features, usually ones that prove inflexible when pushed).

Re: Don't Feed the Thought Leaders

#246

Post by ChrisMarshallNY »

beckingz wrote: post #244
ChrisMarshallNY wrote: post #206

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…

Sometimes people will insist that sticking beans in their nose is absolutely necessary. https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...

I love that! Thanks!

Re: Don't Feed the Thought Leaders

#247

Post by wccrawford »

CGamesPlay wrote: post #223

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.

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.

Re: Don't Feed the Thought Leaders

#248

Post by mwcampbell »

Tainnor wrote: post #202
systemvoltage wrote: post #105

Earlier quoted context omitted.

> All of this makes it hard to move beyond stage 2 into stage 3. Often, moving to the stage 3 is a waste of time and resources. There are a few cases if your business's main secret sauce is stage 3, but for most other things - commoditize and focus. I've seen so many teams and engineers trying to master stage 3 but no real business need and ROI. Engineers love mastering things but good leaders guide them in the right…

> commoditize and focus You say that as if there were any agreement about what that means. But the point of the article is that this is not true; you'll always find someone that insists on using technology (or technique) X for your project, only technology X will be different for each person. Moreover, X might be actually making the project harder to understand, longer to develop or have other significant downsides.…

Here's how I interpret "commoditize and focus": standardize on a well-established and popular solution that's known to be widely applicable, so you can focus on adding business value in your product. Don't go for the new shiny thing being promoted by thought leaders, but an old workhorse. Do it even though you know the old workhorse is suboptimal on one or more technical axes, because in the bigger picture, the third-party ecosystem, talent pool, and other correlates of popularity and maturity are more important.

I've repeatedly failed to follow this approach myself and have come to regret it. As I mentioned the other day, I chose Pulumi over Terraform for infrastructure as code, because Pulumi is undeniably technically superior in some ways. I now believe that was a mistake.

I'm trying to figure out how to implement the "commoditize and focus" approach when it comes to standardizing on a web application framework for my company. I believe the classic server-rendered, multi-page approach is the right one most of the time, so I'm talking about that kind of server-side web framework. I implemented our current product in Elixir using Phoenix, and I now believe that was a mistake as well. If we suppose that the top three server-side workhorse languages are Java, Python, and JavaScript via Node.js (as implied by the availability of a certain Amazon SDK for those three), then I should choose a popular framework in one of those languages. If I still try to hang onto technical merit within these constraints, then I suppose I should go with Java and Spring, since Java is statically typed and the JVM is high-performance. But Spring has such an enterprisey smell about it. If I go with what I already know, that would be Python and Django. But CPython has such awful performance, dynamic typing has known drawbacks at scale, and choosing something just because it's what I already know feels far too much like becoming old and set in my ways (I'm 40). And a strike against Spring and Django, as well as Rails and others, is that they require knowledge of a different language on the back-end than the one we already have to use on the front-end. So I guess I should go with Node.js. Maybe Express with a view engine like Pug? But to really take advantage of using the same language on both the front-end and the back-end (I don't shy away from complex front-end JS where it's needed), I should use an isomorphic framework, something like Next.js. But Next.js throws away web fundamentals like being able to submit a form the old way without JavaScript. And what about bundle size and performance on low-end devices? Yes, I'm supposed to hold my nose and tolerate mediocrity for the greater good, but should I even do that at the end-user's expense? And the better isomorphic JS frameworks (Remix, Marko, SvelteKit...) are too bleeding-edge. I don't know...

So, you're right, there's no one right way to "commoditize and focus". Sorry for the wall of text; this thread hit too close to home.

Re: Don't Feed the Thought Leaders

#249

Post by mattgreenrocks »

spyckie2 wrote: post #35

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

This also accounts for why you see such a noisy contingent of people clamoring for difficult things (ex: software architecture) to be reduced to a discrete process: it suits the way they are currently learning, avoids sunk costs in said learning, sidesteps the hard question of, "do I really know this?" and maintains the current social status quo.

At stage 3, things aren't necessarily easy, but you have the skills to navigate much larger amounts of uncertainty than stage 1 or 2.

Re: Don't Feed the Thought Leaders

#250

Post by mattgreenrocks »

tomxor wrote: post #200
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…

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

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