My Startup Lesson Learned

A few years ago, I quit my job to build a bootstrapped startup called SandwichBoard–a content management system for restaurants. Patrick Joyce and I put $5,000 into the business and made a leap of faith to live off savings and occasional consulting gigs.

After we got the sales routine down, we were growing at a steady pace, but not early or fast enough for our personal lives. We both really wanted to marry our girlfriends. We needed money, and ultimately had to ditch the bootstrapping salaries. I was elated to be marrying the woman I had been waiting for my whole life, but throwing-in the startup towel felt like a huge loss. It was something I had been working towards for a long time, but giving it up to marry my wife was the best decision I ever made.

…

Now that I’ve had time to reflect on what went well and what didn’t, I have my own list of lessons learned–things I would do again or make sure never to go near when building a business or product. But you’ve already seen that sort of list before. Instead of dumping a bunch of do’s and don’ts on people, I would rather leave them with an encouragement–one that will give someone else the courage to take that leap of faith.

My lesson learned: even though the startup plane may come to a fiery end, the pilots have ejection seats.

Our efforts were not wasted. While building SandwichBoard, we became proficient in Ruby on Rails, resulting in a great product and more than two significant open source contributions. This helped land Patrick a position at a company called Hungry Machine and me a job at Razoo. Taking that risk propelled us from working typical IT jobs into the startup world. I’ve had fun just about every day since I took that leap of faith, become a better engineer at an accelerated rate, been able to work with incredible people, and turned that savings loss into a short-term investment.

…

Patrick’s employer renamed itself LivingSocial, and his first major responsibility was to develop a small site called LivingSocial Daily Deals. (Maybe you’ve heard of it.) I rejoined Patrick this July and am leading the technical team responsible for building LivingSocial’s latest local-commerce product: Instant–restaurant takeout and delivery ordering (currently only in Washington, DC). It’s a fitting end to the SandwichBoard story.

Results may vary, but I still think it’s worth a try. Give it a go; jump off that cliff!

strip_attributes, Rails 3, shoulda 2.11 hack

I have never understood why Rails doesn’t strip attributes by default. I know at least one person who tried committing it to core, only to have it rejected. I always end up installing the strip_attributes plugin.

I’m ramping-up a new Rails 3 project, with Shoulda 2.11. I installed strip_attributes. It works, but the strip_attributes Shoulda macros don’t work anymore. I could take the route of upgrading the plugin, but then I would “have to” also refactor the Shoulda macros since macros have been ditched for matchers. Then I’d have to re-write the tests. At that point, I might as well make it a gem and add that feature I’ve always wanted. But, I’m just not ready for that sort of commitment right now (#gtd_maybe_someday).

So, here’s a short line to add to the end of strip_attributes/init.rb to get the old strip_attributes Shoulda macros working again:

require File.expand_path(File.join(File.dirname(__FILE__), 'shoulda_macros', 'macros.rb')) if Rails.env.test?

JavaScript Style Sheets

One of the privileges I have experienced in my professional life is having worked with Jeremy Keith of Clearleft. I learned a lot from the author and web developer from our interactions and by studying his code.

Jeremy is a fan of graceful degradation and ensures that a site will function just fine without JavaScript browser support. However, instead of mingling JS and non-JS styles together, he employs a particularly clever technique. He puts the standard styles in the standard CSS file. But just as his sites provide print and mobile stylesheets for printers and mobile devices, he also provides one for JS-enabled browsers. This has two nice side-effects: (1) better CSS organization and (2) CSS that is applied immediately, not after JS has had an effect on the DOM.

One example is a thumbnails carousel he designed. If the browser does not have JS support, the thumbnails are arranged in a grid. If the client does support JS, he wraps-up the thumbnails in a single row inside a horizontally-scrolling carousel, so they can be browsed left to right. The carousel presentation of the thumbnails requires a different set of CSS rules, which override the vanilla styles.

Here’s how he pulls off the wiring-up of a JavaScript CSS style sheet:

  <script type="text/javascript">document.write('<link rel="stylesheet" href="/stylesheets/javascript.css" media="screen,projection">');</script>

Any site I’m involved in will be following suit.

Thanks, Jeremy!