Over the past decade “developer infrastructure” teams have become an increasingly common presence in industry. Focused on serving the unique needs of an organization’s engineers, their responsibilities can be as modest as build script support or as ambitious as developing new general-purpose programming languages. As a practitioner they can be a wonderful place to work; a perfect environment to apply state of the art techniques to real world problems and invest in new ideas, all while keeping a tight feedback loop with a potentially massive user base. But with great power comes great responsibility, and the potential for waste is real.

How many build systems, UI frameworks, code review tools, and bespoke IDEs have been developed in industry because of “unique needs”? Of those, how many actually improved the state of the art or eventually provided a return on their investment? Why does conventional wisdom — or common sense — so seldom apply when we choose to pursue these sorts of projects? (Why is it so often easier to get funding to develop a new programming language than it is to make critical improvements to an aging but essential piece of infrastructure?) The truth is that we often build new developer tools not because they’re necessary, but because personally meaningful, easy to rationalize, and fun.

While fun is great – I’m a big fan of it – we have a professional obligation to be honest about our intentions, use resources responsibly, and go into our work with open eyes. In this talk I aim to call out the most common sources of irrational exuberance when it comes to developer infrastructure, and the lies I’ve been told (or told others) to justify certain classes of projects. Where appropriate I’ll provide cautionary tales from my last two decades working in the field (names will be changed to protect the innocent), sensible alternatives for those wiser than I was, and advice for those foolhardy enough to try and build that better wheel. (Because I guarantee you – whatever mistake you’re thinking of making, I’ve either made it myself or know someone who did.)

The discussion and AMA following this talks will be moderated by Keith Adams.

Joe Pamer is an Engineering Director at Instagram, where he serves as their Head of Infrastructure, Feed, and ML. Before joining Facebook to help lead their programming language efforts, he was instrumental in the design and development of the F#, TypeScript, and Swift programming languages, and has contributed to many other major developer technologies ranging from .NET to VS Code to Clang. He currently resides in Brooklyn, New York.