Everyone's favorite sarcastic talking pushpin asked an honest question about the state of the web:

From the outside, front end development in 2017 looks pathologically overcomplicated. Is this a fair perception? If so, why is it happening?

— Pinboard (@Pinboard) May 21, 2017

I replied with a tweetstorm. Here it is as a slightly more readable blog post on my ancient, creaky blog.

The replies to Maciej's tweet are interesting to read. They fall roughly into two camps:

1. Older/not front-end developers: because the web is shit!
2. Current front-end developers: because shit is hard!

As is often the case, both camps are correct! The web is a shitshow of wheel reinvention and bad APIs. It's also a blizzard of innovation.

Expectations for what a web site should be able to do have evolved enormously. Users expect snappy, desktop-like responsiveness and rich presentation in web apps. They also expect those same web apps to work equally well on mobile devices. And they expect these apps to load basically instantly. As Tom Dale says, that's actually a harder problem than desktop or mobile apps face. Users expect to download and install those types of apps before they will run.

Devs must meet these high expectations, but they have no more time and no more co-workers than they did before, and they still have to ship just as fast. To meet this requirement, they are throwing ever larger combinations of frameworks, boilerplate code, tools and build chains at the problem. The result is a lot of complexity and it's frequently frustrating.

The web as a platform, as ever, lags behind its developers. They want ES6 syntax, they want modular JavaScript, modular CSS and modular HTML. Browsers provide none of these things, so they are hacked together in frameworks.

Devs aren't adopting all this new tech just because it's new and fun (though it's a bad idea to dismiss fun as a valuable quality in a development tool). They are doing it because they have to in order to survive.

Modern web dev has the complexity of, say, the native mobile ecosystem, but no single vendor or consensus build chain or tools. iOS and Android have compilers and long build steps and dozens of competing frameworks, but nobody complains that these things are unnecessary. But they do for the web, because the web didn't need them before. (And if you're okay with throwing together a simple, 2000s-era web page, they're still not. But few users are happy with those any more.)

Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that's silly and unnecessary. But so what? The misuse of technology does not invalidate it.

Over the next 5 years I expect there will be a lot of consolidation in technologies and in tools. A lot of the stuff web devs are currently constructing using frameworks will be adopted as first-class citizens, built into browsers. Because the web has a lot of inertia, people will keep using these tool chains longer than they need to, much as web devs still use jQuery even though mosts of its API is part of browsers natively now.

jQuery is an instructive example: jQuery was a reaction to a terrible API and a lack of raw functionality in the web at the time. It changed the web for the better, forever, by showing browser makers what devs needed, and how it should work. It was a huge success, and its ultimate success is that it made itself unnecessary.

Webpack, babel, react, and the cambrian explosion going on in that ecosystem will do the same thing again. All of these frameworks and tools are devs experimenting, seeing where they want the web to go.

jQuery was a performance problem at scale, and sometimes over- or mis-applied, or used superfluously by newbies who didn't know there was a simpler way. Big deal.

Modern front-end devs are repeating the same mistakes: these new frameworks often create shocking performance hits. Sometimes we over-use them. Sometime we mis-use them. But the web is evolving, and evolution is by nature slow and messy. And the results are already amazing.

Is modern web development fearsomely, intimidatingly complicated? Yes, and that's a problem. Will we make it simpler? Definitely, but probably not as soon as you'd like. Is all this new complexity worthwhile? Absolutely.

The web's amazing capacity to reinvent itself, to evolve and adapt to new needs is its strength as a platform. Things that don't adapt die or are replaced. Nobody is talking about the death of the web. Nobody is demanding it be replaced. If anything they're pleading for it to slow down a bit, and let them catch up. That's a sign of a healthy platform, an innovative platform. The web was like that in 1996 and it's still like that, and that's amazing.

Nobody but nobody loves the web more than I do. It's my baby. And like a child, it's frustrating to watch it struggle and make mistakes. But it's amazing to watch it grow up.

It's a question on the minds of all right-thinking Americans, and on mine. I don't claim to be a political genius, or that this is the right solution or the only solution. But here's what I've got so far; tell me what you think.

First, to defeat Donald Trump you must make him unpopular. His popularity is what elected him, but more importantly it is what drives him. An unpopular Donald Trump will melt down and quit, humiliated. That's what we want. We need "being the next Donald Trump" to be an ignominious fate. We want Donald to never run again, and we want any Donald-shaped monster in future to be terrified of the possibility.

To work out how to make him unpopular, we must understand what made him popular in the first place. To do this, we must look beyond our liberal peers, with whom he is already maximally unpopular, as widespread demonstrations have indicated.

Here's what Donald Trump supporters believe about him (however incorrectly) that they like:

• he is not part of the establishment
• he is not as corrupt as most politicians
• he is secretly racist, just like them, and will look out for white people
• he's a strong man who will keep them safe

Anything about economic insecurity and not listening to the concerns of rural voters or the working class is bullshit. Poor people did not vote for Trump (his voters earn above the median wage, unlike Hillary). There are also plenty of rural voters who went for Hillary, and plenty of city dwellers who voted for Trump.

So to defeat Trump, we must make him look highly corrupt, part of the establishment, unwilling or unable to privilege white people over other people, and weak. The first two are easy, the second two more challenging.

Part of the establishment

It's easy to make Trump look like part of the establishment because he is part of the establishment. He is the damn president. Everything bad that the government does, whether or not he had anything to do with it, can and should be tied to him. Every slip in the economy, every problem with healthcare, every sparrow that falls from a tree should be loudly attributed to Donald's mismanagement. Republicans got really good at this and so should we. We can also point to his appointments of CEOs of Exxon, Goldman Sachs and other very-much-establishment companies to important posts.

Corrupt

Making him look more corrupt than most politicians is trivial because he is shockingly corrupt. His casino deals, his mafia ties, his many bankruptcies, Trump University, and repeatedly welching on debts to contractors establish him easily as a cheat, a liar and a crook. His base seemed to overlook or ignore these things as "tough negotiation" or something but we can keep dredging up more tales of his thievery basically forever.

Not racist?

Making him look like he's not secretly racist is very tricky because he is openly racist. He has repeatedly said he believes his superior genes guarantee his success, and that's before you get to his many obviously racist acts, from refusing to rent houses to black people, to failing to condemn the KKK, to demonizing Mexicans and Muslims (neither of which is a race, but racists aren't very bright).

To make Trump look un-racist will not work. What we can do is make him look powerless to act on that. Here we've already seen the most action: protests on the Muslim ban and swift legal action have halted it and may overturn it entirely. Protests against his border wall will likewise do so, and legal or legislative action should come there too. Making him look powerless to enact racist policy, however, is just part of the bigger play: make him look weak.

Weak

Because by far what people responded to in Trump is his strong man persona. He claimed he could do anything, fix anything, build anything, and it would all be great, the best, yuge, people would love it. His supporters bought these empty boasts as promises, so we have to puncture the idea that he can get anything done.

We have to be careful though. If the obstruction appears to come from outside -- from filibusters and other legislative hacks, from well-meaning heroics by democratic appointees, from "the establishment" -- then we bolster his support rather than erode it. Instead it needs to come from within, and here we are aided by Trump's stupidity and incompetence. His failure to negotiate trade deals, his inability to fund the wall, his botched attempt to ban Muslims, his failure to deport illegal immigrants: these are or will soon be his failures, and we can amplify them. This house of cards will collapse on its own, but we need to make sure it falls our way.

The other way to make him not just look weak but really become weaker is to peel off his inner circle one by one. The loathsome, openly racist and anti-semitic Bannon has already overstepped several times, to Trump's displeasure. By amplifying Trump's sense that he is being manipulated and overshadowed, we can use Trump's own ego to get Bannon ejected or diminished.

The repugnant Kellyanne Conway, with her "alternative facts" and imaginary terrorist attacks, is also faring badly in the spotlight. In any other administration her repeated, obvious lies would have already had her fired. In the Trump administration what will get her fired is if news organizations refuse to interview her anymore because her every word is openly mocked. If she doesn't get to speak on television, her power and her value to the administration will fail and she will be discarded after one lie too many. Sean Spicer will suffer a similar fate, perhaps even sooner.

Next steps

What can we do? We can amplify. Every failure must be trumpeted, every policy overturned, every decision nullified by protest or local action. His inner circle must be hounded until they become political liabilities, leaving Trump isolated and impotent. But be selective: don't amplify things that make liberals angry (you'll exhaust yourself, everything he does makes liberals angry). Amplify things that make him look stupid, make him look inept, make him look corrupt and compromised by establishment ties. And above all, make him look weak. If we can persuade his base to abandon him, he will not last as president.

Nolan Lawson has written a great piece about progressive enhancement that brings up some fascinating points. An over-simplified summary would be: progressive enhancement doesn't mean it works without JavaScript, it means it works without network. As a web developer of the oldest possible school, it's interesting to me that the most vociferous objections to his position seemed to be coming from similarly old-school devs (that was a totally subjective impression and might be wrong).

Offline-first is great for web apps

Right off the bat, I think it's important to acknowledge that I think a single-page application that works offline in 2016 is definitely doing more useful for its users than that same application rendering entirely without JavaScript. That seems to be where Nolan is coming from, and as far as it goes I agree. But I think early on he dismissed another interpretation that is equally important.

He mentions, briefly:

Paul Lewis is a big fan of progressive rendering for performance reasons

But it seems to me this conflates two very different use-cases that we should consider separately:

1. A single page web app (an "app" from here on)
2. A website that consists of multiple pages (a "site" from here on)

Not everything on the web is an app

The generational disconnect I mentioned earlier seems to be coming from the fact that web developers are in two groups, with different "default" ways of thinking about web development. The first group, who turned up in the past 5 or maybe even 10 years, think of it as application development with the web as a medium. The second group, which includes myself, who started 20 years ago think of it as building a set of discrete pages. Obviously, both groups can and do build both types.

Progressive rendering isn't very useful for apps

If you are developing an app, the user ideally loads the app exactly once -- whether it's over a slow connection or not. Whether or not it's bootstrapped, they take the hit of activating the JavaScript one time, and then the app works. Given that the app is complicated and probably takes a while to load, optimizing for app caching and an offline experience is definitely worth the trouble. A single page app probably doesn't have any good use case for JavaScript turned off, because an application without JavaScript cannot really be interactive, and another name for a non-interactive application is "broken". Progressive rendering doesn't really make any sense. This was Nolan's point and I'm on board.

But if you are developing a web site consisting of many discrete pages, the act of loading goes from a single event to the most common event. Content sites of all kinds -- news, entertainment, whatever -- and lots of e-commerce applications are, and for good reasons probably will always be, page-based rather than applications. These types of sites can have a great JavaScript-less experience: it's easy to read an article with JavaScript turned off, and you can click a "buy it now" button without JavaScript as long as it's a real button.

Progressive rendering is essential for sites

In a web app, a user has exactly one chance to experience a catastrophic loading error -- getting their connection cut off mid-load, say, or a JavaScript error completely torching all other scripts on the page. Somebody who experiences this will reload and get on with things, probably. You want to minimize the chances of it happening, but it's not really very common in the first place, so you can probably dismiss it.

On a multi-page web site, on the contrary, the number of chances users have to experience a catastrophic loading error rises by orders of magnitude. In fact, it's almost guaranteed in a world of mobile connections that your users will experience half-loaded pages, and on ad-supported content sites, crappy ads will break your scripts another big chunk of the time. In this situation, optimizing for progressive rendering is an obvious imperative: the JavaScript-less case is both useful, and guaranteed to happen.

Long live web development, in every flavor

As I argue every time I give my Stuff Everybody Knows talk, web development is not a competition between single page web apps and multi-page web sites. Neither is going to "win". There will always be both kinds of web experiences, and what counts as "graceful degradation" is very different depending which one you're building.

Nobody's arguing that graceful degradation is a bad policy, merely what it looks like, and I think these widely diverged use-cases is the source of the disagreement. In fact, as I mentioned on Twitter early this month, web app development and web site development are so different now that they probably shouldn't be called the same thing anymore. Both types of developers are web developers, but you should probably specify which flavor you're talking about. Web app development and web site development (pick your own terminology if you don't like mine, just make it unambiguous) are so different now that rules from one flavor almost never apply to the other.

A combination of events at Reddit and LGBTQ in Tech Slack spurred me into a tweet storm about online spaces:

The tragedy of all online community spaces is that the goals of "inclusive" and "safe" are, at the extreme, mutually exclusive goals.

— Laurie Voss (@seldo) July 13, 2015

If you keep including people you will eventually end up with people in the same space who cannot stand each other and will not get along.

— Laurie Voss (@seldo) July 13, 2015

At some point you have to exclude someone. You get to pick if it's the people feeling unsafe, or the people making them feel unsafe.

— Laurie Voss (@seldo) July 13, 2015

And *that's not always an obvious choice*. Somebody's "reasonable topic of discussion" is *always*, eventually, somebody's threat trigger.

— Laurie Voss (@seldo) July 13, 2015

I've run online communities for 20 years and I have learned that there is not even an approximation of a consensus of "reasonable".

— Laurie Voss (@seldo) July 13, 2015

This is why online communities fragment. Let them do it. It's the only viable solution to the existence of mutually incompatible people.

— Laurie Voss (@seldo) July 13, 2015

Define your space clearly. Let in anyone who shares your reality. Be honest that people who don't share it will be excluded. Say why.

— Laurie Voss (@seldo) July 13, 2015

Don't wring your hands about free speech. You are under no obligation to let people say things you hate. They can go elsewhere, and will.

— Laurie Voss (@seldo) July 13, 2015

[Disclaimer: I am writing this from my perspective as npm's CTO, but purely in a personal capacity. It has not been reviewed or approved by anyone at the company, and any questions or complaints about it should be directed at me.]

At npm, we care a lot about workplace diversity.

This statement by itself distinguishes us in no way from the majority of companies, who will all say, if asked, that they value diversity. Of course they do! "Diversity" sounds like one of those nice, cheap, HR sorts of words, like "empowerment" and "transparency", that you can put into your mission statement and be so meaningless as to require no effort whatsoever on your part to live up to. Just another buzzword. The actual level of commitment to diversity, and even the level of understanding what it means to have and support a diverse workplace, vary enormously from company to company.

We started npm, Inc. back in January 2014, and over the last 14 months I feel like I have come a long way as a manager of people and learned a great deal about what it means to really, truly value and support diversity. When I learn things I like to write about them, so that's part of my motivation for this. Another, bigger part of my motivation is intense, unbearable impostor syndrome about my own, and by extension npm's, actual level of success at doing so.

This started when I wrote a blog post comparing diversity at major tech companies, then seriously escalated when I wrote a half-joking rhetorical tweet about a Bechdel test for tech (which, you're right, Ryan, should totally have been called the Techdel test:

Does your project pass the Bechdel test? To pass, a function written by a woman dev must call a function written by another woman dev.

— Laurie Voss (@seldo) February 27, 2015

This then got picked up by the excellent people at 18F, who used it to kick off a much more serious and useful conversation about gender diversity at their organization, and from there to diversity in general. The original tweet has been remarkably long-lived and 18F's post has been picked up by dozens of other sources. It has been extremely gratifying to see an offhand remark of mine, mostly via 18F's amplification, spur so many interesting and useful conversations, but it has also made me feel like a huge fraud.

Here's why: npm has, at present, exactly 11 employees (though we are hiring a bunch more right now). The three founders are all white men (though we managed some diversity in sexuality, having one straight, one gay and one bisexual founder). Of the 8 non-founders, all of whom are engineers of various kinds, we have four women and four men, all but one of whom identify as white, with some additional variation in the LGBT spectrum. This is... fine. It's not great. It's better than a lot of places. It could be much better. It's also far, far too small to be statistically meaningful, so as we grow we could either get much better or significantly worse. The best I can say is that we're doing okay so far, and will continue to try to improve. Hiring diversely is hard, and a great deal has been written about it, and I'm not going to write about it now.

But hiring diversely is merely the first step. You can't just hire a diverse group and then employ standard Silicon Valley workplace culture and expect things to go well. Once you get people in the door you have to make sure the culture values them and helps them perform at their best. And this is another reason why I have been so uncomfortable receiving attention for our own diversity, because in this area we have been even less successful.

Of our eight employees, over 14 months, people have had big enough problems with the workplace environment and their job quality to raise those concerns to their manager (me, in nearly every case) a total of about 20 times (we keep records of the individual meetings, but I haven't collected them for exact stats). From my experience of previous companies, that's actually not bad -- people often run into things that make them unhappy at work, especially at startups where the situation changes rapidly. But what is bad is that of those reports, more than three-quarters were raised by the women.

These problems varied in scope. Some were minor -- we had problems with over-talking, especially during ad-hoc meetings. We were unnecessarily negative in our discussions of third parties and other technologies. A couple of times, I gave credit for a piece of work to a man who worked on a project instead of the woman who actually did the work until I was corrected. More seriously, I gave ineffective feedback in a way that was distinctly gendered. Various members of the team fell victim to gendered expectations on a number of occasions. On two occasions I really majorly fucked up, totally misunderstanding a team member's needs and expectations, making them miserable entirely by accident. Not all of these problems were gender-related, but obviously since women experienced the majority of them, gender bias was at work.

The best, in fact the only, thing that I can say in our defense is: we give a shit. We really do. When these things were brought to our attention, we took them seriously. We made immediate changes. Sometimes they worked and the problem was resolved or at least improved. On some we had to try a couple of times before we found something that worked. On some of them we still haven't found a solution. But we give a shit. We are trying.

Really early on, we talked about what npm's values are, and one of the clearest summaries of them turned up in a tiny paragraph of text that Isaac churned out for our jobs page. It's so good that it has been almost unchanged in 14 months:

npm is not a typical product, and we are not a typical early-stage “work hard/play hard” startup. We are responsible adults with diverse backgrounds and interests, who take our careers and our lives seriously. We believe that the best way to iterate towards success is by taking care of ourselves, our families, our users, and one another. We aim for a sustainable approach to work and life, because that is the best way to maximize long-term speed, while retaining clarity of vision. Compassion is our strategy.

The way you can tell what a company's values are -- as opposed to what they say they are, which are universally the meaningless platitudes I mentioned at the beginning -- is by their actions. In particular, you can tell what a company believes is really important by what it will give up, or pay, to get that thing. At npm we have made real, meaningful sacrifices in terms of speed of development and cash outlay, to ensure that our team works sensible hours, and isn't woken up in the middle of the night for operational issues. We have also made real, tangible sacrifices in speed of hiring to ensure that our applicant pool is diverse, and our interviews as fair as we can possibly make them. We didn't decide things in favor of happiness and diversity vs. cash every single time, but we did it often enough to hurt, and to be sure that yes, we really do value these things enough to bear that hurt. Because we give a shit.

And that's really all you can do. Detecting and compensating for bias is mind-breakingly difficult. You can be totally conscious of your bias and yet still make biased decisions even though you're actively trying to avoid doing so. You can put processes in place to promote fairness but the design of the processes themselves can and will be biased. You can track statistics and set goals but that doesn't make them happen. You can try to cast a wide net for hiring but job postings are more likely to spread via social connections, which means your friends, i.e. people who are already very similar to you. That's not to say you shouldn't try to correct for your bias, and make goals, and put processes in place, and hire widely. of course you should. But it will never be enough. It is a morass. Once you notice bias you suddenly see it everywhere. I spend an inordinate amount of time on my morning commute considering the gender politics of who gets out of my way.

Oh, and what about the Techdel test? Well, until very recently, npm didn't even pass that. Our four women devs are all on different teams (www, registry, cli, and dev relations). While they all lay down a great deal of high-quality code, their functions rarely call each other directly. On our website, Raquel's code now calls a caching library written by CJ, so we squeak by. I'm not beating myself up over this, though. The Techdel test was a rhetorical joke intended to inspire a conversation, not be a genuine measure of quality of participation, and while npm's gender diversity isn't perfect, we are well above the minimum bar that it was the original Bechdel test's aim to set.

Ultimately, npm is a tiny part of the overall picture. Me giving a shit about hiring diversely and working diversely is not going to change Silicon Valley, especially since I get it wrong half the time even though I'm trying really, really hard. But I care, and I really honestly try to do better every day. It's not good enough, but it's not bad, and that's better than most.

You are bad at giving technical interviews. Yes, you. You're looking for the wrong skills, hiring the wrong people, and actively screwing yourself and your company. Without changing anything about your applicant pool, you can hire different people and your company will do better and you will enjoy your job more.

I realize these are bold claims. In the ten years since I became senior enough to be asked to interview people, I have conducted a great number of technical interviews, been part of a lot of teams at companies big and small, and watched the effect that different types of hires have had on those companies. I'm not claiming to be perfect at hiring -- at various points, I have done nearly all of the things wrong that I'm about to tell you not to do. But here's what I've learned so far.

You are looking for the wrong things

Don't hire for what they already know

The primary mistake that people make when interviewing is over-valuing present skills and under-valuing future growth. Don't hire people for what they already know; the pool of people who do exactly the thing you need them to do is much, much smaller than the pool of people who are smart enough to be good at that job.

But even worse is the way we try to determine whether people have these skills. People ask questions in interviews about obscure syntactical features of programming languages, or details of popular APIs. The famous fizzbuzz test simply asks "are you aware of the modulo operator?" If the answer is "no" then they are probably a pretty weak candidate, but it provides exactly 1 bit of data. Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.

Don't hire for what they can remember in an interview room

I used to ask people to write code in interviews. This is terrible. Writing code on a whiteboard is an experience so far removed from the real practice of writing code as to be no predictor. Even writing code on a computer, as part of a pair for instance, tests for the wrong ability -- you are asking them to write code under time pressure, with somebody watching. Some of the best engineers I know would melt under those conditions. And if your belief is that writing code under intense time pressure is part of your job, then you should examine whether that's a problem your company has.

Whiteboard and coding interviews also routinely ask people to re-implement some common solution or low-level data structure. This is the opposite of good engineering. A good engineer will try to maximize productivity by using libraries to solve all but the most novel problems. It's also a poor test: how do you know if somebody is solving the problem or merely remembering somebody else's solution? There is no value to memorizing the details of algorithms you can google in 15 seconds.

Don't hire for a fancy degree

Some people are impressed by academic credentials. Having gone to a good college, or having gone to college at all, are not in my experience good predictors of ability as an engineer. Having a PhD in a relevant field is interesting but also an unreliable predictor: engineers write code and ship software; academics prove theories and write proofs of concept. Somebody smart might be able to do both but it's by no means a given, or even very strongly correlated.

Don't hire for their previous employers

People also over-value brand names on resumes. Don't hire somebody because they worked at a hot company, or a famous one, especially not if that company is big. Variation across teams in big companies is enormous. Just because a company was successful doesn't mean your candidate had anything to do with that. If you are familiar enough with another company's hiring process that you can vouch for it as a good selector of qualified people, you might use that to bump them to the front of an applicant queue, but beyond that, go with what's in front of you.

Don't hire friends and family

And finally, never hire your family and if you can avoid it, don't hire your friends either. Existing relationships create bias and implicit power structures, webs of obligation and loyalty that are at odds with what is best for your company. You will either compromise your friendship or your company, and rather than being forced to pick one or the other, just avoid the conflict entirely.

Here's what you should be looking for instead

Your first stage of interviewing should be attempting to answer two questions:

1. Can they do this job? This is not the same as "can they do this job right now?" but you need to be confident they can learn how to do the job.
2. Are they going to get better at this job? The answer has to be yes.

Relevant experience is a plus but not a requirement

Syntax and API questions are aimed at finding relevant experience but they are bad ways of doing so. Instead, talk about the technology they're going to be working with. Find out how much they know about it. You're not looking to hire or pass on the basis of any individual fact. If they are weak on the skills they need for the job, then find a topic they know a lot about instead, and get them to talk about it, if necessary explaining it to you. You are looking for grasp of complex topics and the ability to clearly communicate about them, which are the two jobs of the working engineer.

Somebody who is constantly improving is a requirement

Much more important than what they know is how they learn it, and how quickly. You are looking for somebody with a track record of learning new skills and applying them successfully. Talk about their career path, and look for evidence of increasing responsibility (which is related to, but not the same as, seniority). Remember that anybody you hire will expect raises every year: somebody who isn't getting better all the time is going to become worse and worse value unless their skills increase in value, too.

Smart and Gets Things Done™

Joel Spolsky's classic essay The Guerilla Guide to Interviewing (and the book that followed it, Smart and Gets Things Done) are some of the smartest things that have ever been written about technical hiring. Smartness is hard to judge, and some of the techniques I'm talking about here should help. But "gets things done" is equally important. Have they shipped real software?

Joel and I don't agree on everything, though. I don't think live coding exercises are particularly valuable. Joel is (or was) also pretty big on understanding pointer math, which is an interesting "can grasp a complex topic" question but likewise outside the experience of many excellent engineers, so while it can be a useful thing to try talking about, it shouldn't be an acid test.

Somebody who can intelligently discuss technology

As I mentioned, the two jobs of an engineer are to understand complex concepts, and then communicate them clearly. Somebody who can do just one or the other may have a brilliant career in some other field, but is going to be an inferior engineer. The best programmer in the world can develop incredibly efficient algorithms in record time, but the job of an engineer is to work with a team to achieve something larger, and if you are unwilling or unable to spend time communicating with your colleagues you're only doing half of your job.

Somebody who knows what they don't know

When interviewing I always attempt to find some area of expertise where I definitely know more than my subject. This is not to prove I'm smarter -- see below -- but because it's important to see how somebody reacts when they find themselves out of their technical depth.

The weakest candidates will try to waffle or make wild guesses. This is a terrible sign, firstly because it never works, and secondly because they thought that it would. In Dunning Kruger terms they are in the bottom quartile, unable to accurately judge their own lack of knowledge. It also means they will try to do this in other situations.

Strong candidates say "I don't know" as soon as they hit their limit, and may start asking questions. The very strongest candidates say "but if I had to guess" and then attempt to extrapolate. Those are great because it shows intellectual honesty and a strong desire to figure things out.

This is a conversation, not an interrogation

As I said before, it's a good idea to find an area where you know more than your interview subject. But this is not to prove to them that you're smarter or better: it's to explore the extents of their expertise, to get a sense of the breadth and depth of their knowledge. You will bump into the edges or touch bottom, and that's the point. When you do so it doesn't mean they've failed.

It's important that they're aware of this contract, too. You want your interviewee to be relaxed and comfortable, because that is the state they'll be in when they're doing their job (if not, your company is awful, please quit). Answers you get from candidates who are stressed or panicky are basically useless. This is true even if they're good answers, because they're not representative answers. Stress and panic are not sustainable states, so you risk hiring someone who only performs when pressured to do so.

There's always an exception

If your candidate has no relevant prior experience, your only option is a more traditional technical interview. This is true of both very junior candidates, and also more experienced people switching from other careers.

Somebody who has just completed a training course, no matter how intensive or well-regarded, does not know how to be an engineer. They may know how to code, but that's only half the job. Somebody fresh out of college may not even really know how to code beyond academic puzzle-solutions. In my experience, if someone has been coding professionally for less than a year, there's not really been enough time to know if they're good at it.

Fresh-out-of-college and other junior types are also not going to know anything about how to interact professionally. Not only does this make interviewing them trickier, it's also a terrifying responsibility: if you hire them, the culture and working practices of your company will be what they think of as "normal" forever.

Big companies can accommodate poor communicators

The other exception to my rules is if you work at a company large enough that engineers can become deeply specialized. When that happens, you may in fact need the genius programmer who isn't very good at explaining what they're doing. If you're big enough, you can hire a manager whose full-time job is to communicate with that person and then translate back and forth between them and the rest of the company. This works really well but is expensive, so it's not something startups can really afford to do. Past your first 50 engineers, you might consider it.

The final question: do I want to work with this person?

When you're sure your candidate is good enough to do the job, you have another question to answer: do I want to work with this person? There are no specific questions to ask to get this answer; it's more about how they answer the other questions. This makes it a personality test, and that makes it very, very dangerous territory. Personality is subjective, and that means you are inviting bias into the equation. Personal bias, implicit bias, unconscious bias.

The terrifying possibility of turning away a great candidate because you are biased towards them in some way you don't even know about is why people think giving pure, right-or-wrong technical questions are better. They're not, they're just easier. And they do nothing to protect against bias: when there are 50 syntax questions you ask, it is easy to give hints and passes to the candidates you implicitly prefer and pretend that they were just better. I've caught myself doing this. There is no simple way around this: you have to be aware of your biases, constantly conscious of them, and correct for them, or you will screw your company by hiring inferior people.

Look for somebody to WORK with

The most common way I see startups get the "do I want to work with them?" question wrong is by confusing that question with "do I want to be friends with this person?"

Get that assumption out of your head. Those two are not the same. You can have brilliant, productive professional interactions with someone with whom you have absolutely nothing in common with on a personal level, and that's fine. Your company does not need to "feel like a family". It's sure as hell not your frat house. You are not picking a drinking buddy (and as an aside, if your company regards drinking as a big part of its culture you probably have deeper problems).

No Jerks

From day one at npm Inc we implemented our No Assholes policy, and I was pleased to read recently that Polyvore (who seem to do brilliantly at maintaining a diverse engineering team) have pretty much the same policy. Avoid the "genius assholes", avoid the bitter and cynical, the bullies, the snobs. Don't work with somebody who is going to be mean, unpleasant, or demeaning to their co-workers. There is no level of brilliance and productivity that can compensate for poisoning the morale of your team, and once a team culture is broken it is very hard to fix. Hiring these people, even to get you through a crunch, is not worth what it costs. And if you hire one by mistake, fire them fast, and without hesitation.

The easiest way to spot that you are hiring a jerk is the phrase "hire, but not for this team". That means "this person has skills, but I don't want to work with them directly". If you don't, nobody else will, so don't inflict crappy people on other teams.

But in general jerks are easy to spot. If somebody has a personality flaw so strong and baked-in they can't keep it in check for a couple of hours while being interviewed, it is going to be a huge problem in the regular work environment. Arrogance, rudeness, inattention to detail -- these things turn up quickly, and if you spot them, trust your instinct to avoid them.

You are NOT hiring for "team fit"

I have never heard a definition of "team fit" that didn't end up sounding like "let our bias run free". Phrases like "looks like they belong here" are terrifying. More insidious are complaints like "doesn't like the same social activities we do". Grow up. Your office is not your frat house, and socializing with your co-workers outside of work is not some crucial test. There is no requirement that you like someone socially as long as you want to work with them.

And while I'm at it, as an introvert and lifelong non-drinker, may I make a personal plea that you stop incorporating social events into your hiring process? Professional interactions and social ones are not the same. Some people suck at small talk, and are not comfortable at bars. Remember the part about making sure your subject is relaxed and comfortable? It's about them being comfortable, not you.

How do you reconcile the "don't hire for team fit" rule with the "no jerks" policy and the "somebody you want to work with" requirement? The distinction is subtle, but important: somebody who is good for your team is not necessarily somebody you want to be friends with. It's tempting to look for both, but it's the wrong metric for the success of your company and is ultimately unsustainable.

Homogeneity is disastrous

I'm not going to make an argument that "diversity is intrinsically good" for some social purpose. That's a stupid way of looking at it. Lack of diversity is obviously, mathematically, bad for your company. Instead of hiring for "best for the job" you have accidentally hired for "looks like me". There is no chance that all the best programmers in the world look the same, so a lack of diversity means only bad things. It means "this team sucks at hiring", it means "management and HR are not strong or competent enough to spot and correct this", and worst of all it means "this team is not the best people available".

But what if I can't find anybody like this?

Here I must hand-wave. npm is incredibly lucky on the talent front: people love node and npm, and we get dozens of qualified candidates just by posting a vacancy. My previous startup, awe.sm, was not nearly so popular, but we managed to find good people anyway. It's a matter of taking a long time, and trying every channel: we got great candidates via posts to the Who's Hiring post on Hacker News, via our blog, and once from some coverage on TechCrunch.

The important thing to remember is that hiring a bad person is more expensive and wastes more time than waiting for a good person. It's tempting to say "at this point, anybody would do" but that's never, ever true. The wrong person will not merely fail to do their job, they will make everybody slower at theirs, and unhappy to boot. Don't hire if you're not sure about somebody, and if you hire somebody who's no good, give them as much support and direction as you can afford to get them to turn around, but if you don't see any improvement be ruthless in letting them go.

This is all very hard

This is why you've been giving bad technical interviews all this time: bad interviews are easier to give. They require less thought and creativity and effort on your part. These techniques are tricky to define and tough to follow. But that's what hiring is like. It's really hard, and it always takes much longer than you hope it will. The rules are fuzzy, and there are no acid tests that can be applied. But the payoff to trying harder is a stronger company, better people, a better product, and a happier working life for everyone on the team. Making those things happen is, as a hiring manager, your only job.

TL;DR

1. many interview techniques test skills that are at best irrelevant to real working life
2. you want somebody who knows enough to do the job right now
3. or somebody smart and motivated enough that they can learn the job quickly
4. you want somebody who keeps getting better at what they do
5. your interview should be a collaborative conversation, not a combative interrogation
6. you also want somebody who you will enjoy working with
7. it's important to separate "enjoy working with" from "enjoy hanging out with"
8. don't hire assholes, no matter how good they are
9. if your team isn't diverse, your team is worse than it needed to be
10. accept that hiring takes a really long time and is really, really hard

Update 2014-07-23: added Twitter and Salesforce to the spreadsheet after they published their numbers.

Something really unusual happened recently: Google, then Yahoo, and finally today Facebook all released diversity reports, detailing how their workforces break down along gender and racial lines.

This is unusual first because this is data they previously kept secret, and also because of the striking uniformity of the reports -- they all chose to report in the same categories and even gave those categories exactly the same names. I'm not sure how that happened -- maybe they conferred, maybe there's a third party driving all three of them to do it -- but whatever happened, it means it's possible to do an apples-to-apples comparison of these three, which collectively employ around 60,000 people (Google is by far the largest company).

First up, gender breakdown across US employees:

Unsurprisingly given what we hear about tech, men are over-represented. The only other interesting thing is that Yahoo is the only company to acknowledge a non-binary gender option (though they include "undisclosed" in that group, so it's not clear how many employees are taking advantage of that). But interestingly, all three companies chose to further break down their stats by "technical" and "non-technical" positions. None disclosed how they made that classification, but the results are strikingly similar. Here's non-technical staff:

Not bad at all. But here's technical staff:

Boom. The problem with gender diversity isn't in "Silicon Valley companies" it's in engineering. In case you needed the point rammed home any harder, this is 100% tech's problem. The companies are doing generally okay, but the engineering organizations are ridiculous, averaging only 16% women.

The racial data has fewer surprises. Here's all US employees again:

Again, I had to make no adjustments at all to this data. All three used exactly the same names for categories. Is there some national standard for reporting this data I'm not aware of, or is there some coordinated campaign? Anyway, these companies are hella white, and basically everybody who isn't white is asian. The breakdown amongst non-technical staff is pretty much identical across all three companies:

With the one surprise being in the data on technical staff:

Yahoo's engineering staff is majority asian, by a huge margin. I triple-checked my data to make sure I wasn't getting this wrong, and that this is only about US employees (Yahoo India is a substantial organization). But no. For some reason Yahoo employs way more asians compared to the other companies, and all the "extra" asians are engineers. As an ex-Yahoo myself I can't say I ever noted this myself, but there it is.

What does this say about our industry? Nothing we didn't know before: tech companies are very mostly[1] white and very male, and engineering organizations embarrassingly so. Engineering orgs are also disproportionately asian (the Bay Area is 23% asian, and non-technical staff match that figure). But here's some nice, solid, clean data, all released in the same six-week period, to back that up.

If you want the actual numbers, you can save some typing by cloning this spreadsheet, which also has the charts from this post.

[1] Thanks to Tom Coates for suggesting I clarify this.

Well, that sure happened fast.

Ten days ago, Mozilla announced that its co-founder and CTO since 2005 Brendan Eich had been appointed CEO by the board. The move was met with widespread outrage from the LGBT+ community and its supporters, who had been incensed in 2012 to learn that in 2008 Eich had donated to California's proposition 8, a successful attempt to strip gays and lesbians in California of their right to marry.

Mr. Eich first tried a non-apology, saying he was sorry he "caused pain" without actually saying he was sorry he donated in the first place. Two days later, half of Mozilla's board resigned over the decision. This week he tried another non-apology, this time claiming the mission of Mozilla itself could be at risk. But the writing was on the wall, and today he "resigned", though it doesn't sound like he had a lot of say in the matter.

Like many gay people, I have a lot of conflicted feelings about this. I have no reason to believe anyone will particularly care about my position on the matter, but this blog has always been about helping me think things through, so here's what I've thought.

The mistake made was not made by Brendan Eich

Mr. Eich can believe anything he wants. If he wants to back up that belief with public action in the form of political donations he has every right to do so. But he should know that his actions have consequences. And this is a key point: belief is not the same as acting on that belief. You can believe as hard as you like, but when your actions lead directly to the suffering of thousands of people, it is only rational to expect those people to be very, very angry at you.

The people who messed up here are the board of the Mozilla Corporation. Everyone had known about the donation for several years and there had been a lot of fuss at the time. Presumably, given the resignations, it wasn't an easy decision. But it was clearly the wrong one. A CEO is a public-facing, highly visible role. Appointing such an obviously controversial figure should never have happened. Once it had happened, and it became clear that the uproar would prevent him from doing his job effectively, the only remaining option was to fire him, which, despite the language, is what seems to have happened (most people write their own departure announcement).

Brendan Eich is not a bad person

Eich is a brilliant technologist, and everyone I've spoken to who has interacted with him in any capacity say he is kind and friendly to everyone, regardless of background. He also invented JavaScript, which despite its many flaws made the web a much more interesting place, and is now doing the same on the server side. The fact that he is evidently such a nice guy is why a lot of people I know and respect immediately defended him. It's hard to reconcile somebody you like personally having really abhorrent political views.

And make no mistake: these views are abhorrent. Whether based on religion or not -- and he hasn't said, so I won't assume -- Mr. Eich's actions show he believes LGBT+ people are less than heterosexual people, undeserving of equality. Whatever his basis for believing it, his repeated refusal to recant or apologize shows he strongly believes it, that it wasn't a mistake. But the problem is that he then acted on that belief, and in doing so stripped thousands of people of their right to marry the person they love. It doesn't matter whether you're a nice guy in person, your actions were hostile.

So where does that leave us? Nice guy, brilliant technologist, appalling politics? Well, it should leave you out of the way. I could just about reconcile myself with Eich being the CTO of Mozilla; the organization was largely his (and Mitchell Baker's) idea, and he was good at technical things. He could have stayed as CTO indefinitely, but he chose not to. He'd effectively run the place for years anyway; becoming CEO was merely a symbolic change. But symbols are important.

This is a huge blow to Mozilla, but they should recover

They have at once hugely damaged the well-deserved public respect and goodwill they enjoyed by making a terrible decision. Their capacity to make sound decisions in general will be rightfully questioned. Simultaneously, they have lost a co-founder and an invaluable technical resource.

We owe a great debt to the Mozilla foundation. Thrown overboard from the sinking ship that was Netscape, the Mozilla browser eventually gave birth to Firefox, which for years was the lone light of advancement in the field of web development. As somebody who holds the web very close to my heart, I have to acknowledge that they saved it. I owe them a debt. And to the degree that Brendan was the driver of that process, I owe him too.

But freedom to love who I want is more important than freedom from poorly-designed web standards, or the ability to block ad networks, or open source software, or online privacy, or anything else the Mozilla foundation concerns itself with. To claim otherwise is offensive. They are not even the same class of problem. If the triumph of equality meant the death of Mozilla I would make that trade in a heartbeat. I don't think it's necessary, though. Mozilla will lick their wounds and recover, as will Mr. Eich, who I'm certain will go on to do more great technical work while holding views that annoy me.

This is not "reverse discrimination" or "bullying"

There has been a lot of pushback of this kind on twitter, with a lot of ridiculous hypotheticals. I don't know how many times we have to say this, and in how many ways, but here are some: calling you a jerk for your belief that I am sub-human is not the same as you believing I am sub-human in the first place. Your freedom of speech does not mean freedom of consequences of that speech. There is no right to not be offended by things. Your religious expression is not more important than my equal rights, and in any case my having equal rights does not affect your ability to express those beliefs. Taking away your privilege is not equivalent to oppressing you. It's not bullying. An adult punching a three year old is bullying; it's not bullying if the three year old punches back. Power matters, and until very recently you had all of it, and you still have more than your share.

This is a culture war, and we won

But I don't want to claim that there was any great liberal or democratic principle at stake here. Had there been more people who disliked gay people than who liked them, this would have gone the other way. Are there other corporations where the CEO is anti-gay and nobody cares? Sure. Would I be outraged if conservatives got a CEO at some other company fired for her liberal views? Absolutely. Was this mob rule? It most certainly was.

But in this instance -- not all instances, but this one -- mob rule is fine with me. Because Mr. Eich is wrong, utterly wrong about this matter, and my friends and I are right. And now every board at every tech company in America is going to remember this lesson: don't fuck with the gays. In the past few decades they learned it's not okay to be even a little bit racist, or sexist, and now it's not okay to be homophobic either (of course, they often are still racist, sexist and homophobic, but at least they know). I believe that's the way things should be, and as long as I can help things be the way I want them to be by simply loudly and repeatedly expressing my opinion, I'm going to keep doing so.

Because we don't usually get to be here. For decades LGBT+ people and minorities of all stripes have been shouted down, excluded, and systematically discriminated against, denied homes and jobs and rights of all kinds. It was unfair, and unjust. Now the tables have turned, and I'm not going to let some misplaced sense of honor get the best of me. You lost, we won, and me and my multi-colored, sexually fluid, blurry-gendered friends are still very much at a disadvantage, so we're going to take any victories we can get.

Our freedom to be ourselves is more important than you being okay with that.

"Why do you want to build websites?"

That was the question posed to me by my boyfriend a couple of nights ago, as we discussed my latest half-baked plan for building world-changing software. A very talented programmer himself, he's more of a generalist than I am, so I think the way my ideas nearly always boil down to "this will make it easier to build websites" confuses him. He doesn't understand my focus on this one, singular problem, in a world of interesting programming problems. He meant "why do you always want to build websites?"

Then last night, a random stranger emailed me about Makomi, my currently-paused prototype to, yes, make it easier and faster to build websites, in this case by providing a GUI that runs on your local machine and lets you draw a functional interface and bind it to data. I still believe it's a good idea, but a ton of work, and better for non-technical people to put together prototypes than my original idea, which was to have it adopted by full-stack web developers like myself, to accelerate their work (the YCombinator-backed Appcubator is a hosted version of the same idea, though thankfully my commit logs verify I started working on the idea before they announced themselves, or I would feel like a plagiarist).

The stranger and I got to talking about Thinkstack, my latest idea. I gave him the elevator pitch -- you'll be getting it too, in a follow-up post to this one. He liked the idea but said it's missing the "Why" (a reference to this TED talk, which I'd seen before but forgotten about). That, and my boyfriend's question, finally crystallized for me how to begin this series of blog posts about the state of web development and how I intend to make it better: I have to supply the Why, even if it is somewhat embarrassingly personal. Watch out, because this language is gonna get flowery.

The web is my light and my salvation

As I've written previously, my teenage years were extremely unhappy. I was a closeted gay kid in a small, deeply conservative country where being gay was and is still illegal. Confused, isolated and suicidal, Internet access arrived in January of 1996, a few months after I turned fifteen. The Internet, and the web in particular, saved my life.

People will sometimes flippantly say "X saved my life" about a piece of technology that they love. The web is not like that for me. A heartbreaking 30-40% of LGBT youth attempt suicide, and the web is what stopped me joining that group. I had a plan -- I had more than one plan. I had written drafts of the note. The web is what saved me. I have no record of the first article I found, but it had a title very much like "I think I might be gay, now what do I do?"

The advice in that article is so simple as to be banal, and 17 years later the answers to questions like "Am I normal?" and "How do I learn to like myself?" seem to be stupidly obvious, especially if you grew up in a rich western country where progress on these things has come faster than other places. But to a gay kid with no other sources of information and nobody he felt he could talk to, the sentences "Yes, you are absolutely normal. Many people are gay" were life-changing, life-saving. I read them over and over for reassurance. I clung to them like a drowning man clutches a life preserver.

It is hard to find the words that express how powerful, how important this basic, positive information was. As tears spill down my cheeks and onto my keyboard, these words look too simple, too subdued, too prosaic to convey the effect they had. My teenage mind was a dark maelstrom of guilt and shame and grief and fear and longing. The web was a lighthouse that threw a single, bright light of hope into my world. I was still in a storm, but suddenly I knew there was a shore. I was still close to drowning, but finally I had a direction in which to swim.

And then I went looking for more. And boy did I find more. Oasis Magazine ("blog" had not yet been coined) was full of stories of kids my age, wrestling with the same questions, talking about coming out to friends and family, showing parents and friends could be accepting. The Youth Lists introduced me to happy, healthy gay kids who I could talk to about my life, crushes at school, my frustrations, without fear of rejection or judgement or exposure. Again, it all sounds so basic, so simple. But I can't emphasize enough how much difference they made to me. I need you to shout these words in your head: THE WEB SAVED MY LIFE.

But that wasn't the web, that was people, right? It may seem strange that I have these intense feelings of gratitude towards the medium itself, rather than the people who used it. And of course it's true: the people were the ones who saved me, and over the years I have thrown actual money, not just overwrought words, at the organizations that helped me through those years. But those people always existed: the web was what got their words through to me. The web was how I found out it could get better, years before that was a catchphrase. Without the lighthouse, they would just have been helpless bystanders, watching another body wash up on the shore.

The web is my guide and my teacher

In the years since then, the web has helped me over and over, not just through that crucial period. Starting with Angelfire and HotDog website builder (a GUI for making websites! what a concept!), the web showed me that anybody could add to it, and showed me how. Starting with no more knowledge about what I was doing than how an if-then statement worked, PHP's documentation taught me how to build a website that could do stuff, not just sit there.

It's so basic to how the world works now that we don't even notice it anymore, but the idea that anybody can add a page to the web was a fundamental, ground-breaking innovation. In those days, my little website thrown together in an afternoon looked only a little bit less professional than that of the New York Times; we were all learning how to build the web at the same time. The concept of publishing authority, that "it must be true, it's in the newspaper" became self-evidently nonsensical. Yahoo's web directory blew the doors open, allowing you to follow random walks through a forest of information that was already beginning to seem infinite (Yahoo listed my personal website, and that listing is still there, a discovery that blows my mind).

Then Google turned the frustration of poring through that infinity into one of astonishing ease. Some people reading this now will be too young to remember, but the "I'm feeling lucky" button was, at the time, an astonishing boast: "we are so sure the first result will be the one you want, we'll take you straight there". Web search was, prior to that, a matter of trying multiple combinations of search terms, over and over, and clicking through dozens of pages of links to see if there could be anything relevant. When was the last time you clicked past even the first page of a search result?

Now the web knows the answer to every question I've ever thought to ask it -- yes, even that question. Anything I want to learn, any worry I want assuaged or confirmed, any idle curiosity, flows through the magic of HTTP to me, first through wires, nowadays through thin air to a tiny magic rectangle I can hold in my hand. But it's still the same web, even though the sites have changed and everything is more complicated now.

The web has everything we know on it, and you can read it all. Nothing's stopping you. Maybe the fact that that still blows my mind marks me as an old fogey, but honestly, how can that not blow your mind? And people are adding to it, constantly, every day, writing detailed research, quick tutorials, fiery opinions, thoughtful advice, answers to each others questions, beautiful prose, terrifying depths of depravity and hate, joy and sadness, love and anger, sympathy and delight. You can listen to them doing it, their contributions turned into music. All life is here; just hit the right buttons and go looking for it. How do you stop reading that? What could possibly ever tear you away from an artifact of such limitless potential?

How can you not want to build websites?

And that's why, since 1996, "building websites" has been pretty much the only thing I've done. Not always well, not always or even mostly towards some noble goal, but continuously. The web saved my life and then built me a new one. A single living entity, it touches everything in the world and is always getting better -- and I can help. I owe it so much; if I can help it out, make it better in any small way, how can I possibly refuse? And if I can make it easier for other people to help make it better, then my efforts are multiplied.

I am a web developer. I develop the web. And all of this is Why.

I'm not a big believer in euphemisms, nor in burying the lead^[1], so let me begin by saying that I no longer work at awe.sm on a day-to-day basis. The parting, while solely my idea, was completely amicable, and I remain attached to the company as an advisor, occasionally weighing in on architectural issues. This was not a sudden decision, or a quick exit: over the last six months I slowly transitioned my responsibilities to the other members of the team, and then stepped away entirely on a trial basis to make sure things could run smoothly in my absence. As of two weeks ago, we made that permanent. For all intents and purposes, I am a free agent for the first time in more than a decade.

After taking some time off, including a pretty awesome road trip, I started work on a pair of related ideas for software that will make web development easier, faster and higher-quality. The opportunity to work on them uninterrupted was a big part of my motivation for leaving awe.sm, and I'll be blogging a lot more about the state of web development and the tools themselves once they are a little further along in development.

As for awe.sm in my absence, I have nothing but positive expectations. As I noted last year, everybody who works there is smarter than I am. Fred and Jonathan have the right strategy, and Bennett may not tweet much, but he's one of the best engineers I've ever worked with, so I'm happy to leave the engineering team in his hands.

A quick PWBFAQ: (Probably Will Be Frequently Asked Questions)

Does this mean you're doing a new startup?

It's not clear yet whether the ideas I'm working on will be useful, or monetizable, but I'm certainly not ruling out the possibility. I'm not in "stealth mode", I'm just coding some stuff, and will be talking about it more soon.

Does this mean you're looking for a job?

Not right now. If you are looking for somebody to consult with you, especially about building or scaling a web application, I may be available, and you should email me. But for the immediate future I want to concentrate the majority of my time on my own projects.

Sure, but I'm a recruiter for this AWESOME funded startup in Palo Alto and we should really talk.

I am definitely not interested in full-time employment anywhere. Recruiters who call referring to this blog post should be prepared to explain why they ignored this part.

Why does your blog look so broken?

It's been a bit neglected recently. I intend to fix that.

[1] Or the lede, if you're a journalist. Please don't email me about spelling.