In a few years, everything will be vibe-coded. That’s the prophecy.
Yeah, sure.
For now, we just need to ride it out. It’s the age of slapping AI labels on everything, inflated job titles packed with AI-flavoured bullshit, and vibe-coding sold as the next revolution.
Managers are getting starry-eyed at the thought they no longer need those weirdos with beards and shorts, sipping coffee, avoiding eye contact, and smelling a bit odd.
Only those of us old enough to have lived through the pre-DevOps world can truly appreciate just how revolutionary the idea really was. I remember those long, dreaded release planning meetings before a Big Bang production deployment. People from alien departments—who hadn’t spoken to each other all year—would suddenly be packed into a room to plan what sounded like a bank heist:
“You come in at midnight and shut down system X. At 1:15am John will install system Y. At 2am Jane will update the config and deploy the hotfix. At 3am Tom will bring system X back online…”
People often ask how to apply the engineering principles I talk about.
My answer — “it depends” — isn’t a cop-out. It’s a recognition that teams and contexts vary. But across high-performing teams I’ve led, some patterns consistently work (yes, in the real world; yes, in large orgs; yes, in regulated industries).
Here’s what that looks like:
Not just engineers. A cross-functional group: engineering, UX, product, QA, domain experts — collaborating daily. We need some process, but the real value comes from interactions. Colocation is optional. Real-time collaboration is not. The best teams I’ve worked with mobbed for 4–6 hours a day. If not that, then rotating pairs. If not rotating pairs, then just pairs. Solo work? Only for trivial, isolated tasks.
The Forest and Desert metaphor is a compelling way to highlight the communication gap between software teams in different working conditions, but it risks slipping into absolutism and evangelism.
I don’t like it.
It sets up a dichotomy where the Forest is seen as the enlightened, flourishing state of software development (agile, tested, customer-focused) while the Desert is a place of dysfunction, scarcity, and struggle. This framing is seductive, but ultimately incomplete and potentially harmful.
I made a huge mistake early in my career. I thought I was going to get fired. My manager just said, ‘Just learn from it.’
I saw this quote from a junior engineer reflecting on their early experience, and while it sounds enlightened and kind on the surface, it’s actually not the right stance.
A better response would have been: “Let’s all learn from this. How do we fix the environment so that an engineer—especially someone new—was in a position to make that mistake in the first place?”
“Adding manpower to a late software project makes it later.” — Fred Brooks, “The Mythical Man-Month”, 1975.
I think we should stop calling these kinds of observations “laws.” It feels like we’re borrowing the authority of science too freely. Brooks’s Law isn’t a natural law. It’s an observation about what happens when teams are poorly structured and managed under pressure.
That said, the insight still matters. Adding people to a late project often makes it later, especially in waterfall-managed environments. But a lot has changed in 50 years.
