The Snepo Blahg

I attended the BRITE Conference at Columbia Business School last week. It was a bit painful to realize that I had, in fact, become a marketer. Regardless, I had the opportunity to learn an absolute ton, much of which will help with marketing PathPoint, particularly with our work around gathering a community of digital signage advertisers.

The conference was great though, the keynote was delivered by Seth Godin and it was chock full of speakers. The subject matter focused quite a bit on community building and the notion of tribes. I attended preparing to hold my nose as legions of clueless marketers rambled on about synergies and leverage but to my delight only one of the presenters went that direction.

The second day of the conference was spent split into workshops. The second workshop I attended was run by Frog Design. These guys were on fire, they presented their brainstorming technique and we tried it out with the problem of generating revenue for the New York Times.

The Technique

• Start with the problem: The New York Times Needs Revenue
• Then list assumptions, these are based on how the problem is typically solved or how it currently works. In this case we assumed (among other things) that Money comes from readers and advertisers
• Then provoke those assumptions by exaggerating, reversing, or otherwise throwing them completely off kilter. You can tell the quality of a provocation fairly easily, if it elicits snickers from your group then you’re on the right track. My contribution was “What if there were no readers?”
• Then come up with ideas based on those. Again my contribution to my team was “Lease out the writers and content creators”

When trying to find the exact terms for the rest of the provocation categories I happened across this fastcompany article and this blog posting at Really Practical. That right there is enough to make a guy feel fairly chuffed with himself.

Mocking and what the hell?

Ok, you might be asking yourself what the hell is this guy talking about. Let me start by saying this. If you could build your application from the outside in, wouldn’t that assist you in delivering a better product?

What I mean of course, is that as developers we tend to think in ways of how to store data? How can I make it fit my idea of a relational database? So we start with UML documents, schema’s, migrations and all that guff. We start from the inside and work our way out. We get this fantastic architecture that we love, we’ve toiled over it after all, it’s like a child, and god dammit I’m not giving it up for nobody.

Welcome client

With bold new ideas, and assumptions that you as the poor developer had no idea about.

bq.Wait, that won’t fit into my architecture!

Now I know what you’re thinking, “this is just one of the things with being agile, you need to let go”. I agree whole heartily, but it doesn’t make it any easier to try and fit a square peg into a round hole.

Now imagine if you could develop the majority of your controller code (assuming you’re using an MVC architecture) and get a really good practical idea – assumptions aside – that you could develop from. It’s lean and really simple to change.

rSpec to the rescue.

Mocking and stubbing is a part of rSpec these days, and since I’m a Ruby guy, I’m also an rSpec guy, so all the examples here are in rSpec, however the principles remain the same regardless of language.

A Mock is described by the rSpec website as follows,

Mock objects are imitation objects that give you declarative control over their behaviour in the course of the execution of an example

Personally I always found this a little confusing, so in my own words, Mocks are a way for you to use object that don’t exist, or to pretend that you have an object that you in fact don’t have. Let’s look at an example.

 it "should mock an Event class since we haven't written that yet" do
  @events = mock(["Event 1", "Event 2"])
  User.should_receive(:find).with(:all).and_return(@events)

  events = User.find(:all)

  events.should eql(@events)
 end

Before you run this… It won’t work, I’m presuming we have no models/schema at all, so there is no class called User as yet.

 it "should mock an Event class since we haven't written that yet" do
  User = stub!(:user) unless Class.constants.include?("User")
  @events = mock(["Event 1", "Event 2"])
  User.should_receive(:find).with(:all).and_return(@events)

  events = User.find(:all)

  events.should eql(@events)
 end

We’re now “stubbing” in an object to use in place of the User class. The difference between a “mock” and a “stub” is that a mock has an expectation of being used, i.e. that if a mock object is not used, it will cause the test to fail. It’s an expectation in itself. A stub however is just a simulated object, there is no expectation placed upon it. Note also I’ve got unless Class.constants.include?(“User”), that way if and when you do develop a User model it will be used instead of the stubbed object.

This all seems quite pointless…

If you’re feeling like the above examples are pointless, well, you’d be right. Realistically that is a useless test. So lets look at a real example.

 describe LoginController do
   it "should authenticate a user" do
     User = stub!(:user) unless Class.constants.include?("User")
     user = mock("A logged in user")
     User.should_receive(:authenticate).with('login' => 'cbarrie', 'password' => 'oohhhh').and_return(user)

     post :authenticate, :user => {:login => 'cbarrie', :password => "oohhhh"}
     response.should redirect_to(admin_url)
   end
 end

Controller tests/specs are the one place that mocks and stubs are awesome. When testing controllers, it’s a bit of shame to be testing code, that you’ve already tested elsewhere, 1. it’s slower, 2. fixtures in the database are fragile, and 3. ActiveRecord is already heavily tested. Why test the whole stack each and every time you run your controller tests/specs? It just makes it hard to find the errors.

In the above example we now have the opportunity to test – in isolation – a method in the controller without the need to test the User class. Our authenticate method on the User class should already be tested in a separate test, there is no need to hit it twice. More so we don’t even need to have a User class at this point in time to run this.

Now you can test in isolation and begin developing with an environment that can easily adapt to the changes required by business owners.

Ruby is such a great language, and we use it for all sorts of development; from simple scripting to full blown web applications. One of the things I like about it, is the way it is integrated into all sorts of platforms and frameworks and OS-X’s Cocoa framework is no exception. As of X-Code 3 the RubyCocoa scripting bridge is a part of the whole framework. For a Ruby programmer, it makes hacking up an OS-X app simple and quick.

Of course personally I’d never use this for a big heavy full blown Cocoa application, that’s what Objective-C is for, but for taking something simple. Well that’s a different matter.

First we need to understand a little bit about how the framework actually works. If you’re a Ruby guy and you’ve used Rails, you’ll start to feel comfortable, since Cocoa is an MVC (Model View Controller) framework, so the abstraction is similar to that of Rails (or Merb or Camping or numerous other frameworks out there). Models are classes just like they are in Rails, as are Controllers. Views however are made up of NIB files, which are created by the Interface Builder Application.

What we’re going to do is to create a simple echo app, that can take an input, and echo it back to you reversed. Trivial, I know but it does help to explain some core concepts about how Cocoa and Ruby work together.

Let’s get started

Start a new project in X-Code 3 and select the Cocoa Ruby Application option to create an application framework with the Ruby Scripting bridge.

In the classes folder on the left add a new file and name it MainController.rb. Paste the following code into the MainController , so that it looks like this:

require 'osx/cocoa'
class MainController < OSX::NSObject
    ib_action :display_message
    ib_outlet :text_field, :text_display

    def display_message(sender)
      @text_display.setStringValue(@text_field.stringValue.reverse)
    end
end

You’ll first notice the two methods, ib_action and ib_outlet, these two methods allow us to map methods and instance variables to our NIB file (remember our NIB is our View), these methods come courtesy of OSX::NSObject which we inherit from.

Next double click the NIB file MainMenu.nib, this will launch the Interface Builder application and we can begin to build our View.

From the Library on the right, find NSTextField and drag two of them onto the Window, then also find a Push Button, and drag it onto the Window and rename it to Echo.

Your window should look something like this:

Now it’s time to wire things up. Firstly we need to instantiate an object from MainController. From your library find Object (it’s the blue cube), and double click it, it should pop up in your MainMenu.nib window.

Now highlight it, and select the Tools -> Identity Inspector from the menu. Under class select MainController, you’ll see it populate with the methods and instance variables we set in MainController with ib_action and ib_outlet earlier.

Now for the tricky bit of Interface Builder. Press the control button and drag from the Main Controller instance in the MainMenu.nib file on to the top Text Field on the Window, you should see a popup listing your two instance variable. Select text_field(this make the instance variable @text_field an instance of NSTextField), do the same again for the other NSTextField and select text_display.

Then Control click from the Echo button back up to the MainController instance, and this time you should see our ib_action display_message, this maps the action of this button to the method, display_message.

Guess what, that’s it, you’re done. Save the work you’ve done in Interface Builder and quit it, head back to X-Code and select the Build and Go option. Viola when you enter some text in the top box and then click then echo button, you’ll see text reversed below it.

Wow, we did it. We have a Snepo office in NYC. Well, to be fair it’s not an Office Offfice, it’s like having another startup.

As many of you know I’m an American by birth (Australian by naturalisation—And spelling) and I have been hankering for a return to the mother country for a while. New York presents a lot of opportunities for Snepo as a company, the size of the market here is massive. With the release of our fantastic new product, PathPoint, which is an OMFG awesome kiosk software suite, it just made sense to go for the gold and push ourselves internationally.

Still, I miss Sydney and as much as I’d never admit it, especially not to an internet full of strangers, I miss the guys at the office (not Arse). New York is great though and I’ll endeavour to keep the blahg updated on the adventures of Snepo, Inc. as we enter the next phase of our business development and the push to start marketing a new product to a new market.

Why start a business, or why work at a start up? The pay isn’t so good, the offices can be bit cramped (unless you work at Snepo), the prestige isn’t exactly going to get you an interview on The Daily Show. So without motivators like money, fame, and prestige what makes us go?

Accomplishment

This is the king. The beautiful conceit that fuels the fire of so many start ups, that we can create something to change the world. Even if there’s not a noticeable change in the planet, at least there’s the singular feeling of exhilaration that comes from creating something with quality.

The founders, the first employees, the partners—None of us would be anywhere near the fire if it weren’t for the chance to say that we did something. We made something. That’s hot shit. It’s what keeps smart people awake at night, spinning ideas around in their head and hangin’ for the whole sleep thing to be over with so they can get up in the morning and make stuff happen. Those Captain-Of-Industry-Motherfuckers can’t get away from the fact that they’re just junkies for that rush that comes from accomplishing something.

That drive is fantastic but it burns out after a bit. It takes a long time to notice it’s happening, too. It’s all too easy to charge and charge even when the wheels start to spin. Here’s an experiment for you: Take a whole room full of ambitious, motivated people and work ‘em until their wheels start spinning and they aren’t getting anything done. Now wait for the knife fights. We tend to sow the seeds of our own destruction, that’s poetic and all but it’s hardly any way to run a business.

So what to do? We’re motivated by accomplishment but what else? If we are going to stave off the knife fights we have to find some way to catch traction.

Fucking Off

Call it whatever you want, “Team Building”, “Morale Boosting”, “Getting Drunk at The Pub”—It all comes down to understanding and accepting that as human beings our sense of well-being comes from more than one place. At Snepo we make it a point to have at least one Fuck Off day per month. Over the last few months we’ve done things like:

• Ten Pin Bowling (a much bigger novelty here in Australia than it is in the States)
• Hit the pubs at 7:00AM for Arse’s birthday. We made it most of the day and then had a party back at the office.
• Go-Karting. Arse’s father is a gear-head and we rented the track for a day with some super charged go-karts o’ death.

I consider all of those to be official Snepo Business. None of us got involved in this thing to be running on a treadmill until we burn out. A good solid day of tearing things up and screwing around is absolutely essential to keeping that accomplishment drive greased up and ready.

A bit of competition is good for diffusing the knife-fighting urge we talked about earlier as well. I’d much rather race my buddy around a track, lose control, and slam into a tire barricade at 60/kph than argue over the colour of a gradient or what sort of test framework to use. It’s just a bit more humane.

Leisure is Necessary

There’s been a lot made of the 40 hour week maxim. If you work any more than eight hours in a day then you’re probably just adding bugs. Our experience at Snepo has found this to be painfully true. It’s a hard one to stick by but it’s paid off in spades. We’ve decided to take things further though. We have a policy that roughly a quarter of our “work” time should be spent doing what we want.

Seriously. Writing a book, painting, building robots, hacking a new programming language. Something, anything to tap into that hot juicy Accomplishment Vibe and give it a little bit of variety.

What about money? Holy shit! You’ll never be able to pull it off, you couldn’t possibly get anything done that way!

Just watch us. We’ve been in business for about 10 months now and we’re steadily growing. We’ve got one employee, and enough consulting work to keep us busy. We’re watching the sales of our first product grow and it’s delightful. Moreover, we’re wicked productive because we don’t succumb to the Ambition Treadmill and burn ourselves out just for the sake of it.

The latest buzz flitting about in the “I haven’t used it but it sounds cool” programming language crowd is Erlang. An admittedly cool and exotic language, it was developed by Ericsson in the late Mesozoic and has been used to build ultra-massively scalable telecom switches that fail once every thirty billion years. It has all the things that you could possibly want if you were developing a telco exchange, ATM switch or some other highly available networked switching and routing style system.

So of course people have been talking about building web apps with it. Those people are silly.

There are other kinds of apps?

Yeah. I hate to go all “bubble-bursty” but not everything is a webapp. In fact at Snepo much of what we do is networked web available applications that provide functionality that web apps can take advantage of through service interfaces. One of those projects came up recently, we had a client who needed a highly available, super scalable video encoding solution. Erlang was the perfect fit for the job so I fired up the old erlang-mode in Emacs, got reacquainted with the Erlang Documentation Site and set about the project.

Design Principals and the OTP

Erlang has its roots in the world of large applications where good architecture is absolutely necessary. In typical class based Object Oriented programming it is common to design a top level abstract class or interface for a bit of functionality. Erlang, being a functional programming language doesn’t have objects or classes. It does however have the institutionalised design pattern of behaviours. They accomplish much the same thing in much the same way.

A good example is the gen_server behaviour which is declared like so:

-module(most_awesome_server_evar).
-behaviour(gen_server).

start() ->
 gen_server:start({local,most_awesome_server_evar}, 
                   most_awesome_server_evar, [], []).

init() -> []. 

handle_call(do_stuff, _From, State) ->
  {ok, stuff, State}.

A behaviour is a contract that says that a certain set of functions will be available in the module that has declared it. The end result is that you can use the gen_server module to manage communication with your implementation.

>{ok, Pid} = most_awesome_server_evar:start().
>gen_server:call(Pid, do_stuff).
stuff

Thrilling. The upside is that you get the benefits and convenience of object orientation style polymorphism without the pain in the arse that comes from managing class hierarchies. It also sets you up to work in the Byzantine world of the OTP (Open Telecom Platform). To create an OTP app you need to coordinate a series of start scripts and configuration files that is easily on par pain-wise with the self-flagellation that occurs during Java development. At least there’s no XML.

The first thing I did was spend a day or two putting together some Rake tasks to automate project creation, testing, compilation, and the bundling of applications. And I’m glad I did. Here’s what you need to do to set up the Erlang test server:

• unpack the test_server distribution in your OTP directory
• create a test working test directory somewhere
• start the erl shell and eval ts:init() (or some such thing…)

That sets the groundwork, now to actually set up a test environment

• place your test .beam files in a folder at the same level as the test_server directory named <app_name>_test
• Put a test.spec file in <app_name>_test with just the right path information (this took me a while to get right).
• run the tests, either from an active erl shell or from the command line, using a command along the lines of: erl -pa PATH_TO_TEST_SERVER_LIB -noshell -s test_server_ctrl run_test SPEC app_name_test.spec -s erlang halt

Not a whole heck of a lot of stuff to do if it’s properly automated but it becomes a bit of a hassle to figure out how to get things to hang together due to the lack of documentation.

Packaging the application up is a headache in and of itself. There is a .rel file, a .app file, and a script file that needs to be generated. I won’t go through the steps because I’m still a little scarred. Now this is fair enough because the Erlang OTP was developed for use in one company with an already existing expert base. I’m sure that as the architecture evolved nobody noticed how needlessly complex the setup process had become.

I had run across this stuff before, the last time we built something in Erlang (a year or so ago) and it was just as painful then. Unfortunately it’s not any less so now but at least I had some cobwebby memories to guide me through the hoops.

But it’s not all bad

Not by a long shot. Once you finally get around to actually developing in Erlang it is a treat. By using pattern matching you end up with succinct, declarative code that is perfect for routing requests from one place to another and keeping tabs on available nodes. Our video server was built to have N+ encoder nodes and a couple of routers to send requests to the most available encoders, this part of the job was a treat.

To top it off, transferring binary data between nodes is fast. It’s quite performant, depending on the task it’s in the same club as C and it doesn’t have issues with pointers and other uglies associated with programming at that level.

What made Erlang such a good choice for this project was the ability to automatically scale up the number of nodes for this project. Need 10 encoders? 1000? Fine, stack ‘em up like pizza boxes. Some of them crashed? Fine, there are supervisor nodes that are watching them and will restart them when they go down. All of that would’ve had to have been reproduced in another language, distracting us from the job of actually writing the application itself.

But some of it is bad

Erlang sucks at strings. It’s a common complaint but no less valid for it. There is almost no application that you can write now days that doesn’t deal with strings. This is particularly true if it actually has to talk to the outside world. In our case there was a wee bit of multi-part form encoded HTTP request parsing that needed to be dealt with. She works but she’s ugly.

But once again, when does ATM switching ever have to deal with strings? I can hardly begrudge the Erlang developers for overlooking this but it is a huge gotcha when you are trying to use the platform for something a wee bit outside of the intended purpose.

More unforgivable is how terrible the C interface is. It’s bad enough that it makes Haskell’s FFI seem nice and transparent (not that the FFI is that bad as far as C interfaces go…). This is strange to me because I assume that there would be a lot of dealing with the C side of things in the switching world. The concept is that you load a C library and then start an event loop which takes byte flags. You send a list of bytes to the C process, delegate those bytes to your C functions, and then encode the responses as a new list of bytes which you send back to Erlang. RAR. It’s a wee bit error-prone.

But would you do it again?

Of course. I wouldn’t dream of developing this type of application in anything else. Sure I could give Termite Scheme a shot but it’s hardly as road tested as Erlang is and that makes it harder to sell to a client. I came for the concurrency and distribution. I was enchanted by the nice abstraction of behaviours, I love the terseness of pattern matching, but I hate the mess that comes out of using tuples everywhere.

I love the reliability that comes from having processes signal each other when there is a problem. I hate the esoterica required to configure the application and its supervisors properly. But in the end, nothing is perfect and development is often about picking the right trade-offs.

The beautiful thing about having so many programming languages available is that there are times when you have the opportunity to truely use the right tool for the right job. Erlang was the right tool for this one but I sure wouldn’t try to build a web site with it.

With Snepo, much like many other startups, we have endless faith in our great ideas. Unfortunately that didn’t mean that we were able to just run out the door at the beginning. Money, that stuff that we’re all interested in making gobs of (while changing the world of course) was also necessary if we were going to turn our idle chit-chat into a real company.

If you find yourself in this position or if you’re getting ready to take that brilliant idea to market you have one or more of the following options available to you:

• Save and save until you have enough money to support yourself and pay rent, utilities, etc… for at least a year
• Borrow from family and/or friends
• Try to lure somebody into investing in you
• Consult while trying to maintain focus

There are benefits and drawbacks for each of these as you may suspect. Let’s examine them in more detail.

Save and Save

Seems like a good idea at first until you realise that in order to save enough money to live and pay rent for a year would require you to already be making at least double what you spend. Clearly going a pure savings route is just not in the cards unless you’re already in more money than you know what to do with. Alternatively you could be independently wealthy from the get-go, it worked for Bill Gates and it could work for you.

Assuming you’re not going that route saving enough money to go without salary for three or four months is still a must. When starting a new business nothing is for certain save for the certainly of going longer than you thought without pay. So if you’re entertaining fantasies of putting money down on a house, think again. You can be a homeowner after you make it big.

Borrow from family and friends

On one hand this can be a spectacular option. The loans are cheap and the repayments are easy. Unfortunately there looming problems that are all too obvious. First, there’s the emotional baggage of carrying debt to a loved one or friend. This can be intimidating depending on your family’s financial status or emotional health. The other factor is that if you do run across hard times the inability to repay loans can wreak far more havoc on your life when you owe Maw and Paw money than when you owe The First National Bank of Renaldo several months salary.

A slightly kinder compromise to the notion of borrowing several months salary from your family and friends is living off of your partner. If you have a supportive spouse and are willing to take your lumps then this is a viable option and probably one of the better ones out there. Unfortunately none of us had that option, my partner being a full time student and both Arse and Ben’s other halves being heavily pregnant when we decided to commit to Snepo. Take it if you can get it, mate.

Lure some poor bastard into investing in you

Ha! What a great idea, somebody gives you and the other founders a year’s salary to make your idea a reality. All they ask is your heart and soul and the ability to immediately replace you with people that actually know how to run a business after you’ve begun to produce meaningful IP.

The truth of it is that it really depends on your product. If you’re selling a service based software solution where there’s a huge advantage to the first mover then you’re best bet is probably the VC dough. On the other hand if you’re selling a software product and you’re not required to make everyone in the world a user right this minute then it pays to spend that VC courtship energy on actually developing your product.

Unfortunately, in many cases the search for funding takes precedent over the business itself. You can end up spending more time on your elevator pitch than on your products. This is my intuition anyway, perhaps after a while I may regret our decision to refrain from chasing venture dollars. Probably not though.

Consulting

Ahhhh consulting, that double edged sword. Consulting can pay the bills ohhh so well. It’s relatively easy work to get these days with the market rebounding a bit, and who can turn down consulting rates? It all comes at a price though. If you’re consulting then you cannot be working on your big ideas full time. This is a lot more serious than it sounds, being a consultancy is great if that’s the business that you’re in but if you’re keen to build a product it has the ability to weigh you down with the siren call of steady income.

It doesn’t have to be all doom and gloom though. If you set a quota of time per week that must be spent developing your product and you stick to it then taking consulting work is about the best way for a startup to stay started. That’s not all, if you choose your clients wisely then you can end up in a good position to develop future markets for your product.

In the case that you have a client and the job you’re doing could benefit from your shit-hot automatic penguin classifier algorithm then be up front with them. Tell them that you’re working on a product that may be useful to them and that in exchange for a reasonable licensing fee you will be willing to use it in their solution. Be clear about the state of it and you could end up killing a few birds with one stone.

What we’re doing

When Arse, Ben, and I left to start up Snepo we were certain that we’d not even see a dip in pay (HA!). We had lined up two different consulting clients that were both vying for our attention. Both of these parties were big enough to provide us with our current salary rate for several months. Well, sure enough- we were along our merry way and the client that we chose to deal with stalled our first payment. Heh, no big deal right? Well, this client kept stalling and we finally ended the relationship before it had really begun. Meanwhile we were busy lining up other potential customers and managed to land enough paying contracts to keep us afloat.

However, those contracts paid Net 30 which is actually pretty speedy for larger corporate clients. That means that we get paid 30 days after we invoice. We deposited money into our business account for the first time about a month and a half after we opened it.

The lesson is to make sure you can absorb the loss of income right away, don’t run out the door to startup a wanky “web 2.0” company, eschew consulting work, and neglect to be able to support yourself. I couldn’t imagine very many things more crushing than having to give up and get a real job being just a few weeks away from being self sustaining.

Having recently found myself in a situation where I was required to double frame a massive amount of animation I figured I wanted to preserve my click finger and F5 key.

JSFL to the rescue:

var additionalframes = 1;
function addFrames(item){
    var frms = item.frameCount;
    for(var j=frms;j>0;j--) 
        item.insertFrames(additionalframes, true, j-1);
}
var dom = fl.getDocumentDOM();
addFrames(dom.timelines[0]);
for(var i=0;i<dom.library.items.length;i++) { 
    addFrames(dom.library.items[i].timeline);
}

The script is run as a command and will recursively traverse all time lines (including anything in your library) and add additional frames as specified by the additionalframes variable.

sample files (.zip 64kb) Another handy JSFL script for those times when you need to change font usage across an entire fla. This command is particularly handy when dealing with missing fonts that need to be updated or change at a later date.

var dom = fl.getDocumentDOM();
var font_select = "Arial";
var font_replace = "Verdana" 
chageFonts = function(timeline) {
  for(var layer in timeline.layers){
    for(var frame in timeline.layers[layer].frames){
      for(var element in timeline.layers[layer].frames[frame].elements) {
        var item = timeline.layers[layer].frames[frame].elements[element];
        for(var txt in item.textRuns) {
          var font = item.textRuns[txt].textAttrs.face;
          if(font == font_select)  
            item.textRuns[txt].textAttrs.face = font_replace;
        }
      }
    }
  }
}
for(var i=0;i<dom.library.items.length;i++) {
    chageFonts(dom.library.items[i].timeline)
}
chageFonts(dom.getTimeline());

The script is run as a command and will recursively traverse all time lines (including anything in your library). It will update font usage at a character level thus preserving textfields with mixed font usage.

There are a million things to worry about with a startup. There’s the bazillion dollar idea, there’s funding, rent, the cheapest place to buy ramen. All of these are important to be sure but since most startup founders aren’t starting up on their school holidays (unless they’re MIT graduates residing in Paul Graham’s small intestine*) there’s also the looming concern of leaving your old job.

This is a relatively easy step if you don’t like the place you work or if you’re a sociopath but in the case that you actually work with people that you respect or you have a shred of human decency then you have a lot of strategising to do. When the idea of Snepo first started geminating Arse, Ben and I were working at a small shop that developed touch screen applications for kiosks. It was interesting work, we were located in an inner city warehouse complete with all of the fixins. We had an annoying dog, a ping pong table (upon which Arse and Ben LIVED). We even had a masseuse come into the office to knead our backs into paste on a monthly basis.

Life was pretty good. There was always weird hardware around, I had a lot of small projects going and I was developing things in Ruby (pre Rails). Hell, I even had an Erlang project. I was constantly writing interfaces to hardware devices like credit card printers. For an ex-web jockey this was heaven.

But It was someone else’s business. It may have been a developer’s dream job but it wasn’t going to make my dreams come true. Arse and Ben were in the same boat. However, we worked with a great bunch of people that we didn’t want to leave in the dust on the way out the door. So here it is, the Snepo Guide To Fucking Off Your Old Job Without Burning Bridges or SGTFOYOJWBB (yeah! Airpuncher!)

Document things

You’ve been an invaluable part of the team**. That means that you probably have a mountain of elegant, efficient, even beautiful software that you’ve written or contributed heavily to during your tenure. When you’re gone there’s no fucking WAY that anybody is going to maintain it without good documentation.

Do you want to know what’s even worse? Even if it’s well documented it won’t be maintained unless the documentation is stellar. If your documentation doesn’t read like a fucking Irvine Welsh novel then your successor is going to rewrite everything from scratch. If you can’t convey in an engaging, entertaining way that your code is worth reusing then there are two things that are going to happen:

• Your company will lose a lot of money and time rewriting everything you built

• Everyone will think you are an idiot because the new guy who takes your place will be sure to tell EVERYONE that the “last guy here” couldn’t find his ass with both hands.

If you write the best documentation ever, you are engaging, witty, and you make it easy to see why your code should be reused (assuming it is actuallly good enough to be reused and we are assuming that) there is about a 38% chance that it actually will be.

That’s what happens if someone senior takes your old role.

If they get a junior in to do your job then your documentation will mean the difference between the poor guy flailing about like an epileptic housecat and being able to bugfix or maintain your work.

If it’s that hard to convince someone to stand on your shoulders then why bother? Well, in the worst case you will still end up with a good body of documentation that you can use to put people at ease. When you get that incredulous “I can’t believe you’re leaving us all alone” puppy dog look from your manager you can point to that stack of hawt LaTeX typeset PDFs and say, “Hey buddy, don’t worry it’s all documented”.

There are probably some of you huffing and puffing about how you document your code anyway. I know I do—just until a deadline starts breathing down my throat or until a couple of projects stack up. If I were to look through my “documented” projects right now I’d still garauntee that there are significant holes in the documentation having to do with things like that race condition that surfaced a few months after the project ended or that mysteriously overflowing buffer that caused three people to die in a train wreck in Uzbekistan. Taking the time to review and update the documentation on old projects will make a world of difference to anyone who has to maintain your work after you’ve gone.

Here’s a hint You’ll never be allowed enough time to document everything before you leave. When you give notice you will be told to finish up the project you were working on. Most likely you’ll be told to spend your last few weeks doing mind numbing bugfixes. The key is to start documenting about a week before you actually announce that you’re quitting.

Nutting up

Get your shit together and get out the door. If you and your buddies really do have the talent and the best idea evar then you had better get moving. It takes about 18 months for someone else to commercialise on that cool idea that you had at lunch. If you don’t move on it right away someone else will.

See, if you thought of something awesome then there are roughly 1000 other people around the world that have thought of it and are also capable of building it. At least thirty of those people will make a business out of that idea***. In order to be successful you have to be one of those thirty and you have to be a rockstar with big nuts. Those nuts have to be big enough for you to quit your job and live on ramen noodles for a month or two.

If you are capable and have the money to survive those first few months then the longer you put off quitting the more opportunities you will miss. The more likely you are to be just another one of those wankers that is “gonna start a company one of these days” but never actually will because they’re a bit too comfortable and their balls are just a little too narrow in diameter.

It’s not you, it’s me

Breaking the news sucks. Strike that. Breaking the news to your team sucks. These are the people that you’ve worked with closely the whole time you’ve been at the company. They’re great—and talented—people and you are leaving them in the dust to pursue your rockstar dreams. In order to be a decent human being you need to let them know that it’s not personal. Do your best to allay their fears that you are going to spend the rest of your four weeks’ notice subtley fucking them over.

Do this because you are a good human. If that’s not motivation enough then remember that it never pays to burn a bridge, these are talented people you work with and you may want to headhunt them one of these days.

Why bother?

Because it’s good practice! I don’t believe in Karma but when you treat people well, they will tell their friends. If you are an asshole they will tell even more of their friends. The world is a very small place and it never pays to piss people off. Even if you hate them, which you probably don’t, it is worth your while to be kind and go out of your way to make their lives more pleasant while you are leaving, even from a completely pragmatic perspective.

More importantly if you really want to start your own business you’re better off starting on the right foot. At Snepo one of our major motivations to start up was to Do Things The Right Way. The very first thing you do when you start a new business is leave the old one and it was very important to us to do it The Right Way. It sets a precedent.

* Just kidding Paul, we love you and want to have your children. Lisp is neato! Star nosed mole rats RULE!

** Of course you’ve been invaluable, you wouldn’t be capable of starting a new company if you were just another wang would you?

*** Those numbers are totally scientific, at Snepo we’re all scienticians.