How to build quickly

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

If premature optimization is the root of all evils, totally disregarding it leads to painful refactoring.

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 feel that I need to build enough that the user is engaged with it.

I feel like those first explorers willing to try out a new thing are incredibly valuable and their attention should not be wasted on the outline, but they should be presented with the owl.

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 each one, I add more nested sub-tasks. The nesting keeps going until I end up with sort of leaf nodes that can be done without depending on other tasks. This gives me a nice visual of how complex some tasks are versus others.

I generally prototype and design the implementation at the same time, and having this outline gives me a place to "dump" tasks and other work I'll need to do later, and you do often encounter more work than you expect, so an outline makes it easier to find a good "parent" for the task. Having a big outline also lets me jump around from high-level design to low-level implementation easily as well, which you need if you're prototyping and trying to find the right shape for your solution.

It's great as a motivator too since I can see when I complete something big when I check off a parent task that has a lot of nested children.

I find a simple text file outline like this is so much more convenient than say an app or a web UI since I can just jump around the file and cut and paste outlined sections and indent or un-indent them to re-parent them. (Having to use something like JIRA to do this would be way too slow, especially when you're in a flow state.)

This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly.

By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless function, then pipe your data through a graph of these functions.

With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces because the state is all tangled up. Which slows you down.

It's surprising how very simple the individual components can be, even for very complex systems, when following this approach.

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 building quickly, the focus is on your attention/what’s most important, rather than traversing from the beginning to the end serially.

Great post!

[0] https://en.m.wikipedia.org/wiki/How_to_Read_a_Book

I'm not as much of an overhead strategist, but I do have a rule that I follow that matches this article: if I hesitate to start working on a problem because it seems too difficult, it's because that problem has not yet been broken into small enough parts.

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's blog is a now a dead link. Previous discussion: https://news.ycombinator.com/item?id=6993060).

This is a great article that summarizes a method I’ve already used for my work over the years. When writing a new project from scratch ill make a bunch of structure (defining modules, writing pseudo code) then start to fill things out piece by piece. Often times ill need to adjust the structure as I go but helps for building a mental model of a new project (at least for me)

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

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?

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

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

This 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 step where you prune some of the nodes to make the overall outline tighter as a final step before proceeding on building. But do not worry too much and cut nodes ruthlessly. Often times you can get stuck at this point if you think too much.

This reads like a strategy for creating filler content. If you have to write a school essay an outline helps you churn through all the BS. By contrast, when you try to write something meaningful almost all effort goes into two things (a) figuring out what you actually have to say and (b) finding the right words to express it. School essays are written by people who don't have anything to say. Intro fluff. Chapter one fluff. Conclusion fluff. It's not real writing. You can speedrun it because no thinking is involved.

The same applies to fluff software, but only to fluff software. If you have to create a page with a dozen buttons with a bunch of click handlers, hook those up to basic AJAX calls, then yes, you can speedrun that as well. Because it's extremely easy work that involves no thinking.

Many things in life are kind of mundane and tedious. Fake school work, taxes, cleaning, ironing, to give just a few examples. And having strategies to blast through that kind of work effectively is useful. But these strategies absolutely unhelpful when you're trying to do anything creative or difficult.

You can't write a great spy novel with an outline like: 'introduce spy character', 'successful mission 1 in present time', 'flash back to failed earlier mission', 'introduction of big bad guy', 'flash back to tragic backstory', 'spy gets assigned special mission only his handler knows about'. Filling out an outline like this produces an uninspired, boring, formulaic trash. You end up with bad airport reading, the equivalent of AI slop.

To give another example: PG spends MONTHS on a single essay. He is not bottlenecked by a missing outline. Speedrunning the wiring process doesn't help. Figuring out exactly what you want to say is the hard part. Putting words on paper is trivial in comparison.

loading bar = answering questions

outlining = asking questions

i think the education system encourages the loading bar style. we are taught how to answer questions. i think AI will push education more towards the second type where the emphasis on asking questions.

like in a tech interview, instead of asking you some leetcode puzzle, i will ask you to ask me questions about the subject to demonstrate your knowledge. kind of socratic style.

For my personal projects I use a very similar approach. However, I find this technique difficult to do with a group (more than 3 people).

For me, this approach works great with one enormous exception: I must already know exactly what I'm going to write about.

I have tried outlining my writing countless times. But inevitably, the real work of thinking meticulously comes with the writing itself. In composing prose at the finest level of detail, I discover the true shape of the topic through its nuance.

I always throw out my outlines, no matter how many times I have iterated on them. My high level thinking couldn't sufficiently understand the topic.

PG expressed this well: writing is thinking, at least for some of us.

I've been diving into the science of learning, and the blog author clearly knows their stuff. For those intrigued by this field, here are some fascinating concepts worth exploring:

Bloom's Taxonomy (absolute game-changer), Inquiry-Based Learning, Deep Cognitive Processing & Higher-Order Thinking (closely tied to Bloom's Taxonomy), Generation Effect & Testing Effect, Deliberate Practice, Interleaving, Metacognition, Cognitive Load Theory, Problem-Solving Techniques: First Principles Thinking, Second-Order Thinking, Socratic Questioning, 5 Whys, Inversion, Divide and Conquer

Each of these concepts can seriously level up your learning game. Happy googling/using llm!

There is the spirit of "divide and conquer" in this method. Which thing is good.

However, I do not know how to follow this advice: "DO NOT PERFECT AS YOU GO. This is a huge and common mistake" because, when you develop something critical and apply TDD, testing actually is a synonym of perfecting your approach to solving an issue. Not to mention that testing comes before code itself: it pushes you to think carefully, and come out with the best strategy before iterating any further.

This is just top-down design.

https://en.wikipedia.org/wiki/Bottom%E2%80%93up_and_top%E2%8...

I’m constantly amazed at how differently I learned to do things from my father than from school.

My father had all sorts of approaches similar to this, and it’s how I learned to write essays (outside-in) and research (inside-out), and which I later applied to programming. It made school trivial and fun, and it’s what I’m teaching my kids.

If you do Kotlin, the TODO() function is very useful.

I did something like that the first time I had to write a device driver, but I did it kind of stupidly.

It was in college and I had a part time job doing doing system administration and programming for the high energy physics department. They had an RX02 8" floppy drive that they wanted to use on their VAX 11/780 which was running Unix/32V and I was assigned to write the driver.

I basically started with a C file that just had empty functions for all the functions that I knew Unix expected a driver to have, and then started filling those functions with comments recording what I had figured out that they had to do.

Each started with just a few high level comments. Then I'd add more comments breaking those down, and so on, until I finally had all the information I'd need in there and could start coding.

That's when I then did something stupid. As I started implementing the things the comments described I replaced the comments with the code.

I got about half way through before I realized that I should adding the code below the comments rather than replacing the comments.

2 counterpoints

- if you are pushing technical boundaries you may need to prove something is achievable before you go back and do the comparatively easy stuff (build the website, set up the company etc.)

- As context switching creates a huge cognitive load it can be useful to create discrete chunks of work and not just jump around all the time.

This is almost a 100% "divide and conquer", but a good article with concrete examples.

Definition : "A divide-and-conquer algorithm recursively breaks down a problem into two or more sub-problems of the same or related type, until these become simple enough to be solved directly. The solutions to the sub-problems are then combined to give a solution to the original problem."

This sounds like a really good idea, but I wonder if it works when you are writing to think. Like when PG writes essays, could this work for that?

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.

I do that in a similar way. I start doing all parts at the same time, going back and forth until it’s done. It’s not a perfect approach though. Two downsides I sometimes encounter are: dependency, when most or some of the work or scope depends solely on perfecting another part, and if the work is complicated, you can get extremely overwhelmed to the point you don’t know where to start or even start at all.

After reading the article, it made me realise this is why Power Automate and most of those low-code platforms are inefficient as they force you to do things "loading bar" style.

Yet another word for "top-down" design.

I really prefer the "progressive JPEG" name for this method.

I call it “PDCA over progressive JPEG” method.

The most fascinating thing about human intellect is how we all land in the same places, we just give them different names upon discovery.

DO NOT PERFECT ANYTHING UNTIL DONE

without caring about quality AT ALL

I really need to master this. I spend absurd amounts of time thinking about the littlest things. It can take a long time for me to mentally accept that the code is fine and ready to be committed to the repository and published.

im gonna try this out over the coming weeks and report back

this could be the most powerful thread ive come across on HN

Sadly for me I don't find execution on a clear idea to be the problem most of the time in my work. It's choosing the right idea to execute on that's hard.

I wish it would work with actual building building projects…

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.

Well 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

Good advice, but it also depends on the size of the project. For a very large project you may have to do it in phases, i.e. start with a very high-level breakdown, and then proceed with phase 1 and park whole sub systems for later.

Really appreciate the bits in the article about identifying what is fundamental and correcting misevaluations.

Making an outline is also important for writing. However doing research also has its place. See this here https://cse.buffalo.edu/~rapaport/howtostudy.html#makeoutlin... (also previously discussed on HN)

I like this idea a lot! I’ll try it today. I think a version of this is how I, and most professionals(?) already work. But I do believe my process can be sharpened.

I think there's tremendous value in keeping and publishing the outline itself. I know this because I just spent a week turning a book back into an outline and discovered that there was a great demand for it.