This series was born out of my frustration with how poorly software engineering is taught.
As a software engineer, I often think about the software of software engineers. Namely, how do great software engineers think? How can we program the right set of attitudes, skills, and values? How can we distribute these lessons widely, so that great engineers are just as consistently created outside the top schools or top tech companies or top open source projects?
I started learning software engineering through a surfeit of missteps that were costly in time but invaluable for learning. Since then, I’ve mentored several cohorts of junior software engineers through my time in Y Combinator and my early work in cryptocurrencies.
Over the years, I have seen a fairly common set of issues with junior engineers: favoring shiny new technology, not thinking in tradeoffs, not reading enough good code, focusing on frameworks rather than concepts, to name just a few. My meandering explorations into the early history of MongoDB or ruminations on software engineering debates or common misconceptions in OSS have also highlighted a host of other challenges.
It’s no wonder junior engineers struggle. They aren’t getting what they need from traditional computer science programs or boot camps.
On the one hand, computer science programs focus on theory with lessons taught by academics who’ve rarely built performant, real world systems. On the other, bootcamps — while doing a laudable job of being pragmatic — over focus on often ephemeral frameworks to maximize short-term job prospects, rather than instilling a way of thinking.
Even great engineers often don’t teach the softer skills of software engineering, like lessons on how to assess the torrent of Hacker News technology posts or how to have an effective technology debate.
Some will argue that it is impossible to teach software engineering. They might say you need years of work apprenticing for great software engineers to make it. However, not everyone can find great engineers to apprentice under.
At minimum, the journey to become an effective, productive software engineer can be hastened with the right resources. With any luck, I hope to bottle up some of what I see in the best engineers, and scatter it to all the places around the world that aspiring software engineers live. At worst, the perspectives shared here can stoke a debate — vitriolic, if instructive — about what mindsets and skills comprise the best software engineers.
I want this series to be opinionated and controversial. I also want it to be collaborative, with other engineers contributing to the series. The lessons will also most reflect great startup engineering and perspectives at Silicon Valley companies.
All feedback can be directed to me ([email protected]). Disagreement is highly encouraged.