Joining a new company

I decided to publish an email I was writing for a buddy - he's joining a company for the first time (though he has successfully run one). Given I've joined about 10 companies now I've picked up some some key strategy and decided to share them with him.

---------- Forwarded message ----------
From: Michael Ossareh <ossareh@gmail.com>
Date: Sun, Apr 1, 2012 at 08:31


Be non-political
This sound easy - but it is actually hard. We're leaders, that is why we start companies. We're charismatic, that is why we could raise money. Leadership and charisma cannot be taught, they're acquired when we're young - usually around 5 to 6 years of age. When you join a company being a leader is dangerous because there is already an established hierarchy in the company; politics start taking place once you're about 5 people, and the increase in politics is usually larger than linear as you hire more people. 

Be moral
I've found that when negotiating politics sticking to the right thing is the best. Good companies have less of this issue because they want to do the right thing however no company is full of A+ people, this is just fact. The non A+ people will hopefully want to be A+ people and fight for what is right, but sometimes they don't and they make life hard. Always stick to what is right.

Take direction
Knowing what is the right thing is hard. Analyze people to establish whether they do the right thing, I usually do this through a process of working out where other people are in terms of my thinking. This sometimes makes people think I'm dumb, because I ask simple questions, but their answers permit me to plot them on a graph of moral correctness. When I work out who I think is right in terms of my definition, I then take their direction with regard decisions made within the company. This helps you fall into step with the company and as a result gain institutional knowledge faster, permitting you to make the correct decisions about why, when and how to do something.

Be independent
When faced with a problem, decide a reasonable length of time to work on it before you ask for help. Assume you're asked to do "foo" and as you start with foo you realize that you have a problem, perhaps tests are failing or maybe there is some gnarly code and you want to fix it but it is touched by a lot of other things, decide how long you're willing to work on it without help; I usually set 3 hours for hard problems. Be strict with that box, once you hit the limit then ask, but in that time box work hard on it. The benefit to this is that you acquire a lot of knowledge from the edges of the problem, then when you're given help you can actually help the helper.

Establish expectations with your partner
You're moving from giving her lots of time, to giving her less time. Without fail every single time I've started at a company I've heard complaints around "I don't see you anymore", "you're grumpier since you've been working at X", etc. This is because I throw myself into things and want to impress people. It is like starting a company, except instead of building a user base you're building a trust base. You must build this in a relatively short length of time; in the order of 3 months or so. If you do not build that trust base, your desires to have your opinion heard (remember, we're leaders) will not be satiated and that manifests itself as frustration. Your partner is going to be most vulnerable in this situation; in one case my partner went on to cheat on me because she lacked attention - she didn't even know she was doing it. So set expectations, let her know you'll be busy, when to expect you home (and stick to it - or let her know if you cannot), organize date nights (and stick to them).

Choose a cause and champion it
Never have I believed it was correct to hire someone with a complete intersection of my own knowledge. Knowledge is a pool and you want it to be as wide and deep as possible; each employee brings with them new potential. Hiring is actually quite beautiful; your company becomes a patchwork of brains. You'll want to satiate your desires to be heard (we're leaders!) and one of the best ways to do that is take something the company isn't good at that you are either good at or are willing to become good at (i.e. you've an interest in it) and champion it. When you're putting in all those extra hours, most of them should be spent on this. I arrived at JTV and it was  coding-cowboy-corral (no tests, no code review), I knuckled down and built testing frameworks, I wrote emails about how to test, why to test, I pair programmed tests with people, when helping people to on board I explained the importance of testing and code review. 12 months later I see people understand why, and they contribute their own tests and improvements to the testing infrastructure and we have zero deployments to production without at least one other set of eyes sanity checking the code; it is really satisfying. I'm moving my maniacal focus to tooling now :)

I hope this helps,

Cheers,

mike

Filed under  //  personal   thinking  
Posted

Running IE8 on Linux

So it turns out most of the Asian market use antiquated versions of IE. Fortuanately we're somewhat heartless and are OK EOLing certain browsers; we only want to support IE8 and below. So then the question becomes "How does one run IE8 on a linux machine without mad headaches". It turns out Microsoft make this almost trivially easy. Assuming ubuntu 11.10:

  1. apt-get install virtualbox virtualbox-ose-guest-utils virtualbox-ose-guest-x11 unrar
  2. Download Win7 - IE8 (all four parts) from http://www.microsoft.com/download/en/details.aspx?id=11575
  3. unrar x -e Windows_7_IE8.part04.rar
  4. fire up virtualbox, create a new windows 7 instance, when prompted for hard drive deselect the "startup disk" check box. Select "continue" in the popup.
  5. Edit your instance, in storage add a new drive and select the window 7 IE8 vhd. Save
  6. Start the VM - and away you go. Password is "Password1" btw.

Posted

Interviews are tough, code submissions are harder

One of the things that struck me after joining Justin.TV is just how hard it is to interview at a company. For reference JTV give you 4 hours of interviews and we score each interview on a scale of -1 though 2. -1 pretty much vetos the decision to hire the candidate, 0 is "meh", 1 is "OK", 2 is "I want this person on my team". By the end of the first two interviews you must have scored 1, and you must keep this average across the next two, we round down; thus if your first interview is 0, the second 1, you must score 2 in your next.

I learned from Nathan Marz that keeping people chill increases the chance that they can think clearly. Panic and frustration is just noise when trying to assess someones calibre. I like to think I have a good handle on this in general.

Before getting to the interview stage there are two other stages; 1) problem solution, 2) phone screen.

The phone screen is much the same as an in person, particularly thanks to tools like Skype and collabedit / etherpad.

I'm always so shocked by how clear it is that people are panicing in their problem solutions, however. We do not put any time limitation on the candidate[1], you are at your behest to take as long as you wish to implement the best solution you can. You have all the time in the world to read, refactor, submit test cases, etc. Very rarely do people gold-plate their answers, I've had less than 1% of the solutions I've received contain a test case; which, frankly, leaves me gobsmacked. 

It is fair, while creating something for the first time, that you do not create test cases, build processes, etc. But before you submit code for peer review you should make sure you would stand behind it, maintain it, pontificate about how great it is. If you do not have the basic code-hygeine bases covered how do you expect me to be able to rate your ability as a developer?

Of course, none of these concerns are important in an in person interview thus you can be "lazier' than you would in real life, but the code you send us is real life; I want to run it on my system, a co-worker may want to run it on their system, does it work on both? Which systems? Did you include a README telling us which systems it runs on, which it has been tested on, how to use your build script?

The worst thing you can do is not take my time seriously, our users need my time, and when I'm reviewing your code you are taking me away from where I want to spend my time. Make it a pleasant experience for me... please.

If you like taking code seriously, and producing high quality work, then chances are we'll like you and you should apply to us :)

[1] - not entirely true, we have recently started putting a time limit on one of our positions - however we feel speed is a very important part of this position so it reflects what we expect from the candidate.

Posted

What qualifies you to say your software is high performance?

We're building an IRC implementation to replace the current one that we built a number of years ago. JustinTV has a load of irc traffic, probably the #1 irc service in the world - #2 if not. Naturally any self discerning software engineer checks out what exists out there with a view to how many of the checkboxes that you value does it check; for us, extensibility and performance. The search for high performance irc daemon actually yeilds a number of hits, and you go to those projects and no one has any numbers. 

As such we're going to build and opensource ircbench, a tool similar to apachebench that will performance test your irc server and spit out some data that permits you to graph the performance of your ircd.

It will be on github for the whole world to see

Posted

How to patch Riak 0.14.0 to avoid the newline parsing bug

Today we discovered that newlines in strings causes Riak.mapValuesJson to crap out. The fix is relatively simple, and detailed here to hopefully aid others:

Newline parsing is broken in JSON2.js shipped with Riak. Drop a more recent version of JSON2.js in the directory referred to by js_source_dir in app.config's riak_kv section, e.g.

{js_source_dir, "/etc/riak/js/"}

and reload the node.

--Kyle

So to step through it:

  1. cd to your js_source_dir
  2. curl or wget http://github.com/douglascrockford/JSON-js/raw/master/json2.js
  3. change line 162 to; var JSON = {};
  4. delete lines 163-165
  5. save the file
  6. service riak restart (or riak-admin js_reload if it works for you).

Douglas Crockford wants to fall back to any existing, likely browser, implementations of JSON parse/stringify and steps 3'n'4 circumvent that.

Hope this helps.

Posted

California is outrageous

http://arstechnica.com/tech-policy/news/2011/01/warrantless-cell-phone-search...

There has long been debate over user privacy when it comes to various data foundon a cell phone, but according to the California Supreme Court, police don't need a warrant to start digging through your phone's contents.
I highly recommend working out where you stand with regard encryption on your mobile device.

Posted

love irc

Screen_shot_2010-12-12_at_9

the sarcasm in IRC is definitely the best bit of it.

Posted

Batch consumption of Crunchbase with Clojure

A special `thanks` goes out to Alex Osborne for helping me out in the ever amazing #clojure on freenode.

We wanted to get some numbers from the company listing on crunchbase, particularly the employee distributions. My initial pass resulted in lots of memory issues.

to run: (filter (complement nil?) (pmap process-company (take 1000 companies)))

The issues in order:

  • line 47: turns out (:name co) is `evil` (at least, not as benign as you might think it is).
    • the data structure created on line 45 is comprised of mostly strings.
    • extracting the name from the company results in that data structure being kept around.
    • After about 300 companies I'd exhausted my heap.
    • fixed by (String. ^String (:name co)) - creates a new string, permitting the backing object to be GCed
  • line 41: using http agent like this will create a ton of threads
    • Agents are backed by a thread pool
    • This pool queues up threads to be run, it will not block when you reach the limit of the pool (I've no idea why I thought it would block...)
    • fixed by not using agents and using clj-sys/work
    • Screen_shot_2010-12-11_at_12

The work library makes running this very easy: (future (filter (complement nil?) (work/map-work process-company 3 companies))). The (future) permits me to get my repl back so I can check on the status:

  • (reduce + (for [k (keys @emp-ranges)] (count (k @emp-ranges)))
  • (for [k (keys @emp-ranges)] (str k " has " (count (k @emp-ranges))))

The result... a finished data set thanks to far more manageable resource consumption

 

Screen_shot_2010-12-12_at_1

Posted

I <3 FP

Facebook will never accept the following answer since it is not one of the supported languages. That said the elegance of expression here is so great. I truly love functional programming, particularly in lisp.

 

Filed under  //  clojure  
Posted

Learnings from our survey

Summary: Colours are important, as is the order of data. Bureaucracy is a serious yet mostly unspoken about pain.

Recently we surveyed 10% of the YC alum for their views on start ups vs big companies, the answers were interesting but not as interesting as the conversation that followed. In that conversation a few things became very clear.

Bureaucracy seems to be a necessity, yet it causes so much pain.

When organizations institute bureaucratic rules, it's always to avoid problems-- e.g. duplication of effort. They never seem to consider the cost of the rules, only the cost of not having them.

  - Paul Graham, YCombinator

To take an extreme example we hired a rather insecure engineer who proclaimed himself a "UDP expert", and successfully petitioned management to put in place a rule that anyone wishing to implement even the simplest piece of UDP code must talk to this guy before every commit [...] 

My first day at justin.tv was quite a contrast. Justin and Emmett pretty much just said "go implement a very scalable chat system - the one we have right now is breaking. And try not to interrupt anyone if you can, we're all very busy".

- Bill Moorier, Justin.tv

Bureaucracy is entropy for companies.

- Ben Reesman, Klout

There are some interesting search results:

When presenting data, colours and the order of the data are important

BTW, if you have a range of answers, map it onto range of colors. Don't use blue for no, red for weak yes, and purple for strong yes, because chromatically purple is between blue and red.
Paul Graham, YCombinator

 

[...] could the bars be sorted by some weighted score? So the statements they most agree with pile up on one side.
- Neil Kandalgaonkar, Brevity.org

Posted