Has anyone trained an LLM to do this? Start with high-level ideas, and recursively fill in more detail. As opposed to generating text left-to-right
How to build quickly
31–40 of 147 posts
Re: How to build quickly
#32In particular if you have to build on existing systems, a top-down approach doesn’t always work well, because the overall design may well depend on details of the existing parts you have to integrate with. In that case, starting with prototyping a vertical slice of the functionality can be the better approach.
Exactly. I've found that even with a greenfield project, there is the tension between keeping things simple and avoiding fully-engineering code so as to quickly get to an MVP, and the fact that code that is under-engineered is creating technical debt that becomes more ossified the more you build on top of it.
My current thinking on a solution to this conundrum is this: try to craft the best architecture and engineering you can up-front _vertically_, but drastically reduce the workload by paring things down _horizontally_.
Re: How to build quickly
#33This message is suspiciously like being told to draw the outline of an owl then draw the rest of the fucking owl. https://seths.blog/2014/01/how-to-draw-an-owl/ The word recursively does a lot of work in the post. Every project I go into thinking I can do it quick and it never works that way because the minimal viable or minimum lovable thing is a long way from the minimum actual concept of what I have in mind. I fee…
The post is meant for people who already know how to draw an owl, and want to draw owls quicker.
Re: How to build quickly
#34This really works. When I used to work at big tech, I had a reputation for being incredibly fast and this is the method I used. This is also one of the reasons why I never moved away from Workflowy as an outlining tool. Nothing else has come close to it. If I have to add one thing, it is that when you are recursively building your outline, it might grow really big and that might overwhelm you so I recommend a pruning…
Intrigued by your Workflowy mention. Any resources where I could learn your style of workflow with it?
Re: How to build quickly
#35This is just top-down design.
https://en.wikipedia.org/wiki/Bottom%E2%80%93up_and_top%E2%8...
Re: How to build quickly
#36This message is suspiciously like being told to draw the outline of an owl then draw the rest of the fucking owl. https://seths.blog/2014/01/how-to-draw-an-owl/ The word recursively does a lot of work in the post. Every project I go into thinking I can do it quick and it never works that way because the minimal viable or minimum lovable thing is a long way from the minimum actual concept of what I have in mind. I fee…
The post is meant for people who already know how to draw an owl, and want to draw owls quicker.
owl drawing speedruns
Re: How to build quickly
#37This is how I work on my projects as an indie dev. When I start working on something significant (a new feature, for instance), I'll create a markdown file that has a summary of what I'm trying to achieve and then a TODOs section which turns into this massive outline of all the tasks that I'll need to do to complete the work. At first, the outline just has a few tasks that are fairly high-level, but as I dive into ea…
What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match?
Re: How to build quickly
#38This really works. When I used to work at big tech, I had a reputation for being incredibly fast and this is the method I used. This is also one of the reasons why I never moved away from Workflowy as an outlining tool. Nothing else has come close to it. If I have to add one thing, it is that when you are recursively building your outline, it might grow really big and that might overwhelm you so I recommend a pruning…
Intrigued by your Workflowy mention. Any resources where I could learn your style of workflow with it?
Honestly I keep things pretty simple. Just the fast outlining features and the "mirror"[1] is what I use the most to mirror the current "speedrun" on the top level for next day so when I come in I don't worry about what to start.
Re: How to build quickly
#39This is how I work on my projects as an indie dev. When I start working on something significant (a new feature, for instance), I'll create a markdown file that has a summary of what I'm trying to achieve and then a TODOs section which turns into this massive outline of all the tasks that I'll need to do to complete the work. At first, the outline just has a few tasks that are fairly high-level, but as I dive into ea…
What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match?
Generally, with this type of work (where I'm trying to go fast), I have to be flexible, so I will often just let nested tasks "die off" after I've found alternative ways of solving the problem or I've changed the idea a bit.
Sometimes I'll delete the nested entries outright, but usually I'll just keep them around until I get to a point where I'm close to completing the feature and then I'll re-visit them to see if they still apply or if I need to reincorporate them into the new design.
Re: How to build quickly
#40Well explained, people always ask how I get projects done so fast over the weekend, but i haven't really been able to explain.
this is bascially how i do it if you look at my notion doc for the idea, and the first commits of the codebase