[HN Gopher] How to build quickly
___________________________________________________________________
How to build quickly
Author : fagnerbrack
Score : 187 points
Date : 2024-08-03 19:05 UTC (3 hours ago)
(HTM) web link (learnhowtolearn.org)
(TXT) w3m dump (learnhowtolearn.org)
| ziotom78 wrote:
| Something similar to this is presented with much more details in
| Zerubavel's "The clockwork muse", a highly recommended book.
| jimbokun wrote:
| 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.
| ziotom78 wrote:
| 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.
| jumploops wrote:
| 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
| TechDebtDevin wrote:
| How to Read a Book, is ironically one of my favorite books.
|
| I attribute a lot of my ability to learn to this book and a
| teacher in high school that forced us to read and understand
| it.
| sourcepluck wrote:
| Can you explain the irony there? I don't get it.
| Vinnl wrote:
| Presumably they had to read it without knowing how to read
| a book, and yet they were still able to appreciate it.
| nrvn wrote:
| In the top directory of my improvised library of electronic
| books, papers and pdf prints of valuable web pages there are
| three uncategorized files:
|
| - How to read a book by Adler
|
| - How to read a paper[0]
|
| - How to study[1]
|
| Serves as an entrypoint and gatekeeper. Reminds me every time
| how to spend my time effectively there.
|
| [0] http://ccr.sigcomm.org/online/files/p83-keshavA.pdf
|
| [1] https://cse.buffalo.edu/~rapaport/howtostudy.html
| bckr wrote:
| 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.
| andrewstuart wrote:
| 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.
| bdcravens wrote:
| It feels like the article is describing how to draw an owl, but
| in reverse. You know what the owl should look like, and you
| simplify all the way down until each step is little more than a
| tiny pencil mark.
| alehlopeh wrote:
| The first explorers will to try a new thing, as you say, will
| also be quick to try the next new thing. So they're probably
| less valuable than you'd expect.
| yard2010 wrote:
| Just like that episode in SpongeBob in which SpongeBob tries to
| teach Squidward how to draw a perfect face.
| spencerchubb wrote:
| The post is meant for people who already know how to draw an
| owl, and want to draw owls quicker.
| frostsnap wrote:
| owl drawing speedruns
| andrewstuart wrote:
| "Speedrun" seems like odd advice, kinda like saying "Here's
| how you move faster: move faster".
| captainkrtek wrote:
| 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)
| 3abiton wrote:
| Do you mind sharing a concrete example of one your project s?
| captainkrtek wrote:
| Nothing open source specifically to share, if you were
| looking for that kind of concrete example.
| kpw94 wrote:
| 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).
| jimbokun wrote:
| The other provides a very good example in one of the video
| illustrations, with the left hand side showing "loading bar"
| writing and right hand side simultaneously showing "outline
| speed running" writing.
| gchamonlive wrote:
| 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.
| burakemir wrote:
| 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)
| tbm57 wrote:
| 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.
| theZilber wrote:
| I agree, I follow the same principle. Also i would like to
| extend it to - "if you slow down when working on a problem, you
| might have stumbled upon something unexpected, identify it, and
| break it down.
| layer8 wrote:
| I tend to hesitate because I know exactly that it will be a lot
| of long and difficult work to break everything up into small
| enough parts, of which there will be many, and work through
| them and integrate them all.
| jimbokun wrote:
| 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.
| ilrwbwrkhv wrote:
| 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.
| karolist wrote:
| Intrigued by your Workflowy mention. Any resources where I
| could learn your style of workflow with it?
| ilrwbwrkhv wrote:
| 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.
|
| [1] https://workflowy.com/feature/mirrors/
| nrvn wrote:
| 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.
| teo_zero wrote:
| 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.
| lee wrote:
| I think it's the opposite. I think quality often comes from
| evolution and iteration.
|
| There've been so many projects where I get stuck because I want
| to maximize quality, so I get writer's block. The worse, is
| that sometimes you'll try to perfect something on your project
| that ultimately isn't of great value.
|
| Building something quickly, and then iterating to perfect it
| seems to work for many people.
| gamerDude wrote:
| Yes, but at the beginning you can't be totally sure that what
| you are building is right thing to build or the money/resources
| to be slow.
| allenu wrote:
| 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.)
| ukuina wrote:
| What do you do when an idea changes and now there are dozens of
| nested entries that need to be changed to match?
| allenu wrote:
| 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.
| leetrout wrote:
| 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.
| layer8 wrote:
| 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.
| prmph wrote:
| 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_.
| spencerchubb wrote:
| 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
| tazu wrote:
| 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.
| spencerchubb wrote:
| There are LLMs that are trained to fill-in-the-middle,
| particularly code editing LLMs. There is nothing inherently
| required about left-to-right.
| amelius wrote:
| This is just top-down design.
|
| https://en.wikipedia.org/wiki/Bottom%E2%80%93up_and_top%E2%8...
| dangoodmanUT wrote:
| 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
| throwaway63467 wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-03 23:00 UTC)