Why senior developers fail to communicate their expertise • Hacker News Board

Re: Why senior developers fail to communicate their expertise

#191

Post by dirtbag__dad » Wed, May 13, 2026, 1:29 AM UTC

> I don’t like senior developers who like trying new technology. I like ones that avoid more complexity.

I guess the author has never worked on a dog shit system with no tests at all and constant downtime.

I have worked with “complexity averse” engineers who would rather fix the edges over and over again, than roll up their sleeves and just get the job done.

I just don’t believe that using new tools is at odds with avoiding complexity.

Sometimes you have to take it to the chin, and get to use the new shiny thing along the way to move much faster.

Re: Why senior developers fail to communicate their expertise

#192

Post by kevdoran » Wed, May 13, 2026, 1:30 AM UTC

I feel like I was totally on board until the conclusion about one fast system and one stable one. It's not really possible in practice, once a customer starts paying for something, even a vibe coded app by a sales person, it's now a stable system.

The thing breaks, the salesperson says "can you check this out?" then disappears and we're back to where we started.

I don't even find this very new: many companies I've been at have tried to spin-off a "fast" team to sell stuff.

Re: Why senior developers fail to communicate their expertise

#193

Post by ChrisMarshallNY » Wed, May 13, 2026, 1:33 AM UTC

hamstergene wrote: post #69

Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it. An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to anoth…

Just wanted to say thanks for this.

Great thread.

Re: Why senior developers fail to communicate their expertise

#194

Post by hun3 » Wed, May 13, 2026, 1:35 AM UTC

mgaunard wrote: post #36

Even with AI, there is a clear difference between juniors and seniors. None of the things I can think of have anything to do with avoiding problems. To some degree, having 5+ agents working on different projects is similar to leading a team of 5+ people. The skills translate well. The senior is also able to understand what the agents do, review and challenge it. Juniors often can't. And finally, the senior has a deep…

Avoiding problems outside your business problem domain, and can therefore guide the AI more effectively towards building the right thing.

Re: Why senior developers fail to communicate their expertise

#195

Post by danieltanfh95 » Wed, May 13, 2026, 1:36 AM UTC

hamstergene wrote: post #69

Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it. An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to anoth…

yep, as I was exploring in https://danieltan.weblog.lol/2026/05/dunning-kruger-and-the-... , the expert pays the "communication tax" to dumb down concepts that the listener can understand. There is a gap between domain understanding and what is being conveyed that is similar for human-llm interactions as well.

Re: Why senior developers fail to communicate their expertise

#196

Post by simplyluke » Wed, May 13, 2026, 1:36 AM UTC

himata4113 wrote: post #190

abhisek wrote: post #189

I partly agree. Agents are not going to replace senior devs. Exactly for the internal context and the decision making that comes with it. But senior devs are also expected to have a compounding effect even pre-AI. Writing a single doc, refactoring legacy code to make it extensible, building security frameworks specific to the project and many more. All of these would compound the dev team. I think the same will happe…

They will (and already have) replace low-performing senior developers because a single high-performance senior developer can do a lot more than they used to. I have personally noticed this a lot how multiple people can work on the same problem, but the more senior developers get way more miledge out of AI compared to those that are early in their carreers. Another difference I've noticed is how many agents one can ke…

> will result in a shrinking workforce

Jevons paradox is already rearing its head, I've seen data suggesting open roles in tech are at their highest since the post-pandemic slump [1]. If you're a senior leader at a company and your engineers are now capable of multiple-times more productivity, is the logical choice to fire half, or set way more ambitious goals? One assumes engineers are hired because their outputs are worth more than their cost. If outputs, at least for those capable of wielding new tools, are higher, so is the value of that employee to you.

The universal thing I'm hearing from friends at small-mid-size tech companies, and experiencing myself, is that there is way more work and demand for it from senior leaders than they're capable of with their current teams.

1: https://www.ciodive.com/news/tech-job-postings-hit-3-year-hi...

Re: Why senior developers fail to communicate their expertise

#197

Post by tardedmeme » Wed, May 13, 2026, 1:43 AM UTC

Yokohiii wrote: post #126

giancarlostoro wrote: post #23

Earlier quoted context omitted.

Reminds me when the ELK stack was called just ELK (idek what it is now) we had a server we put it on, and after making the additional dashboards my manager wanted, we learned the limits of ES / ELK. It needs a ridiculous amount of memory, because it will shove everything in memory. Same thing when I learned that MongoDB indexing puts every item in memory as well, which is a yikes, why would you not want to index? I b…

Production grade multi tenant databases want to *solely* run on RAM. > why would you not want to index? Because if you don't need an index it wastes RAM, as you've learned. Maintaining indices also has a cost. Index only what you need. In the sense of the blog post: A senior with decent DB experience would have told you. ;)

Everything "wants to" run solely in RAM, but we don't have infinite RAM, so a "production grade" database should also be able to fetch data from disk unless this is an explicit tradeoff. MariaDB and PostgreSQL do not require all indices to be stored in RAM. Obviously they can be accessed more quickly if they are in RAM but they are designed under the assumption they will often be stored on disk. It sounds like MongoDB is not, and given the reputation of MongoDB, this is as likely to be incompetence as it is to be a willing tradeoff.

Re: Why senior developers fail to communicate their expertise

#198

Post by romaniv » Wed, May 13, 2026, 1:44 AM UTC

>We could call this the ‘Speed’ version of the system. It’s not meant to be understandable, the goal is getting things good enough to take it to the market for feedback.

AI is actually quite awful for prototyping, because it makes it far too easy to add random crap to your "prototype" without any specific intention. This quickly transforms the prototyping process from something that's high-level and geared towards building the mental model of the real system into something akin to copy-editing a random piece of software without any coherent mental model involved. Moreover, prompting allows to to glaze over some essential complexity of the task without getting any notions of the scope of the effort of actually doing it. In other words, people end up failing to make necessary decisions and simultaneously get bogged down with unnecessary ones.

In short, fast feedback loops are only useful if there is actual feedback involved.

Re: Why senior developers fail to communicate their expertise

#199

Post by bruce511 » Wed, May 13, 2026, 1:45 AM UTC

LooseMarmoset wrote: post #183

hamstergene wrote: post #69

Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it. An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to anoth…

I think that this is actually a good thing. If everyone had the same internal world model, we would have very little innovation. I try to train and mentor those that are junior to me. I try to show them what is possible, and patterns that result in failure. This training is often piecemeal and incomplete. As much as I can, I communicate why I do the things I do, but there are very few things I tell them not to do. I…

I agree. It's pretty easy to train based on facts, and even experiences. And learners can often take things in unexpected directions.

I think it becomes difficult to train the next layer up though, which is a sum-total of life experience. And I think this is what the parent poster was referring to.

For example, I read a lot of Agatha Christie growing up. At school I participated in problem-solving groups, focusing on ways to "think" about problems. And I read Mark Clifton's "Eight keys to Eden".

All of that means I approach bug-fixing in a specific mental way. I approach it less as "where is the bug" and more like "how would I get this effect if I was wanting to do it". It's part detective novel, part change in perspective, part logical progression.

So yes, training is good, and I agree that needs to be one. But I can not really teach "the way I think". That's the product of a misspent youth, life experience, and ingrained mental patterns.

Re: Why senior developers fail to communicate their expertise

#200

Post by hosh » Wed, May 13, 2026, 2:02 AM UTC

chrisweekly wrote: post #85

hosh wrote: post #64

Earlier quoted context omitted.

They all influence each other to one extent or another. And, the Cynefine Framework defines “complexity” a bit differently than the intuitive way it’s often used. The simple domain is a single dimension. The complicated domain is a system of factors. I think when most people say “complex”, they are really talking about what Cynefine labels as “complicated”. The Cynefine complex domain is not so easily solved or reduc…

Interesting and salient comment. But > "Software systems tend not to be complicated, not complex, until you start getting into distributed systems." these days so much software is "distributed systems".

I don’t know at what threshold a complicated system becomes complex.

For example, at a level of scale, Kubernetes start having emergent behavior.

On the other hand, it doesn’t take much to produce a complex system. The Boids simulation is a complex adaptive system in the form of a flock, yet each member of the flock concurrently follows only three basic rules.