Top
Best
New

Posted by nilirl 21 hours ago

Why senior developers fail to communicate their expertise(www.nair.sh)
617 points | 270 commentspage 3
romaniv 10 hours ago|
>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.

heisenbit 6 hours ago||
While I agree with adding code contributing to complexity is problematic there is lots of code in existing code basis which is overly complex due to past outdated requirements or less than perfect human coders. The current flood of AI driven security fixes demonstrates that AI can be pretty good in detecting security edge cases. It is not inconceivable to use it to also reduce code complexity.
overgard 12 hours ago||
Hits home for me; although a lot of times adding complexity is not about your opinion as a senior developer but rather what the business wants. I've definitely worked jobs where I helped create microservice kubernetes nightmares, and while this was partially my fault for wanting to play with shiny things, a lot of this was just "this is what the business wants and you have the expertise to do it", and I'd kinda shrug and go OK. I worked one job (small business) where an executive once leveled with me that the reason they wanted the complexity is because it looked good to investors, not because it was an actual need.

FWIW though the idea about a "speed" product and a "stability" product isn't new. We used to call it "prototyping". I don't know when/how that disappeared from the collective consciousness. "have a space where we can build things fast with horrible practices" isn't some AI era innovation, it's what smart companies have done for decades.

est 5 hours ago||
> Senior developers care a lot about stability

I saw this yesterday

https://trinkle23897.github.io/learning-beyond-gradients/

They are very remotely related yet somehow very close.

BiraIgnacio 18 hours ago||
One could say in order to be a senior developer in any area, more-than-good- communication skills are required.
nathanielks 18 hours ago|
Unfortunately that's not the case. There are many senior and above level engineers out there who are unskilled communicators but very technically skilled.
lwhi 17 hours ago||
In which case maybe they're best suited to not leading a team.
CobrastanJorji 17 hours ago||
> I don't like the kind of senior developer that says "I found this new tool and it’s pretty cool ..."

Remember that the first half of this statement, the part listed here, is great. I love playing with new tools.

The only bad part is the implicit bit after the dots: "we should use this in our product." You don't want cool things anywhere near your product, unless the cool thing is that they remove complexity.

devhouse 12 hours ago||
Good read. The big elephant in the room though: you likely won't purely hand-code the Stable version for much longer. So where's that split? Prototype vs. Prod? Feature Flags? Canary? 2 codebase nightmare? All of this already exists.

The message that hits for me is that of AI being a destabilizer while simultaneously being an accelerator. The Speed/Scale suggestion won't address this. A codebase no one understands, growing at machine speed won't go away just because you drew a box around it. The fix is likely more mundane stuff like process and role shifts, smaller PRs, tests, tooling, ownership principles.

kevdoran 10 hours ago||
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.

invalidSyntax 9 hours ago||
It sounds like a perfect idea on paper until you notice that junior devs will not be able to learn about stable code. Unless AI get's good enough to write stable code, or good enough that no human has to look in the code, the next generation will face a bigger problem than now. Well it's AI that started it so let's make AI take responsibility... Oh they can't. Now what?
More comments...