It takes a village

I typically describe my career as being the result of a lot of luck. There are so many key moments in my professional journey that just happened to go right for me while also being largely out of my control that it feels disingenuous to attribute the entirety of my achievements to my own skill. I've certainly put a lot of effort in to my craft, but identical inputs between two different people can yield extremely different outcomes due to luck or access to opportunity.

My current role at Rye is a good example of this in action. The quality of this very blog--resulting from my own effort and skill--was what prompted them to interview me in the first place, but I was simultaneously lucky that they happened to stumble upon my blog at the right time. I had relatively little organic traffic back at the start of 2024 and just so happened to post a link to my blog in a Hacker News thread that their freshly-hired technical recruiter saw.

There are things we can control about our careers, and there are things we can't. Understanding what falls in to each bucket is really important when strategizing the future of your career, and massively helps you out when discussing progression with your manager.

Unfortunately I've found that the term "luck" is extremely polarizing. Most people I've spoken with about this idea immediately push back on it, and respond like I'm completely discrediting the effort I've put in to my own career development. It bears repeating: luck and effort are not mutually exclusive! But regardless, using the "L" word doesn't seem particularly constructive given the strong reactions it creates.

I've managed to come up with a more nuanced framing which I articulated for the first time late last year talking with Perry Tiu. You can catch the full discussion on the latest episode of Podcast Ruined by a Software Engineer, but the gist of it is this: it takes a village to create a great software engineer.

I would say that at least 90% of the ideas I have about software engineering were sourced from other professionals in the field, rather than being my own invention. I think most good software engineers are in a similar boat. My unique value add mostly comes down to me synthesizing all of the knowledge I've acquired, and turning it all into something greater than the sum of its parts.

The quality of your village directly determines a large portion of your success. By far the most significant component of your village are your coworkers because you spend so much more time with them than anyone else. Finding great coworkers is something that you partially control (because you can interview at companies with good reputation for engineering culture) but is still subject to a bit of luck (the reputation may be unfairly earned, or you're matched to a lower-performing team in the company).

So much of my career is a function of being around smart people that had a lot to teach me. It's really important to avoid workplaces where you are the smartest person in the room--especially early on in your career, when it's much harder to learn effectively in a self-directed fashion.

If you aren't regularly learning new techniques from your coworkers and you don't see an obvious pathway towards that changing in the near future, then it might be time to start looking for an exit¹.