Coding Horror

What was Microsoft's original mission?

In 1975, Gates and Allen form a partnership called Microsoft. Like most startups, Microsoft begins small, but has a huge vision – a computer on every desktop and in every home.

The existential crisis facing Microsoft is that they achieved their mission years ago, at least as far as the developed world is concerned. When was the last time you saw a desktop or a home without a computer? 2001? 2005? We're long since past the point where Microsoft's original BHAG was met, and even exceeded. PCs are absolutely ubiquitous. When you wake up one day to discover that you've completely conquered the world … what comes next?

Apparently, the Post PC era.

Microsoft never seemed to recover from the shock of achieving their original 1975 goal. Or perhaps they thought that they hadn't quite achieved it, that there would always be some new frontier for PCs to conquer. But Steve Jobs certainly saw the Post PC era looming as far back as 1996:

The desktop computer industry is dead. Innovation has virtually ceased. Microsoft dominates with very little innovation. That's over. Apple lost. The desktop market has entered the dark ages, and it's going to be in the dark ages for the next 10 years, or certainly for the rest of this decade.

If I were running Apple, I would milk the Macintosh for all it's worth – and get busy on the next great thing. The PC wars are over. Done. Microsoft won a long time ago.

What's more, Jobs did something about it. Apple is arguably the biggest (and in terms of financials, now literally the biggest) enemy of general purpose computing with the iPhone and iPad. These days, their own general purpose Mac operating system, OS X, largely plays second fiddle to the iOS juggernaut powering the iPhone and iPad.

Here's why:

The slope of this graph is the whole story. The complicated general purpose computers are at the bottom, and the simpler specialized computers are at the top.

I'm incredibly conflicted, because as much as I love the do-anything computer …

• I'm not sure that many people in the world truly need a general purpose computer that can do anything and install any kind of software. Simply meeting the core needs of browsing the web and email and maybe a few other basic things covers a lot of people.
• I believe the kitchen-sink-itis baked into the general purpose computing foundations of PCs, Macs, and Unix make them fundamentally incompatible with our brave new Post PC world. Updates. Toolbars. Service Packs. Settings. Anti-virus. Filesystems. Control panels. All the stuff you hate when your Mom calls you for tech support? It's deeply embedded into of the culture and design of every single general purpose computer. Doing potentially "anything" comes at a steep cost in complexity.
• Very, very small PCs – the kind you could fit in your pocket – are starting to have the same amount of computing grunt as a high end desktop PC of, say, 5 years ago. And that was plenty, even back then, for a relatively inefficient general purpose operating system.

But the primary wake up call, at least for me, is that the new iPad finally delivered an innovation that general purpose computing has been waiting on for thirty years: a truly high resolution display at a reasonable size and price. In 2007 I asked where all the high resolution displays were. Turns out, they're only on phones and tablets.

That's why I didn't just buy the iPad 3 (sorry, The New iPad). I bought two of them. And I reserve the right to buy more!

iPad 3 reviews that complain "all they did was improve the display" are clueless bordering on stupidity. Tablets are pretty much by definition all display; nothing is more fundamental to the tablet experience than the quality of the display. These are the first iPads I've ever owned (and I'd argue, the first worth owning), and the display is as sublime as I always hoped it would be. The resolution and clarity are astounding, a joy to read on, and give me hope that one day we could potentially achieve near print resolution in computing. The new iPad screen is everything I've always wanted on my desktops and laptops for the last 5 years, but I could never get.

Don't take my word for it. Consider what screen reading pioneer, and inventor of ClearType, Bill Hill has to say about it:

The 3rd Generation iPad has a display resolution of 264ppi. And still retains a ten-hour battery life (9 hours with wireless on). Make no mistake. That much resolution is stunning. To see it on a mainstream device like the iPad - rather than a $13,000 exotic monitor - is truly amazing, and something I've been waiting more than a decade to see.

It will set a bar for future resolution that every other manufacturer of devices and PCs will have to jump.

And the display calibration experts at DisplayMate have the measurements and metrics to back these claims up, too:

… the new iPad’s picture quality, color accuracy, and gray scale are not only much better than any other Tablet or Smartphone, it’s also much better than most HDTVs, laptops, and monitors. In fact with some minor calibration tweaks the new iPad would qualify as a studio reference monitor.

Granted, this is happening on tiny 4" and 10" screens first due to sheer economics. It will take time for it to trickle up. I shudder to think what a 24 or 27 inch display using the same technology as the current iPad would cost right now. But until the iPhone and iPad, near as I can tell, nobody else was even trying to improve resolution on computer displays – even though all the existing HCI research tells us that higher resolution displays are a deep fundamental improvement in computing.

At Stack Exchange, we insist that people who ask questions put some effort into their question, and we're kind of jerks about it. That is, when you set out to ask a question, you should …

• Describe what's happening in sufficient detail that we can follow along. Provide the necessary background for us to understand what's going on, even if we aren't experts in your particular area.
• Tell us why you need to know the answer. What led you here? Is it idle curiosity or is this somehow blocking you on a project? We don't need your whole life story, just give us some context here.
• Share your research on your problem; what have you found so far? Why didn't it work? And if you didn't do any research … should you even be asking? If you're inviting us to spend our valuable time helping you, it's only fair that you put in a reasonable amount of your valuable time into crafting a decent question. Help us help you!

We have a great How to Ask page that explains all of this, which is linked generously throughout the network. (And on Stack Overflow, due to massive question volume, we actually force new users to click through that page before asking their first question. You can see this yourself by asking a question as a new user.)

What we're trying to prevent, most of all, is the unanswerable drive-by question. Those help nobody, and left unchecked they can ruin a Q&A site, turning it into a virtual ghost town. On Stack Exchange, questions that are so devoid of information and context that they can't reasonably be answered will be actively closed, and if they aren't improved, eventually deleted.

Like I said, we're kinda jerks about this. But for good reason: we're not-so-subtly trying to help you help yourself, by teaching you Rubber Duck problem solving. And boy does it ever work. I've gotten tons of feedback over the years about how people, in the process of writing up their thorough, detailed question for Stack Overflow or another Stack Exchange site, figured out the answer to their own problem.

It's quite common. See for yourself:

How can I thank the community when I solve my own problems?

I've only posted one question so far, and almost posted another. In both cases, I answered my own questions at least partially while writing it out. I credit the community and the process itself for making me think about the answer. There's nothing explicit in what I'm writing that states quite obviously the answer I needed, but something about writing it down makes me think along extra lines of thought.

Why is it that properly formulating your question often yields you your answer?

I don't know how many times this has happened:

• I have a problem
• I decide to bring it to stack overflow
• I awkwardly write down my question
• I realize that the question doesn't make any sense
• I take 15 minutes to rethink how to ask my question
• I realize that I'm attacking the problem from a wrong direction entirely.
• I start from scratch and find my solution quickly.

Does this happen to you? Sometimes asking the right question seems like half the problem.

Beginning to ask a question actually helps me debug my problem myself

Beginning to ask a question actually helps me debug my problem myself, especially while trying to formulate a coherent and detailed enough question body in order to get decent answers. Has this happened to anybody else before?

It's not a new concept, and every community seems to figure it out on their own given enough time, but "Ask the Duck" is a very powerful problem solving technique.

Bob pointed into a corner of the office. "Over there," he said, "is a duck. I want you to ask that duck your question."

I looked at the duck. It was, in fact, stuffed, and very dead. Even if it had not been dead, it probably would not have been a good source of design information. I looked at Bob. Bob was dead serious. He was also my superior, and I wanted to keep my job.

I awkwardly went to stand next to the duck and bent my head, as if in prayer, to commune with this duck. "What," Bob demanded, "are you doing?"

"I'm asking my question of the duck," I said.

One of Bob's superintendants was in his office. He was grinning like a bastard around his toothpick. "Andy," he said, "I don't want you to pray to the duck. I want you to ask the duck your question."

I licked my lips. "Out loud?" I said.

"Out loud," Bob said firmly.

I cleared my throat. "Duck," I began.

"Its name is Bob Junior," Bob's superintendant supplied. I shot him a dirty look.

"Duck," I continued, "I want to know, when you use a clevis hanger, what keeps the sprinkler pipe from jumping out of the clevis when the head discharges, causing the pipe to..."

In the middle of asking the duck my question, the answer hit me. The clevis hanger is suspended from the structure above by a length of all-thread rod. If the pipe-fitter cuts the all-thread rod such that it butts up against the top of the pipe, it essentially will hold the pipe in the hanger and keep it from bucking.

I turned to look at Bob. Bob was nodding. "You know, don't you," he said.

"You run the all-thread rod to the top of the pipe," I said.

"That's right," said Bob. "Next time you have a question, I want you to come in here and ask the duck, not me. Ask it out loud. If you still don't know the answer, then you can ask me."

"Okay," I said, and got back to work.

I love this particular story because it makes it crystal clear how the critical part of rubber duck problem solving is to totally commit to asking a thorough, detailed question of this imaginary person or inanimate object. Yes, even if you end up throwing the question away because you eventually realize that you made some dumb mistake. The effort of walking an imaginary someone through your problem, step by step and in some detail, is what will often lead you to your answer. If you aren't willing to put the effort into fully explaining the problem and how you've attacked it, you can't reap the benefits of thinking deeply about your own problem before you ask others to.

If you don't have a coding buddy (but you totally should), you can leverage the Rubber Duck problem solving technique to figure out problems all by yourself, or with the benefit of the greater Internet community. Even if you don't get the answer you wanted, forcing yourself to fully explain your problem – ideally in writing – will frequently lead to new insights and discoveries.

There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.

1. First, pass a few simple "Hello World" online tests.

I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable.

That's why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it's sad and kind of depressing that this is even necessary, but if you don't perform this sanity check, trust me – you'll be sorry.

Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.

2. Ask to see their portfolio.

Any programmer worth their salt should have a portfolio of the things they've worked on. It doesn't have to be fancy. I'm just looking for a basic breadcrumb trail of your awesomeness that you've left on the Internet to help others. Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff. Got a professional blog? A tumblr? A twitter? Some other word I've never heard of? Excellent, let's have a look. Share applications you've designed, or websites you worked on, and describe what parts were yours.

Just seeing what kind of work people have done, and what sort of online artifacts they've created, is tremendously helpful in getting a sense of what people do and what they're good (or bad) at.

3. Hire for cultural fit.

Like GitHub, I find that cultural fit is often a stronger predictor of success than mad programming chops.

We talk about [philosophy] during the hiring process, which we take very seriously. We want any potential GitHubber to know what they’re getting into and ensure it’s a good fit. Part of that is having dinner and talking about stuff like the culture, philosophy, mistakes we’ve made, plans, whatever.

Early on we made a few hires for their skills with little regard to how they’d fit into the culture of the company or if they understood the philosophy. Naturally, those hires didn’t work out. So while we care about the skills of a potential employees, whether or not they “get” us is a major part too.

I realize that not every business has a community around what they do, but if you do have a community you should try like hell to hire from your community whenever possible. These are the folks who were naturally drawn to what you do, that were pulled into the gravitational well of your company completely of their own accord. The odds of these candidates being a good cultural fit are abnormally high. That's what you want!

Did a few of your users build an amazing mod for your game? Did they find an obscure security vulnerability and try to tell you about it? Hire these people immediately!

4. Do a detailed, structured phone screen.

Once you've worked through the above, it's time to give the candidate a call. Bear in mind that the phone screen is not for chatting, it's for screening. The call should be technical and structured, so both of you can get out immediately if it clearly isn't a fit. Getting the Interview Phone Screen Right covers the basics, but in summary:

1. A bit of on-the-fly coding. "Find the largest int value in an int array."
2. Some basic design. "Design a representation to model HTML."
3. Scripting and regular expressions. "Give me a list of the text files in this directory that contain phone numbers in a specific format."
4. Data structures. "When would you use a hashtable versus an array?"
5. Bits and bytes. "Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny?"

What you're looking for is not magical perfect answers, necessarily, but some context into how this person solves problems, and whether they know their stuff (plus or minus 10 percent). The goal is to make sure that the candidates that do make it to the next step are not wasting their time or yours. So don't be shy about sticking to your guns and ending the call early if there are too many warning flags.

5. Give them an audition project.

So the candidate breezed through the hello world programming tests, has an amazing portfolio, is an excellent cultural fit, and also passed the phone screen with flying colors. Time to get them in for a face-to-face interview, right? Not so fast there cowboy!

I've seen candidates nail all of the above, join the company, and utterly fail to Get Things Done. Have I mentioned that hiring programmers is hard?

If you want to determine beyond the shadow of a doubt if someone's going to be a great hire, give them an audition project. I'm not talking about a generic, abstract programming problem, I'm talking about a real world, honest-to-God unit of work that you need done right now today on your actual product. Something you would give to a current employee, if they weren't all busy, y'know, doing other stuff.

This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement. Select a small project that can ideally be done in a few days, maybe at most a week or two. Either the candidate can come in to the office, or they can work remotely. I know not every business has these bite-sized units of work that they can slice off for someone outside the company – but trying desperately to make it inside the company – to take on. I'd argue that if you can't think of any way to make an audition mini-project work for a strong hiring candidate, perhaps you're not structuring the work properly for your existing employees, either.

If the audition project is a success, fantastic – you now have a highly qualified candidate that can provably Get Things Done, and you've accomplished something that needed doing. To date, I have never seen a candidate who passes the audition project fail to work out. I weigh performance on the audition project heavily; it's as close as you can get to actually working the job without being hired. And if the audition project doesn't work out, well, consider the cost of this little consulting gig a cheap exit fee compared to an extensive interview process with 4 or 5 other people at your company. Worst case, you can pass off the audition project to the next strong candidate.

(A probationary period of conditional employment can also work, and is conceptually quite similar. You could hire with a 6-8 week review "go or no go" decision everyone agrees to in advance.)

6. Get in a room with us and pitch.

Finally, you should meet candidates face-to-face at some point. It's inevitable, but the point of the earlier steps is that you should be 95% certain that a candidate would be a great hire before they ever set foot in an interview room.

I'm far from an expert on in person interviews, but I don't like interview puzzle questions, to put it mildly.

Instead, I have my own theory about how we should interview programmers: have the candidate give a 15 minute presentation on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you'll quickly ascertain …

• Is this person passionate about what they are doing?
• Can they communicate effectively to a small group?
• Do they have a good handle on their area of expertise?
• Would your team enjoy working with this person?

The one thing every programmer should know, per Steve Yegge, is how to market yourself, your code, and your project. I wholeheartedly agree. Now pitch me!

7. None of this is guaranteed.

Please take this list at face value. I've seen these techniques work, and I've occasionally seen them not work. Adapt this advice to your your particular situation, keep what you think makes sense, and ignore the rest (although I'd strongly advise you to never, ever skip step #1). Even in the best of circumstances, hiring human beings is hard. A job opportunity may not work out for reasons far beyond anyone's control. People are, as they say, complicated.

If you think of work as a relationship, one you'll spend 40 hours a week (or more) in the rest of your life, it behooves everyone involved to "date smart". Both the company and the candidate should make a good faith best effort to determine if there's a match. Your goal shouldn't be merely to get a job, or hire someone for a job, but to have fun and create a love connection. Don't rush into anything unless it feels right on both sides.

(as an aside, if you're looking for ways to attract programmers, you can't go wrong with this excellent advice from Samuel Mullen.)

The prevalence of free, open WiFi has made it rather easy for a WiFi eavesdropper to steal your identity cookie for the websites you visit while you're connected to that WiFi access point. This is something I talked about in Breaking the Web's Cookie Jar. It's difficult to fix without making major changes to the web's infrastructure.

In the year since I wrote that, a number of major websites have "solved" the WiFi eavesdropping problem by either making encrypted HTTPS web traffic an account option or mandatory for all logged in users.

For example, I just noticed that Twitter, transparently to me and presumably all other Twitter users, switched to an encrypted web connection by default. You can tell because most modern browsers show the address bar in green when the connection is encrypted.

I initially resisted this as overkill, except for obvious targets like email (the skeleton key to all your online logins) and banking.

Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution. I'd rather see a better, more secure identity protocol than ye olde HTTP cookies. I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret. But gee, I sure do care if they somehow sniff out my cookie and start running around doing stuff as me! Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.

Of course, there's no reason to encrypt traffic for anonymous, not-logged-in users, and Twitter doesn't. You get a plain old HTTP connection until you log in, at which point they automatically switch to HTTPS encryption. Makes sense.

It was totally painless for me, as a user, and it makes stealing my Twitter identity, or eavesdropping on my Twitter activity (as fascinating as I know that must sound), dramatically more difficult. I can't really construct a credible argument against doing this, even for something as relatively trivial as my Twitter account, and it has some definite benefits. So perhaps Twitter has the right idea here; maybe encrypted connections should be the default for all web sites. As tinfoil hat as this seemed to me a year ago, now I'm wondering if that might actually be the right thing to do for the long-term health of the overall web, too.

Why not boil the sea, then? Let us encrypt all the things!

HTTPS isn't (that) expensive any more

Yes, in the hoary old days of the 1999 web, HTTPS was quite computationally expensive. But thanks to 13 years of Moore's Law, that's no longer the case. It's still more work to set up, yes, but consider the real world case of GMail:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

HTTPS means The Man can't spy on your Internet

Since all the traffic between you and the websites you log in to would now be encrypted, the ability of nefarious evildoers to either …

• steal your identity cookie
• peek at what you're doing
• see what you've typed
• interfere with the content you send and receive

… is, if not completely eliminated, drastically limited. Regardless of whether you're on open public WiFi or not.

Personally, I don't care too much if people see what I'm doing online since the whole point of a lot of what I do is to … let people see what I'm doing online. But I certainly don't subscribe to the dangerous idea that "only criminals have things to hide"; everyone deserves the right to personal privacy. And there are lots of repressive governments out there who wouldn't hesitate at the chance to spy on what their citizens do online, or worse. Much, much worse. Why not improve the Internet for all of them at once?

HTTPS goes faster now

Security always comes at a cost, and encrypting a web connection is no different. HTTPS is going to be inevitably slower than a regular HTTP connection. But how much slower? It used to be that encrypted content wouldn't be cached in some browsers, but that's no longer true. And Google's SPDY protocol, intended as a drop-in replacement for HTTP, even goes so far as to bake encryption in by default, and not just for better performance:

[It is a specific technical goal of SPDY to] make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.

There's also SSL False Start which requires a modern browser, but reduces the painful latency inherent in the expensive, but necessary, handshaking required to get encryption going. SSL encryption of HTTP will never be free, exactly, but it's certainly a lot faster than it used to be, and getting faster every year.

Bolting on encryption for logged-in users is by no means an easy thing to accomplish, particularly on large, established websites. You won't see me out there berating every public website for not offering encrypted connections yesterday because I know how much work it takes, and how much additional complexity it can add to an already busy team. Even though HTTPS is way easier now than it was even a few years ago, there are still plenty of tough gotchas: proxy caching, for example, becomes vastly harder when the proxies can no longer "see" what the encrypted traffic they are proxying is doing. Most sites these days are a broad mashup of content from different sources, and technically all of them need to be on HTTPS for a properly encrypted connection. Relatively underpowered and weakly connected mobile devices will pay a much steeper penalty, too.

Maybe not tomorrow, maybe not next year, but over the medium to long term, adopting encrypted web connections as a standard for logged-in users is the healthiest direction for the future of the web. We need to work toward making HTTPS easier, faster, and most of all, the default for logged in users.

How many meetings did you have today? This week? This month?

Now ask yourself how many of those meetings were worthwhile, versus the work that you could have accomplished in that same time.

This might lead one to wonder why we even have meetings at all.

At GitHub we don't have meetings. We don't have set work hours or even work days. We don't keep track of vacation or sick days. We don't have managers or an org chart. We don't have a dress code. We don't have expense account audits or an HR department.

Now, I'm sure Tom was being facetious when he said that GitHub doesn't have meetings, because I sure as heck saw meeting rooms when I recently visited their offices to give a talk. Who knows, maybe they use them to store all the extra forks.

Although some meetings are inevitable, even necessary, the principle he's advocating here is an important one. Meetings should be viewed skeptically from the outset, as risks to productivity. We have meetings because we think we need them, but all too often, meetings are where work ends up going to die. I have a handful of principles that I employ to keep my meetings useful:

1. No meeting should ever be more than an hour, under penalty of death.
   

   The first and most important constraint on any meeting is the most precious imaginable resource at any company: time. If you can't fit your meeting in about an hour, there is something deeply wrong with it, and you should fix that first. Either it involves too many people, the scope of the meeting is too broad, or there's a general lack of focus necessary to keep the meeting on track. I challenge anyone to remember anything that happens in a multi-hour meeting. When all else fails, please keep it short!

2. Every meeting should have a clearly defined mission statement.
   

   What's the mission statement of your meeting? Can you define the purpose of your meeting in a single succinct sentence? I hesitate to recommend having an "agenda" and "agenda items" because the word agenda implies a giant, tedious bulleted list of things to cover. Just make sure the purpose of the meeting is clear to everyone; the rest will take care of itself.

3. Do your homework before the meeting.
   

   Since your meeting has a clearly defined mission statement, everyone attending the meeting knows in advance what they need to talk about and share, and has it ready to go before they walk into the room. Right? That's how we can keep the meeting down to an hour. If you haven't done your homework, you shouldn't be in the meeting. If nobody has done their homework, the meeting should be cancelled.

4. Make it optional.
   

   "Mandatory" meetings are a cop-out. Everyone in the meeting should be there because they want to be there, or they need to be there. One sure way to keep yourself accountable for a meeting is to make everyone optional. Imagine holding a meeting that people actually wanted to attend, because it was … useful. Or interesting. Or entertaining. Now make it happen!

5. Summarize to-dos at the end of the meeting.
   

   If your meeting never happened, what would the consequences be? If the honest answer to that is almost nothing, then perhaps your meeting has no reason to exist. Any truly productive meeting causes stuff to happen as a direct result of the decisions made in that meeting. You, as a responsible meeting participant, are responsible for keeping track of what you need to do – and everyone in the room can prove it by summarizing their to-do list for everyone's benefit before they leave the meeting.

It's not that we shouldn't have meetings, but rather, we need to recognize the inherent risks of meetings and strive to make the (hopefully) few meetings we do have productive ones. Let's work fast, minimize BS, and get to the point.