{"slug": "writing-toy-software-is-a-joy-2025", "title": "Writing Toy Software Is A Joy (2025)", "summary": "Writing toy software is a joyful and educational practice that helps developers understand systems deeply, according to a 2025 essay. The author argues that building small, non-production programs like a regex engine, OS kernel, or GameBoy emulator provides valuable insights that often prove useful in professional work. The essay encourages developers to embrace simplicity and avoid over-engineering to rediscover the craft's joy.", "body_md": "# Writing Toy Software Is A Joy\n\nWhy you should write more toy programs\n\n*15 Jun 2025*\n\nI am a huge fan of Richard Feyman’s famous quote:\n\n“What I cannot create, I do not understand”\n\nI think it’s brilliant, and it remains true across many fields (if you’re willing to be a little creative with the\ndefinition of ‘create’). It is to this principle that I believe I owe everything I’m truly good at. Some will tell you\nto avoid reinventing the wheel, but they’re wrong: you *should* build your own wheel, because it’ll teach you more about\nhow they work than reading a thousand books on them ever will.\n\nIn 2025, the beauty and craft of writing software is being eroded. AI is threatening to replace us (or, at least, the most joyful aspects of our craft) and software development is being increasingly commodified, measured, packaged, and industrialised. Software development needs more simple joy, and I’ve found that creating toy programs is a great way to remember why I started working with computers again.\n\n## Keep it simple\n\nToy programs follow the 80:20 rule: 20% of the work, 80% of the functionality. The point is *not* to build\nproduction-worthy software (although it is true that some of the best production software began life as a toy).\nAggressively avoid over-engineering, restrict yourself to only whatever code is necessary to achieve your goal. Have\nevery code path panic/crash until you’re forced to implement it to make progress. You might be surprised by just how\neasy it is to build toy versions of software you might previously have considered to be insummountably difficult to\ncreate.\n\n## Other benefits\n\nI’ve been consistently surprised by just how often some arcane nugget of knowledge I’ve acquired when working on a toy project has turned out to be immensely valuable in my day job, either by giving me a head-start on tracking down a problem in a tool or library, or by recognising mistakes before they’re made.\n\nUnderstanding the constraints that define the shape of software is vital for working with it, and there’s no better way to gain insight into those constraints than by running into them head-first. You might even come up with some novel solutions!\n\n## The list\n\nHere is a list of toy programs I’ve attempted over the past 15 years, rated by difficulty and time required. These ratings are estimates and assume that you’re already comfortable with at least one general-purpose programming language and that, like me, you tend to only have an hour or two per day free to write code. Also included are some suggested resources that I found useful.\n\n### Regex engine (difficulty = 4/10, time = 5 days)\n\nA regex engine that can read a POSIX-style regex program and recognise strings that match it. Regex is simple yet shockingly expressive, and writing a competent regex engine will teach you everything you need to know about using the language too.\n\n### x86 OS kernel (difficulty = 7/10, time = 2 months)\n\nA multiboot-compatible OS kernel with a simple CLI, keyboard/mouse driver, ANSI escape sequence support, memory manager, scheduler, etc. Additional challenges include writing an in-memory filesystem, user mode and process isolation, loading ELF executables, and supporting enough video hardware to render a GUI.\n\n### GameBoy/NES emulator (difficulty = 6/10, time = 3 weeks)\n\nA crude emulator for the simplest GameBoy or NES games. The GB and the NES are classics, and both have relatively simple instruction sets and peripheral hardware. Additional challenges include writing competent PPU (video) and PSG (audio) implementations, along with dealing with some of the more exotic cartridge formats.\n\n### GameBoy Advance game (difficulty = 3/10, time = 2 weeks)\n\nA sprite-based game (top-down or side-on platform). The GBA is a beautiful little console to write code for and there’s an active and dedicated development community for the console. I truly believe that the GBA is one of the last game consoles that can be fully and completely understood by a single developer, right down to instruction timings.\n\n### Physics engine (difficulty = 5/10, time = 1 week)\n\nA 2D rigid body physics engine that implements Newtonian physics with support for rectangles, circles, etc. On the simplest end, just spheres that push away from one-another is quite simple to implement. Things start to get complex when you introduce more complex shapes, angular momentum, and the like. Additional challenges include making collision resolution fast and scaleable, having complex interactions move toward a steady state over time, soft-body interactions, etc.\n\n### Dynamic interpreter (difficulty = 4/10, time = 1-2 weeks)\n\nA tree-walking interpreter for a JavaScript-like language with basic flow control. There’s an unbounded list of extra things to add to this one, but being able to write programs in my own language still gives me child-like elation. It feels like a sort of techno-genesis: once you’ve got your own language, you can start building the universe within it.\n\n### Compiler for a C-like (difficulty = 8/10, time = 3 months)\n\nA compiler for a simply-typed C-like programming language with support for at least one target archtecture. Extra challenges include implementing some of the most common optimisations (inlining, const folding, loop-invariant code motion, etc.) and designing an intermediate representation (IR) that’s general enough to support multiple backends.\n\n### Text editor (difficulty = 5/10, time = 2-4 weeks)\n\nThis one has a lot of variability. At the blunt end, simply reading and writing a file can be done in a few lines of Python. But building something that’s closer to a daily driver gets more complex. You could choose to implement the UI using a toolkit like QT or GTK, but I personally favour an editor that works in the console. Properly handling unicode, syntax highlighting, cursor movement, multi-buffer support, panes/windows, tabs, search/find functionality, LSP support, etc. can all add between a week or a month to the project. But if you persist, you might join the elite company of those developers who use an editor of their own creation.\n\n### Async runtime (difficulty = 6/10, time = 1 week)\n\nThere’s a lot of language-specific variability as to what ‘async’ actually means. In Rust, at least, this means a\nlibrary that can ingest `impl Future`\n\ntasks and poll them concurrently until completion. Adding support for I/O waking\nmakes for a fun challenge.\n\n### Hash map (difficulty = 4/10, time = 3-5 days)\n\nHash maps (or sets/dictionaries, as a higher-level language might call them) are a programmer’s bread & butter. And yet, surprisingly few of us understand how they really work under the bonnet. There are a plethora of techniques to throw into the mix too: closed or open addressing, tombstones, the robin hood rule, etc. You’ll gain an appreciation for when and why they’re fast, and also when you should just use a vector + linear search.\n\n### Rasteriser / texture-mapper (difficulty = 6/10, time = 2 weeks)\n\nMost of us have played with simple 3D graphics at some point, but how many of us truly understand how the graphics pipeline works and, more to the point, how to fix it when it doesn’t work? Writing your own software rasteriser will give you that knowledge, along with a new-found appreciation for the beauty of vector maths and half-spaces that have applications across many other fields. Additional complexity involves properly implementing clipping, a Z-buffer, N-gon rasterisation, perspective-correct texture-mapping, Phong or Gouraud shading, shadow-mapping, etc.\n\n### SDF Rendering (difficulty = 5/10, time = 3 days)\n\nSigned Distance Fields are a beautifully simple way to render 3D spaces defined through mathematics, and are perfectly suited to demoscene shaders. With relatively little work you can build yourself a cute little visualisation or some moving shapes like the graphics demos of the 80s. You’ll also gain an appreciation for shader languages and vector maths.\n\n### Voxel engine (difficulty = 5/10, time = 2 weeks)\n\nI doubt there are many reading this that haven’t played Minecraft. It’s surprisingly easy to build your own toy voxel engine cut from a similar cloth, especially if you’ve got some knowledge of 3D graphics or game development already. The simplicity of a voxel engine, combined with the near-limitless creativity that can be expressed with them, never ceases to fill me with joy. Additional complexity can be added by tackling textures, more complex procedural generation, floodfill lighting, collisions, dynamic fluids, sending voxel data over the network, etc.\n\n### Threaded Virtual Machine (difficulty = 6/10, time = 1 week)\n\nWriting interpreters is great fun. What’s more fun? *Faster interpreters*. If you keep pushing interpreters as far as\nthey can go without doing architecture-specific codegen (like AOT or JIT), you’ll eventually wind up (re)discovering\n*threaded code* (not to be confused with multi-threading, which is a very different beast). It’s a beautiful way of\nweaving programs together out highly-optimised miniature programs, and a decent implementation can even give an AOT\ncompiler a run for its money in the performance department.\n\n### GUI Toolkit (difficulty = 6/10, time = 2-3 weeks)\n\nMost of us have probably cobbled together a GUI program using tkinter, GTK, QT, or WinForms. But why not try writing\nyour GUI toolkit? Additional complexity involves implementing a competent layout engine, good text shaping (inc.\nunicode support), accessibility support, and more. Fair warning: do not encourage people to use your tool unless it’s\n*battle-tested* - the world has enough GUIs with little-to-no accessibility or localisation support.\n\n### Orbital Mechanics Sim (difficulty = 6/10, time = 1 week)\n\nA simple simulation of Newtonian gravity can be cobbled together in a fairly short time. Infamously, gravitational\nsystems with more than two bodies cannot be solved analytically, so you’ll have to get familiar with iterative\n*integration* methods. Additional complexity comes with implementing more precise and faster integration methods,\naccounting for relativistic effects, and writing a visualiser. If you’ve got the maths right, you can even try plugging\nin real numbers from NASA to predict the next high tide or full moon.\n\n### Bitwise Challenge (difficulty = 3/10, time = 2-3 days)\n\nHere’s one I came up with for myself, but I think it would make for a great game jam: write a game that only persists 64 bits of state between subsequent frames. That’s 64 bits for everything: the entire frame-for-frame game state should be reproducible using only 64 bits of data. It sounds simple, but it forces you to get incredibly creative with your game state management. Details about the rules can be found on the GitHub page below.\n\n### An ECS Framework (difficulty = 4/10, time = 1-2 weeks)\n\nFor all those game devs out there: try building your own [ECS](https://en.wikipedia.org/wiki/Entity_component_system)\nframework. It’s not as hard as you might think (you might have accidentally done it already!). Extra points if you can\nbuild in safety and correctness features, as well as good integration with your programming language of choice’s type\nsystem features.\n\nI built a custom ECS for my [Super Mario 64 on the GBA](https://www.youtube.com/watch?v=nS5rj80L-pk) project due to the\nunique performance and memory constraints of the platform, and enjoyed it a lot.\n\n### CHIP-8 Emulator (difficulty = 3/10, time = 3-6 days)\n\nThe [CHIP-8](https://en.wikipedia.org/wiki/CHIP-8) is a beautifully simple virtual machine from the 70s. You can write\na fully compliant emulator in a day or two, and there are an enormous plethora of fan-made games that run on it.\n[Here’s](https://github.com/zesterer/emul8/raw/refs/heads/master/test/test.ch8) a game I made for it.\n\n### Chess engine (difficulty = 5/10, time = 2-5 days)\n\nWriting a chess engine is great fun. You’ll start off with every move it makes being illegal, but over time it’ll get smart and smarter. Experiencing a loss to your own chess engine really is a rite of passage, and it feels magical.\n\n### POSIX shell (difficulty = 4/10, time = 3-5 days)\n\nWe interact with shells every day, and building one will teach you can incredible amount about POSIX - how it works, and how it doesn’t. A simple one can be built in a day, but compliance with an existing shell language will take time and teach you more than you ever wanted to know about its quirks.\n\n## A note on learning and LLMs\n\nPerhaps you’re a user of LLMs. I get it, they’re neat tools. They’re useful for certain kinds of learning. But I might suggest resisting the temptation to use them for projects like this. Knowledge is not supposed to be fed to you on a plate. If you want that sort of learning, read a book - the joy in building toy projects like this comes from an exploration of the unknown, without polluting one’s mind with an existing solution. If you’ve been using LLMs for a while, this cold-turkey approach might even be painful at first, but persist. There is no joy without pain.\n\nThe runner’s high doesn’t come to those that take the bus.\n\n[let me know](mailto:joshua@jsbarretto.com)!", "url": "https://wpnews.pro/news/writing-toy-software-is-a-joy-2025", "canonical_source": "https://blog.jsbarretto.com/post/software-is-joy", "published_at": "2026-07-29 05:14:46+00:00", "updated_at": "2026-07-29 05:53:26.691555+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Richard Feynman"], "alternates": {"html": "https://wpnews.pro/news/writing-toy-software-is-a-joy-2025", "markdown": "https://wpnews.pro/news/writing-toy-software-is-a-joy-2025.md", "text": "https://wpnews.pro/news/writing-toy-software-is-a-joy-2025.txt", "jsonld": "https://wpnews.pro/news/writing-toy-software-is-a-joy-2025.jsonld"}}