Technical Excellence Is Not Enough

While I can't say that I observe that kind of radical shift for myself, one of the reasons I still can see something similar is AI development.

Basically manager asks me something and asks AI something.

I'm not always using so-called "common wisdom". I might decide to use library of framework that AI won't suggest. I might use technology that AI considers too old.

For example I suggested to write small Windows helper program with C, because it needs access to WinAPI; I know C very well; and we need to support old Windows versions back to Vista at least, preferably back to Windows XP. However AI suggest using Rust, because Rust is, well, today's hotness. It doesn't really care that I know very little of Rust, it doesn't really care that I would need to jump through certain hoops to build Rust on old Windows (if it's ever possible).

So in the end I suggest to use something that I can build and I have confidence in. AI suggests something that most internet texts written by passionate developers talk about.

But manager probably have doubts in me, because I'm not world-level trillion-dollar-worth celebrity, I'm just some grumpy old developer, so he might question my expertise using AI.

Maybe he's even right, who knows.

>Ignoring it costs more later, but later is someone else's problem

Given the standard advice to job hop every 1-3 years, and the intern/coop work pattern of semester long stints, is this not just a structural consequence?

Do you gain competitive advantage as a company with longer tenures? Or shorter, even?

Or is it an attitude problem, compare with old people planting shade trees:

“Codebases flourish when senior devs write easily maintainable modules in whose extensions they will never work”

It’s a trust issue. There’s no one more of a PITA than a new team member who joins and starts questioning every little thing and demanding it be changed (the initial questioning is fine, so long as you accept “because” as a reason). OF COURSE any team that’s shipping software will have things that don’t make sense prima facie, because they’re accumulated tech debt or historical accident.

Go beyond identifying all these problems towards solving them. Choose a small problem, where you won’t have to fight and argue, just a little dust bunny you can sweep out of the way. Do it again, and again, and again. This is how you build trust. As you build trust, it becomes easier to seek change.

Additionally, you may also find that not all the little problems are worth solving, and what’s more interesting are the bigger problems around product-market fit, usability, and revenue.

I find OP's communication style abrasive and off-putting, which tracks with them saying they've been coached on this, and found that advice lacking.

Maybe it's still insufficient advice, but it hasn't worked for them at least in part because they haven't figured out how to apply it.

From the post, I see low empathy and an air of superiority, (perhaps earned by genuinely being smarter than their peers-- doesn't make it more attractive).

That's going to cause friction because a team is a _social_ construct.

If we believe that, then the real question/answer for the OP's worries is that software development is in a race to the bottom, and then the advice becomes "have you tried switching to hard-to-automate-and-outsource industry?" because you are certainly never going to get respect by volunteering to be paid less just to remain competitive with cheaper workers