Tuesday, January 20, 2015


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.

Puzzle-solvers love software development because it gives them the opportunity to solve difficult problems.  To them, they tend to look at every task as a puzzle to be cracked.  Every task is a challenge--a challenge to see how they can write it in the most efficient way, or with the least amount of code.  They may choose to use new technologies, even though they aren't technically necessary, just because it's fun for them to learn something new.  In the worst case scenario, if they are bored at work, they may even entertain themselves by making their code needlessly complex just to challenge themselves, not that they'd ever admit to it.

Puzzle-solvers are a great resource for any team.  They are typically very smart.  They contrive solutions that no one else would even think of.  They excel at building the lower level components that everyone else shies away from.  They are great at creating and implementing complex algorithms.  They are the ones you should call when you need to fix something that's running too slow or that uses too much memory.  They can even sometimes be helpful in tracking down those hard-to-reproduce bugs.

Like everything, however, all of these strengths come with a downside.  Since they are so comfortable with complexity, they can wrongly assume that others are comfortable with it too.  They create things that they, themselves, have no trouble using, but are difficult for everyone else to understand.  Since designing a good system architecture requires a reduction of complexity, they tend to not be as good at it as others are.  Rather than asking a puzzle-solver to develop a new framework or to design a new system architecture, it's typically better to assign them the task of developing the lower level components which will then be wrapped behind higher levels of abstraction.  They can be great to have around in a design meeting, especially at the beginning, when out-of-the-box thinking is really valuable, but once the overall design is settled, their input on the nitty-gritty of the system's architecture and user-interface will likely be less helpful.

No comments:

Post a Comment