simplicity

Practice 24

TODO or Not TODO

When I’m heads-down writing code, I’ll often realize that a change I’m making will affect another piece of code. Or perhaps while working on a change, I’ll notice an unrelated bug in some adjacent code.

In the old days I’d head off, make those changes, then return to the original task. But when I get back, I’ve lost context; I have to spend some time rereading the code and repeating my initial analysis. Change is slow.

Now I do it differently. I look at the secondary change. If it’s something like a simple typo or changing a parameter value, I’ll do it then and continue working the original problem. For anything that’s bigger, I now slap in a TODO comment.

shape = ellipse(r, r)     # TODO:: could this just be a circle? ...