App mindset, Infra mindset

Hey there newsletter readers. I'm Nat Bennett, software consultant and dog namer extroardinaire (current front runners for the next one: "Stroopwaffel" and "Big Hissman") and you're reading Simpler Machines, a weekly letter about computers and how to make them behave better by letting them do fewer things.

This week, by the way, the letter likely won't be weekly – family vacation coming up, so I'm taking a break.

In the last few years I've worked as both an infrastructure engineer and an application developer, switching back and forth between the two from team to team and job to job. It's a little bit like the engineer/manager pendulum, but for engineering specialties. Switching back and forth regularly gives me superpowers, and I bring the skills from the other specialty to whatever team I'm on.

Lately, I've been on an application team, so I've been doing a lot of infrastructure work – teaching Terraform, explaining what the big deal is about containers, digging into the details of our build system and deploy systems. I also spend a lot of time helping my team understand and interface with infrastructure teams– because the infrastructure mindset is really different from the application mindset. Each speciality sees the system they work on together very differently, and those different assumptions can lead to conflict if you're not aware of them.

When I have an Application Mindset, I care a lot about the details of one particular application. My app is a "pet," even if the servers it runs on aren't. I'm thinking about what's going on inside of it, what its code is doing and how that code is structured. I'm thinking about the people who use it and what exactly they're trying to do. When I interact with other systems – the platform it runs on, the pipeline that deploys it, the data services it uses, the other services it talks to – I'm thinking about those systems in relation to my app. I care about the details of individual requests. I want everything to be optimized for my particular use case, my particular workflow.

When I have an Infrastructure Mindset, an app is just an app. It's "cattle," one of many. If I care about some detail of it, it's probably a category that it shares with other applications– what language it's written in, what framework it uses, what common dependencies its packaged with. Same thing with requests, data services, and most of the infrastructure I deal with. They're each one of many, and I care about their behavior in aggregate. I care about error rates, and individual errors only as examples of a type of misbehavior. I care about scale, both of the system as a whole, but also about my team's ability to support ever-more applications and ever more application developers. I want every individual thing to be as similar as possible to others of its type, so I can manage it in aggregate.

Not every conflict between the two groups comes down to this difference but it sometimes calms everyone down a lot to point out that e.g. some release team's baffling insistence on some inconsequential detail is because they're dealing with hundreds of things with that detail and that it's tremendously simpler for them if all those things are the same. Infrastructure teams often take for granted that standardization is important, but this isn't obvious to people who work primarily on applications, because the details inherently matter so much for apps.

Likewise – folks with an infrastructure mindset often have some blind spots around which details are most important for applications and application developers. They may assume, especially, that the work involved in setting up new applications and services is trivial or straightforward, or at least obviously worth the investment in learning, because they do it all the time. But for an application team, "setting up a new application" is something that they may only ever do once, so anything they have to learn to be able to do it won't be as obviously valuable to them.

Conversely, if a process is really difficult at the beginning, or while the code is changing all the time, but then gets easy once the application is deployed and running, it will seem "easy" to an infrastructure-oriented team that spends a lot of time thinking about how to keep working applications working, and "hard" to the application team that mostly works on applications while they're actually changing the code.

So– next time someone on the other side of that line does something completely baffling ("organize all the apps in this repo by language," "complain about having to make their closed-source repo ssh-pullable just like the open source repos") I hope that this helps you understand what the hell they were thinking, and how you can explain what you and your team needs.

Media etc.

Moon Knight. It's good. Oscar Isaac does actor stuff and he's great at it. I've mostly stopped watching Marvel stuff because deeply tedious but I was glad I made the exception here. He's one of these rare-ish dudes who's unreasonably handsome for how good of a character actor he is, and Moon Knight really relies on his ability to convince you that the two characters he's playing are different people. Can't say too much without spoilers but he's really skilled at body language and the show really showcases this, especially later in the season.