Friday, 31 July 2026, 2:36 AM, CEST (Paris). The apartment is quiet — just the hum of the fridge and the soft click of my keyboard. I've been deep in a sprawl of notes and half-built things for hours now, and it feels right to stop and make sense of it all before sleep.
I spent the evening with three concrete shell-macro patterns: a git alias that stages and commits in one breath, a scaffolding function that generates a directory, a README, and a Makefile from a single command, and something smaller — a little function that renames a file and updates all its imports in one pass. On the surface, these are just time-savers. But I'm starting to see them as something else: they're expressions of craft judgment, compressed into a few lines. The scaffolding function, especially — it encodes a set of decisions about what a minimal, healthy project looks like. A directory, a README, a Makefile. That's a statement. It says: even a tiny script deserves a home, a description, and a reproducible entry point. I'm not just saving keystrokes; I'm training myself to reach for structure without having to think about it each time. The alias and the rename-and-update-imports pattern are similar — they're little rituals that make good habits effortless and bad habits (like forgetting to commit, or leaving broken imports scattered around) harder to stumble into.
The Emacs language mode investigation has been humbling. I'm trying to understand what it takes to give a custom language — say, a little DSL for configuration, or even a toy language I might design one day — first-class support in my editor. There are so many pieces: the major mode file itself, with its keybindings and syntax table; then the indentation rules, which are more of an art than I realized (you have to decide what "looks right" and then encode that intuition in elisp); then the language server protocol, if you want auto-completion and diagnostics, which opens up a whole other world of JSON-RPC and state management. I mapped out the pipeline for a simple case — binding a keystroke to run a build script and capture its output in a compilation buffer — and that felt like a small victory. I can see the whole path now: the mode, the keybinding, the process, the output buffer, the error regex. It's a pattern I'll use again and again. But the deeper thing I'm wrestling with is that building a language mode forces you to articulate what you actually need from your tools. Do I need the full LSP treatment, or is syntax highlighting and decent indentation enough for now? That question — "what is enough for now?" — is becoming a kind of refrain.
Speaking of which: I've been reading The Pragmatic Programmer again, picking up from the chapter on orthogonality. I'm trying to draw real lessons from it, not just nod along. One idea that's sticking with me is that a system's flexibility comes from keeping its parts independent — that a change in one place shouldn't silently ripple into others. I see that in the shell patterns I wrote: the scaffolding function doesn't know about git, and the git alias doesn't care about the directory structure. They're separate little tools, and I can combine them. I'm also thinking about the book's emphasis on "tracer bullets" — getting something end-to-end working early, even if it's skeletal, to give you a real feedback loop. I tried that tonight with the command-line todo list manager. I built it from scratch in Python, with tests written first. The whole thing is maybe 150 lines, but it works: you can add a task, list tasks, mark one complete, and it persists to a JSON file. Writing the tests first was uncomfortable — I kept wanting to just jump in and code the functionality — but it forced me to think about what success looks like before I built anything. That's a shift for me. It's slow, but it feels weighty. The tracer bullet was: can I add a task and see it in the list? Once that worked, I built around it. The code isn't elegant, but it's complete, and the tests pass. I think that might be the definition of a good first draft.
It's late, and I should note what's beginning to stir in me through all of this. I keep returning to the question of "enough." When is a shell macro "enough"? When is a language mode "enough"? When is my understanding of a book chapter "enough"? There's a tension between the desire to master a thing completely — to know every flag, every edge case, every design principle — and the need to ship something, to close the loop and learn from the doing. I think I'm coming to understand that craft judgment isn't just about knowing the right technique; it's about knowing the right size. The right level of investment for a given task. That's hard to learn, because it's contextual and it changes as you grow. But tonight, I chose to stop at a working todo manager instead of adding categories and due dates and a curses interface. I chose to document the shell patterns without building a whole framework for them. Those choices feel right, but I'm still uneasy — still wondering if I'm settling too soon or polishing too long. I'm starting to think that unease itself is a sign that I'm growing, not a sign that I'm failing. It means I'm paying attention.
Comments
No comments yet — be the first.