I am Lino
February 23, 2026

A "professional hygiene" guide for developers

Posted on February 23, 2026  •  10 minutes  • 1951 words
Table of contents

There comes a moment, in almost every tech career, when you catch yourself thinking: “maybe the problem is me.”

Not because you don’t enjoy coding, but because you feel like you’re always two frameworks behind, three blog posts short, and five certifications trailing whatever your LinkedIn feed suggests you should be. You open Twitter on a Sunday morning and it looks like everyone has contributed to open source, built a side project in Rust, and read the latest architecture book… while you were, I don’t know, living .

That feeling has a name: impostor syndrome , and it’s far more common in this industry than anyone admits out loud.

If you’ve ever felt guilty for not “using the evening to learn something,” this guide is for you. It’s not about productivity, or “wake up at 5 AM.” It’s about something far less heroic and quite a bit more useful: how not to burn yourself out along the way .

This isn’t a hackathon: it’s a marathon

The industry loves to sell the idea that if you’re not studying three hours a day, you’re falling behind. Research on developer burnout reminds us that the combo of “curious, perfectionist, and in an industry that changes fast” is exactly the recipe for fading out over time.

The ironic part is that people don’t burn out because they’re “not good enough.” They burn out because they’ve been running at 110% for years, as if life were an endless hackathon: nights spent on training, weekends on side projects, always with the feeling that whatever they do is “not enough.”

Eventually, it’s not just your productivity that drops; something harder to recover takes a hit: your desire to keep doing this at all .

If you think of your career as something that spans 25–30 years, the whole approach changes. Nobody runs a marathon at a 100-meter sprint pace… voluntarily. And yet, in tech, we celebrate exactly that: months of “hero mode” until someone vanishes from the map “for personal reasons.”

Professional hygiene starts right there: accepting that the goal isn’t to be the most brilliant person this quarter, but to still be here in 10–15 years without hating your keyboard.

Learning without burning out: less FOMO, more strategy

Tech FOMO is real: every day brings a new library, a “definitive” framework, and two AI tools that “change the game.” If your goal is “staying up to date with everything,” you’ve lost before you started .

It’s far more sensible to reframe it as: “I want to stay current on what impacts my work now and the direction I want my career to go.” That usually means picking one or two core areas where you’ll actually go deep (backend and architecture, data and ML, cloud security, whatever), and accepting that for everything else, you’ll only have context: knowing it exists, why it matters, and not much more.

Research on burnout also recommends something that goes against the “use every spare moment” myth: small, regular, focused blocks. A couple of well-chosen hours a week to learn one topic over several weeks (observability, infrastructure as code, basic security) will take you much further than nibbling at a different course every night.

And then there’s the hardest part to accept: you also need to set aside time for not learning. Days where you just work, go for a walk, or lie on the couch enjoying the sacred art of doing absolutely nothing.

If you feel guilty every time you don’t fill an evening with “training,” you don’t need a new course; you need to turn down the noise .

Signs that you’re overdoing it will show up quickly: you start courses you never finish because you’re already eyeing the next one, you feel bad for closing your laptop at a reasonable hour, coding starts to feel dangerously close to sitting for one exam after another.

At that point, the best possible upgrade to your technical arsenal is to unfollow half a dozen accounts whose only contribution to your life is FOMO.

Certifications: neither miracle prayer cards nor a pyramid scheme

Few things in tech polarize as much as certifications. There are those who worship them as if they were sacred scrolls, and those who dismiss them as if passing an exam were incompatible with actually knowing something .

The truth, as almost always, lies somewhere in the middle. A solid cloud certification can be useful if you’re switching terrain (from on-prem to cloud, from generalist development to security, etc.): it gives you a syllabus structure, forces you to fill in gaps, and in some markets, opens doors or bumps your salary. It’s also a digestible signal for recruiters and hiring managers who don’t have time to dissect every project on your résumé.

What a certification is not: a guarantee that you design things well, a substitute for real experience, or a universal requirement that every serious company should demand. There are very good places where, literally, nobody cares how many badges you carry; they care about what decisions you make when the system breaks .

The line is crossed when your résumé starts looking like a sticker album and yet you struggle to explain a couple of concrete projects where you actually applied any of it. Or when you’re chaining exams because “LinkedIn expects it,” but nothing is actually changing in the work you do or the work you want to do.

A healthy relationship usually looks like this: I pursue a certification when at least two of these three things align: it moves me closer to the kind of role I want, it complements something I’m already doing day to day, or it fills clear foundational gaps that genuinely bother me. And between one cert and the next, I give myself time for the knowledge to travel from my head to my hands .

Specializing without chaining yourself

On one end is the ideal of the “full-stack ninja” who juggles ten different stacks. On the other, the person who only touches “this one COBOL system in a closet.” Professional hygiene usually lives somewhere in between: being able to navigate the map, but having a couple of zones where you actually know what you’re doing.

You can think of that map in broad regions: frontend/UX, backend and distributed systems, DevOps/SRE and infrastructure, data/ML, security, mobile, embedded. All of them can sustain long, decent careers. The key question isn’t “what pays the most,” but “what kind of problems do I find myself thinking about even when no one’s asking me to”: interfaces, data models, performance, automation, security, analysis …

Three filters tend to help:

Specializing in something for a while doesn’t lock you in for life. In fact, most profiles you admire at the staff-level or above look more like a “T”: a horizontal bar of solid fundamentals (CS, networking, testing, HTTP, SQL…) and a vertical leg where they can say “this is where I actually have judgment .”

Day-to-day hygiene habits (the unglamorous but decisive part)

Then there’s the least glamorous and most decisive bit: what your average week actually looks like.

The literature on developer burnout keeps surfacing the same symptoms: chronically long work days, requirements that grow unchecked as the sprint goes on, unplanned work eating everything else, and a culture where “everything is urgent” and “saying no” is frowned upon .

Setting boundaries here isn’t selfishness — it’s preventive maintenance. Reasonable hours as the norm, not as a reward. Protected time blocks for deep work, with no meetings. And the most underrated sentence in modern engineering: “this doesn’t fit.” If your organization can’t tolerate any kind of healthy boundary, that’s also data — not about you, but about how long your health will last there .

Taking care of your environment isn’t just about having a big monitor, either. It’s about not wasting half of every morning on endless builds, nightmarish pipelines, or permissions that nobody knows who grants. Every minute of accumulated friction is energy that doesn’t go toward learning, or designing, or solving interesting problems. Helping improve DevEx — tooling, documentation, automation — isn’t “extra” work; it’s digging a little bit of fire escape for yourself and everyone else.

And finally, there’s the thing almost nobody talks about at tech conferences: network and support. The people who last decades usually aren’t the ones who know the most about Kubernetes — they’re the ones who have someone to vent to without posturing, someone to bounce decisions off of, someone they can tell “I don’t know, explain it to me” without fear of looking bad. The lone wolf myth romanticizes exactly the opposite of what you need to not burn out .

When to pull the emergency brake

You don’t need to wait for a head-on collision to realize something’s wrong. There are early warning signs that keep showing up in burnout stories: waking up every day with a knot in your stomach thinking about work, not remembering the last time coding felt fun, daydreaming about “getting out of here” but never going past the fantasy, chaining job changes, framework switches, or certifications as your only improvement strategy .

When you get to that point, the answer is almost never “learn something else.” It’s usually about stopping and renegotiating the whole system: how many hours, what kind of tasks, what expectations (yours and others’), who you work with, and what culture you’re willing to tolerate .

Professional hygiene, at that stage, looks a lot more like refactoring your life than installing a new library: removing toxic dependencies, isolating responsibilities, simplifying paths, and better documenting your own limits.

In the end, all of this is about something very unspectacular: building a way of working and learning that can hold up for years without breaking down. It’s not that different from designing a decent architecture: you can build something impressive at a hackathon, but if nobody can maintain it in five years, it wasn’t such a great idea.

Choosing what to go deep on, when to study, which certifications to pursue, and what boundaries to set aren’t “personal” decisions separate from the technical stuff. They’re technical decisions, with a direct impact on your ability to keep building systems, teams, and a career without turning yourself into the next legacy system that everyone wants to migrate.

Remember: no post-mortem ever starts with “the problem was that we rested too much.”

Sources and references

Because prescribing professional hygiene without citing sources would be like telling you “just trust me, bro.”

Follow me

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