XY Problem

Every now and then a question/request will come up on Slack or in a conversation that seems odd, but in an attempt to be helpful I'll answer it and a follow-up question or two. And then the next question breaks my mental model of the situation and I do an internal double-take. In those situations my response is usually something along the lines of Wait, what is it you're really trying to do?

And that's an XY problem. The kind of problem where you each step requires a more esoteric and specific solution from a generic tool. When you find yourself in that situation it's usually a good idea to step back and make sure you're approaching things the right way. You'll usually find that if you work with the system instead of against it things will go much smoother.

It often happens when your go-to tool isn't quite the right tool for the job. sed is in fact a turing complete language, meaning you can do just about anything with it, but that doesn't mean you should use it for your problem. It's great for examining/modifying text one line at a time, and is OK for multi-line text, but beyond that use something else. xargs is where I often find myself getting too far down into the weeds.

The other day I was trying to clean up some kubernetes pods, and selecting the right ones was a little tricky. It seemed easy at first, but as the condition got more complicated the amount of escaping and nesting was getting out of hand. I fought with it for a while, consulted the bash grimoire and stack overflow, but eventually realized that the best solution was to stop trying to mash it all into one line and use an external script.

It never quite got to the point of writing a Golang program to handle it, I came really close, and I promised myself that the next time it needs to be extended I'm moving to Golang and taking the opportunity to merge 3 custom scripts into a more generic, extensible program.

Sometimes you just need to go back to first principles. Look at the requirements, look at the non-requirements, and start down a different track with the knowledge you've gained. The trick is to balance the determination to see a plan through as written against the possibly slightly longer time to get a more maintainable, long term solution