FB Share

An Introduction

This is the intro to the Software Engineering for Early Engineers series.

This series was born out of my frustration with how poorly software engineering is taught.

I started learning software engineering through a surfeit of missteps, costly in time, but invaluable in 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 see 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 discursions into the early history of MongoDB or ruminations Software Engineering for Early Engineers debates or common misconceptions in OSS have also highlighted a host of other challenges.

These issues are unsurprising given how poorly our current engineering education systems serves us. 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. And 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.

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 take these lessons and distribute them more widely, so that great engineers are just as consistently created outside the top schools or top tech companies or top open source projects?

Some will argue that it is impossible to teach software engineering. Instead, an apprenticeship under great software engineers and years of dutiful work is the only path to the top. This perspective especially fails people who can’t find great engineers to apprentice under.

At minimal, I’ll argue that your journey to 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.

This series is opinionated, and therefore necessarily controversial. It’s also collaborative, with a number of other engineers I respect contributing to the series. The lessons will also most reflect great startup engineering, web development, and perspectives at Silicon Valley companies.

This website will host a heavily curated list of pieces, while the associated Github will be more open to pieces that aren’t included here.

All feedback can be directed to me or on the Github. Disagreement is highly encouraged.

This is the introduction in the On Engineering series. The rest of the series is available here. feedback? drop a note to nemil at this domain