Wednesday, January 21, 2015


This article is one in a series. See the introduction here.

Solution-providers are passionate about what they do, but in a very different way. While the others kinds of developers that I've mentioned care deeply about the inner-workings of the software and how it is structured, solution-providers care about the user experience.

Don't be fooled, mind you; just because they are geared towards meeting the users' needs doesn't mean that they are necessarily good people-persons. Many of them are still the typical anti-social developer that you would hesitate to introduce to clients. It's not their people-skills that identify them as a solution-provider; it's what motivates them that matters.

Solution-providers get thrilled by the problems that their product is solving. They are often the feature-visionaries that dream-up all sorts of amazing things that the software could do. Where other impassioned developers tend to find roadblocks (e.g. "that would take too long", "we'd have to refactor our existing architecture to support it", "it would complicate deployment"), the solution-provider paves ahead full-speed because they are focused on the end-of-the-road. Often, to the shock (and sometimes horror) of the others, the solution-providers are usually capable of achieving their objectives in brilliant fashion.

Tuesday, January 20, 2015


This article is one in a series.  See the introduction here.

Some people love to build things. It doesn't, so much, matter to them what it is that they are building. The materials don't matter. Even the end result doesn't matter. It could be a tower of wood blocks, or a train-set, or a model, or a house of cards. None of that matters. The thing being built doesn't even really need to serve a purpose. It's the building of it that interests them. It's the manner in which the pieces were expertly placed that excites them--the careful consideration that went into the configuration and placement of each one. If you are ever able to tear them away from their game of Minecraft or SimCity, and ask them what they do for a living, some of them will tell you that they are software engineers. This is the kind of person that I call a system-builder.

Unlike puzzle-solvers, who care deeply about how each component works, system-builders are less concerned with that and far more concerned with how those components fit together.  Where puzzle-solvers thrive on the underlying complexity, system-builders thrive on reducing that complexity.  System-builders don't care about how a particular component was implemented, they are just interested in how they can use that component as a building-block for something bigger.  They appreciate that some puzzle-solver has already invented the quick-sort algorithm, but they have no particular interest in understanding how it works. As long as it already works, they don't want to take time to reinvent it.  They're too busy thinking of different ways that they could use it.


This article is one in a series. See the introduction here.

Some children enjoy puzzles.  I don't mean jig-saw puzzles.  I mean things like riddles and brain-teasers.  They love finding solutions to difficult problems.  They are clever.  They think out-of-the-box.  Like many others, they are interested in math and science, but perhaps a bit more so.  As they progress, they become interested in higher-level mathematics and physics.  When it comes time to choose a career, some of these people choose to become software engineers.  When they do, they become a kind of developer that I refer to as a puzzle-solver.

Puzzle-solvers get thrills from taking difficult tasks and inventing the cleverest and least obvious solutions for them.  Puzzle-solvers love things like code-golf and code-obfuscation contests.  They don't just admire low level esoteric languages from afar. If given the chance, they'd use Befunge to solve real-world problems--not because it makes practical sense to do so, but just because they find it fun to prove that it can be done.  They jump at the chance to interpret the meaning of a complex regular expression.

Personality Types - An Introduction

When you compare artists, it's very easy to see their differences.  Even non-artists have no trouble distinguishing between major categories like painters, actors, and musicians.  No one would approach a sculptor and ask them to sing at their wedding reception.  When it comes to software engineers, however, the distinctions are harder for people to see.  It's fairly obvious why, and it's not really a problem, so who cares?  Well actually, you do.  Or, rather, you should.

As a manager of a software engineering team, you need to understand and learn to recognize the differences.  Of course there are the outward things--the learned skills.  Some people are more proficient than others in certain technologies, but that's easy to spot.  I'm talking about something deeper.  Their motivations.  The way their minds work.  Why are they a software engineer?  What do they love about it?