TODO: Granting Yourself Permission To Move Forward
I just read Chris Ferdinandi's latest newsletter, Gardening and code, about the importance of solving the problems in front of you. In it, Chris touches upon an issue that we all struggle with at some point: feeling like our first solution has to be the perfect solution. It reminded me of a powerful cognitive tool that I use in my own programming: the TODO: comment.
I refer to the TODO: comment as a cognitive tool because, for me, the TODO: comment has very little to do with keeping track of tasks. Yes, it does help you remember to revisit unfinished thoughts. But, for me, that's a secondary benefit. The true power of the TODO: comment is that it grants you permission to move forward in the face of a sub-optimal solution.
Consider this TODO: comment that I have right now in a production web application:
// TODO: This is a temporary measure to assert access controls. In
// the long run, this pathway won't exist. All exports will be
// generated within the app context.
I was building an export feature and I needed a way to preview what the export artifact would look like. The preview of the export and the generation of the export both have security considerations. But, instead of taking time to come up with the perfect solution—or, rather, attempting to come up with the perfect solution—I dropped a TODO: comment, got something good enough working, and moved on with the main focus of the problem.
And the funny thing is, I thought this code was going to be temporary (and, in fact, the TODO: comment still refers to it as a "temporary measure"); but, it ended up becoming permanent. Once I was done building the export feature, I decided it would also be valuable for my users to be able to preview the export prior to generation.
You could argue that I now have sub-optimal code in my production application. And, you could argue that the comment is misleading (vis-a-vis "temporary measure"). And, you'd be right on both counts. But, I have a working, correct, sub-optimal solution that my users can consume today. For me, solving a problem for my customers is a higher priority than is creating the perfect solution.
The TODO: comment is a powerful way to remind myself of this perspective. And, to allow myself to move forward even when it makes me uncomfortable.
And, of course, the TODO: comment is also a reminder that—if I have some spare time one of these days—I can go back in and clean up this code.
// TODO: This is not a great name; but, I'm not sure what to call it
// yet.
// TODO: This is not the right place for this code - I'm having
// trouble finding the right boundary. Leaving it here for now in
// hopes that a better place will be revealed later.
// TODO: It would be better to load these values from the server.
// But, at this time, I have no expectation of changing them so I'll
// just hard-code the values for now.
To be clear, I'm not advocating for broken or insecure code. A TODO: comment should never be about making code work—it should only ever be about making code work better.
Want to use code from this post? Check out the license.
Reader Comments
I love it when I find a TODO comment in my code. It sometimes reminds me of the complexities which are generally only obvious to the person thinking (very) deeply about the logic. And usually, I find that it was not necessary to complete for the application to provide real value. Most often, I find that the TODO item which felt important at the time, was not very important at all. And in the end, I'm grateful I didn't invest a lot of time "getting it right" when it was actually perfectly fine not to do it at all.
Great post Ben!
@Chris,
You have some great insights there, especially regarding TODO comments that end up being something that never gets done (in a good way). I feel like that's a sign of critical thinking about architecture.
// TODO: Comment this awesome blog post from Ben.
😂
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →