Forem: NorthernDev

The Emotional Terror of Closing a Browser Tab

NorthernDev — Mon, 13 Apr 2026 07:49:30 +0000

My laptop sounds like it is preparing for a low-orbit launch. The fan is screaming. The metal chassis is hot enough to burn my palms.

And the reason is not a complex data simulation, a massive Docker build, or a rogue machine learning model.

The reason is that I currently have 147 browser tabs open, and I am emotionally incapable of closing a single one of them.

Look at your browser right now. Look at the top bar. If the icons have shrunk so much that they are just a solid, unreadable line of pixelated colors, you know exactly the kind of psychological trap I am talking about. We need to talk about this digital hoarding, because it is entirely out of control.

The Insurance Policy (aka The Fixed Bug)
There is a Stack Overflow thread sitting in my third window. It is about a minor routing bug I fixed last Tuesday. The code is committed. The pull request is merged. The feature is literally running in production.

But I cannot close the tab. What if the bug comes back? What if the server somehow forgets the solution and I have to find the exact answer again? Closing that tab feels like throwing away a compass in the middle of a dark forest. I am keeping it open as a pathetic insurance policy against my own future incompetence.

The Aspirational Lie
Then we have the aspirational tabs. You know exactly the ones I mean. A massive, ten-thousand-word article on the memory management architecture of Rust. A tutorial on a complex state machine concept. You opened them three weeks ago because you wanted to be the kind of developer who reads deep technical literature over a quiet morning coffee.

You are never going to read them. You are going to stare blankly at your screen while your pipeline fails for the fourth time. But keeping those tabs open is a performance. It is a lie we tell ourselves to feel intellectually superior. Closing them means admitting defeat. It means looking in the mirror and accepting that you are just a regular person trying to survive the sprint, not a software architect visionary.

The 64GB Ram Lie
We buy machines with 64 gigabytes of RAM. We tell our managers we need the memory to run heavy local environments and databases. That is a complete fabrication.

We need 64 gigabytes of RAM to sustain our psychological inability to let go of a GitHub issue we clicked on by mistake last month. We are slowly destroying our expensive hardware to feed our emotional insecurities.

The Physical Panic of the Accidental Click
The absolute worst part is the physical panic of the accidental click. You aim for one specific tab, your hand twitches, and you hit the little cross on the entire window. A cold sweat breaks out immediately. Your heart rate spikes.

You frantically smash the keyboard shortcut to reopen closed windows, holding your breath until all forty tabs slowly resurrect from the dead. You did not even know what half of those tabs were. You could not name three of them if your life depended on it. You just desperately needed the comfort of the clutter.

Closing a tab is an act of finality. It means a task is truly done, an idea is abandoned, or a problem is solved. And in an industry where nothing ever feels completely finished, where the code is always evolving and breaking, holding onto those tabs is our pathetic way of keeping control. They are a museum of out-lived anxiety and unfinished thoughts.

I am not going to tell you to clear your workspace. I am not going to write a motivational guide on digital minimalism, because I am clearly in no position to give advice. I am just going to ask you to do one thing.

Find one tab. Just one. Maybe an API documentation page for a version of a library you stopped using two years ago. Look at it. Thank it for its service. And close it.

Your laptop fan might just quiet down for half a second.

Trading My Body for Logic: The Physical Decay We Ignore

NorthernDev — Wed, 01 Apr 2026 05:45:19 +0000

It burns behind my eyelids. Not the normal kind of tired, but a sharp, constant ache. It feels like someone rubbed fine gravel into my eyes while I slept, if I can even call those three hours of restless tossing actual sleep.

I am sitting in a dark room. It is three in the morning, and the only thing illuminating my pale, shaking hands is the cold glow of the monitor. I just solved a bug that has been torturing the team for a week. I should feel a rush. I should feel like a god.

But all I feel is a dull, pounding weight in my chest. It is not a heart attack, I know that now. It is just the physical manifestation of pure, unadulterated stress that has moved into my ribcage and refuses to pay rent.

I am writing this because I have to. Because we need to stop lying to ourselves. We talk a lot about burnout and mental breakdowns in this industry. But we almost never talk about how we systematically destroy our own bodies in the pursuit of the perfect algorithm.

The Myth of the Immortal Brain
When I first started coding, I felt invincible. I truly believed I was pure intellect, a machine that only needed coffee and silence to perform. My body was just an inconvenient vessel for my brain. A biological necessity that I could starve, ignore, and push aside however I pleased.

I bragged about how little I slept. I took pride in sitting completely still for twelve hours straight. I treated my body like an enemy, something that just got in the way with its annoying demands for food, bathroom breaks, and movement.

We live in a culture that glorifies the crunch. Sleeping under the desk, working through the weekend, and completely neglecting physical health are seen as badges of honor and true passion. It is a dangerous lie, and I bought it completely.

But my body kept the score. It absorbed every missed hour of sleep, every caffeine-fueled night, every hour of complete immobility. It started sending small, subtle warning signs. An eyelid twitching. Dull headaches. A stiff lower back.

I ignored them. I popped a painkiller and kept typing. I honestly thought I could outsmart biology with sheer willpower.

When the Body Stops Negotiating
Eventually, my body got tired of negotiating. It stopped sending subtle warnings and went straight to full-scale alarms. That was the moment I realized I was not an immortal machine. I was a human being made of flesh and bone, and I was breaking apart.

It started when I woke up one morning and could not move my right arm. A blinding pain shot through my neck and spine at the slightest movement. I panicked, thinking I was having a stroke. It turned out to be an extreme muscle spasm, the direct result of weeks of constant tension and sitting in the exact same twisted posture.

Then came the insomnia. I literally could not shut my brain down. I lay awake for hours, writing code in the dark behind my eyelids. I woke up exhausted, irritable, and completely drained. I started making stupid mistakes. I started forgetting things. I felt like a stranger trapped inside my own failing body.

And that heavy weight in the chest became my constant companion. I started getting panic attacks on the subway. I isolated myself. All of this suffering, all of this physical decay, for a piece of software that will most likely be completely rewritten from scratch in three years anyway.

The Absurd Trade
It is a completely absurd trade. We sell our physical and mental health to build things that are entirely ephemeral. We wreck our spines and our eyes to optimize a machine that steals people's attention or sells digital garbage. We think we are so smart, that we have these untouchable super brains, but we are just slaves to a culture that demands constant, unnatural output.

I am putting this out there as a warning, and as a public apology to my own body. I have finally started listening. I have started taking care of myself. It is a slow and difficult process, but I have finally accepted the hardest truth of all: my body is my most important tool.

Without it, there is no logic. Without it, there is no code.

Close the laptop. Stand up. Breathe.

The Illusion of the Human Touch

NorthernDev — Mon, 23 Mar 2026 11:10:22 +0000

We are currently obsessed with playing the AI police. Everywhere you look online, people are pointing fingers at articles and posts, confidently claiming they can spot the "AI rhythm" or the exact words a machine uses.

But here is the harsh reality: the AI detector is dead. And I am not just talking about software like Turnitin or GPT Zero that constantly fail and falsely accuse students. I am talking about our own internal human detectors.

There is a fascinating and completely hypocritical phenomenon happening right now. When a real human writes something long, ambitious, and perfectly structured, people immediately call it out as AI. They point to the flawless grammar or the paragraph structure as "proof."

But when an AI actually generates a text that resonates with people emotionally, those same people will defend its "authentic voice" and praise the "human touch."

We see the machine where it doesn't exist, and we miss it completely when it is right in front of us. We are all just guessing, and most of the time, we are wrong.

The truth is, the line between human and machine writing is not blurry anymore. It is gone.

We should use the AI that is available for help. It is a tool. Nobody demands a percentage breakdown of how much a politician actually wrote of their own speech, or how much a heavy-handed editor rewrote a bestselling book. If the tool is named Claude instead of Karen, it shouldn't suddenly be considered cheating.

The question we need to ask is no longer "Who wrote this?"
The only questions that actually matter are: Is this true? Is it well-thought-out? Is it worth reading?

If you are creating content, writing code, or doing work right now, the method doesn't matter. What matters is that you own the outcome. Make sure you actually understand it, and make sure you can stand behind whatever you put your name on.

I Think a Lot of Developers Are Quietly Grieving the Old Internet

NorthernDev — Mon, 16 Mar 2026 06:35:16 +0000

I think a lot of developers are carrying a kind of grief right now, but rarely naming it.

Not burnout exactly.
Not simple nostalgia either.
Something quieter.

A feeling that the internet used to feel more human.
Not better in every way. Not cleaner. Definitely not smoother. But more alive.

The old internet was messy. Half-broken. Full of ugly forums, strange little blogs, abandoned tutorials, and personal sites that looked like they had been built at 2 a.m. by someone running on caffeine and obsession.

But that was part of the magic.
You could feel the people in it.
You could feel that someone made this because they cared about something. Not because a content calendar told them to. Not because an algorithm rewarded it. Not because a brand needed a voice.
The internet felt less polished, but more real.
Now it often feels like the opposite.
Cleaner. Faster. Smarter. More optimized.
And somehow flatter.

A lot of what we see now is technically impressive, but emotionally empty.
Everything is content.
Everything is packaged.
Everything is trying to perform usefulness.
And I think a lot of developers feel that loss more than most people, because many of us were shaped by the old web.

We learned from weird blog posts.
We found answers in obscure forum threads.
We followed people who were not trying to become creators. They were just sharing what they knew.
That mattered.
It made the internet feel like a place where people left pieces of themselves behind.

Now a lot of it feels more like output.
Not expression. Output.
And yes, AI has made this feeling stronger.
Not because AI is automatically bad. But because it speeds up something that was already happening:
more volume
more sameness
more polished emptiness
More things that look finished without really feeling alive.
I think that is what a lot of developers are grieving.

Not just old websites.
Not just forums.
Not just blogs.
We are grieving an internet that felt more like discovery than consumption.

An internet with more rough edges. More weirdness. More small corners. More signs that an actual person had been there.
And maybe the hardest part is that many of us are helping build the thing we miss.
We optimize our writing.
We polish our sites.
We think about hooks, reach, growth, engagement.
I do it too.

That is what makes this hard to talk about honestly.
Because it is not just that the internet changed around us.
We changed with it.
We became more polished. More strategic. More legible.
And maybe a little less real in public.
I do not think most developers miss bad design or slower pages.
I think we miss evidence of human life.
And the more the internet becomes polished, generated, and optimized, the more precious that starts to feel.

I miss that.

Not Everyone Gets to Be a Beginner in Tech

NorthernDev — Sun, 08 Mar 2026 09:02:53 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

Tech loves to call itself meritocratic.

We like to believe the best ideas win. The hardest workers rise. The most curious people find their place.
I want that to be true.
But the longer I spend around this industry, the harder it is to ignore something uncomfortable:
Not everyone gets to be a beginner in the same way.
Some people are allowed to learn in public.

They can ask awkward questions. Build messy things. Say "I do not know yet" and still be seen as capable. Their mistakes are treated like part of the process. Their rough edges are seen as potential.
Other people do the exact same thing and get judged immediately.
Their mistakes are not seen as growth. They are seen as proof.
Proof that they do not belong. Proof that they are not technical enough. Proof that they are somehow behind in a race that others were allowed to run while still learning.

That difference is quiet, but it changes everything.
It changes who speaks up.
Who posts.
Who asks questions.
Who applies.
Who stays.
A lot of people in tech are not just trying to get better at coding.
They are also trying to survive the feeling that every mistake costs extra.
That kind of pressure does something to you.

It makes you smaller.
It makes you overthink simple questions.
It makes you rewrite messages three times before pressing send.
It makes you feel like you have to arrive polished, because being unfinished does not feel safe.

And that is the part I do not think we talk about enough.
We talk a lot about access in tech. Courses, tools, AI, open source, tutorials.
But access is only the first step.
Feeling allowed to stay is something else.
Because what keeps people in this industry is not just ambition.
Sometimes it is one patient reply.

One kind mentor.
One room that does not make them feel stupid for being early.
One moment where they are treated like a person with potential instead of a problem to evaluate.
I think that is part of what gender equity in tech really asks from us.

Not just to open the door.
But to change what happens after someone walks through it.
Who gets patience?
Who gets generosity?
Who gets to be unfinished without being quietly dismissed?
Some people get to grow in public.

Others learn to hide until they are good enough to be safe.
And I think tech loses a lot of brilliant people in that silence.
Not because they lacked talent.
But because the cost of being a beginner was made too high

The End of Tab Anxiety: Building a Destructive Read-It-Later App

NorthernDev — Mon, 02 Mar 2026 13:09:15 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini
I built Sigilla, a privacy-first, read-it-later application specifically designed to cure "digital hoarding" for Personal Knowledge Management (PKM) users.

Most developers and tech enthusiasts suffer from the Collector's Fallacy. We save hundreds of articles in tools like Pocket or browser bookmarks, creating a graveyard of unread links just to feel productive in the moment.

Sigilla solves this by introducing forced auto-decay. If you save a link and do not read it within 7 days, it is archived. It forces a hard decision: either prioritize the information right now, or let it go. For the articles you actually read, Sigilla features built-in Spaced Repetition (SM-2) to help you retain the knowledge, and provides clean Markdown exports directly to systems like Obsidian. It also handles massive Pocket and Instapaper imports entirely client-side, ensuring no server ever touches your data.

Google Gemini played a massive role as my lead architect and co-pilot. I used Gemini to rapidly prototype the React frontend, structure the backend logic, and write the complex client-side parsing needed for the imports. It allowed me to focus entirely on the core philosophy and user experience of the app, rather than getting bogged down in boilerplate and syntax.

Demo
The web app is live and fully functional. You can try the methodology yourself here:

Sigilla | Retrieval-First Reading Workflow

Save articles, highlight what matters, and find it again when you need it. Portable exports for Obsidian, Notion, and more.

sigilla.net

(Note: The companion Chrome extension is currently sitting in the Google Web Store review queue).

What I Learned
The biggest lesson was a personal one: letting go of my developer ego.

I used to be highly skeptical of AI coding assistants and have been vocal about it in the past. However, building Sigilla completely shifted my perspective. I realized that we should use the AI that is available for help. It is not cheating; it is simply the next natural layer of abstraction.

Working extensively with Gemini taught me how to shift from being a traditional "coder" to becoming an "editor" and a technical director. Your job is no longer to memorize the exact syntax for an obscure array method; your job is to deeply understand the user's actual problem and guide the AI to build a robust solution for it.

Technically, I learned a great deal about client-side data processing. Forcing the app to handle heavy imports without a backend server required strict state management, and iterating on those solutions alongside an AI sped up my learning curve immensely.

Google Gemini Feedback
The Good:
The speed of iteration is unmatched. Gemini is fantastic at taking a high-level architectural concept and churning out the complex regex and component structures needed to make it work. It acts as an incredible sounding board when you are stuck on a logic problem, instantly offering two or three different approaches to evaluate.

The Friction:
The main challenge was context degradation. During long coding sessions with multiple files, the model would sometimes lose track of earlier architectural decisions or specific data schemas we had established. I had to learn to be very strict with my prompting, regularly resetting the context and reminding the model of the exact constraints we were working within. You cannot just put it on autopilot; it requires a firm, guiding hand to keep the code consistent across a growing codebase.

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev — Sat, 28 Feb 2026 05:48:51 +0000

A weird thing happens when you become a developer.
You can go days without anyone needing you in a human way.
Not because people don’t care.
But because work is now async, social life is optional, and “busy” sounds responsible.

You ship PRs. You reply in threads. You keep things moving.
And slowly your life becomes a clean interface.
Functional. Quiet. Empty.

Nobody warns you about the emotional side of remote competence

When you’re good at your job, you become low-maintenance.
You don’t ask for help.
You don’t block anyone.
You don’t cause drama.
You deliver.

From the outside, you look like you’re thriving.
From the inside, it can feel like you’re fading.

Because the truth is:
A lot of developer life can be done without being truly seen.

The “I’m fine” loop

I’ve seen this pattern in myself and in others:
You work a lot because it’s predictable.
You cancel plans because you’re tired.
You feel guilty for canceling, so you avoid reaching out.
You become isolated.
You work more because the silence is loud.

And the scary part is how normal it looks.
It doesn’t look like a crisis.
It looks like productivity.

The day I realized something was off

It hit me on a random weekday.
I had done everything “right”:
exercised
ate okay
shipped code
answered messages

But I couldn’t remember the last time I had laughed with someone in real life.
Not a polite smile. Not a reaction emoji.
Actual laughter.

That’s when it clicked:
You can have a full calendar and still have nobody close.

If you’re reading this and it resonates, try this

Not advice like “join a community” or “go outside.”

Something small and real:
Pick one person you like.
Send a message that doesn’t require a big conversation.
Something like:
“Hey. Random check-in. How are you really?”
Or:
“I realized I’ve been quiet lately. Want to grab a coffee this week?”
It feels stupidly simple.
But it breaks the loop.

Developers are great at systems

So here’s a system that helped me:
I treat friendships like health checks.
Not in a robotic way.
In a “I don’t want to drift away from my own life” way.

Once per week:
one message to a friend
one plan that involves leaving the house
one thing that is not productive
Because if I don’t schedule connection, my default becomes isolation.

Question

Do you ever feel like dev life makes it too easy to disappear?
If you’ve been through it, what actually helped?
Not theory. Not productivity hacks. The real thing.

Digital hoarding and the beauty of decay

NorthernDev — Mon, 23 Feb 2026 13:24:50 +0000

In a recent discussion about the value of deleting code, one specific habit kept coming up: leaving blocks of commented-out code in a file, just in case we might need it later.

We all know we should not do it. We have version control systems that remember every keystroke we have ever made. Yet, we leave that graveyard code right in the middle of our active files. We do it because deleting feels permanent, and keeping it feels safe. But in reality, it just transfers the cognitive load to the next person trying to read the file.

This habit of hoarding code is just a symptom of a much larger problem. We are a generation of digital hoarders.

The cognitive load of "read-it-later"

Look outside your IDE. Look at your browser with its forty open tabs. Look at your read-it-later app, filled with hundreds of articles, tutorials, and deep dives that you saved months ago. We hoard this information with the best of intentions. We tell ourselves that we will read it this weekend.

But we rarely do. Instead, that infinite list of unread links becomes a source of low-grade anxiety. It transforms from a library of knowledge into a visual reminder of everything we are failing to keep up with. It is the exact same cognitive load as the commented-out code, just applied to our daily lives.

Embracing digital decay

The solution to both problems is the same: we need to embrace the concept of decay.

In nature, things that are no longer useful break down and clear the way for new growth. In software and personal knowledge management, we try to keep everything alive forever. But if a piece of code was truly important, you will write it again, probably better. If an article was truly essential, the concept will cross your path again.

We need to stop treating every piece of digital information as a compounding asset. Most of it is temporary context.

This specific realization is actually what pushed me to build my own tool recently. I was tired of feeling guilty about my endless list of saved links, so I built Sigilla. It is a bookmarking tool with a very specific constraint: unread links decay and disappear over time. If you do not read it, the system cleans it up for you. No graveyard, no endless backlog, just the things you actually have the time and intention to focus on right now.

Whether it is a block of legacy code or an article about the latest framework, the most liberating thing you can do is to let it go. There is beauty in letting things decay.

The most valuable skill in 2026 isn't writing code. It is deleting it.

NorthernDev — Tue, 17 Feb 2026 12:42:44 +0000

We are currently living through the greatest inflation of software in history.

With the AI tools we have available in 2026, a Junior Developer can generate more lines of code in an afternoon than a Senior Developer used to write in a month. We have lowered the barrier to entry for creation to almost zero.

But we have not lowered the cost of maintenance.

If anything, we have created a crisis. We are drowning in "good enough" code, boilerplate, and features that "might be useful later."

Code is not an asset. It is a liability.

I used to measure my productivity by how many green squares I had on my GitHub contribution graph. I thought that writing more meant I was building more value.

I was wrong.

Every line of code you write is a commitment. It is something that needs to be:

Tested
Debugged
Secured
Updated when dependencies break
Read by the next person (or yourself in 6 months)

The Hoarder Mindset

I recently realized that my codebase looked exactly like my "Read Later" list—a graveyard of good intentions.

I had features I built "just in case." I had abstractions that were "future-proof" (for a future that never arrived). I had utility functions that were used once and then forgotten.

It was digital hoarding. And just like hoarding physical objects, it creates a mental load that paralyzes you.

The Era of the Code Janitor

The best developers I know right now are not the ones spinning up 10 microservices in a weekend. They are the ones walking into a project and saying:

"We can delete this module."
"We don't need this library."
"We can solve this without code."

They are not Architects. They are Janitors. And I mean that with the highest possible respect.

The Art of Subtraction

I spent this past weekend doing nothing but deleting.

I removed a feature that only 2% of users touched but caused 50% of the support tickets.
I ripped out a complex state management library and replaced it with standard React hooks.
I hard-coded variables that I had made dynamic "just in case."

The result? The bundle size dropped. The build time was cut in half. But most importantly, my mental model of the system became clear again.

Conclusion

In a world where AI can write infinite code, the value of writing code approaches zero. The value shifts entirely to curation.

Your job is no longer to build the mountain. Your job is to carve the sculpture out of the rock.

If you want to be a Senior Engineer in this new era, stop asking "What can I add?" and start asking "What can I remove?"

Go look at your PRs from last week. Did you add complexity, or did you remove it?

The most satisfying commit message is not "Feat: Added X".
It is "Refactor: Deleted 2,000 lines".

Your "Read Later" list is a graveyard. It is time to stop hoarding.

NorthernDev — Wed, 11 Feb 2026 12:58:25 +0000

You have a tab open right now that you have been meaning to read for three weeks. You have a "Read Later" folder with 500 links you haven't touched since 2023.

We treat information like fast food. We see a headline, we get a dopamine hit, and we click "Save." We feel productive. We feel like we have learned something just by bookmarking it.

But we haven't. We have just moved a URL from a public server to a private database row.

I looked at my own habits recently. I wasn't building a knowledge base. I was building a digital cemetery.

The tools we use, Instapaper and Notion are designed for hoarding. They want you to save as much as possible because that keeps you in their ecosystem. They measure success by "items saved," not by "knowledge gained."

I wanted a tool that respects my attention and actually forces me to learn. So I built one.

The "Collector's Fallacy" There is a concept called the Collector's Fallacy. It is the false belief that "having access to knowledge" is the same as "having knowledge."

As developers, we are the worst offenders. We save tutorials on Rust, articles on System Design, and papers on AI architecture. We tell ourselves we will read them "this weekend." We never do.

To fix this, I realized a "Read Later" app needs to do two things that most apps don't:

Stop the spying. I don't want an app that analyzes my reading habits to build an ad profile.
Force engagement. A list is passive. A learning tool must be active.

Enter the Resurrection Engine I built Sigilla to solve my own problem.

It is a privacy-first reading companion. It runs on a boring, stable stack (PostgreSQL via Supabase + React), because I want my data to outlive the current hype cycle.

The core feature isn't saving. It is resurfacing.

I implemented a Spaced Repetition system, similar to Anki, but for articles. If I save a deep dive on Postgres Indexing, Sigilla doesn't let it rot. It brings it back to my attention. It asks: "Did you actually read this? If not, do you want to delete it?"

It forces a decision. Read it, or admit you never will and let it go.

Privacy as a Feature We have seen the recent reports about browser extensions scraping user data. It is a nightmare.

That is why I built Sigilla to be quiet. The extension doesn't track your browsing. It doesn't "phone home" with your history. It only activates when you explicitly tell it to save a specific page.

I calculate reading metrics (like scroll depth and time spent) locally in the browser. The only thing that touches the database is the final engagement score. I don't want your data. I just want you to read the articles you saved.

Why I am building this I am tired of renting my brain to SaaS companies that profit from my distraction.

Sigilla is currently free to use. I am building it for myself and for other knowledge workers who are tired of the noise.

If you are ready to stop hoarding and start curating, you can try it out. But be warned: It will force you to actually read.

Sigilla

Let me know in the comments: Be honest, how many unread tabs do you have open right now?

The Junior Developer is Extinct (And we are creating a disaster)

NorthernDev — Thu, 05 Feb 2026 13:05:27 +0000

I have a confession to make.

Five years ago, if I had a tedious task like writing unit tests for a legacy module or converting a JSON schema, I would assign it to a Junior Developer. It was boring work for me, but it was gold for them. It taught them the codebase, it taught them discipline, and it taught them how systems break.

Today, I don't assign that task to a Junior. I assign it to Copilot / Claude.

It is faster. It is cheaper. It is often more accurate (at least syntactically).

And that is exactly why the software industry is walking off a cliff.

The Broken Ladder

We are currently optimizing for short-term velocity at the expense of long-term survival. By using AI to automate the "boring" entry-level tasks, we have inadvertently removed the bottom rungs of the career ladder.

A Senior Developer isn't just someone who knows syntax. A Senior Developer is someone who has broken production 50 times and knows how to fix it. You don't learn that by reading tutorials. You learn that by doing the grunt work that we are now automating away.

If we stop hiring Juniors because "AI can do it", where will the Seniors come from in 2030?

The "Vibe Coding" Trap

I see a lot of excitement about "Vibe Coding", the idea that you can just prompt your way to a product without understanding the underlying code.

This works fine for a prototype. It is a disaster for longevity.

When a Junior writes bad code, I review it, we talk about it, and they learn why it was bad. They grow. When an AI writes bad code, I just re-prompt it. No one learns anything. We are filling our codebases with logic that no human fully understands, maintained by a generation of developers who never learned the fundamentals because the machine did it for them.

The Knowledge Gap

We are creating a "Barbell Distribution" in tech:

The Super-Seniors: Developers with 10+ years of experience who use AI as a force multiplier. We are becoming 10x faster.

The AI Users: People who can prompt but cannot debug a race condition or understand memory management.

The middle is disappearing. The path from Group 2 to Group 1 is gone.

What Happens Next?

I don't have the solution, but I know the current path is unsustainable. Companies need to stop viewing Junior hiring as "charity" or a "cost center" and start viewing it as an existential insurance policy.

We need to hire Juniors not to write code (AI can do that), but to audit AI. We need to teach them "Forensic Coding", the art of understanding why the machine hallucinated.

Discussion

Are you seeing this in your company? Is your team still hiring Juniors, or has the pipeline frozen?

Junior devs: How are you finding the job market right now? Senior devs: Are you worried about who will replace you?

Let's talk about it.

Unpopular Opinion: I stopped coding on weekends and my career got better.

NorthernDev — Thu, 29 Jan 2026 23:00:28 +0000

For years, I lived with a constant, low-level hum of guilt.
You know the feeling. It’s Saturday morning. You are drinking coffee, maybe about to go for a walk or play a video game. But in the back of your mind, a little voice is whispering:

"You should be working on that React Native side project."

"Have you tried out Bun yet? Everyone on X is talking about it."

"Real developers code for fun."

The tech industry has sold us a lie: That passion equals hours logged. That if you aren't grinding on the weekend, you will be left behind by someone younger, hungrier, and willing to sleep under their desk.

I bought into it. I spent years coding 50 hours at my job, and another 15 hours on weekends building half-finished apps that nobody used.

I wasn't becoming a better developer. I was just becoming exhausted. My code on Mondays was sloppy, my patience in meetings was thin, and I hated opening my editor.
So, about a year ago, I did something terrifying. I stopped.
I made a rule: Laptop closes Friday at 5 PM. It does not open until Monday at 9 AM. No exceptions. No "just checking a PR."

I thought my skills would stagnate. I thought I’d lose my edge.
Here is what actually happened:

1. My subconscious started solving problems.
Before, when I hit a wall on Friday, I’d bang my head against it all weekend. Now, I walk away. I go hiking. I see friends. And almost every Sunday night, while doing dishes, the solution just pops into my head. I solve complex problems faster on Monday morning in 30 minutes than I used to in 8 hours of tired weekend hacking.

2. I became a better colleague (and got promoted).
Turns out, being a Senior developer isn't just about raw coding speed. It's about communication, patience, and leadership. When I wasn't constantly burned out, I was nicer to work with. I listened better in architecture meetings. People started trusting my judgment more because I wasn't manic.

3. I rediscovered the joy of coding.
Distance makes the heart grow fonder. By starving myself of code for two days, I actually look forward to Monday mornings.
The Nuance (Before you yell at me)
I know some of you will say: "But I love coding on weekends!" If that's genuinely true, keep doing it.
I also know juniors often need to put in extra hours to bridge the knowledge gap early on. I did too.
But if you are a mid-level or senior developer and you feel like you are drowning in hustle culture, let this be your permission slip to stop.

You are not a compilation machine. You are a human being who solves problems with code. Humans need rest. Machines don't. Which one do you want to be?

Let’s argue in the comments:
Is "passion" mandatory to be elite in this industry? Or is coding just a job that pays well so we can enjoy our actual lives?