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

231–240 of 289 posts

Re: Don't Feed the Thought Leaders

#231

Post by breckenedge »

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…

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

Re: Don't Feed the Thought Leaders

#232

Post by unyttigfjelltol »

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.

Re: Don't Feed the Thought Leaders

#233

Post by heywherelogingo »

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.

The Matrix.

Re: Don't Feed the Thought Leaders

#234

Post by ludamad »

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.

DRY I would argue doesn't conflict nearly as much with a nuanced approach. "Apply Aggressive Compression to Your Code" certainly flies in the face of many other nice features of code as a working body, though

My more nuanced take I guess is "don't duplicate logic, except if it may in fact be mutable data". It does take some forward thinking to think that this e.g. list of 10 rules should be unrolled and not compressed by meaningless helpers, etc

Re: Don't Feed the Thought Leaders

#235

Post by [deleted] »

quetzthecoatl wrote: post #145
mym1990 wrote: post #79

Earlier quoted context omitted.

Not really, Messi is great at soccer, he didn't write the rules of the game, but he was able to do things with the tools available that no one thought possible. To be great you usually have to be creative.

Messi can teach the ones who teach football. Not the best example. He was doing unbelievable things when he was a literal teenager. A surprisingly better example would be Cristiano Ronaldo. Ronaldo was absolutley frustrating to watch in his early career. It was someone trying hard to do flashy moves without any end product. He needed guidance, rules and structures. He also slowly transitioned from Winger to Forward/S…

[deleted]

Re: Don't Feed the Thought Leaders

#236

Post by MrsPeaches »

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 throw another quote into the mix:

“Learn the rules like a pro, so you can break them like an artist.” - Pablo Picasso

Re: Don't Feed the Thought Leaders

#237

Post by OhNoMyqueen »

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.

Re: Don't Feed the Thought Leaders

#238

Post by moksly »

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 with people instead, working at it together, when that’s what is going to happen despite any concerns I have. Usually when you end up being right, people will listen to you more the next time if you’ve stood there with them.

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

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

Re: Don't Feed the Thought Leaders

#239

Post by wayoutthere »

catlifeonmars wrote: post #38
anw wrote: post #31

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…

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.

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

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

Re: Don't Feed the Thought Leaders

#240

Post by jackcviers3 »

q-big wrote: post #212
methodsignature wrote: post #192

Earlier quoted context omitted.

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

> 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. KISS and DRY are different paradigms, i.e. come from different schools of programming.

KISS -

Most people would not recognize simple code if it hit them I'm the mouth.

KIES (keep it easy, stupid) is what they mean, and that means following idioms, frameworks, that are familiar.

Post reply on HN