My friend Doc posted this on Twitter, and it really grated on me, so much so that I’m compelled to write.
Meet Bill.
Bill’s a rockstar programmer.
He codes fast.
Bill doesn’t need to refactor.
He codes fast.
Bill’s too valuable to take support calls.
He codes fast.
Bill doesn’t pair; it’s inefficient.
He codes fast.You should hire Bill.
‘Cause we don’t need his kind around here.
In the 15 years I’ve been in the field, I have seen “that person” a few times, and when I do, there usually has to be an intervention or a call to reality. Somehow, I’ve become the “go to person” for these tough conversations, bringing people back to earth gracefully. So let me share why these things grate on me.
The Rockstar Programmer
Rockstar, unicorn, ninja… these are all terms I hear when companies are looking for “the ideal candidate”. I groan at every mention of those.
When I hear these terms, I know they are looking for candidates who have ALL THE SKILLS, can be masters of technologies in short periods of time, and sets expectations high. They want bigger, faster, stronger. However, with rockstars come egos, and “the rockstar programmer” is seldomly a team player. They are the lone wolf who insists they can do it on their own.
Does Not Need to Refactor
Wait… does not need to refactor ever?!? Typically, the end product isn’t written right the first time. Missing scope tends to be common. Having peers review code, there are opportunities to learn how to improve code or possibly take other approaches. And if he does not need to refactor but his code happens to suck… yay for technical debt. 🙁
Too Valuable to Take Support Calls
The most productive, most valuable pieces of code I’ve written have been from user feedback. Whether it’s understanding a user’s environment or realizing that a feature we thought was usable was more confusing than usable, there is always room for improvement. Your users are the ones who are your job security – without users, your product has no reason to exist. I have had employers think that I was too valuable to speak with end users, but in the end, I opted for opportunities where I could talk with the users and show the employers just why support calls are important. Maybe it’s because I have done some time in support (and even managed a technical support team) – but I don’t think any developer is too valuable to take support calls and learn about the pain points in their products or services.
Doesn’t Pair as It’s Inefficient
I have had inefficient pairing sessions, so I can understand where people may think it’s inefficient all along. Like any methodology or practice, I see pairing as a tool that can be useful when understood. I love considering pairing as a tool for on-boarding new folks – knowledge transfer and having those on the team already gauge where the new person may need more guidance and support. I also appreciate seeing some teams pair a QA person with a developer to have the QA person help the developer understand thinking like their users and for the developer to help the QA person automate tests. Is pairing inefficient? It can be with the wrong pair of people or under the wrong circumstances. But… it can also be useful.
Bill Codes Fast
<sarcasm>Ready… set… type! Code as fast as you can. Make as many bugs as you go. Forget about readability – it’s all about speed. Forget about maintainability – again, it’s all about speed.</sarcasm>
Just because someone can code fast doesn’t necessarily mean that it’s working code or the right feature or… hopefully, you get the picture. Coding fast doesn’t necessarily mean it’s a good thing.
Hire Him… We Don’t Need His Kind Around Here
At what point do we decide that we don’t need his kind around here and have the hard talk that he has career-limiting behavior? If we have that talk with him and if he’s willing to try to change, would you give him the opportunity to change?