An incomplete list of skills senior engineers need, beyond coding [x-post]
An incomplete list of skills senior engineers need, beyond coding [x-post]
cross-posted from: https://programming.dev/post/144418
I generally don't like "listicles", especially ones that try to make you feel bad by suggesting that you "need" these skills as a senior engineer.
However, I do find this list valuable because it serves as a self-reflection tool.
Here are some areas I am pretty weak in:
- How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time
- How to convince management that they need to invest in a non-trivial technical project
- How to repeat yourself enough that people start to listen
Anything here resonate with y'all?
You're viewing a single thread.
I do agree with the sentiment with lists being dangerous, especially when thrown around title discussions. It's far too tempting to interpret it as a checklist when in reality every engineer is so different and provides value through different strengths.
As a self-reflection tool, this is a decent list. When I onboard new team members at the start of their career, I like to boil this down into its broad theme in hope that i can shape their perspective on work from the outset -- There's being a software coder, or a software professional. Soft skills are just as important as technical ones. We're here to work together as a team and get stuff done. As you grow your soft skills, the scope of your influence will grow. Starting from influencing the path of a single ticket, to the team, multiple teams, and then to the org.
Many of these soft skills revolve around ego, trust, collaboration, and communication. The only item that stands out from the rest in that regard is
- How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid
It gives off a vibe of superiority. Being able to explain a technical concept to someone that isn't quite understanding it is certainly important. But it's not about indulging. You need to be able to alert a product manager when their design will lead to an implementation that's bad for the system so that they can address it. You need to be able to let you manager know when a project will be delayed because you need to take care of an unforseen complex technical issue that puts the project at risk. You need to be able to point out areas your code impacts such that a QA engineer can include edge cases for the most complete coverage. These all require knowing how to break down an explanation in more detail until thry understand it. It's possible that someone wants to know more about something that's out of their depth because they're curious and want to learn. That's ok too.