> 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.

▲

Karrot_Kream 5 hours ago | parent | next [-]

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.)

▲

crystal_revenge 5 hours ago | parent [-]

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.

▲

Karrot_Kream 5 hours ago | parent | next [-]

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.

▲

edgyquant 4 hours ago | parent | prev [-]

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

	▲	Karrot_Kream 2 hours ago \| parent [-]
		You definitely do. Do you think Anthropic isn't working with thousands of users an hour? They're struggling to keep up with the scale and their ability to create a stable platform is, well, existential for them. Do you think Anthropic isn't a startup? The pace of their feature rollouts is exponential. Even in areas where startups aren't literally creating new product categories like the foundational model providers, the edge of a startup over a more established business is the speed at which they can provide value. What's the point of buying CoolCo when you can go with L&M Inc. that has thousands of headcount working on your feature. The value prop of CoolCo is that CoolCo can roll out a feature in the time it takes L&M to make a detailed specification and a quarterly planning doc breaking down the roadmap and the order of feature implementation.

▲

esseph 5 hours ago | parent | prev | next [-]

> 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.

▲

cyberax 39 minutes ago | parent | prev [-]

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.