“Listen, and understand. That terminator is out there, it can’t be bargained with, it can’t be reasoned with, it doesn’t feel pity or remorse or fear, and it absolutely will not stop…EVER, until you are dead!”
— Kyle Reese, The Terminator

In this day and age, especially in medium-to-large sized, established companies, it’s common for software developers to spend most of their time in meetings. It’s sad but true: There are even developers who brag about how loaded their meeting calendars are.

The worst kind of all meetings is the dreaded regular status meeting where many valuable person-hours go down the drain every week. Tom DeMarco and Timothy Lister really nailed it in their bestselling book Peopleware: “Though the goal may seem to be status reporting, the real intent is status confirmation. And it’s not the status of the work, it’s the status of the boss.”

But while the rest of the team is worshiping the project leader and discussing what could/should/might be done next or at some point in the future, one is already busy implementing and creating facts: the Codenator.

The Codenator is an extremely prolific individual who just can’t sit on his hands. Whereas the Terminator’s mission is to kill, the Codenator’s mission is to code. To him, the keyboard is a weapon of mass construction; he hammers away at it in an endless battle against impossible deadlines, missing specs, and buggy compilers.

APPEARANCE

Just because he’s such a badass, no-nonsense coding machine, don’t get fooled into assuming that the Codenator comes with a strong physique and a loud voice—not at all: the majority of Codenators appear to be timid or nerdy, at least at first sight. The Codenator doesn’t put much emphasis on clothing, either. All he’s interested in is generating as much software as possible.

PERSONALITY TRAITS

One might think that the Codenator holds strong opinions and loves to fight for them. While the former is certainly true, the latter often is not. Being an omega male much more than an alpha male, he avoids direct confrontations and prefers to wage war behind the scenes. If in a design meeting he’s convinced that his approach or idea is superior (and he always is), he agrees with his opponents or at least gives in—just to end the discussion. Then, later, he goes on to implement it his way, anyway.

If he’s not contented with the code of his peers, he doesn’t waste time giving constructive criticism, either; he patiently waits till they are on holiday and then performs a massive overhaul of their components. I’m not exaggerating: I witnessed this happening many years ago when—during the absence of a coworker—a Codenator rewrote a 20 KLOC device driver in two weeks. Needless to say, the Codenator’s design was clearly better plus it fixed all the issues we previously had with the driver. But can you imagine the traumatizing impact this assault had on the component owner, whom it took months to write the original code?

Probably suffering from Asperger’s syndrome, the Codenator is a maverick, hates teamwork, discussions, and compromises. Yet, he’s smart and productive. It’s just his utter lack of people skills in general and empathy in particular, which make him a difficult, if not impossible, team member. You shouldn’t be surprised to hear that he’s unable to take criticism. To him, it’s either his way or the highway.

TOOLING

Remember the scene from Terminator 2 where the Terminator discovers the minigun at the arsenal? Likewise, tools are important to the Codenator as they help him complete his missions. He shows a great level of mastery of the tools he uses daily. Nevertheless, he’s conservative, quite the opposite of an early adopter, and therefore hesitant towards employing new tools. A Codenator is unlikely to try out new programming languages either and will do most of his coding in matured, proven versions of C, C++, and Java. Why? Because the Codenator’s credo is that no new tool or programming language can ever solve the fundamental problem of software development: that people talk instead of code.

RATING

According to the Q²S² framework, a Codenator’s rating is 5/3/1/1.

POLAR OPPOSITE

The Non-Painting Painter/Non-Painter

CONCLUSION

If Sarah Connor were a programmer, she’d probably put it this way: “In a world full of code fear, a Codenator might be the sanest choice.” If he just wasn’t such a heartless robot! But don’t attempt to socialize a Codenator. Even if he honestly tried to change, he would soon relapse. And if you push him too hard, it’s very likely that he’ll just pack his bags and leave. Another big mistake would be to put a Codenator in an environment with strict rules, like a scrum team, for instance. Scrum is a very systematic approach to software development and requires lots of coordination through various forms of planning and meetings. That wouldn’t work for him. He’s a Codenator, mind you, not a coordinator.

Instead, assign him to tasks where his harsh personality can be put to good use. Have him work on prototypes, code ports, and performance optimizations, for instance. Especially when requirements are foggy or non-existent, he will close the gaps, come up with pragmatic solutions that help him carry on doing what he loves most: constantly write code. While some highbrow developers might complain that a Codenator’s code is far from aesthetically pleasing, his code is solid and—more importantly—works. A Codenator is the incarnation of the “finished is better than perfect” adage.

To sum it up, despite his weaknesses with people, he’s a must-keep because he’s never afraid to start. Even better, he’s a finisher. A Codenator doesn’t stop when he’s tired—he stops when he’s done.