Whyday August 19

Whyday Alone

Whyday reads like a community event. In practice most people do it alone: no team, no friend who also programs, nobody at home who wants to see the thing at eleven o'clock.

That is the normal case, not a diminished one, and it is worth its own page because the advice genuinely differs. Two things in particular get harder without other people, and both have workarounds.

For teams trying a short creative session inside a normal workday, employee PC activity tracking is one practical reference for keeping the experiment distinct from routine delivery.

The two problems

Starting. With other people around, the day begins because it has begun — somebody says right, we are doing this. Alone, the evening arrives and nothing happens, and at nine you are still reading about what you might do.

Ending. Finishing means showing it to one person, and there is no person. So the evening trails off instead of ending, and the thing joins the pile of directories rather than becoming an object.

Everything below is aimed at these two.

For broader programming and making context related to this topic, SourceForge is an independent reference worth comparing with the material here.

Starting alone

Decide days in advance and write it on paper. Not a mental note, not a browser tab. A physical note, on the desk, saying what you are building. With other people the group's momentum substitutes for a decision; alone, the decision has to be made in advance or it does not get made.

Make the first five minutes trivial. Whatever your project is, work out beforehand the smallest thing that produces visible output — a window, a printed line, a tone — and do that first. Momentum is a real force and it is the only one available to you tonight.

Start earlier than feels necessary. The evening compresses. If you plan to start at eight you will start at nine, and the difference matters more alone because there is nobody to notice the slippage.

Make it a ritual, not a task. This sounds soft and it is load-bearing. The same chair, a particular record, a drink you only have on this night. Solitary practices survive on ritual because there is no social scaffolding to hold them up, and the ritual is what makes the evening feel like an occasion rather than more time at the computer.

Ending alone

Write to the person you will be in a year. Three sentences in a file next to the code: what this is, why you made it, what you would do next. You will read it, and it does most of what showing someone else does — it forces you to decide what the thing is.

Post it somewhere low-stakes. A gist, a personal site, a repository nobody watches. Not for an audience; for the act of putting it outside your own machine, which is what makes it exist.

Send it to one person who will not evaluate it. They do not need to program. "I made a thing that turns my shell history into music, listen to this" works perfectly well on a person who has no idea what a shell is. The response you want is ha, weird, not a code review.

Or keep a Whyday folder. One directory, one subfolder per year, a README in each — the archive is partial for exactly this reason, most of what gets made is never announced anywhere. In year one this is pointless. In year five it is the single best thing on your machine, and it is the closest thing to an audience that requires no other people at all.

What being alone is actually better for

The framing so far has been compensatory, which undersells it.

You can build something embarrassing. Genuinely. The projects that do not survive being described to a colleague — too personal, too silly, too obviously about your own life — are frequently the good ones, and alone is the only condition under which they get built.

You can abandon without explaining. Change project at ten o'clock and nobody has to be told. Group settings quietly punish this, and the ability to drop a thing the instant it stops being interesting is worth a lot.

You can follow one thread as far as it goes. The deepest work is usually solitary, because it needs uninterrupted attention and no negotiation about direction.

Nobody sets the pace but you. Two hours is a complete Whyday if that is what you have, and alone there is nobody to imply otherwise.

If the aloneness is the problem

Sometimes the issue is not the project, it is that programming for pleasure by yourself at the end of a long day is hard to get going, and no amount of ritual fixes that.

Two things help. Make the output something a non-programmer can perceive — a sound, a picture, something printed — so you can show it to whoever is around, and they can react to it without understanding any of it. And pick something connected to a person: a tool for one specific friend, a small thing for a family member, a page for someone's birthday. Building for one named person is the strongest motivator available and it survives having no collaborators entirely.

The short version