08/13/2015 10:09 am ET Updated Dec 06, 2017

The Difference Between Hackers, Programmers, Engineers and Computer Scientists


Author Anthony Scherba is the President and Founder of Yeti, a product focused development and design studio in San Francisco. Yeti works with companies from large enterprises to startups on building innovative products that blend the physical and digital world.

The terms hacker, programmer, engineer and computer scientist get thrown around a lot, and they're all too frequently mixed up as a broad definition of anybody who's working on software.

But if you want to effectively clarify business needs and project goals, it's important to understand that these are not all the same thing (though someone who can program a computer can utilize different skills to achieve different outcomes). At Yeti, we try to make a clear distinction from when we're hacking, programming, engineering and applying computer science to our development process. It helps with both our frame of mind and our goals for the development and product management teams.

If you also work with software development teams, it's important to know the difference between these terms, and that they are not interchangeable.

The Hacker

Hackers build things quickly to try to get them off the whiteboard and into your hands. It's more about proving a concept than caring about long-term quality. So while hackers often have to be able to conceptualize how a product will eventually get built while furiously writing code, this role is all about speed. Hackers and "hacking it together" are mostly valuable when prototyping a product or dealing with an emergency situation. Hacking is not concerned about the long term effects of the code.

For us, hacking is mostly used in the prototyping phase. For instance, when connecting a home appliance to a mobile phone. In the early stages we will rapidly prototype a couple of educated guesses on how we can make them connect -- the goal is to just see if the pieces will fit together. We know later we will make the solution much more robust. Hacking is a known sacrifice of quality for speed.

The Programmer

The role of the programmer is very procedural and requires full concentration and well-defined skills. Programmers are entirely focused on writing code and getting features done the right way, so the features are available for later use and integration. Programming is the act of actually swinging the hammer and building the software well.

You can usually tell someone is in a programming mode because they are "in the zone" and generally have a concentrated stare. A programmer is internalizing the system they are working on and writing and editing pieces of what can best be described as a very large algebra problem. In any piece of software this requires a lot of concentration to do correctly because simplifying, documenting and writing tests for your code is very important to help others understand it later (including the programmer). Most of the time we spend on software development is concentrated programming.

The Engineer

Engineering is about looking at the big picture of the project and coming up with solutions. How do we build this appropriately? The engineer is looking at both the entire project to define a plan, and the tasks required to execute that plan. Best practices are very important to the software engineer. Engineers understand business constraints and use that real-world knowledge to create a multi-tiered solution.

Engineering is when the headphones come out and the software development team ends up at the whiteboard. It's the process of looking at what should be going on with the system and where the programming tasks should be divided up. When new parts of an app are getting built, previous decisions start causing issues or business requirements change, engineering is important.

In a marketplace app, for example, it's very important to spend time engineering the proper way the system will handle payments and how the data will be stored. Just hacking or programming this is hazardous. At Yeti, we encourage this behavior often -- we make sure to have engineering planning meetings each week to stay on track.

The Computer Scientist

Pure computer science is involved much more with the abstract. Computer scientists look at the tools we're currently using, how they work now and how they can work in the future. There are many branches of computer science -- AI, programming language theory, databases, networks, graphics -- and the field is evolving at a rapid pace as technology evolves. It's a very young science (relative to other fields), and has really only been studied for less than a century. Just as a civil engineer should know the science of physics, a good software engineer should have a solid grasp of computer science.

A good example of a computer science pursuit is figuring out how to make the languages we use more efficient, readable and speedy. A large group of computer scientists study how we write better code and make it more effective on the computers we run it on. This sort of work has large implication for the industry and the future.

The Distinctions Are Important

Products at different stages have different needs when it comes to development. If you're trying to build a working prototype as quickly as possible, hacking something together is great. Most of the time, when developing an application or complex system, you'll need your engineering team to spend a lot of time as programmers. When the system is being designed and architected, your engineer will spend a lot of their time initially using their knowledge of computer science to assess and architect the system optimally. R&D efforts, early product development and solving tough scale and data problems usually require at least some degree of computer science thinking.

Knowing these differences in style and mindset can help you direct your team's focus towards the best procedures and solutions. It will help you build software products without the pain of not knowing what your team is doing or why certain things are happening. Hopefully your development team will be happier as well, since their manager will understand what is going on day to day.