Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to build quickly

learnhowtolearn.org

Post reply on HN
Print view View original

41–50 of 147 posts

Re: How to build quickly

#41

Post by andrewstuart »

spencerchubb wrote: post #33
andrewstuart wrote: post #6

This 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.

"Speedrun" seems like odd advice, kinda like saying "Here's how you move faster: move faster".

Re: How to build quickly

#42

Post by throwaway63467 »

I think it’s often called the “tracer bullet principle” as well. Get a full version of your system working quickly from end to end, then improve each part incrementally. Powerful stuff indeed, also for your motivation and sense of accomplishment. Nothing sucks the joy out of work more than building and building and not getting any feedback.

Re: How to build quickly

#43

Post by tazu »

spencerchubb wrote: post #31

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

I'm pretty sure LLMs have to generate text left-to-right, but there was a screen recording floating around that had "multiple cursors" of text generation at once, where it looked like the LLM was filling in a grid of text, so to speak. I'll see if I can find it.

Re: How to build quickly

#44

Post by spencerchubb »

tazu wrote: post #43
spencerchubb wrote: post #31

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

I'm pretty sure LLMs have to generate text left-to-right, but there was a screen recording floating around that had "multiple cursors" of text generation at once, where it looked like the LLM was filling in a grid of text, so to speak. I'll see if I can find it.

There are LLMs that are trained to fill-in-the-middle, particularly code editing LLMs. There is nothing inherently required about left-to-right.

Re: How to build quickly

#45

Post by leetrout »

allenu wrote: post #29

This 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…

Similar here - i use asana or linear for highlevel planning with a calendar and then as I write code I drop in TODOs and FIXMEs and such then just grep them out or use a VS Code extension called "TODO Tree" to track them.

Re: How to build quickly

#46

Post by ziotom78 »

jimbokun wrote: post #18
ziotom78 wrote: post #2

Something similar to this is presented with much more details in Zerubavel's “The clockwork muse”, a highly recommended book.

Frankly, this article might be better because it's very short and encourages you to go out and put it into practice immediately. Which is arguably more valuable than reading an entire book to make the same point.

I wouldn't say that this article and the book just "make the same point". Zerubavel devotes an entire chapter to explain how to get a good estimate of the time required to complete the project, another chapter provides tips about how to track progress efficiently, etc.

Re: How to build quickly

#47

Post by gchamonlive »

kpw94 wrote: post #9

The author provides an example of the bad "Loading bar writing" but unfortunately not a good example of what they call "Outline speedrunning writing" pg, who's good at writing essays, does provide a good example of the latter, with https://byronm.com/13sentences.html . This is the writing process that lead to https://paulgraham.com/13sentences.html . (the https://code.stypi.com/hacks/13sentences?doomed=true URL on pg…

What I do for my blog is I write everything at once. Then I figure out where to put images, then I publish it!

It makes me go back and read it carefully since I have already published it, and then I polish, rewrite sections and add stuff that I missed.

Re: How to build quickly

#50

Post by darkteflon »

allenu wrote: post #29

This 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…

Same here. I wrote a little multitree-based TUI with vim-adjacent key bindings for exactly this purpose, since I find it generalises to all complex projects, software-related or not (and who can resist any excuse to write a TUI?), but a simple markdown file is just as good, really, and for software means you can keep it in the repo directly adjacent to other project docs.
Post reply on HN