@dpwiz yep, define the interfaces and invariants/assertions, overall module structure, make a to-do list in Org-mode then quickly write a naive but clear implementation without thinking much about the corner cases then run it ASAP to catch up the syntax errors, identifiers clash, and types mismatch then observe that it works incorrectly and start debugging it and thinking about the corner cases and only then start optimizing it, after reaching the correctness, optimize only those parts which a tool *has shown* to be inefficient, not those you *think* may be inefficient and after finishing don't rush to show it to the supervisors or release, let it draw for a while and do something else then return to it and reread everything, fix the newly discovered errors and comment everything not entirely obvious, also maybe rename some identifiers with regexp-replace to make them consistent only then release or wait for the deadline
then quickly write a naive but clear implementation without thinking much about the corner cases
then run it ASAP to catch up the syntax errors, identifiers clash, and types mismatch
then observe that it works incorrectly and start debugging it and thinking about the corner cases
and only then start optimizing it, after reaching the correctness, optimize only those parts which a tool *has shown* to be inefficient, not those you *think* may be inefficient
and after finishing don't rush to show it to the supervisors or release, let it draw for a while and do something else
then return to it and reread everything, fix the newly discovered errors and comment everything not entirely obvious, also maybe rename some identifiers with regexp-replace to make them consistent
only then release or wait for the deadline
something like that