Sleep Deprivation Experiments

In the course of my studies at Berkeley, I have been able to conduct several of my own sleep deprivation experiments. I collected the most data in Spring of 1994, when I took cs150 and cs184 at the same time. Here is a brief summary of my findings on the different methods of sleep management and deprivation:

8 Hours Every Night

This is the theoretical ideal sleep management technique. Unfortunately, it has been difficult to implement in practice, since I work really slowly on homework. We need to collect more data on this method.

4 Hours Every Night

Although similar to the "8-hour" method, we have much more data on this one. This appears to be the best compromise between theory and practice. It is enough sleep to enable proficient programming, but not necessarily enough to stay awake during 1.5 hour lectures. Common side effects include minor headaches and a decreased energy level.

2 Hours Every Night

This method is often a last resort during "project crunch times". It is sustainable for only short periods of time (2-4 days) before total exhaustion begins. After the first day, programming skills are reduced. Experimental subjects have difficulty reasoning clearly about complex topics. They occasionally nod off while programming, and make mistakes much more frequently. MTBN (mean time between naps) in class is reduced to 15 minutes. Common side effects include prolonged headaches, disorientation, and blurred vision. This method also leaves the subject vulnerable to caffeine addiction.

Sporadic All-Nighters

Rather than spreading the misery out over several days, this method concentrates the misery on a single day, which can be advantageous if the experimental subject has few obligations that day. The effects on the "day after" are similar to the "2-hour" method above (15 minute MTBN). At least six hours of sleep the following night returns the subject to normal status.

The Neverending Day

This method is used only rarely, when project deadlines loom in the near future and projects are far from completed. This method is, by far, the least desirable. Also known by the terms "consecutive all-nighters" and "caffeine tripping", this method involves foregoing sleep until the project is finished. After 36 hours, MTBN falls below 5 minutes, making class attendance a futile effort. Common side effects include spontaneous memory lapses, nervousness, panic attacks, hallucinations, momentary lapses of consciousness, and inability to perform basic logic functions. Our longest experiment lasted 68 hours (cs162 project), which the subject described as "pure and utter hell." Full recovery requires 12-16 hours of sleep. Even then, the subject will feel "jet lag" and disoriented for a day or two afterwards.

The 32-Hour Day

In theory, this method has few drawbacks, especially if the subject has a stretch of 4 days without classes (such as spring break, Thanksgiving, or the week before finals). The subject works 25 hours, sleeps 7, works 25 hours, sleeps 7, works 25, sleeps 7, and then is back on normal schedule. In effect, three 32-hour "virtual days" replace four 24-hour days.

This method has several unique advantages. The subject gets a full night's sleep every "virtual night", and 25-hour stretches are not very strenuous. Additionally, during "crunch time", the subject gets to take advantage of lower computer loads at odd hours. Furthermore, some subjects find it easier to wake up and get out of bed at 4pm and midnight than at the usual 8am, since there tends to be more surrounding activity at those times. After four days, the subject's schedule is back in synch with a 24-hour schedule.

The unforeseen drawback is that the subject's internal clock does not exactly appreciate this sudden alteration of the sleep cycle. Disorientation, momentary lapses of consciousness, and headaches are common. However, analytical capability is not diminished nearly as much as with some other methods, and programming proficiency is diminished only slightly.

The 48-Hour Day

I became acquainted with this method, also known as "sleeping alternate nights", in the summer of 1995. I had moved back home to Belmont, and so my daily commute (by public transportation) was about 3 hours each way. I soon found that I could not afford to spend 6 hours a day on the road; I spent almost as much time commuting as I did programming. To reduce the amount of commuting time, I started pulling 48-hour virtual days. I would go to the computer lab in the morning, pull an all-nighter there, and go home the following evening. Thus I only travelled one way each day, and I cut my commuting time in half.

The obvious advantage of this method is that I was able to put in 30 hours of programming every two days, and still got 10 hours of sleep every other night. The disadvantages included an increase in caffeine dependency, and sleep-deprivation effects towards the latter end of the 30-hour stretches. To compensate, I would often tackle the most challenging problems on the first day, and do less intensive things (such as debugging, test cases, and writing documentation) on the second day.

This approach worked well under the circumstances. The internal clock appreciated the fact that I was going to sleep at the same time every other day. The savings in commuting time more than made up for the lower efficiency due to sleep-deprivation effects.

Disclaimer: In case it wasn't obvious, this page is intended solely for amusement. There were no scientific experiments, I was only speaking about my own experiences of staying up late to finish programming projects. I wrote it in 3rd person as a humor device. -- Lucas

Back to Lucas' writings.
Back to Lucas' homepage.