Lessons in Shipping Real Software

How I learned to stop fidgeting and deliver working tools.

May 20, 2026

I first learned how to program at the age of 13, intending to write mods for 3rd generation Pokémon games—which incidentally are still the target of modding efforts today. I only shipped my first piece of software written for real users when I was 29. Yes, I spent a larger portion of my life knowing how to program and not doing anything with it beyond fiddling than I had spent not knowing how to program.

The trajectory between both points is rather long, involves a lot of detours, false starts, general tomfoolery, and is broadly kind of boring. What I wanted to discuss today were the things that had to happen before I could ship real software after I had learned how to program.

I Needed The Right Care

A body that isn’t functioning properly can mean very suboptimal function of the brain, the single most important organ when it comes to software development.

I transitioned to female. It turns out that crippling gender dysphoria can get in the way of writing code, let alone doing anything really.

I started taking CNS stimulant medication every day, as prescribed by my doctor. Executive dysfunction means one’s ability to manage the complexities of software development is shot, and anything to keep that dysfunction at bay will help. Stimulants also help me to cope with dysfunctional reward circuitry that would otherwise make it impossible to persevere with long-term projects.

I began observing a strictly gluten-free diet. I don’t have a diagnosis for celiac disease, but implementing this change did completely eliminate most sources of chronic pain in my bowels and joints. Bowel pain in particular is noteworthy as a significant contributor to economic stress, due entirely to the symptomology of IBS and not any biological damage caused by the disease itself as it is relatively harmless. Not only did I experience similar symptoms from eating gluten my whole life, but celiac disease does directly cause many secondary health issues if not addressed through elimination of gluten from one’s diet. These pains in my body would often interrupt my train of thought in times when I wasn’t hyperfixated on specific projects, and it is wonderful to be rid of them. It is also nice to know that any deletrious health effects I may have eventually experienced from eating gluten are now arrested.

I Needed The Right Workspace

I started using the GNOME desktop on Linux—my main working operating system—after years of tinkering around with pointless tiling window managers that I now believe to be a net negative on user wellbeing. The problem with a computer that constantly begs to be tinkered with is that tinkering can often be just as stimulating as doing real work while rarely having an upside. GNOME is designed to minimize distractions, and this design is backed by lots of user testing.

I wrote my own text editor for use in programming and general writing. Coders and programmers have long had “holy wars” over which text editor is best. There is no one-size-fits-all answer, but decades of trying only gave me text editors rife with distractions. For programming, I was expected to use IDEs with constant popups suggesting function and variable names to use. In those and many others, I’d be confronted with colourful “syntax highlighting” that would flash in a dizzing array of colours every time I typed a quotation mark or opened a block comment, assuming I didn’t have automatic closing of braces enabled. I never did, because I always found that these features were more trouble than they were worth, often inserting extraneous or incorrect additional characters that I didn’t expect or want. For “simpler” text editors aimed at programmers, often they still have hundreds of settings and advanced features that would prompt me to figure them out instead of continuing with whatever task I was trying to accomplish.

Since its earliest versions, Parchment helped enable most of my projects in the past two years. While it is of course tuned to my specific tastes, the fact remains that no users will spend more time tinkering with it than actually writing what they want, because it is untinkerable. Tools that resist being made into fidget toys are themselves a superpower when your brain craves easy feelings of accomplishment.

I Needed The Right Language

When it comes to actually writing software, I used to spend a good chunk of time trying to learn various programming languages. I’ve tried learning Go, Haskell, Nim, Lisp, Forth, as well as tried honing my skills in various languages I learned while on the job but never found anything that didn’t eventually get in my way or somehow annoy me until I found Lua.

Lua is small and minimal. It lacks libraries for many simple tasks, instead requiring the use of external dependencies or simply writing the code yourself. The downside is added friction where in other languages it may be easier to get started with certain tasks. The upside is that the way forward is often clear. I seldom experience decision paralysis in Lua. Unlike other minimalistic programming languages though, Lua is designed such that what’s there is as powerful as possible. Lua’s table type can be applied well to just about any problem space imaginable, and prototype solutions written without needing to write hundreds of lines of prerequisite code to build up specific data structures out of mathematically sound but impractical building blocks.

Minimal programming languages are often rightly derided as Turing tarpits, where it is technically possible to write any possible program it is often painfully difficult to do so. Lua on the other hand makes nearly every other language feel like a Turing tarpit. If the goal is to get something working quickly, I might be able to do better than Lua, but because my goal is to get things working in a way that I can come back to later, that’s a different story. I can’t create new syntactic constructs in Lua, the language doesn’t support macros, and the few control structures that are there are pretty simple. Where Lua is odd, such as 1-based indexing or in lacking increment and decrement operations, there are usually very good reasons for that which reveal themselves in time.

Discovering Lua and giving myself the opportunity to really grasp it as a tool has changed the way I approach software development for the better. Never before had finished software felt so achievable to me.

I Needed The Right Habits

I learned that one of the easiest ways to frustrate myself when writing software is to split the codebase into multiple files much too quickly. It’s better to have a few files that are a couple thousand lines each than a dozen files that are a few hundred lines each. My mind naturally remembers the “shape” (for lack of a better term) of the code I’m writing and large files each tend to have a unique shape while smaller ones have yet to take on their own distinct shape. On top of that, a lot of code in a project exists often only to cope with the project’s own file structure. Splitting up files proactively often only serves to overcomplicate a project for little gain. Personally, it’s easier for me to navigate to different sections of a file instead of navigating to different files, but I know I’m an outlier.

I have also started to take a “fast results” approach to writing code. Often in the past I’d spend hours writing code to make an entire polished finished project out of an idea. This was born from knowledge that code would often need to be thrown away, and that such time was wasted or would even make more work for future-me. While I still believe these things, I understand that it’s important for my own ability to focus on a problem to be able to quickly begin achieving results. That means quick prototypes so I can validate my own assumptions, and then taking time later to do it right. I suspect my prior habits were formed due to bad experiences in professional development. Often, protoype code would make it to production with zero polish and little regard for how it would fit into a codebase’s overall structure, and this would often cause problems later as predictable and expensive bugs would surface. More time would be spent fixing obvious problems than would have taken to get things right in the first place. However, I find when working on a solo project that the iterative process is much more suitable to me. This is in part because my own unpolished code isn’t being pushed to production—often I am the only person to use that code, let alone see it—and having half-baked code is helpful while the overall structure of a project is revealing itself to me. It’s sometimes impossible to make high-level structural decisions ahead of time when what you’re writing is so new to you.

Perhaps my lesson is that I’m bad at engineering software. I accept this answer, but I think the truth is more nuanced. Software is hard, writing code is hard, and not having definitive answers is very much how this task works. At least when working solo I have the space to make these decisions myself specifically for myself without any external pressures.

I Needed the Right Scope

Finally, the points I’ve made in this article all coalesce into one: I needed to scale down and aim to write smaller applications.

The GNOME desktop specializes in small unitasker applications that only do one thing, with minimal variance in configuration—if there’s any configuration at all. Lua is a small language implemented in about 20,000 lines of C code. My brain already puts a hard limit on complexity, but newfound codebase organization habits made it difficult to create behemoth projects.

Small, practical apps tick all of my boxes. I can iterate quickly, don’t get bogged down by my own mess, can see the results of my work, don’t need to spend a lot of time fiddling, insert my weirdo opinions, and actually finish a project. Getting there was a long process, but I’m glad I never relented—even if I can’t.

Limited scope means I will probably never successfully get to do the game development I am so passionate about, and while I will never stop trying I am glad I’ve at least gotten to do something concrete with these skills.

It is in retrospect sort of amazing that, after pivoting to a mindset that cared more for consistent effort than achieving any outputs, my outputs began to grow from “nonexistent” to “modest”. Aiming for big goals when your brain can hardly work on more than 3 small goals at a time is a recipe for disaster. At the same time, focusing more on doing work with the explicit goal of enjoying myself has been tremendously helpful in finding interesting things to make. My apps are all pretty basic, and all but one are focused more on delivering a different version of things which already exist. I did write an interesting mod for a 20-year-old video game, but it’s one which will likely never have more than a couple hundred players due to its niche. Then again, if I cared about popularity or reach I would not choose to embrace being an eclectic Linux weirdo who hates AI.

My point is this: If you struggle to get things done, to put your hard-won talents to good use, to finish your ambitious projects, then the solution is to disregard the idea of producing an end product and insted embrace the idea of doing what your brain tells you to do. Take it moment to moment, and you will eventually find opportunities to share interesting things with the world. It worked for me—perhaps it’ll work for you, if you share some of my struggles.