Jeremy Kahn's Dev Blog

There's always a method to my madness.

Developers vs. Engineers vs. Scientists

I’ve been programming professionally for about 3 years at this point, and I’ve noticed some interesting patterns in other programmers I’ve worked with. One of the key differentiators among programmers is motivation. I’m not referring to an individual’s passion to simply be successful in their career, but rather the type of work they want to pursue. The thing they want to do with computers every day, the types of problems they are interested in solving.

The programmers I have observed generally fall into one of three categories: Developers, engineers, and computer scientists (or just “scientists”). These are not silos. They are ranges on a spectrum, and programmers may find themselves oscillating all over this spectrum throughout the course of a day. However, individuals are usually more comfortable in one of these ranges than the others.

It’s important to make something very clear at the outset: The categories I describe here do not imply differentiating levels of aptitude or intelligence. A developer can be every bit as smart as a computer scientist - it’s the interest area that sets programmers apart. It’s also worth noting that the definitions here are not official in any capacity, this is strictly my opinion.


Developers want to get things done. They are the prototypers, the guns for hire, the guys you can trust to get something workable by the end of the day. They are also reliable for driving a project to completion. Developers love to keep up on the latest jQuery plugins and Ruby Gems. They are always learning the newest tools that will solve their problems faster. Developers are especially useful for building websites in deadline-driven environments. From a business perspective, it is valuable to have someone like this who can hack something together without getting bogged down in technical minutiae. As for starting a programming career, “developers” face the lowest barrier to entry.

Developers run into trouble when their tools stop working. When the third-party JavaScript library they’ve been using suddenly doesn’t meet project requirements exactly, they often have to resort to strange workarounds and code comments like /* DON'T TOUCH THIS!! */, rather than gaining a comprehensive understanding of the problem and why their solution works. At least as far as this definition is concerned, a developer’s knowledge area is a mile wide and a meter deep.


Engineers are interested in the mastery of a problem domain. Engineers don’t settle for solutions that “just work,” they dig until they have a holistic understanding of the big picture. They focus on reusable solutions that scale, elegant architectures, and building tools to automate work. Engineers are adept at designing unique solutions for unique problems. Engineers prefer to write and maintain the Ruby Gems that developers find themselves learning and using.

Engineers are sometimes more interested in building solutions than they are in actually solving problems. Rookie engineers in particular will spend a lot of time solving problems they may never have, because it is an interesting challenge for them. If you are managing engineers, it is important to keep them focused on practical tasks, rather than unrestrained experimentation and exploration. That’s what their Github hobby projects are for.


Computer Scientists live in a world of theory and are the most likely to advance the state of the art. These are the algorithmists, the mathematicians, the statistical analysts. Depending on what you are trying to build, scientists are indispensable. They build solutions for the problems that most people don’t even understand.

At least in my experience, computer scientists aren’t the best builders. While they construct the most elegant and efficient theoretical solutions, they may not write the most readable code or maintainable systems. Since they are in the minority that actually understands certain complex problems, knowledge transfer becomes an issue. Even with good documentation, it can be difficult to get inside the head of a scientist that has been working out a solution for several weeks.

The skill set of a scientist has a lot of overlap with that of an engineer. I would argue that these groups are differentiated by a focus on theory versus implementation. Scientists focus on theory, and engineers focus on actual implementations. The programmer with a good mix of science and engineering is a true phenom and an invaluable asset. This type of programmer is also very rare.

It takes all kinds

A truly effective team consists of all three of these types of programmers. A good baseball team leverages the strengths of each of its players, and a development team is no different. For my own part, I find myself most comfortable near the “engineer” range of the programmer spectrum, but I often venture into the “developer” range for various tasks. I identify myself as a “scientist” less often, but it becomes necessary from time to time. The point is, programmers flit all around the spectrum, but tend to gravitate towards one range more than others. Balance your team according to what you want to build.