Another really good breakdown of developer psychographics, following James Governor’s original post - which I covered at the time.
James Governor got me thinking along these lines by asking how to segment developers. He asked whether the web “killed” the professional developer, or at the very least radically reshaped the segments. I don’t know about all that, in fact I’m pretty skeptical. But what I do know is that the way James talked about developers didn’t really resonate with me at all…
What really was more interesting to me was thinking about how to dimensionalize the skills of developers. There are a number of very development-centric skills that I have seen that describe what developers are capable of in terms of development. We could add a bunch of the usual more HR-centric qualities (works and plays well with others, yada, yada), but let’s keep to being development centric.
What then are the 7 Kinds of Developer Wushu?
1. Hackers
I’ll start with the purest expression of development Wushu. The Hacker grinds out code. Uber Hackers practically exude it from their pores. I had the pleasure of working with Rob Barnaby, the creator of the original Wordstar word processor for one gig. Rob was the consummate hacker. He could directly type code in as fast as a touch typist could transcribe and in fact, it often seemed like the keyboard was preventing his expression of code from proceeding as fast as his mind could create. Watching Rob in action convinced me once and for all that an editor had to be fully operable without taking one’s hands from the home keys to facilitate this kind of bond between man and machine at the highest possible bandwidths.
Hacking is distinct from the other forms of Developer Wushu, as we will see. As an aside, “hacking” used to have a very bad connotation, and maybe it still does in some quarters. At one time it meant someone who haphazardly coded, beating their way through the process through sheer trial and error brute force. It was the antithesis of the elegance so many developers worship. When I use the term “Hacker”, I mean it in a good way!
2. Language Polyglots
Did you read “Godel, Escher, and Bach?” Did you really understand what it all meant? Did you glide through that book effortlessly, constantly in agreement, and finding it a sheer joy? Or was it one of those books you see that smart people all claim to have read and understood, but that was sheer drudgery for you? If you’re in the former category, you may be a Language Polyglot. For you, the ability to execute a language, to be a Turing Machine, is the highest accomplishment of the computer. It’s what makes it our only Universal Machine, at least until somebody figures out nanotech replicators, which will have to be computers in large part anyway. My first product, Quattro Pro, contained no less than 18 specialized interpreters that implemented various domain specific languages to accomplish different deeds. These little interpreters made Quattro Pro easier to write, faster, and more flexible than the competition. In the end of the day, all things computer wind up being lanuages. Adobe proved that by making printers into languages in the form of Postscript.
The Language Polyglot makes every problem into a language of some sort. These folks worship Lisp (first language I learned to program in, yes, I’m a Language Polyglot). More recently, they create tools like Ruby on Rails. Ruby, the language, by itself is interesting. Rails, a framework on its own, is another framework. But somehow the marriage of the two is magic. It takes a Language Polyglot to figure out that sort of thing. Good ones are responsible for all things Meta, which is to say imbuing a software program with the ability to change and take on some of the universal character that makes the computer a unique machine among machines.
3. Algorithm Mentats
Ah, the Mentats of Dune. What a compelling image.
Does your software need to be fast? Does it need to scale? If so, you’d better have some Algorithm Mentats. These people uniquely understand how to combine algorithms and data structures to make a software program fly. There are lots of sub-specialties. Database algorithms, parallel and distributed computing, graphics, and others to name a few.
A good Algorithm Mentat is not just good at creating algorithms, these folks are often the most familiar with the literature in their areas of specialization. Computer Science, as a discipline, is largely about Algorithms and Languages, with some Architecture in the sense I will describe shortly thrown in.
4. UX Wizards
If some poor user actually has to understand and hopefully love your software, your success depends on the quality of your User Experience (UX). This area is poorly understood, frequently abused, and much talked about. Everyone is a consumer of UX and everyone therefore considers themselves expert at UX. Most of them are wrong. Some view UX as a Design problem. It’s not really, although Design helps a lot. Some view it as understanding Workflows, and there are elements of that. I think about it as a mixed discipline that involves Design, Workflows, Communication, and a deep understanding of what the User is trying to accomplish.
UX is about crafting a medium that communicates in both directions. Until we had computers, communication was largely one way. We had writers, composers and musicians, actors, and so forth. Those folks have a lot in common with UX, but let us not lose sight of the fact that like any medium, UX is specialized. We don’t expect Mario Puzzo to be a great movie director nor Steven Spielberg to compose a symphony. They’re masters of a particular medium. And, it’s a medium that morphs. Batch had a particular UX, then we had dumb terminals. PC’s ushered in an era, and then we had GUI. Today we add Social and Mobile. What a rich palette for the UX artist to draw from. It’s all still here, amazingly enough.
5. Architecture Builders
Architecture Builders are masters of arcs and circles. They know what to put in the boxes and how to connect them for best results. They think in layers, abstractions, and interfaces. Refactoring is a joy to be embraced each and every time it is called for. Patterns are their method of expression, as are the various odd notations associated with Object Modelling. All large products need Architectural Builders, lest they be poorly architected and collapse under their own weight. A good Architect can create a product that allows more people to work on it longer, which can be a decided competitive advantage. Bad architecture results in constant rewriting with the difficulty of finishing increasing almost exponentially with each new release. Architecture Builders are masters of managing complexity and hiding it where its mischief can be minimized.
6. Process Plotters
What do you call that developer that has a million little scripting tools that make them awesomely productive? They seldom have to create much as they’re forever transforming or improving using tools and processes. These are Force Multipliers not to be underestimated. Whether your Process Plotters are focused on the scripting and tools side or whether they’re focused on Agile Programming or whatever other methodology is the tool of choice. They know when you have too much process and it is interfering with productivity. They know when you have too little, and it interferes with quality and ultimately, productivity. With the right tools, they are the consummate DevOps gurus. They are consultants and managers who set forth the right campaign to accomplish your goals in a timely way.
While many of the processes and tools of development are useful in other disciplines, there has been little evidence the converse is true. Assembly lines, Six Sigma Black Belts, and the like have not made much impression on the world of software. It is for that reason that I call Process Plotting one of the 7 Wushus of Development.
7. Black Boxers
This one is a curious trait, but I have seen it in action too many times not to be certain it exists as a powerful skill. Black Boxers know how to deal with Black Boxes. They’re the best debuggers, the best at going into code they didn’t write and understanding it. There are different kinds of Black Boxers. Some are ideal QA experts. They formulate tests that are effective in mapping out the unknown territory associated with Black Box testing. Some are very low-level. One of my startups involved very sophisticated automated software testing tools. We had frequent “blue screens of death” as our software had to do a lot of undocumented and unsupported unnatural acts to accomplish its job. One of our team was an awesome Black Boxer. He had a hardware debugger, which was a card with a button that could stop the machine and let him poke around inside what was left. From that, he could usually figure out the source of our BSD and tell us how to fix it.
Incidentally, the very best Black Boxers hack security and break copy protection schemes.
