Mark Zuckerberg said it in 2004. It’s 2024. Why are we still acting like this is the holy grail of business advice? It’s a lie. Total lie.
I remember sitting in a cramped office in SOMA back in 2017. I was working for a fintech startup called Lendr—not the real name, obviously. It was a Tuesday night, about 3:15 AM. I was the lead dev, and we were trying to ship a ‘minor’ refactor of our core ledger system. We wanted to be fast. We wanted to show the VCs that we had velocity. I ran a cleanup script that I thought was scoped to our staging environment, but I’d accidentally left the production credentials active in my terminal. I dropped a table. 4,200 users woke up the next morning and couldn’t see their account balances. For six hours, we were effectively insolvent in the eyes of our customers. I remember the smell of stale coffee and the way my hands wouldn’t stop shaking while I tried to restore from a backup that was twelve hours old. That wasn’t ‘innovation.’ It was just a disaster.
That’s the problem. When you break things in 2004 on a social media site where people are just poking each other, nobody dies. When you break things in 2024 in healthcare, finance, or logistics, people lose their livelihoods. Or worse. We’ve fetishized the breaking part so much that we forgot why we were moving fast in the first place.
The Zuckerberg hangover
The Zuckerberg era of tech is basically a long, expensive hangover. We spent a decade thinking that if we just shipped enough features, the technical debt wouldn’t matter. But debt always collects interest. What I mean is—actually, let me put it differently. We’ve confused motion with progress. Just because you’re running doesn’t mean you’re going the right way.
Most startups today aren’t building the next Facebook. They’re building tools that people actually rely on to do their jobs. If your ‘disruptive’ SaaS platform goes down for four hours because you skipped a code review to ‘move fast,’ you aren’t a visionary. You’re just unreliable. I might be wrong about this, but I think the industry is finally starting to realize that 90% of the things we ‘broke’ didn’t need to be broken. They just needed to be built properly the first time.
Shipping broken code is like trying to build a house while the foundation is still wet cement.
Anyway, I once worked in an open-plan office where the CEO used to ring a literal bell every time we pushed to production. It was deafening. You’d be trying to debug a complex race condition and—CLANG—someone just changed the button color from #F3F3F3 to #F4F4F4. But I digress.
Why I actually hate Linear
I know people will disagree with me on this, and honestly, the design nerds will probably want my head on a pike, but I genuinely dislike Linear. I refuse to recommend it to the teams I advise. Why? Because it’s too ‘perfect.’ It makes engineers feel like they’re playing a video game instead of solving hard problems. I’ve seen teams spend three hours a week just perfecting their ‘cycles’ and making sure their issue labels look pretty. It creates this false sense of speed. You feel fast because the UI is snappy, but your actual product is still a buggy mess. I’d honestly rather use a messy Trello board or a plain text file. Linear is the ‘Live, Laugh, Love’ sign of project management. It’s a distraction masquerading as efficiency.
It’s exhausting.
The 142-hour math
I decided to get scientific about this a couple of years ago. I tracked my time for all of 2022 using a simple spreadsheet—not some over-engineered SaaS tool—and found that I spent exactly 142 hours fixing bugs that were directly tied to ‘quick and dirty’ deployments from the previous year. That’s nearly four full work weeks. Imagine what I could have built in those 142 hours if I wasn’t busy cleaning up my own past mistakes. I know a guy who claims he saves time by skipping unit tests. He’s also the guy who gets paged at 2 AM every Sunday. No thanks.
- Speed is a byproduct of mastery, not a lack of guardrails.
- If you can’t deploy on a Friday afternoon, your system is broken.
- Technical debt is just a fancy word for ‘I’ll let my future self suffer.’
The part nobody talks about
I honestly think if you use the phrase ‘move fast and break things’ in a pitch deck in 2024, you’re either a grifter or you’ve been living under a rock since the Obama administration. Investors are smarter now. Or at least, they’re more tired. They’ve seen the ‘fast’ companies go up in flames because they didn’t have a single person on the team who cared about documentation or scalability.
I used to think being the ‘fastest’ coder in the room was a badge of honor. I was completely wrong. The best engineers I know are actually kind of slow. They spend a lot of time staring at the screen. They ask ‘why’ a lot. They write things down. They don’t break things because they actually understand how the things work. It’s not as sexy as the ‘hacker’ trope we see in movies, but it’s what actually builds companies that last more than eighteen months.
Maybe we’re all just scared. We’re scared that if we don’t ship something today, we’ll be forgotten tomorrow. But is being fast and wrong really better than being slightly slower and right? I don’t know the answer to that for every single case, but for me? I’m done breaking things.
Slow down. Write the test. Drink your coffee while it’s still hot. Your users will thank you.