There's a repeated joke in the Rockford Files that everyone in or that has been in jail was innocent; just ask them. (Of course, we're supposed to assume Jim really is innocent, but I've leave the meta alone for now.)

Ever heard something similar with programmers? Have you ever met a programmer who won't tell you they're a superstar? Coders' self-proclaimed brilliance is like ex-cons' proclamations of innocence. Seriously, who doesn't think they're above average? The sea of programmers thinks itself an extended version of Lake Wobegon.

A more interesting discussion would be to ask yourself why every coder thinks that and who is encouraging it, but I'm leaving that alone for now too. ;^)

Labels: coder, coding

"Don't be too clever," is one of my mantras. pic.twitter.com/y7NQuwVHOb

— Nicholas C. Zakas (@slicknet) March 24, 2016

So that's a clever saying, I guess, but I really think the take-home lesson is that creating code is at least three different, clearly differentiated skills:

1. The ability to write code from scratch that works reasonably well.
2. The ability to constantly refactor that code into something that's increasingly maintainable.
3. The ability to reverse engineer code that you're coming to cold.

In one, you have the ability to write something that works reasonably well the first time. That's an important skill, but a pretty straightforward and, relatively speaking, common one.

The second skillset, creating (and editing) maintainable code, is actually covered by two different abilities almost entirely that are too often conflated. One is the ability to write maintainable code. That's perhaps the toughest skill to find, and it's not one that's easy to find out in a quick interview session, if you're the type of company that likes to give programming questions. Because you can write maintainable code a few ways, but the best way is when you get to refactor what you've got. Write code that works, and get the time to make it code that is maintainable.

There are certainly ways to minimize the refactoring by using best practices the first time, and those are habits and skills that you can find in an interview pair programming session. But it's a lot better to find someone who naturally refactors into every more maintainable code than to find someone whose first cut is pretty good.

The second half of the second skill [sic] is the coder who can reverse engineer anything. Can you get into the mindset of the person who wrote this code? How long does it take to rethread your head and work with the code in front of you?

This reverse engineer is also insanely rare and important, because they're the folks who can inevitably pull your rear out of the fire when you've got code written by that first type of coder, the ones who can write code that works reasonably well the first time, but who might not be the type that writes maintainable code. If that coder is still on your team -- especially if they are good refactorers, in which case you should put them on the task as soon as is efficient most of the time -- great, but seemingly more often, that original coder is gone, and it's the reverse engineer that proves the most clever of all.

(In case the image didn't come out because you've got Twitter JavaScript turned off...

)

Labels: coder, style