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

81–90 of 147 posts

Re: How to build quickly

#81

Post by jddj »

lelanthran wrote: post #77
ukuina wrote: post #37

Earlier quoted context omitted.

What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match?

> What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match? I use this tool: https://github.com/lelanthran/frame/blob/master/docs/FrameIn... It allows me to drop a node in the tree, dropping all children along with it. Or rename arbitrary nodes in the tree, or move them around.

This looks very cool, especially for hobby projects. I follow approximately the same flow with infinitely nested TODOs in logseq.

The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored.

Re: How to build quickly

#83

Post by idk1 »

What's interesting about this is, I have always done what the author describes and I just assumed when people wrote (for example) an essay, they would outline all the points and the structure first and then go and fill in each section and refine it over time. Same with ideas and projects, I would do rough outlines, then add fidelity. Same with programing, I'll make an outline and go and refine it all.

It's strange, I assumed this so strong I never thought anyone would ever start writing and essay from the beginning without considering more of it, similar to just starting projects or code, I guess they do and it works really well.

What's the break down of people's approches to things here, which bucket are you in?

Re: How to build quickly

#84

Post by smu »

idk1 wrote: post #83

What's interesting about this is, I have always done what the author describes and I just assumed when people wrote (for example) an essay, they would outline all the points and the structure first and then go and fill in each section and refine it over time. Same with ideas and projects, I would do rough outlines, then add fidelity. Same with programing, I'll make an outline and go and refine it all. It's strange, I…

As a hobby project, I started a market research/overview of the Belgian cybersecurity ecosystem [1].

This required me to write a lot more than before, although I've always enjoyed writing.

In the beginning, I wrote beginning -> end, with just a high outline in my mind. Now, I write bullets first and then expand into paragraphs. This has helped me write a lot quicker and I think the articles have become easier to read (which matters a lot online, where everyone reads diagonally).

[1] https://becyberscape.com

Re: How to build quickly

#85

Post by ghnws »

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

At least OpenAI creates more noise than useful output if you try to make it tackle a problem this way.

Re: How to build quickly

#86

Post by znkr »

teo_zero wrote: post #25

This is a good way to maximize speed. I'm not convinced it's also a good way to master quality. Rushing ("speedrunning") to a first working version may force you to choose sub-optimal paradigms (algorithms, data types, etc.) that you won't have the time or the will to correct later. I'd even postulate that's why we have so many crap applications today that are first on the market but slow, inefficient and user unfrie…

> I'd even postulate that's why we have so many crap applications today that are first on the market but slow, inefficient and user unfriendly.

That’s certainly one way to get a crappy application. Another way is to find optimal paradigms only to discover that the problem that needs to be solved has changed and now the optimal paradigms are technical debt that needs to be worked around.

Re: How to build quickly

#87

Post by dmvdoug »

jumploops wrote: post #3

This strategy can be applied to learning as well. The concepts are very similar to those presented in “How to Read a Book”[0]. The general gist is: create a mental outline of the book/material (via the table of contents), dive into interesting chapters, resurface to the outline, dive again, etc. This strategy is useful for quickly building a mental model and using your own interest as the guiding light. Similar to bu…

It’s just the hermeneutic circle at work, nothing magical.

Re: How to build quickly

#88

Post by dmvdoug »

And here I was, having been led to believe there’s No Silver Bullet. :(

Also lol at the comment that speedrunning and iteration lets you get the junk out of the way so you can really focus on where quality matters… a paragraph away from saying speedrun and iterate and then feel good about being 90% done while you sit around twiddling with the title bar styling.

Re: How to build quickly

#89

Post by lelanthran »

jddj wrote: post #81
lelanthran wrote: post #77

Earlier quoted context omitted.

> What do you do when an idea changes and now there are dozens of nested entries that need to be changed to match? I use this tool: https://github.com/lelanthran/frame/blob/master/docs/FrameIn... It allows me to drop a node in the tree, dropping all children along with it. Or rename arbitrary nodes in the tree, or move them around.

This looks very cool, especially for hobby projects. I follow approximately the same flow with infinitely nested TODOs in logseq. The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored.

> The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored.

It's a trade-off: aggressively pruning the noise leaves a lot of signal. I have also found that, when writing down goals/objectives/tasks/whatever, knowing in advance that they are going to be discarded once done makes them more focused on achieving the goal, rather than trying to document what is done.

Essentially, when adding nodes, I add directives to be filled, not documentation for what was done. This keeps me focused on achieving the goal without getting side-tracked by putting in explanatory documentation for future me.

The notes I make are to allow future me to implement $thing, not future me to understand $thing.

Post reply on HN