SMART goals and Petered principles

List three to five goals for the next year. These goals must be SMART (Specific, Measurable, Attainable, Relevant, Time-Oriented). Include both those goals that would help you in your current role as well as those that prepare you for future roles in the organization.

Few work-related things fill me with greater dread than this annual question. And I’ve gotten it at every job I’ve ever worked at where there were more than a hundred people.

I’m a programmer. In every position I’ve ever worked, I was hired on the basis of a skillset I had at the time. Spry hired me because I knew Perl when Perl was barely a year old; F5 because I knew Perl and Curses; Isilon because I knew both kernel development and web application development at a time when both were truly esoteric; Canvas because I knew both Django and assembly language; IndieFlix because I knew Django; Spiral because I knew Single Page Development when that was brand new; CK12 because I knew web development and the EPUB 2.0 standard.

While I was there, other problems became apparent to me: Spry needed me to learn both C++ and Python; F5 needed me to learn Lex & Yacc; Isilon needed me to learn server development; IndieFlix needed me to take my hobbyist-level transcoding skills and go professional; CK12 needed me to learn WebGL. None of those needs were apparent until they were immanent. It’s not as if I could scan the horizon of issues and see, “Months from now we’re going to discover that this rendering technique won’t work on an iPad without WebGL” or “Months from now, we will discover that the application server needs an ‘always on’ userspace component for consistent kernel communication; I’m going to need to know how to write one of those.”

Questions like the one above imply a kind of restlessness that can only be cured one way: with money. The idea is not that you want to be great at your job; the idea is that you want to be great at the job that leads toward ascension, and in most corporations the only ladders available lead away from a lifetime of training and experience toward “leadership.” I have deep respect for good leadership, and I hear the siren song that says, “You have all these skills; your duty is to help others achieve the skill level you have.”

Given the level of interpersonal skills I have, I ultimately end up wondering: “If they achieve the same skill level I have, does that mean you’ll Peter them too?”

As a software developer, I love learning new things. I’ve been studying a couple of things at random: Category theory, type systems, interpreter cores; basically, a lot of meta around the lambda calculus. Along the way I learned a little Haskell, and learning even a little Haskell made me a much better programmer. The odd thing is that few of those interests map to those of my employer; usually, they don’t want esoterica, they want better in the realm in which they work. It has been my fortune to have “significant advanced skills” in customer-facing engineering; it’s my misfortune to realize that I’ll be working in the same four damn languages for the rest of my life if I want to keep making the same salary.

I have only one goal: Get better at what I do. Everything else is commentary.

Software development needs copy editors

Magazine, newspaper, and book publishing, in both fiction and non-fiction, all have two specialized roles that the work goes through before it reaches it’s final form:

The Project Editor and the Copy Editor.

Software teams have a project editor, although usually he’s called the project manager. In literature, the project editor doesn’t usually edit; his responsibility, like that of the project manager, is to see the work go from manuscript to bound volume, and is responsible for schedule, budget and the interaction of other departments such sales and marketing, in order to assure the success of the work.

There is no job in software anything like the copy editor. And that’s a problem.

Linters and style checkers can make sure that you have the right number of indentations, ensure that your line length fits into the house editor, check you have comments where comments are required. What they can’t do is ensure that your variable names have meaning, that your classes are SOLID, that each function does one thing and does it well, and that a future maintainer can look at any given piece of code and not say “WTF?”

Every creative profession that works on a commercial production line, that is treated as a craft, has an editorial pass. If you’ve ever worked in advertising, there’s one guy whose job is to make sure the studio musician is creating background music that matches the taste of the ad; there’s also someone who makes sure that every background image in an animation matches the overall feel of the production. These aren’t “I know it when I see it” jobs, either; these are people who are expert studio musicians and illustrators who have earned the trust of their peers and graduated to the role of guiding others to excellence.

Every creative profession except software. Software developers are a weird bunch: the good ones are absolutely ready to take criticism from their peers, as they want to get better. The bad ones believe that “it passes all the tests, so you shouldn’t care about its style” and you can’t tell them anything at all. Given just how much money is sloshing around this industry, any change to impose more discipline is opposed with ferocity. We all have someplace else to go.

Software copy editing would be a line job; it wouldn’t be management, and yet it would have the final, human-eye check on whether or not something goes into the repository. It wouldn’t be about if the code is testable; it would be about if the code is maintainable. Can a future code monkey at a glance see what you meant and how you acheived it? As a line job, it would be dependent upon the productivity of others to succeed, yet in agile the editor would have no velocity himself.

There are tons of anti-patterns that are opposed to this idea:

• “I don’t want to pay some guy just to sit around and read code.”


• “Testing will find all the bugs.”


• “The next revision will be a complete re-write, so code readability isn’t an issue.”

I’m sure you could name more.

But if you really give a damn about code quality, and your company has more than twenty developers, consider hiring a software copy editor, a hands-on, polyglot programmer with an opinion about how software should be written.<