I've yet to come across something with vim bindings that lacks a .vimrc where you can map 'jk'. Either way, switching back to ESC is as annoying as it is in the first place.
I did an exhaustive comparison of window managers and settled on using Raycast for simple resizing (full screen, center, mid-size centered, 1/2, 1/3, 2/3 left/right) + FlashSpace[1], which implements simple virtual spaces with instant switching.
You can also use Rectangle or Spectacle or others in place of Raycast.
+1 for FlashSpace. I used to be an i3 user and MacOS workspace management drove me mad. For years we had TotalSpaces, but that is no longer being maintained. With FlashSpace I finally have a great setup.
My solution has been binding a key Hyper+[a-z] for my applications. When used in conjuction with FlashSpace I get a usable setup. I also heavily rely on native MacOS binding Cmd+` (backtick) to cycle the currently focused application, and mission control for the current workspace.
Let me know if this is interesting; I've been considering creating a YouTube-video about this setup.
According to the meter, I used $15k in tokens with my Max plan (along with $5k of Codex tokens) in the last 30 days. That built an entire working and (lightly) optimized language, parser, compiler, runtime toolchain among other things.
If you're running the 4k display at 1440p, I'd agreed. But I run two 4k 60hz displays on a 16" MacBook Pro work laptop at 2880x1440 effective resolution and it looks fine to me. Yes, it doesn't look as good as the Studio Display I have on my personal Mac. But even though I have the MacBook Pro screen right next to the 27" monitors, I just don't notice the difference as I switch between them all day long.
I'm not saying there is no difference. But I suspect how one reacts to it is highly dependent on the person. I wear glasses that aren't perfectly focused for either screen, but they're good enough to get the job done - and mostly importantly, I get to use my two 4k 27" monitors to give me the same effective resolution as a Studio Display at far less money than two Studio Displays.
Ah, thanks so much for this question. I ended up building a tool that agent can use to track 'compounding' in my corpus of .markdown files. Keep iterating and thinking about it, and you may find you can do the same for your process.
It's too early. People are trying all of the above. I use all of the above, specifically:
- A well-structured folder of markdown files that I constantly garden. Every sub-folder has a README. Every files has metadata in front-matter. I point new sessions at the entry point to this documentation. Constantly run agents that clean up dead references, update out of date information, etc. Build scripts that deterministically find broken links. It's an ongoing battle.
- A "continuation prompt" skill, that prompts the agent to collect all relevant context for another agent to continue
- Judicious usage of "memory"
- Structured systems made out of skills like GSD (Get Shit Done)
- Systems of "quality gate" hooks and test harnesses
For all of these, I have the agent set them up and manage them, but I've yet to find a context-management system that just works. I don't think we understand the "physics" of context management yet.
On your first point, one unexpected side effect I’ve noticed is that in an effort to offload my thinking to an agent, I often end up just doing the thinking myself. It’s a surprisingly effective antidote to writer’s block… a similar effect to journaling, and a good reason why people feel weird about sharing their prompts.
Came here to say something similar. For me, the craft aspect is now even more exciting because I can craft more ambitious things without getting bogged down in the details. For me, refining my conceptual model, drawing diagrams, finding the right way to think about something was the craft.
Maybe that's another way of saying: I was trained as a designer, and now the distinction between design (read: architecture, service-design, product, ux, cx) and programming is blurring.
Heck yeah! Love that way of putting it. Agree. Now there’s more time to focus on making the right architecture and carrying it out. It’s no longer a days long task to do a big refactor to remove code smells.
reply