Profile cover photo
Profile photo
Steve Yegge
Someday my foot won't fit in my mouth.
Someday my foot won't fit in my mouth.

Steve's posts

Return of the Mystery Machine Bus!  In 3D!

The inputs are in!  Everyone's had a chance to mull over my liberal/conservative distinction in the big world of programming styles and approaches to software engineering.  Lots of great feedback.

Thank you to everyone who took the time to think about this conceptual model and share your thoughts.

Here are a few things that jumped out at me, reading the feedback.

Surprise Factor

My distinction seems to have taken almost everyone by surprise.  I'd half-expected people to point me off to papers and articles that had already explored this metaphor.  But no, this appears to be a genuinely new way of looking at the programming world.

Which means, naturally, that reactions will range from hyper-enthusiasm to the Five Stages of Grief, and everything in between.  Mostly in between.  I think most of us are (justifiably) too happy with our awesome choice of career to get too riled up about this stuff.

The Unhappy Quadrant

As a rough generalization, it appears that political conservatives didn't seem to object to my taxonomy.  They're fine with being labeled either software-liberal or software-conservative.  And political liberals don't mind being software-liberal.  But political liberals HATE being labeled software-conservative.

As many commenters pointed out, though, it's pretty much inevitable at this point.  The metaphor is too useful to ignore.  The parallels to political science run deep.  I will explore more of them in today's little sequel.

Mad Marketing Rush

Some Clojure-language folks wrote a charming and possibly satirical response entitled "Clojure is not Software Conservative", in which they basically said:  "We are not sure whether this so-called liberal/conservative distinction is well-defined enough to be considered valid, so we're not really going to stoop to playing that game.  But we are most definitely NOT conservative!  We are liberal!"

I think the Clojure guys, to their immense credit, were the first to deduce a critical implication for programming language evangelists:  <b>You can only market a language to half the developers in the world.</b>  You can market to the left, or the right, or the center, but ultimately you're only going to appeal to the developers clustered around your language's basic value system.  And people are going to be way more aware of that now.  Languages are no longer going to be able to get away with saying "Ideal for Everyone!"

The Clojure post was a valiant attempt at market positioning.  And you have to hand it to them -- they aimed at the "bigger half", which is to say:  distancing themselves from the decidedly unpopular crop of highly conservative languages.  There's some truth in what they're saying, since Lisp itself is amazingly expressive and composable, and Clojure's syntactic choices are, I think, a genuine advance in the field.  The other Lisps could learn a thing or three.

But the reality is that Clojure is quite conservative.  As far as I'm concerned, if you can't set the value of a memory variable without writing code to ask for a transaction, it's... it's... all I can think of is Morgan Freeman in the Shawshank Redemption, working at the grocery store, complaining "Forty years I been asking permission to piss. I can't squeeze a drop without say-so."

And it's not just variables.  I could rattle off a dozen ways that the language imposes heavyweight protective machinery and restrictions that you don't see in, say, Common Lisp.

This is just a basic (and irreconcilable) difference of opinion.  It doesn't help matters for the Clojure people tell me: "No, really, we promise we'll let you urinate any time you want!  All you've gotta do is ask someone in charge!  It's practically a rubber stamp!"  I just don't want to have to ask.  In fact I don't want an authority in charge at all.  Period.

But that's just me.  Some people love it.  Having a conservative Lisp dialect is actually a cool thing.  I think we've needed one for a long time.  I think it's a great way to attract the H-M crowd into the wonderful world of Lisp.  I think you should be able to choose from Lisps all along the political spectrum, and Clojure has helped us fill out the offerings.  So go Clojure!

False False Dichotomy

Several folks decried my taxonomy as a logical fallacy of the False Dichotomy variety, thereby hoping to have the case thrown out of court on procedural grounds before it could go to trial.

I'll bet you can guess whether they were soft-cons or soft-libs.

Unfortunately they overlooked the fact that this is a court of Public Opinion, so the harder they fight, the more likely it is to go to trial.  Their best bet would have been to ignore me.  Oopsie.

And what will the ruling be?  I think sensible people will realize that projecting a complex multi-dimensional value space onto a single axis, though lossy, still has genuine value.

Take movies, for example.  How do you tell if you're going to like a movie, assuming you can't see the trailer?  What's the first indicator you look at?  Well, there's genre, sure, and some folks have halfheartedly tried to argue that genres might be a better taxonomy.  But we already have a bunch of genres in programming:  frontend, backend, n-tier, rdbms, distributed, real-time, etc. etc.  We're all specialists nowadays.  The notion of "genre" in programming is nothing more than a classifier for the problem domain.

Once you've picked a genre, I'll venture to guess that your main yardstick when deciding whether to watch a movie these days -- assuming it's not opening day -- is the star rating.  Maybe you use IMDb's rating, or Netflix's rating, or rottentomatoes or metacritic or whatever.  But you want to see an aggregate score.  Because it matters!

Let's say you're choosing between two movies to watch tonight.

Movie 1 has great sound, decent acting, world-class cinematography, sloppy film editing, a wonderful soundtrack, inconsistent pacing, an unsatisfying ending, incredible action sequences, a memorable plot, and laughably bad special effects.

Movie 2 has exactly the same description, but the adjectives are all rotated one clause to the right.

Which one should you watch?  I don't know!  What are their IMDb ratings?

A star rating has exactly the same problem as a political axis:  it's an oversimplification.  But it also has exactly the same advantage:  it gives you an analog metric and some confidence that you know roughly what the metric means.  <b>Even if it's only useful as a relative way to rank two similar things.</b>

If you think star ratings in general (for games, movies, iTunes songs, whatever) are complete bullshit, and that we shouldn't be using them, well, you're entitled to your opinion.  You don't have to look at them.  But most of us find them pretty useful.

And despite its problems, I think most people find the political spectrum useful too.

The Money Party

Some people argued that "conservative" really means "small government", so I should be using the term "liberal" for programmers who want a big automated nanny state protecting them from errors.

But let's face it:  that's a definition of "conservative" that hasn't been truly applicable to U.S. politics since World War II, if not earlier.  Today, both parties want to spend a crapload of money.  Republicans and Democrats are both arms of the Money Party.  All the debate nowadays is strictly over how the money will be spent.

We should probably model the programming metaphor on the social political axis.  In hindsight I shouldn't have confused the model by mentioning the "fiscal conservative / social liberal" problem (which is in fact a gaping hole in the U.S. political system -- the two-party system pretty much screws this large demographic.)

I actually think the axis we're comparing to would be more accurate if it went from Libertarian to Conservative.  That's a more faithful isomorphism to the underlying distinction I'm trying to make.  But I think it might cause more confusion than benefit.  So we'll call the opposite of software-conservative "liberal", and just between you and me, we'll know what it really means.

The Introspection Problem

Various people pointed me to articles, essays and even one TED Talk from Jonathan Haidt about differences between liberals and conservatives in the real world.  They were all interesting and relevant, so thanks for the links.

I found it noteworthy that all the attempts to model the fundamental nature of the disagreement between liberals and conservatives seemed to come from liberals.  Conservatives, rather than coming up with their own alternate models, simply dismiss the liberal models as irrelevant or off-base.

I'd love to see some pointers to essays from deep-thinking political conservatives that attempt to provide any metaphors, any thought experiments or conceptual models for the liberal/conservative spectrum itself, without reference to any particular issues.  Because what I've been seeing in my brief survey of political science is the same thing I've been seeing in the programming world -- namely, that many conservatives don't want to admit there are other valid viewpoints.

Some conservatives apparently just want to be "right", and anyone who thinks differently is just "wrong" -- but without going so far as to inadvertently legitimize the opposing position by giving it first-class citizenship on a smooth spectrum.  They just want there to be no spectrum at all.

That's obviously not true for all conservatives, so like I said, I'd love to see some pointers to conservative metaphors for the difference in world-view along the political axis.

The "Look and Feel" Problem

I think a lot of people took umbrage to being labeled "conservative", even when they clearly understood and more or less agreed with what I meant by the term.  Because they don't feel conservative.  On the contrary, many (maybe most) software conservatives feel quite liberal.  They're out to change the world too!  They don't think of themselves as stodgy or over-cautious or engaging in Security Theater or any of that other stuff I accused them of.  I've got it all wrong!  They're super liberal!  I'm just thinking about it wrong!

But here's the thing:  almost nobody feels conservative.  If you actually feel conservative, you're probably way off in the deep end in the conservative pool.  Middle-of-the road conservatives and slightly right-leaning moderates are going to feel liberal and open-minded and embracing of change and willing to take on "acceptable" risks.

I can tell you from personal experience:  just because I'm 43 years old doesn't mean I feel old.  I don't feel old at all.  I feel young!  In fact, I am young!  You're just thinking about it all wrong!  This whole "age" thing is a False Dichotomy!

Everyone feels young.  It's a fact of life.  How people label me, though, has nothing to do with how I feel.  If I look old, people are going to label me old.  And they're not wrong, because the term is relative.

I think a lot of the people who tried on the political-axis suit and found it didn't fit comfortably are missing a key point.  The labeling isn't based on how it feels to them.  The reason I'm drawing this whole political-axis distinction, and the reason I'm going to continue using this model as a didactic tool, is that liberals needed a way to label conservatives.

Why?  Because we don't want to work that way.  But software conservatives have increasingly been acting like a Moral Majority, where their way is the One True Way, and everyone who I'm now calling "more liberal" is just lazy and ignorant.

It's clearly all a matter of degree, since C++ programmers (moderates, by and large) are considered lazy and ignorant by hardcore Hindley-Milner folks.  Those C++ programmers are too lazy to learn a "truly" safe language, and they're ignorant in thinking that C++ is by any definition at all "type-safe".  Now the H-M crowd has to use the politically-correct term "liberal", and the C++ crowd has to use the politically-correct term "bear-shooter".

Oh yeah, and some folks thought this was just about types.  Not so.  Not even close.  It's much, much broader than that.

Just look at the hardcore relational data modelers vs. NoSQL folks.  They have historically denounced NoSQL approaches as naive, undisciplined and doomed to failure.  It wasn't until the NoSQL people rallied together and actually started marketing their views (including the catchy name, "NoSQL") that the data modelers had to back off even a teeny bit.  It was a case of marketing legitimizing a perfectly valid world-view that had been around forever but suppressed in a fairly ghastly fashion by the intellectual aristocracy.

So yes.  This distinction is phenomenally important, because it is finally giving programmers with a perfectly valid, proven world-view -- proven again and again in the marketplace -- a seat at the table.

Are you talking about Marketing again?

Ah, marketing.  Conservatives have always been really effective at marketing, because fear and uncertainty are incredible motivators.  Conservatives have made tremendous inroads in getting programmers to feel afraid of their code.  All they need is FUD, and they can get almost any crazy bureaucracy approved -- institutional, procedural, technological, you name it.

I've been fighting this marketing battle for a decade.  I'm not exaggerating in the slightest.  Ten long years.  I've written hundreds and hundreds of pages on the subject.  I've written articles, essays, rants, fictional works.  I'd have written limericks if I'd thought it would help.

But all that time I was making the mistake of trying to change the way software-conservatives think.  And of course that's not a tractable problem.  In fact the TED Talk I mentioned argues that it's a bad idea, and that we need diversity of opinion in order to keep looking at new problems (collectively) with a fresh perspective.  Seems plausible to me, although according to the talk, it's also precisely the kind of conclusion that only a true liberal could arrive at.

Now, though... now, after all these years, I think I've finally caught a break.  I found a marketing concept that actually solves the problem I've been fighting with, and it does so far more elegantly than I'd ever have hoped.  I've stumbled on a way to force the legitimization of the liberal viewpoint, simply by drawing the distinction as a political one rather than a religious one.

So let's wrap up the rebuttal and get on with solving mysteries and catching bad guys and stuff.

Do You Respect Your Code?

Time for an all-new generalization!  _Note: generalization._

I think there is a vast and fundamental divide in the way liberals and conservatives view their code.  Conservatives like their code, while liberals view their code as a necessary evil.

Political scientists have observed that U.S. Conservatives basically think of the United States as a force for Good.  They think the U.S. should go out and "fix" the rest of the world, so they can be just like the U.S.  They look at countries where people are suffering in any way at all and they think, "Gosh, why can't those good people have picket fences and credit unions and McDonalds and Wal Mart and all the other wonderful goodness of the U S of A?"

Whereas U.S. Liberals basically think of the United States itself as the primary problem that needs fixing.  They think of the U.S. as an evil military-industrial complex run by a corporate hegemony, and that it is well down the path of destroying the Constitution, abandoning its people, and turning, eventually, into something resembling North Korea.

It's an oversimplification, but it's at least partly true.  The Right, in general, thinks the U.S. is Awesome, and the Left thinks it's Broken.

And with that in mind, let's go back and look at your code.  How do you feel about it?

Wel, one way to look at your code is that it's going to last a long time.  Code has a long lifespan.  It's going to grow and grow, especially if it's successful, and eventually it will become so large, so many millions upon millions of lines of code, that no one human being could ever understand how all of it works.  So we need to take steps right now to make sure it's going to be extremely well-organized, and make sure we have automated tools that can help us understand and globally modify the code, and so on.

Another way to look at your code is that it's going to die -- and probably soon, at that.  You look back at all the projects you've ever been on, and you can't think of a single piece of code that wasn't rewritten at least once, maybe half a dozen times, over the years.  Hell, a lot of the projects you were on never even launched, or the launch was a dismal failure and the code was quickly retired.  Or maybe the launch was a smash success!  But then other engineers came along, and they brought new frameworks and updated designs to match the new biz requirements, and gradually, a piece at a time, they threw all the old code away and replaced it with new code.

Liberals view code itself as a problem: nothing more than reified technical debt.  Conservatives will often refer to their huge code base as an "asset" that has to be managed and protected, just like any other asset.  And liberals tend to think of their code base as a genuine liability, one that becomes increasingly problematic as it grows.

Conservatives say: "We need to plan ahead for millions of lines of code, to ensure we can manage it!"

Liberals say:  "Here is a loaded shotgun.  Keep it there in your drawer.  If we ever wind up with millions of lines of code, I want you to shoot me."

So their planning stages are incredibly different.  Liberals set out to minimize the amount of code they have to write.  All their decision-making revolves around how to keep the code base tiny and manageable.  If you can avoid code by using a helper binary, or by writing a script, do it!  If you see a DSL emerging from the bloat, embrace it!  (And at least to this extent, Clojure is a lot more liberal even than Java.)

Whereas conservatives immediately get to work start building huge bunkers for the oncoming storm.  And they never write scripts.  Conservatives hate scripts.  It's a dirty word to them.  Scripts don't have APIs and monitoring ports and stuff, and they're usually written in dirty hateful liberal typeless languages, and they're notoriously slow so why would you ever ever use one, etc.  Lot of hating on scripts in the conservative world, especially as you head farther right.

A lot of this difference in attitude comes down to basic respect for the code.  Conservatives respect their code like you might respect, oh, the Eiffel Tower.  It's an impressive achievement, even a beautiful one.  Conservatives always want to build the next Eiffel Tower, the next Louvre, the next Markarth.

In contrast, liberals "respect" their code in exactly the way that you respect a power outlet, a moving vehicle, a loaded gun, a box of dynamite.  They see code as a dangerous tool that you need in order to do an important job.  A programmer is like a lion tamer, and a big lion is a dangerous lion.  Liberals do whatever it takes to keep their code base as small as they can.  Right off the bat, the most important decision you can make in this dimension is your choice of programming language, because some languages are naturally and necessarily verbose.

I wrote about this in my essay "Code's Worst Enemy".  And many of the responses were just plain bafflement.  I had argued that code size is not just a problem, it is in fact the most serious problem you will ever face as a programmer.  And yet many programmers remain convinced that not only is it not a problem, it is one of the biggest non-problems!  It's, like, totally solved with refactoring tools and APIs and stuff.

Well, now we know why they they're baffled.  They feel like I'm saying that Rome is just too goddamned big.  I point at this huge, thriving, beautiful, astonishing, millenia-old architectural marvel of a city -- their software project, that is -- and I declare that the thing is more bloated than one of Yegge's blog posts.  And they're shocked and a little hurt.

But I'm not really saying Rome's too big.  What I'm saying is that that you can't build it, even if you're dead-set on trying.  You'll wind up building Detroit, or, God help you, the Adwords Frontend.

My highly liberal view is that it's always best to build something small and organic, and let it evolve naturally.  Liberals like me believe that this trumps everything.  And any liberal who spends enough time really researching the problem -- no fair if you give up before you've tried everything -- will eventually realize that the best way to do this, the timeless way, is by using Lisp.

But hell, even Perl works a hell of a lot better than Java.  I dislike Perl immensely because (I've come to realize) they're way more liberal than even I am.  Well that, and I eventually found that Ruby gives me all the benefits without the irregularity.  But I watched Perl programmers kick Java's ass in one of the most apples-to-apples showdowns that may have ever gone down in the industry.  I wrote about it in my old essay "Is Weak Typing Strong Enough?"

Now, years later, I see that the answer is pretty clear:  it depends on YOU.  The choice comes down to your own personal values, beliefs and preferences as a programmer.

Applications as Cities

When conservative programmers set out to build a system, they think of it a little like building a city.  They do their city planning, and the design their little scale models and artist's visualizations of the city, and they plan ahead to contain sprawl and to keep stuff organized.

When liberal programmers set out to build a system, the think of it more like building a military encampment.  Get the thing built fast.  Make sure you can tear it down or reorganize it fast.  Don't waste a bunch of time on building it to last.  You're going to have it for a month or a year or a few years, but it's just there to get the job done, and at some point it's almost guaranteed to move.

Only after a LONG time, after they've proven that the military really needs a base there, do liberal programmers start talking about making it a more formal thing.  By then they'll know exactly how it interacts with the surroundings, and how the logistics and supply lines need to work, and where it needs to be defensible, and so on.  And even then, they just build a bare-bones base, because anything fancier than that is just gonna hurt your feelings if it gets blown up.

Order and Chaos

We're almost done with this episode's blatant stereotyping of liberal vs. conservative software developers.  I think we needed this sequel to finish the job properly.  I think I almost could have gotten away with it last week, if it weren't for you meddling kids!

Conservative programmers want to write beautiful code.  They want to write orderly code.  Early on in the comment threads, I joked that conservatives should be happy that I didn't use the Dungeons and Dragons alignment dual-axis of Law/Chaos and Good/Evil as my metaphor.

But then several commenters observed that this debate really seems to center around the desire for order.  If we assume this isn't due to OCD, then it's really just another way of saying that it centers around risk management, because orderliness can yield -- well, if not safety, then at least the comfortable feeling that you always know what's going on.

So the D&D scale isn't actually so far removed as you might think.  In my many debates with conservative programmers over the years, they have often wound up saying:  "But your position is inviting chaos!  It's going to be pure chaos!"  And true chaos, of course, leads to lots of uncertainty and risk.

But there's "chaos" and then there's "natural order", which can appear quite chaotic from the outside.  Christopher Alexander spent a lifetime examining the curious phenomenon that he called "Quality Without A Name" (QWAN), in which he noticed that organically-evolved architectures and habitations were often far more beautiful, functional and ultimately livable than their orderly, organized top-down-designed counterparts.

If these places are more livable and functional, then surely we're not looking at chaos so much as a natural, domain-specific set of underlying forces governing the growth of the system.  They may not all be controlled by some central planning authority, but every single individual decision is made by a thoughtful person who does what is best for that particular situation.  And the result is beautiful.

So yes, we are talking (also) about Law and Order vs. Organic Evolution.  To a conservative, organic evolution is chaos, and they can always point to some big code base or system that they claim everyone hates because it's "weird" or "messy".

Oddly enough, those systems they point to are usually in massive use.  I'm not much into channeling Stroustroup, but his point about there being two kinds of systems, "the kind nobody uses and the kind everyone bitches about", seems pretty relevant here.

I mean, how often can you point to any big legacy code base, and say, "Oh, everyone loves that code base.  It was so well designed!  It's just wonderful.  We love working in that big beautiful beast."

The fact is, one person's beautiful code base is another person's nightmare.  Every code base on earth is a code base that someone is just itching to rewrite.  Hell, I wanted to rewrite Emacs at one fairly junior point in my career (in Java, no less), because in my juniorosity I craved the orderliness that Java promised me.  Nowadays I feel like the Emacs code base is a turd that smells... not so bad.  Better than most code bases, even.  Although the lack of unit tests is creating an awful reek.  Jeez, guys!

Action at a Distance

Last topic, very related to the Law/Chaos angle.  I promise:  it's the last topic.

Conservative programmers HATE action at a distance.  Actually that term is way too generic for the small set of ideas I have in mind here, but it's the term conservatives use.

"Action at a Distance" refers to anything that can change the behavior of YOUR code behind YOUR back.  In other words: general extensibility.

This is a pretty serious philosophical divide.  In one camp, we have Emacs, which provides so dizzyingly many ways to conduct action at a distance that you can never, ever be sure how your code is going to work on someone else's system when multiple plugins get together.  Not unlike JavaScript in browsers, really, except Emacs is even more over-the-top in providing a playground for layered, interleaved plugins that all smack each other around as they see fit.

Conservatives frigging hate that idea.  They are extremely attached to their code, since (as we noted before) they want it to be beautiful and orderly and last a long long time.  So anything that allows users to come in and change the private parts of the code puts conservatives into Fight or Flight mode.

Back when I was at, Gregor Kiczales, inventor of Aspect-Oriented Programming (AOP) and Liberale Academique Extraordinaire, came and gave a jaw-droppingly awesome talk about how AOP could allow people to write code that modifies the runtime behavior of other code.

The Amazon Java engineers understood the idea, but not why you'd want to do it.  They asked why, and Gregor said, in a nutshell, "Because sometimes code is Broken, and this gives your users a way to fix it without bothering you."

And the Amazon Java engineers said:  "But Sir, you are mistaken.  Our code is Awesome, and keep your filthy grubby paws off it."

Then I went to Google, and the same thing happened there.

There are all sorts of ways to provide action at a distance.  Classic OOP subclassing is one such way.  If you've so much as glanced around lately, you'll have noticed that subclassing has fallen into extreme disfavor with Java programmers, as they have gradually realized that it lets people do shit that the authors really didn't want them to do, and this makes them very uncomfortable.

In languages where everything is public by default (e.g., Ruby, Python), and especially in languages that have metaprogramming hooks (e.g., Ruby, Python), action at a distance is pretty easy and pretty normal.  Although Pythonistas kind of frown on it, being stodgier than the usual liberal.  They're still liberal, very liberal.  But they're stodgy-liberal.  If you want to use lambdas and metaprogramming and eval and stuff, be prepared to get the Frowny Face from them.  Followed by:  "Well, we're all adults here, so do whatever you want.  Just be warned:  you're inviting chaos!"

Python really straddles the line.  Liberal-ish language, conservative-ish community.  I ranked them as middle-of-the-road "Liberal" in my now-infamous lineup last week.  But I love 'em all the same.

In Java and to some extent C++, the idea of everything being public is side-splittingly comical.  They'd have your head for it.  Not in some allegorical sense, either.  They'd cut your goddamned head off and post it on youtube.

I wrote about this lovely cultural phenomenon in my academic research publication, "Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed".  And oh man, did the Java community ever flip their shit over it.  Search for "steve yegge pile of fetid dingo kidneys" or "steve yegge is an idiot" if you want to see some of the reactions.

At the end of that post, I compared Python's attitude with Java's, with respect to open-source software.  In the Python world, when they open-source something, they recognize that they're basically giving it to you.  If it doesn't meet your needs, but it's close, then hopefully you'll find a hack that forces it to work the way you want.

Whereas in Java-land, they DO NOT want you doing stuff "behind the code's back", even if it's open source!  Even if they're dead and gone!  It doesn't matter to them.  They defined the way it should work, and they carved it in stone, and Tough Shit if you don't like it.  They'd rather have you fork the code base than make it generically extensible (as opposed to narrowly extensible through predefined and probably-wrong channels).

And Java people are moderates!  Well, moderately conservative, anyway.  In strongly-typed languages, they've built protections into the language syntax (and in Clojure's case, into the runtime) to prevent you from EVER accessing something outside its intended scope or purview.  At least in Java you have Reflection as a back-door, if you really need it.

And that's all OK.  Every programmer out there is entitled to their opinion on these issues.

Me, though -- I want to work with programmers who don't need the software equivalents of "Baby on Board" signs on everything.  And nowadays I would rather build throwaway military encampments than cities of stone.

Or put another way, as I once argued in my essay "The Pinocchio Problem", I would rather build living systems than dead ones.  Yes, living systems are scary and unpredictable and they can sometimes bite you.  That's why you want a tiny lion rather than a big one.  But I'll take a real one over a stuffed one any day of the week.

Your mileage may vary!  Stuffed lions are nice too.  Rawr.

Notes from the Mystery Machine Bus

I've spent the past eight years (starting back in June 2004) writing elaborate rants about a bunch of vaguely related software engineering issues.

I was doing all that ranting because I've been genuinely perplexed by a set of "bizarre" world-views held dear by -- as far as I can tell -- about half of all programmers I encounter, whether online or in person.

Last week, after nearly a decade of hurling myself against this problem, I've finally figured it out. I know exactly what's been bothering me.

In today's essay I'm going to present you with a new conceptual framework for thinking about software engineering. This set of ideas I present will be completely obvious to you. You will probably slap yourself for not having thought of it yourself. Or you might slap the person next to you.  In fact you probably have thought of it yourself, because it is so blindingly obvious.

But in my thirty-odd years as a programmer I'm pretty sure this way of thinking about things, if it already existed, has never been mainstream. That assertion is backed by what has to be at least ten Google searches that turned up nothing. So I'm pretty confident.

I'm going to make it mainstream, right now. Watch!

And I suspect this conceptual framework I'm giving you will immediately become, and forever remain, one of the most important tools in your toolkit for talking with -- and about -- other programmers.

The punch line, a.k.a. TL;DR

I won't keep you in suspense. Here is the thesis of this looooong essay. It is the root cause that motivated over half of my ranting all these years, starting at Amazon and continuing here at Google.

(Note: I Do Not Speak For My Employer. This should be patently obvious. When employers want someone to speak for them, they hire a person like the Mouth of Sauron, to make absolutely sure everyone knows they are speaking for the Employer.)

My thesis:

 1) Software engineering has its own political axis, ranging from conservative to liberal.

(Note: Technically, you could stop reading right here and be at pretty much 90% comprehension. In case you care.)

 2) The notions of "conservative" and "liberal" on this political axis are specialized to software engineering. But they exhibit some strong similarities to their counterparts in real-world politics.

 3) Everyone in the software industry who does stuff related to programming computers falls somewhere fairly precise on this political spectrum, whether they realize it or not.

Put another way, YOU are either a liberal or a conservative software engineer. You may be more of a centrist, or maybe an extremist, but you fall somewhere on that left/right spectrum.

Just as in real-world politics, software conservatism and liberalism are radically different world views. Make no mistake: they are at odds. They have opposing value systems, priorities, core beliefs and motivations. These value systems clash at design time, at implementation time, at diagnostic time, at recovery time. They get along like green eggs and ham.

I think it is important for us to recognize and understand the conservative/liberal distinction in our industry. It probably won't help us agree on anything, pretty much by definition. Any particular issue only makes it onto the political axis if there is a fundamental, irreconcilable difference of opinion about it. Programmers probably won't -- or maybe even can't -- change their core value systems.

But the political-axis framework gives us a familiar set of ideas and terms for identifying areas of fundamental disagreement. This can lead to faster problem resolution. Being able to identify something quickly as a well-defined political issue means we can stop wasting time trying to convince the other side to change their minds, and instead move directly into the resolution phase, which (just as in politics) generally boils down to negotiation and compromise. Or, you know, Watergate.

Are real politics and software politics correlated?

Does being a political conservative make you more likely to be a software conservative? I think all we have are hunches and intuition at this point. We'd need studies for an answer with any scientific basis.

But my hunch tells me that they are only loosely correlated, if at all. I suspect that the four possible combinations of political left/right and software left/right each contain around a quarter of the programming population, plus or minus maybe 8%. But that's a totally nonscientific hunch, and I'd love to see the real numbers.

The reason I suspect they're only loosely correlated is that I think a person's software-political views are largely formed by two forces:

 1) Their personal early/formative experiences as a programmer -- in particular, what kinds of decisions either burned them or made them wildly successful.

 2) The software-political core values of their teachers, professors, mentors, role models, and coworkers.

But there are some factors that could increase correlation between political orientation and software orientation. One is geographic/regional influence -- for instance, big tech universities being located primarily in red or blue states. Another might be basic personality traits that may incline people toward traditionally liberal or conservative value systems.

Regardless of how correlated they are, there are going to be a lot of programmers out there who are mildly shocked to find that they are political conservatives but software liberals, or vice-versa.

Isn't the 2-party system a flawed model?

Well, yeah. Mapping something as nuanced as political viewpoints onto a one-dimensional axis is a well-known gross oversimplification. For instance, some U.S. voters may self-identify as fiscally conservative but socially liberal, and as a result may wind up not having a strong tie to either majority political party. These "swing votes" tend to be the reason that political moderates more often wind up winning elections, even though studies have shown that people tend to assign more credibility to extreme opinions.

The influence of centrists or moderates is just as important in the software engineering world, and we'll explore it more in a bit.

But having a single axis still allows for a wide distribution on both the right and the left. As in real politics, a moderately right-leaning viewpoint may seem dishearteningly liberal to someone who lies even further toward the extreme right. I will illustrate with some well-known real-world programming language scenarios in the examples section.

All in all, despite its oversimplifications, I think 2-party model is a good starting point for educating people about the politics of software. It'll be a good frame of reference for refining the model down the road, although that's out of scope for this essay.

So what's a Software Liberal slash Conservative?

If you ignore specific real-world issues, and just focus on the underlying traits and values of real-world conservatives and liberals, it boils down to just a few themes. I'll argue that those underlying themes are also the basis for software politics.

It's easiest to talk first about conservatives, and then define liberals in terms of what conservatives are not. This is because conservatives tend to have a unified and easily-articulated value system, whereas liberals tend to be more weakly organized and band together mostly as a reaction to conservatism. This applies to both real-world and software-world politics.

So we'll start with an operational definition of conservatism, from Jost et al.:

 "We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear."

This theory is explored, re-tested and affirmed in a 2008 study from Garney et. al, "The Secret Lives of Liberals and Conservatives: Personality Profiles, Interaction Styles, and the Things They Leave Behind".

I hope you'll agree that this definition is minimally controversial. After all, the adjective "conservative" is more or less synonymous with caution and risk aversion. Financial conservatism is frequently (and intuitively) associated with age and with wealth. Companies tend to grow more conservative with age as they weather the storms of lawsuits, technical fiascoes, dramatic swings of public opinion, and economic downturns. We even have fables about ants and grasshoppers to teach us about conserving food for the upcoming winter.

Conservatism, at its heart, is really about risk management.

Similarly, liberal views are often associated with youth, with idealism, with naivete. In the corporate world, we think of startups as being prototypically liberal -- in part because they're setting out to change the world in some way (and liberalism is traditionally associated with change), and in part because they have to go all-out in order to hit their scheduled funding milestones, which can justify cutting corners on software safety.

Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised.

To be sure, conservatives think that's what they're maximizing too. But their approach is... well, conservative. Flexibility and productivity are still motivators, but they are not the primary motivators. Safety always trumps other considerations, and performance also tends to rank very highly in the software-conservative's value system.

The crux of the disagreement between liberals and conservatives in the software world is this: how much focus should you put on safety? Not just compile-time type-safety, but also broader kinds of "idiot-proofing" for systems spanning more than one machine.

Let's characterize this core disagreement with some example statements that would be rated with much higher importance by conservatives than by liberals:

1. Software should aim to be bug free before it launches. (Banner claim: "Debugging Sucks!") Make sure your types and interfaces are all modeled, your tests are all written, and your system is fully specified before you launch. Or else be prepared for the worst!

2. Programmers should be protected from errors. Many language features are inherently error-prone and dangerous, and should be disallowed for all the code we write. We can get by without these features, and our code will be that much safer.

3. Programmers have difficulty learning new syntax. We should limit the number of languages used at our company, so that nobody has to learn a new syntax when a system goes down in the middle of the night on Christmas Eve. And we should never permit features that allow defining new syntax, nor changing the semantics of existing syntax. (Common examples: no operator overloading, and NO metaprogramming!)

4. Production code must be safety-checked by a compiler. Any code that cannot be statically checked should in general be avoided. In specific cases where it is strictly necessary, uses of it must be approved by a central committee. (Examples: eval, dynamic invocation, RTTI).

5. Data stores must adhere to a well-defined, published schema. Relational databases must be in third-normal form and adhere to a UML or equivalent schema definition. XML should have a DTD. NoSQL databases and name/value stores -- both of which should be avoided in general -- must have a separate physical schema that defines all permissible keys and their corresponding value types.
6. Public interfaces should be rigorously modeled. Data should never be stored in strings or untyped collections. All input and output entities should be thorougly and explicitly specified via statically-checkable, ideally object-oriented models.

7. Production systems should never have dangerous or risky back-doors. It should never be possible to connect to a live production system via a debugger, telnet shell, nor any other interface that allows the developer to manipulate the runtime operation of the code or data. The only ports into a production system should be read-only monitoring channels.

8. If there is ANY doubt as to the safety of a component, it cannot be allowed in production -- no matter how teams may cry and wail that they need it to make forward progress. (I'm talkin' to you, FUSE).

9. Fast is better than slow. Everyone hates slow code. Code should perform well. You should engineer all your code for optimum speed up front, right out of the box. Otherwise it might not be fast enough. Avoid using languages or DSLs or libraries that have a reputation for being slow.  Even if they're fast enough for your current purposes, the requirements (or callers) could change, and suddenly the software would be too slow!

Of course these examples are meant to be illustrative rather than comprehensive. And obviously not all of them may necessarily be espoused by everyone who self-identifies as a conservative. But barring minor exceptions, they are all very common Conservative viewpoints.

To decide whether a system or a technology is liberal or conservative, just think of a bunch of independent "safety checkboxes". If a majority of them are checked, then the system is conservative as a whole. The more that are checked, the more conservative it is.

By way of comparison, here are the Liberal versions of the nine examples above. It might help to think of Scooby-Doo characters. The examples above are all from Fred, and the examples below are from Shaggy.

1. Bugs are not a big deal. They happen anyway, no matter how hard you try to prevent them, and somehow life goes on. Good debuggers are awesome pieces of technology, and stepping through your code gives you insights you can't get any other way. Debugging and diagnosing are difficult arts, and every programmer should be competent with them. The Christmas Eve Outage scenario never, ever happens in practice -- that's what code freeze is for. Bugs are not a big deal! (This belief really may be the key dividing philosophy between Conservative and Liberal philosophies.)

2. Programmers are only newbies for a little while. The steady state for a programmer's career is being smart, knowledgeable, creative, resourceful and experienced. Putting a bunch of rules in place to protect newbies from doing harm (or being harmed) is incorrectly optimizing for the transient case instead of the steady state.

3. Programmers figure stuff out amazingly fast when their jobs depend on it. People learn to read sheet music, braille, sign language, and all sorts of other semiotic frameworks. Hell, even gorillas can apparently do all that. Programmers don't need protection from syntax. They just need documentation and a little slack time to read up on it.

4. Succinctness is power. Code should be kept small. Period. If your static checking tools can't reason about the code, then the checking needs to be made smarter (e.g. by incorporating runtime data) rather than making the code dumber.

5. Rigid schemas limit flexibility and slow down development. Lightweight/partial/optional schemas are a better tradeoff. Moreover, the schema is often not well-understood until a lot of data is collected and a lot of use cases are thorougly exercised. So the schema should follow the code rather than precede it.

6. Public interfaces should above all else be simple, backward-compatible, and future-compatible. Rigorous modeling is just guessing at how the interface will need to evolve. It makes both forward- and backward-compatibility almost impossible, resulting in interface churn and customer unhappiness. Public interfaces should always do the simplest thing that could possibly work, and grow only as needed.

7. System flexibility can mean the difference between you getting the customer (or contract) vs. your competitor nabbing it instead. Security and safety risks in runtime production systems can be mitigated and controlled by logging, monitoring and auditing. There are plenty of existence-proofs of large systems with root-access backdoors and shells (e.g. RDBMS, online game servers) whose risk is controlled while still giving them world-class runtime flexibility.

8. Companies should take risks, embrace progress, and fiercely resist ossification. It doesn't matter how big your business is: it must grow or die. If you want to stay competitive, you have to make a conscious, often painful effort to take risks. Which means you'll need good recovery techniques for the inevitable disasters. But you need those even if you don't take risks.  So take risks!

9. Premature optimization is the root of all evil. Get the code working first, focusing on correctness over performance, and on iterative prototyping over correctness. Only when your customers list latency as the top priority should you begin performing profiler-driven optimizations.

There you have it: Shaggy vs. Fred.

Just as in real-world politics, software liberals are viewed by conservatives as slovenly, undisciplined, naive, unprincipled, downright "bad" engineers. And liberals view conservatives as paranoid, fearmongering, self-defeating bureaucrats.

Once again, although I don't think the two camps will ever agree, I do think that mutual understanding of the underlying value systems may help the camps compromise.

Or at the very least, the conservative/liberal classification should help the two camps steer clear of each other. I think it is probably better to have a harmonious team of all-liberals or all-conservatives than a mixed team of constantly clashing ideologies. It's a lot like how vehicle-driving philosophies can differ regionally -- it's OK if everyone drives in some crazy way, as long as they ALL drive that way.

So Security Engineers are the most conservative, then, right?

Wrong! The reality here goes against intuition, and I mention it to show how poorly our intuition fares when it comes to interpolating software-political views from job descriptions.

Security engineers are deeply concerned with risk assessment and attack-surface management, so you might well guess that they would naturally tend towards software conservatism.

In practice, however, security engineers tend to be keenly aware of the tradeoffs between caution and progress, since they have to spend big parts of their day meeting with software teams who are often too busy (not to mention woefully underinformed) to spend a lot of time on security. Security engineers learn quickly to make well-informed and practical risk-management decisions, rather than conservatively always trying to be as safe as humanly possible.

Hence many security engineers are in fact software liberals. Some just swing that way.

Many of the security engineers at Google happen to be fans of Ruby -- both as an intrinsically secure language, and also as a nice, expressive language for writing auditing scripts and other security analysis tools. It wound up being fairly easy for me to get security sign-off for using Ruby in production for my first project at Google. In contrast, it was almost career-endingly difficult for me to get the same sign-off from our highly conservative systems programmers.

The reality is that almost any programming specialization is going to be divided into liberal and conservative camps. There are left- and right-wing versions of web developers, persistence engineers, protocol engineers, serving-system engineers, and most other sub-genres of programming.

I'm hard-pressed to think of any domains that tend to be mostly-liberal or mostly-conservative, with the sole exception of Site Reliability Engineering, which is sort of by definition a conservative role. For most of the other domains that initially came to mind -- for instance, data analysts, which at first I thought were uniformly liberal -- I've been able to think of specific teams or subdomains composed entirely of one or the other.

So in the end I think it comes down to personal preference. That's it. I don't think it's as domain-driven as much as it is personality-driven. Some people are just liberal, and some are just conservative, and that's how they are.


Before I continue, I will now issue the important disclaimer that I am a hardcore software liberal, bordering on (but not quite) being a liberal extremist.

This fact, by and large, is what has driven me to pen many of my most infamous and controversial rants, including (among others) "Execution in the Kingdom of Nouns", "Portrait of a N00b", "Rhinos and Tigers", "Code's Worst Enemy", "Scheming is Believing", "Tour de Babel", "Dynamic Languages Strike Back", "Transformation", "Haskell Researchers Announce Discovery of Industry Programmer Who Gives a Shit", and many others besides.

Sure, I sometimes write about other stuff. My in-progress "Programmers View of the Universe" series is motivated by an entirely different bugbear that has nothing at all to do with software politics. My "Universal Design Pattern" article is about a technique that transcends software politics and can be applied with equal effectiveness in either a conservative or a liberal manner. And I've written about video games, Japanese anime and random other stuff.

But I've come to understand that liberalism underlies a tremendous amount of my thinking. Even when I'm writing about management, I see that I am a liberal manager rather than a conservative one. And despite being both relatively old and relatively wealthy, I am also a political liberal -- both socially and fiscally.

Nevertheless I am going to try to represent both sides fairly and accurately in this essay. You know, mostly. I think it's most important for you to buy in to the left/right distinction itself. I think it's far less important whether you happen to agree with my particular side.

I'll consider this essay a success if a sufficient number of you agree that the liberal/conservative distinction is valid for software engineering, and that my particular left/right classification of various technologies and philosophies below seems intuitively reasonable. I'm fine with declaring success if we disagree on a few small details, as long as we agree on the overall picture.

Soooo... static typing enthusiasts are conservative, right?

Why yes. Yes, they are. Static typing is unquestionably one of the key dividing software-political issues of our time. And static typing is a hallmark of the conservative world-view.

In the conservative view, static typing (whether explicit or inferred) is taken on faith as an absolute necessity for modern software engineering. It is not something that one questions. It is a non-issue: a cornerstone of what constitutes the very definition of Acceptable Engineering Practice.

In the liberal's view, static typing is analogous to Security Theater. It exists solely to make people feel safe. People (and airports) have proven time and again that you can be just as statistically secure without it. But some people need it in order to feel "safe enough".

That's a pretty big difference of opinion -- one I'm sure you can relate to, regardless of how you feel about it.

I'm not going to try to defend my view here, since that's what all those old blog posts were for. If I haven't convinced you by now, then there's not much point in continuing to try. I respect your opinion. Well, now. And I hope you now have a little better understanding of mine.

I should, however, mention that there is an unrelated (i.e. politically-neutral) point on which both camps agree: namely, that static types yield better toolchain support. This is undeniably true today, and I have made it my life's work to ensure that it is not true tomorrow.

I have spent the last four years championing an initiative within Google called the "Grok Project", one that will at some point burst beyond our big walled garden and into your world. The project's sole purpose in life is to bring toolchain feature parity to all languages, all clients, all build systems, and all platforms.

(Some technical details follow; feel free to skip to the next section heading...)

My project is accomplishing this lofty and almost insanely ambitious goal through the (A) normative, language-neutral, cross-language definitions of, and (B) subsequent standardization of, several distinct parts of the toolchain: (I) compiler and interpreter Intermediate Representations and metadata, (II) editor-client-to-server protocols, (III) source code indexing, analysis and query languages, and (IV) fine-grained dependency specifications at the level of build systems, source files, and code symbols.

OK, that's not the whole picture. But it's well over half of it.

Grok is not what you would call a "small" project. I will be working on it for quite some time to come. The project has gone through several distinct lifecycle phases in its four years, from "VC funding" to "acceptance" to "cautious enthusiasm" to "OMG all these internal and even external projects now depend critically on us." Our team has recently doubled in size, from six engineers to twelve. Every year -- every quarter -- we gain momentum, and our code index grows richer.

Grok is not a confidential project. But we have not yet talked openly about it, not much, not yet, because we don't want people to get over-excited prematurely. There is a lot of work and a lot of dogfooding left to do before we can start thinking about the process for opening it up.

For purposes of this essay, I'll assert that at some point in the next decade or so, static types will not be a prerequisite for world-class toolchain support.

I think people will still argue heatedly about type systems, and conservatives may never be able to agree amongst themselves as to which type system approach is best for modeling program behavior. But at least I will have helped that discussion be ONLY about representations. The quality of the corresponding developer tools should no longer be a factor in the discussions.

Dividing up the Space

I'm going to go through and toss a bunch of random technologies, patterns, designs and disciplines each into one of six buckets: "apolitical", "conservative", "centrist", "liberal" buckets, plus two buckets that start Centrist and head Left or Right in the presence of overuse. One bucket per thingy. Hey, it's not an exact science. But it should help set the rough foundation for the more detailed use cases below.

Non-political Stuff: Algorithms, data structures, concrete mathematics, complexity analysis, information theory, type theory, computation theory, and so on. Basically all CS theory. These disciplines occasionally inspire tempest-in-a-teapot butthurtedness in academia, but when it happens, it's just similar fish in too small a tank biting on each other. It's to be expected. Overall, these essentially mathematical disciplines are timeless, and they are all equally applicable to both the Liberal and Conservative programming worlds.  Yes, even type theory.

Conservative Stuff: Provably sound type systems. Mandatory static type annotations. Nonpublic symbol visibility modifiers (private/protected/friend/etc.). Strict, comprehensive schemas. all-warnings-are-errors. Generics and templates. Avoidance of DSLs (XPath, regexps) in favor of explicit DOM manipulation and hand-rolled state machines.  Build dependency restrictions.  Forced API deprecation and retirement.  No type equivalence (i.e. no automatic conversions) for numeric types.  Checked exceptions.  Single-pass compilers.  Software Transactional Memory.  Type-based function overloading.  Explicit configuration in preference to convention. Pure-functional data structures.  Any kind of programming with the word "Calculus" in it.

Centrist (or flat-out Neutral) Stuff: Unit testing. Documentation. Lambdas. Threads. Actors.  Callbacks.  Exceptions.  Continuations and CPS.  Byte-compilation.  Just-in-time compilation.  Expression-only languages (no statements).  Multimethods. Declarative data structures.  Literal syntax for data structures.  Type dispatch.

Liberal Stuff: Eval. Metaprogramming. Dynamic scoping. all-errors-are-warnings. Reflection and dynamic invocation. RTTI. The C preprocessor. Lisp macros. Domain-specific languages (for the most part). Optional parameters. Extensible syntax. Downcasting.  Auto-casting.  reinterpret_cast.  Automatic stringification.  Automatic type conversions across dissimilar types.  Nil/null as an overloaded semantic value (empty list, empty string, value-not-present).  Debuggers.  Bit fields.  Implicit conversion operators (e.g. Scala's implicits).  Sixty-pass compilers.  Whole-namespace imports.  Thread-local variables.  Value dispatch.  Arity-based function overloading.  Mixed-type collections.  API compatibility modes.  Advice and AOP.  Convention in preference to explicit configuration.

Centrist Stuff that Becomes Conservative If Taken Far Enough: Type modeling. Relational modeling. Object modeling. Interface modeling. Functional (i.e., side-effect-free) programming.

Centrist Stuff that Becomes Liberal if Taken Far Enough: Dynamic class loading and dynamic code loading. Virtual method dispatch. Buffer-oriented programming.

Woah, that exercise was surprisingly fun! It's far from complete, but hopefully you get the idea.

Some natural themes arise here:

 -- implicit is generally liberal; explicit is generally conservative.

 -- performance-oriented is generally conservative; late-optimized is generally liberal.

 -- compile-time binding is generally conservative; runtime/late binding is generally liberal.

 -- concurrency and parallelism in general seem to be politically charged topics, but the disagreement is orthogonal to the liberal/conservative camps.

I'd love to keep going with the classification. But I'll stop here, since we've got higher-level stuff to discuss.

Examples and Case Studies

I'll walk you through a bunch of examples to show you how just widespread and deep-rooted this political phenomenon is.

Example 1: Languages

Here are some very rough categorizations. Note that within each language camp there are typically liberal and conservative sub-camps. But as a whole, language usage tends to be dominated by what the language makes possible (and easy), so the culture tends to follow the features.

This list is just a few representative examples to give you the flavor. I'm only listing general-purpose languages here, since DSLs and query languages are typically feature-restricted enough to be hard to categorize.

Assembly language: Batshit liberal.

Perl, Ruby, PHP, shell-script: Extremist liberal.

JavaScript, Visual Basic, Lua: Hardcore liberal.

Python, Common Lisp, Smalltalk/Squeak: Liberal.

C, Objective-C, Scheme: Moderate-liberal.

C++, Java, C#, D, Go: Moderate-conservative.

Clojure, Erlang, Pascal: Conservative.

Scala, Ada, OCaml, Eiffel: Hardcore conservative.

Haskell, SML: Extremist conservative.

These are my own categorizations based on my own personal experiences with these languages and their respective communities. Your mileage may vary. However, I'd be quite surprised if you chose to move any of these languages more than a step or two away from where I've positioned it.

One thing that jumps out is that a language doesn't have to be statically-typed or even strongly-typed in order to be conservative overall. More on that in a bit.

The next thing you might notice from the list is that the liberal and moderate languages are all pretty popular, and that popularity declines sharply as languages head into conservative territory.

I think this has a simple explanation: It's possible to write in a liberal language with a conservative accent, but it's very hard (and worse, discouraged) to write in a conservative language with a liberal accent.

For instance, it's straightforward to write JavaScript code in a way that eschews reflection, eval, most automatic type casting, prototype inheritance, and other dynamic features. You can write JavaScript that plods along as unadventurously as, say, Pascal. It doesn't have all the static type annotations, but you can replace them with assertions and unit tests and stereotypically stolid code organization.

But if you try writing your Haskell code with a bunch of dynamic features, well, you're in for a LOT of work. Haskell enthusiasts have managed to implement dynamic code loading and a ton of other ostensibly dynamic features, but it was only through herculean effort.

What's more, if you write your liberal-language code in a conservative way, people will just look at it and say: "Well, it's kinda boring, and you could have saved a lot of coding by using some dynamic features. But I guess it gets the job done. LGTM."

Whereas if you write your conservative-language code in a liberal way, you run the risk of being ostracized by your local language community, because... why are you doing all that dangerous dynamic stuff in the first place? I'll explore this cultural phenomenon further when I talk about Clojure below.

The last big, interesting observation from the list is that a lot of the most popular languages out there are only moderately conservative -- even if they think of themselves as quite conservative compared to their ultra-dynamic cousins.

I've said it before, and it bears repeating here: the reason C++, C# and Java have been particularly successful in the marketplace is that -- just like effective politicians -- they know how to play both sides.

C++ allows liberal-biased programmers to program in straight C, and it allows conservative-biased programmers to layer in arbitrary amounts of static type modeling, depending on how much work they want to expend in order to feel secure. Java?  Pretty much the same story.

Playing to both the fast-and-loose and lock-your-doors mindsets has proven to be a key ingredient to market success.  Also marketing, but it helps a LOT to be viewed as philosophically friendly by both the liberal and conservative camps.

There is a new crop of languages on the horizon (for instance, Google's Dart language, but also new specs for EcmaScript) that are deliberately courting the centrist crowd -- and also delicately playing to grab both the liberals and conservatives -- by offering optional static types. In principle this is a sound idea. In practice I think it will come down to whether the marketing is any good.  Which it probably won't be.

Language designers always seem to underestimate the importance of marketing!

Example 2: Tech corporations

Just for fun, let's contrast four similar-ish tech companies in their software-political outlook.

1) Facebook -- Diagnosis: Extremist Liberal. Despite their scale, they are still acting like a startup, and so far they've been getting away with it. They use primarily C++ and PHP, and they're prone to bragging about how their code calls back and forth from PHP to C++ and back into PHP, presumably bottoming out somewhere. Their datastore is memcached: just name-value pairs.  No schema. They dump the data and logs into a backend Hive store and run Hadoop mapreduces for offline data analysis.  They still hold all-night hackathons every other week or so, which will remain feasible for them as long as the majority of their programmers are very young males (as was the case last time I toured there) and their stock continues to promise great riches (as was not so much the case last I checked.)  As a company they are tightly knit and strongly biased for action, placing a high value on the ability of individual programmers to launch features to their website with little to no bureaucracy or overhead.  This is pretty remarkable for a company as big as they are, with as many users as they have.  Conservatives no doubt regard them with something between horror and contempt.  But Facebook is proving that programmers of any world-view can get a hell of a lot accomplished when they gang up on a problem.

2) -- Diagnosis: Liberal. Which is surprising, given how long they've been in business, how much money is at stake, how mature their Operations division is, and how financially conservative they are. But "Liberal" is actually quite a retreat compared to their early days. Back in 1998-1999 they were almost exactly like Facebook is today, with the sole exception that they put everything in relational databases and did a ton of up-front relational data modeling.  Well, except in Customer Service Apps, where we used a name/value store just to be flexible enough to keep up with the mad chaotic scramble of the business launches.  All part of my multi-decade indoctrination as a Liberal.  In any case, despite many corporate improvements with respect to work-life balance (which happened after several stock plunges and years of significant double-digit turnover in engineering), Amazon has retained its liberal, startup-like engineering core values.  Every team owns their own data and makes their own decisions, more or less like independent business units.  Amazon still launches and executes faster than just about anyone else out there, because they're still willing to take real risks (incurring occasional huge outages), and to make hard decisions in favor of launching early and often.  Above all else, Amazon has proven conclusively that after fifteen years, they can still innovate like nobody else.  They've still got it.

3) Google -- Diagnosis: Conservative. They began life as slightly liberal and have grown more conservative ever since. Google was only software-liberal in the very very early days, back when the search engine itself was written in Python. As they grew, they quickly acquired a software conservatism driven entirely by the engineers themselves.  Manifestos were written about the dangers of using multiple languages, and strict style guides were put in place to severely limit "risky" or "hard to read" language features of the few languages they did allow.  Google's JavaScript code is written in an extremely conservative style with extensive static type annotations, and eval is forbidden.  The Python style guide forbids metaprogramming and other dynamic features, which makes their Python look a lot like untyped Java.  And they have severely limited the use of many C++ language features, with C++11 support rolling out literally one feature every few weeks.  (There are over five hundred new features in C++11.)  In internal surveys, Google engineers commonly cite bureaucracy, churn and complexity as core obstacles to feature advancement and rapid launches.  Google has made serious attempts on several occasions to reduce this bureacracy, but they always get pushback from -- surprise -- the engineers themselves, who have grown so staunchly conservative that they actively (and even more often, passively) resist the introduction of more flexible stacks and technologies.  Most of the major technological shifts within Google over the past half-decade have been overtly conservative.  For a liberal like me, it has been a very sad process to observe.  But at least I've found myself a niche that's widely regarded (by both camps) as valuable, and within my own org we can still be pretty liberal and get away with it.

4) Microsoft -- Diagnosis: Batshit Conservative. Microsoft has two geese that lay golden eggs: Office and Windows. Microsoft has been reduced to a commercial farmer protecting the geese from all incursions.  The golden eggs still have value, because customers are locked into the platform by the cost-ineffectiveness of retraining their fleets.  But Microsoft can no longer innovate in Office or Windows precisely because of those corporate fleet retraining costs.  Their OEMs are stretched as thin as they can go.  Apple is dominating the handheld markets, and Microsoft is actively stifling their own innovation in Windows Phone because they're afraid it will cannibalize their core Windows business.  Microsoft has not had a successful product-level innovation in fifteen, maybe twenty years.  All of their successful products have been copies of competitors' products:  IE, XBox, C#, .NET, Bing, Windows Phone, and so on ad infinitum. All great implementations of someone else's ideas. Microsoft's playbook is to embrace, extend, and leverage their brand to crush the competition -- or at least it was, until the goverment put an end to that circa 2002.  Now the company genuinely doesn't know what the fuck to do with themselves, and what's more, instead of Bill Gates they now have a lunatic in charge.  Employees are leaving in droves, all citing the same internal "existential crisis" and unbearable corporate politics caused by competing business units actively sabotaging one another.  Microsoft has turned into a caricature of right-wing corporatism: sitting on their front porch with a shotgun cursing at passers-by, waiting for their government bribes to give them another few years of subsidies and shelters while they wait to die.  I've personally chatted with close to four hundred current and ex-Microsoft employees over the past seven years.  Oh, the stories I could tell you... someday, maybe.

5) Bonus company: Apple. Diagnosis: no idea, but they're so good at marketing that it's almost irrelevant. Would love to have more insight into their internal software culture, though.  Any takers?  Throwaway accounts?  AMA?

OK, that was a fun exercise too. But we need to move on! Almost done now.

Specific Case Study: The Clojure Language

I've been meaning to follow up on Clojure for a while now. Over a year, at least. But until recently I didn't have the conceptual tools to explain what I wanted to say about it.

Now I do!

Clojure is a new-ish Lisp dialect that runs on the JVM and .NET, and I was honored to write the Foreward to "The Joy of Clojure" a while back. For a few years I had been really excited to start learning Clojure, and my initial experiences with it were quite positive.

However, I eventually learned that the Clojure community is extremely conservative. That is is pretty unusual for a Lisp dialect. Lisp is widely regarded as one of the most liberal language families in existence. And Clojure has the superficial appearance of being a laissez-faire kind of language. It is quite expressive, including a -- ahem -- liberal dose of new syntax. And it eschews static type annotations and strong type modeling in favor of a small set of highly regular, composable data types and operations -- not unlike, say, Scheme or Python.

But the resemblance to a liberal language ends there. Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types (lots of puns today!) who happen to recognize the benefits of Lisp's tree syntax. So under its expressive covers, everything about Clojure is strongly conservative, with a core overriding bias towards protecting programmers from mistakes.

And the community follows suit. At a Clojure conference last year (or was it two years ago? time flies so fast these days...), there was a key presenter doing a talk on how Macros were basically harmful and should be avoided in modern Clojure code.

I trust that if you know anything about Lisp, your blood is basically boiling at this point. I know mine was.

But his argument is perfectly valid from the classic software-conservative's viewpoint. Macros allow you to invent domain-specific language abstractions. Those require documentation in order for users to figure out what they do, and what they mean. That means you can know Clojure and not really know enough to read someone's Clojure code without some documentation handy. Which is sort of the definition of a newbie. And there you have it. In a very real sense, conservatives fear being turned -- in the blink of an eye -- from masters into newbies by the application of macros.

It's sort of scary if you have a lot of your personal identity invested in knowing some shit. And wouldn't you know it, real-world politics conservatives are shown in study after study to be "staunch" in sticking to their world views rather than compromising. That means they have a lot of identity tied up in those views.

So while I liked a lot of what I saw in Clojure, as a hardcore software liberal I was inevitably and inexorably driven away from the language. And that's good for me, and it's good for Clojure. I mean, why should they compromise?

I think that my conceptual framework gives us an "out" -- a way to avoid being emotional about these subjects. Casting the problem as a clash between Liberalism and Conservsatism gives us the ultimate ticket for "agreeing to disagree".

Hopefully it will also help language designers and communities do a better job of targeted marketing. Right now just about every language out there makes a claim along the lines of "This language is the best choice for everybody!" But now we know that is very unlikely to be true -- or if it is, we can at least be assured that they're centrists, and they run the risk of being equally distasteful to everybody.

In the conservative/liberal framework, language designers can make more accurate, less bait-and-switchy claims; for instance: "Haskell is the best choice for every radical extremist conservative programmer!"

Well, we can work on the wording. But you get the idea.


I was thinking of going through a bunch more examples and stuff, but I see that I'm on my third (Editor's Note:  fourth) glass of wine, which means my typing is about to give out any minute.

So let's wrap it up!

There's one kinda key point I wanted to get across, but didn't see a good place for it. That point is this: please do not be alarmed that I am calling you a (software) Conservative.

I worry that politically left-leaning programmers will hear the term "conservative" and will immediately associate it with all of the... uh, politically-charged connotations associated with far right-wing conservatism in the United States political arena today. You know, racism, sexism, religious fundamentalism, homophobia, warmongering, bear-shooting, that kind of thing.

I'm not saying they're bad, at least not in this essay. I'm just saying nobody in their right mind wants to be associated even remotely with those embarrassing wingnuts. See what fine-grained, nuanced distinctions three (Editor's Note: four) glasses of wine can produce? But I'm not saying their views are bad. No. Not here.  I'm just observing that they're heavily politically charged viewpoints which have, for better or worse, recently come to be associated with the term "conservatism" in US politics.

So please do me a favor and try to dissociate those specific agendas and real-world political viewpoints from the generic term "Conservative", which here really just means "risk averse".

It's perfectly OK, and normal, to be a programming conservative. You don't have to shoot any bears. I would actually like to see the terms "liberal" and "conservative" to become badges of honor in the programming world. People should stand behind their beliefs. I mean, we do already, I think, so it shouldn't be much of a stretch to allow our beliefs to be given convenient labels.

Ah, me. I can see the Euphemism Treadmill rearing its ugly head already. We'll see.

Anyway, tell me what you think! I welcome any and all viewpoints and comments. Even from bears!

Special thanks to Writer's Block Syrah for reviewing this post for career suicide.

(Special Note to my fellow Googlers:  Yes, I meant to post this externally.  BOTH times.  No, I am not the Mouth of Sauron.)

I've tried writing another Amazon War Story a couple of times, but so far no luck. It's not Writer's Block. I can write plenty. This time my problem is Writer's Crap. So today I'll try something different, and write about working at Google.

The main problem with writing about Google is that nobody will believe you.

My friend +Dominic Cooney and I were talking about it one time. I told him I felt this secret guilt every time I went to work, because everyone was so smart and they treat you so well. I told him I truly felt like I didn't deserve it.

Dominic said he knew what I meant, and that every day at Google he felt like he'd won the lottery.

It's crazy. This guy is hands-down one of the smartest people I've ever worked with in my life, and he told me that working at Google felt like winning the lottery. How many of you can honestly say that about your job? I mean, sure, Amazon felt like that to me sometimes, but it was more like Shirley Jackson's lottery.

I've been wanting to write up how it really is here, but it's too much. It's like trying to introduce you to warm chocolate cake by forcing you to swim through a lake of it. I remember once my brother Dave and I bought the biggest pieces of chocolate we could find in Ghirardelli's Square in San Francisco, and we ate chocolate until we couldn't choke any more down. The next morning I woke up to Dave waving a hunk of chocolate in front of my nose, saying: "Want some choooooocolate?" and I almost puked.

It's kind of like that. My challenge is to find a way to describe Google to you without making you puke.

Speaking of Ghirardelli's Square, my Amazon pager went off while I was there once, on vacation, and I had to dial in to a conference call about a site outage while I was eating my ice cream. My challenge with Amazon is finding a way to describe it without making me puke. But I'll figure something out, eventually. In many ways they're a world-class operation -- primarily in ways that matter to their customers; employees, not so much. But I guess in the end it's the customers that matter.

Anyway, until I figure that one out, I guess I'll write about Google.

Google has offices all over the world, dozens of them, and I've only been to a few. So I'll tell you about Google Kirkland, where I work. It's a pretty average office in terms of size, location and perks. But it's what I know best.

Here's what it's like in Google Kirkland. At least, here's a little piece of it, on a little plate with a white napkin and a silver fork. Enjoy.


At Google there's a lot of food. Everyone at other companies just shrugs it off as "free food", which is sort of like shrugging off Google's giant yearly bonuses as "occasional tips". In our three little buildings here we have three cafeterias, at least six or eight kitchen areas filled with free snacks, two espresso cafes staffed with barristas, a 1950s-style dessert bar, a frozen yogurt machine with a self-serve toppings bar, probably a dozen fridges filled with free drinks, a weekly Farmer's Market all summer where you can take home huge bags of locally-grown veggies, and every Friday afternoon, long tables of themed hors d'oeuvres and beer and wine while we watch TGIF. Am I forgetting anything? I'm sure I am.

And the food is good. One of our chefs was the Executive Chef at the Earth and Ocean restaurant in the W hotel in downtown Seattle, and the other one had equally impressive credentials. The cafe in my building, Sudo Cafe, has a DIY burger bar, daily entree selections, a pizza bar, a sandwich bar and panini press, a rotisserie, a salad bar, a fruit bar, two daily soup selections, a vegetarian and vegan selection, and random bowls of fruit and cakes and all sorts of other stuff lying around to tempt you. To me it feels like Ofelia's second task in Pan's Labyrinth, except look ma, no monster.

There are three meals a day, five days a week, all you can eat for free. You can even bring guests to lunch. The salad and sandwich and espresso bars stay open between meals, and the micro-kitchens are open 24x7. And for those who wonder whether it's OK to take some food home once in a while, there are take-out containers sitting right next to the plates.

Amusingly, every other Google office I've ever been to had better food than we do. The old NYC office had an olive bar that was longer than the one at Whole Foods. The Seattle office has microbrews on tap. The Mountain View main campus has more than forty cafes and restaurants. Kirkland's food has been catching up fast in the past year or two, but the bar is insanely high.

Why all the free gourmet food? I don't know. Maybe they're planning to cook us and eat us. That's the most plausible explanation we've been able to think of. That, and the fact that we're never tempted to leave the campus at lunchtime or afternoon-tea time, so we all wind up working at least an extra half an hour a day. But that can't possibly be a sufficient return on investment for Google, not by a long shot.

I think the real explanation is that they do it because that's part of how you create an environment that attracts the smartest people in the world. I'm not in that category, but for a while I was gunning for fattest person in the world, so they managed to attract me too.


There's free underground parking, but there aren't quite enough spots. So they have a free valet service. The valets park your car and bring your keys up to your office later in the day. (Amazon never had free parking. As far as I know, they still don't.)

The decor at Google is colorful and makes the whole place feel more fun. I know it doesn't seem like a big deal. Who cares about the decor, right? But I've worked in typical cube-farm companies, and there's something magical about Google's decor. I've been to Microsoft a few times, too. Their decor is opulent and fancy, like going to the Waldorf-Astoria hotel. Google's decor is more like walking into an FAO Schwarz toy store.

The cafe in our newest building has a nautical theme. It has hardwood floors the color of a boat deck, and big rope spools turned sideways into tables, and portholes that look through a hallway decorated with ship-deck furniture onto a huge wall mural of downtown Seattle. Oh, and there are boats. I gave my brother Mike and his friend Jay a tour of the place over the weekend, and Jay was trying really hard not to be impressed. He started to crack when he saw the gym, but it was the boats that finally got him.

"How did they get them IN here?" was Mike's question. Mike's got his own construction company and has worked with heavy equipment, and all he could do was marvel at these big frigging boats on the second floor. They're these, I dunno, roofed gondola-looking boats with leather bench-seats. They're there so you can have an impromptu meeting on a boat, or work on your laptop on a boat, or just hang out on a boat and have some espresso and soak up that nice boat feeling, I guess.

Downstairs one of the video-conference rooms has comfy leather chairs and wall-to-wall murals of farmland scenery, and a stable with a bunch of hay and a couple of horses. Yep, you heard that right. They startle the crap out of people the first time they go in there. Couple o' great big stuffed horses like you might find at, say, FAO Schwarz.

I mean, don't get me wrong here. Amazon had some decor too. And by "some decor", I mean a Cave Bear. One day a Cave Bear skeleton showed up, standing a good ten or twelve feet high, complete with an anatomically-correct dick-bone attached to its pelvic region with a movable steel wire. It became a sort of ad-hoc weathervane for employee morale.

Just as with the food, I could go on for chapters about the facilities and probably never finish, because they keep adding new stuff. There's a climbing wall, and pool tables, and foosball tables, and a bunch of $5000 fancy massage chairs with incomprehensible Japanese instructions. Man they feel nice though. There's a super nice 24-hour gym, and lush real plants everywhere, and a doctor's office with a full-time Google doctor, and a haircut place where the Corporate Cuts lady comes by a few times a week.

Oh, and there's a massage salon with three or four licensed massage therapists. That's a Google tradition. Ours is subsidized down to practically no cost for an hour-long table massage. And there are prayer rooms, and a basketball court, and a dog park with Google-colored fire hydrants to pee on, and breast-feeding rooms for new moms, and electric-car spots, and a red British phone booth that I assume is for changing into superhero costumes, and gigantic oversized lava lamps, and comfy couches around roaring fireplaces, and a photo booth, and a bike cage with a tool bench and an air compressor, and hammocks and bean-bag chairs, and a room-length shuffleboard table, and three or four game rooms with air hockey and ping-pong and XBoxes and Wiis and arcade games with thousands of titles, and on and ON and ON.

I mean, damn. You thought I was exaggerating when I told you nobody would believe me, didn't you?

And sadly I can't even tell you about the two new coolest things they're opening here, because they won't officially launch until next week. But it's always like that. I've been putting this post off for years because there's always some new thing in the works that I want to wait for before I tell you about it all.

Amazing True Story: One day I started getting jealous of this digital piano that people were playing every day. So I sent a nice email to someone in facilities asking if there was any chance we might be able to get a guitar. She said it sounded like a good idea and she promised to look into it.

A month went by, and I started to get a little sad, because I thought they were just not interested. But I sent her a little email and asked if there was any update. Just hoping, you know, against hope.

She told me: "Oh yeah, I'm sorry -- I forgot to tell you. We talked it over with the directors, and we all decided the best thing to do was to build a music studio."

So now we have Soundgarden over in Building A. It has two rooms: one with soundproofing and two electric guitars and a bass and a keyboard and a drum set and a jam hub and amps and all kinds of other crap that I can't identify except to say that it's really popular. The other room has a ukulele and some sort of musical drum and a jazz guitar and some other classical instruments.

Remember back in the first paragraph of my infamous rant, where I made the bizarre claim that "Amazon does everything wrong, and Google does everything right?" It's a pretty complex claim to try to explain, but I feel like the "Ask for a guitar, get a music studio" story is one of the best metaphors for how the two companies operate. At Google, when they're faced with any kind of problem at all -- anything -- they step back and ask: "What is the first-class way to solve it?" Whereas at Amazon, I wouldn't even have been able to ask the question, because there's nobody to ask. Amazon's facilities team is tiny, and they spend all their time trying to solve the problem of squeezing more employees into less space.


Google has twelve paid holidays a year in the US. In contrast, Amazon had five, at least when I was there. At Google we get two days at Christmas, two at New Year's, two at Thanksgiving, and then six others. Pretty nice.

Every year we have a company morale trip. One year they put us up for the night at the Whistler ski resort, including a fancy bus ride there and back, a fancy hotel room, free rental equipment and lift tickets, free lessons if we wanted them, and of course a massive party with a live band and giant dinner and open bar and a chocolate fountain and mechanical bull and whatnot. You know, the usual.

Actually +Adam de Boor tells me I missed some stuff. He went dogsledding, and you could alternately go snowmobiling or get spa treatments or choose some other options we've both forgotten now. Psh. That was so last year.

This year we had two trips -- you could pick whichever one you liked better. Half of us went skiing overnight and the other half went to Vegas. I went skiing, but I heard Vegas was pretty awesome. As you might expect.

But regardless of which trip you picked, everyone got to go to a Vegas "practice night" a few weeks before the trip. They set up a casino in the cafeteria, catered by some local company that provides tables and dealers. The dealers gave lessons to anyone who wanted to learn to play craps or poker or blackjack or roulette. Craps is frigging complicated, so I went and played poker until I was too drunk to see my cards anymore, and went and crashed on a couch upstairs. I do remember at one point some guy pushed all his chips at me and left, even though he hadn't lost or anything. I didn't even see who it was, but if it was you -- thanks!

The morale trip for every Google office is different, and usually different each year. One year down in Mountain View they took everyone skiing in Lake Tahoe. Another year they rented out Disneyland.

Every December we have a huge holiday party. Everyone dresses up (well, it's Seattle, so it's not that dressy). They do the casino thing there too, and you get a thousand "dollars" of fake money in chips that you can spend at the casino, with the overall winner getting an iPad or some such. The holiday parties are my favorite. You bring your S.O. and get your pic taken with Santa. And they bring arcade games and golf cages and table games and sometimes even those big outdoor inflatable carnival games, except they're indoors and you compete on them while you're hammered.

Last year was the best one yet -- they rented out the Experience Music Project and Pacific Science Center in downtown Seattle, and threw the party there. It was amazing.

We just had our yearly Halloween party. There were like 300 kids there, all going through this elaborate scary haunted-house setup in one of the auditorium rooms, and then going office-to-office to trick-or-treat. The whole campus was decorated with Halloween decor -- spiders and cobwebs and stuff that you see all year round at some companies. It was nice.

Every summer we have a company picnic, and you can bring your whole family. Last summer they had hiking and golf and horseback riding and rafting and carnival games and rides and huge outdoor barbecues and who knows what else. They pretty much had me at "golf", so I didn't pay much attention to the other attractions.

Every single week Google has TGIF, where Larry and Sergey and various VPs go up on stage and give a report on the exciting stuff that's happened in the past week, and then field questions from Googlers. There is a site where you can submit questions for that week's TGIF, and vote questions up or down. So by the time TGIF rolls around, the top questions are the really burning ones that everyone wants answered. And you can ask about anything. They even take live questions from an open mic in the audience. And there's always beer and wine, so the live questions tend to be rather pointed and direct, at least when they're intelligible.

Contrast that with Amazon, where they have something similar, but it's quarterly, and you have to write your questions down on index cards that are then vetted by some secret cabal who chooses which questions are suitable for Jeff Bezos to answer.

In addition to our yearly morale offsite, and the holiday party, and the halloween party, and the summer picnic, and the weekly TGIF, and any other regularly-scheduled parties I've overlooked, Google also has random other parties and offsites all the time. We all go bowling every now and then, and they take us all to movie premieres when something extra cool comes out (anything from Harry Potter to An Inconvenient Truth), and we sometimes just go down to the lake and have a catered lunch at the pavilion when the weather is nice.

We also have guest lecturers, and performances from bands, and seemingly random other "stuff". You can never predict what it will be. Sometimes we get fancy gifts for no apparent reason. Last year we all got "Fireswords", which are these insanely bright $400 flashlights that we had to sign waivers for because they can actually blind you, presumably in an attempt to generate more grass-roots interest in Accessibility. Another time they gave us all Earthquake Preparedness Backpacks, which are these black packs that weigh about a thousand pounds. I have no idea what's in mine, but it feels heavy enough to keep the building from moving during an earthquake.

Every year they give us a holiday bonus and a holiday gift. A couple years in a row we got Android phones. I'm still using my latest one. I don't think there's any guarantee that we'll get a holiday gift every year, but so far they've seen fit to give us all gifts, and I don't hear anyone complaining.

At Amazon they were always terrified that they'd create a sense of entitlement, so they never gave us anything. They went to great lengths to avoid instilling a sense of entitlement in the employees, and they often talked about this philosophy publicly.

Google handles the entitlement problem by not giving a shit. They just keep on throwing stuff at us: gifts and perks and activities and facilities and benefits and vacations and lord knows what else. And guess what? There is almost no sense of entitlement here. When it does come up, Googlers self-police: they'll publicly ridicule anyone who complains that the brownies aren't sweet enough, or whatever.

The only people who I think don't really "get" it, who don't realize just how different Google is from the Real World, are college hires who've never worked anywhere else. I always tell people we should have a "slap an intern" program, just to give them a little taste of what working at other places is like. I feel kind of bad for them, should they ever have the misfortune to go work somewhere else. It will be quite a shock for them.


Like I said: this could be a book. I haven't even begun to talk about the amazing equipment we get. Or the incredible travel policies. Or how easy it is to request special software or hardware or ergonomic equipment. Or the astounding lengths they'll go to in supporting employees with disabilities. Or the peer-committee promotion process. Or the software engineering culture. Or any of the gazillion other amazing things about this place.

Like I said: it's too much. And half of you probably wouldn't believe me anyway. I sure as hell didn't believe my recruiter when she was telling me about this place seven years ago.

Are there downsides? Sure. A few. The food can make you fat. The environment can make you spoiled. The smart people around you can give you Degree Envy. Some people don't do well with the lack of structure, since it's geared towards self-motivated people who figure out what to work on. You can even wind up on a project that's got a little too much heat on it, and be briefly miserable -- but compared to daily life at most companies, that misery is pretty well soaked in sugar frosting.

I hope this puts a little more context around some of the things I've said about Amazon, though. I would guess that Amazon is in the bottom half of the industry in terms of being a nice place to work -- but not in the bottom 25%. I've seen much worse than Amazon. Heck, pre-2000 Amazon was much worse than today-Amazon. Overall I'd say that today they're probably just a little below the average, industry-wide.

So comparing Amazon to Google is a little unfair, because comparing anyone to Google is unfair. Google's undoubtedly in the top 0.1% of the best places to work in the world, across anything even remotely computer-related.

Hopefully it helps you understand a little better where I was coming from. I didn't really use the right wording before, when I said that Google does everything "right". It's more accurate to say they do everything awesome.

Is this stuff worth writing a book about? You tell me!

[Thanks to my friend +Adam de Boor for reviewing and improving this post, and also for reviewing its awful predecessor that thankfully I didn't publish.]

Last week I accidentally posted an internal rant about service platforms to my public Google+ account (i.e. this one). It somehow went viral, which is nothing short of stupefying given that it was a massive Wall of Text. The whole thing still feels surreal.

Amazingly, nothing bad happened to me at Google. Everyone just laughed at me a lot, all the way up to the top, for having committed what must be the great-granddaddy of all Reply-All screwups in tech history.

But they also listened, which is super cool. I probably shouldn’t talk much about it, but they’re already figuring out how to deal with some of the issues I raised. I guess I shouldn’t be surprised, though. When I claimed in my internal post that “Google does everything right”, I meant it. When they’re faced with any problem at all, whether it’s technical or organizational or cultural, they set out to solve it in a first-class way.

Anyway, whenever something goes viral, skeptics start wondering if it was faked or staged. My accident was neither. While I have no proof, I can offer you what I think is the most convincing evidence: for the last six and a half years, I have never once ragged on Amazon publicly. Even just two months ago, in a keynote talk I gave at a conference, I was pretty flattering when I talked about my experiences there. I’ve always skirted any perceived shortcomings and focused on what they do well.

I still have a lot of friends at Amazon. In fact the place is chock-full of people I admire and respect. And up until now I have prided myself on my professionalism whenever I have talked about Amazon. Bagging on the company, even in an internal memo, was uncharacteristically unprofessional of me. So I’ve been feeling pretty guilty for the past week.

So. Without retracting anything I said, I’d like to paint a more balanced picture for you. I’m going to try to paint that picture via some true stories that I’ve never shared publicly. Nothing secondhand: it’s all stuff I witnessed myself there. I hope you’ll find the stories interesting, because it’s one hell of an interesting place.

Since Amazon started with Jeff, I’ll start my stories with one about Jeff.

Amazon War Story #1: Jeff Bezos

Over the years I watched people give presentations to Jeff Bezos and come back bruised: emotionally, intellectually, often career-ily. If you came back with a nod or a signoff, you were jumping for joy. Presenting to Jeff is a gauntlet that tends to send people back to the cave to lick their wounds and stay out of the sunlight for a while.

I say “presentations” and you probably think PowerPoint, but no: he outlawed PowerPoint there many years ago. It’s not allowed on the campus. If you present to Jeff, you write it as prose.

One day it came time for me to present to Jeff. It felt like... I don’t know, maybe how they swarm around you when you’re going to meet the President. People giving you last-minute advice, wishing you luck, ushering you past regiments of admins and security guards. It’s like you’re in a movie. A gladiator movie.

Fortunately I’d spent years watching Jeff in action before my turn came, and I had prepared in an unusual way. My presentation -- which, roughly speaking was about the core skills a generalist engineer ought to know -- was a resounding success. He loved it. Afterwards everyone was patting me on the back and congratulating me like I’d just completed a game-winning hail-mary pass or something. One VP told me privately: “Presentations with Jeff never go that well.”

But here’s the thing: I had already suspected Jeff was going to like my presentation. You see, I had noticed two things about him, watching him over the years, that others had either not caught on to, or else they had not figured out how to make the knowledge actionable.

Here is how I prepared. Amazon people, take note. This will help you. I am dead serious.

To prepare a presentation for Jeff, first make damn sure you know everything there is to know about the subject. Then write a prose narrative explaining the problem and solution(s). Write it exactly the way you would write it for a leading professor or industry expert on the subject.

That is: assume he already knows everything about it. Assume he knows more than you do about it. Even if you have groundbreakingly original ideas in your material, just pretend it’s old hat for him. Write your prose in the succinct, direct, no-explanations way that you would write for a world-leading expert on the material.

You’re almost done. The last step before you’re ready to present to him is this: Delete every third paragraph.

Now you’re ready to present!

Back in the mid-1800s there was this famous-ish composer/pianist named Franz Liszt. He is widely thought to have been the greatest sight-reader who ever lived. He could sight-read anything you gave him, including crazy stuff not even written for piano, like opera scores. He was so staggeringly good at sight-reading that his brain was only fully engaged on the first run-through. After that he’d get bored and start embellishing with his own additions.

Bezos is so goddamned smart that you have to turn it into a game for him or he’ll be bored and annoyed with you. That was my first realization about him. Who knows how smart he was before he became a billionaire -- let’s just assume it was “really frigging smart”, since he did build Amazon from scratch. But for years he’s had armies of people taking care of everything for him. He doesn’t have to do anything at all except dress himself in the morning and read presentations all day long. So he’s really, REALLY good at reading presentations. He’s like the Franz Liszt of sight-reading presentations.

So you have to start tearing out whole paragraphs, or even pages, to make it interesting for him. He will fill in the gaps himself without missing a beat. And his brain will have less time to get annoyed with the slow pace of your brain.

I mean, imagine what it would be like to start off as an incredibly smart person, arguably a first-class genius, and then somehow wind up in a situation where you have a general’s view of the industry battlefield for ten years. Not only do you have more time than anyone else, and access to more information than anyone else, you also have this long-term eagle-eye perspective that only a handful of people in the world enjoy.

In some sense you wouldn’t even be human anymore. People like Jeff are better regarded as hyper-intelligent aliens with a tangential interest in human affairs.

But how do you prepare a presentation for a giant-brained alien? Well, here’s my second realization: He will outsmart you. Knowing everything about your subject is only a first-line defense for you. It’s like armor that he’ll eat through in the first few minutes. He is going to have at least one deep insight about the subject, right there on the spot, and it’s going to make you look like a complete buffoon.

Trust me folks, I saw this happen time and again, for years. Jeff Bezos has all these incredibly intelligent, experienced domain experts surrounding him at huge meetings, and on a daily basis he thinks of shit that they never saw coming. It’s a guaranteed facepalm fest.

So I knew he was going to think of something that I hadn’t. I didn’t know what it might be, because I’d spent weeks trying to think of everything. I had reviewed the material with dozens of people. But it didn’t matter. I knew he was going to blindside me, because that’s what happens when you present to Jeff.

If you assume it’s coming, then it’s not going to catch you quite as off-guard.

And of course it happened. I forgot Data Mining. Wasn’t in the list. He asked me point-blank, very nicely: “Why aren’t Data Mining and Machine Learning in this list?” And I laughed right in his face, which sent a shock wave through the stone-faced jury of VPs who had been listening in silence, waiting for a cue from Jeff as to whether he was going to be happy or I was headed for the salt mines.

I laughed because I was delighted. He’d caught me with my pants down around my ankles, right in front of everyone, despite all my excruciating weeks of preparation. I had even deleted about a third of the exposition just to keep his giant brain busy, but it didn’t matter. He’d done it again, and I looked like a total ass-clown in front of everyone. It was frigging awesome.

So yeah, of course I couldn’t help laughing. And I said: “Yup, you got me. I don’t know why it’s not in there. It should be. I’m a dork. I’ll add it.” And he laughed, and we moved on, and everything was great. Even the VPs started smiling. It annoyed the hell out of me that they’d had to wait for a cue, but whatever. Life was good.

You have to understand: most people were scared around Bezos because they were waaaay too worried about trying to keep their jobs. People in high-level positions sometimes have a little too much personal self-esteem invested in their success. Can you imagine how annoying it must be for him to be around timid people all day long? But me -- well, I thought I was going to get fired every single day. So fuck timid. Might as well aim high and go out in a ball of flame.

That’s where the “Dread Pirate Bezos” line came from. I worked hard and had fun, but every day I honestly worried they might fire me in the morning. Sure, it was a kind of paranoia. But it was sort of healthy in a way. I kept my resume up to date, and I kept my skills up to date, and I never worried about saying something stupid and ruining my career. Because hey, they were most likely going to fire me in the morning.

Thanks to Adam DeBoor for reviewing this post for potential Career Suicide.

As you can imagine this has been a pretty stressful week for me. But it hasn't been all bad. On Thursday I was given an honorary Darwin Award, and on Friday they crowned me Miss South Carolina.

Hi external-world folks,

I posted a long opinionated rant tonight about how I think Google could be doing a much better job of thinking from the ground up in terms of services rather than products. Sadly, it was intended to be an internal post, visible to everybody at Google, but not externally. But as it was midnight and I am not what you might call an experienced Google+ user, by the time I figured out how to actually post something I had somehow switched accounts.

I've taken the post down at my own discretion. It was kind of a tough call, since obviously there will be copies. And everyone who commented was nice and supportive.

I contacted our internal PR folks and asked what to do, and they were also nice and supportive. But they didn't want me to think that they were even hinting at censoring me -- they went out of their way to help me understand that we're an opinionated company, and not one of the kinds of companies that censors their employees. That was cool and all, but I still didn't know what to do.

So I made the call myself and deleted it. Part of the reason is that for internal posts, it's obvious to everyone that you're posting your own opinion and not representing the company in any way, whereas external posts need lots of disclaimers so people don't misunderstand. And I can assure you, in case it was not obvious, that the whole post was my own opinions and not Google's. I mean, I was kind of taking them to task for not sharing my opinions. :)

The other reason I deleted it is that it's really a private conversation between me and my peers and co-workers at Google. I love working at Google, and I especially love the fact that I'm comfortable posting something as inflammatory as my post may have been. The company is super open internally, and as I said several times in my post, they really try hard to do everything right. That includes being open to strongly differing opinions, and that has certainly not been true at every company I've worked at.

There are of course lots of parts of my post that I'd love to talk about externally, except I'm kinda lazy and complacent these days. Please realize, though, that even now, after six years, I know astoundingly little about Google. It's a huge company and they do tons of stuff, and I work off in a little corner of the company (both technically and geographically) that gives me very little insight into anything else going on there. So my opinions, even though they may seem well-formed and accurate, really are just a bunch of opinions from someone who's nowhere near the center of the action -- so I wouldn't read too much into anything I said.

Anyway, as soon as I've got a good night's sleep (unlikely at this point, but I can try), I'll repost it internally.

I think I've finally found someone worse at math than I am.

Dunno what G+ did with my link, so...

Post has attachment
I shot a 1.23 million on the Buzz Astro Blasters ride at Disneyland this weekend. If you thought I was some kind of ordinary dork, well, think again, Space Ranger.

My "Poor Steve" post yesterday was was about +Steve Lacey, a friend and fellow Googler who was killed by a drunk driver on Sunday. I found out about it as I was driving back from OSCON in Portland. I apologize for any confusion, but no, I did not mean myself.

Just got back from Portland and heard the news. Poor Steve. He was a really, really, really good guy. I hung out with him at work almost every single day. I feel terrible for him and his family. Unbelievable. Just unbelievable. Steve, man, I'm really going to miss you.
Wait while more posts are being loaded