Fix your tools

The caveat is that you might end up shaving a yak.

More often than not I end up three or four tasks deep while trying to fix a tiny issue.

https://m.youtube.com/watch?v=_UZFI-8D5uA

Engineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe).

My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”

Excellent advice. I try to follow it in my daily work, with some success.

Excellent follow-up advice: now stop fixing your tools, and go fix your actual problem instead. I try to follow it in my daily work, with noticeably less success.

> The very desire to fix the bug prevented me from seeing I had to fix the tool first, and made me less effective in my bug hunt

Kenneth Stanley's book "Why Greatness Cannot Be Planned: The Myth of the Objective" is dedicated to this phenomenon

biggest lesson i learned here: all-in-one tools that promise to handle your whole workflow are almost always worse than stitching purpose-built ones together.

i tried every no-code automation platform (make, airtable, n8n) for a content pipeline i was building. they all break the moment you need to run it more than twice a day at any real scale. weird rate limits, silent failures, state management nightmares.

ended up just writing python scripts that call APIs directly. less "elegant" but infinitely more debuggable. the fix-your-tools moment for me was realizing the tool itself was the problem -- sometimes fixing means replacing with something simpler and more transparent.

Using the debugger to understand/read code is invaluable. Seeing live stacks is so powerful compared to static analysis.

Totally agree with this. I spent way too long fighting my dev environment last month before I finally sat down and properly configured everything. The ROI on fixing your tools is insane - what took me 2 hours of yak-shaving per week now takes zero.

The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.

It's not just the tools, it is your tests. Most times you encounter and fix a bug, your first question should be 'Why didn't my tests catch this?'

> So I fixed the debugger (it turned out to be a one-line configuration change)

That line links to the commit, which adds

    .withDebug(true)

to an invocation of GradleRunner in a file named AllFunctionalTests.kt in the krossover project.

My question is:

Why can the software choose whether, when I run a debugger on it, the debugger will work?

It can't, of course, so what's going on?

This is the reminder I needed. For some projects the python LSP I am using in Neovim just breaks sometimes. Always so frustrating when I start fuzzy searching instead of just jumping to a declaration or restart it.

If you like what you just read you should probably never install Emacs.

You're welcome.

My friend once told this joke:

> "A good programmer, when encountering a debugger bug," he paused, cleared his throat, and said solemnly: "should immediately drop the program they're debugging and start debugging the debugger instead!" The auditorium once again erupted in thunderous applause.

I aim for the Boy Scout rule - always leave things better than you found it. It’s always a balance and you have to not lose the forest for the trees. Always ask what is the end goal, and am I still moving forward on that.

If you're still dipping your toes into an LLM world, this is an excellent place to begin. I helped with a deploy at work the other day, we have some QA instructions (Notion). I pointed the LLM at one of the sections, asked it to generate task list for each section, and once that looked good, had to convert the processes into a set of scripts. The latest models make short work of scriptable stuff that you can use for debugging, testing, poking, summarizing, etc.

My version of this is ‘always be toolin’, but then of course one must use judgement lest it be better to just get on with it.

Ugh, this brings on flashbacks to when I had to work with Ruby, and the *** debugger would break with every single release. The RubyMine IDE that 45% of the company used was based on some bizarre custom Ruby gems to enable debugging, and that crap would take a month to be fixed by JetBrains. 10% used VSCode where debugging would sometimes work and sometimes not.

"Give me six hours to chop down a tree and I will spend the first 4 sharpening the axe"

Also, FYI: Claude is very good at fixing tools

OP here, thanks for submitting!

"first we shape our tools, then our tools shape us"

Next time use AI.