as you found, you end up with a pileup of cars – you should be avoiding creating too many parallel work streams. there's no way it's faster in the long run
One of the wonderful things about working alone is you can take three weeks off without feeling any pressure to think about a problem set. No emails, no meetings, no pull requests to peek at.
The motivation always comes back around - and it really helps to avoid burnout.
There are numerous downsides though. Honestly it’s not “better” - but you take the wins where you can. Especially for pre-release work.
work on one PR at a time. parallel code writing is a sniff test, and it means you're probably not adequately defining your work.
move to a **process** in which you define specs, iterate on them and create tickets.
once the tickets are well defined, work on one at a time.
I learned many years ago to just let go when you aren’t motivated. No punishment, no self criticism, no wallowing. Just permission to have a break. If you do, it always circles back.
Wish I could take that lesson into greater life, but I’ll use it in my work nonetheless.
I've settled on a fairly powerful workflow while working on timber – my new framework.
At some point, I will share my lessons and write about it. But I've found that the more I try to push parallelization, the lazier I am being. One write-heavy work-stream at a time is plenty.
someone asked: "how are people dealing with claude code creating 20 goodish pr's in 10 minutes that then all trip over each other"
I fear that I am cooking 🧑🍳
either way, I'm going out with strong opinions