John Kerl's home page

About

I’m a software engineer — but so are a lot of us these days. What kind am I, and what do I value?

Managing complexity: Software is a huge part of our lives, more than ever. And, unlike the earliest days of computing, you don’t need to be a programmer in order to use a computer. Click a button and you’re online chatting with someone across the world, and you don’t have to know everything about how the video-chat frontend (let alone backend infra) works. It’s magic, and it just works. But somebody — several somebodies — do need to make the magic happen in all its detail. Organizations that own systems need them to deliver value today, tomorrow, and the next day — and they need people like us to make that possible. Seeing (and advocating for) the amortized costs and benefits, both obvious and non-obvious, of our work over time is essential to how we define our value to the world.

Owning complexity: I like being a place where the buck stops. I value depth over breadth (although I value them both). I take full responsibility for service ownership, user experience, operations, observability, and maintainability. Writing code is only a small part of what software engineering is --- there are the cross-functional collaborations that guide us, the code itself whose lucidity enables and inspires us, the documents before/during/after that make us confident and quick, and the metrics/observability that keep us sane and nimble as we own more and bigger systems over time.

Curiosity: I’m endlessly curious. I’m a googly-eyed polyglot, forever enamored with languages (both natural and artificial) that we invent to communicate and automate our thoughts. Among my pantheon of heroes are Hopper, Backus, Ritchie, Gosling, Eich, and van Rossum — they invented new languages and taught the rest of us to speak them.

Broadening clarity: While it’s good that most of us don’t need to understand everything about software to use it, the opposite problem is also to be avoided: only one person at a company knows how something works, and things stay broken if they’re out of the office. Or worse (and this happens all too often): zero people still at the company know how a thing works and everyone’s afraid, and unable, to make any changes to it. Here again the four-legged stool of collaboration, code, documentation, and observability keeps us balanced. If we are to best serve our organizations into the future, we should think of ourselves not as software engineers, but as system-knowledge-management stewards. Our work isn’t done on the release date — our works goes on as we cultivate living communities that thrive in clarity, flexibility, and confidence.

Transparency: Researchers do reproducible science — this is why there are everything from lab notebooks to research papers and confirmation studies. Similarly, we in the software world need to do reproducible engineering. To say The bug is fixed! is necessary, but insufficient: a problem is more deeply solved when more of the following have happened: the cause is understood; underlying opportunities for error have been fixed, not just the particular incident; unit-test cases have been added that catch in a future-proofed way; other people on the team also understand how to have debugged the problem, including whatever debug steps the bug-fixer went through. The latter empowers everyone on the team to have similar aha moments in the future. A functioning codebase without well-lighted, well-signed on-ramps and navigation is an incomplete codebase.

More platform than product: The world very much needs people who can deliver sustained successes of getting the next product-betas out into the world of headlines. As much as I admire (and support) them, I’m not in this career for the competition — within an organization, I’m happiest when I’m of service to a team, working toward sustained, collective successes, doing the thankless work that gives others less to worry about.

Force-multiplication: There’s that saying: teach someone to fish and you feed them not for a day but a lifetime. One of the highest forms of engineering is tool-building that lets non-experts do amazing things for themselves and others. Not just the programming-language-author pantheon I mentioned above — anytime we invest the hard work of encapsulating capabilities into a tool with good user experience, we unlock the human potential in those around us. We help each other do far more than we could alone.

And yet ... everything we do has the opportunity cost of what else we aren’t doing in the same amount of time. If, like me, you focus on amortized costs and benefit over the medium term then you forego some of the glamor and cachet of landing only immediately visible near-term wins. If you help avoid disaster, you may not get as much credit for the disasters that didn’t happen as you would for dealing with them had they happened. Curiosity is a hard master — it can lead us down paths where the deepest insights lie, but it takes time. Writing good documents takes time during which you could have shipped a bit more code. Doing the force-multiplicative development that lets people solve their own problems brings the risk of underselling the work it took to get there.

And yet ... I’ll take it — sustainable reliability brings rewards that few other forms of work do.