System-Builders

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.

System-builders get thrills from things like shared frameworks, interchangeable parts, and encapsulation.  A system builder will agonize over the structure of an application, caring about things such as extensibility, reusability, stability, maintainability, and configurability.  They worry about technical debt.  They have a penchant for dwelling on names for things, wanting to be as clear and concise as possible with all of their interchangeable moving parts.  They may spend hours trying to decide if they should call something a coalesced-data-aggregator or an integrated-model-analyzer.  Then they'll contemplate into which library it should go, what its dependencies will be, and what will have the responsibility of creating it.  This all sounds like unimportant nonsense, even to other types of software engineers, but to a system-builder, it matters a great deal.  They have good reasons for these things.  They have foreseen the consequences of not doing it right.  They will not cut corners!

If you need software that is going to stand the test of time, then a system-builder is exactly what you need.  If you need a design for a good system architecture, or a framework upon which many applications will be built, ditto.  If you need something done right, call a system builder.  If you need it tomorrow, look elsewhere.  Unless you're twisting their arm, system-builders are practically incapable of doing something in a quick-and-dirty fashion.  If you do twist their arm, they may secretly resent you for it.

If you task a system-builder with doing something well, expect that it will take them longer than someone else.  That's okay.  You wanted it done well.  That's why you asked them to do it in the first place. If other developers suggest that all of that elaborate abstraction isn't really necessary, try to give the system-builder the benefit of the doubt.  They may very well have a good reason for it.

Besides their penchant for over-engineering everything, another weakness of system-builders is that they don't focus on efficiency.  In order to make a product that is well built to stand the test of time, some sacrifices have to be made.  Often that results in a slower, more bloated product.  If that is a concern, state it at the outset and then test regularly throughout the development process, identifying problem areas as they arise.

Since they are so concerned with process, system-builders also tend to have strong feelings about how the rest of the company functions.  Or, more straight to the point, they tend to have opinions about your performance as their manager.  With that in mind, try to have a thick skin as you deal with them.  Seeking out their input or constructive criticism before you make a decision, on occasion, can go a long way towards keeping the peace.  With system-builders, you'll need to keep a sharp eye on their attitudes, since they are the most likely to become disgruntled and, in the worst-case scenario, pull others around them down too.