Rock Star Programmers
There's been a lot of talk about the Rock Star programmer on the web these days. Several very interesting articles about it. Today I had a run-in with a new guy at work, and I have to say, while not a Rock Star, he's certainly got several of the worst qualities of a Rock Star, and I'm trying very nicely to point out to him that they really aren't very useful here.
I try to ask people in interviews what they think their most important job is when first coming to a new place. There are a lot of different answers, most of them very political or very technical, but every so often I find someone who understands what it means to be a good developer, and they give me the answer: learn.
That's when I know I have a 'keeper'.
If the smartest person in the industry came into a shop and started changing things, or building things, it would only be by the greatest feat of luck that it actually worked and worked well - with the existing systems. Anyone can build an app. OK, almost anyone. It takes a skilled developer to see the right way to buld the app so that it fits in nicely with the existing apps and services in the organization.
For instance, if a new app is built that needs to make a copy of the accounting data in order to function as built, then it's bound to fail. Or worse, cost excessive manpower to make sure that it's always kept in sync with the real repository of the accounting data. Making copies of critical data is almost always a mistake. But if you don't know how it's stored (because you're new and don't take the time to learn) then you'll build something that has to have lots of scripts for copying, checking, back-filling, etc. all because you didn't learn before you built.
So today I had a visit from a new developer - been here a few weeks. We'll call him Skippy. Skippy wanted to have a new method put on a Java table object that is widely used in the organization: renameColumn(String, String). I pointed out that there already exists the method setColumnHeaders(int, String) that can rename the column header, but he pointed out that if he didn't know the column number, the setter wouldn't really help. Agreed, then use the method getColumnForHeader(String) to get the numerical column and then use that in the setter. Still no good, says Skippy. It's too long.
Too long? I pointed out that it was one line:
setColumnHeaders(getColumnForHeader("old"), "new");
and he said that even that was not as clear and concise as the rename method he proposed. I agreed that the 20 (or so) extra characters make the existing method invocation technically longer than the other, the point was really is this the best thing to be spending time on right now?
We are, after all, understaffed for the workload, which means that things are always getting rearranged on the priority list, and many are just not getting done. This means that we need to be very efficient with our time. While I don't disagree that adding convenience methods to classes makes them easier to use, my question is does this addition benefit the users in a material way? And to that question, I am fairly confident, the answer is 'No'.
Now I'm trying to put this in as non-confrontational a manner as possible, but Skippy is still being quite insistent that this change is significant and warranted. I'm trying to tell him that it's not an issue of the individual change, it's about a balance of the workload and the cost/benefits of each thing that we do. I can see his eyes glaze over... his head turns away... and I know I've lost him. I say as much and we're done.
Later, as I try to use an example of something I had done for him the day before to show him that I'm not against his ideas just because they aren't mine, he told me that he was adding the method in his project. As further evidence of his thoroughness, the feature I added for him wasn't going to be used because he hadn't checked with the Team Lead beforehand, and when he told the Team Lead about it, he directed him to do it another way entirely. Effectively wasting my time the day before because he hadn't learned what was needed. He acted on what he thought was needed.
Rock Stars - more hassle than they are ever worth.