Why senior developers fail to communicate their expertise
Posted by Crafty_Sort_5946@reddit | programming | View on Reddit | 44 comments
Posted by Crafty_Sort_5946@reddit | programming | View on Reddit | 44 comments
thespiff@reddit
The senior devs who hate complexity are the reason your tech stack is still on Java 8 and Oracle, and your product people all quit in frustration because they can never get anything interesting built.
PiotrDz@reddit
But java versions is not about complexity.
thespiff@reddit
While you are correct, building something new to replace something old is, in my experience, often called “adding complexity.”
whinemore@reddit
If you’re a senior developer experiencing this problem with communication ask yourself this. How much time have I dedicated to improving my communication? How does this time investment compare to me improving my other skills?
Please note that “just do it more” is not how you will make any real improvements.
I think for most people the time dedicated to solely working on their comms skills is actually very low. Which, in my opinion makes the reasons behind the “why” here very obvious. Engineers in general spend very little time improving soft skills.
hippydipster@reddit
And how exactly does one work to improve their comm skills?
whinemore@reddit
It's really not complicated.
How do you work on your technical skills? Try to keep yourself honest and look into similar resources. Such as books, content creators. Set goals for yourself, track your progress and don't stop learning. Just like you would do with your technical skills. There is a lot of overlap with Interview Prep/practice for technical roles as well. The problem is people tend to stop practicing after getting the job!
If starting from zero, I'd recommend "Difficult Conversations" as a good primer for effectively navigating... well difficult conversations.
Also, there are public speaking classes and clubs, I'd recommend trying those out. I know there are even personal coaches that are worth exploring.
hippydipster@reddit
Personally, I think it's a disservice to assert it's not complicated. Other than, "read books", your advice is kind of vague and thus fairly complicated. And, one doubts reading books will really help that much, and public speaking classes might actually be a detriment, as the sorts of communication issues we often have are not caused by lack of being able to give a speech, but rather by the tendency to give one when it isn't helpful.
whinemore@reddit
Fair enough. And it is a personal journey. What worked for me might not work for random person online. I'm not on here trying to be a speaking guru or give out advice. I'm pointing out a point that I think is not represented in other comments.
If you want to be better at a skill dedicate time to that skill specifically. Effectively communicating in a job/corporate environment is such a skill.
Be intentional about learning a new skill. Just like you are intentional about learning a new language or technology. Don't expect being good at one skill (engineering) to translate to another (communication) all on it's own.
hippydipster@reddit
If I had to suggest ways to improve communication ability, I'd suggest things like, join a book club, join a writers group, take writing classes - fiction or non-fiction. Public speaking clubs are probably also helpful. But, the problem with these suggestions is they're just not very realistic. And some of it boils down to - join groups where you talk in medium sized groups about interesting things. And then, as you say, you have to be intentional about the fact you're there to learn "communication skills".
I don't think it's easy at all, tbh.
wmjdgla@reddit
Budget, timeline, performance. Real world constraints mean one can mostly optimize for 2 at any one time. "Can we try something quicker?" addresses timeline, but problem comes when management expects no compromises in budget and performance at the same time. What's your answer then?
There's another facet to this dichotomy of goals between management and developers:
yodal_@reddit
I agree with the description of the tension between senior developers and everyone else, but the suggestion seems very simplistic. We've had separate "speed" and "stability" paths for years, it's what demos and MVPs are supposed to be. The problem is, as anyone who has been this industry for long enough can tell you, the temporary solution often is permanent.
In my experience, if management is given a solution that solves their problem they won't care if it is the hackiest solution ever made as long as it doesn't break when trying to make a sale. I can say, "We did the quick solution now we need to clean it up so we can continue to improve the feature and it doesn't break in the future," and they will say, "But it works right now, and we really need this other feature as quick as possible." I can fight that fight, but if the management I am talking to thinks they can replace existing engineers with AI then I have my doubts that I will win. Down the line when the hack inevitably either causes a feature to take three times as long to implement or blows up in production I as a senior engineer am now responsible for an emergency that I never signed up for.
Kalium@reddit
What I've found is that managers now sincerely believe that if they invoke "AI!" a few times, the only gap between a demo or MVP and a shipping product is a fistful of tokens and ten or so minutes. As far as management is concerned, a senior developer's efforts to manage complexity and reduce uncertainty are actively harmful because they inhibit moving faster.
When each manager has a higher-ranking manager breathing down their neck to move fast, all incentives point towards speed. When that EVP believes that AI is magic and expects all their subordinates to agree, any argument to the contrary is going to be a losing one.
What I have found personally is that the suggestion at hand here is actively counterproductive. You stick a candle on your sandwich and five layers up senior leadership will hear that there's a perfect, freshly baked birthday cake. Whether or not it's true doesn't matter. It's good enough for today. The full cake will never be budgeted for and you'll spend the next year trying to make it between all the other oversold things you're trying to do. When you offer to do something quicker, you actively play into this pathology.
What I have found to be a necessary survival approach is to never do a demo or MVP. If you're going to show it to management, it needs to be done or very close to done. They are going to want to ship immediately. This is inevitable. You need to be ready with something polished. If it's not polished when you show it to management, in all likelihood you will literally never get the chance.
slaymaker1907@reddit
I don’t think it’s wrong to demo an MVP since I think the MVP is often complete/nearly-complete. However, the part that takes a long time is the productionizing. Things like testing, documenting, reviewing, etc.
Kalium@reddit
I have good news and bad news. The good news is that you're right and we need a way to communicate those. The bad news is have multiple ways to communicate those that are regularly and effectively used. What we don't have is a way to convince management to care.
We should assume that management won't care about the productionizing work. With this in mind, we should not present them with things until the MVPs are actually production ready. Further, we should never present management with anything that resembles a working prototype, as they consistently interpret this as a shippable MVP.
chessto@reddit
The problem being that we're not a single thinking entity.
If you commit to something reasonably robust that translates to time and effort, which management may not care or understand and there will be no shortage of people willing promise a lower the quality solution just to match the expectations of management / customers.
In a sense it boils down to the objectives you had when you joined the field, some people did it for the cool engineering, some others did it just for the money, unfortunately we've culturally veered from the idea of properly engineered and robust products into a use-and-dispose world and software is not exempt.
BusinessWatercrees58@reddit
Is this even unique to software? This sadly sounds like how most companies do business. Ship whatever sells as quickly as possible, hope it doesn't fuck things up for a lot of people, and if it does, fire and point fingers.
programming-ModTeam@reddit
Your post or comment was removed for the following reason or reasons:
LLM-related content is banned from r/Programming.
hippydipster@reddit
Most communication failure happens in the ears of listeners. The vast majority of people are a lot better at sending out a reasonable facsimile of their internal ideas than they are at taking in, understanding, and integrating the ideas expressed by others.
I would, even those who garble their own thoughts badly enough to be labeled incoherent, are definitely not doing better with your thoughts.
ManySugar5156@reddit
lol, but half the time management hears 2 weeks as no and just wants the speed demo, not the why.
Acrobatic-Watch-8037@reddit
This blog post, as with most about the disconnect between developers and management, fails to understand that the fundamental issue is not communication, or the lack thereof. It's the fact that businesses are run by morons who would much rather listen to product drones who say "it can be done in 2 days", instead of developers who say "it can be done in 2 weeks".
Further, the whole notion that senior developers should have to constantly explain why their experience should be trusted, is nonsensical and offensive. Do you ask the doctor who's treating you to explain why they're competent to do so? If not, why the FUCK do you expect your developers to do that?
The one thing the post does get right is what makes a developer "senior" or not. A senior is not someone who constantly tries to solve problems by building new and shiny things, but by repurposing current and tested things. A senior is not someone who reinvents the wheel because it makes them happy, but gets on with delivering value. A senior is not someone who tries to use AI everywhere because it's the new cool thing, but asks "does it make sense to use AI here"?
And one of the most insidious things that the rise of AI is causing, is for the faux-seniors to be perceived as real seniors simply because of the amount of shit they output via AI assistance. Of course those faux-seniors are the ones being promoted to management positions, where they continue to perpetuate their particular brand of incompetence. And thus the world turns to shit.
BlitzMints@reddit
That's a killer last sentence " I’ll have the Speed version ready in 3 days. Then the Scale version in about 6 weeks.”
Your scale version will never ship.
stevemk14ebr2@reddit
Yea it's a nice idea but clearly the author hasn't worked in tech long enough. Anyone who has knows a better, more scalable version never gets written because we already have the speed version, which is 'good enough '
mycall@reddit
Why can't speed versions also scale? I guess they mean time to market, not efficiency.
Venthe@reddit
Because for starters, there is no such thing as "scale" version.
You always design with constraints in mind, and "scale" & "speed" are variables, not absolutes.
For instance, I could design & implement something in a week that will handle 5* current traffic at a reasonable speed. I could also spend a month designing something that will be twice as fast; or will scale to 50*.
Question is - do we need that now? Because I would rather have something that will need to be updated in a couple of years in a week; rather than waiting months+ for a "scale" version, where scale might not ever materialize.
JarredMack@reddit
So many developers fall into the trap of designing for a scale that is never actually necessary. One of the most valuable skills a senior has is being able to decide when quick and dirty is in fact good enough for the problem
Gwaptiva@reddit
Scalability is the biggest YAGNI in existence
Venthe@reddit
But the issue is - we are always guessing and always making a judgement call how much overhead is enough, and how much is YAGNI.
Hell, without actually implementing the code and measuring it the assumption about the throughtput is only a hypothesis. Should I develop for 1.5x and risk that in practice it will fail in a week; or for 10x and risk that 8x will be unused?
The fact is - we don't know. And the best predictor is usually experience; one that you gain from overengineering things and failing hard.
OverwhelmingGirth@reddit
I think this is one of the biggest reasons why AI won't fully replace experienced devs so easily. There's a lot of judgement calls required which needs a lot more business context and market context than what an AI can really see. Software development to me is much more than just making code that works.
There have been times where I worked hard to make my software really robust and dynamic and scalable and it never got used beyond the basics. There have been times where I shipped a lazy feature quickly only to find out, painfully, that I would be applying patch after patch after patch endlessly until the thing became unmaintainable spaghetti code because I didn't code with enough foresight initially to accommodate the requests I'd be getting.
All_Up_Ons@reddit
Depends what scale we're talking about. NoSQL vs relational is one thing. Relational vs Excel sheets is another thing entirely.
sudoku7@reddit
And one of the big problems is you build for an assumption of where your scaling will be. And senior and staff should be able to make a reasonable educated guess. But... it's still a guess until production tells you how the product is actually being used.
Venthe@reddit
And then we get to the catch 22 - how do we gain the capacity to make reasonable and educated guesses? Most of the time, from experience. And we get that experience from building an overengineered solutions :)
artnoi43@reddit
I once let a smelly MR slip in. The MR introduced new coupling to our core logic. I was the module owner and approved it because the author also saw the problem, and agreed to “refactor” this out after some time. He even put a comment in there.
2 years have since passed and the comment is still here, so is the code. The coupling is so bad that AI is confused all the time when working on it.
It took 1 year (due to priorities being given to new features) to develop a drop-in replacement to switch to once all the edge cases are handled. I personally worked on the refactor for a whole year.
Now I have to wait 1-2 months to be able to deprecate that old crap. And if I had not pushed for the refactor it wouldn’t have been thought about and our devs will happily vibe code through it.
thespiff@reddit
Yeah it will only take 6 months of this process before CTO says “we are going all in on the speed version! Why build twice?!?”
deployguild@reddit
Exactly why I started deployguild.dev - CEOs, non-technical managers and anyone else ignorant of the difficulties involved simply think that that the "demo" version is going to work the same as the scale/stable/production one. Profound misunderstanding.
jug6ernaut@reddit
Deprioritize, deprioritize, deprioritize x100.
Ghi102@reddit
That is a very nicely written essay. I can see issues with the content (as others have said: slightly too simplistic a view), but the article was a joy to read.
feketegy@reddit
The curse of knowledge.
ngroot@reddit
Someone discovered prototyping.
alangcarter@reddit
I've developed all sorts of systems since I started hacking in 1978. The song Soleil Soleil by San Ilya contains a line that resonates with me for the reasons given in the essay:
Espresso superfly we can do nothing if we try
Justin_Passing_7465@reddit
The articles makes some good points, but the problem with complexity is far larger than just instability. Complexity makes everything hard:
It is harder to modify a complex system - every touch breaks seemingly unrelated things
It is harder for new devs to learn a complex system - adding months to the time until a new dev can make valuable contributions to the team is bad for the dev, the team, the product, and the company.
Security - complexity is a breeding ground for vulnerabilities.
Feedback loops - a system riddled with domain complexity is bad enough, but at least that domain complexity makes sense to the customers who work in the domain. Adding system complexity makes it difficult for users to explain friction points to devs, and devs to explain their friction points to users. Complexity is compounded in ways that neither group likely fully understands.
Decomposition - devs have "always" tried to decompose the complex into isolated chunks that are more simple: functions, modules, components, libraries, microservices, etc. However, if the complexity does not fracture along the bounded-context boundaries, then you don't have simple components that collaborate to handle complexity; you have smeared the complexity throughout many components. Nightmare fuel.
Alternative_Nose_874@reddit
Senior devs often “sound” like they are communicating, but they leave out the why and the tradeoffs, so everyone else fills in the blanks. Also, that line about a “scale version” in 6 weeks is basically a trap, it usually turns into a never-ending churn.
lazyegg31@reddit
Good article, thanks fo sharing
liprais@reddit
simple,others are not listening
hbarSquared@reddit
Nice essay. As a dev manager in a large company, I see this tension every day. Nice to be able to sharpen up my language around the issues.