Now for sale: my book for programmers entering industry, the New Programmer’s Survival Manual, is available in ebook and paper form. I expect readers of this book to fall into a couple categories: College students taking Computer Science classes and wondering, “is this what programming is like in the real world?” (Short answer: no.) College grads already in industry, who have noticed first-hand that the answer to the first question is “no,” trying to get their heads around the disparity.

This article is written with considerable snark--put on your flameproof suit if needed. I'm not actually a jerk when interviewing people, but I do get frustrated when candidates fail to do basic preparation. If you're unsure about how to prepare for a programming interview, read on...

I know this might come as a shock to you, but most programming job applicants suck. I’ve interviewed my fair share this month, and it’ll be a lot easier for all of us if I tell you upfront what I’m looking for.

As a hiring manager, my job is to make sure you can do the job you’re applying for. For programming that means you need to be able to program. So when I whip out a laptop in our round-one interview and ask you to write some code, try to hide your terrified expression.

Here are slides from my presentation at the Boulder/Denver Ruby Group on “Simple MapReduce with Ruby and Rinda.” This is much of the same material as my article on the topic, but it focuses on the high points and perhaps better illustrates what’s going on. If you were at the meeting and have comments on the presentation, or have time to play with MapReduce, shoot me an email and let me know!

Here’s a simple version of the MapReduce framework presented in the now-famous Google paper by Dean and Ghemawat. My version of MapReduce is not intended as a usable high-performance framework, but rather as a learning tool. My goal is twofold: first, to learn to write algorithms in distributed/parallel MapReduce style. Second, to see how simply these concepts can be expressed in Ruby.

I use the Rinda framework to distribute tasks to remote workers. This simplifies a great deal of the MapReduce grunt work. The map and reduce code, along with data, is marshaled and sent over the network transparently. Creating a MapReduce job is as easy as creating an object, assigning lambdas for map and reduce, assigning data, then telling it to run.

Here are slides from my presentation at the Boulder/Denver Ruby Group last night. It’s Ruby-focused “Lessons Learned” based on the project I’ve been leading this year, the software for Spectra Logic’s new disk arrays. Topics covered include embedded vs. Internet web servers, interfacing with hardware and 3rd party tools, text processing, and a lot of Ruby on Windows stuff.

I have over a decade of professional C++ experience, but I don’t call myself a “C++ Programmer.” Am I competent with programming in C++? Yes, very much so. But I refuse to let my skills be pigeon-holed by the language I’ve historically used. Nor should you.

Use the right tool for the job, the saying goes, and software development is no exception. Programming languages, frameworks, and other tools are the subject of religious-caliber debate but they are just means to a greater end. This article is a call to both programmers and their managers: a good programmer cannot be summed up by the list of tools they use.

Last night I attended the inaugural meeting of the Boulder-Denver Ruby User’s Group. “Meeting” was a term used in the loose sense–it was more a gaggle of Ruby enthusiasts sitting around tables with beer, chatting about Ruby and other geek stuff. The meeting was held at a brewery, so it was impossible to hear people more than a couple feet away, but as the group shifted around I probably talked with half a dozen others.