Are You A Hacker, Developer or Engineer? (And Why it Matters)
In the software world, the terms “developer” and “engineer” are often used interchangeably to mean “someone who builds things with code.”
Sometimes the word “hacker” gets thrown into the mix if the company is a startup or is trying to make an open job position sound more enticing.
But what does it mean for someone to be a “developer” versus an “engineer”? Does it matter? If you’re trying to “level up” or make a career out of writing code, I’d say it matters a lot.
I recently came across a presentation called So, You Want to be a Front-End Engineer by David Mosher that offers a great overview of how front-end code is executed in the browser. He has an accompanying video presentation here (1 hour).
But he begins the presentation by describing his path to becoming a front-end engineer, and each of the steps most people follow along the way. In the process, he offers a nice definition of “hacker,” “developer” and “engineer” that highlights their differences quite nicely:
A hacker can come up with solutions, but maybe they can’t look back after they’ve finished and realize how they came up with the solution. They just kinda poke at things until they get something that works.
At some point, you level up and become a developer and a developer understands best practices. They’ve heard other developers say things like “you should put your scripts at the bottom of the webpage” … and you use those best practices to craft solutions but you don’t really understand beneath the best practices, beneath the abstractions.
An engineer is someone who can get things done, craft a solution – they understand the best practices, but they also understand why they’re using the best practices that they are … [they] move into an understanding of the platform as a whole.
The labels themselves aren’t as important as the degree of awareness and understanding that each new “level” brings.
From Hacker to Engineer
Listening to David’s explanation, I was immediately reminded of my own progression as a web developer.
When I first got started, I used MySQL as my database because that’s what all the tutorials said to use and I had no idea what the other options were. I copy/pasted some code that I found online and built my own tiny blogging engine in PHP. I had no idea what I was doing, but it worked for my use cases and that was good enough.
About a year ago, I started learning MongoDB because that seemed to be all the rage on Hacker News. Surely if others are using it, it must be really good. I read about indexing and normalization because people seemed to be talking about those a lot and I wanted to learn all of the best practices.
Now, I’m taking a Coursera course on Data Science and another called Introduction to Databases and am starting to understand the why. Why were relational databases created in the first place, what problems did they solve? Why would you choose a schema-less database versus a relational one? Why do indexes make your queries faster, and what are the drawbacks to using them?
Moving Through the Stages
Not only does the degree of understanding change across the levels, but the type of learning that takes place is also somewhat unique. As a hacker, you can play with other people’s code, copy/pasting it around and making tweaks until things seem to work well enough. When you hit a road block you Google it, then move on to the next one.
As a developer, you need to start paying more attention to the community. Subscribe to blogs or Twitter accounts that talk about technologies you’re interested in so that you learn best practices and see how others are approaching similar problems. Sites like Hacker News or technology-specific subreddits can be good for seeing which articles are the most valuable in the community. Your learning is fairly passive and you follow the lead of others.
But you can’t really expect to become an engineer by reading the most popular blog posts in software communities. You need to start learning about things that you didn’t know you didn’t know. Here’s where reading a book or taking a full-fledged academic course really becomes essential. They usually offer the breadth to survey the whole field and give you perspective, showing you the how and why.
David’s definitions really crystallized these stages for me, and I think it’s important that everyone who aspires to make a living writing code is aware of them, and is realistic about where they fall on the spectrum from hacker to engineer.