I am Lino
February 26, 2026

The psychological cost of always being "up to date"

Posted on February 26, 2026  •  12 minutes  • 2450 words
Table of contents

There’s a very specific kind of tiredness that only people in tech truly understand. It’s not sleepiness, it’s not laziness, it’s not “I hate coding.” It’s that moment when you close your laptop at a reasonable hour, go make dinner… and five minutes later open your phone “just to check” LinkedIn or X. In that personal micro-hell , everyone seems to have launched a side project, contributed to open source, migrated to another framework, shoved AI into everything including their grocery list, and written a thread explaining how you can do it too “if you just get organized” .

Meanwhile, you had a normal day: you fixed an ugly bug, helped a teammate, put together a decent API design. None of that generates viral threads. So the little voice shows up: “maybe I didn’t do enough today.” It’s not rational, but it installs itself in your brain like a misplaced while(true).

If that sounds like you, the good news is you’re neither alone nor “weak.” The bad news is that you are, in fact, playing a game that — as burnout studies and productivity reports have been showing — is rigged: if you measure your worth against an aggregate of other people’s highlights, you always lose.

The feeling of always being behind (even when you’re doing fine)

In theory, staying current is part of being a good professional: knowing what’s new, what’s mature, what’s dying. In practice, the thing looks a lot like chasing a train that picks up speed every week .

Picture the scenario. You’ve spent years doing solid backend work: clean APIs, systems that don’t go down, the occasional on-call night saving production. Your team trusts you, the business comes to you when serious decisions need to be made, and nobody questions that you know your stuff. But you open whatever tech social network is trending and see a different movie entirely:

A post with 3,000 reactions about the new “definitive” framework that every serious company is already using (except yours, obviously). A thread about an AI tool that, in the author’s words, “will replace mediocre developers ,” conveniently shared by three HR people. A diagram of a miraculous stack that includes five things you didn’t even know existed, and that now seem essential .

The implicit message, through sheer repetition, boils down to this: if you’re not trying this already, you’re falling behind; if you’re not a full-stack-cloud-devops-data-ml-engineer, you’re incomplete; if you don’t have at least two side projects in Rust going on weekends, you’re wasting your potential.

Recent reports on developer experience and burnout put it in much less sarcastic terms: constant comparison, amplified by social media and misused metrics, generates a chronic sense of inadequacy even in highly competent people. The problem isn’t you — it’s the absurd benchmark you’re playing against: an average that doesn’t exist in reality, assembled from a thousand different profiles.

When learning stops being curiosity and becomes self-defense

One of the beautiful things about this job is that you almost never stop learning. One of the dangerous things is that, if you’re not careful, you stop learning because you’re curious and start doing it so you don’t feel lesser .

Maybe this pattern sounds familiar. You see a new course on advanced Kubernetes, bookmark it “for when you have time,” and on a Sunday afternoon, with zero desire, you start it because you’ve spent the whole week seeing posts about clusters, operators, and the death of VMs. Two weeks later, you drop it halfway through, because you’ve already mentally enrolled in another one on Rust. Then another on MLOps. Then something about Data Mesh. Everything rings a bell, nothing sticks.

Essays like The Measurement Problem in Software Engineering describe exactly this: when everything is measured and everything is compared — tickets closed, commits, courses completed, certifications, shared posts — learning stops being internal growth and becomes an external showcase . You’re no longer studying to understand; you’re studying so you can say you studied.

Reports on developer productivity and burnout from 2024 even talk about training burnout : people who never stop taking courses, workshops, and labs, yet are emotionally exhausted and haunted by the strange feeling that every new thing they learn only uncovers three more things they don’t know.

It’s the professional equivalent of eating when you’re not hungry because “it’s time”: you’ll end up stuffed, and you won’t even have enjoyed the meal.

The “up-to-date” engineer doesn’t exist (but the myth looks great in slide decks)

If you add up every expectation you see in your feed, the ideal profile that emerges is comical: a person who masters backend, frontend, cloud, data, security, AI, MLOps, distributed systems architecture, has three side projects, maintains several open source libraries, and is, of course, excited about all of it.

That person doesn’t exist.

What does exist, and what you see when you talk to genuinely strong engineers without microphones in front of them, is something very different. People who have chosen a few things to go deep on for real — backend and architecture, say, or data and ML, or security — and for everything else, they keep, at most, “a rough awareness ”: they know something exists, roughly what league it plays in, and that’s it.

People who’ve developed a decent approach to the famous “just-in-time learning”: when a project demands it, they dive in, read, experiment, and get up to speed; in the meantime, they don’t try to master everything at once . And people who, in public, tend to sound very confident, but in private drop lines like “I’m learning this right now just like you — I’m maybe a couple of chapters ahead, tops.”

Developer experience reports capture a painfully common paradox: developers in the top percentile of skill who feel “below average” because the average they’re comparing themselves to isn’t their team’s or their city’s — it’s the mental sum of the specializations of hundreds of different people. If you blend the Kubernetes expert from one company, the React expert from another, and the distributed systems architect from a third, and then try to be all three at once… the one who comes out bruised is you.

Changing the game: from “staying current” to “knowing how to choose”

Giving up the goal of “staying up to date with everything” isn’t a defeat — it’s switching sports. Several articles on tech careers suggest a shift that’s simple to state but hard to accept: moving from “I know everything” to “I know how to choose where to invest .”

In plain English: instead of demanding that you “know everything new,” you could aim for “staying reasonably current on what affects my work now and the direction I want my career to go.” That, suddenly, is something a real human can attempt.

In concrete terms, this usually means sitting down one day — calmly and, ideally, without LinkedIn open — and asking yourself: what two or three areas genuinely interest me and make sense for where I am? It could be backend and architecture, it could be data and ML, it could be security. Those are your core areas : where it actually makes sense to read articles, follow thought leaders, build side projects when you feel like it and aren’t running on empty.

Everything else moves to a different category: recognition, not mastery. You know a new frontend framework exists, but you don’t need to do the tutorial the day it drops. You’ve heard of some architecture pattern’s acronym, but you don’t need to memorize every variation until you land on a project where it’s actually relevant .

The other pillar, far less glamorous, is turning down the noise. Productivity reports are nearly unanimous on this: the sheer volume of inputs — newsletters, threads, repos, talks, videos, Discord channels, self-proclaimed essential courses — is itself a source of overload. Unsubscribing from a couple of newsletters that only give you anxiety, unfollowing a certain type of account that lives off triggering FOMO, limiting your tech doomscrolling to one time slot a day… will probably do more for your career than the next crash course you weren’t going to finish anyway.

Fundamentals, depth, and the unpopular superpower of learning “when it’s time”

If you take a calm look at the profiles of people who’ve lasted many years in this profession without burning out (and without losing their technical edge), you almost never see an endless collection of recent frameworks. What you usually see is something less flashy to show off but far more robust:

Solid fundamentals : understanding how a network works, what your operating system actually does when your process asks it for memory, why a query crawls or flies, what the impact of inter-region latency is, how to design an API you won’t want to rewrite every year, what concurrency really means beyond a buzzword. That stuff doesn’t change fast — or at least, it changes at a considerably more human pace than the JavaScript framework of the week.

Reasonable depth in a handful of key technologies: your main language, the stack you work with the most, the cloud you use day to day — not every cloud that exists. That’s where staying current actually makes sense: new versions, best practices, important mental-model shifts. Not so you can recite the changelog at every keynote, but because it makes your daily life easier .

And, above all, a trained ability to learn just in time. Not having taken every Kubernetes course in existence, but knowing how to get your hands dirty when you finally have a project that needs it: finding decent documentation, filtering noise, spinning up a small lab, asking for help when you’re stuck. It’s less impressive than having 15 badges, but it’s what makes the difference when things get serious .

You are not a side project (even if you treat yourself like one)

There’s a phrase that shows up again and again in burnout literature and that, applied to personal life, is dynamite: not everything has to be optimized . Not every minute, not every hobby, not every evening.

Applied to our world, it means accepting that there will be time you don’t monetize — not in skills, not on your résumé: couch evenings, coffees with no professional agenda, video games, walks, books that have nothing to do with architecture, hobbies that don’t turn into products. And that those moments aren’t a betrayal of your career — they’re the equivalent of running maintenance on your operating system before it crashes.

Serious articles on developer burnout highlight a pattern: people don’t break down just from having too much work, but from having no space where they don’t have to prove anything . If everything you do — work, projects, courses, social media — has a performance and validation component, your nervous system never downshifts. It’s like running production at 200% all the time and being surprised when something catches fire .

Remembering this isn’t easy when your feeds are full of people who turn every hobby into a monetizable thread. But it’s worth repeating to yourself: you’re not another side project that has to show returns every quarter. You are, with any luck, a system that should still be running in 20 years without needing a complete rewrite.

How do I know if, despite everything, I’m doing better than I think?

There are no DORA metrics for this, but some healthy indicators keep coming up in testimonials and studies. For instance: you have regular time for learning new things… and times when you consciously decide that this evening or this weekend isn’t for that, and you don’t feel guilty about it.

You catch yourself following a topic because it genuinely makes you curious — because you want to understand how the heck a particular distributed system works, or what goes on inside a compiler — and not just because “job postings are asking for it.” You can, with more or less clarity, articulate where you’d like to steer your profile over the next few years, even though you know the plan won’t survive first contact with reality intact.

And perhaps the most telling sign: you’re able to say “I don’t know that yet” without a part of your brain starting to scream “fraud, fraud, FRAUD” on loop. Burnout reports cite precisely that inability to admit gaps as a brutal source of pressure : if you feel that, to be legitimate, you have to know everything, any gap is experienced as an existential threat.

If none of these things ring true for you, the answer is rarely “one more course.” It usually involves renegotiating expectations — yours and, if necessary, those around you — and literally cutting off a couple of sources of noise.

Falling a bit behind… on purpose

Not trying the trendy framework doesn’t make you a fossil ; it makes you someone who has consciously decided that their attention is finite and prefers to spend it wisely. Skipping the latest AI toy doesn’t make you irrelevant; it lets you not show up exhausted when something actually comes along that fits your work or your interests.

The psychological cost of trying to always be “up to date” is paid by you — not by the person who’s selling one thing today and another tomorrow, nor by the company that now demands “experience in everything” in a job listing and will pivot to another technology in two years. Your career, if things go reasonably well, is a long game. Living every month as if you’re about to be tested on the entire tech universe’s stack is a pretty effective way to never finish the book .

Stay current, yes. But the way you’d update a production system you care about: thoughtfully, with maintenance windows, with possible rollbacks, and knowing that the goal isn’t to impress the dashboard — it’s to keep the service running — in this case, you — without catching fire, for many deployments to come.

Sources and references

Before you close this tab and open yet another newsletter you won’t finish, here are the readings that back these ideas.

Follow me

I write and share opinions about technology, software development and whatever crosses my mind.