The first problem with blogging is deciding where and how to do it. I’ve written static site generators myself in python, ruby, and javascript. I considered writing another one in Rust, my current language of choice, but I decided that this would be too much of a distraction. I have a month between jobs at best, so I need to focus.

If you’re curious, this one is generated with Hugo, which I chose because of how many themes are available without me having to fuss and write one. The theme is a lightly-modified Risotto. The static files are hosted on AWS S3 behind Cloudflare’s free personal plan, because I don’t yet need any of their paid features. I manage the AWS and Cloudflare settings using terraform. I don’t yet have all my personal cloud infrastructure terraformed, but I might take the time to do that over my month+ between jobs. I have flinched from doing that in the past because it felt like too much work, but it was less work than I feared, and I now have reproducible results.

It’s been a long time since I blogged regularly. I still have a presence on tumblr but I’ve let it lag behind in the last couple of years. Work became intense and draining, and burnout meant I dropped a number of hobbies. I think it’s time to resume this one, though, with a focus on the kinds of topics I would have pitched as conference talks before the COVID pandemic.

Here are some topics I’d like to visit:

• The connection between technical dysfunction and organizational dysfunction, and why you have to deal with the organization first.
• How reading Peter Naur’s “Programming as Theory-Building” changed my priorities as a technical leader.
• Why technical correctness is the least useful kind of correctness in the real world (and how none of us ever make decisions based on this anyway).
• Problem statements + values statements: how to arrive at decent solutions to problems if technical correctness isn’t useful.
• What to do with a legacy monolith implemented with a language and framework you don’t know and/or dislike.
• Where “performance” comes from in the messy real world, and where it doesn’t come from.
• Why it took me a year to arrive at a one-line fix for a massive performance problem, and how I hope to shorten that time should I encounter a similar situation again.
• Why a relentless focus on reducing developer friction pays off in team productivity, and some ways to do this.
• The cost of breaking tech hiring so badly that productive, product-shipping engineers feel they have to “grind leetcode problems” to pass an interview.
• How dogmatism is an enemy: let’s not be dogmatic about methodologies, “best practices”, “design patterns”, or anything, really.
• When microservices are appropriate and when they’re not, and some varied approaches to slicing systems up.
• Data-centric analysis for systems design and how to coax people into doing it.

I am not a fan of single right answers for any of these topics. Most real-world tasks are complex enough that many approaches to them are viable, and the “right” approach will depend on the context. What’s your starting point? What does the system around you do right now? What are the people working on it comfortable with? What do they do well and what do they struggle with? Which tools fit their hands best? So in my theory, the best advice I can give anybody is about how to ask and answer questions about that context, and tell some stories about what worked and didn’t work for me.

I also hope to learn enough that five years from now I’ll be convinced that the Ceej writing these posts in 2022 was a prime chump who got much of this wrong. I’ll write another set of blog posts, and keep the blogging economy chugging.