The Scientist, the Artist, and the Engineer: S/W Dev Archetypes

After many years of working with, hiring and managing a wide variety of software developers, I noticed a trend that guided me in my hiring decisions. And, I often used this when giving feedback or career advice to programmers, as well as in my hiring choices.

While there are many ways to categorize and rate software engineers, I observed three primary archetypes emerge after years of interviews: the Scientist, the Artist, and the Engineer. Of course, this is a generalization and no one falls into a single bucket. These archetypes are defined primarily around motivation and core values, but I also believe that skill and talent play a factor too.

The Scientist

the Scientist

The first developer archetype is the Scientist. These are software developers that usually have a foundation in academics, research, and more formal computer science or mathematics. The Scientist worships theory, elegance, and formal proofs. Most Scientists will prefer to do the correct and long-term solution over hacky, fast, short-term, practical, or ugly solutions. Scientists can be important members of your team, and often are the deepest thinkers. But, be careful, they need to understand the reality and importance of business needs. I have worked with a wide range of Scientists developers with mixed results. In many cases, the Scientists were difficult to work since their superior intellect–which they like to assert on managers and business folks and anyone who will listen–would often blur their vision and cause them to work in the ideal world, not the real world. They often are cynical about the importance of business requirements and can be difficult to work with (since they report to a higher power, “the truth”). Of course, I have worked with several that understood and embraced business purposes and were the key develops in the team. I have noticed that experience plays a big role in the Scientist; younger Scientists, just out of school, are often the most difficult. But, given time and experience, the smart ones see that the world and business are far more complicated than they thought, and they begin to show respect for the complexity of building a successful business.

The Artist

the Artist

The second developer archetype is the Artist. Beware of this group. They are primarily motivated by `their works of art’ and see what they do as about them. They are motivated by ego, self-satisfaction, and sometimes great work. They are not in it for the customer or the company; they aspire to higher virtues such as beauty, elegance, and uncompromising perfection (usually defined by their standards). They can be very talented, prodigious, and detail-oriented, but are often the most difficult to work with. Artists are usually talented, but, their talents are often narrowed to their area of interest since they can be uncomfortable if they are not the expert. I have worked with a few Artists that were seasoned and practical. But this came after years of learning the hard way. Beware the Artist.

The Engineer

the EngineerThe third archetype is the Engineer.  The Engineer worships results. The Engineer is the most centered of the three and usually the best hire for a company. I try to build the majority of my software teams from Engineers. Of course, depending on the problem you are solving, you may vary the mix (e.g. require more Scientists). But, almost always avoid the Artists. 🙂 Engineers understand that they are problem solvers. And, the good ones recognize that the problem is rarely as simple as What Code To Write. Good engineers are interested in learning new things and solving problems for their customers. They are honest about their work, enjoy measuring their own results, and recognize that: 1) the real world is messy and complicated, 2) it’s not about them, and 3) if the customer does not benefit from their work, they’re doing something wrong.

The hard part is learning how to separate the Engineers and Scientists, from the Artists. I intend to write about hiring engineers in a future post.


What you know vs. what you don’t know (part 2)


This is my second attempt to explain this little jewel taught to me by Dr. Dan Garber, professor of Engineering at the University of Maryland (sometime around 1979). See my original attempt.

A couple of people have commented “doesn’t the yellow circle represent your current knowledge better than the blue circle?” Answer: “No.” 🙂 First, the total body of knowledge is roughly infinite and thus needs to have infinite dimensions, and is therefore represented by the infinite plane that the circle is drawn on. The area inside the circle represents your current knowledge. In this metaphor, it would need to be an area covering gained knowledge, not a line with zero area. As you grow older and gain more knowledge, the circle expands and the area grows. [Obviously, a more sophisticated model would be n-dimensional and much more uneven than a circle, but let’s not go there. ;-)] The yellow circle is the edge between what you know and what you don’t know. You can think of the edge as your `knowledge horizon.’ Beyond the yellow is the stuff that you don’t know. And, so the point is that as your knowledge grows (area in the circle), your `knowledge horizon’ also grows, and thus your perception of how much you still have to learn grows too.

Again, it’s simple, maybe a little trite, and cutesy, but it reminds me of Dr. Garber’s kind, fatherly mentoring and reminds me not to get carried away with my own brilliance. 😉