Programming with Aristotle

Starting Out and Breaking Things

I originally presented this essay as a brief talk at an engineering summit. Besides tidying it up and getting it to make sense in this new context, I present the original text unchanged below.

I’m supposed to talk today about “ramping up on an unfamiliar tech stack, working with legacy code, breaking old code (and breaking new code),” but before I get to the meat of the issue, I think it’s important to talk about what it means to start something. Starting as a thing that we can do has no shortage of ambiguity. Take for example what Aristotle says in De Memoria, which (borrowing a paraphrase from Semisonic) goes something like, “Every new beginning comes from some other beginning’s end.”

In other words, we always end up picking up somewhere in the middle. I’m lucky that the middle I’m currently starting in is well built, but as with any complex system, getting acquainted takes time. Names have changed, tests don’t necessarily run, and you frequently find yourself wondering which ducks exactly those who came before you were thinking of when they came up with this or that duck-typed component. I’ve found it helpful, when ramping up, not just to read code and ask questions and run tests but also to isolate components and to try to get them working of their own accord. That’s how I made my acquaintance with the Assembly chat system and with projects on the Assembly platform, but I’m left wondering about the gaps in my knowledge. What questions should I ask to know when to circle back? How can I tell if I really understand something?

I mean these as honest questions that I don’t have answers to, although I guess I’ll try for the next minute or so to gesture towards some possible avenues of inquiry. The only thing that I’m really sure of is that there’s little sense in throwing any babies out with the bathwater. Just because I’ve joined a small team and have different opinions on, e.g., semantic whitespace or type safety than the opinions expressed in the system that’s in place doesn’t mean I have license to rewrite what’s in place.

It does, however, give me license to break what’s in place — but in controlled and specific ways (and only occasionally and accidentally in production). The benefit of a broken component is the challenge to put the pieces back together in a way that makes sense for the system as a whole. Broken components — like the busted chat module that I deployed my second or third week in — become isolated, decoupled components that yield dividends for the components around them.

And broken components, once fixed, better illustrate the gaps in the architecture. I think most people’s first impulse is to fill these gaps with something new and awesome, like a Flux architecture on the front end or a fancy server-to-server protocol somewhere in the middle of the stack. I wholeheartedly endorse this impulse, but we need to recognize that this new code can and should be broken too, that it has imperfections waiting to be revealed, and that it needs to grow with the system as a whole.

This is what I find so appealing about Aristotle’s notes on starting: to build robust systems, we need to recognize that we’re always in the middle of building them and that progress itself involves no small amount of recursion. So let’s break things, go back and fix them, and somehow end up ahead of where we started.