Why "being more creative" usually doesn't stick
Most creativity advice is about mood: change your route, play ambient music, think outside the box. It feels good, but the effects are small and don't carry over to technical work. In technical fields, the creative-looking solution almost always comes from someone who knows a lot of patterns and recognizes that one of them applies somewhere unexpected.
The honest summary of the research: generic creativity training produces a modest effect (around 0.3 standard deviations once publication bias is corrected). The bigger and more reliable gains come from domain knowledge you can recombine, practising on real problems before reading the answer, generating many ideas alone before judging them, and stepping away from a problem at the right moment. This guide is built around those four.
What creative output actually depends on
Think of it as a product, not a sum. If any one factor is near zero, the total stays low, no matter how strong the others are.
What you can recombine
The tricks, attack primitives, architectures and failure modes you know, written down. You can't connect A to Q if you've never seen Q.
How you transform a problem
A small set of deliberate operators (invert it, change the layer, break an assumption) that push you off the obvious path on purpose.
How many attempts you make
Volume of ideas and volume of problems. Your best ideas tend to show up late in a list, after the obvious ones are out of the way.
When you step away
A planned break after real effort, filled with something easy (a walk, the dishes) or with sleep. Without the effort first, a break is just a break.
The one category that matters most: worked solutions
Read material that shows the reasoning path to a non-obvious solution: write-ups, disclosed reports, post-mortems, competition solutions. Spend roughly 80% of your reading here. The other 20% goes to other fields that are rich in mechanisms, which is where your analogies will come from.
How to read so it actually turns into ideas
1. Try it before you read it
Give the challenge, bug or competition 20–45 minutes on your own first, then read the write-up. Struggling with a problem before seeing the solution leads to deeper learning than reading first (the "productive failure" research).
2. Extract the primitive
Write one card per trick: context → trick → why it worked → where else it could apply. The last field matters most, because it's what makes a fact usable somewhere new. Use the pattern library below.
3. Compare two examples
People rarely transfer an idea from a single example. Once they compare two examples of the same principle, transfer becomes common (Gick & Holyoak). So when you add a card, look for an older card with the same structure and link them.
Twelve operators for getting off the obvious path
These are deliberate transformations you apply to a problem when your first ideas dry up. Run three of them on every hard problem. They come from security research, TRIZ and design practice, and they work across all four domains.
The 90-minute session: run this on any real problem
The order matters: generate first, judge later, step away in the middle. Each step addresses a known failure, such as fixating on the first idea, judging ideas too early, or losing ideas in group discussion.
Frame
5 minWrite the problem in one sentence and define what "solved" looks like. Then list 10 assumptions: what the system trusts, what's "impossible", what everyone does by default.
Diverge alone
10 minAim for 20 ideas and don't judge any of them yet. In a team, everyone writes alone first and you share afterwards (brainwriting). Groups that talk while generating come up with fewer ideas.
Push with moves
15 minPick 3 moves (or roll them in the generator below) and apply each to the problem. Add at least 3 ideas per move.
Incubate
10–20 min (or one night)Go for a walk without your phone, or do the dishes. Keep it low-effort, because a demanding activity cancels the benefit. If the problem is really hard, sleep on it.
Converge
10 minScore each idea on impact, feasibility and surprise, from 1 to 3. Keep one safe and one bold idea.
Cheap test, then log
restFind the smallest experiment that could prove the bold idea wrong, and run it. Then add whatever you learned to your pattern library.
⚑ CTF / bug hunting variant
- Stuck for 45 minutes? Don't keep grinding the same path. Rewrite your assumption list from scratch.
- Change the layer: encoding, parser, cache, auth flow, deployment, client-side code, timing.
- Find a near-miss: search for write-ups of similar challenges and read only their first paragraph to get a hint.
- Chain low-severity bugs. Two "informational" findings combined are often critical.
⚙ Hackathon variant (first 2 hours)
- 0:00–0:15 Read the judging criteria and sponsor APIs. Those are your constraints.
- 0:15–0:30 Everyone writes 10 ideas alone. Don't talk.
- 0:30–0:50 Share the ideas, then apply "combine two" and "add a constraint" to the top 5.
- 0:50–1:10 Take a walk as a team and agree on one demo moment worth remembering.
- 1:10–2:00 Build the riskiest part first. If it doesn't work, switch to the safe idea.
◆ AI / ML variant
- Before touching the model, ask whether this is really a data problem, an evaluation problem, or a problem with how the task is framed.
- Read 50 raw failures before you have any theory about them.
- Make the 0.1× version: the same result with a smaller model, fewer labels or no training at all.
What the research supports, and what it doesn't
The previous version of this site included charts with illustrative numbers. Here the claims are graded against actual studies instead, so you know which levers are worth your time.
| Intervention | Evidence | What we know | How to use it |
|---|---|---|---|
| Generate ideas alone, then share | Strong | People working separately ("nominal groups") produce close to twice as many ideas as groups brainstorming out loud. Most of the loss comes from waiting your turn to speak. The finding has been replicated many times. | Brainwriting in teams and hackathons. |
| Compare ≥2 examples of a principle | Strong (lab) | Transfer from a single example is rare. Comparing two examples produces an abstract schema, and that schema predicts whether people transfer the idea. | Link pattern cards that share the same structure. |
| Attempt before instruction | Moderate–strong | A meta-analysis of 53 studies found that struggling with a problem first and getting instruction afterwards beats instruction-first for conceptual learning (STEM). | Try the CTF or bug before reading the write-up. |
| Incubation breaks | Moderate | A meta-analysis of 117 studies found a reliable but small-to-medium effect (d ≈ 0.29), larger for divergent tasks and after a longer stretch of preparation. An easy activity during the break works better than a hard one or none. | Work hard first, then take a walk or do chores. |
| Sleep | Moderate | After sleep, more than twice as many participants discovered a hidden shortcut in a task (59% vs. roughly 23% of those who stayed awake). | Load the problem in the evening and look at it again in the morning. |
| Walking | Moderate | People generated about 60% more alternative-use ideas while walking than while sitting, and the effect carried over briefly afterwards. It helped divergent thinking only, not convergent or insight tasks. | Walk during the generating phase, then sit down to decide. |
| Moderate constraints | Moderate | A cross-disciplinary review finds an inverted U: too few constraints leave you without direction, and too many cause fixation. | Use "add a constraint" when you face a blank page. |
| Generic creativity training | Modest | About 0.5 standard deviations as published, but only about 0.3 after correcting for strong publication bias. Many of the studies have methodological weaknesses. | Practise in your own domain rather than with abstract exercises. |
| Coffee-shop noise (~70 dB) | Limited | Comes from a single consumer-research paper with five experiments: 70 dB beat 50 dB and 85 dB on creative tasks. Treat it as interesting rather than settled. | Use it if you like it, but don't count on it. |
| Changing your commute route | No direct evidence | Novelty is pleasant, but no study links it to better technical problem-solving. | Optional. It isn't a real lever. |
Practice tools
"Ocean × Clock" style prompts are fun, but they don't train the skill you need. These prompts use real problem types from your domains instead. Everything you enter is saved in this browser only.
Problem × Move × Lens
Apply the move to the problem, then ask how the lens (another field) already solves something with the same structure. Write your ideas in the sprint box.
10-minute idea sprint
Write one idea per line. The goal is 20, and the strange ones count too.
Pattern library: add a card
Add a card for every write-up, post-mortem or solution you study. This becomes your personal store of things to recombine.
Your cards
"Random pair" picks two of your cards. Ask yourself what structure they share, or what they would produce if combined.
No cards yet. Add your first one from the next write-up you read.
A weekly routine (about 4 hours)
The aim is a routine that still works in a busy week, not motivation. Tick items off as you go; the checklist resets every Monday.
This week
First 4 weeks
- Week 1, setup. Pick one main domain. Bookmark 3 sources from the "What to read" tab. Add 5 cards to your pattern library.
- Week 2, attempt-first. Do 3 problems (CTF challenges, Kaggle kernels, incident write-ups) before reading their solutions. Write 3 more cards and link at least one pair.
- Week 3, real problem. Run the full 90-minute protocol on something at work, school or in a side project, and run the cheap test.
- Week 4, compete. Enter one event: a weekend CTF on CTFtime, a Kaggle playground, or a hackathon on Devpost or MLH. Write your own short write-up afterwards.
- Then: keep the weekly routine. Every month, read through all your cards and roll "random pair" five times.
Writing your own write-ups is the step most people skip. Explaining why your solution worked turns a one-off win into a reusable pattern, and it also builds a public portfolio.