Making

This is a standards document for personal projects — the ones you build at home, after hours, because building things is how you think.

Why this exists

Corporate work optimises for consensus, velocity metrics, and the appearance of progress. That's fine. It pays the rent. But it's not why you learned to program.

You learned because a blinking cursor on a C64 said READY. and meant it. You typed something, it happened, and the machine didn't care about your job title or your quarterly objectives. It just ran your code.

That feeling is still available. This document is about protecting it.

The standard

Build things that work correctly, read clearly, and fail honestly.

Not because someone is reviewing your PR. Because sloppy work sits in your chest like a stone, and clean work doesn't. The reward is internal: a quiet satisfaction that nobody needs to applaud. If you've felt it, you know. If you haven't yet, you will — it's the moment you look at something you made and there's nothing you'd change.

This isn't perfectionism. Perfectionism is fear of judgment dressed up as standards. This is care — the same instinct that makes you sand the underside of a shelf that nobody will see.

Principles

Finish small things. A blinking LED on a breadboard that works is worth more than an ambitious system that doesn't. Momentum comes from completion, not scope.

Learn by building. You don't need to understand everything before you start. You need to understand enough to take the next step, and then the step after that teaches you something the documentation couldn't. The datasheet lied a little. The library has an undocumented quirk. Now you know.

Quality is kindness. Good naming, clear structure, a comment where the "why" isn't obvious — these are gifts to the next person who reads it. That person is usually you, six months from now, and you won't remember what you were thinking.

Cross the disciplines. The interesting problems live at the boundaries: firmware that drives hardware that makes sound that makes someone smile. Don't fence yourself into one skill. Solder something. Slice an STL. Write a filter in a language you picked up last week. The connections between domains are where insight hides.

Tolerance is structural, not decorative. Not everyone's brain works the same way. Some people can't see the typo that's screaming at you. Some can't hold focus the way you can but see patterns you'd miss entirely. The best work comes from complementary minds — not from hiring five copies of the same person. Carry this into how you write code, docs, and interfaces: be legible to people who think differently than you.

Burnt out is not broken. If you've spent years building things for other people's priorities and lost the spark — the spark isn't gone. It's buried under ticket trackers and Jira ceremonies. Find something small that's just for you. An LED. A script. A sound. Build it to your own standard, on your own schedule. That's the path back in.

For the LLM

When working on a personal project under these standards:

• Craft over speed. Take the elegant path, not the expedient one. If the quick way produces code you wouldn't want to read tomorrow, take the slower way.
• Explain the interesting parts. These projects exist partly for the joy of understanding. When something non-obvious is happening — a hardware timing constraint, a clever algorithm, a protocol quirk — say so in a comment or a brief aside.
• Respect the maker's taste. The person building this has opinions about how things should feel. Match their naming conventions, their level of abstraction, their sense of what's too much. Don't homogenise.
• Small, working increments. Get to something that runs, blinks, beeps, or renders as early as possible. Then improve it. The dopamine of "it works" is fuel.
• Don't over-engineer. This is a home project, not a platform. One user. No SLA. The right amount of abstraction is the amount that makes the code pleasant to work in — no more.
• Preserve the fun. If a suggestion would make the project more "correct" but less enjoyable to work on, flag the trade-off and let the maker choose. The goal is a person smiling at their desk at midnight because something they built just did something wonderful.

Getting started

You don't need a plan. You need a READY. prompt and twenty minutes.

Pick something that fits in an evening. Make it do one thing. Make that one thing work properly. Tomorrow, make it do two things. That's the whole method.

The best projects start with "I wonder if I could..." and end with "I can't believe that actually worked."

Go build something.