Hello fellow devs.
I'm Kamon Ayeva. I've spent 20+ years building and deploying web applications, and most of that time in production contexts, where the terminal is where you debug, deploy, and fix things under pressure.
I remember a long time ago when a colleague advised to switch to Linux if I wanted to be more productive. And later, like many developers, I switched to macOS as my OS of choice.
My avenues of learning and teaching have always been inspired by: productivity, frictionless collaboration, the terminal and the power of the CLI. That's where my writing comes from: craft I picked up, and repeated, because a job needed it.
I write a weekly newsletter called Shellcraft, one piece of terminal craft per issue: fzf, broot, lazygit, bat, DuckDB, the shell idioms in between, etc. I'm also the author of The Modern CLI Stack, a free book about the modern terminal toolkit.
This is my first post here, and I want it to introduce the rule behind everything I write, because it's the reason the newsletter is worth your time:
I run every claim on my own machine before it's published.
Roughly one in five claims I draft turns out to be wrong when I test it. Not typos, but plausible-sounding errors. A shortcut that the current version doesn't bind anymore. A config format I half-remembered from an older release. A verb that the docs mention but the binary doesn't ship. Last month I drafted an issue about a tool's panel workflow, ran the session walk before publishing, and discovered the step the whole issue was built around didn't happen on my machine. I spent time rewriting the issue around what actually happens, and I was happy with shipping that version.
The drafts that pass without corrections are the dangerous ones. So before each issue goes out, I write a small verification guide for it (steps to reproduce it, the expected output, etc). It's a private test file, and running it is one of the last steps before publish.
Why am I telling you this in my intro post here? Because it's the promise I'm making to this community. I plan to post here, at least once a month, expanded versions of what I cover in the newsletter, the same way I write it.
If that's the kind of thing you want in your feed, the newsletter sends it weekly. The book is the free full toolkit.
Happy to be here.
What's a terminal claim you believed for years that turned out to be false? Or a suggestion for something I should feature in the newsletter?
Top comments (0)