Live data from Hacker News

Why senior developers fail to communicate their expertise

nair.sh

31–40 of 361 posts

Re: Why senior developers fail to communicate their expertise

#31

> The avoider, the reducer, the recycler. As this kind of person, it can be alienating in some teams / companies. What I've found works best is to convey how the added complexity will affect non-engineers. You have to understand the incentives and trade offs though, and sometimes it's better to take the loss. If you have the fortune of sticking around with the same leaders for awhile, a few rounds of being vocal, but…

The best strategy is to frame your argument from the perspective of the customer:

> This will allow for us to deploy the feature in only X days supporting Y use case with Client W who has been complaining about this shit for Q months now.

Arguments like:

> We should do Z because it would provide future extensibility.

> Z could eventually enable some novel platform capabilities.

> Z is easier to unit test.

Are much less likely to succeed in the business contexts that I have experienced so far.

Re: Why senior developers fail to communicate their expertise

#32
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…

A sort of survivor bias. A VP ordered to use elastic search, because it worked well at his company before. Turned out it worked well for us. Listen to the VP to make technical decisions. And use elastic search.

Pick the right use case. It is super awkward, horrible UI for things like log analysis. Use Scalyr instead.

Re: Why senior developers fail to communicate their expertise

#33
post #15

I don't necessarily disagree with this conclusion, but the way it is written has a lot of AI prose smell that was extremely distracting for me.

I’m inclined to take the author at their word that they’re a copywriter by trade. I agree that the punchy staccato and the rhetorical questions smell AI-ish, but the way this person uses them, there’s, like, a payload each time. Versus LLM-speak, where the assertions are at best banal and more frequently just confusing.

I've found myself using AI rhetorical styles. Mostly in PRs. The whole "not just X, Y" pattern hooked into my brain.

Re: Why senior developers fail to communicate their expertise

#34
This is well-put, but the problem comes when you’ve got leadership looking at what appears to be a fully-functioning version of the product that the market is clearly indicating to them is sufficient to drive revenue. Budgeting the 6 weeks or whatever to translate from “the working version” to “the trustworthy version” is a hard pitch.

This is why part of a senior developer’s job is designing and developing the fast version in a way that, if it goes into production, won’t burn the building down. This is the subtle art of development: recognizing where the line is for “good enough” to ship fast without jeopardizing the long-term health of the company. This is also the part that AI is absolutely atrocious at - vibe code is fast, that’s the pitch, but it’s also basically disposable (or it’s not fast - I see all you “exhaustive spec/comprehensive tests/continuous iteration” types, and I see your timelines, too). If you can convince the org that’s the tradeoff, great, but I had a hell of a time doing it back when code was moving at human speed, and now you just strapped rockets onto the shitty part of the system and are trying to convince leadership that rocket-speed is too fast.

Re: Why senior developers fail to communicate their expertise

#35
post #28
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…

I came to say somethign simular actually. > Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can. There are times when this is good, there are times when actively trying introduce an improvement is the best way forward. A good senior is able to recognise when those times are.

Exactly.

Re: Why senior developers fail to communicate their expertise

#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 deeper understanding of what the business and problem domain are, and can therefore guide the AI more effectively towards building the right thing.

Re: Why senior developers fail to communicate their expertise

#39
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…

I think you may be missing the message the OP is trying to communicate.

The qualities were highlighted because they can all lead to better stability.

Re: Why senior developers fail to communicate their expertise

#40
post #28
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…

I came to say somethign simular actually. > Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can. There are times when this is good, there are times when actively trying introduce an improvement is the best way forward. A good senior is able to recognise when those times are.

That doesn't sound as good in meetings. The person who can cut scope and get everyone to the "we did it" back patting phase makes everyone feel warm and cozy.

Now combing through analytics to determine whether or not what we did was actually good? Less warm and cozy.

Post reply on HN