A twitter thread by Sean Kelly @StabbyCutyou
Recently a younger member of our team asked me: "What do you look for in a software engineer?". He told me my answers surprised him, and weren't like other answers he got, but I've ended up having this same conversation with many people at different levels the past few days...
I'll also say, what I'm about to lay out are not things that I think I always do correctly, or even that after 15 years of doing this that I still don't need to work on them.
But over my career, these have routinely been the markers of a quality engineer that I want to work with
They know how to share their knowledge with others effectively. They know when to go more/less technical, and use more/less details. They understand the importance of body language . They don't hide when things aren't going well, but communicate up/out often.
They know when the right time to work with others is, and when the right time to go heads down on their own is. They're not afraid to run ideas by other team members - both more junior, and more senior. They can defend their positions without getting defensive.
Can be trusted to perform at or above their level. They work to meet their deadlines (combined with points 1 and 2) and know why it matters to hit them. Or they can help adjust expectations so the rest of the business knows why the deadline can't be hit.
This is a tough one, because not every person exists on equal footing - and the same mistakes might receive different critique based on who you are, which is unfortunate. But a general understanding of how to learn from failure and overcome it is a must.
A natural proclivity toward seeking appropriate solutions and understanding root causes has never failed any engineer I've ever met. You don't have to be the Sherlock Holmes of programming to be a good problem solver, you just need dedication and focus.
Ours is an industry that is moves too quickly. Every day, new tech comes out, old "best practices" are uncovered as the frauds we all knew they were the whole time, etc. You don't have to keep up with everything, but you should enjoy the process of learning.
I made a point to tell him "You'll notice I didn't mention specific technology or tooling in any of that", and with good reason.
You can be taught those things more easily than you can be taught the above. You can take engineer with all of the above, and teach them your stack.
But the inverse is not true - you cannot take an engineer who knows your stack, and teach them the above points quickly at all. In fact, the more senior someone gets, the harder it is to correct.
This is why taking a risk on younger engineers is sometimes the best choice.
Engineers often think "The path to improvement is to just do technology harder". Learn more technology, become a deeper subject matter expert, etc. While this is not wrong, it's also not entirely accurate either. You cannot ignore the above skillset as you advance in your career.
When someone on my team is looking to move from more-junior to more-senior position, I'm looking at the above things first - because more senior folks are more widely-facing folks. They cannot avoid interacting with others, because they're more central to getting shit done.
To summarize: Tech is not easy, but people are always harder. Until the robots come to replace us all, you won't be able to avoid dealing with people.
Focus on the above skills, and "technology harder" as a way to increase the scope of where you can be useful to other engineers.
Hi