2 ms·
When I am starting a new project I have learned to identify the unknowns. "I don't know how to do X, Y and Z." Before I begin working on the real solutions fo
by dicroce 3y ago
When I am starting a new project I have learned to identify the unknowns.
"I don't know how to do X, Y and Z."
Before I begin working on the real solutions for X, Y & Z I start by making a test program that does X. It's ok if it requires a ton of scaffolding, or canned data... the important thing is to do X. Then I do the same for Y & Z.
Now that I understand the problem I do a software design. I do this on paper and I purposely do it super quick and not caring about how neat it is... and I throw away designs rapidly as I iterate and improve. Eventually the paper crumbling slows down and I approach a real design.
This is finally the point that I can write "real" code. The unknowns are gone and all the software design iteration happened on paper.
- thelastparadise 3y agoVery interesting. Your "paper crumbling" iterative process is very similar to an LLM iteratively refining information within a context window (the paper is the context window).
- roflyear 3y agoThis is similar to or the same as "throw away the first thing you did" often this can be throw away the second, too, if you want. I totally agree, and I work in a similar way. I find that the time I gain down the road drastically makes up for the time spent on the prototypes. This doesn't apply to every problem, mind you - I only advise this type of working either if you really want to understand something, or if you have a good hunch it is going to be used for a while (or may be). One off scripts, there's not much gain - just get them working. Code that is part of a system, absolutely. It should be done this way. Throw it away - and maybe throw it away again.
- yodsanklai 3y ago> the important thing is to do X ... or you think it's good enough, put it in prod, claim the impact, and move to the next problem.