You can take the "embedded" approach if it solves your problem. No need to over-complexify your design by making things orthogonal, assured. But you have to make a promise to yourself: that the very one day that you're going to traverse the data structure to do other things - what about searching an item? - you will not cut-and-paste the code, changing only the line with the print to do something else.

This is called refactoring. It's when you understand that you already solved that problem in one point of your code, and you do a favour to yourself and don't cut-and-paste, but you rather "summarize" what the two functions have in common into a common function that you call twice, in two different context and for two similar-but-different purposes. Why is this a favour to yourself? Because the very time you'll find a bug, you will not have to go hunting in your code to look for all places where you pasted the bug. Because you learn to give these factored-out functions meaningful names, that make your code easier to read and maintain. Because you'll be able to use the same function the next time you have a similar problem.

Sometimes this factoring excercise is done ahead, like in BrowserUK case. This normally happens when you "see" that an algorithm you're going to use would be really helpful in much other situations, and you prepare to reuse. But be lazy, don't look too much ahead, or you could possibly drawn in a sea of pain, where you spend most of the time in building up a beautiful library, and take 5x the needed time to solve your problem.

To be fair, this is what I've summarised from some answers to a previous question of mines: Writing general code: real world example - and doubts! (just to warn you, the first answers actually deal with the issue, then you can find interesting suggestions about tainting, but I understand that these would be a little OT here :)