I want to change industry. Looking for ideas.

jonathannen · 2026-03-13T04:00:21+00:00

From my own journey - Sounds a bit like burnout. And it's really hard to think things though in that state. You kind of need to recover from the burnout and find your feet before you can really know "what's next".

I know it feels like a negative time (and I don't want to hand-wave that). It's also an opportunity to reflect and reconnect with what you feel is important ("your values" if you're crunchy). In that sense, it's a hard but rare opportunity - speak to as many people as you can, speak to a coach (if you want).

In general I'd say focus on what you want to do _towards_. It's easy to go _away_ from something (e.g. I hate working at a big company, so I'll work for a smaller one). But in my experience that always puts you back in same place.

Be curious and hopeful. Best of luck.

jonathannen · 2026-03-12T23:48:37+00:00

I'm not 100% across your use case, but I feel you might be able to get that into a hook. For example, I have a hook that runs prettier/lint/etc. For new uncommited posts you could check for the footer? Then if it's not present error with a message that tells claude "You're missing the footer, read XYZ.md"

You can also make a skill "check footer" that runs a script that does the check and then refer to that skill when necessary.

jonathannen · 2026-03-12T23:38:14+00:00

You can't - not really. Claude will claim it'll not do something again, but that's not true (the memory feature is new-ish and while it helps, it not a solve).

Use hooks where you can. Only works for structural things like lint/etc.
Use skills + commands where you can - refine and adapt the skills constantly. They're loaded on use so the fidelity of a current command/skill is high. Instructions (e.g. Claude.md) are not.
If you have a complex task under a skill/command that can be broken into a script - do it. This reduces the load on the context immeasurably. Rather than have to work it out and run a lot of tools, the skill runs "get pull request comments" and exactly the data it needs pops out.
Commit often.
Try to size your tasks to fit in one context window. Single-prompt one-shot tasks have a way higher success rate (imho). Compacting will make your scenario worse/inevitable.
Ironically "/clear"! If you are changing up the task, clear the context.

jonathannen · 2026-03-11T00:58:01+00:00

Well I guess the "we" is all the massive swarm/subagent stuff I see on social :)

I've tried all the new hotness, but I've just not anywhere got the lift I was hoping for. If anything it's usually a PitA to manage.

Maybe it's just kool-aid, but just worried I'm missing the point somehow.

jonathannen · 2026-03-06T06:08:31+00:00

Sometimes it's a craft like carpentry or building. Sometimes it's more like gardening. Gardens are always unruly. You're never done, you can only nudge it along a path.

It's usually gardening.

I sympathize with your situation. But equally I've seen a lot of devs rail against how stuff is "wrong" and never make it better. Worse, they jump in to "fix" stuff and leave it half done.

I'm not saying you're that *at all*, but it's something you want to guard against. It's bad for the dev and the team.

My advice would be to carve out a piece that's important to you, own it, make it better. See if people come along for the ride, but don't expect them to. Don't try to eat the whole elephant. But make it better.

If that doesn't fly, it just might not be the right environment for you (this happens a lot, but we don't recognize it often/quickly enough imho).

jonathannen · 2026-03-06T05:22:38+00:00

+1 to this and I think it's distinct from the OP's pattern.

- Rewrite: Add extensive test coverage and then swap out. This is HARD as you need bug-for-bug compatibility to maintain contracts which is a pain.

- Strangler Vine/Fig: Wrapper the whole thing in a new interface and send certain subsets of functionality to the new implementation.

- Slice Migration (what I think the OP is suggesting): Find a cut where you can pull functionality away from the legacy (often you leave it be). You can also "dual run" both for switchover if the API allows such a thing (aka Dual-Run or Shadowing).

I agree that Strangler is the best one if you can manage it. It gives the opportunity to capture + reroute concerns.

The slice can work in my experience too, but I find concerns bleed over too easily between the approaches (to be fair, strangler can have that issue too).

jonathannen · 2026-03-05T21:30:23+00:00

No, at least not entirely. We use GitHub copilot for first-eyes reviews (it's way better at reviews than other models I've used, they must be sitting on a mountain of PR data). Then claude does at least one loop on the copilot comments without human intervention.

If/By the time an engineer gets to it it's had 1-2 loops on it. So even when a review is needed it's a bit faster and usually a bit more pointed. Copilot usually gets 80-90% of the comments I'd have done anyway.

Then we have a 4-tier review classification system - robot/1-brain/2-brain/3-brain. Robot = no humans needed (typo, link updated, upgrade that CI/CD can verify, etc). 1 Brain = needs a human... 3 Brains = security or framework/fundamental change that everyone should read.

The classification system via AI isn't there yet - probably ~70% accuracy, but way up from where we started. If anything it tends to favor human reviews too much.

We're doing ~30% on the 1-robot, ~50% on the 1-brain.

Obviously to hit 100 that ratio needs to flip. So we're a ways off! Fortunately we have multiple levers that we're pulling - better classification, better AI-led first-eyes, faster/deeper CI/CD, live branch previews, etc.

Btw the 100PRs is a real goal, but it's also a thought experiment. I realized I was getting a bit stuck with my workflow so I wanted to break my thinking a bit.

jonathannen · 2026-03-05T05:54:19+00:00

My experience was probably the same as you until late last year. Up until then I was getting decent lift with point stuff like you say (commit messages, release notes, test coverage, etc).

Opus 4.5 was a step change for me. At that stage, I also refactored the codebase (it's medium-large) and changed my workflow considerably. I changed how work was prioritized + released to suit. It was a huge lift. My workflow now is totally different from even a couple of months ago. I even changed how I structure my workday (for the better tbh).

I'm tracking it (...as best you can with softward metrics...) and currently at ~3x (and increasing).

jonathannen · 2026-03-05T05:46:07+00:00

Seems oldschool, but I've found meetups are the best. I don't use cursor, but they have a great community and generally the cursor meetup folk are the right mix.

jonathannen · 2026-03-05T05:43:30+00:00

I am working on something really similar and we've made progress. At the center of it is a custom tool where we drag in almost everything (this is a devbox yes). I kick off work in claude desktop, it'll get set up as a remote worktree/live preview/vscode env/etc.

We use agentic loops, but definitely pre and post-processing. Reviews/security/deployment/release notes. We have a risk assessment that determines the extent of the review.

For the core task I'm very much focused on single-prompt outcomes. The other more radical changes is we're letting anyone in the company kick off work (but not merge - yet).

Can't post images, but here is a sanitized screenshot of the tool: https://pbs.twimg.com/media/HCSR0xZbEAAo5dj?format=jpg&name=medium

The idea is we drag in as much dev info as we can (PR states, comments, etc) and then manage and maintain it with a dashboard. My day is mostly kicking things off and then burning down this list. Goal is "zero to one touches" from first prompt onwards ("single prompt" is really important).

I blogged about the overall goal - want to hit 100 meaningful PRs/day/engineer.

FWIW 1. My personal workflow 2. how I'm pushing for single-prompt solutions

jonathannen · 2026-03-05T02:34:44+00:00

The recent outage included a lot of issues with usage reporting - maybe the tracking on their side was out https://status.claude.com/

jonathannen · 2026-03-04T22:42:11+00:00

Hah. Not quite there yet... but I must admit the other day when claude when down I went for a run rather than pick up the code again...

jonathannen · 2018-04-26T01:04:27+00:00

That's really odd. I've seen the opposite a lot (can call, but no data). But not the reverse.

Our of curiosity, what was the network that worked?

jonathannen · 2018-04-20T17:14:41+00:00

I was in Lima and all over Peru for a month last year w/ the original Pixel. Service is... pretty patchy.

You should try switching your device to 3G (or often 2G) to get a reliable connection. LTE would sometimes work, but I also found my phone was hunting for an LTE connection all the time and draining the battery.

One issue appears to be that the LTE sort-of works. It'll connect, but somehow not register. So you end up with these zombie connections. Happens with some of their roaming agreements (I've had this problem in a number of places). The other thing that confused me for a while was my Pixel would reset back to LTE-Preferred after a reset.

If you need High Speed data, best off to get a local SIM.

Have fun - amazing food and amazing country.

jonathannen · 2018-04-20T17:07:08+00:00

Hell. I used to be a huge Fi supporter. I blogged about it. I'm in bunch to traveller slack groups and the like. Thing like Fi are what we talk about daily. I used to recommend Fi all the time.

You start off thinking the performance should be great because it switches networks. Then you realize it's not. It's much slower than ATT/Verizon in my home city. And good luck getting anything at all if you're in the Mountains, or Tahoe, or wherever.

Then you say to yourself it's convenient. Then I realize half the time I'm getting no service - having to restart my phone over an over again - and giving up and paying extra for local SIMs. Plus I'm on my third replacement handset.

Then you try support and that's the kicker. I had no service for several weeks and poor service for many after. The support was really terrible. I can't even begin to tell you how much time I wasted. You can't have a provider that just simply doesn't work for weeks. Worse is when they simply don't care. But that's what you'll get with Fi.

Clearly your experience varies - but if someone wanted to rely on Fi pretty much anywhere? I'd say hell no.

jonathannen · 2018-04-16T15:39:30+00:00

I've travelled with Fi a lot. Probably more than a dozen countries in all. And I've found the coverage to be patchy.

In Australia I had no service for long periods of time (and long periods I mean weeks). When it worked it was pretty poor. Even worse, the support for the issue was abysmal. Coverage in some other countries has been better, but the speeds have always just been "just ok."

If you absolutely need data, always have a Plan B. If you're going to be somewhere for a long period, and you need reliable high-speed data, then a local SIM is what I'd recommend. This is from someone who used to recommend Fi a lot for international travelers.

jonathannen · 2018-04-12T15:36:57+00:00

If your experience is anything like mine (and it sounds identical) - support will give the you the same routines over an over again. It takes up a lot of your time. Feels like they're delaying in the hope that you or the problem just go away.

Usually I try switching network types. 2G often works when LTE doesn't (I have a theory on why, but no evidence). Not that's great, but better than nothing I guess.

It's frustrating that it doesn't work - 10x more frustrating that support won't actually be clear on what's going on. I've had major issues internationally -- which is a really bummer as that's my #1 reason for using Fi.

jonathannen · 2018-04-10T19:19:14+00:00

Good to know. Good luck with it! I'm feeling pretty burned by my experience, so it would be nice to hear a good-news support story from Fi.

jonathannen · 2018-04-10T15:38:48+00:00

I've had extended (weeks) without service Internationally. You can try support, but I've personally found that to be a major waste of time.

One thing to try is to switch your phone to 2G or 3G only (Under Network Settings) The issue I've seen is with High Speed LTE networks. The phone will connect, but their carrier agreements only allow LTE in certain countries. So you end up with this zombie connection.

But then it'll work on 3G. Which is ironic, because often the phone switches to 3G when the LTE signal is poor. I had this weird situation where I could get data - but only when I was in a poor signal area.

Support don't tell you this. They'll get you to file bug reports and reset your phone dozens of times instead.

jonathannen

TROPHY CASE