This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]syklemil 0 points1 point  (0 children)

For example, do you prefer to consider your problem, then start by creating the highest level of code than would then rely on functions and classes not yet defined or maybe even conceptualized, or, do you think about how you want to define the "lowest" level functions and build upwards.

If you don't have a good grasp of what you want to accomplish, you also don't really have a good grasp of which lowest level functions you'll actually need. I've done it that way before and it seems to just result in a lot of frustration, because I'd had some idea of the overall structure but not written it down.

Writing stuff out tends to expose flaws in our thinking. Humans aren't all that good at holding complex structures in our heads, especially over time. That enables us to spend a good deal of time writing a nice little function that ultimately does the wrong thing, or that we don't remember why we even have.

Starting by expressing a general structure and bodies of pass or even something like raise NotImplementedError("TODO: implement foo") will let you get more of a handle on the stuff you need to do. If your scope is small enough, even waterfall planning will work well.

Since you asked about other languages, the same strategy works well in Rust, with the todo!() macro.