>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.
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.
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?
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.
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.
>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.
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.
Why do I need to punch above my weight? So I can finally tell people 'no' when they try to take my time away with stuff that they can fix themselves?
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.
That's just the point I've been making "climbing the corporate ladder" is about gaining role power. Role power is the least effective method of getting things done in an organization.
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.
What you say makes complete sense. It is correct as per my observations. However, one big issue is that sociopaths (manipulators, idea\effort-appropriators...) have an edge. Also, such people accumulate and ruin workplace.
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.
>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.
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.
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.