Live data from Hacker News

How to build quickly

learnhowtolearn.org

21–30 of 147 posts

Re: How to build quickly

#21
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.

Re: How to build quickly

#22

Earlier quoted context omitted.

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.

Can you explain the irony there? I don't get it.

Presumably they had to read it without knowing how to read a book, and yet they were still able to appreciate it.

Re: How to build quickly

#23
post #12

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.

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.

Re: How to build quickly

#24
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.

Re: How to build quickly

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

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

Re: How to build quickly

#26
post #12

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.

I tend to hesitate because I know exactly that it will be a lot of long and difficult work to break everything down into small enough parts, of which there will be a whole lot, and work through them and integrate them all.

Re: How to build quickly

#27

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

Re: How to build quickly

#28

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…

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.

Re: How to build quickly

#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 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.)

Re: How to build quickly

#30
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.
Post reply on HN