I enjoy reading programming blogs—bitesized chunks of wit and snark, with the occasional war story thrown in. Friendlier than a unix manpage, they are an essential part of the pop culture that surrounds code, creating celebrities, flamewars and fads. Joel on Software is one of the earlier and more successful examples in the genre.

Spolsky’s guerrilla marketing campaign established a template for many of those that followed—tell stories about interesting companies you worked for, talk about why your business practices are effective, all in an authoritative but informal tone. Most importantly, don’t forget to cherry pick from “The Mythical Man Month” and “Peopleware.” They may be notable books, but there is a generation gap — programmers who’ve learned almost exclusively from their browser — so it will always be new to someone.

As Joel on Software became dormant, one of his later rants captured the essence of programming blogs–

This review captures what’s been driving me crazy over the last year… (sic) an unbelievable proliferation of anecdotes disguised as science, self-professed experts writing about things they actually know nothing about, and amusing stories disguised as metaphors for how the world works. […] it all becomes insanely popular simply because the stories are fun and interesting and everybody wants to hear a good story. Spare me.

[…] Now, I am not one to throw stones. Heck, I practically invented the formula of “tell a funny story and then get all serious and show how this is amusing anecdote just goes to show that (one thing|the other) is a universal truth.” And everybody is like, oh yes! how true! and they link to it with approval, and it zooms to the top of Slashdot. And six years later, a new king arises who did not know Joel, and he writes up another amusing anecdote, really, it’s the same anecdote, and he uses it to prove the exact opposite, and everyone is like, oh yes! how true! and it zooms to the top of Reddit (source)

It’s weird to find one of the most damning critics of Joel on Software would be Joel himself. He’s had enough of programming blogs, all like his, while humbly taking credit for the genre. I don’t blame him for the storytelling, as he notes many will come after him, but many other programmers have come before.

In the same way that Joel’s first real job taught him many lessons about programming, Fred Brooks waxed on about shipping a mainframe operating system, and how his experience applied generally. Even Brooks’ latest book opened with a similar complaint to Joel’s, “There are too many Anecdotes in Software Engineering, Let me tell you about how I built a house.”

So much of Joel of Software revolves around anecdotes, it might as well be called “Hackers and Bakers”. Stories begin with a filth encrusted oven, and end with lessons on Project Management, GUI Design and Computer Security. One of his bread making stories stands out as an example of the writing Joel decries, where he makes a case for Hungarian Notation, his snake oil for web security–

Way back in September 1983, I started my first real job, working at Oranim, a big bread factory. […] After two months in the bakery, you learned how to “see” clean.

Code is the same way. (source)

Hungarian Notation, for those yet to appreciate the full horror, is a way of smuggling type information into a programming language. The key idea is to prefix every variable with a type, effectively writing in a programming language where you have to put a cast on every variable, except the compiler doesn’t check this for you.

There are two basic styles Joel outlines—Systems and Application. Systems Hungarian uses the implementation type, meanwhile Application Hungarian chooses to smuggle an abstract type. For me, both litter the code with verbosity—but for Joel, Apps is good and Systems is bad. He claims Apps Hungarian makes “Wrong code look wrong” and prevents cross site scripting attacks–

Making wrong code look wrong is nice, but it’s not necessarily the best possible solution to every security problem. It doesn’t catch every possible bug or mistake, because you might not look at every line of code. […] You instantly gain the incremental benefit that every time a programmer’s eyes pass over a line of code, that particular bug is checked for and prevented.

The foundation of his argument is that a programmer will mentally check a line of code every time they read it and perhaps hopefully they’ll notice the bug if you force them to be verbose enough. The so called security Joel touts is simply security theatre.

Today, cross site scripting attacks can be eliminated by the language runtime, if it is aware of the difference between safe and unsafe strings. Instead of using a naming scheme, use types, and unsafe code results in runtime or compile-time errors. Letting the runtime, instead of the programmer handle security, was quite the missed opportunity for his pet language Wasabi (An in-house coffeescript of vbscript).

Even Joel admits that tools that handle failure are preferable to burdening the programmer–

The way to write really reliable code is to try to use simple tools that take into account typical human frailty, not complex tools with hidden side effects and leaky abstractions that assume an infallible programmer.

Better tools exist now—Facebook’s XHP is a great example of extending a language to handle cross site scripting attacks, and making code simpler to write and maintain. Safety comes from forcing developers to explicitly say when they don’t want string escaping.

Hungarian Notation is a throwback to the past, justified then as a last resort when faced with poor languages and tools. I’m not tired of ancedotes yet, but I’m certainly tired of this one. You cannot secure your code with a naming convention, hungarian or otherwise.