But worktrees have some significant limitations. Not least of which is that their dependence on hardcoded fully-qualified paths written into configuration files not only makes worktrees non-portable, but also makes them DOA for any kind of containerized development environment. The worktree.useRelativePaths option helps here, but as of this writing it’s still relatively brand-new (Git v2.48 released Q1 2025), and not available in the version of git you probably have installed on your host machine or any of your container images. On top of that, VSCode’s support for relative worktrees with devcontainers is experimental, totally undocumented, and (as of this writing) unreliable at best.

Here’s what I didn’t realize until this week: you don’t need worktrees at all!

It’s 2026. Internet bandwidth is fast and disk space is cheap. But! Guess what: you don’t even need to fill up your disk with duplicate repos, or wait for lengthy git clone operations from origin every time you need a new branch-dedicated workspace.

That’s because when you do a local clone:

git clone my-project my-project.my-branch-a
git clone my-project my-project.my-branch-b

…not only is it near-instantaneous, it also doesn’t take up significantly more disk space! Why? Because by default, Git makes hard links for the object files when locally cloning a repo! Object files are immutable hunks of history, so there’s no reason not to share them across repositories on the same volume.

You’ll need to do a little bit more than this: you’ll also want to rewrite the new clone’s origin remote to point to the original origin rather than the source directory. I tasked a robot with making me some git-extension convenience scripts, so for instance I can exec git bc-add my-project my-branch-name to clone, massage remotes, and either checkout or create the branch in one command. You can do whatever streamlining makes the most sense for your process.

The important part is that local git clones are fast and cheap. So don’t worry about worktrees. Just clone and get coding!

1. Make a request, look at the result.

Testing React et al:

1. Make a request.
2. Receive HTML.
3. Ignore it!
4. It also contains a string.
5. The string is attached to a bird
6. The bird speaks latin
7. Find an antiquities professor
8. He can distract the bird
9. While you build a fake browser

With apologies to Penny Arcade

Back in 2017 Slava Akhmechet wrote a post-mortem on the RethinkDB project:

If you do set out to build a developer tools company, tread carefully. The market is filled with good alternatives. User expectations are high and prices are low. Think deeply about the value you’re offering to the customer. Remember – wanting the world to be a certain way doesn’t make it so.

As a veteran of a developer tools startup, my view of that market is similarly jaundiced.

Every hacker has a great idea idea for a developer tools startup at some point. But it’s a tough market to succeed in.

• It’s just not as big a market as you think it is. Yes, there is gobs of money in the software industry as a whole. But the money available for tools servicing that industry is orders of magnitude smaller.
• Other shops’ pain points are less similar to yours than you think.
• Everyone looks at your great idea and thinks “oh, I could do that internally, it’s just a simple matter of coding”. The fact that they are wrong does nothing for your bottom line.
• The more desperately a company needs your tools, the more peculiar will be their ball of legacy code and the more unexpected and non-standard will be their workflows. You will dump hundreds of hours into supporting these hard cases, in order to have compelling success stories. But most of that work won’t translate into supporting the next special snowflake.
• The gulf is deceptively wide between “that’s a really cool idea!” and “I’m going to invest time and energy into incorporating it into our processes.”
• If the idea really has legs, the proof will be that established developer tools companies copy it and commoditize it and it becomes part of the new baseline of tools. Which most likely leaves you back at square one, hopefully having sold your technology to a enterprise dev tool company before the market for it tanked. Of course, if the commoditization happens in the form of a really great Open Source alternative, even that exit may not be an option.

(This article was adapted from a SIGAVDI email from January 2017.)

She makes bracelets. Except sometimes they turn out too short. They turn out to be… keychains, instead.

A couple weeks ago I saw Joel Drapper announce his strict_ivars gem, and I got really excited. I loved the concept. But I immediately thought of my own spin on it. Mostly, I wanted it to generate warnings instead of exceptions. I also wanted to solve the “repetitive initializer” problem at the same time.

It got my wheels spinning in a way they haven’t in a long time. Here was a Ruby metaprogramming problem I could sink my teeth into! It would be fun. It would recruit skills I don’t get to use very often. It could be useful for other people!

I sank a lot of time I really couldn’t spare into the project. I knew if I didn’t turn something out quickly I’d never release anything at all. To work faster I leveraged an LLM assistant to be my hands. I solved some of the trickiest Ruby metaprogramming problems I’ve ever seen, which is saying something. (Have you ever tried to locate the Method object for the original definition of a method that has been hidden behind a prepended module?)

I finished it enough to at least demonstrate the functionality I’d intended, and I released it.

I’d told Joel I was inspired by his work, and after my release he did an excellent, gracious, in-depth technical comparison of the two gems. It turns out he’s building on some tech I hadn’t even heard of (embarrassing!). He pointed out a number of shortcomings in my approach that I hadn’t thought through. Issues baked into the architecture that aren’t easily fixed.

I wanted to make a friendship bracelet. But it turned out that I’d made a keychain. Realizing I’d made a keychain felt embarrassing. I felt exposed. I felt old and busted and shown-up.

The truth is I still put a lot of pride into being Very Good At Ruby. I cling to that pride, sometimes. I want to show that I’ve “still got it”. In a life drowned in caregiving and homemaking and survival, I often feel like I’m vanishing. Like I have so much still to offer, if only—and then there is screaming from another room, and I must defuse a meltdown, or mediate an argument, or make a belated dinner, or chase down a meds prescription, or or or…

And then of course there is the actual consulting work and content work that keeps a roof over our heads. But it is not always technically engaging.

To me there’s not much more alluring and aspirational than being able to buckle down to some really abstruse coding problem and come up with something shiny and cool to show other people.

I feel bad for not initially understanding Joel’s approach better. I feel bad for positioning something less-well-thought-out as an alternative. And I feel a little foolish. But it’s OK to feel foolish.

I need to accept that my life doesn’t presently offer the time for getting bracelets right, and there’s no getting around that.

I learned things though. I learned about Prism, and about TracePoint, and more about how to work successfully with a coding agent while I’m chopping onions.

I don’t think anyone should use ivar in production. I’m planning on pulling it from Rubygems, and I’ll recommend strict_ivars in its place.

I was tempted to pull down the repo as well, out of embarrassment. But I think I’ll leave it up, because there are some interesting metaprogramming examples in there.

Use the Table Data Gateway pattern for this class

It did as it was told, perfectly, the first time. This is not something I could tell a junior without a great deal more hand-holding. It instantly understood me, because uncounted millions of lines of code and writing-about-code are baked into its probability matrix.

On the other hand, no matter how many times I refactor the agent’s work, or tell it how to refactor its own work, it will never learn from that experience. It will never get better than it is. It will never grow in taste and instincts.

Today’s coding agents aren’t like “working with a junior”. They are like working with Jason Bourne, or Charly Baltimore from The Long Kiss Goodnight. They are amnesiac spies, who have a “very particular set of skills” but can’t remember any of them until circumstances prompt them to throw a knife, or to remember every license plate in a parking lot. Nor can they form new memories, except in the most superficial ways: they are always the same idiot savant.

Postscript: Unlike a spy though, the agent is terrible at getting itself out of sticky situations. If it can’t “figure out” (pattern-match) why a test is failing it’ll add more and more code and eventually slime the tests. Even if I’ve explicitly forbidden them to do that. This is a situation in which it shows its lack of self-awareness—another trait that makes it distinctly un-junior-like.

(I think the original post syndicated to the fediverse a little wonky so I’m re-linking it)

fascists would rather we pay less attention to external facts (which they are lying to us about) and more attention to our feelings, because those are so easy to manipulate

It is always a good idea to read Amy Newell, but *especially* now.

Source: Facts, feelings, and fascism – by Amy Isikoff Newell