[overgard]

I don't know about his conclusion of "spend 2 weeks on architecture". If these people don't realize they need to index a database table, 2 weeks of talking about what they're going to do isn't going to help. This is 100% lack-of-experience, and it's why startups should hire more experienced people (and ideally, listen to them).

[JumpCrisscross]

> This is 100% lack-of-experience, and it's why startups should hire more experienced people

But that’s fine. They demonstrated product-market fit. They’re now positioned to be able to afford experience.

Hiring an experienced scaling engineer before you have a hundred users might be about as dumb as spending two weeks architecting an MVP.

[overgard]

The article is talking about timescales around 2 years out though. If you're hitting that point and you haven't fixed your engineering culture..

[JumpCrisscross]

> If you're hitting that point and you haven't fixed your engineering culture

That’s also fine. They’re talking about “a team of 4.” Your priority with a four-person team should not be engineering culture other than getting shit shipped.

[overgard]

If you want to get stuff shipped though, you need a good engineering culture. If you want to move fast you need experienced people. This feels like the argument against automated tests. "It'll slow us down!" So will debugging the slop your coworker thoughtlessly tossed in without bothering to see if it will work!

(I harp on the "experienced people" thing because I see a lot of startups that seem to be 23 year olds vibe coding. That hits a brick wall fast.)

[JumpCrisscross]

> I see a lot of startups that seem to be 23 year olds vibe coding. That hits a brick wall fast

But they’re going fast. That unlocks resources. The whole point is experience is expensive. Moving fast lets you afford that expense. And collision measures velocity.

Messiness is bad. Premature optimization fatal. Young companies tend to be messy because that’s the bias that survives.