this post was submitted on 21 Aug 2023
3172 points (98.3% liked)
Asklemmy
44165 readers
1269 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy π
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- [email protected]: a community for finding communities
~Icon~ ~by~ ~@Double_[email protected]~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I still kinda disagree. We're talking here about engineering role after all. I have a colleague who is a code wizard, but has kinda problem with (under)communicating. He's still widely respected as a very good engineer, people know his communication style and adapt to it.
But if you're a mediocre problem solver, you can't really make up for it with communication skills. That kinda moves you into non-engineering role like PO, SM or perhaps support engineer.
But I would say this - once you reach a certain high level of competence, then the communication skills, leadership, ownership can become the real differentiating factors. But you can't really get there without the high level of competence first.
where? seemed like general advice.
Even then, thee aren't mutually exclusive. your competence will affect how people see you on a personal level, at least at work. And your competence affects your ability to be given problems to own. You're not gonna give the nice but still inexperienced employee to own an important problem domain. they might be able to work under the owner and gain experience, though.
Documentation and presentation are highly undervalued, and your ability to understand and spread that knowledge can overcome that lack of experience to actually handle the task yourself.
I think we might be agreeing, it's just that "mediocre" means different things to each of us. My team supports human spaceflight, and no one we have is crummy. The "mediocre" people have pretty decent technical skills if you're looking across all software development domains.
Personally, I've found the decent technical skills to be easier to come by than the other ones, and having all of them in one package is a real discriminator.