The Day I Stopped Fighting My Tools

A burned-out developer's guide to working with the grain, not against it

Photo by Christopher Gower on Unsplash

---

Three years into my first real engineering job, I had a folder on my desktop called workarounds. Inside were 47 shell scripts, each one a tiny monument to my refusal to read the documentation. I thought I was being clever. I was being exhausted.

This is the story of how I learned to stop, and what changed when I did.

---

The problem with being "clever"

There's a particular flavor of burnout that comes from spending your days bending tools to your will. Not the burnout from too much work — the burnout from too much friction. Every task takes three steps longer than it should. Every commit fights you.

For me, it looked like this:

• Writing custom git aliases to fix problems that didn't exist
• Maintaining a personal fork of a popular linter "just in case"
• Building elaborate scripts to bypass code review
• Avoiding any tool I hadn't personally configured from scratch

The most expensive code you'll ever write is the code that exists only because you refused to learn what already existed.

I read that line in a comment on Hacker News at 2 a.m. on a Tuesday. It hit hard enough that I screenshotted it.

What "working with the grain" actually means

Wood has a grain. Push your plane along it and the surface comes up smooth. Push against it and you get splinters, tear-out, and a piece of furniture that looks like it lost a fight.

Software has a grain too. Every tool, framework, and language was designed with certain workflows in mind. When you work with those workflows, things feel effortless. When you work against them, every small task becomes an argument.

Here's the test I now use before writing any "clever" workaround:

1. Have I read the official documentation for what I'm trying to do?
2. Have I asked someone who uses this tool every day?
3. Am I solving a real problem, or am I avoiding learning something?

If I can't answer "yes, yes, real problem" — I close the editor.

A small example

Here's a script I used to maintain for "easier" git branching:

#!/usr/bin/env bash
# branch-helper.sh — DO NOT DELETE (I will delete this)
current=$(git rev-parse --abbrev-ref HEAD)
target="${1:-main}"
git fetch origin "$target"
git checkout -b "feature/$(date +%s)" "origin/$target"
echo "Made you a branch off $target, friend."

It replaced a single command: git switch -c feature/whatever origin/main. That's it. That was the whole "improvement." I had been carrying this script across three laptops for two years.

I deleted it on a Sunday afternoon and felt lighter.

---

The four habits that actually helped

1. Read the man page first

Not the StackOverflow answer. Not the blog post from 2014. The actual man page or official docs. Most CLI tools have answered your question on page one.

2. Use the boring default

If the team uses VS Code, use VS Code. If the project uses npm, don't sneak in bun. The cognitive overhead of being the one weirdo with the custom setup compounds across every pairing session, every onboarding doc, every "wait, why doesn't this work on your machine?"

3. Time-box the fight

When a tool resists you, give yourself 20 minutes to find the canonical answer. If you haven't found it by then, ask a human. Not a forum. A specific human.

4. Keep a "questions I was afraid to ask" log

Mine started with things like "what does HEAD~1 actually mean" and "why does my terminal say (base)." Once a week I'd pick one and learn it properly. Within six months I'd cleared out about 80 small confusions that had been quietly taxing me for years.

Expertise isn't knowing everything. It's having a smaller and smaller pile of things you're pretending to understand.

---

What changed

I won't claim a transformation. I still write the occasional unnecessary script. But the workarounds folder is gone, and my work feels lighter in a way I struggle to describe — like the difference between walking uphill and walking on flat ground. Same legs, same distance, completely different day.

If you're a few years into your career and feel like you're working twice as hard as the people around you for the same output, it might not be a skill problem. It might be a friction problem. And friction, unlike skill, can disappear in an afternoon.

You just have to be willing to stop being clever for long enough to notice.

---

If this resonated, you might also enjoy "The Art of Reading Documentation" or "Why I Deleted My Dotfiles Repo". And if you have your own workarounds folder, I'd love to hear about it in the responses.

Thanks for reading. 👋

---

Tagged: #programming #productivity #burnout #career #software-engineering