Cutting Out the Middle (Wo)Men

SandwichBoard man Our first two customers are South Street Steaks and Aqui Brazilian Coffee respectively. As you can see, the sites will eventually need new designs; however, both establishments helped us develop a solid system, have been great beta-testers, and most importantly, they love SandwichBoard.

Today I walked Carminha Simmons of Aqui through SandwichBoard. She added a news article, event, and web page herself during the training. While she used the system, I took notes on anything she didn’t understand, things she got stuck on, and features that broke. When I got back to my home office in the afternoon, I went through my list and fixed the majority of the issues or UI flaws I saw before dinner.

I had direct contact with the customer and saw her every mouse click and facial expression. I was able to discuss with her how to fix things she didn’t understand. I didn’t have to go through a committee or get permission to fix what we thought was broken. All we have to do now is run a command to update our system live in a matter of minutes. Try doing that when working in an organization divided into job functions and heavy processes.

A Demonstration to Remember

A went to Ruby East a little over a week ago with Patrick. We heard several good talks about Ruby and Rails and thought the conference was well-worth the money we spent to attend it. The most valuable presentation for me really wasn’t a presentation at all; it was a demonstration.

Giles Bowkett didn’t put us through an hour of slides. Instead, he spent the time walking us through and demonstrating his .irbrc–his Rails debugging tool set. For those unfamiliar with or new to Rails, Rails has an interactive Ruby shell console called script/console where you can execute arbitrary lines of Ruby code to debug Rails applications. Each time the console is launched, initial settings and functions are defined by one’s .irbrc. His contained many useful tools and hacks, the details of which I will leave to the reader to discover. I just wanted to publish something referencing it since it is so good.

(You can read Giles’s thoughts on his own talk too.)

Self-Inflicted Punishment

I will not reinvent the wheel. I will not reinvent the wheel. I will not reinvent the wheel. I will not reinvent the wheel…

Yesterday I wasted nearly five hours trying to implement something someone else had already coded. This isn’t the first time I have tried developing something from scratch without first checking to see what others have done to solve the exact same problem. I need to break this habit.

…I will not reinvent the wheel. I will not reinvent the wheel. I will not reinvent the wheel. I will not reinvent the wheel. I will not reinvent the wheel. I will not reinvent the wheel…

Day Three

A few days ago I left my day job to take a serious stab at a startup with Patrick Joyce.

Day one: Patrick helped me get up-to-speed on Mac OS X; we defined our tasks for the week; we looked at the problem domain and designed the core of our web app; and we set up our Rails development instance.

Day two: we developed with Patrick in the driver’s seat and me in the passenger’s. I played back-seat-driver by helping to make design decisions, catching typos and logic bugs, and learning from the driver.

Day three: we developed with me in the driver’s seat and Patrick in the passenger’s. Patrick played back-seat-driver.

Affirmations

Having two, complementary co-founders makes for good, quick, and concrete decisions. Good, quick, and concrete decisions lead to appropriate and quick actions.
Mac OS X, Rails, and TextMate make web development super-efficient.
Pair programming results in the development of correct, readable, and maintainable code.
Working a reasonable amount of hours, remembering to eat healthy food, and sleeping well keeps you sharp.