Whyday August 19

Twelve Things to Make in One Evening

You have one evening. That is the whole premise of Whyday, and it is also its main constraint. Nothing on this list needs a weekend, a co-founder, or a plan. Each one is sized for the hours between dinner and going to bed, and each one is finished when you stop.

Pick one. Do not pick three. If what you have is a two-hour gap rather than a whole evening, the shape changes.

For teams trying a short creative session inside a normal workday, books about time management is one practical reference for keeping the experiment distinct from routine delivery.

1. A program that draws something you can print

Write something that produces an image and nothing else. A generative pattern, a plotted curve, a page of your own handwriting turned into a repeating tile. Print it. The point of printing is that it forces you to finish: a file can stay half-done forever, a sheet of paper cannot.

2. A tool that solves a problem only you have

Everyone has one. The rename you do by hand every week, the three commands you always run in sequence, the file format nobody else uses. Spend the evening making the annoying thing take one keystroke. This is the single most reliably satisfying project on the list, because you will actually use the result tomorrow.

3. A program in exactly one file

No dependencies you did not already have. No build step. No directory structure. This is the four-kilobyte argument in its gentlest form. One file that you can send to someone as an attachment and they can run. The discipline of a single file changes how you write — you stop making abstractions you do not need, because there is nowhere to put them.

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

4. A thing that makes noise

Sound is the most underused output in programming. Generate a tone, sonify a dataset, make a drum machine with four buttons, turn your git log into a melody where the pitch is the number of lines changed. It will sound bad. That is fine, and it is also funny, which is the point.

5. A rewrite of something you use, deliberately worse

Take a tool you rely on and reimplement the smallest useful part of it badly. A markup DSL is close to ideal for this. A grep that only handles literal strings. A template engine with one feature. A key-value store that loses data on restart. You will learn more about the real thing in three hours of this than in a week of reading its source.

6. A page with no JavaScript

One HTML file, hand-written, styled by hand, that does something genuinely useful. A converter, a reference table, a calculator built out of nothing but form elements and CSS. See how far the platform goes before you reach for a framework. It goes much further than most people assume.

7. A bot that does one dumb thing

Not a useful bot. A bot that posts the current phase of the moon. A bot that replies to you with the same message you sent, delayed by a week. A script that emails you a random line from a book you have already read. Choose something with no business case whatsoever.

8. A game with one rule

Not a game engine. A game. One mechanic, one screen, one way to lose. Snake is one rule. So is a text adventure with three rooms. If you find yourself writing a menu system, you have already lost the evening.

9. Documentation for something undocumented

Find a small library you use that has a bad README, and write a good one. This is the least glamorous item here and probably the most valuable to other people. It also counts, because it is making something, and because making things clear is a craft.

10. A visualisation of your own data

Your shell history. Your commit times. The dates of every photo on your phone. Your music listening for the year. You already have the data, so the whole evening goes into the interesting part, which is deciding what shape it should take.

11. Something in a language you do not know

Not learning the language — using it. Pick one, find its hello-world, and get to something that prints a result within three hours. You will write terrible code. You will also find out what the language actually feels like, which no tutorial conveys.

12. Finish something you abandoned

Open the directory you have not touched in two years — and if you have several, work out which one is actually the right one before you open the editor. Do not restart it. Do not refactor it. Get it to the smallest state where you could show it to one person, and then stop. Abandoned projects are usually abandoned at ninety percent, and the last ten percent is often an evening's work.

How to actually get through the evening

Decide before you sit down. The most common way to lose a Whyday is to spend the whole evening choosing. Pick in the morning, on the way home, in the shower. By the time you open the editor, the decision should be behind you.

Set an end time, not a scope. Say "I stop at eleven," not "I stop when it works." The second one has no floor. If you want the limit to do more of the work for you, take one of fifty constraints instead.

Do not set up. No new framework, no fresh dotfiles, no dev container. Use whatever is already installed. Setup is how an evening disappears.

Let it be bad. This is the one day of the year where nobody is going to review it, deploy it, or maintain it. If you catch yourself writing tests for the fun of it, that is fine — writing tests for the fun of it is also playing. If you are writing them because you feel you must, that is the feeling to put away today.

Tell one person. Not a launch, not a post. One message to one friend saying: I made this stupid thing. That is enough to make it real, and it is what keeps the day going. If there is nobody to tell, there are substitutes, and the bar for "finished" is lower than you think. Where to put it matters less than that you put it somewhere.

The short version