XOR Media

Coding, Operations, Etc.

Types of Software Engineers (Part 2)

Posted on Wed 23 January 2013 by

This is part two of a two-part post on the general categories of software engineers. To pick things up at the beginning, check out the first.

Researcher

Big problems with lots of unknowns. Don't know where to start. Call in someone who's good at dealing with ambiguity and doesn't have a blank-sheet problem. You're in need of a Researcher. They'll dig/read/experiment from here to (some sort) of solution, but you'd better not rely on being able to put their code to use as-is. It will be the result of a million tweaks, changes, and re-jiggerings that result in a mess that only its creator can even begin to unravel.

Rare is someone good at solving big abstract problems who can do it cleanly. Don't let the researcher title make you think you need a Ph.D. Many Ph.D's will have the right sort of mind/skillset for this type of work, but it's not exclusively their domain.

Product

The best product managers are engineers who fit, or at least know, your target audience and care. This person/role runs everything through a filter. Is this the right thing for the user? Will it make the experience better, solve the problem more quickly, and/or make an appreciable difference for the company? They won't necessarily be the strongest coder, but they have a vision for where things need to go and a knack for ignoring/shutting down things that won't help get there.

Leader/Mentor

Hard to find. Even harder to interview for. Leadership is in the details. This is not a manager, it's a technical lead. They get the best out of a team and grow all of its members. They have to have enough technical chops to earn their peer's respect. People will come to with questions rather than being forced to run things by them (a la code reviews, etc.)

A great leader can recognize someone's strengths and weaknesses and help them to find a path that fits the strengths and shores up the weaknesses. They recognize roles and know how to best allocate the team in to them.

Summary

The truth is every position involves a bit of each of type and everyone has a bit of each in them. Neither people nor roles are one-dimensional, but there are benefits to understanding and being able to identify them. You'll have a happier team, less turnover, and more quality/production.

The next post in this series will start to discuss how to find and interview candidates for specific roles. As always, let me know what you think.

In people, tagged: hiring, and opinion.

About the Author

Ross McFarland Ross McFarland | | |

Ross is a 17 year veteran of the software industry with experience spanning low-level signal processing, web and mobile user interfaces, high-scale distributed web services, infrastructure, and networking. He has made extensive contributions to open source highlighted by his time as a primary maintainer of Gtk2-Perl and author of requests-futures and python-asynchttp libraries. (more)