Hello, I'm Russ, and this is my website. I'm a software engineer who programs for the love of the craft in an age of tech disillusionment. The purpose of this site is to give me a place to publish my thoughts in general and on programming, personal projects, and professional developments.
Publish Date: 2026-07-18
It's been two weeks in a row that I've not had the energy to put together the blog model. Why might that be? Two reasons come to mind.
The first is that requirements and design takes extra effort from me. I can do it and think I'm reasonable at it, but I concede that it's draining work.
The second and probably most realistic reason: my 'after-hours' time is mostly on Saturdays and Sundays. Spending those precious moments writing a blog article takes away time to design and make enhancements to my projects. The purpose of the blog is to drive that work, not encumber it.
So, for that reason I intend to back off on my writing. Let's go down to publishing on the third Saturday of the month. Site spec updated. In the meantime, I'm going to flesh out the blog database model, ORM model, and functionality. Hopefully when I post next on August 15, I'll have something better to say.
Publish Date: 2026-07-11
Last week, we discussed the ultimate goal of having an RSS feed. To do this properly, we would need a blog database model and to this end, I migrated the application's database access layer from native SQL to the Object Relationship Model implementation SQL Alchemy w/ SQL Model.
That being said, one thing I've learned from experience is that sometimes it's best to cut straight to the chase and focus on the end goal. Doing so confers some of the benefits of the goal without so much work and can help guide future plans. It's not that I want to cut corners. I do want to implement a basic blog in the end.
So, given that it's easy enough to manually create an RSS feed, I've done exactly that. This blog can now be subscribed to via RSS!
It's nothing special: just an XML file meeting the RSS specification. Some RSS feeds include the entire article, and have all kinds of fancy tags and custom fields. Mine is barebones, partly because I don't know RSS very well and partly because simple is often better.
However, manually updating my RSS feed is pretty cumbersome, so next week I'll turn my attention back to the blog model so that the feed can be generated from it.
Publish Date: 2026-07-04
With the web counter work last month, my blog graduated from a static HTML site into a jinja2 template-based site. I'd now like to go a little further and display articles from a database. For now, I'll continue to display the articles all on the index page, but my ultimate goal is to have a more fully-featured blogging platform, including an RSS feed.
Why an RSS feed? For one, an RSS feed would help make the blog more visible to search engine crawlers, raising traffic. I'll be honest: nobody reads this blog, it's new and mostly unoriginal. I make it for myself, and I don't need people to read it in order to continue publishing. That being said, attention is nice. Maybe one day I'll publish content that people are hungry to read?
Also, I've never worked with RSS before and it would be great to learn it. That's why I'm here, after all.
"Remember that all is opinion." - Marcus Aurelius
One other thing that would be nice is to pick up an Object Relational Mapping (ORM) library for my database model. These are controversial in the programming community, with many arguing that simple SQL is adequate for most cases and that ORM gains are questionable. Myself, I find ORMs lovely to work with:
Some care is needed to avoid N+1 problems, but otherwise, ORMs are great IMO.
Anyhow, the counter logic has now been ported to an ORM. I'm using SQLAlchemy with SQLModel on top for interoperability with Pydantic. My next goal will be building out a blog model. Stay tuned for that next week.
Publish Date: 2026-06-27
After some reflection, I've decided to scrap the plans to submit to Wiby. To be clear, it's an excellent search engine and I fully believe in its mission. The trouble is that its policy on CSS and Javascript is in conflict with my goals. I would like to enhance this site to be more than just a software blog. Ideally it would showcase interesting features like toy games and widgets, polls, experiments, syntax highlighted source code examples, etc. Most of these features are completely out of reach without modern client-side tooling.
There are more practical reasons, too. Earlier, I was adding the first version of the site's hit counter and I discovered that I wouldn't be able to align the "since date" text and the counter without CSS. Yes, an HTML table could be used for this purpose, but they're not really intended for laying out page elements. Do I really want to use a frowned-upon web technique to layout my site just for Wiby compatibility?
I considered making a Wiby-mode URL parameter for the site which displays the site much like it exists today and submitting that URL to Wiby. On further reflection, though, I think that's wrong-headed. Plus, it's against Wiby's policy which explicitly states: "Don't submit a page which serves primarily as a portal to other bloated websites."
The part of Wiby's mission that I really like is where personal/non-corporate sites are featured. I want to be part of the movement to take back the web for regular, everyday people like me and you.
So, where should I submit? Here's a short list I'm considering:
Bam. The site spec has been updated. I really like that, by the way: the site spec determines what this site is. We can use it to keep the site on mission. Yes, that's the royal "we".
I guess that's it for now. Despite dropping Wiby support, I really do want to keep a minimalist aesthetic, and I may also make a "90's mode" feature for the site anyway. What personal website would be complete without animated GIFs, custom separator lines, and MIDI background music, after all?
Publish Date: 2026-06-20
Why program after hours? One clear reason: Programming is activity that gives me immense joy. Solving unique challenges, designing systems, and watching a project come together provide a huge sense of accomplishment.
After hours programming is a great way to build fun things I wouldn't get to build at work. During the last year, I:
It's also an opportunity to learn new libraries, languages, and infrastructure. Learnings at home often pay off at work. For example, a few years ago, I picked up Bootstrap on "for-fun" projects, then later I found myself using it at work and it was a huge boon. I've had similar experiences with languages and libraries like Java, C++, Rust, Python, and PHP. For this site, I'm getting to play with domains, DNS records, hosting providers, and Postgres.
I expect at least some of these learnings will pay off in the future.
Yes, programming after hours is fun and reward. Most days though, I have a hard time convincing myself to actually spend extra time on it. I'd been feeling this way for a while, so this week last year, I challenged myself to produce one commit of code per day for a full year. My goal was to fill the GitLab Activity Chart.
Here's the outcome:
I know, it's silly. Like lines of code, pull requests, and tokens, commits are not inherently valuable. A commit can add nothing, or remove value. For example, imagine a half-baked feature filled with bugs, or a changeset that adds a space one day and removes it the next.
Streaks are motivating, though. Daily contribution ensures some amount of continual engagement which, IMO, is required in order to even remember the state of a project between work sessions. So, for me, the commit streak concept is less about the commits themselves and more about providing a system to force me to continually return to my projects.
The challenges to spending extra time programming are about what one would expect.
Fatigue: For me, the biggest me is that it's just difficult to convince myself to spend extra time programming after my day job. More sitting, more thinking, more analysis. Bleh.
Busyness: There are places to go after work, groceries, family, exercise, etc.
Motivation: If I'm not in the middle of a project, it's hard to overcome the mental friction to start a new one. Speaking of which, AI is a threat to motivation for me. I'll write more on that in later post.
Streaks are highly motivating for me. They create a gamified system for coming back to a project regularly which ensures continued attention is given to it. That attention translates directly into progress, whether it be building an application, learning a language, or improving at some other skill. That's the main and powerful benefit of streaks.
Streaks do have problems and limitations.
For one, our lives are not be defined by the streaks we keep. Some days, one simply needs a break and permission to take some time off from Wordle.
Also, taking baby steps each day does not build a Saturn V rocket. Concentrated effort, long sessions, and deep planning are required for large projects.
Streaks are not always easily measured, making them difficult to track. Apps like Snapchat or Duolingo are noted for providing streak systems. Daily coding is a little more tricky to track. One issue I ran into with tracking "one commit per day" as my streak metric was that some days I would make many commits while other days it was a struggle to make even one. A solution I came to was to use git to push just one commit rather than all of them. That isn't great either because one of the reasons we push to begin with is to back up our code to an external system. Only pushing one commit a day means some changes are not backed up. It would also be a non-starter if the projects that I'd been working on were multi-person since my changes might be needed by others. Also, GitLab's Activity Chart measures contributions, not commits which further complicated my metric.
Failing to maintain a streak is instantly deflating. Five times over the year, I simply failed to push a commit. The worst instance was on 2026-04-13. After a nearly 9 month streak, I simply forgot to push a commit that day. I had +50 commits lined up, too. All I had to do was sit down and push one of them, but I forgot. "Oh no, I broke the streak", better just give up now and call quits on programming.
So, IMO, streaks are useful but come with a lot of drawbacks.
Another angle is to set achievable goals. This isn't in contrast with steaks and in fact works well alongside them. In the absence of a steak, some other motivation mechanisms should come with the goals:
IMO, "fun" is a fantastic motivating factor: fun naturally keeps us coming back without being bribed, guilted, or forced. Not every goal is fun, though.
Goals can fall flat if they lack well defined outcomes or scheduling. Another pitfall is procrastination or perpetual postponement of deadlines.
Ideally, working toward a project or goal should be reward unto itself, but sometimes something extra is needed. One idea I learned from Habitica is the idea of rewarding oneself for completing a task. Spend an hour programming; earn a TV show, ice cream sandwich, etc. This clearly has drawbacks: rewards can lead to bad behaviors outside of the projects (read: "too many ice cream sandwiches"), also sometimes one really just needs an ice cream sandwich with no strings attached.
One thing is for sure: I'm going to stop the "one commit per day" strategy. It's just too cumbersome, easy to forget, and sometimes it just feels meaningless. Later today, I'll push my backlog of all unpushed commits.
I like aspects from streaks, goals, and rewards, but feel that none of these approaches is ideal. Maybe there just isn't one. Instead, I'm going to change my approach. I'll commit to writing one article per week on this blog. The topics discussed should keep me motivated and working towards goals. If I feel like I'm dragging one day, I might promise myself a treat. I'll report back later and let the reader know how it goes.
Publish Date: 2026-06-13
One staple of the old web was the humble hit counter. Counters are a number presented on a site in text or graphic form which represent the count of visits. They still exist today, especially on the "indie web" (Indie Web, Neocities, Wiby), but in the early-to-mid 2000s, they were mostly replaced by more comprehensive systems like Google Analytics which tracked many metrics: browser, geolocation, language, timezone, referrer, etc. Systems like GA are in many ways superior to hit counters except in their reliance on a corporate, third-party system.
For those who've never seen them, here's an example I made in GIMP (I tried very hard not to use any 3s or 7s in the example):
Web counters are a simple concept: each time the counter is accessed, increase count by 1. This post seeks to design a simple web counter for the site.
Here are some desired properties:
The Encounter properties might be useful or interesting for later analysis and can answer questions like:
Let's persist the model in a relational database.
I would like to avoid utilizing cookies because nobody likes those and because I'd like to avoid a GDPR cookie prompt if possible.
Many encounter entities to one counter entity. Pretty straightforward.
I considered having a resource entity which represents the URI that's accessed when an encounter occurs. However, I felt this was duplicating the presence of the counter on the resource's landing. Said another way, the counter's relationship to a URI is defined by its presence on the landing, not by configuration in the database. This allows the front-end to move a counter from one location to another without changing the database.
For the initial version, we'll hard code references to the digit graphics. This will eliminate the need for configuration, for now.
Only one operation is needed:
In today's age, there are lots of great font libraries out there, but I would like to build my counter graphic server-side, the way they used to be built long ago.
There could be other operations like registering a new counter, resetting a counter, deleting a counter, etc. This is too much for now and each would require an authentication mechanism.
Ok, it's time to get to work! I've already started building out the database model, but this week I'm aiming to finish the implementation and put a shiny new counter on each page of the site.
Publish Date: 2026-06-06
Today's project is to start this site and establish it's initial goals. Before publishing, let's walk through some topics.
Should this blog be published under my real life name or under a nickname? I struggle with this one for a number of reasons.
For starters, my opinions change over time and I don't want to be defined by something I wrote 10 years ago which is now controversial. I think of myself as a well-rounded individual, but any take can potentially turn sour over the years.
Also, some things I might write could be unpopular with potential employers. For example, at the moment, employers have a cult-like obsession with "AI". Any criticism could be bad for my work reputation and employment prospects.
OTOH, I'm a professional in it for the love of the craft. I would like credit for my own thoughts and work. And, publishing anonymously is almost a form of self-censorship. Goodness, it's a free country, after all.
So, let's do what's only reasonable: Publish objective content, use opinion sparingly, stay civil, ask reader for grace.
How often shall it receive updates?
Let's go with weekly as a goal. Daily is too much for me to keep up with, monthly may not be enough to establish a habit.
I program in my spare time for learning and fun, and I often wish to have a medium to write down my ideas. I could, and do, write these ideas on paper or in a text editor, but there's some value in preparing an idea for a reader. The act of explaining the idea often refines it.
Sometimes I may want to explore software engineering topics such as specific technologies, APIs, frameworks, or "AI".
I would like this site to be minimalist in nature. This is not a rejection of modern tech, but a celebration of the Internet's roots, a topic I'd like to explore in more detail later.
For now, let's use HTML5 and minimal Javascript and CSS. This should ensure that minimalist search engines like Wiby will index it.
I would also like to have some back end application to facilitate "fun" demos and to store basic information like traffic statistics--let's not go overboard, though.
The above basics should provide some ground rules to keep me producing at a sustainable pace.
I've published a summary of this planning exercise under the "spec" link above.
