How to Sleep Four and 1/2 Hours a Day

Warning: I have revised my thoughts on this subject after reading Pietr Wozniak's excellent breakdown of polyphasic sleep and my own experiences. While my article (this blog post) was not a strong promotion of polyphasic sleep, I thought I would comment that I no longer really agree with cutting out sleep. I think quality sleep is vital to creativity, short- and long-term happiness, and, most importantly, one's health. I am thankful that I had this experience, but would not recommend it to others.

What could you do if you only needed to sleep four hours a day? Assuming you sleep eight hours a day right now, your average day would be 25% longer!

A few summers ago, I tried sleeping 4.5 hours a day while holding a full-time job. Here's what I experienced as the result of doing this.

Preparation

Most people get their sleep in one big chunk, called monophasic sleep. Some get a consistent sleep pattern with two intervals. This biphasic sleep might include slightly shorter nighttime sleep and a siesta during the day. Polyphasic sleepers, on the other hand, split their sleep up into smaller chunks and spread them out throughout the day.

I first found out about polyphasic sleep by reading Steve Pavlina's excellent and detailed series on polyphasic sleep. The idea of getting much greater awake time was compelling to me. Steve used the "uberman" pattern of sleep, which was six naps of twenty minutes stretched in equal parts throughout each day. I researched various polyphasic patterns, and figured out what I thought would be the best pattern based on my schedule. For over a month I tried to stick to the following sleep schedule:

Read on →

Install pandoc from source on Ubuntu

Here are some basic notes on how I installed from source on my Ubuntu x86_64 machine.

Generally followed the build from source instructions.

sudo apt-get install ghc6  # this bootstraps so we can build ghc 7

# get latest ghc
wget http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-src.tar.bz2
tar -jxvf ghc-7.0.3-src.tar.bz2
cd there
./configure
make
sudo make install

# get cabal
wget http://lambda.galois.com/hp-tmp/2011.2.0.1/haskell-platform-2011.2.0.1.tar.gz
tar xvfz haskell-platform-2011.2.0.1.tar.gz
cd there
./configure
make
sudo make install

# get pandoc
# edit ~/.cabal/config to uncomment user-install and set the value to False (so that we get global installation)
sudo cabal install pandoc

pandoc -v

My Lean Startup Machine Boston Experience Report

Lean Startup Machine weekends are a chance to apply the lean startup methodology by trying to build a startup in 48 hours. One of the key goals is demonstrating a process of learning. Learning takes various forms, and might include testing hypotheses through conversations, collecting qualitative and quantitative indicators of interest through surveys, creating MVPs to test acquisition methods and value propositions, getting signed letters of intent to buy a conceptual product, and maybe getting some cold hard cash in hand. Throughout the weekend, teams iterate and pivot as they learn more about their idea and the market through interacting with their customers. A panel of mentors works with the teams when they get stuck, and judge presentations at the end of the weekend to determine a winner.

When I first heard about the LSM in Boston, I signed up. I asked Wes Winham from Indy to join me, and we set off to Boston. This post talks about what I did and saw, and what I learned in the process.

My experience

I had been reading the various resources of the lean startup community for over a year, and was excited to actually put the principles to the test and test out my skills. Doing is a different beast from reading. My personal goal was to work with the team I joined up with to demonstrate that we could work through various difficulties and learn more about the lean startup methodology. I thought whatever team I joined had a chance to win, although it was not my focus.

Our final presentation (PDF, no longer available) gave a good overview of what we ended up doing over the course of the weekend.

The energy and intelligence of the people at this event was a little intimidating at first. There were fifty extremely smart and capable people present. I was a bit out of my element in a city halfway across the nation, but then just started talking with people and things seemed to go well. I enjoyed the networking before the event began. It was clear that everyone was feeling each other out a bit to figure out who they wanted to work with. A weekend is not a huge time commitment, but everyone wanted to have a good experience.

After a round of pitches, everyone cast votes for the different ideas. The top ten idea presenters were chosen as temporary team representatives, and everyone walked around and tried to form into teams. It was a bit chaotic. :)

There were a few ideas and people that seemed most interesting to me, so I walked around for a minute or two getting a sense of the room. I settled on a pitch that was billed as a last minute appointment filler. This could be something that slotted people in for busy service providers, or something that filled up empty slots for not so busy service-providers. It might have been something for service providers, or something more for end users. It seemed open-ended and valuable enough that we could explore some different solutions in the space throughout the course of the weekend. I was excited to work with the team of guys that were interested in the problem as well. It ended up that I was the only "developer" on the team. The rest of the guys billed themselves as "marketers". (LSM also had the distinction of "designer". These roles were pretty open and just served to try to get a range of skillsets at the conference.)

Read on →

Fixing Sporadically Failing Specs

When developing things with a large suite of unit tests or automated specifications, inevitably tests that actually pass fail for some reason. More difficult is the case where the test or spec fails only intermittently. I've taken the approach of late to keep a file around that records when I run into a problematic spec. When I get to five times that the spec failed, it's time to refactor it to be less troublesome.

The first thing I check is to look at the spec and the code it executes and ensure that I think nothing is actually broken. Next, I ensure that the spec is actually adding value. If it's slightly broken and is actually useless, we might as well get rid of it now and not spend more time on it. Generally though, the functionality of a sporadically failing test will be correct, and the spec will add some value.

Read on →