About Me | The Wayfarer

The Path Through the Fog

This blog, “Lost In It,” was born from a common professional reality: in the fast-moving landscape of Information Technology, it is easy to find yourself navigating through thick layers of unnecessary complexity. I spent years wrestling with cryptic errors, scripts and ecosystems that grew into unmanageable monsters—just because they lacked structure.

Experience has taught me that the goal isn’t necessarily a final destination, but the quality of the journey and the resilience of the tools we build along the way.

That feeling of being lost dissipates when you find a reliable compass; usually, this comes in the form of best practices. By following the principles discovered by those who traversed these forests before us, we do more than just “get it to work”—we find mastery in it. I’ve spent my time documenting the maps and patterns that actually stand up to production pressure, and I’m here to share them so we can navigate this landscape with confidence and significantly less technical debt.

My Journey to Better Code

My professional path 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 a direct mirror of our process.

The most frustrating anti-pattern I’ve encountered isn’t a specific technical error like code duplication or violating SOLID principles—though those certainly waste time. It’s the simple, painful pattern of stagnation: developers repeating the same mistakes because they haven’t been shown a better way, or because they’ve accepted “messy” as the default state for certain tools.

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

Underestimating the effort required for “simple” scripts leads to spaghetti code that is impossible to maintain, debug, or change. We start coding for the machine, and we stop telling a story to the next developer (or our future self). 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 trivial tasks. I’m here to push back against that notion. You can do WAY MORE than you imagine with the shell if you approach it with the right mindset.

This conviction is the driving force behind my book, Bash: The Developer’s Approach. It is an introduction to Bash from the ground up (so if you’re completely new to Bash, that book is also for you) that keeps an eye on how we can apply fundamental software development principles directly to shell scripting. It’s about building reliable, testable, and maintainable scripts that stand the test of time.

To prove this point—and to provide a practical example of treating Bash as a serious programming language—I developed log4b. You might think a structured logging framework for Bash is overkill, but the underlying principle is what matters: never settle for “good enough” when you can build for “resilient.” Experience tells us when it’s time to move to another language, but until then: you can build it better, right now, with a developer’s approach.