Amazing read
How to build quickly
131–140 of 147 posts
Re: How to build quickly
#132This is great. Top-down break down followed by bottom-up building. Resonates of the approach advocated by Paul Graham for building software in the book On Lisp.
Re: How to build quickly
#133I have already been doing this. My problem is that I somehow obsess too much over the Outlinining and by the time I come to filling in the outlines, I lose steam at about 30%-40% completion mark.
Then, it feels very boring to finish up the filling of outlines and I get a feeling that dragging myself over a bed of gravel is easier than finishing up the whole thing.
Re: How to build quickly
#134There are a few missing steps:
3b. Realize that your outline is wrong. You did not fully understand the problem when you wrote it. Go back to step 1.
5. Realize that you are never completely done. You will not go back and perfect.
The result is... better than not making an outline, but it's hardly a game-changing approach.
I'm reminded of something that Mike Bloomberg wrote in his book: Make a detailed plan for your work. Write down every detail until you're satisfied that you know how to proceed. Then throw the plan away, because it is now worthless.
Re: How to build quickly
#135summary: do some sort of breadth-first, remember "premature optimization is the root of all evil"
Re: How to build quickly
#136I don't promote often enough, but my writing platform is basically built for working this way: https://gingkowriter.com (came up with the concept when struggling to write my PhD thesis) Hope it helps!
Maybe you should, I was trying to find this for weeks now after first seeing and then forgetting the name :)
Re: How to build quickly
#137This 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…
To tack on to the other responses, this is just good programming. The testability/maintainability/extendability tenets push you to write small pieces of functionality before wiring it all together.
Re: How to build quickly
#138Earlier quoted context omitted.
Sounds interesting. Can you provide some more examples?
Delaney - I second this. Can you write a book on this? Blog posts. Podcasts? I’d read/listen to them all.
I think the book is "How to Solve It" by Polya, I mean it. The skills are transferable.
Re: How to build quickly
#139This 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…
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.
Of course you can. I don't know why people think you can't write functions that don't change a global state in any programming language. Pretty much any experienced programmer does that whenever they can.
Re: How to build quickly
#140This is top-down design presented as slapdashery-as-a-virtue.
Except you can also do top down design without the slapdashery, and it will usually be equally fast and a lot better.
I agree about top-down design vs "progress-bar" design though (I do like this term!).
But of course, there's nothing stopping you from creating slapdash progress-bar code either. Which is the worst possible outcome, obviously.