Upside-Down Development

Consider this one of a thousand signposts I'll erect for the sake of anyone on the journey to becoming a full-breadth developer. What's discussed below is exactly the sort of thing that will separate the people who successfully wrangle coding agents from the people doomed to be replaced by them.

This post by Jared Norman about the order in which we design computer programs got stuck in my craw as I was reading it:

When you build anything with code, you start somewhere. Knowing where you should start can be hard. This problem contributes to the difficulty of teaching programming. Many programmers can't even tell you how they decide where they start. It turns out that thinking of somewhere you could start and starting there is good enough for a lot of people.

Relatable.

Back when people talked about test-driven development, I spilled a lot of ink discussing "bottom-up" (Detroit-school) versus "outside-in" (London-school) design and the benefits and drawbacks of each. Both because outside-in TDD was more obscure and because it's a better fit for most application development, I exerted far too much effort building mocking libraries and teaching people how to use them well.

Whether that work had any lasting impact, who's to say. It kept me busy.

In the broader scope of software development, the discussion of where the fuck to even start when programming a computer can take many forms. Most often, the debate comes down to type systems and the degree to which somebody is obsessed with or repelled by them.

At the end of the day, every program is just a recipe. Some number of ingredients being mixed together over some number of steps. The particular order in which you write the recipe doesn't really matter. Instead, what matters is that you think deeply and carefully consider your approach. The ideal order is whatever will prompt the right thought at the right moment to do the right thing to produce the right solution. The best approach is ever-changing. It will vary from person to person and situation to situation and will change from day to day.

But it's easier to tell people to follow a prescriptive one-size-fits-most solution, like to adopt London-school TDD or to use your type system.

Jared wraps with:

You can build any kind of structure with any kind of technique. Hell, you can write pretty good object-oriented code in C. You'll find no hard laws of computer science here. Your entrypoint into the problem you're solving doesn't decide how your system will be structured.

The order you tackle components merely encourages certain kinds of designs.

In programming, it's seen as a cop-out to inject oneself into a spirited debate between two sides and butt in to say that the real answer is "it depends." But one reason the question of, "where do we start?" has been so fundamental to my programming career—especially as someone who can suffer crippling Blank Page Syndrome—is that there actually is a right answer to the question. The hard part? The only way to arrive at that answer is to think it through yourself. No shortcuts. No getting around it. And if you want to get better over time? That requires deliberate and continuous metacognition—thinking about one's own thinking—to an extent that vanishingly few programmers will ever realize, much less attempt.