geek2geek

It’s been almost half a year since I set up this blog and a mailing list to discuss geek2geek communications. Geeks communicating with other geeks and also mere humans. The subject got a lot of attention at OSCON and BarCampBlock. As these things go, I never got around to writing things up. Well, it’s a new year so let’s get things started.

Of course, where to start. I’ve been having trouble with that, everything’s so interconnected. So I’ll begin at the beginning, where the idea came from.

For the non-programmers out there, I promise it’s not going to be all about programming but you might have to indulge me my coding metaphors while I get to the point.

This all started when I was preparing for my big OSCON tutorial last year, the ambiguously titled “Simple Ways To Be A Better Programmer” aka “What Works in Software Development” aka (my favorite) “How To Be Lazy Without Really Trying”. This is a tutorial I’ve given many times before for many years. It’s my opportunity to have 200 programmers captive while I brainwash them for 3 hours. The title is clever and vague so they don’t know what they’re getting into. Usually I teach whatever it is I think programmers are struggling with that year. Particularly things they don’t teach you in college. Not that I’d know, I failed out.

Usually it focuses on things like version control, documentation, names, testing, refactoring and so forth. Mostly coding issues. This year I proposed the same basic thing as always but it didn’t get me terribly excited. Then right after it was accepted I got a much better idea. Typical. As with all good things, the idea came from my kitchen.

Alton Brown’s show Good Eats could be instead titled Analytical Cooking. (If you hate cooking shows, watch this one.) He breaks down cooking into methodologies and techniques, rather than a series of recipes you’re supposed to follow by rote and guesswork. The cookbook associated with the show, really more of a cooking textbook then a traditional list of recipes, is I’m Just Here For The Food. Emblazoned on the cover is a simple equation that sums his grand philosophy:

food + heat = cooking

He breaks down cooking not by dish but by heating method and focuses his efforts on teaching them.

It’s simple and poignant. Where do I get one of those?

Nominally I’m teaching basic software engineering yet I’m always at a loss to explain just what software engineering is. That’s bad. Well, what does a programmer DO? Breaking it down there’s the part with the algorithms and the compilers and loops and conditionals… all the computery stuff. The part that’s all about telling the computer what to do. The stuff they teach you in college and programming books. Generalizing, it’s the stuff they call computer science.

Computer science is definitive. It’s provable. It’s deterministic. It’s controllable. It has definite boundaries. It’s repeatable. It’s objective. If you have a computer science question you can get the one right answer, because in the end it’s math. It’s a concrete subject and concrete, analytical thinkers (read: programmers, geeks) can deal with it very well.

OK, that’s one half. What about the other half? What is it I’m teaching? What is it that programmers have a hard time with? Refactoring. Coding style. Documentation. Interfaces. Names. For each of these things people are involved. And as every scientist knows, people are not deterministic. They’re not controllable. They’re not bounded. A solution that worked with one person might not work with the next. The answers are subjective and often start with “it depends”. These are messy, “soft” subjects and they all involve people.

So I have my equation.

computer science + people = software development

Probably not strictly correct, but it is poignant.

What’s this got to do with geek2geek communications, you ask? It shows that there’s two kinds of conversations going on while programming. There’s the programmer talking with the computer, translating concepts from the analog world into the workings of an alien universe built not on physics but discrete ones and zeros. And then there’s the programmer talking with other people. Be it with other programmers, through their function names and choice of code layout, or more directly on IM and mailing lists. Or directly with mere humans trying to explain that no, they can’t do the project in just two weeks. Programmers do most of their programming not with the computer in mind but people.

Programmers, already predisposed to being analytical, are further trained to think like and talk with computers. Programmers aren’t trained to deal with people because everyone knows how to deal with other people, right? (Yeah, right.) And a programmer’s job is to work with computers, right? As the equation shows: wrong. The end result of this focused training is programmers are really good at the computer stuff, and really bad at the people stuff. The result is a lot of really crappy, hard to use software. And the flame wars, oh god the endless burning.

With this blog I hope to analyze some of that people stuff as it effects programmers and other naturally analytical types: geeks. I’d like to share my observations and foster discussion on what we get wrong, why we get it wrong, and how we can make it right (because I’m an engineer at heart and like to fix things).

So let’s all stare at our screens, together, and think about the people on the other side.