What is the most challenging part of going from being an average engineer to a 10x engineer?
I’m a not a big believer in the 10x Engineer myth. I do think, however, that there are things you can do to deliberately improve your software craftsmanship. So the 10x engineer is more about improving your own capacity and skill by a factor of 10, rather than joining an elite group of “10x Engineers”, sitting somewhere in a mythical dark room writing over 200 wpm on their Vim.
It’s not sufficient to practice for the sake of progress. In order to truly grow, you have to deliberately think about your areas of improvement. This is where I believe many people fail to increase their capacity, as picking up new skills or improving existing ones beyond intermediate level is not something that can be built upon inertia.
I was asked recently what I believe is the most challenging part of growing as a software engineer. Here are the things that I see as the greatest challenges — and the patterns I’ve seen working best for dealing with them:
It’s just you, so you better be working hard
It takes a lot of work to improve your skills, so prioritize that in your life. Over the years, friends have often asked me for shortcuts as they “don’t have the time” to invest in reading or practicing new habits. There are no damn shortcuts. I signed myself up to a C++ course when I was 13, taking a bus every day during the summer and reading books in a language that wasn’t my native language, using the dictionary to learn new words in English. It was extremely hard. It was frustrating.
This is not to brag, it’s just the opposite. Working hard is what I believe to be my unfair advantage in a world where I cannot guarantee pure brain CPU as a differentiator. It’s nothing inherent in me. It’s just work. And it’s hard.
“Well okay, but now it must be easy, right?” Sadly, it’s far from being easy. It is still frustrating to learn, all the time, how much I don’t know. I’m constantly fighting my own Impostor Syndrome, and it doesn’t get any easier (btw, If you feel these self doubts, I highly recommend reading Malory Isn’t the Only Imposter in Infosec. )
Fall in love with your Unknown Unknowns
Acknowledge the fact that you have a lot to learn. People usually believe they are much better than they actually are, so they are not open for growth. Having some experience or being well paid, or both, doesn’t mean you’re done.
Start with one
Once you are open to learn, figure out who in your company is a great engineer in an area that you’re curious about, e.g. specific language or framework, a domain you’re interested to learn more about, or the way they communicate and sell their ideas internally. Ask them for books to read or side projects you can play with to practice your skills. Ask to join them to practice some pair programming. Ask them to conduct code reviews for things you’ve written.
But above all, ask questions and pay attention. Learn how they approach a problem, which questions they ask you back, and only then how they are solving it.
Scale
If working closely with a peer was fun and helped you grow, scale it further. Create a list of great engineers in your organization, mapped by their unique strength, and try to learn from each one of them as much as you can.
Be nice and humble, this quality never gets old
Say thank you and follow up with emails about your learning from them: What were your takeaways? How did you apply it? How did it changed the end result?
This will impress them, and people enjoy sharing more and more once they feel people making the most of it (i.e. this makes you “teachable”). I’ve used this trick numerous times, and by far it was one of the best things I did to learn from others.
Teach on every medium you can
It may be during Code Reviews, writing on a personal blog, during 1:1s, when leading a Design Review, giving an internal talk, speaking at a conference. Try it all.
If you really want to become a great engineer, you need to practice your communication skills — and you need to give back. You need to explain ideas, abstractions and above all — you need to explain why you decided to do things in a certain way. Teaching is a great technique to make sure you really understand the material.
I’m still trying to figure out my path in this journey. If you have other tips I’d love to hear from you so please drop me a comment.
p.s. did you check my latest side-projects?
1. SoftwareLeadWeekly — a free weekly email, for busy people who care about people, culture and leadership.
2. Leading Snowflakes — The Engineering Manager Handbook: practical tools and techniques for programmers who want to lead.
