Mental Health Tools for Devs: Apps and Habits That Actually Work

I almost didn't write this article.

Not because it's not important — it might be the most important thing I've written all year — but because the intersection of "software engineering" and "mental health" tends to produce content that reads like it was generated by a wellness startup's marketing team. Breathe deeply. Take breaks. Drink water. Practice gratitude. Thanks, I'm cured.

I've been writing software professionally for over thirty years. I've had seasons where the work was genuinely exciting and seasons where I couldn't open my laptop without a low-grade dread settling in behind my sternum. I've watched talented engineers quietly fall apart, leave the industry, or worse — stay in the industry but stop caring about anything, including themselves.

What I'm going to share here is what actually works. Not theory, not wellness culture, not corporate EAP pamphlet advice. Tools, apps, and habits that I've either used myself or watched other experienced engineers use to stay functional and occasionally even happy while doing this work for decades.

---

The Problem Is Structural, Not Personal

Before we get to solutions, I need to say something that took me twenty years to understand: the mental health challenges in software engineering aren't primarily individual failures. They're structural features of how the work is organized.

Constant context-switching. Ambiguous requirements that change mid-sprint. On-call rotations that train your nervous system to associate phone notifications with cortisol. Performance reviews that reduce months of complex problem-solving to a number. The expectation that you'll be perpetually learning new frameworks while also shipping production code on deadline.

This matters because the solutions that actually work tend to address structure, not just symptoms. Meditation is great. But meditation plus fundamentally reorganizing how you handle notifications and context-switching is better.

---

Apps That Have Earned Their Place on My Phone

I'm skeptical of most apps. Most of them are attention-harvesting machines disguised as productivity tools. But a few have genuinely changed how I manage my head.

Insight Timer (Free Tier Is Sufficient)

I resisted meditation apps for years because the marketing around them felt manipulative. Insight Timer won me over because it's mostly just a timer with an optional library of guided sessions. No gamification pressure. No streak shaming.

What I actually use it for: a ten-minute session between deep work blocks. Not to "clear my mind" — that's not how brains work — but to create a deliberate transition between contexts. I've found that the single biggest mental health drain in software work is the residue of the previous task contaminating the next one. Ten minutes of sitting quietly with my eyes closed acts as a cognitive palette cleanser.

I don't do this every day. I do it when I notice the signs that I'm carrying context I can't put down: irritability, difficulty starting the next task, rereading the same Slack message three times without absorbing it.

Forest (Paid, Worth It)

Forest is a focus timer that grows a virtual tree while you work and kills it if you pick up your phone. It sounds gimmicky. It is gimmicky. It also works, because the psychological mechanism it exploits — loss aversion — is genuinely powerful.

I use it during deep work sessions, usually 45-90 minutes. The tree thing is silly, but the real value is that it gives me permission to not respond to messages. That permission is surprisingly hard to give yourself without an external structure supporting it.

Daylio (Free Tier Works)

Daylio is a mood tracker that takes about five seconds per entry. You tap an emoji, optionally select some activities, and it builds a dataset over time.

Here's why this matters for engineers specifically: we're trained to make decisions based on data, but we almost never apply that discipline to our own mental states. Daylio gave me visibility into patterns I couldn't see from inside my own experience. I discovered that my worst mental health days consistently correlated with days where I had more than four meetings. Not five. Not six. Four. That threshold was invisible to me until I had the data.

I adjusted my schedule accordingly. Fewer meetings, better mood. It sounds obvious in retrospect, but I'd been ignoring it for years because I didn't have the data to justify the change to myself.

Obsidian (Free for Personal Use)

Obsidian isn't technically a mental health app. It's a note-taking tool based on local markdown files. But I'm including it because journaling in Obsidian has been one of the most effective mental health practices I've adopted, and the reason it works is directly related to being a developer.

I tried paper journals. I tried Day One. I tried just writing in a text file. What works about Obsidian specifically is that it lets me link notes together, which means my journal entries connect to my technical notes, my project reflections, and my personal observations. Over time, a picture emerges that's richer than any individual entry.

My daily template is simple:

## Energy Level: [1-5]
## What I'm working on
## What's bothering me
## One thing that went well

The "what's bothering me" section is the most valuable. Writing it down externalizes it. Once it's on the page, it loses some of its power. I've been doing this for about two years now, and the compound effect of that daily externalization practice has been significant.

---

Habits That Survive Contact with Reality

I've tried dozens of "wellness habits" over the years. Most of them lasted two weeks. Here are the ones that actually stuck, and more importantly, why they stuck.

The Hard Cutoff

I stop working at 5 PM Alaska time. Not "I try to stop." I stop. The laptop goes into the other room. This habit survived because I made it binary — there's no judgment call about whether this particular evening requires more work. The answer is always no.

This was the hardest habit to adopt and the most impactful. The reason it works isn't discipline. It's that I restructured my work to fit inside the constraint rather than expanding the constraint to fit the work. Tasks that used to feel urgent at 4:45 PM get handled at 8 AM the next day, and the world doesn't end.

The exception: genuine production emergencies. In thirty years, I've had maybe twenty of those. Everything else can wait.

Morning Movement Before Screens

I don't check email, Slack, or any work-related communication until I've done at least twenty minutes of physical activity. In Alaska, that's usually a walk, snowshoe, or some time splitting wood depending on the season.

The mechanism here is cortisol timing. Your cortisol peaks naturally in the first hour after waking. If you immediately flood that window with work stressors — Slack notifications, overnight emails, PR review requests — you're training your body to associate morning cortisol with anxiety rather than energy.

Twenty minutes of physical activity channels that cortisol into something useful. By the time I sit down at my desk, I'm alert but not wired.

The Wednesday Reset

Every Wednesday, I take thirty minutes in the afternoon to review what I'm working on and explicitly decide what I'm going to stop doing. Not what I'm going to start. What I'm going to stop.

Engineers are terrible at stopping things. We accumulate obligations, side projects, "I should look into that" tasks, and half-finished experiments. They create a background cognitive load that's invisible but constant.

The Wednesday Reset forces me to consciously prune. Every week. It's uncomfortable because stopping things feels like failure. But the alternative is carrying an ever-growing backlog of uncommitted obligations that drain energy without producing results.

Saying No to Meetings Without Agendas

If a meeting invitation arrives without a clear agenda and expected outcome, I decline it. Every time. I send a brief message: "Happy to attend if you can share what we're trying to accomplish. Otherwise I'll catch up on the notes."

About half the time, the meeting gets cancelled entirely because the organizer realizes they don't actually know what they're trying to accomplish. The other half, I get an agenda, and the meeting is dramatically more productive.

This habit directly impacts mental health because unstructured meetings are one of the highest-anxiety activities in software engineering. You're in a room (physical or virtual) where you don't know what's expected of you, the conversation meanders, and you leave feeling like you lost an hour with nothing to show for it. Eliminating those meetings eliminated a significant source of daily stress.

---

The Harder Conversation: When Habits Aren't Enough

I want to be honest about something. There was a period about eight years ago where no amount of apps, habits, or lifestyle optimization would have helped me. I was dealing with something that needed professional support, and I delayed getting it because of exactly the kind of self-reliance mentality that made me a good engineer.

The belief that you should be able to fix your own problems is adaptive in software. You encounter a bug, you debug it, you fix it. You encounter an architectural problem, you analyze it, you redesign it. The feedback loop is tight and the agency is real.

Mental health doesn't work that way. The debugging tools are compromised because the system doing the debugging is the system that's broken. Trying to think your way out of depression or anxiety is like trying to compile a program using a corrupted compiler.

I eventually talked to a therapist. It helped. Not in a dramatic movie-moment way, but in a practical way — like having a senior engineer review your approach to a problem and point out assumptions you didn't know you were making.

If apps and habits are the linters and formatters of mental health, therapy is the code review. Both are valuable. Neither replaces the other.

Finding a Therapist Who Gets Tech

This is an underrated challenge. I burned through two therapists who meant well but didn't understand the specific stressors of software work. When I said "I'm on call this week" they heard "I have to take some phone calls." They didn't understand the 2 AM pages, the incident response pressure, the public postmortems.

What worked was specifically looking for therapists who listed "tech professionals" or "high-stress careers" in their specialties. Psychology Today's therapist finder lets you filter by specialty. BetterHelp and Talkspace let you specify your profession, which theoretically helps with matching.

The investment is worth it. A therapist who understands that your anxiety about a deployment isn't irrational — because deployments genuinely can break things that affect millions of people — is dramatically more useful than one who thinks you just need to "put work in perspective."

---

Building a Sustainable Stack

Here's how I think about all of this as a system, because we're engineers and that's how we think about everything:

Daily: Obsidian journal (five minutes). Morning movement before screens (twenty minutes). Hard cutoff at end of day.

As needed: Insight Timer between context switches. Forest during deep work. Daylio mood logging.

Weekly: Wednesday Reset to prune commitments. One conversation with a human that isn't about work.

Quarterly: Honest self-assessment of whether I'm functioning well or just functioning. This is the checkpoint where I decide if I need professional support.

Always: Permission to not be optimized. Permission to have a bad day without diagnosing it. Permission to close the laptop and go look at the mountains.

---

What I Wish Someone Had Told Me at Twenty-Five

If I could go back and give my younger self one piece of advice about mental health in this career, it wouldn't be about apps or habits. It would be this: the fact that you can push through doesn't mean you should.

Software engineering selects for people who can sustain effort through discomfort. That's useful for debugging production issues at 3 AM. It's dangerous when applied to your own well-being, because it means you can function while deteriorating. You can ship code while miserable. You can lead teams while running on empty. You can do it for years.

The question isn't whether you can sustain it. The question is what it's costing you, and whether you're willing to keep paying.

I'm fifty-two years old, living in a cabin in Alaska, writing software and articles and occasionally watching moose walk through the trees. I got here partly through technical skill and partly through finally taking my own maintenance requirements as seriously as I take my servers'.

Your uptime matters too. Monitor it.

---

Shane Larson is a software engineer and writer living in Caswell Lakes, Alaska. He builds things at Grizzly Peak Software and AutoDetective.ai, and wrote a book about training large language models. He still has bad days, but they're less frequent and shorter than they used to be.