Whyday August 19

What Counts as Finished

The day has no goals, no judging and no deliverable, which creates an odd problem: there is no way to tell whether it went well.

That sounds like it should not matter. It matters more than you would expect, because the memory of how the evening ended is what determines whether you do it again next year — and an evening that trails off into nothing at half past midnight leaves a bad taste that has nothing to do with what you built.

For teams trying a short creative session inside a normal workday, productivity vs. efficiency is one practical reference for keeping the experiment distinct from routine delivery.

So it is worth having a definition of finished. Not a standard. A definition.

The working definition

It is finished when you can show it to one person and say what it is.

That is the whole test, and it is deliberately low. It does not require the thing to work reliably, to handle errors, to be installable, or to be good. It requires two things: that it exists in a state where another human can perceive it, and that you can describe it in a sentence.

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

Everything below is about why that particular bar and not a higher or lower one.

Why not "when it works"

Because "works" has no floor. There is always a case it does not handle, and the case is always findable, and looking for it is the most reliable way to turn a two-hour project into a six-hour one that ends in irritation.

More importantly, "works" is the production standard, and importing the production standard is exactly the reflex the day exists to interrupt. Tonight's thing does not need to work. It needs to have happened.

Why not "when I stop"

Because stopping and finishing are different, and the difference is entirely in the last twenty minutes.

An evening that ends when you get tired leaves a directory. An evening that ends with twenty minutes of naming the thing, writing three sentences about it, and taking a screenshot leaves an object. Same code, completely different memory of the night.

This is the single highest-return advice on the whole site and it is also the most ignored, because those twenty minutes feel like admin while the coding felt like the point. They are not admin. They are the difference between having made something and having spent an evening.

The four states an evening can end in

Made a thing. It exists, it does something, you can show it. Finished. This is the common case and it needs no further comment.

Made a broken thing. It exists, it half does something, you can show it and explain the part that does not work. Also finished. Broken is a state a thing can be in; it is not a failure to have made one. Show it broken.

Made nothing, learned something. You spent four hours discovering that the approach does not work, or that the library is not what you thought, or that the idea was less interesting than it looked. This is a real outcome and it is the one people are hardest on themselves about. Write down what you found out — one paragraph — and it becomes an object like any other. Negative results are results.

Made nothing, learned nothing, felt bad. This is the only actual failure, and it has causes. Almost always: no decision made before starting, or a project that needed infrastructure, or a new tool installed at the beginning. All three are avoidable and all three are covered elsewhere on this site. Note which one it was and fix it next year.

The show-it part is not optional

Not publishing. Not a launch. One message to one person: I made this stupid thing tonight, look.

Three reasons this is load-bearing.

It forces you to describe the thing, and describing it forces you to decide what it is, which is often the moment you understand what you made.

It creates an ending. Projects without endings do not feel finished no matter how complete they are.

And it is the only mechanism by which any of this compounds. The 2010 text asked people to celebrate together, on the same day, for exactly this reason — a day where everybody separately builds something and tells nobody is a day that quietly stops happening after two years.

When to abandon rather than finish

Sometimes the right call is to stop at nine o'clock and do something else entirely.

The signal is not difficulty. Difficulty is normal and often the good part. The signal is when you notice you are working rather than playing — when you are pushing through because you said you would, not because you want to see what happens next.

That feeling is the exact thing the day is meant to be a holiday from. Honouring it by grinding on is a category error. Close the editor, pick something smaller, and start again with ninety minutes left. A small finished thing at eleven beats a large unfinished one at one in the morning, every time.

And then leave it alone

The default fate of a Whyday project is that it is never touched again. That is not waste and it does not need justifying. It was an evening, it produced a thing, the thing exists.

If in three weeks you find yourself thinking about it, that is information — it may have been a real project wearing an evening's clothes. But do not go looking for that. Looking for it is how the day acquires a purpose, and a day with a purpose is not this day.

The short version