I’d love to say I know a good programmer when I see him (or her).  That would be a lie.  The difficulty in predicting the performance of programmers lies in the fact that programming, as human endeavors go, well… it’s a bit odd.  We’d like to say (as a group that wants to be taken seriously) that “programming is engineering.”  Well, in 2009, even our own beloved luminary Tom DeMarco admits:

“I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone.” — Tom DeMarco

Phew, I know I’m relieved.  Sure as shit, programming never did seem like engineering to me, the last 20 years I’ve been doing it.  Good thing we don’t have to carry on that charade.

We’re left with one other extreme view, that “programming is art.”  But I don’t think many folks want to see source code hanging in galleries.  Even the pinko commie FSF leader agrees, and he’s right because he’s an Emacs guy:

“I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty.” –Richard Stallman

So, let’s split the difference and neatly pigeon-hole the practice of programming as a “craft”.  Seems fair enough.  Pete McBreen points in this direction in his book Software Craftsmanship.  Knuth was thinking along these lines back in 1974, too.  But using the analogy of “craft” doesn’t go very far to predicting programmer aptitude.  Unlike most other crafts (smithing, knitting, ceramics, architecture, furniture, you name it), programming exists in a realm of nearly pure abstraction, doused liberally with a tonic of interpersonal communication and collaboration.  An odd mix.

So how do you pick out the good geeks in a crowd?  Malcolm Gladwell writes about the difficulties, and I think there are strong parallels between finding good QBs, and finding good programmers.  Until you just try them out, you can’t really know.

Since I’ve long viewed the practice of programming as a craft, I’ve tried to apply the notion of a portfolio, a gimmick I learned from my boss back at AOL.  A good programmer should have a body of work, which can be shown, and in it you will find strong clues as to the type of programmer they are.  So unless I’ve worked with someone before, directly, along with references and resumes, I ask them to provide:

A significant code sample which you feel is representative of your best recent work.

You might be surprised how that surprises folks.  I’m not sure if they think I’m going to poach their code, or rat them out to the employers whom they were working for when they wrote it, or what.  In any case, of those that get over it and send me something, a disheartening number send me what amount to toys – 100 line incomplete snippets of something-or-other.  Or, just as bad, a swath of user interface callback code, or a class definition that’s 90% setters and getters.  Sigh.

Once I’ve settled on the notion that a particular person might be a good hire, I try them out.  That amounts to a six-month “no fault divorce” period, where the candidate is brought on board as a 1099 contractor, but in all other ways as a full fledged member of the team.  Most folks need six months to settle in, get embedded in team dynamics, and learn enough of the problem domain to be useful.  During that time, if anything doesn’t feel right – and I do this purely based on gut instincts – I gently end the relationship.

It doesn’t always work, but it works well enough.  Sometimes it makes me wish that there were true apprenticeships in programming, Programming Guilds whose members (graduates) would come as known quantities, merely through the imprimatur of their Guild Master.  Meantime, we do what we can.

Quick shout-outs for excellent Ruby tools: ImageScience and RubyInline.  We wrestled with RMagic on and off all week and finally punted, moving over to ImageScience with a sigh of relief.  We needed a small enhancement to ImageScience which was easily done using RubyInline.  Voila.  I like it when things are this easy.

Some years ago while studying the occult, I stumbled across Robert Anton Wilson’s Quantum Psychology, which blew my mind all to pieces.  I still pull out my dog-eared copy every year or two to reinforce my mind-blowness, and it never disappoints.  One major benefit I’ve realized from it, while prosaic, may be of some use to you.

Take this simple advice to start writing better:  Stop using the verb ‘to be’.  If you’re like me, it’ll take you awhile to get the hang of it.  Even today I lapse back into using ‘is’ from time to time, but whenever I put myself in the frame of caring about what I write, the practice returns readily enough.  It couldn’t save the novel I wrote from being a “learning experience”, but at least my prose packs a little punch.

Try it.  If it doesn’t blow your mind, at least your sentences will sparkle.

Ok, maybe Bucket List is a bit of a stretch.

But if I had oodles of free time I’d do the following geeky things:

• Lisp.  Really learn it this time.  No.  Really.
• Smalltalk too.
• Build and install an active solar system and a solar hot water heater on my house.
• Do an iPhone app.  Yay, Objective-C!

What’s on your list?

I’m not sure if it’s a fine line or a broad one between programming-in-the-small and programming-in-the-large, but at hotelicopter, we’ve definitely stepped over that line.  Along the way, in a very short amount of time (6 months, give or take), we’ve begun moving to the cloud (aws), adopted distributed source code control (git), automated deployment (capistrano), continuous integration (hudson), unit testing, Ruby on Rails, lost a key developer, and hired a new rockstar.

Just to confuse things, the majority of our site - the importantest parts, anyway – are still written in PHP, on a code base now 2+ years old and about a decade behind the times.  (Can you say “monolithic”?  I knew you could!)

The place we’re aiming for is a highly decoupled (and scalable), cohesive set of services, joined through REST APIs and/or fully reused common business models.  We have multiple “applications” now, all operating on a couple of common databases.  We’ve officially run headlong into one of Ruby on Rails’ deficiencies: programming in the large.  We’re not interested in computer science-y solutions, only pragmatic ones.

I suspect as we muddle along we’ll develop a component-level (service level if you prefer) version of the Law of Demeter, which will drive us to make the right decisions for decoupling.  I’m not too worried about that.  However, we definitely have issues with reuse.  Currently the Ruby on Rails state of the art solution for reuse is the gem.  Which, let’s face it, is a pathetic solution.

We’ve begun rolling what we call our “common” system, composed of a set of models, migrations, configuration artifacts, etc., shared between applications, wedged carefully into the RoR framework, and superglued in.  It supports use standalone, outside of a RoR application environment (though definitely somewhat hobbled in that case), and allows application-specific specialization of common models.

I’m not sure it will be sufficient in the long run, but thus far it is supporting a large degree of reuse between three RoR apps and our PHP site.

I’ve just completed my first custom Myspace page for a consulting client.

Words that come to me are things like shameful, nauseating, broken, hopeless, confused, and ugly.

Myspace, you should be ashamed of yourself. And you deserve every bit of the ass kicking that Facebook sends your way. If your definition of “customizable” is godawful nested CSS “table table table table” nonsense, then… yeesh. I’m speechless.  That’s not a presentation layer.  It’s a pillow held over my face while I sleep.

I really hate to trash local businesses.  Perfect Flavor is my very own local business.  I guess I live in a glass house.  But I can’t help but launch this one out there into the blogosphere:  Don’t hire Plan Electric of Charlottesville.  ‘Nuff said.

Happy accidents? Unforseeable synchronicity that happens from time to time when I try to make art. A confluence of factors – a dash of creativity, a pinch of technique, a spritzing of awareness – come together to create a piece of art that somehow comes together to create a whole that seems to be more than the sum of its parts.

There seems to be a correlation between the rate of happy accidents and the psychic energy I devote to making art.  The more energy, the more happiness.  The relation does not seem to be linear, and it certainly isn’t predictable. (What kind of accidents would they be if I could predict them?) I welcome happy accidents, but they reveal what an abiding gulf there is between my technical prowess – my ability to execute – and my vision.  They even reveal a certain poverty in my vision.  If I can create these images – or simply be in the right posture and attitude to create the opportunity for me to receive them – then the standard to which I currently aspire is too shallow.

Grist on christmas.

Lynsie and I have been practicing our own version of transparency, which includes things like posting our recipes for gourmet ice cream on the company blog.  But this slide (see to the right) is a new ballgame.  People ask us why Perfect Flavor does this, and the answers are pretty straightforward.

First, we want people to know what we put into the ice cream, and into the company itself.  These things are our competitive advantage, and hiding them negates them.  We want people to know that we use only local and organic ingredients.  We want people to know that our ice cream is made by hand, using the same recipes that harken back not just to your grandmother, but to Thomas Jefferson, and beyond.

Our assumption is that our customers are really very smart, well informed, and careful.  They know what they want, and hiding information about how we do business works against us.  Sooner or later, it all comes out, and so why have any secrets at all?

To that end, we’d like to nip the question “Why is this so expensive?” right in the bud.  We’ve gotten it sporadically, mostly from folks who are used to buying a half-gallon of Bryer’s ice cream for a few dollars.  When you compare the cost of Perfect Flavor against that, it’s liable to give you sticker shock.

Are we crazy to disclose the costs of our business so explicitly?  Will it come back to haunt us somehow?