Whyday August 19

Fifty Constraints to Pick From

Pick one before you start. Write it down. Do not negotiate with it until you have hit the wall at least once. If you want the argument for why any of this works, it is here.

The list is sorted by what each constraint does to the work, because that is the useful axis. A limit that removes decisions behaves very differently from one that forces a strange approach, and you want to know which kind of evening you are signing up for.

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

Constraints that remove decisions

These are the ones to choose if your problem is that projects grow while you look at them. They work by making a whole category of choice impossible.

  1. Under four kilobytes of source — the original suggestion
  2. Under one hundred lines
  3. One file, no imports of your own code
  4. Standard library only, no dependencies
  5. No configuration of any kind — every value hardcoded
  6. No command-line options
  7. No error handling beyond crashing
  8. One input, one output, no interactivity
  9. No persistence — everything lives in memory and dies
  10. No installation: it must run from a single copied-and-pasted command

Constraints on time

Different mechanism. These cap the project regardless of what the project is, which makes them the safest choice when you have no idea what you are about to build.

  1. Two hours, alarm set
  2. One hour
  3. Twenty minutes, then twenty more only if it is working
  4. Until a specific record finishes playing
  5. Stop at a fixed clock time regardless of state
  6. One session, no saving — if you close the editor it is over
  7. Ship at 90 percent, whatever 90 percent means at that moment

Constraints on the tools

These change how the work feels rather than how big it gets.

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

  1. A language you have never used
  2. A language you have not touched in five years
  3. No autocomplete
  4. No syntax highlighting
  5. No internet after the first ten minutes
  6. Write it on paper first, in full, then type it in
  7. No mouse
  8. Only the terminal — no editor, just cat and a heredoc
  9. Someone else's editor configuration
  10. No version control, so nothing can be undone

Constraints on the shape of the code

The strange ones. These are less productive and more likely to teach you something you did not know about the language.

  1. No if, no ternaries, no pattern matching on conditions
  2. No loops — recursion or nothing
  3. No variables, only function arguments
  4. No functions longer than three lines
  5. Every function must be pure
  6. No mutable state at all
  7. Everything must be one expression
  8. No names longer than four characters
  9. All names must come from one book, chosen in advance

Constraints on the output

These decide what the thing is before you decide how it works, which is often the right order.

  1. It must fit on one terminal screen without scrolling
  2. It must make a sound
  3. It must produce something printable
  4. It must be a single HTML file that works offline
  5. It must be explicable to a child in one sentence
  6. It must run on a machine older than ten years
  7. It must work with no colour
  8. It must be readable by a screen reader
  9. The entire interface is one button

Constraints that involve other people

The hardest to arrange and the most reliable at producing something surprising.

  1. Ask a friend for a number before you start and use it as your byte limit
  2. Ask a friend for the topic and do not argue
  3. Swap constraints with someone at the halfway mark
  4. Build it to be handed to one specific named person
  5. Two people, one keyboard, ten-minute turns

How to choose

If you always run out of time, take one from the first two groups. Removing decisions is what you need, not novelty.

If you always build the same kind of thing, take one from the tools or shape groups. Discomfort is the point; the output will be worse and the evening more interesting.

If you cannot decide what to make at all, take one from the output group. Deciding the shape first is a legitimate way in, and often faster than deciding the idea first — though if the problem is that you have too many ideas rather than none, sort them out first, and if you have none at all, start from a list of things to make.

If you are running the day with colleagues, draw one shared limit by lottery — that is the single best structural addition to a team Whyday.

If it is your first Whyday, take number 11. Two hours with an alarm is the most forgiving constraint on this list and it teaches you what your actual pace is, which is the information you need for next year.

The one rule

Pick before you start. A constraint chosen halfway through is always one you have already met, which makes it a description rather than a limit. Thirty seconds of choosing beforehand does more for the evening than an hour of good intentions during it.

The short version