— “Elmo’s got the moves” playing in my head since I typed this article’s title —

I wrote a book on Bash scripting that I’m about to publish. It teaches you how to write Bash, and more importantly, how to write it right.

But cool kids don’t write code anymore, do they?

Maybe the time will never come again when we’ll need to read and understand code ourselves—AI agents will have us covered. Maybe it’s fine. Maybe you don’t need to know the basics.

Testing as a topic is a minefield already when it comes to full-fledged programming languages, let’s not even talk about it for shell scripting.

Or shall we?

You see, whether you write software to test other software, or you just fire up a script from the command line and keep running it over and over again until you nail it, that’s still testing, right?

Have you ever been woken up at night because a script failed six months after you wrote it? Or one year later? Or five years later? — For the love of my life, that thing was supposed to be temporary! There’s nothing more permanent than a temporary solution, they say.

Happy New Year! Let’s start 2026 with a look at something that surprises many developers: Bash script performance actually matters, and you can measure and improve it systematically.

If you’ve ever written Bash scripts that process thousands of log entries, iterate over file lists, or run in tight loops, you’ve probably wondered: “Is this as fast as it can be?” The answer is usually no—but the trick is knowing what to measure and how to interpret the results.