Information Anxiety for Software Engineers (Part 1): FOMO, Impostor Feelings, and AI Productivity

Most software engineers have been through a familiar cycle: a new framework or model appears on social media, colleagues start discussing an unfamiliar open-source project, and anxiety sets in. You open a dozen browser tabs, star several repositories on GitHub, and save articles to your read-later queue. Finally, you shut your laptop feeling exhausted and further behind than before.

You spend considerable time tracking technology, but instead of feeling grounded, your backlog of things to learn only seems to grow.

This two-part series begins with the essence of this information anxiety, examining how AI and digital hoarding habits compound that pressure.

1. Anxiety Stems from the “Gap”: Thinking You Ought to Know More

“Information anxiety” did not originate with the internet. In his 1989 book Information Anxiety, American information architect Richard Saul Wurman defined it this way:

Information anxiety is produced by the ever-widening gap between what we understand and what we think we should understand. It is the black hole between data and knowledge.

The critical insight in this definition lies in “what we think we should understand.” Information in technology is inherently limitless. The real issue arises when we reflexively lump every emerging technology into the bucket of “things I ought to master as an engineer.” Once that boundary expands too far, anxiety grows in tandem, even as your actual competence steadily improves.

This differs from mere “information overload.” Overload means incoming data exceeds cognitive bandwidth—too many Slack notifications, back-to-back PR reviews, and endless specification documents. Overload can usually be relieved by cutting back on inputs. Anxiety, however, is a psychological strain. Even if you close every browser tab, the quiet voice insisting that “everyone else understands this while I’m falling behind” remains.

Internet commentator Clay Shirky captured this distinction sharply in his 2008 Web 2.0 Expo talk:

It’s Not Information Overload. It’s Filter Failure.

This observation is often misinterpreted as claiming overload does not exist. Shirky’s point was that in an environment of abundance, the core challenge is building an effective filter rather than attempting to absorb every signal.

For software engineers, not all updates carry equal weight. A critical security patch in a production dependency and a new web framework for an unused language belong to completely different priority tiers. Trying to relieve stress simply by “reading less” risks missing urgent vulnerabilities. Conversely, filtering solely by social media popularity hands your attention over to an algorithm.

Effective filtering requires anchoring back to your immediate context: How does this change relate to the systems I maintain or the problems I need to solve right now?

If there is no direct connection, it is background noise—not a commitment on your to-do list.

2. How the Engineering Environment Amplifies the Gap

Why does information anxiety seem especially acute among software engineers? The nature of day-to-day engineering work acts as a major catalyst.

Much of the information engineers receive comes marked as needing action: major version upgrades, vulnerability advisories, deprecation warnings. Over time, the brain develops a conditioned reflex to treat incoming technical news as an immediate task. When that reflex encounters social feeds full of trending tools and viral open-source repositories, the line between “necessary for work” and “trending on social media” blurs.

Measuring Yourself Against Someone Else’s Highlight Reel

Engineering competence cannot be captured by a single benchmark. One engineer excels at Linux kernel tuning, another specializes in distributed consensus, and a third crafts seamless front-end interfaces. Online, however, their achievements appear side by side on your feed, creating the illusion that a capable developer should master all of them simultaneously.

The comparison is fundamentally asymmetrical: you see someone else’s polished outcome—a clean open-source architecture, an articulate technical write-up, or a flawless production rollout. Meanwhile, you compare it against your own messy, day-to-day reality of trial, error, and debugging. You remember spending an entire afternoon fixing a trivial configuration bug, but you never see how many drafts the other person discarded before publishing that pristine architecture.

This asymmetry easily triggers impostor feelings: even after delivering real value, you attribute success to luck or finding the right answer online, dreading the day you get exposed. Confronted with an unfamiliar technology, you instantly treat lack of knowledge as proof of inadequacy.

While popular claims suggest that “70% of people suffer from impostor syndrome,” empirical research paints a much more nuanced picture. A 2020 systematic review by Bravata and colleagues found that prevalence estimates across studies fluctuated widely from 9% to 82%, depending entirely on the screening scale and diagnostic cutoffs used.

Impostor feelings and information anxiety share a common blind spot: a subjective sense of insufficiency cannot be cured simply by accumulating more accomplishments. When successes are written off as flukes and blind spots are treated as flaws, learning more only leaves you feeling more inadequate.

Fear of Missing Out and Compulsive Checking

Fear of Missing Out (FOMO) describes apprehension that others might be having rewarding experiences from which one is absent. Research by Przybylski and colleagues (2013) showed that FOMO correlates significantly with frequent social media checking.

In technical learning, this dynamic creates an energy-draining loop: refreshing social feeds and technical forums every hour provides a fleeting illusion of staying informed. Yet compulsive scanning only reveals that something exists; it does not build real understanding. Each refresh serves only to remind you how much you still don’t know, deepening the feeling of falling behind.

Compounding this is the pervasive industry narrative of the “learning treadmill”—the idea that one must run at full speed just to stay in place. Learning is subtly transformed from purposeful problem-solving into survival anxiety. But that treadmill is a cultural narrative, not an objective law of software engineering.

3. AI Changes How We Work, but You Don’t Have to Chase Every Model

The rise of generative AI has intensified the pressure to keep up. Beyond missing out on a framework, the deeper anxiety is existential: “If others code ten times faster with AI, will I become obsolete?”

Yet when tested against empirical research, the data tell a far more grounded story.

The Illusion of Speed: Feeling Faster vs. Actually Faster

The productivity benefits of AI depend heavily on task complexity and context, and experimental findings often conflict:

• Greenfield, isolated tasks: In an experiment by Peng and colleagues (2023), developers building an HTTP server from scratch with GitHub Copilot completed the task roughly 56% faster.
• Complex real-world issues: In an RCT by METR (2025) involving senior open-source maintainers working on real issues in their own repositories, developers using AI actually took 19% longer. (While the sample was small and tools continue to evolve—as noted in METR’s 2026 update—it highlights the friction of applying AI to complex existing codebases.)

Most telling was the perception gap METR documented: participants initially expected AI to speed them up by 24%, and upon finishing, still believed they were 20% faster, even though they had slowed down. Fast code generation provides a sense of momentum, but that feeling is not the same as faster end-to-end task completion.

Writing Code Faster Does Not Mean Delivering Better

Software development has never been a typing competition. Once code is generated, the real work begins: code review, automated testing, system integration, deployment, and ongoing maintenance.

Google’s DORA reports illustrate this tension. The 2024 DORA report found that increased AI adoption correlated with higher documentation quality, but also with decreases in delivery throughput and software stability. While throughput shifted positive in the 2025 report, the negative correlation with stability persisted.

Generating code faster provides little value if the downstream burden of verification and debugging escalates at the same rate.

Crucially, these productivity studies evaluate task efficiency and delivery performance—not unemployment rates. They neither prove that ignoring AI means instant obsolescence, nor guarantee that dismissing it carries no cost.

A pragmatic approach is to evaluate tools strictly against your own workflow: How much time does this tool save on my actual tasks? How much effort does it take to verify and debug its output? Knowing when to apply a tool—and when to put it aside—is far more valuable than showcasing a long list of models you have tried.

4. Saving Is Not Learning: The Collector’s Fallacy

When flooded with information, an engineer’s instinctive reaction is often to hoard: open dozens of tabs, star GitHub repos, save links to read-later apps, and subscribe to multiple technical newsletters.

Holding onto the material provides immediate reassurance: at least I haven’t lost it; I can always read it later.

Saving is harmless in itself; the danger lies in mistaking saving for progress.

In psychology, this behavior closely mirrors features of digital hoarding. Research indicates that the primary motive behind saving is “just-in-case” thinking. Clicking “save” delivers instant relief from FOMO, rewarding the brain with a false sense of completion.

Personal knowledge management communities call this the Collector’s Fallacy: mistaking storing data on a hard drive for acquiring knowledge in your head.

A growing reading list does not improve technical judgment. When a problem arises in production, you still need to understand principles, write code, and navigate edge cases yourself before knowledge becomes competence.

This brings us full circle to the opening loop: scanning feeds reveals more blind spots, while saving offers brief comfort. But without dedicated time for deliberate digestion and practice, the anxiety gap between what you know and what you think you should know never closes.

Information anxiety is a normal reaction, but it does not have to become an endless learning queue. Part 2 will explore what happens when you deliberately choose not to chase the latest hype, and which foundational concepts remain worth mastering yourself in the age of AI coding.