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?
How to build quickly
71–80 of 147 posts
Re: How to build quickly
#72There 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,…
Well, for example, one could not systematically test everything in the first pass but a few things, and then come back later to write more tests.
The first draft can, should even, be sketchy: it doesn't have to work all the way through; one can think of it as a prototype to help you understand the problem better[0]. It can even be discarded, for example if it's too far away from what is actually needed.
In that setting, TDD might be more suitable for a second or a third pass, once you have a solid grasp of the code's structure.
[0]: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pil...
Re: How to build quickly
#73[deleted]
Re: How to build quickly
#74Good 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.
Re: How to build quickly
#75This 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…
I’m not so convinced that this is a property of functional programming as much as simply good programming. I’ve seen functional programs that pass around huge data structures that couple functionality. I’ve never seen the benefit of performing elaborate monadic dances to avoid state that would have been simpler to represent in a non-functional language.
Re: How to build quickly
#76loading 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.
Re: How to build quickly
#77This 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 ea…
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.
Re: How to build quickly
#78This 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 ea…
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 a modified form of https://xit.jotaen.net/ for my task lists. xit uses [~] notation for obsolete tasks. sometimes an entire branch gets this. i also avoid fleshing out tasks in detail until i've settled on the design for the higher level goal.
Re: How to build quickly
#79loading 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. k…
yeah. there's a place for coding interviews but I'm lucky in that the one I give is basically tell me about something you know a lot about, and find how strong people are at their strengths.
Re: How to build quickly
#80This 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…
I’m not so convinced that this is a property of functional programming as much as simply good programming. I’ve seen functional programs that pass around huge data structures that couple functionality. I’ve never seen the benefit of performing elaborate monadic dances to avoid state that would have been simpler to represent in a non-functional language.
One benefit there if it's statically typed is that you've pushed some correctness validation into the compiler.
In dynamic languages like Clojure it is far too easy to couple functionality and write implicitly imperative but superficially functional code. Something I'm guilty of because it's too easy to do and takes a lot of experience and discipline to avoid.