> As a side note, I would not recommend this practice for writing code.

Oh, I do! I mean not all the time, but if I have a particularly hard problem I'm working on, pencil and paper and coffee in the morning help me work it out. You're not going to write out pages and pages of code, obviously. But there's just something about scratching out the algorithm or sketching a design freehand on paper that helps my thinking process.

Bonus: I don't tend to need to rely on IDEs writing code for me. And Whiteboards don't scare me in the least.

I do that sometimes, too. Sometimes it works better if I do it somewhere other than my desk. I can go outside with a notepad, sit on the lawn, look at the clouds, and work out an algorithm.

I'm curious to know why this process wouldn't work well for code?

Some of the best code I've written has also been in an exhausted/ not-fully-awake state

Because to me designing a piece of software is the analytical work: making estimates, picking candidates for data structures and algorithms, doing back-of-the-envelope calculations, considering trade-offs, maybe making a little prototype in a toy language.

The coding proper can be done in a less vigilant state: it is like laying bricks or folding napkins. The hands know what they are doing. (Exaggerating here, but not too much. God knows I have coded tired or drunk or stoned, and not even my worst work.)

I generally agree that coding can take a lot more planning than writing and the more experienced I get, the more I plan. I also like to occasionally run with the "write one to throw away" method, which is very much like splitting between writing and editing. It's just that the second version is less editing of the original text and more editing the original approach / methodology / process.

I so wish I could code stoned. I've never been able to in any meaningful way. I don't code inebriated anymore, but in my twenties it was preferred. These days I think my brain basically responds to inebriation of any sort as "why are you still working while I'm trying to enjoy myself?".

One of the most complex pieces of code I have ever written, I wrote while traveling home intoxicated on the midnight train.

It was something I had been considering, analyzing, debating and discarding as impossible for several weeks prior to that. Then when it came down to it, not only was I able to implement it, but it worked perfectly for more than 6 years before anyone was able to improve on that design.

I attribute the success to two things: (a) the fact that I had done a lot of analytical work beforehand; (b) the inhibition-lessening effect of alcohol that allowed me to enter the zone and implement the solution without worrying about complexity or other external factors.

Once the core idea worked - and worked it did! - all that was left was to revisit it the next day, sober this time, and fix the remaining issues, documentation and tests.

i hope you checked the code afterwards. i can't code when i am not fully awake. but somw of the best documentation i once wrote after pulling an all-nighter.

Thank you for the visual write-up. You've named and described something that wasn't even aware of - how I came to develop my best functionalities. Initial work in a half-dreamy state, and clean up later on. Probably more of a holistic, rather than analytical, approach to design.

The secret might have been, all along, wake up late, arrive at work shortly after without doing much in between[1], and start designing already while commuting.

Notably I've been able to achieve a little bit of the same while half-falling asleep, with the added caveat that it requires jotting down good ideas for the next day. And they may be not quite discernible the next day.

Bears repeating - not quite the best code, but certainly the best functionalities.

--

[1] breakfast before work is a productivity killer

A quote often misattributed to Hemingway puts it even simpler: “Write drunk, edit sober.”

“If an important decision is to be made, they [the Persians] discuss the question when they are drunk, and the following day the master of the house where the discussion was held submits their decision for reconsideration when they are sober.”

Herodotus, allegedly

You left out the rest of it: " Conversely, any decision they make when they are sober is reconsidered afterwards when they are drunk." So it's not just that all decisions should be considered sober; it's that they should be considered both sober and drunk.

> You left out the rest of it

Intentionally, yes. I couldn't find a definitive translation that I liked. Here's another take:

"They [the Persians] are accustomed to deliberate on matters of the highest moment when warm with wine; but whatever they in this situation may determine is again proposed to them on the morrow, in their cooler moments, by the person in whose house they had before assembled. If at this time also it meet their approbation, it is executed; otherwise it is rejected. Whatever also they discuss when sober, is always a second time examined after they have been drinking."

I really just wanted to riff on the subject of involving alcohol in decision making.

Breakfast for me is the occasional weekend perk. A lazy luxury. I love it. But not for working days.

It looks somewhat related to the following strategy for making important decisions: start by getting drunk, then make decisions. Then wait enough time to sober up completely and repeat the process. If you reach the same conclusion as when you were drunk, then go ahead.

An idea similar to "write drunk, edit sober".

Funny, that actually is my approach for difficult code projects. I generally just try to hammer something out, even if I have to brute force the result. Then I spend time editing that code down and optimizing it so it isn't a mess and actually works well.

YMMV, I'm a morning person, and I generally do my best coding before 10am.