I remember the first time I interviewed for a front-end programming position and got asked how to do something in JavaScript on a white board. The specifics are vague, but it’s crystal clear how stupid it made me feel and how little it had to do with the actual job.
Since then I’ve rarely heard a kind word about the parlor tricks of programmer hiring, but I’ve heard plenty of scorn. There’s certainly a minority of puzzle solvers who love to get their fancy tickled like this, but I sure wasn’t one of them and neither have most programmers I’ve met.
I’ve known fabulous programmers flame out in the quizzing cage and terrible ones excel. So unless you’re specifically hiring someone to design you the next sorting algorithm, making them do so on the white board is a poor gauge of future success.
The only reliable gauge I’ve found for future programmer success is looking at real code they’ve written, talking through bigger picture issues, and, if all that is swell, trying them out for size.
(If you need help posting a comment, feel free to use any of these samples: “You make todo lists, you don’t need real software engineers”, “Math is actually really important, you know!”, “Google is worth one gajillion dollars and they use quizzes, so there!”)
The great thing about keeping score is that you can track your progress. We started asking customers who contacted support what they thought about the interaction in 2010. We were thrilled to end that year with just seven out of a hundred being unhappy with the service (and 84% being happy, 9% being OK).
But I’m really proud to announce that we’ve dramatically raised our game in 2011. We’ve gotten the frown ratio down to just three out of a hundred (90% being happy, 7% being OK). That’s less than half of what it was just the year before!
(If you look at just the last six months of 2011, it went even better still: 92% happy, 5% OK, 3% frowns).
Part of this is hiring a bigger team so the average number of emails each person has to answer is less. We’ve gone from needing each person to answer about 80 emails per day to just around 40 (again, on average—there were and are significant swings at times). That of course means that we can spend more time on each response and making more customers happier is the result.
Gains have also come from analyzing the data. Finding out what made people unhappy and trying to do better. We also now follow up with more frowns and try hard to “flip ‘em” by doing what we can to make a bad experience great.
I’m so proud of our support team for what they’ve accomplished this year. Thank you Ann, Chase, Emily, Joan, Kristin, Merissa, and Michael.
Ma Bell engineered their phone system to have 99.999% reliability. Just 5 minutes of downtime per year. We’re pretty far off that for most internet services.
Sometimes that’s acceptable. Twitter was fail whaling for months on end and that hardly seem to put a dent in their growth. But if Gmail is down for even 5 minutes, I start getting sweaty palms. The same is true for many customers of our applications.
These days most savvy companies have gotten pretty good about keeping a status page updated during outages, but it’s much harder to get a sense of how they’re doing over the long run. The Amazon Web Services Health Dashboard only lets you look at a week at the time. It’s the same thing with the Google Apps Status Dashboard.
Zooming in like that is a great way to make things look peachy most of the time, but to anyone looking to make a decision about the service, it’s a lie by omission.
Since I would love to be able to evaluate other services by their long-term uptime record, I thought it only fair that we allow others to do the same with us. So starting today we’re producing uptime records going back 12 months for our four major applications:
- Basecamp: 99.93% or about six hours of downtime.
- Highrise: 99.95% or about four hours of downtime.
- Campfire: 99.95% or about four hours of downtime.
- Backpack: 99.98% or just under two hours of downtime.
Note that we’re not juking the stats here by omitting “scheduled” downtime. If you’re a customer and you need a file on Basecamp, do you really care whether we told you that we were going to be offline a couple of days in advance? No you don’t.
While we, and everyone else, strive to be online 100%, we’re still pretty proud of our uptime record. We hope that this level of transparency will force us to do even better in 2012. If we could hit just 4 nines for a start, I’d be really happy.
I hope this encourages others to present their long-term uptime record in an easily digestible format.
Remote working might still be the minority configuration, but there are plenty of enlightened companies around who do get it. Here’s a list of five current positions from our job board:
If you want to post a remote-working position on the job board, please use “Anywhere” as the location. We’ll highlight these positions again in a few weeks.
Every day I read a new article about some company whining about how hard it is to hire technical staff. Invariably it turns out that they’re only looking for people within a commuters distance of their office. I refuse to feel sorry for such companies.
If we were only trying to hire in Chicago, we’d never have the world-class team we have today. 37signals has people from such distinct tech hubs as Fenwick (Canada), Phoenix, Caldwell (Idaho), Romiley (UK), Jefferson Hills (Pensylvania), Ann Arbor (Michigan), Boulder (Colorado), Tampa (Florida).
The technology to successfully run and manage remote teams has never been better. We use Basecamp to keep track of our projects, Campfire as the virtual water cooler, Skype for calls and screensharing, and iChat and email to top it off.
None of it is fancy, expensive, or hard to use. Everything we do to manage a business consisting mainly of remote employees is something anyone else could do too. There’s so much untapped tech talent that does not live near your office, but would work for you if you allowed them to.
So stop whining, spend a day to get up to speed on remote working practices, and hire outside of your commuter zone.
If you want to reach peak performance, you have to find the limit. Finding the limit means stepping over the limit. Going too far, going too fast. It means taking a good idea to the extreme to learn just how far it’ll bend before it snaps.
In racing, the driver who can most consistently drive just beyond the limit — running the optimal seven degrees of slip — is most likely to win. The same applies in business.
When you continously seek out the limit, you’ll realize that it’s often much higher than you expected. Yes, you can make that screen even simpler than the bare-boned version you’re looking at. Yes, you can trust your employees much more than you imagined. Yes, you can launch without a billing system.
Once you train yourself to seek out the limit in all endeavors, you’ll get better and faster at correcting the inevitable oversteps, and hit that peak performance.
But if you never dare venture close to the limit, you’ll find that it’s shrinking all the time. There will be even more people you could possibly offend, even more bells that need whistling, ever more realities of the real world you cannot change.
Records are set by the people who said fuck your limits and found their own.
Nick Quaranto joins 37signals as our eighth programmer today after impressing everyone during his trial month. Nick is not only a manager of one, but also eager to leave everything better than he found it. That’s a valuable instinct when you’re working with applications old enough to talk back!
Nick’s work on creating the modern-day rubygems.org was certainly no minus either. I’m constantly amazed at how easy it now is to create, distribute, and update Ruby libraries and frameworks through the gem system. It almost feels like cheating after living through a former era of zip files, rubyforge, and other more manual approaches.
So we welcome Nick to our small troupe of programmers and hope he’ll stay long. He’ll be in great company. Sam Stephenson just celebrated his sixth birthday with 37signals today. Jamis Buck has been here for close to seven years. Jeremy Kemper for almost five years. As a company, we’re in this for the next twenty years and beyond, so it’s wonderful to have a crew to grow old together with.
If I hear one more Silicon Valley type gush over a computer science graduate from CMU, MIT, or Stanford, I’m going to puke. Yes, yes, I’m sure these are mighty dandy nice schools, but you’re letting the stench of superiority and shallow whiff of superficial judgement pollute my airways.
The fantastic thing about programmers is that we don’t have to give a fuck about where they were trained because we have something much better available: We can look at what they actually do! We don’t need the indirection of pedigree to guess at their skills, we can look at their code and know it.
Here’s a list of the top tier schools that helped shape the fine band of programmers we employ at 37signals:
- Lawrence University
- Rochester Institute of Technology
- Brock University
- Washtenaw Community College
- California Institute of Technology
- Copenhagen Business School
- Brigham Young University
“Can you ask Sam about that? Stacker is his domain”, “I’d rather let Josh look at the router, he wrote it”, “Jon is better versed in associations, send it to him”.
The natural progression of programs is towards the territorial. When a programmer has weaved an intricate web of considerable complexity, others are loathe to enter his lair and he is loathe for them to do so.
This is despite the fact that we all agree that it’s bad for programs to become territorial. When only one or a few people know how to work on something, you get bottlenecks where progress is stunted until the master is ready. You risk the hit-by-a-bus factor where nobody knows how the system works if the master leaves. You ensure the annoyance of stakeholders who can’t understand why another minion can’t fix his urgent problem.
But this problem can’t be solved with a slogan. You can proclaim that “we shouldn’t have territorial parts of our program” until you turn blue, but nothing is going to change until you accept the cost of avoidance.
The first step of acceptance is to recognize that sending someone fresh in to fix a single issue in a complex part of the code is expensive. It’s going to take Pratik five to ten times the effort to fix a single issue in Stacker that it’s going to take Sam. And the odds are that even that is not enough to appreciate the internal coherency of the system, which means that the fix is likely to be a butcher’s job, and Sam will have to rewrite it afterwards anyway.
To broaden the base of knowledge, you’re going to have to let someone else not only spend considerable effort getting up to speed. Then you’re going to have them deal with more than just a quick fix. Let them deal with a raft of issues and let them spend the time of the original creator to learn it all.
To do all that, they can’t do anything else at the same time. That feature you want do is now going to be pushed a few days or a a week out. Until you’re ready to delay things you really want done, it’s fruitless to bemoan that parts of the code base territorial.
