Considered harmful: rockstar developers

Ten years ago when I told people that I worked with computers I would often get the response "you don't look like a geek". These days no one seems to think it strange. I currently work in an office in which some of the developers talk about football and have meaningful social relationships. Being a software engineer has become somewhat cooler; as part of that "coolification" process, certain things have changed and other things, which always existed, have been named and magnified. Rockstar developers have always been a thing, but now they have a name and are often seen as desirable. Before I start to explain why I think rockstar developers are harmful, lets define one and the circumstances in which they are harmful.

Characteristics

• Above average understanding of their language.
• Love of esoteric knowledge.
• Egotistical style of programming.

The first two items on the list aren't in any way negative, however, they can lead to problems if not applied responsibly with reference to the environment they are used in. It's the third characteristic that I believe leads to harmful behaviour, because the "me, me, me" can overrule common sense when it comes to the application of logic in a given environment. So there is a tendency to create overly complex solutions to simple problems as small monuments to personal vanity.

Habitat

If you are a rockstar developer as described above, working on a solo project, then go ahead, knock yourself out. It's like being a singles tennis player, there's no need to alter your style for the benefit of others. Have fun, it's your code.

If you are working in a commercial environment, being paid to do a job, then it's not your code. If you are working with a small team of like-minded rockstars, then I hope it's the nirvana it should be and once again, have fun! Unfortunately, the likelihood is that you are working as part of a team of individuals of mixed ability. This, to me, is where rockstars become harmful. It's almost always a problem related to the egotistical programming style creating problems for others. If you are part of a team, then you need to act like it and put the needs of others above your own need to show off.

Obfustication

Yea, sure, bitwise operators are interesting and using them can be a shining badge of your elite status, I mean, how else will people know you can use them unless you do? In a large team, with high code churn, it's pretty likely that someone else will have to read / understand and then modify your code. If you have code reviews, then it's a certainty. Here's an illustration with some reasons why obfustication is awesome and my rebuttals. It's not a real conversation as I wouldn't change someone's code without talking to them first.

"Hey broheim, I was checking the logs and saw you changed my code dude, what's up with that man? It's like, you took my gnarly code, babyfied it. You know your code doesn't do the same thing right?"

"Yup, it's more readable now and therefore maintainable by all members of the team, so I figured it was worth changing. I understand that your code is checking purely for -1, but that's a different discussion."

• Original code: if (!~index) index = 0
• New Code: index = index < 0 ? 0 : index;
• The new code is a conditional ternary operator which is used quite widely in the codebase, if it wasn't, I'd have written:
  

  if (index < 0){
      index = 0;
  }

Here are the most common reasons I've heard as to why something like the original code is better. In my rebuttals my arguments are designed to be for the general case of unnecessarily complex code while still referring to the specific example.

It's not my fault everyone else is an idiot.

Although I've put this point in it's harshest possible form, this is the point I feel has the most value. Finding code you don't understand and looking it up is a very valuable way of learning. In this case though, I'd argue that it's not the right code in the right place, it's just a block of vanity code. Even though you understand that the ~ operator switches the 0's and 1's around in the binary representation of the operand, it still isn't immediately obvious that the code is checking for the case where index is equal to -1. There are enough complex things which require complex solutions, lets leave simple things as simple. It's also hopelessly naive to assume that people will understand unnecessary complexity just because they should. It's like leaving your wallet in your unlocked car because no-one should steal it.

Optimisation dude!

Ok, this is a blog post all on it's own, so we'll gloss a little here. Lets just say that there are two forms of optimisation that are important in a commercial environment.

Code Optimisation

Most important point: optimise where it hurts. Looking at the performance difference in time between our different approaches is all well and good, but we need to take into account the environment in which we are working. At the end of this code, we then append the result to the DOM. Optimising a conditional in this environment is like optimising your drive from Glasgow to London by running to the car (perf. test).

Maintenance optimisation

In general it is much easier to show the cost to a company in lost man hours caused by hard to maintain code than it is to show the boost in profits caused by pre-optimised code (I'm referring here to code optimised by a developer prior to any requirement from the customer). So it's usually preferable to write maintainable code first and then optimise where it's hurting.

Complexity is better

I know this may sound strange, but I have first hand experience of a culture in which a complex solution to a problem was considered better by virtue of it being more complex. After a long discussion of the differences between two possible solutions, it was finally agreed that both solutions achieved the same goal. One group insisted that the more complex solution was better "if you are a developer", yet were unable to define a single benefit of the complex solution over the simpler one. I have also been told, as a put down, "yes, I understand your proposal, it's so simple even my grandmother could understand it". Despite how crazy this sounds, it's actually an easy trap to fall into. If something has been hard to work through, it can be difficult to accept that there is an easy solution, you want it to be difficult and require a complex solution to justify the time it took you. Again, beware of your ego.

Conclusion

Coding is interesting and those of us who do it for a living are lucky, we get paid to do fun stuff. Being good at coding is something you want to show off, but like many things it's not the flashy stuff that shows your mastery. A complex piece of work, that is simple to read and understand is the sign of great coder. The good thing about this attitude is that it scales. What you think is easy to read depends on your level of competence, to someone less experienced there may be logical tricks you've used that they have trouble following. This is where they will learn from reading your code, but without the unnecessary obfustication we've been discussing.