Career Philosophy: Product vs. Infrastructure

A running theme of my blog over the years has been me trying to figure out the landscape of the software industry and where I fit within it.

I'm an "Evergreen" and not a "Stack Chaser". Cool. I don't enjoy CS and math enough to get hired at a FAANG company. Got it.

One dimension of the software career landscape that I had not considered until recently is Product vs. Infrastructure.

As Michelle Lim breaks it down in her post Stop Just Using Frontend or Backend to Describe the Engineering You Like, there are two broad categories of software engineers:

1. “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.

2. “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end. 

Product-first engineers map to “Product engineering”—building, launching and maintaining features that solve user problems. They often love being in the same room as designers and product managers to learn about users, and they love finding technical opportunities that can improve the product.

Code-first engineers map to “Infrastructure engineering”—building infrastructure platforms that support applications, be it via building CI/CD pipelines, implementing logging, or supporting high traffic etc. They’re motivated to better the craft of programming and are often obsessed with things like test coverage, using the latest technologies, code architecture, etc.

We're so used to splitting engineers into "frontend" and "backend" roles. I love the idea Michelle puts forth that some engineers just want to be closer to the user's problem. That doesn't necessarily mean they have some preference for the set of technologies that run in a browser vs. run on a server, for example.  There are many ways to affect the user throughout the stack, and the technologies are not particularly relevant.

There's nothing more fascinating to me in the software world than learning about how users do their work and how I can use my engineering skills to make that work easier. And I feel very drained when I'm working "far from the user".

I guess I'm a Product Engineer. Who knew?