Forem: Tom Mango

Quick Shell Access from Claude Code

Tom Mango — Sun, 08 Feb 2026 20:22:30 +0000

When using Claude Code, you'll often want to drop to the shell for quick commands like checking git status, switching branches, or running tests. There are two main ways to do this, and which one you use depends on what you need.

For single commands, Claude Code supports the ! prefix. Type !git status or !python -m pytest and it runs the command inline without leaving your session. This works well for one-off checks, but each command needs the ! prefix, and there's no way to stay in bash mode. If you're moving quickly through multiple commands, having to remember the prefix each time fights against muscle memory.

For more involved shell work, you can suspend Claude Code entirely with ctrl+z, which gives you your full shell prompt. Here, you can handle tasks like git branch management yourself instead of asking Claude to do them and burning tokens and network round-trips for something trivial. When you're done, run fg to resume Claude Code exactly where you left off.

One caveat: only suspend when Claude is idle and waiting for your next message, not during an active generation. When you hit ctrl+z, you're suspending the local client process. If Claude is generating a response, the server-side work continues while your client is frozen. When you fg back, the client and server can be out of sync, and you risk losing the response or corrupting the session state.

Product Engineering & Pragmatism

Tom Mango — Sat, 03 Jan 2026 16:26:36 +0000

Let's get the caveat out of the way first. My perspective here is about businesses. There are certainly different tradeoffs and values in other types of organizations, but I'm talking specifically about businesses that employ software engineers to build software that customers pay for.

Even within businesses there are sliding scales on tradeoffs, but typically, time spent by people costs money. What engineers spend their time on is an investment, and investments are meant to have a return.

Healthy Organizations

Healthy organizations are pragmatic. Not just on the engineering side, but on the business side as well. Ideally, they don't even refer to themselves as "sides" of the company. That language implies you're working against each other, not together. But it happens a lot.

There are a lot of idealistic engineers out there. I think it's good to be idealistic, but only in places where you have time that doesn't directly cost money, and that is almost certainly not at your job. Being pragmatic means understanding what tradeoffs exist and how to make them. It also means being idealistic on your own time, where you can explore ideas, experiment, and hone your skills without those constraints.

Idealistic engineers who understand when to be idealistic and when to be pragmatic tend to become champions of things like strong culture. They rally their teams. They know how to balance progress with technical debt. They find compromises. They put data together to convince partners outside of engineering why certain investments are worth making. Over time, they build trust and bargaining power because leadership sees that they understand the broader context. Trust is powerful.

When Idealism Breaks Down

The problem is when idealistic engineers can't come to terms with pragmatism in a business environment. When there isn't unlimited time, because time costs money. In my experience, those engineers don't become champions. They don't rally the team. When they don't get their ideal outcome, frustration turns into negativity, and that negativity seeps into everything. It drains the joy out of the work. Negativity kills teams.

There are, of course, roles inside businesses where people can take more time, go deeper, or move at their own pace. But realistically, businesses paying those salaries aren't doing it out of the goodness of their hearts. They're still betting on a return. Open source investments fall into this category, and that isn't a bad thing. Businesses investing in open source can be a win-win. It's good for the company and good for others. But it still needs to be good for the company first.

I've worked with idealistic engineers who were incredibly smart but not pragmatic at all. They often felt “other than” the rest of the organization. Some of them looked down on the product engineers who were focused on supporting and shipping the product. Once that happens, the team stops listening to their advice. But add a dose of pragmatism, and you get someone who is still pushing standards, while also meeting the team where they are.

Culture

Product engineering is what most employed software engineers in businesses are hired to do, and successful product engineers are pragmatic. I'll work with a pragmatic product engineer any day of the week. But an idealistic product engineer who is also pragmatic tends to be the kind of person teams rally around. They work with partners outside of engineering to deliver what needs to get delivered, while also working with their engineering peers to do those things well.

For as long as I can remember, I've told my teams that everything is a negotiation. We're there to deliver what's prioritized, but it's also our responsibility to speak up and make the case for the tradeoffs we think matter.

So by all means, be idealistic. Just make sure you can also be pragmatic, where and when it counts.

Stacking PRs & Squashing Merges

Tom Mango — Wed, 08 Oct 2025 20:37:07 +0000

Sometimes you're working on a feature that's too big for one PR and splitting it up makes it easier to review. The way I handle this is by creating a first feature branch, then branch second off of it, then third off of second. As each branch is ready for review, I open a PR and each subsequent PR stacks on the last, so reviewers can focus on one layer at a time.

That setup works really well, but it gets messy when your team uses a squash merge strategy where each PR turns into a single commit when merged into main.

Here's what happens: when you squash-merge first into main, Git collapses all of those commits into a single new commit. This is great for keeping main's history clean and readable. But your second and third branches are still branched off the old first—the one with all those individual commits. When they compare against the new main, they'll suddenly include all of first's commits in their diff. The diff becomes noisy and reviewers can't tell what's actually new in second or third.

The fix is to rebase your next branch back onto main. When you do that with the right flags, Git will replay just the commits unique to that branch on top of the new history, dropping anything that already exists upstream. Here's how.

Rebase the next branch (second) onto main

git fetch origin
git checkout feature/second
git rebase --onto origin/main origin/feature/first
git push --force-with-lease

The --onto flag tells Git: "replay the commits from second that don't exist in first, putting them on top of main instead." Then update the second PR's target branch to main. Now when reviewers look at the PR, they'll see only the changes second introduced—no noise from the merged first.

Rebase deeper branches (third) with --fork-point

Once you've rebased second, its commit history changes. If third was branched from the old version of second, it's still holding onto all of first and second's commits. You can't just use --onto again because you need Git to figure out where third originally forked from the old second, even though those commit hashes no longer exist. That's where --fork-point comes in:

git fetch origin
git checkout feature/third
git rebase --onto origin/main --fork-point origin/feature/second
git push --force-with-lease

The --fork-point flag does the heavy lifting: it finds the point where third originally branched from second, traces through the rebasing that happened to second, and figures out which commits in third are actually new. Then it replays just those commits on top of main. The result is what you want—third now shows only the changes it introduced, not everything from first and second.

Why this matters

The real value here is keeping each PR's diff clean and focused. When reviewers look at a stacked PR, they can actually see what that specific branch contributed without wading through noise from previous merges. It's a small bit of bookkeeping, but it makes the difference between a review that's clear and one that's confusing.

The technique is straightforward, but it's worth understanding what's actually happening. A squash-merge creates a new commit that replaces an entire branch's history. Your stacked branches are still pointing at the old history. Rebasing with the right flags replays your branch's work on top of the new baseline, so everything stays clean and readable. It's one of those moments where knowing how Git thinks about commits—not branches or PRs, but commits—suddenly makes a workflow problem disappear.

Platform Engineering: Easy to Use, Hard to Mess Up

Tom Mango — Fri, 03 Oct 2025 18:33:09 +0000

We used to have a saying on Recharge's Platform Services team: It should be really easy to use and really hard to fuck up. As a team building a platform that allowed not only ourselves, but other engineering teams to quickly spin up services, it's easy to see why we said this so often.

This team didn't really start as a Capital-P "Platform" team in the general sense, though. It started as a team that built an eventing and serverless platform (the Event Bus), then built first-party services on top, and exposed those services for other teams to consume. After each service we built on the Event Bus, we updated the underlying patterns, we defined new golden paths, we improved observability, and we exposed more utilities (like API clients, storage abstractions, base Cloud Function classes, etc). These services were so successful (in terms of launching quickly, enabling quick iteration, and scaling fast) that other teams wanted to start building services on the Event Bus too.

At first, other teams would look at what was done previously, recreate the setup of a repo, and go forward. This worked great early on. Other teams were getting a lot of the benefits. A lot, but not all. Many guardrails to keep us on the golden paths were conventions based on internal team knowledge. Also, our team didn't stop evolving the Event Bus platform. So, drift set in between repos. And once drift sets in, it compounds.

If you're having to set up CI/CD, API clients, error handling, and logging with each new service repo, you will almost certainly have drift between service repos. This means if someone moves from one service repo to another, there are nuances that will inevitably bite them. This also goes for incident response. The more "sameness" between services, the smaller context people need to know to solve things. They aren't looking in different places for different things. They know what they're looking for because it's the same for every service.

You see, there's a difference between having a single team that owns their own platform and a Platform that is set up in a way to enable other teams. We had to evolve into a Capital-P "Platform" team.

What I Mean by Platform Engineering

I tend to think of Platform Engineering as building internal platforms for the delivery and lifecycle management of services. It's about codifying the golden paths and making the right way, the easy way. Or, making things really easy to use and really hard to fuck up.

But, Platform Engineering is a multiplier. It amplifies whatever patterns and practices you already have. If your service design patterns are solid, Platform Engineering makes them consistently excellent across all teams. If your patterns are poor, Platform Engineering just makes it easier to build bad services faster.

In practice, this means:

Standardization – Every service starts from the same baseline.
Self-Service – Spinning up a new service takes minutes, not weeks.
Guardrails, Not Gates – You can move fast, but you stay safe.
Enablement Over Enforcement – Developers spend their time on product logic, not boilerplate.
Ongoing Updates – Each service can easily be kept updated to get the latest improvements shared across the platform.

Without Platform Engineering, you're reinventing CI/CD, IAM, observability, and more for every new service. As anyone who's ever set up a CI/CD pipeline knows, even when you have a reference point, it takes iteration to get it right. The same goes for API clients, error handling and logging layers, normalized request/response structures. All of those are decisions and configuration that take time to set up and get working correctly. With Platform Engineering, you run something like service new object-cache and start writing business logic immediately.

The Options

What happened with the Platform Services team was not only typical, but healthy. It's how pragmatic teams in pragmatic engineering organizations evolve. Like that team, most teams I’ve seen in this situation face the same three choices:

Do nothing – Keep shipping, share one-off improvements between service repos, and fix problems as they come. Short-term velocity, long-term drag.
Temporary Monorepo – Pull everything together into a single monorepo, but organize features into macro services. Then, after things are standardized and well-defined, break them back out later with your Platform Engineering approach. A structured path, but risky if your monorepo isn't working well (more on this later).
Eventual Consistency – Keep repos separate, but invest in your Platform Engineering approach iteratively to make them eventually consistent: templates, shared modules, automation. This allows for an incremental approach but requires discipline.

The Spectrum

Whether you want to go with a temporary monorepo or stick with multiple service repos, you still need to put in the work. Both monorepo and multi-repo approaches can work, but they can both fail too.

A bad monorepo: slow CI, flaky tests, poor abstractions.
A good monorepo: fast pipelines, great patterns, consistent experience.
A bad multi-repo setup: drift and duplication.
A good multi-repo setup: standardized templates, automated propagation of improvements.

The difference? Good design patterns as the foundation. A bad monorepo amplifies poor abstractions and flaky patterns across all services, while a good one amplifies solid patterns consistently.

We saw this drift firsthand when someone created a function handler without using the existing base class and reimplemented a number of things incorrectly. This was found during an incident call and took time to understand. We went back and aligned it with the platform and made it harder to fuck up in the future with generated templates.

When a team spun up a service, we would take their questions and confusions, solve for them, then bring back improvements to the platform to benefit future services. This feedback loop is what turns either organizational approach from messy to manageable.

The Real Question

The question isn't whether to invest in Platform Engineering. It's how to get there. Consolidate first, or align incrementally? The answer depends on your commitment, team size, growth rate, and tolerance for disruption.

That said, a Platform Engineering approach isn't always the right answer. If your team is small enough that everyone can maintain shared context about patterns and practices, and you're not seeing people struggle with inconsistent implementations or step on each other during development, you might not need the formal separation and standardization yet.

More importantly, if you don't have solid service design patterns established, Platform Engineering might not be your first priority. You need that foundation first – otherwise you're just making it easier to consistently build the wrong thing.

With a sufficiently large organization, the Platform Engineering destination is the same: paved roads, golden paths, and engineers focused on building products instead of plumbing.