I took the leap. I made the jump. As of almost a month ago I’m no longer an employee. I’m now an entrepreneur! That’s right, I’m now working full time on my startup Geomium. So how did it happen?

Even at University I was making small steps towards it, working on my own interesting tech projects and doing freelance development work. When I started work as a developer for Siemens I kept this up, making sure I continued to read up about new and interesting technologies, and to write about it all for this blog and others.

A great part of working for such a large company was that they had a fantastic graduate development program. I got to go on courses about communication, presentation, and negotiation. There were even team building exercises where we got to go rock climbing and tackle assault courses! The whole time I was thinking “How could I apply these skills to my own business?”, and I got to take a lot from the program. Working for a large company certainly had its downsides though, and after I’d completed much of the graduate course and finished the project I was working on I knew it was time to move on.

The Run Up

I had a brief spell with a smaller company, and although I preferred the smaller company atmosphere I didn’t feel I was learning much. I needed a challenge! That’s when I moved moved to London to join Mendeley, a tech startup, as their second employee and first web developer. Who knew that a couple of years later that Mendeley would have over 40 employees in London and New York, and have won numerous awards?

Getting in early on meant that I really got to make a difference, and was able to play a critical role in making Mendeley what it is today. I found working for a startup so refreshing. Good ideas get worked on right away, there are no forms to fill in, or committees or procedures to get in the way. It requires hard work though. I remember the mad rush to get the first public beta of Mendeley ready, with several of us holed up in the office with vast amounts of Redbull. We ended up getting the first tube of the day home at around 6am, when most people were just getting up for work. Long hours, but lots of fun.

Mendeley not only gave me the chance to work on a large-scale high-traffic website, with all of the technical challenges that entails, but as the company grew I took on the role not only of technical lead, but also web team lead, so I got to learn first hand about managing teams, setting deadlines and targets, interviewing and recruiting people. It was an invaluable experience.

Being based in London also meant I could take advantage of its great tech scene. There are loads of monthly tech events, and annual conferences. I tried to attend as many of these as I could not only to keep up with the latest tech, but also to meet new people and to open myself up to more opportunities. It wasn’t through one of these meetups that I would eventually meet my co-founder though.

The Jump

Around a year ago I was browsing a freelance job site and came across a post from Michael Ferguson. The post sounded really interesting, so I got in touch. We first met at Costa Coffee, and spent at least an hour discussing not only Michael’s ideas for the project, but also about our backgrounds and interests. I think we almost immediately realised we were a good match, with complementary skill sets. By the time we’d finished our coffees we were both excited about moving forward with the project that would eventually become Geomium. At the time I thought it’d just be another interesting side project to work on though, little did I know that 12 months later I’d be leaving Mendeley to pursue it fulltime!

As the project progressed Geomium demanded more and more of my time. Not only on development, but also meetings with potential partners and investors, and going to events to try and get the word out. It was becoming clear that Geomium would soon need my full time commitment. It was at this point that I had to take the leap, and it was a time of mixed emotions. It was hugely exciting, but at the same time I was sad be leaving a company I’d cared so much about and put so much effort into for the previous couple of years. It was also scary to be leaving the relative security of employment, especially as I have a wife and baby to support. Fortunately my wife is hugely supportive, and just as excited about the opportunity as me. I took courage in the words of Tom Preston-Werner:

When I’m old and dying, I plan to look back on my life and say “wow, that was an adventure,” not “wow, I sure felt safe.”

It certainly is going to be an adventure, but with hard work and dedication from Michael and I, and support from our family and friends, I’m sure we can make a success of it. So far things are going well. Geomium recently took third in the TechCrunch summer pitch battle, and we’ve had some good write ups. It’s still early days though, there’s a whole lot still to do. The really hard work starts now!

I’ve been a huge fan of Douglas Crockford and his articles about JavaScript for a long time. I often point people to his The World’s Most Misunderstood Programming Language article when I hear them complaining about the language. It’s taken me a couple of years to get around to reading his book, JavaScript: The Good Parts, but it exceeded all of my expectations.

Being an avid reader of his online stuff, and having watched various talks of his I knew the book would be well written and informative, but I thought it’d probably just repeat much of what I’d already read, without providing much new information or insights. To a certain extent this was true, the book does reiterate what’s said in many of his online articles and talks, but the book is absolutely amazing for a different reason: The code examples.

The book is extremely succinct. There’s no padding, and very little dialog to join one section to the next. There is a common thread thoughout the book though, and that’s the code. Examples of good coding practices are repeated, and functions written in earlier chapters are often reused in later ones. So although the book appears to be presenting one feature at a time with a small code example you’re actually building up more and more complex javascript applications, and the book ends with a full JSON parser!

Crockford’s coding style seems to match his writing style: succinct and to the point. There’s some really great code in the book, that I think even non-JavaScript developers could appreciate. Here’s my favourite, from the chapter on regular expressions:

var parse_url = /^(?:([A-Za-z]+):)?(\/{0,3})([0-9.\-A-Za-z]+)(?::(\d+))?(?:\/([^?#]*))?(?:\?([^#]*))?(?:#(.*))?$/;
var url = 'http://www.ora.com:80/goodparts?q#fragment';
 
var result = parse_url.exec(url);
var names = ['url', 'scheme', 'slash', 'host', 'port', 'path', 'query', 'hash'];
var blanks = '       ';
var i;
for (i = 0; i < names.length; i += 1) {
    document.writeln(names[i] + ':' + blanks.substring(names[i].length), result[i]);
}

Which outputs:

url:    http://www.ora.com:80/goodparts?q#fragment
scheme: http
slash:  //
host:   www.ora.com
port:   80
path:   goodparts
query:  q
hash:   fragment

I also love the explanations Crockford gives as to why he avoids using certain parts of JavaScript, and limits himself to a “good” subset of the language. He doesn’t simply say “This is bad and you shouldn’t use it”, it’s usually accompanied by a story about a time when Crockford had used that feature and got caught out, which is much more compelling.

I think it’s fair to say that JavaScript: The Good Parts is one of my favourite programming books: It’s succinct, packed full of great code examples and best practices for writing maintainable and bug free code. It’s a fantastic JavaScript reference, but much of what the book talks about is relevant to programming in general. Highly recommended!

Last weekend I attended the London Startup Weekend, a 54 hour event hosted at the IBM building on London’s Southbank. It was a fantastic event. I met loads of great people, had a lot of fun, and successfully launched a new website! Arianna, Pedro and Debbie have already written up great summaries of the event, so instead I’ll be focusing on how our team managed to build and launch our project, automatic event management for twitter.

After forming a group most of Friday evening and Saturday morning was spent discussing ideas around the original pitch of twitter calendar integration. We discussed a whole range of ideas including an event broker service, calendar availability widgets, and a twitter/google calendar mashup. It took until lunch time on Saturday to finalise our idea. We’d settled on a a service that would automatically work out the date of an event mentioned in a tweet and keep track of these events. There were now only 36 hours left!

I got straight to work on the code, using Django. I knew we’d need to pull in tweets and then analyse the dates. Using the python-twitter library I wrote a management command to pull in all tweets containing some specific hashtags every minute.

The next stage was to work out a date from the tweets. A Stack Overflow question suggested two options, parsedatetime library, and some pyparsing example code. I tried the parsedatetime library first, and it gave some fairly good results right away. It wasn’t so good at more complicated dates though. I tried the pyparsing example, but unless given just the date string (eg. “Next week” instead of “See you next week”) failed to work out a date at all. I did briefly investigate using the NLTK to extract the date from a tweet, but worried about running out of time I gave up on investigating further and stuck with parsedatetime.

While I’d been busy programming Guillume had come up with a great name for our service: tweevents. He’d then set about registering the domain name, setting up a twitter acccount and facebook fan page. Once we had the name sorted I setup an online logo competition offering $25 to the winner, and an hour later we had our logo.

Gabriel worked hard overnight to produce some HTML/CSS for the site, so on Sunday morning I worked on integrating that into the Django project. We worked on adding features to the website, such as links to add events to your google calendar, hCalendar markup, and the ability to filter events by twitter username, and the rest of the day was spent putting a presentation together.

So tweevents is now up and running. Within 54 hours we’d gone from a rough idea into a working website. The presentation we gave gives some details about what’s next from the business side, but there’s also some things I’d like to get done on the development side. Most importantly improved date parsing. I plan to give the python-dateutil library a try, and failing that go back to look into NLTK in more detail. Guillume’s also working hard on improving the library we’re already using. Should none of the Python options work I’ve also come across some great date parsing libraries for other languges, such as Chronic for Ruby and Datejs for Javascript. A Rails or Node.js rewrite might be on the cards! There are also features that we could add, such as Facebook event creation, or filtering the list of events to just your twitter followers, or people you follow.

A huge thanks to Damien, James and Franck who organised and helped out at the event, and made it all so much fun. Of course, tweevents wouldn’t be much without the rest of the team. Thanks also to my girlfriend, who was left on her own with our 2 month old daughter for the entire weekend!

Back in February I started work on integrating Yahoo’s FireEagle location service into Geomium and I ran into a problems with Python 2.5. Using Steve Marshall’s Python library the included test.py script was working perfectly with Python2.6, but when running with Python2.5 I’d get back an “Invalid OAuth signature error”.

I posted the problem to the OAuth user group but didn’t get any response. I got in touch with Yahoo. After quite a bit of back and forth we finally figured out the problem, which I’m posting here to try and save others from months of frustration!

The Yahoo guys noticed that with Python2.5 the HTTP host header was being sent through as as “fireeagle.yahooapis.com:443″, whereas 2.6 sends “fireeagle.yahooapis.com”. The inclusion of the port results in an invalid OAuth signature, because the signature is generated assuming the port isn’t included. I dug into the Python2.5 httplib code and came across this:

 813    if self.port == HTTP_PORT:
 814        self.putheader('Host', host_enc)
 815    else:
 816        self.putheader('Host', "%s:%s" % (host_enc, self.port))

In Python 2.6 the comparison on line 813 is done with self.default_port instead of HTTP_PORT, which prevents the port from being added with HTTPS requests. I noticed that later on in the code that if you pass in your own host header it prevents one being created for you:

 875     def _send_request(self, method, url, body, headers):
 876         # honour explicitly requested Host: and Accept-Encoding headers
 877         header_names = dict.fromkeys([k.lower() for k in headers])
 878         skips = {}
 879         if 'host' in header_names:
 880             skips['skip_host'] = 1

So the fix turns out to be really simple – explicitly set the http header. That’s exactly what I’ve done in my fork of the fireeagle library (see the fix). I’ve also sent a push request, so hopefully this fix will make it back into the original library. Thanks to Arnab Nandi and Anand S from Yahoo for helping to debug things their end.

37signals are the creators of the popular Ruby on Rails web framework and the people behind successful web applications such as basecamp and campfire. Their previous book Getting Real, about effecitive web application development, really resonated with me.

When I heard that they were writing a new book, ReWork: Change the Way You Work Forever, about “building, running and growing (or not growing) a business” the 37 signals way, I was excited. Especially as it arrived at a time when I’m working on my own startup.

A week has passed since my copy arrived from Amazon, so I’ve had a change to read the book and write up some of my favourite points below.

Planning is guessing

“Working without a plan may seem scary. But blindly following a plan that has no relationship to reality is even scarier”

Don’t make long term plans, or at least don’t obsess over them if you do. I think the key point here is be flexible.

Start making something

“Ideas are cheap and plentiful…the real question is how well you execute.”

Coming up with cool ideas all day won’t get you anywhere. Starting something will. Even if it’s lame, you’ll learn something that’ll make the next attempt better.

Build half a product, not a half-assed product.

“Getting to great starts by chopping out what’s merely good.”

The classic 37 signals do less argument, about less being better, and bloat being bad.

Launch now

“Stop imagining what’s going to work. Find out for real.”

I’m also reminded of the Reid Hoffman principle here:

“If you aren’t embarrassed by what you launch with, you waited too long to launch.”

Good enough is fine

“When good enough get the job done, go for it. It’s way better than wasting resources or, even worse, doing nothing because you can’t afford the complex solution.”

I think the above rule is really a specific version of this one. Get something basic done first – worry about making it great later!

Pick a fight

“Having an enemy gives you a great story to tell customers…They take sides. Passions are ignited.”

This is certainly an approach that 37 Signals employ, and it seems to have worked well for them. OnStartups have a good article on the power of polarization which goes into more detail about this idea.

Don’t confuse enthusiam with priority

“The enthusiasm you have for a new idea is not an accurate indicator of its true worth. What seems like a sure-fire hit right now often gets downgraded to “nice to have” by morning.”

Don’t drop everything to start on your latest idea. You’ll constantly be chasing new ideas, and never finish any of your old ones which might be just as good, if not better.

Take a deep breath

“When people complain, let things simmer for a while. Let them know you’re listening…but explain that you’re going to let it go for a while and see what happens. You’ll probbaly find that people will adjust eventually.”

Every time Facebook change their privacy settings there is a huge uproar. When websites change their design you hear complaints. Changes aren’t always for the best, but there are some people complain no matter what. The advice given here is to wait a while for things to settle down before making any decisions based on the feedback.

Four-letter words

“Need, must, can’t, easy, just, only and fast. There words get in the way of healthy communication. They are red flags that introduce animosity, torpedo good discussions, and cause projects to be late.”

This is one of my favourite points in the book. I’ll certainly be making an effort to avoid these assumption-ridden words in the future!

Inspiration is perishable

“Inspiration is a magical thing, a productivity multiplier, a motivator. But it won’t wait for you. Inspiration is a now thing. If it grabs you, grab it right back and put it to work.”

So true. A great reason why you should start making something the second you feel inspired to do so.

They were my favourite points, but the book is filled with many more. If you’ve also read the book I’d love to know what you though and what your favourite parts were, either in the comments section or on twitter.