“Rockstar Developers” are a dangerous myth

Recently I’ve run across several uses of the phrase “rockstar developer” or “rockstar programmer” (“code ninja” is another hip variant). The term shows up on slashdot, for example. I’ve also seen it in job postings and in blogs.[1],[2],[3] A rockstar hacker archetype is standard fare in TV shows, where his or her computing feats are practically a superpower (Agents of Shield, Person of Interest, Leverage, Scorpion, …) Of course Hollywood loves the notion, too; I thought The Imitation Game was fascinating, but besides taking liberties with history, it portrays Alan Turing in a distorted way that feeds such mystique. (Turing was absolutely brilliant, and certainly one of the most important pioneers in computing. But he didn’t invent his codebreaking machine alone.)

Alan Turing and team members at Bletchley Park, with a forerunner of the modern computer-- technology invented by brilliant people to break the Nazi Enigma encryption. Screenshot from official trailer, under fair use.

from The Imitation Game: Alan Turing and team members at Bletchley Park, with a forerunner of the modern computer — technology invented by brilliant people to break the Nazi Enigma encryption. Screenshot from official trailer, under fair use.

It’s even in my inbox. After I began writing this post, I got an email from a recruiter on LinkedIn, looking for “superstars”:

superstar

The buzz about these mythical supercoders has begun to raise my hackles.

Continue reading →

Know Your Limits

I just finished the nastiest debugging experience of my career–nearly 3 weeks on a single bug. After days and days of staring at code, swearing at core dumps, tailing logs, connecting to gdbserver via a multi-hop ssh tunnel from inside a secure environment, and general programmer misery, I felt like doing cartwheels when I finally figured it out, tweaked a few lines of code, and observed stability again.

Hindsight teaches me this lesson: undocumented, unhandled constraints waste enormous amounts of time and energy. If you’re interested in writing good code, you must know your limits, and you must communicate them. This especially matters when the constraints are obscure or surprising.

image credit: ericdege (Flickr)

Naive optimism

My bug seemed simple enough at first blush: Continue reading →

A More Important Manifesto

A couple years ago, I wrote about signing the Agile Manifesto and the Manifesto for Software Craftsmanship.

Today I want to write about something a lot more important.

Let me use résumés to provide some context.

I used to think that the “Objective” section of a résumé was fluff–a place to dump vague platitudes, maybe. You know the stuff I’m talking about:

Objective: Craft high-quality, enterprise software in an environment where I can make significant contributions to the bottom line of a growing company.

Blah, blah, blah.

Theoretically, this stuff helps you get jobs, but as someone who writes a lot, my drivel-o-meter pegs at such verbiage. Usually, it means about as much as the Business Buzzwords Generator recently posted by the Wall Street Journal.

image credit: David Blackwell (Flickr)

But it doesn’t have to be that way.

Your objectives ought to matter.

Continue reading →

Variadic macros tricks

Have you ever wanted to write a “for each” loop over all the args of a variadic macro? Or have you ever wanted to overload a macro on the number of arguments? (If you’re saying to yourself, “good grief, why?” — I’ll describe a use case at the bottom of this post.)

I learned how to do this today, and I wanted to blog about it to cement the technique in my own mind. (And I hereby put all the code I show here into the public domain.)

What happened when I decided to learn this technique. I’m trying to spare you… :-) Image credit: xkcd.com

Simple variadic macros

The first piece of magic you need to do something like this is __VA_ARGS__. This allows you to write macros that take an arbitrary number of arguments, using ... to represent the macro’s parameters:


#define eprintf(fmt, …) \
fprintf(stderr, fmt, __VA_ARGS__)

view raw

variadic_macro_1

hosted with ❤ by GitHub

Nice. __VA_ARGS__ is a standard feature of C99, and I’ve known about it for a long time. I’ve also known about GCC (and Clang’s) extension, which attaches special meaning to ##__VA_ARGS__ if it’s preceded by a comma–it removes the comma if ##__VA_ARGS__ expands to nothing. If I change my macro definition to:


#define eprintf(fmt, …) \
fprintf(stderr, fmt, ##__VA_ARGS__)

view raw

fancier-eprintf

hosted with ❤ by GitHub

…I can now call eprintf("hello, world"); without a complaint from the compiler.

But it’s not enough

That doesn’t let me do a “for each” loop, though. All the args that I pass are expanded, but I can’t do anything with them, individually. I have no names for my macro’s parameters–just the anonymous ….

I went poking around, not expecting to find a solution, but I was pleasantly surprised.

Continue reading →

Taming Side Agreements

When I was a technical director at Symantec, I had to formally certify at the end of each quarter that I had not entered into any “side agreements” with customers.

A side agreement is any arrangement that takes place out-of-band, off-the-books, or using private channels not normally examined by accountants. In business, they are usually a bad thing; they can be used to build Enron- or Madoff-style house-of-cards revenue pipelines that are gleaming and glittery at first glance, but that are ripe for collapse because they’re full of hidden caveats and preconditions.

The former Enron towner, now owned by Chevron. Image credit: DaveWilsonPhotography (Flickr)

The problem of side agreements might not impinge on the consciousness of software engineers much, except when they grumble that sales or execs or product management is “selling the roadmap” instead of shipping features. But would you believe me if I said that engineers perpetrate their own Enron-esque side agreements all the time?

Continue reading →