If you can’t communicate ideas and basic concepts to non technical people, you will both limit your career opportunities and not be able to get your ideas implemented while someone with worse ideas will.
Developers underestimate the amount of influence you can have just by being able to communicate effectively.
At some point, we need to start demanding basic technical competence from the people around software developers.
Otherwise, people will just be interrupting you all day and how much have we collectively written about that problem?
And that’s why developers don’t get ahead....
There are basically “three levers of power” in an organization - relationship, expert, and role in that order.
The developer who knows how to build relationships is the one that doesn’t get his silly bug put on blast by the QA and gets an unofficial Skype message and doesn’t get official very visible tickets when something blows up in production and gets a quick Slack message so that he can be prepared to explain it.
It’s also the different between a developer who has to submit a ticket to netops and wait three days for a VM and one that can send an email, get it set up within 30 minutes and then create the ticket as a formality.
If you want to be the go-to guy/gal that gets constantly interrupted with this sort of stuff, your time won't be respected.
Plus, you're teaching them to go research things on their own. Why is that a bad thing?
No one gets promoted by constantly telling coworkers and management to RTFM.
Great. That's exactly what I said in my original post -- hire someone specifically to do that. Problem solved. Now your junior/mids don't have to explain that. But that's not the career trajectory of every developer, let's be honest.
If someone's going to deny me a promotion for linking a wikipedia page that answers a basic question and completely ignore my technical contributions, I absolutely do not trust that place has the best interests of its developers in mind and is likely driven more by politics than anything else.
No place has the "best interest of its developers in mind". That's true for any industry. It's a lot easier to replace the on the floor factory worker (i.e. the developer) than the foreman (the architect) and they get paid accordingly.
Don't get caught up on the title, role power is the least effective type of power in an organization. If you leverage relationships and can be seen as the expert, you can easily punch above your weight.
I think it's clear we have two very different motivating factors in careers. You want to climb the corporate ladder and get power and influence, and I'm content building things.
I wanted to "build things" my entire career and was stymied by management and team leads who I couldn't convince to see my "vision", net ops and dev ops who made me go through mounds of red tape to get anything done and coworkers who had their own agendas and wanted to get noticed and get the prime projects just as much as I did. It led to a lot of frustration.
The best way to be able to "build things" the way you want is to have the influence to do so by getting people on your side through relationship building and getting people to trust your expertise.
I like to "build things" too and have no desire for management. But, the way to stand out and make more money than the average, heads down developer is to have soft skills.
Some engineers really do sit in a quiet room all day writing code, but my experience has been that it is an extremely communication-centric job.
Either way: if you do work in the kind of environment where you need to work with other engs and teams frequently you do need to test communication skills, and simply coding is not always sufficient.
This is a good use of time though. You won't find this on wikipedia, obviously, and is not considered basic technical information.
This is what I want to spend my time explaining.
Now, you're right, the technical distillation is not going to be on the level of "explain relational databases to a Joe off the street starting from square one", but it's effectively the same as the skill of "demystifying arbitrary misunderstandings and knowledge gaps other have", which is important.
No, I write code daily but I might have to distill down technical concepts once a week or so (usually not even that much) and even then if I happen to be the only one who can distill it down.
If your devs are often explaining basic stuff like 'what is a relational database?', you need to hire someone specifically to do that. It's not a good use of time especially when they can go google/wikipedia those concepts and figure it out themselves.