[FLUX-YOU]

>Isn't a lot of the job of software engineering to quickly and concisely communicate complicated concepts?

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.

[scarface74]

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.

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.

[FLUX-YOU]

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort.

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?

[scarface74]

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort.

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.

[FLUX-YOU]

That's just silly, you can build relationships in other ways.

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?

[scarface74]

Once you get to a certain level in your career, part of your job is to be the go to person that explains things, mentors, spends way too much time in meetings and just greases the wheels. The heads down developer is not seen as the multiplier like the team lead/architect is and they get paid accordingly. I have my office days where I expect to get interrupted and my work from home days where I don’t.

No one gets promoted by constantly telling coworkers and management to RTFM.

[FLUX-YOU]

>Once you get to a certain level in your career, part of your job is to be the go to person that explains things, mentor, spend way too much time in meetings and just grease the wheels. The heads down developer is not seen as the multiplier like the team lead/architect is and they get paid accordingly.

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.

[wdewind]

Sure, people don't need to explain RDBMS frequently, but that code you wrote last week? Or that reason you can't do exactly what the PM wants? YMMV but I spend a LOT of time communicating difficult concepts to other engineers (not only mentoring juniors, but also just doing hand-offs and stuff to others), to product managers, sales people etc.

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.

[FLUX-YOU]

>YMMV but I spend a LOT of time communicating difficult concepts to other engineers (not only mentoring juniors, but also just doing hand-offs and stuff to others), to product managers, sales people etc.

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.

[nosseo]

To be clear, we don't ask candidates 'what is a relational database', and I'm totally in agreement that that's a weak interview question.

[JCzynski]

If you can't concisely communicate complicated concepts, you're creating technical debt every time you hand off a project.

[FLUX-YOU]

If you come to me for basic stuff every time without effort on your own part, you're not likely a good fit for the team.

[SilasX]

Once a week (or even every two weeks) is still frequent enough to count as a core job responsibility. And the raw frequency understates its significance, considering that it can be a blocker for other employees' contributions.

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.