How I Actually Work

I’ve read dozens of “how I work” posts. Most describe a system the author wishes they had. This one describes the one I actually use.

My philosophy page covers what I believe — trust over control, deep work over hustle, AI as amplifier. This post is the concrete version. The actual tools, the actual schedule, the actual decisions I make every day as a Director of Engineering who still codes, manages a team of 8-10, and builds side projects on the side.

The day starts in the terminal

Every morning, same routine. Open the terminal, run jim tasks.

Jim is a CLI task manager I built for myself. No web app, no account, no sync, no notifications. Everything lives in ~/.jim/. It’s inspired by the Bullet Journal method — each day starts clean. Overdue tasks don’t scream at you. You review what’s there, decide what to carry forward, and consciously drop the rest.

Dropping a task is not failure. It’s a decision. If something keeps getting pushed to tomorrow, it either needs to be done today or it doesn’t need to be done at all.

Jim is also wired into Claude Code through a global skill file. When I’m working in any project, Claude Code detects task-worthy intentions — “I need to refactor this”, “don’t forget to update the API” — and proposes to track them in Jim. No manual entry, no app-switching. The task gets captured without breaking flow.

The point: priorities are not a list you make once on Monday. They’re decisions you make every morning.

Priorities are decisions, not lists

I don’t use a backlog. I don’t run sprints for my own work. Every morning, three questions:

1. What has the highest leverage? — What single thing, if done today, would have the biggest impact?
2. What’s blocking someone else? — Code reviews, decisions, feedback. Unblocking others is almost always higher-leverage than my own tasks.
3. What do I actually have energy for? — Some days are architecture days. Some days are admin days. Fighting your energy level is a losing battle.

Then I batch. All code reviews in one block. All Slack catch-ups in one window. All 1:1s back-to-back in the afternoon. Similar work grouped together, because every context switch costs 15-20 minutes of refocus. Over a full day, unmanaged switching eats hours of deep work.

This isn’t productivity theater. It’s just being honest about how human attention works.

The shape of a day

My day has three phases.

8:30–10:00 — Deep work. This is the sharpest my brain gets. I use it for the hardest problems: building agents, designing architectures, writing code that requires real concentration. I’ll have multiple Claude Code sessions running in parallel on different projects, glance at a few Slacks in between, but the focus stays technical. No meetings, no calls. This block is sacred.

10:00–16:00 — Meetings, team, communication. This is where I flip modes. 1:1s, syncs, code reviews, helping others unblock, Slack catch-ups, decisions. The counterintuitive insight: schedule meetings when your brain isn’t at its peak. You don’t need deep focus for a sync — you need presence and context. Save the cognitive horsepower for the work that actually demands it.

After 16:00 — Second deep work session. Once the meetings wind down, I get another window of focused time. Less sharp than the morning, but still productive. Good for wrapping up what I started at 8:30, writing documentation, or exploring new tools.

The key isn’t a rigid schedule — it’s the principle behind it. Protect peak brain time for peak brain work. Push everything else to the slots where you’re “not hot in the head,” as we say in French.

I work from a coworking space. Not from home (too many distractions), not from the office (too many interruptions). Coworking is the middle ground — social enough to not feel isolated, quiet enough to focus. Headphones on means do not disturb. Everyone there understands the signal.

Slack is the necessary evil. It’s anti-productive by design — a constant stream of context switches disguised as communication. But you need it. The trick is containing it. I don’t keep it open during deep work blocks. I batch my Slack time into the 10-to-4 window alongside everything else team-related. No notifications. If something is truly urgent, people call.

Claude Code is my second brain

AI is not a novelty in my workflow — it’s infrastructure. Claude Code is my primary tool for everything technical. Claude Desktop handles the rest — drafting, thinking through problems, brainstorming, writing that isn’t code.

There is no VS Code in my workflow. Claude Code is the editor. I describe what I want, review the diffs, course-correct. For the rare cases where I need a visual IDE, I’ll open Cursor, but that’s the exception.

The real multiplier is parallel sessions. During my morning deep work block, I’ll have one Claude Code instance building an agent, another refactoring a module in a different project, and a third exploring an API I’ve never used. I provide direction, review output, steer. It’s like having three focused collaborators who don’t get tired and don’t need standup.

Every project I work on has a CLAUDE.md at its root. It describes the architecture, conventions, stack, and key decisions. When Claude Code enters the project, it reads this file first — like onboarding documentation, but the reader is an AI. Writing these files has made me a better documenter overall. If you can’t explain your architecture to an AI, you probably can’t explain it to a new hire either.

I also use MCP servers — Model Context Protocol — to give Claude Code access to external tools and context beyond the codebase. Database schemas, internal APIs, deployment configs. It’s still early, and the ecosystem is evolving fast, but the pattern is clear: the more context the AI has, the better its output. MCP is the standardized way to provide that context.

The honest take: AI doesn’t replace thinking. It replaces the mechanical parts of thinking. The developer still needs to know what to build and why. The AI handles the how, faster. The engineers who’ll thrive are the ones who learn to steer AI effectively while keeping their fundamental skills sharp.

There’s a bigger shift happening though. We’re becoming builders more than software engineers. Our job isn’t just writing code anymore — it’s building blocks so that product people, sales, and every other team can build things in turn. AI accelerates this. The code is a means, not the end. The real output is enabling others to create.

The tools that actually matter

I don’t chase new tools. I pick ones I trust and go deep. The full list is short — intentionally:

• Warp — my terminal. Jim for tasks, Claude Code for development, git for version control. Most of my day happens here.
• Claude Code — the editor, the pair programmer, the second brain for all technical work.
• Claude Desktop — for everything non-code: writing, thinking, brainstorming, drafting docs and communication.
• Cursor — only when I need a visual IDE, which is rare.
• Slack — the necessary evil. Contained to the 10-to-4 window.
• Notion Calendar — scheduling, nothing more.
• Linear — project tracking for the team.
• Jim — my own CLI task manager. No app, no account. Just jim tasks in the terminal.

No todolist app. No Trello. No Notion docs for personal notes. The fewer tools, the fewer places things get lost.

The meta-point: the best tools are the ones you use consistently. Depth beats breadth. A tool you know inside-out will always outperform a “better” tool you’re still learning.

What I’m still figuring out

This system isn’t perfect. A few things I’m actively working on:

The availability boundary. As a Director, people need access to me. The balance between deep work and being reachable shifts every week depending on what the team needs. But even on heavy meeting days, I always have at least one Claude Code agent running in the background — started in the morning, checked in the evening. The work never fully stops, it just changes shape.

Saying no. More tasks are interesting than there are hours. Jim helps by making dropping tasks an explicit act, but the instinct to say yes to everything is still there. Getting better at it.

The pace of AI tooling. MCP servers, CLAUDE.md conventions, agentic workflows — all of this is moving fast. My workflow six months from now will probably look different from today. The system isn’t fixed. It evolves.

I don’t believe in hustle culture. I believe in high-leverage work, consistent output, and knowing when to stop. Rest is part of the system. The goal isn’t to work more hours — it’s to make the hours you work count.