Finding the Joy in Small Software

I have been coding since the 1980s. Before software became my work, it inspired wonder.

I could sit down at a computer with a question and, through some combination of curiosity, experimentation, and stubbornness, make it do something new. The program did not have to be important. It did not need users or a business model. Making it work was enough.

There was joy in that.

I never stopped caring about software, but over the years the act of building it accumulated more layers. Planning, coordination, deadlines, roadmaps, stakeholders, platforms, and process all exist for good reasons. They are part of building software with other people and at a meaningful scale.

Those layers can also create distance between an idea and the pleasure of making it real.

Recently, building small software helped me close that distance again.

I wanted it, so I made it

I built C2K because I wanted a straightforward running app that did not require an account, show ads, collect data, or sell me a subscription. I looked for one and did not find what I wanted.

I made it.

That sentence captures something I had missed. I had a real problem. I wrote code. Now I have a tool that solves it.

There was no business case to prepare. I did not need to estimate the market or decide how the app would make money. I did not need a growth strategy. I could make technical choices because they were right for the tool and the people using it, not because they improved a metric.

The feedback loop was direct again. Every working screen, audible prompt, and completed workout made the idea more real. I could use what I had built, notice what was wrong, and make it better.

That was fun.

The joy of the hacker mindset

I mean "hacker" in its original, constructive sense: someone who is curious about how things work, willing to open them up, learn from them, and make them do something new.

The hacker mindset does not begin with a product plan. It begins with questions:

• Can I make this?
• Can I understand how it works?
• Can I make it simpler?
• What happens if I try this?

Those questions give you permission to explore. You do not need to know the answer before you begin. The point is to find out.

That spirit shaped what made programming exciting to me in the first place. Code was a medium for thinking and discovery. The computer gave immediate, honest feedback. Something worked or it did not. Either result taught you what to try next.

After decades of writing software, becoming a beginner again feels refreshing. A small project creates room to follow an interesting question simply because I want to understand it. It lets me learn without needing to justify the learning as a return on investment.

It lets me be a hacker again.

Small enough to enjoy

The Unix philosophy has always valued small tools, clear boundaries, and programs that do one thing well. People often discuss those ideas as good software design. They also help preserve the joy of building.

C2K is an Android app, not a Unix command-line tool, but the same restraint applies. It guides a runner through a Couch to 5K or Couch to 10K program. It keeps time, gives prompts, records progress, and optionally tracks distance.

It does not need to become a fitness platform. It does not need a social network, coaching marketplace, account system, or cloud service. It can be complete without becoming large.

That matters because every feature changes the relationship with the project. Each one demands design, testing, explanation, translation, support, and maintenance. Enough additions can turn a small source of joy into another system of obligations.

Doing one thing well is not a lack of ambition. It protects what made the project worth building.

Sharing without chasing scale

Part of the hacker tradition is scratching your own itch and then sharing what you made.

Open sourcing C2K completed that loop for me. The app began with my own need, but other people had the same need. They reported bugs, suggested improvements, contributed translations, and helped make it better.

Those connections have been more meaningful than a download count. Someone cared enough about a small thing I made to use it, improve it, or tell me how it helped them. That is software operating at a human scale.

The internet makes numbers unusually visible. Stars, downloads, followers, revenue, and growth can make a project feel insignificant when it does not reach a large audience. But reach is only one kind of impact.

If a tool helps one person start running, saves someone a frustrating hour, or gives another hacker something useful to learn from, that matters. The work does not become less real because it cannot fill a growth chart.

Sharing can be an act of generosity without becoming a demand for scale.

Finding the joy again

Small software is not effortless. Platforms change. Dependencies need updates. People find bugs I never saw. Publishing creates responsibilities even when it creates no revenue.

The difference is that I can keep the promise small. I can support the core purpose, be honest about what I can maintain, welcome help, and resist expanding the project beyond my interest in it.

Most importantly, I can finish something.

Making a tool that is understandable, useful, and complete brings a particular satisfaction. It does not have to be the foundation of a company or the first step in a larger plan. It can simply exist because I wanted it to exist and enjoyed making it real.

That feels like the software I remember from the 1980s. Not because the technology was better or the work was easier, but because making the computer do something useful was itself a reward.

After all these years, the joy was still there. I just needed a small enough project to find it again.

• ← Previous
  Totally: I'd Ship It This Way Again