When given something to build…
Bad Startup Engineers
A bad startup engineer will immediately start writing code. There’s very little consideration for how it should be built. You say make a button that when pressed does X. They make a button that when pressed does X. The project will get “done” in a week but you will spend the next 3 weeks fixing bugs and have to re-write it again in 3 months.
Good Startup Engineers
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.
Recent Computer Science graduates are often 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.
Great Startup Engineers
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 think about it for few hours and come back with options on how to build it. Typically those options will include the following..
- 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.
- 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.
- 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. With them, you feel like anything is possible and start dreaming even bigger.
Why Are They So Valuable?
At a large company, the product has been mostly figured out. Engineers are mostly focused on scale and extensibility. At a startup, it’s the opposite. The most important thing for a startup, and by extension the engineers at the startup, is iteration speed.
Sometimes people interpret that as engineers who get things done quickly through hacky code and lots of bugs. More often than not, that actually decreases your iteration speed because you end up spending so much time fixing bugs. In the worst case, 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 not just about cutting corners, it’s knowing which corners to cut and how.
This thread was originally posted on Hsu Ken's LinkedIn.
