I was cruising the Joel On Software forum recently and came across this post and I felt compelled to blog my thoughts.
I often find it quite perplexing, the term superprogrammer. It seems that people are looking for this one size fits all definition of what is super. This doesn't tie well to the definition of a super hero though which is the metaphor being used. Super heroes are certainly super, but not perfect. Generally a super hero has a few abilities that scale far beyond that of the average person (and oftentimes some weaknesses that scale far beyond as well). My point is that what is super in one organization is not necessarily super in another. Let's look at some cases:
Case 1: Super Speed Man
This programmer is fast, damn fast. They can push working code at astonishing speeds. These people generally have some solid code templates and a great memory for the framework and application so they rarely have to stop and look things up. These are the guys that you assign a 6 week task to when it needs to be done in 3.
The weakness? In most cases super speed man is short on useful documentation. In addition, their code is rarely abstracted out and when requirements change down the road the code changes generally require more work than a better architectured solution would be. Finally, sometimes this hero will forsake coding standards for the sake of speed.
Super Speed Man is most appropriate in consulting shops where the time is money scenario is very critical and the ability to push working code quickly to a customer is paramount. Time to market is definitely a desirable thing, so speed man also excels in start-ups. Speed Man can be frustrated by traditional shops surrounded by a lot of red tape.
Case 2: Mr Architect
Here's a hero that can build a framework that aligns with the needs of today and the perceived needs of tomorrow. They have an innate ability to predict the future and see problems before they show up.
The weakness? This guy is actually the opposite of speed man. He requires a lot of time for information gathering and planning. A shop that can't afford to wait is not a good match for this hero. Also keep in mind that a shop with very loose requirements and specifications will probably frustrate this guy. In addition, he can sometimes clash with Dr Consistency since patterns and framework concepts do change with time and individual growth.
Case 3: The Communicator
This hero has the valued capability of being able to translate "user speak" to "tech speak" and back. This is your liaison to the other pieces of your organization and customers. The communicator has the ability not only to make the end users comfortable that their message is getting across, but also can educate them in some of the inner mysterious of development. This hero is your team's champion to the outside world.
The communicator is damn near useless in an internal shop with highly technical users. Like Aquaman without a dolphin.
Case 4: Dr Consistency
This hero is a great member to have in an environment with multiple teams and workers that move between projects. Dr Consistency is able to see development patterns emerging and set and enforce coding standards. This hero is key to a multi project environment where maintenance is a concern.
Consistency takes time and refactoring however. Organizations who are not willing to allocate time spent working on code that shows no change to the end users should avoid this hero. He can also clash with super speed man when consistency adds time to the development process.
This was kind of fun. Maybe next I'll do super villains.