Home-cooked, situated software

For July 2024, James is hosting the IndieWeb Carnival and he picked the theme of Tools for us to write up:

Over the next month, I invite you to write a blog post about tools and how they do, or have, influenced your createive process. You can write about tools in the context of any creative practice you have: writing, acting, drawing, painting, woodworking, cooking, coding, singing, VTubing, or whatever is applicable to you.

I’m extending James’ invitation to you! If you have a blog, why not join the carnival and join our jolly crew. We have a really fun community.

There are so many things I could write about. I have earlier written about how at the beginning specific tools matter less but as your skills improve, they become very important to master so I won’t go there today. I have written about how blogging is a great tool for refactoring and I have shared some of my favourite tiny software tools and tools and services that I use daily.

I’m a Saturday evening hobbyist

As a software developer, I mainly consider myself as a “Saturday evening hobbyist”: I love software development but the part of it that I enjoy the most is build small things for myself, my family, my friends and my communities rather than doing full-time professional software development (which I occasionally do to pay the bills).

Explaining it felt bit cumbersome though because it wasn’t easily clear to other people what that meant. That was until I read the notes and later saw the recording for Maggie Appleton’s Home-cooked Software and Barefoot Programmers (blog format) which lead me to learn how different people have described my approach in different ways. In her talk, she talks about how large language models (LLMs) can have a revolutionary impact on how non-professional developers can build software for their need.

I won’t be talking about LLMs but explore the ideas she shared about home-cooked software and how it relates to my relationship with software development and building tools.

Home-cooked software

The term of home-cooked software comes from Robin Sloan’s An app can be a home-cooked meal from 2020 where Robin describes a mobile app he built that had a small handful of users: his family. It was an application to record and share short video messages to other family members.

In his article, he talks about how he is the programming equivalent of a home cook:

People don’t only learn to cook so they can become chefs. Some do! But many more people learn to cook so they can eat better, or more affordably. Because they want to carry on a tradition. Sometimes they learn because they’re bored! Or even because they enjoy spending time with the person who’s teaching them.

He also writes about the freedom that comes from realising that not every software need to be a professional product:

When you liberate programming from the requirement to be professional and scalable, it becomes a different activity altogether, just as cooking at home is really nothing like cooking in a commercial kitchen. I can report to you: not only is this different activity rewarding in almost exactly the same way that cooking for someone you love is rewarding, there’s another feeling, too, specific to this realm. I have struggled to find words for this, but/and I think it might be the crux of the whole thing: [\n] This messaging app I built for, and with, my family, it won’t change unless we want it to change. There will be no sudden redesign, no flood of ads, no pivot to chase a userbase inscrutable to us. It might go away at some point, but that will be our decision. What is this feeling? Independence? Security? Sovereignty?

Situated software

Both Robin and Maggie link to Clay Shirky’s article Situated Software from 2004 where Shirky, who taught Interactive Telecommunications Program in NYU, talks about a paradigm shift he noticed in students’ approaches to building software services.

The biggest difference this creates relative to classic web applications is that it becomes easy to build applications to be used by dozens of users, an absurd target population in current design practice. Making form-fit software for a small group of users has typically been the province of banks and research labs -- because of the costs involved, Web School applications have concentrated on getting large-scale audiences. And by privileging the value that comes with scale, Web School applications put other kinds of value, particularly social value, out of reach.

It felt so reassuring or relieving to find other people talk about what I’ve been feeling and giving it better names, terms and analogies than I ever could.

I really like the first examples Clay shares:

The first had to do with reputation systems. One project, The Orderer (designed by Vena Chitturi, Fa-yi Chou, Rachel Fishman, and Cindy Yang) was for coordinating group restaurant orders, common in late-night work sessions. The other, WeBe (Brandon Brown, Yoonjung Kim, Olivier Massot, Megan Phalines) was a tool for coordinating group purchases of things like chips or motors. Because money was involved, a Web School approach would require some way of dealing with the threat of non-payment, using things like pre-pay or escrow accounts, or formal reputation systems.

I often hang out with professional developers: I run meetup communities, chat online with developers, attend conferences, and read a lot of blog posts and guides by fellow developers. A big chunk of the technical discussions there are about professional software and “best practices” for them.

But I love building what Shirky calls situated software. Software that doesn’t have to be universal, general and productised.

The gap between “just enough for us” and “public production-grade” software is massive and honestly, very little of that extra work is something that excites me. To bridge that gap, one needs to do a lot of work. There’s work to be done in infrastructure: scaling servers, authentication and user management (with all of the signup/recovery flow that it comes with), security and so on. And the user experience needs to be much more polished when the product is aimed for a larger audience.

One of the fun parts is also that when building these software, we don’t need to worry so much about “best practices” (I put them on quotes ‘cause I’m not convinced there are any). Rather: if it works, it’s good to go. The surface area for bugs and security problems is so significantly reduced compared to professional software that it’s okay to not follow all the patterns they teach in software engineering.

Some examples of my home cooked software

Party selfie app

One of my favourite examples of these types of trade-offs is from a small software I built for one event a few years ago. The company I was working for was sponsoring a social event and we wanted to have something fun for people to do while having a great time.

The application worked like this: there was a list of categories for which you had to find someone in the event who fit that and take a selfie with them. Think of categories like “a cat person” or “alumni of class 2015”. They would then post these images to a Telegram bot that I wrote, which would send them to a local Flask server that stored them in a local sqlite database and a simple frontend that showed the photos in real-time on a screen at the event.

To make this into a proper, production-grade application, there’s a lot one needs to do to build polished UX and add security and authentication features. Since it was meant to be used only once in that event and I had other work to do as well, I didn’t want to spend all that time to work on the extra stuff.

That’s why I kept everything local: to get started, someone needed to start a local dev server and open the localhost address on the browser to show the photos. The images were stored on the laptop and not shared in the web and everything could be easily deleted with one command at the end of the night.

235

Another example is 235 which is a command-line tool I built for myself to get NHL results into my terminal. It is a bit more polished and it is publicly available for anyone to install but it’s mainly built for myself, providing the features I want it to have. It was originally built as a project to learn Rust.

Pokemon TCG tools

Gym Leader Challenge Decklist Validator is another one. It’s purpose-built for our community of Pokemon TCG players and has a simple design. It has a small handful of users (to my knowledge, I have no analytics) since it’s a very niche use case.

Even more niche is a tool that I’ve been building for myself to build Pokemon TCG decks. As the official Pokemon TCG Live’s deck builder is not to my taste, I started building my own. It’s not finished, it’s not published but I use it weekly by starting a local dev server for my React project, use it and when I’m done, I close the dev server and go on with my day.

Tooling to run this site

IndieWeb wiki lists the key principles of the community, two of them being:

💪 Make what you need. Make tools, templates, etc. for yourself first, not for all of your friends or ”everyone“. If you design for some hypothetical user, they may not actually exist; if you make for yourself, you actually do exist. Make something that satisfies your needs (also known as scratch your own itch), and is compatible for others, e.g. by practicing POSSE, you benefit immediately, while staying connected to friends, without having to convince anyone. If and when others join the indieweb, you all benefit.

and

😋 Use what you make! Whatever you build you should actively use. If you aren't depending on it, why should anybody else? We also use the metaphor eat what you cook for this principle. Personal use helps you see both problems and areas for improvement more quickly, and thus focus your efforts on building the indieweb around actual needs and consistently solving immediate real world problems, instead of spending lots of time solving what may be theoretical problems.

My approach with building this website and the tools made to build and run it matches these principles. This is also what I’ve been telling students and juniors who want to get better at software development: build something that you need and will use because it makes it easier to find improvement ideas and be more motivated.

The tooling for this website and blog is a collection of custom scripts and software, mostly run either as Javascript functions with Eleventy during build time or as command-line tools to fetch blog posts, to manage post relation data, to handle Mastodon comments, to update my “Most popular” posts list and so on and so on. These tools are very specific to my site and they are not something that anyone else could pick up and add to their project as-is.

Ad-hoc one-off scripts

Sometimes these tools don’t even reach the “tool” stage. I weekly write short scripts of Javascript that I run in the console to do things like extract Youtube playlist videos into a Markdown bullet point format. These are tiny tiny scripts that are almost always one-use with specific use cases so I rarely store them in any files because it’s often easier for me to build them from scratch every time than to try to modify existing to a changed environment.

These can look something like this:

let talks = $$('#contents ytd-playlist-video-renderer') // Using Firefox's shortcut $$

Object.values(talks).map(talk => {
	let title = talk.querySelector('#video-title').textContent.trim();
  let href = talk.querySelector('#video-title').href

  let url = new URL(href);
  let videoId = new URLSearchParams(url.search).get('v')

  return `[${title}](${url.origin}${url.pathname}?v=${videoId})`
}).join('\n')

Another tiny local script that I developed during the writing process for this blog post is my shell utility ,table which allows me to generate a Markdown table template with any amount of columns to speed up the creation process.

All of these examples are the software equivalent of home meals that I cook to keep myself going, not for their monetary value or to be served on a restaurant menu.

I’m happy I can do this

Software development is a quite nice profession to have: the salaries are great, the work culture is often good (thanks to the big demand for devs) and you get to build tools and services used by people to solve their problems.

That’s not why I love it though. I love it because my ability to build what I need for myself, my friends & family and my communities enables me to make things that truly matter. These days, I don’t even notice every time I do it.

Even though my apps are not always usable as-is by other people, I aim to publish near everything as open source so if someone wants to see how they are built, they can. I also share my learnings and snippets and ideas as blog posts to inspire others.

Only once I started drafting this blog post, did I realise how much I rely on tools built by myself on a daily basis (and enjoy using them).

I wish everyone would have someone in their life who could help them with custom software. In Finnish, we often call these people “kotinörtti” (”house geek”, a play on the Finnish House Elf folklore) and they are often family members who help fix printers and solve other computer problems.

At the same time, I hope that as an industry, we’d also learn to not see ourselves as the universal only tool to solve problems – especially when those problems are not technical.

You can build own tools without coding too

Programming isn’t the only way to build tools either. It’s maybe the most efficient and powerful since there are few limitations but you can build all sorts of fun stuff with office tools like Powerpoint/Keynote/Google Slides with a bit of tinkering and imagination.

Youtube channel ZaneGames uses slides to create all sorts of fun Pokemon quiz games to play with his friends on their channel. Emeral went to the distance and built a VR Beat Saber style game with Powerpoint.

Back in the day, I taught idea phase startup entrepreneurs how to build mobile app prototypes with Keynote to communicate their idea.