If you were in charge of the curriculum at a college teaching web development, would you ensure the curriculum was regularly updated with bleeding edge technology? Or would you establish a slower moving curriculum with tried and true technologies? That’s tough. You can’t just flip a coin. It may be impractical to re-invent the curriculum too often. Maybe it even leads to worse outcomes, for example, because the staff has no time to iterate and improve on a foundation, or the choice of cutting edge technology turned out to be a flash in the pan.

It also doesn’t have to be one or the other. I’ve never been intimately involved with planning a curriculum, but I’ve spoken with a decent amount of people in charge of this job over the years, and it’s more of a spectrum. As in, there is likely foundational courses that tend to stick around (databases, APIs) and others that are designed to be more de jour. Like more freeform capstone course building a portfolio or projects for a real business. The tendency is sticking with the tried and true, and sprinkling in the modern more conservatively, sometimes even only through things like guest speakers, optional workshops, or independent studies.

It’s easy to mock a college curriculum for being stodgy, but it might be a little closer to smart. You know what they always say, something something fundamentals.

I was thinking of this reading Nicole Tietz-Sokolskaya’s A student asked how I keep us innovative. I don’t.

One of the students asked a question that I loved. They asked something like, “As a principal engineer, how do you make sure your company stays at the forefront of innovation?”

There are two reasons I love this question. The first is that it’s a good and natural one, which I had early on too. The second is that it’s unintentionally leading. It assumes you should be working at the leading edge of innovative technology.

And that’s why my answer started with “I don’t. I make sure we don’t.” A leading question gets a snappy answer!

It feels like most developers hit this point in their career where they’ve seen enough problems-via-churn that they are like can we just do this a way that is known to work? Call it stogy, call it boring, call it old, whatever, systems that work are pretty darn cool in my book. (He writes on his WordPress blog.)

There are a myriad of desirable traits of old/stable/boring software: reliability, security-through-heavy-usage, hosting options, refined documentation, actually finding answers when you search for them, etc. Debuggability might be another one. In my experience, the rough edges of brand new technology are often around how it fails. Error messages suck, diagnostic tools may not exist, StackOverflow threads haven’t been hoovered into LLMs yet, etc. And thinking of how it fails in production is also interesting. Good advice from Ryan O’Neill’s Random Thoughts 15 years into Software Engineering:

Debuggability is highly underrated. When writing code, you have to think about how it will execute. You also need to be thinking about how it will fail and how you will debug it in production. Leave yourself audit trails, store data in human readable formats, and invest in admin tooling.

While we’re basking in coding philosophy, allow me to end with linking up Patrick Dubroy’s Cold-blooded software. It starts with a pretty unforgettable moment involving a baby turtle, turned heavy-handed software metaphor.

I see a similar dichotomy with software projects. Certain technology decisions lead to projects that are warm-blooded: everything is great when there’s constant motion on the project, generating heat. But put warm-blooded software in the freezer, and you’ll pull out a corpse six months later.

A cold-blooded project is like the baby painted turtle. You can freeze it for a year and then pick it back up right where you left off.

🐢