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

Why senior developers fail to communicate their expertise

nair.sh

Post reply on HN
Print view View original

231–240 of 361 posts

Re: Why senior developers fail to communicate their expertise

#231

Post by lionkor »

d_sem wrote: post #223
hibikir wrote: post #209

Earlier quoted context omitted.

A non-trivial part of the big difference between the juniors that seem talented and "get it", and those that don't is precisely their ability to form accurate enough world models quickly. You can tell who is going at the "physics" of software and applying them, and who is just writing down recipes, and doesn't try to understand the nature of any of the steps. It's especially noticeable when teaching functional progra…

This resonates. Tips on how to build this skill?

No who you replied to, but practice. Deliberate practice; not just writing the same apps over and over, but instead challenging yourself with new projects. Build things from scratch, from documentation or standards alone. Force yourself to understand all the little details for one specific problem.

Re: Why senior developers fail to communicate their expertise

#232

Post by tsunamifury »

hathawsh wrote: post #165
gooseyard wrote: post #159

Earlier quoted context omitted.

By complete coincidence, yesterday I came across this link to an article Peter Naur wrote in 1985 ( https://pages.cs.wisc.edu/~remzi/Naur.pdf ) which I haven't been able to stop thinking about. I've been doing this for coming up on thirty years now, mostly at one large company, and I spent a significant number of hours every week fielding questions from people who are newer at it who are having trouble with one thing…

Isn't that interesting? The job of exploring a theory or model to such an extent that it can be expressed in computer code always seems to fall on the shoulders of a software developer. Other people can write specifications and requirements all day long, but until a software developer has tackled the problem, the theory probably hasn't been explored well enough yet to express clearly in computer code. It feels like s…

Sorry this is just the interior trapped nonsense that engineers find themselves in. Please touch grass

Product designers have to intuit the entire world model of the customer. Product managers have to intuit the business model that bridges both. And on and on.

Why do engineers constantly have these laughably mind blowing moments where they think they are the center of the universe.

Re: Why senior developers fail to communicate their expertise

#233

Post by tsunamifury »

reverius42 wrote: post #147
forlorn_mammoth wrote: post #117

Earlier quoted context omitted.

good things llms solve this problem by assuming everything can be put into words and then convincing the world this is true.

You might be encouraged by this then -- it seems some leading AI researchers agree with you: https://www.technologyreview.com/2026/01/22/1131661/yann-lec...

That is 100% NOT what he is doing.

My guy LeCun believes in deterministic systems describing reality even more than LLMs. He is literally a symbolic logic die hard.

Re: Why senior developers fail to communicate their expertise

#234

Post by ruszki »

d_sem wrote: post #223
hibikir wrote: post #209

Earlier quoted context omitted.

A non-trivial part of the big difference between the juniors that seem talented and "get it", and those that don't is precisely their ability to form accurate enough world models quickly. You can tell who is going at the "physics" of software and applying them, and who is just writing down recipes, and doesn't try to understand the nature of any of the steps. It's especially noticeable when teaching functional progra…

This resonates. Tips on how to build this skill?

Fail, and try to understand why. Don't be quick with the answer. Sometimes it takes years. But it's crucial to want to improve, and recognize when the answer is in front of you.

Read why programming languages have the structures what they have. Challenge them. They are full with mistakes. One infamous example is the "final" keyword in Java. Or for example, Python's list comprehension. There are better solutions to these. Be annoyed by them, and search for solutions. Read also about why these mistakes were made. Figure out your own version which doesn't have any of the known mistakes and problems.

The same with "principles" or rule of thumbs. Read about the reasons, and break them when the reasons cannot be applied.

And use a ton of programming languages and frameworks. And not just Hello World levels, but really dig deep them for months. Reach their limits, and ask the question, why those limits are there. As you encounter more and more, you will be able to reach those limits quicker and quicker.

One very good language for this, I think, is TypeScript. Compared to most other languages its type inference is magic. Ask why. The good thing of it is that its documentation contains why other languages cannot do the same. Its inference routinely breaks with edge cases, and they are well documented.

Also Effective C++ and Effective Modern C++ were my eye openers more than a decade ago for me. I can recommend them for these purposes. They definitely helped me to loose my "junior" flavor. They explain quite well the reasons as far as I remember.

Re: Why senior developers fail to communicate their expertise

#235

Post by dotancohen »

I stopped communicating my experience-derived lessons when I discovered that 1. it cheapened the perception of "my genius", and 2. nobody wants to hear it anyway. From non-tech workers for whom I'd write a bat or bash script for, to engineers for whom I'd debug a complex race condition - they all just want the answer and care nothing about how I got it.

Fine, then, I'll keep the experience to myself.

Re: Why senior developers fail to communicate their expertise

#237

Post by rdiddly »

lnenad wrote: post #4

As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by > “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?” as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out…

Congrats on being the third top-level comment at this hour, and the first one who seems to have read more than just the headline.

Re: Why senior developers fail to communicate their expertise

#238

Post by p0w3n3d » 

  “I found this new tool and it’s pretty cool ...”
yup

  “This company  does things this way, so …”
agreed

  “Here, look at this HackerNews post that says this is best practice, we should probably …”
sir/m'lady, we're at war from now on. This is the only reason I come here. Of course I don't take everything carelessly, but the amount of experts on this forum is damn high and this is the only forum in the last 10 years that helped me grow so much

Re: Why senior developers fail to communicate their expertise

#240

Post by lukebuehler »

gooseyard wrote: post #159
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…

By complete coincidence, yesterday I came across this link to an article Peter Naur wrote in 1985 ( https://pages.cs.wisc.edu/~remzi/Naur.pdf ) which I haven't been able to stop thinking about. I've been doing this for coming up on thirty years now, mostly at one large company, and I spent a significant number of hours every week fielding questions from people who are newer at it who are having trouble with one thing…

I keep saying this is the single most important article to consider when talking about AI assisted software building. Everyone should read it. The question should always be: is a human building a theory of the software, or is does only AI understand it? If it's the latter, it is certainly slop.

(Second, albeit more theoretical, would be A Critique of Cybernetics by Jonas)

Post reply on HN