|
|
|
|
|
by skydhash
385 days ago
|
|
The approach that always works for me is iteration and recursion. Just like drawing, where you do a loose sketch and refine it until you're happy. You're either stepping back and work on the whole, or focus on a small part to detail it[0]. So for a software project, I break it into parts recursively. Sometimes for a module, I can build some scaffolding even when I'm not sure about the full implementation. I can go up and down that tree of problems and I always have something to break away from my current thinking track. So there's always a lot of placeholder code, stubs, and various TODO comments around my codebase. And I rely heavily on refactoring (which is why I learned Vim, then Emacs as they helped me with the kind of quick navigation I need for that approach). Also REPL and/or some test frameworks. [0]: https://www.youtube.com/watch?v=prQH5V5inbA |
|
However I’ve noticed that too much refactoring while exploring the problem space becomes tedious for me. At that point I go back to a notepad or whiteboard. Maybe this change of medium is another way to engage the subconscious?
And to your point about vim/emacs - the choice of tools no doubt impacts your engagement with the problem at hand. That’s why having AI generate teams of code doesn’t work for me - but using it to iteratively develop some PoC code whose core I then incorporate into my own code works brilliantly.