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

181–190 of 361 posts

Re: Why senior developers fail to communicate their expertise

#181

Post by CharlieDigital »

It's funny, I've been literally trying to convey these exact sentiments to my team over the last few days down to the:

    > Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it?
Pretty much word for word.

It feels like engineers are collectively feeling the pain now that product has decided that engagement of mental faculties is no longer necessary on their behalf; just build it and figure out the user persona and utility later...if ever. What used to be a process of taking the time to understand the domain, the user, and how the product fits into some process has been tossed out the window; just ship whatever we think some imaginary user wants and experiment until we succeed.

It creates the exact problem that OP talks about: every random feature that gets vibe-coded becomes a source of instability and risk; something that can then only be maintained via more vibe coding because no one has a working mental model of the thing.

Re: Why senior developers fail to communicate their expertise

#182

Post by panny »

t43562 wrote: post #52

I found that the proposers of features "want everything" because they don't know what is critical - they're therefore totally unwilling to accept anything other than "the full monty". So as a senior developer you cannot propose any faster route. As you might imagine, a lot of these ideas fell by the wayside but we had to develop them in full.

It's the XY problem. The customers tell sales they want Y, rather than stating their problem X which they think Y will solve. Sales runs breathlessly to the dev team and demands we implement Y. Now scale this up to 10 customers or 100 customers. They all have the same X but come up with independent Ys.

You see the problem immediately. Sales/marketing didn't do their job sussing out what X is and wastes dev time with Ys. And worst of all, write once, support forever. Each one off Y has to be maintained for the special snowflake customer that uses it. None of the Ys actually work well for all the customers with problem X so you end up drowning in "technical debt" spent to create them all.

If your marketing department leads the company, I've discovered the best option is to just quit. Go find a job at an engineering company.

Re: Why senior developers fail to communicate their expertise

#183

Post by LooseMarmoset »

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 am often surprised at the way people I have trained solve problems, and frequently I learn things myself.

Training is less successful for those who aren’t interested in their own contributions, and who view the job only as a means to get paid. I am not saying those people are wrong to think that way, but building a world view of work based on disinterest isn’t going to let people internalize training.

Re: Why senior developers fail to communicate their expertise

#186

Post by t-writescode »

sublimefire wrote: post #166
hirako2000 wrote: post #8

Most proof of concepts I've seen get traction turned into production. A rewrite? I recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened. The article touches on responsability, accountability. There is none for risk taker. By definition. You have a crazy idea, you rush it out, you hope clients bite. You profit. It's not even your problem how to make it work, sca…

A mention of a “rewrite” triggered. Whoever does rewrites is effectively out of ideas on what to do next. This is an opportunity cost and the team/company chooses what is more important and the rewrite is never at the top. So even promising or expecting such a thing is silly. IMO it is a bit arrogant to assume it is more important to engineer a better version of a thing rather than make money quicker and cut corners.…

They said a Proof of Concept goes to prod. That’s not “rewrite the whole service that’s been built for months”. That’s “I vomitted a neat thing over the weekend” -> now it’s in prod.

Hackathon and overnight oncall fixes ABSOLUTELY should be rewritten or production-hardened, but they very often are not.

Re: Why senior developers fail to communicate their expertise

#187

Post by [deleted] »

CharlieDigital wrote: post #181

It's funny, I've been literally trying to convey these exact sentiments to my team over the last few days down to the: > Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it? Pretty much word for word. It feels like engineers are collectively feeling the pain now that product has decided that engagement of mental faculties is no longer necessar…

[deleted]

Re: Why senior developers fail to communicate their expertise

#188

Post by drzaiusx11 »

sublimefire wrote: post #166
hirako2000 wrote: post #8

Most proof of concepts I've seen get traction turned into production. A rewrite? I recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened. The article touches on responsability, accountability. There is none for risk taker. By definition. You have a crazy idea, you rush it out, you hope clients bite. You profit. It's not even your problem how to make it work, sca…

A mention of a “rewrite” triggered. Whoever does rewrites is effectively out of ideas on what to do next. This is an opportunity cost and the team/company chooses what is more important and the rewrite is never at the top. So even promising or expecting such a thing is silly. IMO it is a bit arrogant to assume it is more important to engineer a better version of a thing rather than make money quicker and cut corners.…

I do "rewrites" for my day job all day every day; with as of late the goal being rewriting critical services to get past scaling plateaus.

Rewrites require an existential-level threat to pursue and should never be taken lightly. They must solve a real verifiable need, backed by real world data. Rewrites for rewrites sake or some lofty or nebulous goal of "better" or "more maintainable" code are doomed to fail and a waste resources.

I've seen the worst of it, from your average monoliths with no separation of concerns to 1000s of lines of self-modifying assembly in dead architectures with no code comments containing critical business logic, etc.

The main rule is to not to bite off more than you can chew, which if I'm being honest you really only learn from fucking up or watching others fuck it up.

Re: Why senior developers fail to communicate their expertise

#189

Post by abhisek »

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 happen with agents working on a org specific paved path set by senior devs.

Re: Why senior developers fail to communicate their expertise

#190

Post by himata4113 »

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 keep running without losing awareness.

It generally just raised the bar on what management will expect from developers which will result in a shrinking workforce. The only ones that will benefit are AI companies and the upper management since less employees means less management so lower management will get screwed too.

Post reply on HN