Comment by crystal_revenge
14 hours ago
> You learn the most valuable information from watching how things break and then fixing them.
Trust me, you get plenty of experience in this as a founding engineer in a startup.
Many of these comments make me wonder how many people here have actually worked at an early stage startup in a lead role. You learn a lot about what's maintainable and scalable, what breaks and what doesn't, in the process rapidly iterating on a product to find your market.
I don't think HN has been frequented by startup engineers with leadership responsibilities in any density in a long time. It's very obvious to me reading a lot of the comments here that most folks are ICs somewhere in a large, bureaucratic software organization. That's why there's so much BOFH style commentary here these days.
(For readers, I don't think there's anything wrong with that but it just means that certain perspectives are overrepresented here that may not be more reflective of the broader industry.)
That's what I've come to realize. For most of the commentators here "greenfield" means typing in 'npm init', for me it usually means doing three different roles in order to iterate as fast as possible on the product to find your market, then figuring out how to scale it to the new users you've started acquiring.
The idea that this is means "you don’t learn the actually valuable lessons" is completely baffling to me.
Most people I've know with founding engineer experience or similar leave not because it's not challenging, but because it's exhausting.
Increasingly I've realized that the HN community and I are not even speaking the same language.
Some of the sharpest engineers I knew built tools and business processes at startups and watched them fail as they scale. I ran an internal presentation for years at a Unicorn where I was an early employee called "Failure at Scale" where I tried to capture lessons of huge incidents we had that were caused by us crossing scaling thresholds. Eventually the presentations stopped being meaningful because the company became too big and too removed from its origins.
No but it usually doesn’t mean achieving stability at tens of thousands of users a day (or hour) and ensuring that stability while rolling out new features, migrating infrastructure etc
1 reply →
> how many people here have actually worked at an early stage startup in a lead role
Obviously very few, because these roles are impossible to get into. What else did you expect?
Lots of stuff breaks only after 5 or 10 years. Because you most likely don’t have people who originally built stuff and knew why it was like that.
Then customers and market changed so you also most likely have different customers.
I had to undo a lot of over-engineering to fix performance issues that was implemented in good faith by people who ultimately left the company and they thought they did a good job future proofing our product.
I am with company from start and now it is 11 years. I knew why they built it like it was so I was able confidently what to fix. But it still took almost a year to undo stuff that was making our current customers miserable.
> Trust me, you get plenty of experience in this as a founding engineer in a startup.
Now be part of the team of folks that keeps that application running for 10, 20, 30 years. Now be part of the transition team to the new app with the old data. Those tasks will also teach you a lot about system stability, longevity, and portability... lessons that can only be learned with more time than a startup has.
I'm a founding engineer in a startup right now, and I was a founding engineer in a startup acquired by a large company. So then I became a part of a large company.
The technical challenges are _very_ different between these environments. In a small company you have to deal with technical breakages all the time, but you don't really have systems-level problems.