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.