Probably because unlike apprenticeships a senior developer isn’t an owner. This creates a situation where imparting knowledge means you have less time to do your own packed work stack.
Why senior developers fail to communicate their expertise
91–100 of 361 posts
Re: Why senior developers fail to communicate their expertise
#92Because 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…
this is why I only communicate in poetry complexity is not what you believe it is please try listening
So cool. One reading is “complexity is not what you believe it is”. Another is “complexity is”… “not what you believe it is”. Seems similar but the difference is subtle. Even the “please try listening” line changes in both versions. One is confrontational, the other is empathetic.
Re: Why senior developers fail to communicate their expertise
#93What I found is that my willingness to communicate and share my expertise is usually not in demand with more junior developers. In general, I find developers uninterested in finding a mentor. They don't look at your linked in profile, they don't look at you as a possible source of knowledge and expertise. So it's not like I have nothing to share after 30 years of experience in the industry, I just have nobody to shar…
Exactly my experience. You describe it more diplomatically than I do hah. To me, young people just don't seem to know, or want to know, that information and knowledge can be gained from a person. It's the arrogance of youth x100 They have a supercomputer in their pocket/on their desk, and an AI that knows 'everything'. I can't imagine what it's like being a teacher right now. How's your AI going to explain the office…
I don’t think it’s the arrogance of youth. It’s just that this generation and honestly a big cohort of millennials are not used to gleaning information from people. A stunning number of people have been raised/educated solely by the internet. That’s the source for knowledge, not other people.
Re: Why senior developers fail to communicate their expertise
#94I can/have done this without AI and it tends to be disasterous. Management declares we need X fast. Okay, we can build that really fast, but it won't scale. Management says fine, just build it. We do. Management now wants to build Y fast. But wait, what about X? Nevermind, just build Y now. Okay, we're building Y, and X collapses... because it wasn't built to scale. Now we're being called in at 2 am to fix X while also expected to ship Y tomorrow. Sure, they'll glow you up and tell everyone what a hero you were for coming to the rescue at 2 am, but on that six month performance review, the blowup is used as reason to withhold raises and promotions. They don't lose any sleep of course, just you, the developer.
Re: Why senior developers fail to communicate their expertise
#95As 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…
Agree. context matter. As a senior developer you need to understand complexity, risk, upsides and and downsides. Understand the business side. If you are a startup or a big company that is already a cash cow makes a difference when changing a core featrue of the product etc... context context context
One of the side effects of the LLM boom is that it made it a lot easier to tell people that context is important
Re: Why senior developers fail to communicate their expertise
#96Because 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…
[dead]
Re: Why senior developers fail to communicate their expertise
#97Earlier quoted context omitted.
Why can't innovation bring better stability?
Innovation is change, and change is the opposite of stability. Innovation can reduce pain though, if the current pain is strong enough. A stable stream of failures in production can be the kind of "stability" you want to disrupt.
What are we talking about? Philosophically yes. Factually, no. In the context of a system innovation could be switching from one form that renders in 1 second to another that renders in 50ms. Stability isn't part of that equation.
Re: Why senior developers fail to communicate their expertise
#98Earlier quoted context omitted.
There's no high performance database that wont take all of your memory (at least for size of data) if you let it. That's because it's much, MUCH faster to do it that way, though if you can deal with certain type of latency trade offs for throughput something like turbopuffer can do wonders for your costs.
MySQL doesnt eat up all 8GB of my system when I need to query a table with indexed values, MongoDB seems to eat it all up.
If the data is < ram size and if you read that data again and its off disk again its the slowest it can possibly be, there's a reason most databases implement a buffer cache (actually making writes insanely faster as well) but yeah, MySQL is generally not a very good operational database with all the ones I have tinkered with.
Re: Why senior developers fail to communicate their expertise
#99Re: Why senior developers fail to communicate their expertise
#100> 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 le…
We may be looking at this differently based on our own experience fwiw. I also should have said added complexity or lack of (from poor planning).
That can work too, e.g. when demonstrating the pain a customer will experience when something complex is poorly designed (like some b2b workflow), but it's less visceral than telling your internal stakeholders all the extra work they'll have to do if it's rushed. Even the best of your peers are a bit selfish. The business side has a lot of incentives around quick turnarounds so it's easy to overlook the downside.
Imagine such a scenario. You're in healthcare and working on a feature that will add new data model for some kind of clinical information.
You could say:
> 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.
Yeah that very well may prevent W from churning, though hopefully you think about how it will affect other clients too.
Or, you could say
"If we get this data model wrong, and the value set is ambiguous, you (product/sales/cs) will have to reach out to every single customer and clarify what they meant by x/y/z if we wish to migrate it with any degree of accuracy in the future."
That's drawn from experience but I'm sure there are a lot of parallels to that in other industries for any kind of data. Migrating data is a pain in the ass for everyone, but often it can be the people pushing for a quick solution that suffer the most when that goes wrong.
This kind is stuff is why commission structures should consider churn / residuals. Bad incentives make for hastily made decisions.