Break It on Purpose: The Developers Who Sabotage Their Own Tools to Think Better

Somewhere in Portland, a senior software engineer named Marcus is coding on a ThinkPad from 2011. It's not because he can't afford something newer. It's because the lag forces him to think before he types.

"When the machine keeps up with every half-formed thought, you stop having complete thoughts," he says, barely looking up from a terminal running a stripped-down Linux distro. "I needed the machine to push back."

Marcus isn't alone. Quietly, in Slack servers and forum threads that don't show up in your algorithmic feed, a subculture of American developers is doing something that sounds almost offensive to the productivity-obsessed tech mainstream: they're making their own workflows worse. On purpose.

What 'Productive Friction' Actually Means

The phrase gets thrown around a lot in UX circles, usually to describe tiny speed bumps designed to stop users from doing something dumb — a confirmation dialog before you delete a file, that kind of thing. But the coders in this scene have taken the idea somewhere far more personal and far more radical.

For them, productive friction means removing the guardrails that modern development environments have spent decades installing. No autocomplete. No linters screaming at you in real time. No AI co-pilot finishing your sentences. No Stack Overflow tab open in the background. Just you, a text editor, and whatever you actually know.

Jamila, a freelance backend developer based in Austin, disabled GitHub Copilot eight months ago after noticing something that unsettled her. "I was shipping faster than ever and understanding less than ever," she says. "The suggestions were good. That was the problem. I stopped reaching for solutions myself because something else was always reaching first."

She's not romanticizing struggle for its own sake. She's describing a specific cognitive phenomenon — what some researchers call automation bias, the tendency to trust and defer to automated suggestions even when you'd know better on your own. When the tool is always right, you stop checking.

The Silicon Valley Gospel of Seamless

The dominant religion of the tech industry for the past two decades has been frictionlessness. Remove every obstacle. Flatten every learning curve. Make it so easy that anyone can do it without thinking. This gospel has produced genuinely amazing things — it's why your grandmother can video call you from her phone without reading a manual.

But the developers in this scene argue that the same philosophy, applied to the tools that build tools, has created a generation of engineers who are fast but brittle. Coders who can operate within established frameworks at incredible speed but freeze when asked to reason from first principles.

"We optimized for throughput and forgot about depth," says Derek, a systems programmer in Chicago who now writes code exclusively in Vim, with syntax highlighting turned off. "The industry got really good at producing people who can assemble things quickly. It got a lot worse at producing people who understand what the pieces actually do."

Derek's vim config is legendarily sparse. He shared it in a forum once and people thought he was joking.

The Practices: What This Actually Looks Like Day to Day

The friction farmers — a term some in the community have started using with a mix of irony and pride — don't all practice the same rituals. There's a spectrum.

On the milder end, you've got developers who simply disable autocomplete in their IDEs, or who enforce a "no search" rule for the first hour of working on a problem. The idea is to exhaust your own mental resources before outsourcing to the internet.

Further along, there are folks like Marcus on his aging ThinkPad, who deliberately introduce hardware constraints. Slow machines enforce patience. Limited RAM means you can't have forty browser tabs open while you code. You have to choose what gets your attention.

At the more committed end of the spectrum, there are developers who code offline for entire sprints — disconnecting not just from social media but from documentation sites, package repositories, everything. One engineer in Seattle described completing a two-week project using only local documentation and a handful of physical books. "It was humbling," she said. "I realized how much of what I thought I knew was actually just knowing where to look it up."

That distinction — knowing something versus knowing where to find it — is at the heart of this whole movement.

Is This Elitism in a Hoodie?

It's worth asking the uncomfortable question: is this just a bunch of already-skilled developers doing a performance of difficulty? A kind of tech asceticism that's only available to people who already have the luxury of slowing down?

Fairly, yes — to a point. You can't tell a junior developer at a startup, under deadline pressure, to turn off their linter as a spiritual exercise. The friction farmers largely acknowledge this. Most of them have years of experience. They're not suggesting this is a universal practice.

But they push back on the idea that it's purely self-indulgent. Jamila points out that the junior developers she mentors are entering the industry already dependent on AI completion tools, having learned to code alongside them. "They've never had to hold a full program in their head," she says. "That's not their fault. But it's a real skill gap, and nobody in the industry wants to talk about it because it's inconvenient."

What You Actually Lose When Everything Just Works

Here's the thing about a perfectly smooth road: you stop noticing the terrain.

The friction farmers are, at their core, arguing for a more honest relationship with technology — one where the tool doesn't pretend to be smarter than the person using it, and where the person doesn't let it be. They're pushing back against a development culture that has quietly redefined competence as the ability to orchestrate powerful tools, rather than the ability to think through hard problems.

That's a cultural argument as much as a technical one. And it's one the industry isn't particularly eager to have, because the tools that enable seamless productivity are also extremely profitable.

Marcus wraps up a session on his battered ThinkPad and closes the lid. He wrote maybe 40 lines of code in two hours. He knows exactly what every one of them does.

"Speed is a metric," he says. "Understanding is a different thing entirely. We've been measuring the wrong one."