SmoothSpan Blog

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.  I’ve been managing developers for 27 years now, including a couple of stints that have involved selling tools to developers (via Borland and my Integrity QA startup, then at Rational/Pure Atria), and I just don’t think of them as “hobbyists”, “enterprise timeservers”, or any of the other possibilities suggested.  Likewise, while I found Coté’s alternative niches vaguely entertaining, they didn’t fit either in terms of providing me a unified field theory of how to think about developers.  Part of the problem is in not defining what the segmentation is for.  When I hear “segmentation”, I think about mapping out a plan to go sell something to an audience.

Putting all that aside, 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!

FWIW, I rate myself a “5” on the 1 to 10 scale of hacking.  I grind out code pretty well, but if I’m productive, it is more because some of the other Wushus have allowed me to write less code.

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.

I will somewhat egotistically give myself a “10” as a Language Polyglot.  It’s what I do best.

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.

I will charitably rate myself an “8” as an Algorithm Mentat.  I don’t love it enough to do better, not like I do Languages and UX.

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.

I rate myself “9” on UX.  I hold the patent on spreadsheet notebook tabs (originated in Quattro Pro), and would be named on a patent for the right mouse button if we hadn’t felt it was entirely too obvious to patent back in the day.  We did that first and I remember the Microsoft Product Managers where lined up in the aisles taking notes like crazy when we first demoed Quattro Pro at Comdex.  Pretty soon Excel had these features too, LOL!

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.

I’ve done architectures for software that’s stayed fresh without need of rewrite for many generations, so I’ll call myself a “7” on this type of Wushu.

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.

I do okay with process and was practicing a variation of Agile Programming before the movement even had a name.  There are papers written about the productivity and processes used by my Quattro Pro team by a Bell Labs PhD named James Coplien.  They serve as some of the earliest working documents for the Agile movement.  Based on that, I put myself down as a “7” on process.

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.

While I have done Black Box reverse engineering, and managed to derive the Lotus 123 file format for Quattro without disassembling any of the software code in 123, I don’t rate myself very high on the Black Boxer scale.  Call it a “4”.

Conclusion

There are at least 7 Kinds of Developer Wushu.  If there are more you can think of, please comment.  It should make for a spirited discussion.  Any developer has strengths and weaknesses along all of these dimensions, though I’ve never met a developer that was a star in every category.  It takes all kinds to round out a team, so it may be helpful for teams to take inventory of the Developer Wushu expertise of their members.  It can shine a light on strengths and weaknesses and inform how you hire and grow the team moving forward.  It may also be helpful when interviewing new developers to think of questions and discussion topics that focus in each of these areas.  Get your developers who excel in a particular art to focus on questions about that art.  You’ll pretty quickly understand what your applicant is capable of and what will be challenging for them.