Building Developer Tools That Fit The Way You Actually Work

Productivity Is A Systems Problem

Developer productivity is often framed too narrowly. It gets reduced to editor choice, keyboard shortcuts, or whatever new tool is currently popular. Those things matter, but the larger issue is usually workflow design.

How many times do you repeat the same check? How many context switches are required to understand the current state of work? How much of your setup depends on memory rather than a clear system?

Those are engineering questions, not lifestyle questions.

Where Friction Actually Appears

In day-to-day development, friction often shows up in small repeated forms:

• checking the same repo status repeatedly
• remembering local project commands
• opening several tools to understand one piece of context
• copying information between environments
• manually running setup steps that should already be encoded somewhere

Each action is minor. Together they create a workflow that feels slower and noisier than it should.

A Better Approach

The goal of good developer tooling is not to create a personal ecosystem for its own sake. It is to make routine work feel calmer and more predictable.

That usually means:

• CLI-first tools with clean input and output
• small utilities that do one useful thing well
• information surfaced close to where the work happens
• simple local dashboards only where they add clarity
• avoiding brittle "magic" behaviour that becomes hard to maintain

Why Linux And Neovim Influence This

I enjoy working in environments where tools compose well. Linux and Neovim both encourage a more deliberate relationship with tooling: text-based interfaces, small utilities, and workflows that can be shaped around actual habits instead of fixed GUI assumptions.

That does not mean every tool should be terminal-only. It means the underlying system should remain understandable and flexible.

What Makes A Good Internal Tool

The best personal tools tend to share a few traits:

• the job is specific
• the output is useful immediately
• the behaviour is predictable
• the code remains readable
• the tool is easy to remove if it stops adding value

That last point matters. Good workflow tools should reduce dependency on memory and repeated effort, not create a new maintenance burden.

Why This Fits My Work

This area aligns closely with my broader goals because I am interested in software that improves workflows. Developer tooling is simply another version of that problem space. Instead of serving an external client or operator, it serves the process of building and maintaining software itself.

Result

The result is a believable set of developer-facing tools that reflect the same values as the rest of my work: practical scope, strong structure, and a focus on making systems easier to use rather than more elaborate.