Coding Horror

On the internet, you can pretend the world is flat. Whatever country you live in, whatever language you speak, you have the same access to the accumulated knowledge of the world as every other citizen of the planet Earth. And a growing percentage of that knowledge can and should be available in your native language.

But I believe the rules are different for programmers. So much so that I'm going to ask the unthinkable: shouldn't every software developer understand English?

A wildly disproportionate amount of programming information is available in English. The overwhelming majority of programming languages use English keywords. By any metric you can possibly measure, English is the lingua franca of programming.

Now, In terms of cultural literacy and travel, presuming that everyone should speak English is a totally unacceptable attitude, the epitome of the ugly american.

But those rules don't apply to us.

We're not talking about normal everyday people. We're talking about programmers. Citizens of the internet. People who swear allegiance not to a country, but a compiler. Hackers have their own culture, their own norms and standards for literacy. Eric Raymond notes that functional English is required for true hackers:

As an American and native English-speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet, and that you will need to know it to function in the hacker community.

Back around 1991 I learned that many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. For similar reasons, translations of technical books written in English are often unsatisfactory (when they get done at all).

Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following.

Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong -- and we have no use for sloppy thinkers. If you can't yet write competently, learn to.

It's difficult to communicate this idea without feeling like an ugly American programmer. But it doesn't come from a nationality, or a desire to dominate the world. It's nothing more than great hackers collectively realizing that sticking to English for technical discussion makes it easier to get stuff done. It's a meritocracy of code, not language, and nobody (or at least nobody who is sane, anyway) localizes programming languages.

I received this email from Slawomir, a Polish programmer, a few months ago. He confirmed what I've always suspected and secretly believed -- but have been hesitant to say:

I just listened to Stack Overflow podcast episode 29 where you discuss localization of developer tools.

In my opinion there is no reason to translate developer tools and documentation.

I know many developers in Poland who prefer (as Joel mentioned) to get English documentation rather than Polish translation and the reason for that is that translations were not always accurate. Even Microsoft developer documentation was translated partially or with errors, so reading original English document was easier than English-Polish soup.

If everybody blogs and develops in English - our global repository of solutions and blog posts is much bigger and you have better chances of finding an answer to your problem.

Consciously choosing to switch from Polish to English reminds me why I gave up Visual Basic for C#, as painful as that was. These languages do exactly the same things -- and the friction of choosing the minority language was severe. I found reams of code and answers in C# whenever I searched, and almost nothing at all in VB.NET. I spent so much time converting code into VB.NET and introducing new bugs and errors in the process, along with countless language-only forks. This eventually stopped making sense to me -- as it would to any good programmer.

Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits. If that makes me an ugly American programmer, so be it.

Have you ever considered paying for, or sponsoring, a

• bug fix
• new feature
• plugin
• small tweak to existing functionality

... for software that you use?

I don't mean waiting for a new release of the software, which will contain a bunch of new features you may or may not care about, along with all new bugs. I'm talking about making a very specific request for existing software happen through financial sponsorship.

Sure, if the software you're using happens to be open source, you can theoretically download the source code, roll up your sleeves, and code it yourself.

If you have a very strong desire to see a particular feature implemented, your odds of success of ultimately having it become a part of the tool are dramatically increased if instead of asking for it to be implemented, you check out a copy of the latest source code tree, code it yourself (even if slightly incomplete or somewhat buggy), and submit it for peer review by the existing developer pool. Other technical parties are far more likely to help you complete a worthwhile code enhancement that you've clearly put time and thought into than they are to remotely consider doing what you want from scratch just because you want it.

Of course, not all end-users have the technical acumen or programming experience to bring such things to reality. You have three options: a) find a programming friend that you can get excited about your idea and have him follow the above paragraph, b) live without the feature and enjoy the software you have been provided free and proves useful to many others, or c) find a different software package that does do what you want.

But how realistic is this for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that?

Sometimes, when people say this:

The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?

They're really saying this:

F**k you.

That seems a bit harsh to me. Surely there's something between the extremes of "give up" and "code it yourself."

Why isn't there a service to aggregate and pool funds to sponsor programming particular features or bugfixes in open source software?

There are many end-users willing to pay for improvements to free software and writing new programs. There are also many talented programmers wanting to get paid to work on free software. Allow end-users to escrow payments that are pooled together to pay developers for implementing features / writing software. A panel of well-known free software experts is needed to vet new ideas before payment is escrowed for them, and to review programmer work having met the target.

I realize that using financial incentives on open source projects can have some unintended consequences. But a sort of attention and interest aggregation service for existing projects -- one backed by real money, so you know the interested parties are serious -- seems like a worthwhile cause. It might even attract the interest of other programmers if the pool got large enough.

To me, at least, sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project. For example, I've sponsored several bugfixes in a key .NET open source library that we use for Stack Overflow. These are bugfixes they considered low priority, but were serious issues for our site. I was happy to give back to the project, and it was certainly a more realistic option than us carving out a chunk of our own development time to contribute the bugfixes ourselves.

That said, I am concerned that this sort of aggregated sponsorship system hasn't naturally evolved on its own by now. Is it not sustainible, or incompatible with the kind of intrinsic motivations that drive most open source development?

I didn't fully understand 37 Signals' advice to Have an Enemy until recently.

Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go.

When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different, the anti-Project.

One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.

I've explained Stack Overflow to hundreds of people, and by far the most effective way to explain what we do -- the way that causes people to visibly "get it" almost instantly, with a giant cartoon lightbulb practically appearing over their head -- is this:

We're like experts-exchange, but without all the evil.

I never appreciated how easy Experts-Exchange makes it for us. They are almost universally loathed. We don't just have a rival, we have a larger than life moustache-twirling, cape-wearing villain to contrast ourselves with.

No matter how much we may suck (and we try very, very hard not to suck), we can simply point to the experts-exchange website and we instantly become the hero. The good guy. The underdog.

I have absolutely nothing against Experts-Exchange. Realize that I've been a fan of the smackdown learning model for a long time; it's like kayfabe in professional wrestling. There are no hard feelings; this "rivalry" is mostly useful as a way to explain what it is we do. This internet is certainly big enough for the both of us -- big enough, in fact, for hundreds of Q&A websites.

That said, if you have an arch-enemy -- the more horrible and evil and larger-than-life the better -- consider yourself lucky. They're doing you a huge favor.

So, who's your arch-enemy?

I have the very great honor of speaking at this year's EclipseCon with one of my heroes, Clay Shirky.

The theme of this year's EclipseCon is collaboration -- so all the talks are presented by two speakers. Our talk, The Social Mind: Designing Like Groups Matter, will alternate between the theory (Clay) and practice (Jeff) of online community. Hopefully in a coherent way.

This is an easy talk for me to deliver, because I quite literally used Clay Shirky's book, Here Comes Everybody: The Power of Organizing Without Organizations, as a blueprint for building Stack Overflow.

I wasn't kidding when I said It's Clay Shirky's Internet, We Just Live In It.

I can't emphasize enough how deeply I respect Clay. I've read everything he's written to a degree that you might even say I studied it. Clay continues to be one of the most perceptive and insightful technical writers in the world on the topic of internet culture and community. His latest missive on the demise of newspapers is not to be missed. It's thrilling to have this opportunity to speak side by side with such a vital, important figure in internet history.

It is also extremely gratifying to me that I am giving this talk to a group of non Windows-centric developers. Despite my personal background, we always intended Stack Overflow to be a tribute to the greater craft of programming, a place where you could rub shoulders with fellow programmers from all sorts of different backgrounds and professional interests -- a bit like the old, classic computer programming magazines like Byte and Dr. Dobb's Journal.

It pains me to see developers who let themselves get locked into some particular toolchain ghetto, without at least peripheral awareness of what else is going on in the programming world around them.

Good programmers are interested in everything -- and that's exactly the kind of talk Clay and I intend to deliver.

Update: I'm not sure the event was recorded, but Alan Zeichick's summary of our talk is outstanding. I also put the slides up on SlideShare for viewing or download, though it's tough without audio.

I've been a longtime fan of Eric Lippert's blog. And one of my favorite (albeit short-lived) post series was his Five Dollar Words for Programmers. Although I've sometimes been accused of being too wordy, I find that learning the right word to describe something you're doing is a small step on the road towards understanding and eventual mastery.

Why are these words worth five dollars? They're uncommon words that have a unique and specialized meaning in software development. They are a bit off the beaten path. Words you don't hear often, but also words that provide the thrill of discovery, that "aha" moment as you realize a certain programming concept you knew only through experimentation and intuition has a name.

Eric provides examples of a few great five dollar programming words on his blog.

1. Idempotent

There are two closely related definitions for idempotent. A value is "idempotent under function foo" if the result of doing foo to the value results in the value right back again.

A function is "idempotent" if the result of doing it twice (feeding the output of the first call into the second call) is exactly the same as the result of doing it once. (Or, in other words, every output of the function is idempotent under it.)

This isn't just academic. Eric notes that idempotence is used all the time in caching functions that create the object being requested. Calling the function two or a thousand times returns the same result as calling it once.

2. Orthogonality

Imagine for instance that you were trying to describe how to get from one point in an empty room to another. A perfectly valid way to do so would be to say how many steps to go north or south, and then how many steps to go northeast or southwest. This hockey-stick navigation system is totally workable, but it feels weird because north and northeast are not orthogonal -- you can't change your position by moving northeast without also at the same time changing how far north you are. With an orthogonal system -- say, the traditional north-south/east-west system -- you can specify how far north to go without worrying about taking the east-west movement into account at all.

Nonorthogonal systems are hard to manipulate because it's hard to tweak isolated parts. Consider my fish tank for example. The pH, hardness, oxidation potential, dissolved oxygen content, salinity and conductivity of the water are very nonorthogonal; changing one tends to have an effect on the others, making it sometimes tricky to get the right balance. Even things like changing the light levels can change the bacteria and algae growth cycles causing chemical changes in the water.

Orthogonality is a powerful concept that applies at every level of coding, from the architecture astronaut to the lowest level code monkey. If modifying item #1 results in unexpected behavior in item #2, you have a major problem -- that's a form of unwanted coupling. Dave Thomas illustrates with a clever helicopter analogy:

It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you're constantly dancing on all the controls to keep the helicopter stable.

That's kind of similar to code. We've all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back -- like that Whack-a-Mole game -- and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you'll always get that kind of distributed bug fixing.

3. Immutability

Immutability is a bit more broad, but the commonly accepted definition is based on the fact that String objects in Java, C#, and Python are immutable.

There's nothing you can do to the number one that changes it. You cannot paint it purple, make it even or get it angry. It's the number one, it is eternal, implacable and unchanging. Attempting to do something to it -- say, adding three to it -- doesn't change the number one at all. Rather, it produces an entirely different and also immutable number. If you cast it to a double, you don't change the integer one; rather, you get a brand new double.

Strings, numbers and the null value are all truly immutable.

Try to imagine your strings painstakingly carved out of enormous blocks of granite. Because they are -- they're immutable! It may seem illogical that every time you modify a string, the original is kept as-is and an entirely new string is created. But this is done for two very good technical reasons. Understanding immutability is essential to grok string performance in those languages.

I don't pretend that these three words are particularly unique or new, just a tiny bit off the beaten path. They were, however, new to me at one time, and discovering them marked a small milestone in my own evolution as a programmer.

What's your favorite five dollar programming word? And how did it help you reach that particular "aha" moment in your code? (Links to references / definitions greatly appreciated in comments -- perhaps we can all discover at least one new five dollar programming word today. Remember, learn four and you'll earn a cool twenty bucks worth of knowledge!)