Stupidity Laws

One day many years ago, must have been around 2001, when I was still involved with my
own venture, I happened across a short pamphlet tantalizingly named The Basic Laws of Human Stupidity [1]: it was to be one of the most influential readings I ever came across (probably, second only to Richard Dawkins’ Selfish Gene book who completely shook my entire world view at the tender age of 14).

To fully understand my attitude towards my co-workers, and my approach to building fantastic teams, one must fully understand (and embrace) the Fourth Law, which, grossly oversimplified, bars a fully-reasoning individual to associate himself with stupid folks.

The other well-known, oft-cited, but no less true, maxim here in Silicon Valley is never to hire B-players, as they will invariably hire C-players; and from there to a spiraling slide of doom towards mediocrity is only a brief step [2].

Put the two together and one cannot but logically arrive at anything other than my
Basic Law of Hiring:

Only hire people who are smarter than you, at least in one area, 
and ideally many.

This works great for me both as an individual (I get to be surrounded by great guys from whom I can learn daily) and as a leader (I get to have a team who does awesome stuff, even though I could be, for all intents and purposes, the village idiot).

Which also has a corollary (let’s call it the Corollary of Zero Tolerance):

Be relentless and ruthless in removing from the team those 
individuals who prove to be mediocre, lack initiative and/or refuse
to learn from their own mistakes.

Back to Principles

Notably absent from the principles above are any references to specific technology, areas of expertise or years of tenure: I am mildly amused by those job descriptions which require “at least 7 years Java EE development experience”; well, hate to break it to you, but I feel I must: the fact that you’ve been banging out EJB’s for the past seven years, does not make you a great developer (let alone say anything about you not being a mediocre individual).

This is instead what I look for when building a great team:

• abstract reasoning, and in particular good understanding of algorithms (both theory and practice);
• appreciation of testing (particularly unit testing) and a great grasp of the different types of testing (unit, functional and integration) – and their relationship to Continuous Integration (CI);
• desire for learning new technologies, facing new challenges, testing untested waters;
• proactive attitude (or, by negation, its ugly sister: waiting to be told what to do).

Distributed Systems

Writing distributed systems is hard.

It is even harder when it needs to be done at speed, with changing requirements and without the benefit of extensive field testing – to this, add the complexity of deploying your system to a public (or private) cloud, and its attendant configuration and maintenance issues, then it’s clear that you need a special kind of person to really thrive in this environment.

My empirical observation is that “hackers” (in the pejorative meaning of the terms, as folks who solve the problem immediately in front of their nose, without any consideration for even the simplest generalization to a broader class of problems) fare particularly badly in this environment, while people with a capacity for abstract reasoning, and an appreciation of the imperative to build an extensible and maintainable code base.

This is also why I put much emphasis in the “algorithmic ability” of candidates: problem-solving, tree and graph traversal, optimization and sorting problems, these are classes of problems that we face daily and require some intellectual rigor.

More about what to look for when building distributed systems in Part 4

Testing, Testing, Testing

I still have bouts of uncontrollable laughter (or depression, depending on the mood of the moment) when I recall this guy (reportedly a senior ex-Cisco QA superstar) who, when pressed to come up with a plan to reduce our (failing) QA cycle from several weeks to days (and eventually hours) first refused to even contemplate the possibility it could be done, but then came up with a grand plan to hire 17 QA testers – this for a development team of less than 5 at the time!

Of course his suggestion was to offshore this to India: as if, by adding a 24-hour round-trip
communication delay, language and cultural barrier and team separation to the problem, it would somehow magically disappear – because, you know, if you really want that baby, just offshore it to nine Indian women, and it’ll come to you in one month [5].

The astoundingly talented (Indian) woman who now leads the QA team is instead working feverishly to increase the level of (surprise!) automation (especially around our integration) tests, to the point where we hope (in the short term, at least) to reduce the release/QA cycle to a couple of days and possibly less, with a grand plan of reducing it to hours in a few months.

More in general, I look for folks that have an immediate appreciation for the absolute necessity of automated testing (at all levels: unit, functional, integration) in order to manage the incredible complexity of distributed, loosely coupled systems and maintain speed of development: in particular, unit testing has an almost symbiotic relationship with code quality – code that is not well unit tested (or that is not easily testable) has almost certainly bugs, is probably not well written and is virtually impossible to refactor.

More on testing in Part 4

Summary

Here’s my recipe to build a great team:

• hire only great people, smarter than you;
• get rid of low performers: whatever their contribution (if any) may be, you’re better off without;
• look for people with strong critical skills and abstract reasoning abilities;
• always ask for a coding question (in writing, or in person on a whiteboard) and be wary of weak responses;
• weed out people who are not obsessive about testing and do not understand the value of automation;

and, oh, yeah: be a nice guy – no one wants to work for an asshole.