The Difference Between Bad, Good, and Great Startup Engineers

Given something that needs to be built..

A bad startup engineer will immediately start to build it. There’s very little consideration for how it should be built, ways it could be built and what the trade-offs are. You say make a button that when pressed does X. They make a button that when pressed does X. No questions asked. The project will get done in a week but it’ll be buggy. You will probably spend the next 3 weeks fixing bugs. In 3 months, they will tell you that they need to re-write the entire thing. At some point, another engineer will tell you a non-trivial amount of the code they wrote is copy and pasted from Stack Overflow. Your very promising startup will feel like it’s stuck in the mud. Constantly slipping and falling over itself.

A good startup engineer will consider how to build it but only in the most elegant, scalable, highest quality way possible. It will be a work of art but it will take a month to build and be complete overkill. Most recent Computer Science graduates are like this. They learned all the theory and can’t wait to put all of it to use. And by all, I mean all of it. Your very promising startup will feel like sitting in a car with a Grab driver who drives so slowly that you wonder if you’ll get pulled over. When merging, they wait until there’s no other visible cars on the road (maybe the planet) before merging. You will get there, and you will get there safely but by the time you do, dinner will be over and your friends long gone.

A great startup engineer will ask for context. Why are we building this? What are we trying to accomplish by building it? How do we know if it’s successful? After getting the appropriate amount of context, they will go off for a few hours and come back with options on how to build it. Typically those options will include the following..

1. Fast But Low Quality – If we cut corners, we can get it done in 3 days with minimal bugs but it’s not that extensible so if X happens, we’ll have to re-write it but I don’t expect X to happen for another 3 months.
2. Slow But High Quality – If we do it the “right” way, it’ll take us 3 weeks but we’ll never have to re-write it again. It’ll be extensible and scalable from the beginning.
3. Moderate and Moderate Quality – If we cut the right corners, we can get it done in a week. It’s relatively extensible and scalable. We might have to make improvements at some point but that shouldn’t be for at least a year.

These are the best engineers and it’s not close. I tear up a little bit thinking about them. Your very promising startup will feel like it’s being led by an experienced, capable guide in search of treasure. You still have to figure out where to go, what you’re looking for, etc. but there’s someone there who knows the terrain, knows how much food to pack and where the dangers are. With them, you feel like anything is possible and start dreaming even bigger.

Why are engineers like this so valuable to a startup? At a large company, the product has been mostly figured out. Engineers are mostly focused on scale and extensibility. At a startup, the product has not been figured out. Frankly, you don’t know if the product you’re working on now will be the product you’re working on in 3 months. 80% of the code you write will be thrown away. Not because it’s bad but simply because you’re trying to figure out what your users want. Startup engineers will build features one week only to remove them 2 weeks later.

In that type of environment, the most important thing for the startup, and by extensions the engineers at the startup, is iteration speed. Sometimes people interpret that as engineers who get things done through hacky code and lots of bugs. In fact, that drastically decreases your iteration speed. You end up spending so much time fixing bugs and it’s hard to tell if people want what you built because it’s so buggy.

To increase iteration speed, a startup needs to find the right balance between speed and quality of code. It’s knowing which corners to cut.