The Unbearable Effectiveness of Being Able to Run the Damn Code
I've worked on computer systems in many different environments: cloud-native serverless functions, self-managed virtual servers, embedded devices, pushing code for on-prem bare-metal racks that I'm not allowed to look at, much less touch. My experience across all these projects has falsified a lot of opinions, but there's one thing I believed when I first started coding and still believe now, perhaps more than ever:
You need to be able to run the damn code.
Whether you're starting a new feature, testing your implementation, or trying to root-cause some gnarly bug, you need to be able to run the damn code.
Whether you're shotgunning printlns, attaching a debugger, or grinding out bugs with fuzzing, you need to be able to run the damn code.
Whether you're a senior operating at the highest levels of architecture, a junior hanging on by your fingernails, or somewhere in the middle trying to level up, you need to be able to run the damn code.
Whatever your scaling challenges, cost constraints, compliance requirements, ideological loyalties to this or that technology the thing you should never give up, no matter what the content marketing or the case studies or the highly paid consultants say is the ability to run the damn code.
Not “we have a functional core that we run in a serverless shell.” Not “we have a staging environment that developers can access.” Not “you can spin up an emulator for this data service that mostly works except for this long list of caveats.” You need to be able to run the code on your own hardware with full access, zero marginal cost, and total visibility into the process.
Anything less will become a productivity destroying, team blocking, project killing obstacle.
This means:
- Writing code that can run in an environment you can emulate: prefer containers to cloud functions unless you have a very good reason
- Use software that can be obtained without approval: either use an open source database or pony up for as many licenses as you have developers
- Write your code to be run: it can be a
composefile that emulates production or a local Kubernetes environment, but it can't be a pile of shell scripts and implicit state (unless you have someone who's extremely good at shell scripts) - Write down all the state: Keep your infrastructure definitions in version control and run them. A lot. Do devops as “developers can operate the system”, not “we have someone whose job is YAML and AWS certifications”
And of course having a coding agent makes this so much more true. Having a system you can inspect yourself is necessary. Having a system that an fast-working, dogged, and reasonably capable LLM-driven tool can interact with and iterate on without worrying about costs or permissions or dropping a database that you needed, actually—that's glorious.