Showing posts with label Personality Types. Show all posts
Showing posts with label Personality Types. Show all posts

Wednesday, October 7, 2015

Code-Fiddlers

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

Everyone is driven by a desire to succeed, but for some, success does not come through superior skill or intellect; for some, success comes through will-power and determination. In the field of software development, such people can often be described as code-fiddlers. There was a time when I looked down on code-fiddlers, but I've since come to realize that they can perform better than me in some ways. To the untrained eye, code-fiddlers are hard to spot. They are able to meet goals and create working products just like everyone else, but we engineers understand the big underlying difference.

Code-fiddlers, you see, don't really know what they are doing. Okay, that's a bit extreme, but at its heart there's some truth to it. They obviously have some clue about programming. They know enough to be able to get their code working, but they don't fully understand why or how it works. You may be thinking that sounds absurd--how could anyone write complex functioning software that they themselves don't understand?! If you are incredulous, let me assure you, it's absolutely true. I have worked closely with many developers over the years that fit this very description. At first, I didn't believe it either. I still don't fully grasp how code-fiddlers manage to pull it off, but I assure you, they do. Perhaps it will make more sense by way of a metaphor...

Thursday, April 9, 2015

Hiring by Personality-Type

As I have elaborated in some of my previous articles, the underlying personality of a developer should be of chief concern to you. Depending on the types of products that your team develops, you should have a desired ratio of personality-types among your engineers.  For instance, if you run a contracting service that develops websites for businesses, you will likely want a higher ratio of solution-providers on your team. If you develop pattern-recognition image-processing libraries, you likely want a higher ratio of puzzle-solvers.  Before hiring a new developer, you should seriously consider the type of developer of which you are currently most in need.

Friday, February 20, 2015

Dispassionate-Programmers


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

All of the personalities that I have presented thus far have been people who were impassioned in their work. They have been the kinds of people that became software engineers because there was some aspect of the job that they really loved. Most of those people would create software whether they were paid for it or not. That's not the case, though, with the type of developer that I am presenting today. Today I'm going to discuss the dispassionate ones. The word "dispassionate" can evoke some negative connotations, but that’s not the way I intend it. Sometimes dispassion is a great thing and is precisely what you need.

Wednesday, January 21, 2015

Solution-Providers

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

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.

Puzzle-Solvers

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?