Obligatory Blog Post About the Blog
Don't worry. We're not gonna get meta or anything.
Hello, there.
And welcome back to my blog. If you've read one of my starting posts from early to mid last year, then the tone of this post may already seem different. Last year, when I started putting this site together I wanted a few things out of it, but mostly: to write and share thoughts on software development. If you're thinking, “oh no, he's about to change everything!” then fret not, there will still be plenty of thoughts on software development shared here. I expect to continue writing about my opinions and experiences as a professional software developer, what “good” software development looks like, and sharing some specific guidance as best I may. I also want to do a little more and get a little better at all of it - if you know me, this probably sounds like business as usual.
That said, the last date on a long form post here is from June 2023. June! 2023! Gasp! Clearly, some stumbling in the writing process happened alongside some major life events - some of which are still in motion. I had a goal of writing 6 long form posts last year and failed to reach that for some and all of those reasons. Failure, however, is never the end.
So now, I am doing what I do whenever I fail at something. I am taking a fresh look at the situation, setting myself up for success, and doing my best to keep a steady rhythm in working on it. I'm expecting the next phase to be hard, and I'm hitting it straight on.
First off, I migrated from using Svelte Kit to using Bridgetown (more on that later) to ease the writing, development, and maintenance of the blog after learning what did and didn't work last year. I added some better structure and layout to the site to make finding and accessing blogs versus quick posts easier both functionally and on the eyes (more on that later as well). Lastly, I settled more firmly on a few things I want out of this small site.
During last year's efforts to reach that goal of 6 posts, I often considered writing about how I built the blog. I reflexively eschewed that idea because it felt like an easy out to count against my writing goal. “Ah, yes, let's write about writing!” I am regularly harsh on myself like this when it comes to measuring progress towards personal goals and I try best not to take the easy route for better and worse. My personal choices aside, this new evolution feels like the right kind of thing to talk about because it's about more than just building the blog. It's about failing forward, as we call it sometimes. It's about resiliency in the face of defeat.
The Right Frame(work) of Mind
Comfort, as it turns out, can be a productivity multiplier.
When I started this effort back in late 2022, I had a few ideas about what I wanted to build. First, I wanted to build it for myself and I wanted it to be fun and feel cool. There is little software, relatively speaking, that I get complete control over. Given that 40+ hours of any given week goes towards whatever my current employer wants me to build, I set aside a fair amount less time to build software on the side. This project should feel nice and relaxing to write, not stressful.
I also knew I wanted it to be cheap and relatively simple. I didn't need Wordpress, a fancy text editor, or anything else. Some type of simple static file delivery and some HTML output is what I needed. I've been developing frontends for over a decade at this point, so writing some HTML here and CSS there to get exactly what I wanted was no concession. I did know, however, I wanted some level of componentization to be available whether it was through a file based solution, a JavaScript library, or something else. If it could compile down to static files, that was it.
I settled on using Cloudflare Pages and Svelte Kit. Cloudflare's Pages product is great and free. It delivers your static files, allows hooking into Github repo's directly (including private ones, thankfully), provides a simple build system, and even provides preview deployments on Pull Requests. In fact, Cloudflare Pages is the one part here that hasn't changed because of how simple and useful it is.
Svelte Kit was nice at first and the componentization model even feels very React-like in many ways. JavaScript has a long history of being frustrating for many folks, but I'm happy with JavaScript and understand it well. I was happy to work in a JS context, or even a JSX-ish one. Svelte, however, continued to be a step away from my preferred mental model of development. React is easy to imagine and visualize because everything is a component, simple as that. In Svelte, I found it took a different paradigm which didn't map often to anything else I worked on. It was a little too different, it produced a few too many JS files, and it didn't make enough sense all the time to my brain. While I will still recommend it to anyone leaning towards a JavaScript based stack and it never broke or failed me, I still wanted something that felt more… comfortable. This wasn't a project I was pushing forward to make money or solve a problem, so choosing a different technology on a whim or preference or comfort was acceptable.
When I think of comfort in programming, I think of Ruby. And Rails. Both have a way of feeling like home to me. Maybe this is because I spent 8 years maintaining or managing an open source Rails project that I built from scratch, twice. Maybe it's because I've spent years writing Ruby scripts, libraries, and CLI tools. Maybe. Regardless, my favorite former manager mentioned working with Bridgetown on a new marketing site which was mostly static content. My interest was piqued. I've been down the rabbit hole of Ruby based static site generators and even gave the typical options like Jekyll a trial run back in 2022. None of them seemed to click at the time like Svelte did, but only a couple hours into using Bridgetown and everything seemed right.
I appreciate the similarities and differences it has from popular frameworks, some of the inspiration it pulls from others, and more. I haven't conducted any deep analysis of the differences, but the fact that it worked well for me and my needs right now (and in the near future) is all that mattered. It solved a few specific issues like: providing a familiar mental model, clearly separating the HTML and JS contexts, and giving me some helpers out of the box like a feed generator and including Stimulus as part of the JS bundle.
In the couple of weeks since I poked at Bridgetown initially, I've already migrated the entire site, ensured parity of all data and features, tested it, and deployed it behind this domain. In other words, I've done more work in a couple weeks than I found the interest to do in the last 6-8 months. Part of that is due to me restarting after recognizing my failure, but a bigger part of that is because building in this now feels much more inviting to me.
Getting Myself to Get Over Myself
My own worst critic is … *checks notes* … me?? Shit.
As I said, I've been developing front end user interfaces and sites for more than a decade. With that kind of time and experience, I'd be surprised if anyone didn't develop some opinions about what was annoying. The funny thing is finding myself making choices which end up annoying, of all people, me later on.
The initial idea for this blog was inspired by The Verge's own redesign in September 2022. Personally, I love The Verge, their style of reporting, their strategy, and most of all they produce. Primarily, the thing I loved about the redesign was the combination of long form and short form posts (or “quick posts” as they call them). It was during the Twitter/X transition and I, myself, had already migrated off Twitter to Mastodon. Prior to this point in time, I thought a blog would be too much pressure for too little reward. Not being a writer already, it felt like it would be a significant hurdle to write 500+ word posts for… who?! Me?! No thanks.
Around that time, on some episode of their weekly podcast, the Vergecast, their editor in chief, Nilay Patel, mentioned that one of their strategies was sending readers from their homepage to another site. Not even another Vox-owned site. Anywhere else. After all, why regurgitate someone else's reporting when you can link a reader of yours to the original post and provide a quick cue as to why it's worth reading? That was the trigger point for me. Sharing links was something I adored doing on social media. I loved using Twitter to link folks to interesting tech news, new ideas, and other random cool stuff (yes, and to make pun laden jokes, but that's a different blog post topic).
With all that in mind, I developed the initial structure of the site with a combination of a long form post on feedback and a couple quick posts to get started. I kept everything on the front page because… well, I didn't have a bunch of content yet. I felt the need to fill the front page and kind of just figured it'd be fine until the page felt long enough to do something about it. In hindsight, that plan worked, just not how I expected.
I wrote some long form posts, and in between wrote more quick posts by trying to find different sources that were worth sharing so that any reader, like you, could be exposed to lots of different cool sites on the web.
So I've shared a bunch of cool links and written a few long posts, but… eventually the amount of content triggered some very annoying internal opinions about what was starting to happen to my front page. Looking at the front page spurred thoughts like, “ugh, all these quick posts are drowning my last long form post!” or, “I don't want to write yet another quick post because it'll look like I've given up on writing long form stuff because the last one is so far down the page!” At one point I even thought, “wow, I hate this layout right now”. My years of opinion building collided with my initial “make-do” plan of a layout and I was stopping myself from dealing with the problem... Yes, the problem I created and had planned from the start to fix once it started breaking!
So I found a way to lower the annoyance barrier. I made the shift mentioned earlier and started building with Bridgetown. The momentum I gained from migrating allowed me to jump ahead and whip out a new structure and layout while trying out some of the framework's features. There was just enough content to help me feel comfortable putting in some new structure and it has led to something much more pleasant, if still simple. I feel now very similar to how I felt at the end of 2022 with launching the blog initially - energetic, comfortable, and like this is built first and foremost for myself with you, the reader, as a second priority. With those issues resolved, I can now revisit some ideas I had back at the start of all this.
Your Blog is Evolving!
dun DUN dun DUN dun DUN
For years prior to 2022, I considered having an online presence, but never had much motivation. As any web developer does, I have many bookmarks for simple, web based tools to do my job. After all, who among us internet citizens hasn't developed a list of bookmarked tools like a JSON formatter, some unit or format conversion tool, or even Eric Meyer's classic Decoder/Encoder. I've always thought it'd be nice to build and host my own tools, but I never felt the value was more than the effort it took.
That changes now. Now, this blog is built in a way that is easy for me. Even with Svelte, I had a hard time getting things to work the way I wanted them to rather than the way they did in Svelte. I was working around the framework. Now, the framework works for me. Now, I have access to the libraries and structure I want - including Stimulus or any other frontend library I'd prefer. Now, the page is built efficiently. So, now, I can build my own tools, guides, or anything else and it should be quick and simple provided I've made the time and taken care of myself (a challenge all its own).
So, in the coming months, I hope to build some useful tools, write some guides, and share more long form thoughts here so that my site can be a useful tool to me and, maybe, to you as well. Maybe I'll even go beyond that. After all, quick posts are very much like Mastodon posts, so an ActivityPub integration isn't outside of the possibilities.
Got an idea for a web based tool? Wish there was a better written guide for something? Want a deep dive into a topic or perspective on some aspect of software development? Go find me at one of the places linked at the bottom of the site and let me know.