What People Actually Mean When They Say Impossible Things Before Breakfast
It is a mental exercise, not a productivity hack, and most people write about it wrong. The concept comes from the Lewis Carroll line in Through the Looking-Glass where the Queen tells Alice she must believe six impossible things before breakfast. In practical application, it has been adopted by several communities—creatives, engineers, puzzle designers—as a way to force your brain out of its standard pattern-matching loops. I started using it around 2017 when I was stuck on a design problem for months. Not stuck in a dramatic way, just going through the motions. Someone in a thread I was reading mentioned trying one "impossible" constraint every morning for two weeks, so I tried it. I wrote down three things that should not be possible in my current project and forced myself to find a technical path to each one. Two of them turned into working features. The third one exposed a fundamental assumption I had been carrying that was actually breaking something else in production.
How to Actually Do Impossible Things Before Breakfast
The method is straightforward but easy to mess up. Here is the mechanics. Each morning, before you start your actual work, write down three constraints or problems that seem impossible given your current tools, time, or knowledge. They need to be genuinely difficult, not just hard. "I want to reduce page load time" is not impossible. "I want a single HTML file under 50 kilobytes that renders a full interactive 3D simulation without any external libraries" is closer to the right category. Then spend fifteen to twenty minutes trying to solve at least one of them. Do not look anything up. Do not search for existing solutions. Push your own reasoning until it hits a wall. The wall is where the useful thinking happens. Most people stop too early because they get uncomfortable around the feeling of not knowing. That discomfort is the point.
I once spent three weeks on a constraint that asked me to design a database query that could sort a result set by relevance without using ORDER BY at all. I ended up building a custom bucket-sort algorithm in application code that was slower than a poorly indexed query but taught me more about how databases actually work than anything I had learned in formal training. The final solution was never used in production. It was still worth it.
Get the Full Details
The Common Pitfalls
Most people pick problems that are impossible for the wrong reason. They pick something that is impossible because of scale or budget, not because of a gap in their understanding. Those are not useful exercises. You want constraints that are impossible because your current mental model is incomplete. Another trap is treating this as a daily quota system. You do not need to solve the impossible thing. You need to work against it. The act of pressing against an impossibility reveals where your assumptions are weak. A week of this is worth more than a month of just writing down constraints and moving on. I saw someone online claim that doing this exercise for six months made them a senior engineer. That is not how it works. It makes you slightly less confidently wrong about things you thought you understood. The value is incremental and uneven. Some mornings you will make progress. Most mornings you will not. Both outcomes are normal.
Where It Fails
This approach does not work well if you are already in survival mode at work. If you are burning through tickets and the backlog is eating your evenings, adding a morning exercise is just another thing you will fail at and feel guilty about. Use it when you have a small window of mental space, not as a replacement for rest or actual paid work. It also does not work if you pick constraints that are purely dependent on external factors you cannot control. "I want to ship a product in two days with zero testing" is not an interesting impossibility. It is just negligence dressed up as a challenge. The constraint needs to be technically or conceptually impossible, not organizationally impossible. The exercise has diminishing returns if you keep picking problems in the same domain. I noticed my gains stalled after about four months because I was always solving variations of the same type of problem. I started rotating domains—sometimes I would work on a math puzzle, sometimes a UX contradiction, sometimes a hardware limitation. That kept the exercise useful.
Impossible Things Before Breakfast as a Long-Term Practice
If you stick with this beyond the novelty phase, the benefit shifts. Early on, you are just practicing uncomfortable thinking. After a year or so, you start noticing patterns in the kinds of impossibilities you keep running into. Those patterns tell you where your blind spots are. I found that I kept picking constraints related to data consistency, which meant I did not actually understand distributed systems as well as I thought. I went back and studied it properly after that realization. There is no official curriculum or framework around this. It is a personal discipline, not a methodology with certification. The closest documented versions I have seen are in puzzle design communities and a few engineering newsletters that mention it in passing. Most people who do this seriously just keep a notes app open and document the constraints they tried and where they got stuck. The notes become useful over time. When you hit a real problem at work that feels impossible, you can flip back and see if you have ever encountered a similar shape before. I have had at least four instances where a constraint I wrestled with months earlier turned out to be structurally identical to a production bug. I knew how to approach it because I had already failed at it in a low-stakes environment.
