Hackers or Engineers?
I’m going to to talk about two archetypes I’ve observed over my career as a developer, the Hacker (the programmer kind, not the software breaking kind) and the Engineer.
How to Spot a Hacker
Hackers get shit done, and fast. It may not be the most elegant or scalable solution, but it comes to life, and it works, and it solves a problem or is just something cool.
Hackers value source code over support or documentation. Hackers thrive in open source. This also makes them fearless. They have the attitude: if you have the source code, you can fix any problem you encounter. Hackers read a lot of code.
Hackers are polyglots by nature. They are curious and want to learn the newest programming language or framework that will enable them to build something novel.
This person is trawling the trending repositories on GitHub and ‘wow, cool, think of what I could build with X.” And then they do it.
Hackers come from everywhere. They don’t necessarily study computer science, or even go to college at all.
The Engineer
The Engineer, on the other hand, is generally characterized by discipline, meticulous engineering practices, and a strong computer science background.
In short: the Engineer knows how computers and systems work. They often cover the entire stack, and at least one part of the stack they work in very deeply.
Great engineers understand the tradeoffs of what they do, and can express the performance of their solutions in big-O notation.
Where Hackers are early-adopters and often make decisions based on possibilities, Engineers value time-tested solutions, experience, and authority to back their choices.
Engineers strive to write code that is beautiful, maintainable, and lasts the test of time.
It’s Not Mutually Exclusive: The Hacker/Engineer
I’ve had to privilege to work with some amazing people who embody the craftsmanship of the Engineer AND have the creativity and curiosity of a Hacker. They have strong engineering practices, powerful groundings in computer science that enables them to solve things elegantly and efficiently. Yet they do not shirk from new technology, libraries, techniques to cobble together something to solve a real problem in a novel way.
Off the top of my head, some more “famous” examples of this include Brad Fitzpatrick (of Livejournal, Memcached, Go fame) or TJ Holowaychuk (that guy who writes all of the libraries you use in Node, and is now doing the same for Go).
These are people you want to keep with you. If you could fill 100% of every team with people who represented both of these archetypes, it would be ideal.
Don’t Pigeonhole Yourself — Evolve
No matter where you consider yourself on the spectrum now, strive to become both a Hacker AND Engineer.
My friend Mark and my cofounder Dustin are Hacker/Engineers. Neither have computer science backgrounds. They both started off hacking things together and picked up knowledge of algorithms, system internals, engineering practices like testing and how to write clean code, etc along the way.
I, on the other hand, started off more on the Engineer side. I learned a lot from a classical computer science education. Though I was always tinkering with Linux when it came to my first programming ‘job’, I lived in the Microsoft/Java world. It was always my tendency to agonize over how to solve something in the cleanest and most elegant way.
Now I don’t think I could ever live in a world where I was restricted to a set of closed-source libraries and solutions to solve a problem. I now often write code that is sloppy so that I can ship it faster. I integrate open source code into everything I write and contribute to OSS whenever I can. I read Hacker News, Github, and various blogs to look for new trends and technologies I can use accomplish something cool in a new, better way.
The Hacker Ethos is Contagious
One other thing I’ve discovered is that the Hacker ethos is contagious. Put a couple of hackers on your team and you’ll see them subtly influence the rest of the team — encouraging use of a new framework or technology or library, pasting in cool stuff, prototyping things on their own that weren’t part of a sprint backlog. Other developers will chime in and be inspired by this.
Similarly, a young Hacker with a good attitude paired with a meticulous Engineer will learn good engineering practices that will improve his ability and extend the lifetime and maintainability of his code.
Who should I hire for my startup?
Assuming you don’t have the ability to fill your engineering team with Hacker/Engineers, and with the caveat that the ratio may change depending on the nature of the product you are building (e.g. are you building a space shuttle? or a mobile app), you should live by the following rules:
During the early growth phase, weigh your team heavily toward hackers and Hacker/Engineers. Because you are probably going to throw away all of your code anyway. You need people who are inventive, who are going to be able to cobble together working code and iterate fast to get to the next milestone (MVP, fundraising demo, first customers) over something that is going to be maintainable and last the long haul.
During the scale phase, add seasoned Engineers. At this stage, you need people with experience and most importantly patience to iterate on the code to make it viable for the years to come. They can take your crappy prototypes, refactor in time-tested solutions for scale, and help evolve your product to 100k users and beyond. Assuming you have all of the questions about business model and product-market-fit already established, you now have the luxury to spend months on developing elaborate scale-test harnesses and all of the things that make your software easy to work on and maintainable. Presuming you have laid out some engineering practices already in place, Engineers can evolve them.
