About Me | The Wayfarer

The Wayfarer’s Philosophy

This blog, “Lost In It,” is born from a shared feeling: the profound sense of being adrift in the boundless, fast-moving ocean of Information Technology. Like many who started this journey out of passion, I’ve often found myself crushed by overwhelming complexity and problems far out of scale. The lack of shared knowledge and quality in our artifacts only deepens this fog.

I identify with the philosophy of the Wayfarer—not someone with a strict destination, but one who finds the goal in the journey itself, and in sharing the road with others.

The “lost” feeling dissipates when we find a reliable compass: best practices. By adhering to paths and principles found by those who traversed these swamps and dark forests before us, we don’t just survive the journey—we find meaning in it. My mission is to share the maps I’ve found, one post at a time, to help us all navigate the risks and appreciate the beauty of this wild landscape.

My Journey to Better Code

My professional path, like that of any developer, is paved with code that worked, code that failed, and constant, incremental Aha! moments. It wasn’t one single revelation, but a continuous realization that what we build is often a mirror of our process.

The most frustrating anti-pattern I’ve encountered isn’t a technical error like code duplication or violating the SOLID principles (though these certainly waste time). It’s the simple, painful pattern of not progressing—developers not learning from their mistakes and not seeking a better way.

This led me to a simple truth: we must treat scripting no differently than coding in structured languages.

Why? Because underestimating the effort required for ‘simple’ scripts leads to spaghetti code that’s impossible to maintain, debug, or change. We start coding for the machine, and we stop telling a story to the next developer (or future self) who will read that code. My journey has been about taking the rigorous, developer-first approach learned from complex systems and applying it to the smallest, often overlooked corner of our craft: Bash scripting.

Sharing the Map: Bash: The Developer’s Approach

We often put limits on what we can achieve with Bash, dismissing it as a ‘quick and dirty’ tool for simple tasks. I’m here to gently push back against that notion. You can do WAY MORE than you imagine with Bash.

This conviction is the driving force behind my book, Bash: The Developer’s Approach. It is an exploration of how we can apply fundamental, high-quality software development principles, from Clean Code to SOLID, directly to shell scripting. It’s about building reliable, testable, and maintainable scripts that stand the test of time and complexity.

To prove this point—and to provide a practical example of treating Bash as a serious programming language—I developed log4b. While no one needs a structured logging framework for Bash, the underlying principle is key: Don’t put limits on your capabilities. Instead, learn and apply the best tools and patterns available, even in the shell. Experience will eventually tell you when it’s time to stop and move to another language, but until then: you can build it better, now, with a developer’s approach.