Dr. Cat Hicks on Why Developers Feel Anxious At Work

Modern technology organizations are failing the very people who build their future — developers, was a data-backed wake-up call by Dr. Cat Hicks, a psychologist researching software team, delivered at Craft Conference in Budapest.

In tech teams, developers often feel unseen and unprepared for rapid change. One engineer admitted, “So much of my work never sees the light of day. That’s hard.”  

Why Developers Feel Invisible and Anxious at Work

Data tells the same story: a recent survey found that 88–90% of engineering managers believe they make developers’ work visible to the company, yet only 24% of developers agree.  

At the same time, roughly 43–45% of developers report anxiety that AI will render their skills obsolete. These gaps fuel real distress on teams: code-review anxiety, for example, can spike avoidance and withdrawal behaviors by around 40%, delaying work and eroding trust. Many devs feel trapped in a career treadmill – unsure if they’ll be noticed or needed – and the resulting stress leaks into every sprint and standup.

Burnout and Code Review Anxiety

Hicks’s research shows this isn’t just burnout – it’s a systemic problem of perspective and culture. Managers who see devs as isolated “cogs” create pressure to crank out quick wins. Devs respond with survival tactics – racing through tasks or hiding mistakes – but little of it builds lasting value.

The cost is high: projects stall, innovation sputters, and talented people become disillusioned. “When people avoid or procrastinate code reviews,” notes one psychologist, “it leads to delays in software. It also results in less cohesive teams and lower-trust teams”. In other words, anxiety and invisibility on the team translate directly into lost productivity and morale.

The Brains-in-Jars Fallacy

Hicks calls this destructive mindset the “brains in jars” model. Per that metaphor, developers are treated as fungible problem-solvers – machines whose output is all that matters. Teams push for metrics and milestones as if everyone works in isolation, ignoring the messy realities of people, collaboration, and learning.

But developers aren’t brains in jars. They bring history, creativity, and social needs to their work. When organizations adopt the brains-in-jars view, they underestimate how much developers learn from each other and how context shapes reasonable solutions. They assume any developer can jump in and instantly produce perfect code, which leads to punishing mistakes and ignoring the need to nurture skills.

What It Means to Treat Developers as Interchangeable

This flawed model drives what Hicks dubs “riddle productivity.” Teams obsessed with answering today’s riddle – shipping this feature or hitting this sprint goal – chase short-term wins. They fail to tend to the long-term ecosystem. The result?

“The more a team fixates on demonstrating short-term performance,” Hicks warns, “the less able they are to protect the foundations of long-term performance .” Engineers report crunching for deadlines and then fixing the same bugs again later.

Meanwhile, ample research shows that this pressure damages code quality and creativity. One developer’s lament—that their careful design never makes it to production—reflects a system that rewards output over insight.

Most developers have deep, sophisticated learning strategies, and their organizations… don’t care.

When Performance is Measured by Tickets Closed

Hicks paints the human side of this fallacy. Developers describe deep intuition and learning tactics they use daily – constant refactoring, personal projects, knowledge-sharing – but organizations often refuse to recognize or support those efforts.

Instead, “performance” is measured by ticket closures and story points. When people are measured this way, they stop experimenting or asking questions. They hide what they don’t know lest it count against them. Social learning—the conversations, pair programming, mentorship—is seen as an indulgence rather than the norm.

In a brains-in-jars culture, “learning on the job” becomes a risky gamble, and many devs stop asking for help or even stop proposing improvements. Innovations get shelved, and the organization’s collective knowledge becomes brittle.

Riddle Productivity vs. Cumulative Growth

The brains-in-jars mindset feeds a contest culture, like every sprint is a competition. People hoard knowledge to get ahead. They fixate on being the fastest coder or writing spotless code on the first try. Short-term metrics climb, but teams lose resilience. “Contest cultures” reward only immediate victories, not collaboration, says Hicks, and that creates a cycle of stress.

Developers become anxious that any mistake will be their downfall. Meanwhile, team members compete quietly over code ownership and recognition, fragmenting trust. Hicks argues there is a better alternative: a thriving, cumulative culture. In a flourishing culture, teams view each challenge as a shared puzzle (“a riddle we solve together”), not a duel.

Embracing Learning over Speed

The goal shifts from “be the best this sprint” to “learn and improve for next week.” Instead of hiding mistakes, people share them openly so everyone can learn. Instead of valuing only quick fixes, the team invests in documentation, mentorship, and tooling that pays off over time.

Growth is seen as a long game. As one leader summarized Hicks’s insight: teams should “amplify under amplified voices” and break out of fixed mindsets. In practice, this means encouraging side projects, pairing juniors with seniors, and celebrating learning, even if it looks like slower delivery in the short term.

The more a team fixates on demonstrating short-term performance, the less able they are to protect the foundations of long-term performance.

Developers Are Like Seeds, They Need Soil to Flourish

To move beyond brains-in-jars and contest culture, Hicks offers the “Seed and Soil” metaphor as a solution (borrowed from social science). Developers are like seeds: they have enormous growth potential but need the right soil to thrive. No matter how talented a developer (seed) is, growth is stunted if the organizational environment (soil) is toxic or unforgiving.

Even modest developers flourish in rich soil. Walton and Yeager’s psychological-affordance research underscores this: interventions only stick when the context supports them. A learning workshop or new tool will wilt on dry ground; teams must first nurture the soil of culture.

Hicks defines three “psychological affordances” – essentially the nutrients in the soil – that are essential for developer thriving:

• Learning Culture: Teams must make learning itself a core goal. This means praising questions, tolerating failure as part of the process, and dedicating time to training or experimentation. In an authentic learning culture, mistakes are dissected constructively, and knowledge-sharing (like post-mortems or tech talks) is routine. Devs feel safe exploring new techniques because the team values the growth outcome over blaming the gap.

• Social Acceptance (Belonging): Every team member must feel valued as a whole person, not just a code machine. This includes respecting diverse backgrounds and perspectives, celebrating small wins, and ensuring everyone’s voice is heard in planning and reviews. Belonging means leaders and peers signal that they want your input and that failures won’t ostracize you. Hicks’s data show that when developers feel this acceptance, they write better code and take more ownership.

• Self-Efficacy: Developers should believe in their ability to learn and contribute, even when tackling complex problems. This is built by giving people autonomy, appropriately challenging tasks, and feedback emphasizing progress. When developers build confidence through small wins, they’re less likely to freeze in the face of unfamiliar tools or AI uncertainty. Organizations can boost self-efficacy by pairing novices with mentors and framing AI as a tool that augments skills, not a threat.

These conditions – learning culture, belonging, and self-efficacy – form the fertile ground that lets developers “live up to their potential,” as one researcher puts it. But, seeds need soil, light, and water: in organizations, those correspond to support for learning, trust among colleagues, and belief in personal agency.

Invest in the Developer Environment, Not Just the Stack

On a human level, managers should listen to developers’ frustrations. A survey response like, “Most developers have deep, sophisticated learning strategies, and their organizations… don’t care,” is a wake-up call. The action starts with simple steps: ask developers what they want to learn next quarter; publicly praise someone for pairing or reviewing another’s code; invest in a learning stipend or a retreat. These are small seeds that, with enough care, can grow into thriving ecosystems.

Small Seeds, Big Change: How to Begin Today

In doing so, organizations take a science-backed approach. “We must study the world as it comes to us,” Walton and Yeager remind us, meaning we must address root causes, not just symptoms. By tending the soil (affordances), we enable seeds (developers) to flourish. It’s a shift from “every developer for themselves” to “all developers together.”

The stakes are high: well-supported developers stay curious, write better code, and innovate more. And the business wins too – resilient teams that avoid churn and build maintainable products. As Hicks puts it, teams should no longer “chisel (roadmaps) out of rock while muttering about how ‘selectivity accelerates deliberation.'”

Instead, let’s turn on the lights, share the roadmap, and plant a garden of knowledge that pays off for years to come.

Innovation Needs Psychology

Dr. Cat Hicks is currently working on a book with CRC Press that will be released in 2026. The book aims to provide a human-centered roadmap for building healthier, more innovative technology teams.

I really believe, as a scientist in tech, that how we support innovation is with good psychology.

That’s what makes the lasting technology that we all want for the world.