The disproportionate influence of early tech decisions — brandur.org
Spend five years at a hypergrowth startup like Stripe, and you see a lot changes during that time. Organizationally, it’s night and day, as a few hundred people scaled to thousands, the structure adapted to teams with charters and responsibilities that were much more fixed, and with a rigid manage...
Hasnain says:
I’d say a lot of early decisions are important just because the cost of change is often higher than that of leaving a working thing alone. This piece resonated a lot.
“It’s not a bad instinct, but quality is more of a sliding scale than it is a good or bad dichotomy, and I’d argue that many small companies optimize too much in favor of speed by trading away too much in terms of maintainability by shipping the first thing that was thrown at the wall.
And this fails the other way too, where major believers in academic-level correctness agonize over details to such a degree that projects never ship, and sometimes never even start. (Cough, Heroku Dogwood stack, cough.)
As with most things, the answer is somewhere in the middle. Spend time thinking and planning, but not to a degenerate extent – it’s also important to do. Refactoring is a key part of the equation – code is never right the first time, it converges on right through many iterations. And ideally the first couple refactors are significant, not only small patches that leave the bulk unchanged. More refactoring passes are better, but subsequent ones will produce diminishing returns.”
Posted on 2022-08-04T04:34:45+0000