753 karma · joined March 16, 2009
Working on many things in parallel on the surface is very overwhelming.
So we need to start by creating a slow and intentional process for shipping high quality features (i.e. brainstorming documents, planning documents, todos, triage, multi-agent reviews, etc). Create your own, or use plugins like compound engineering/gsd/superpowers.
Compound engineering for example can take many minutes between each prompt as it explores and thinks. It creates great output (given strong input) at the cost of time, like any person would.
Once you have a process you like, it should be the equivalent of you pair coding with a better version of yourself.
Pair coding with one person at a time is not scalable.. I.e. trying to watch the changes and pair code with two people writing different features at the same time would be a nightmare.. and the same can be true with pair coding with a few agents in parallel.
So to leverage worktrees you need to shift your perspective of shipping a single feature, to managing the outcomes of many engineers.
Imagine each worktree is an engineer on your team, assign work the same way (i.e. no two worktrees should be working on exactly the same feature), then simply answer their questions/help them test their changes/provide feedback.
You only review code when the worktree agent has reviewed their own code enough times that they (Claude) are happy with the result and submit a PR. Then you review the code, just like any other person on your team. Ask for changes and back to testing.
AI makes code is cheap, your time is still valuable, so figuring out how to scale yourself is always going to be better than a tool that tries to scale for you.
Just wanted to share this quick video demonstrating the value of git worktrees with Claude code.
Start by slowing things down. Create a repeatable process for shipping high quality features - using plugins like compound engineering/gsd/superpowers.
Compound engineering for example can take many minutes between each prompt as it explores and thinks etc.. so all of the sudden you have time.
If you are working from a perspective of managing the outcomes of many agents instead of pair coding with one, it can dramatically alter your output.
Imagine each worktree is an engineer on your team, assign work the same way, help them test their changes and provide feedback. Only review code when they have reviewed enough times that they (Claude) are happy with the result and submit a PR. Only then do you review the code, just like any other person on your team. Ask for changes and back to testing.
Code is cheap, your time is valuable.
- https://github.com/gsd-build/get-shit-done - https://github.com/obra/superpowers - https://github.com/github/spec-kit
I personally haven't used them, but I think any process like these + worktrees is the serious pro-tip/unlock.
As the primary designer for a product, who can also implement the design - the amount of communication needed between design and engineering literally evaporates.
I tell my devs they can build an ugly v1 of any feature simply for the sake of speed, and I’ll go in after to clean it up and make it look consistent. they don’t need to waste time with CSS.
Design changes so often after implementation, that I don’t even keep a living design file, most changes happen directly in code. If I do need to design something as part of a pitch or meeting material I take a screen shot of the product and just modify that.
Having worked as only a designer, and then only as an engineer, I can’t express how much faster my team is when design is part of engineering.
Speed is most critical to startups, I’ve always found interviewing with startups and presenting this skill set is highly sought after when expressed properly.
Our platform analyzes events relevant to investors, company financials, and textual data to give investors an edge.
Our back end consists of Python and node based micro-services. We also utilize machine learning and big data to analyze equities and events, and to transcribe and analyze audio. We capture and re-broadcast audio via WebRTC, SIP, HLS, DASH. Our APIs are a mix of REST and GraphQL. We utilize Docker, AWS services, Terraform.
You may be a fit if:
* 3-5+ years of professional software development experience, ideally some of which was spent in a startup or fast-paced environment, but this is flexible for the right candidate * You enjoy thinking about systems design, and diving deep into the details * You are a self starter and can make decisions quickly * You have good communication skills and can support project stakeholders * You have experience working with Python, SQL, GraphQL, AWS, Docker, ElasticSearch * It would be amazing if you had WebRTC, SIP, telephony, experience, but is not required
reach out to elliot [at] aiera if you're interested!
Most places I've worked have a bug log? Priorities balance between new feature development and fixing bugs / tech debt. If a bug isn't high priority, or the feature it was about has been changed or removed, the bug might now be stale - but still exists in a list somewhere.
> The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
It's the opposite, it's saying that if the bug / issue isn't easy enough to be solved right then, it needs to be reported again later, or added to the official prioritized road map.
> What happens if the stakeholder's sanity runs out first?
This is a good question :)
This helps scale a team, and build a cohesive lightning fast unit.
I’ve worked with fantastic devs in the past who had no real understanding of this kind of “architecture”, and as a team the difference was clear.
Dark is a game changer in my opinion for getting a prototype online as quickly as possible, or a lightweight backend - and I imagine it can and will support much more.
Personally I feel the author’s final design is also a step backward - while I realize things have been “cleaned up”, a horizontal menu with that many options is too many - and they are not of equal value. The existing division is helpful based on real life use - not the authors idea of what looks good. I don’t need menu items I rarely touch given the same importantance of the ones I use daily - I don’t want to even accidentally read them - it wastes my time. Also, how quickly does this need an alternative solution for narrower screens? Lastly, the authors design is looks to me just like stack overflow - I don’t think it’s fair to say it’s any more modern than githubs current design which has strong and consistent visual language I appreciate as a benchmark for how other products could look and feel. Github looks like GitHub in every part of GitHub, and for me at least, that’s a good thing.
For Reddit, it's one of the biggest communities online (maybe the world?) - there are many ways to leverage and monetize that even if they haven't figured out all the optimal ways to do that yet, the perceived value is enough to convince investors in its future.