When I first thought about this, I imagined that I would present some broken code and then jump on my soapbox and pontificate on how evil the patterns were, and I’d follow that up with a diatribe on how to write good code.
There are a couple of fundamental problems with this approach.
First of all, it would introduce concepts that are neither easily digestible by beginners nor interesting to intermediate programmers and would ultimately be more of an ego trip than a text that really helps programmers evolve and refine their craft. I think there are enough beginner level textbooks out there; we need more that show coders what it takes to earn that Staff or Principal title.
Second, and more challenging, is that taking answers to the next level is actually hard. They require some serious thought and planning, and if the goal is to apply techniques in the context of a technical interview, they also require a level of methodology and organization, as you not only focus on the edge cases and dotting the i’s and crossing the t’s, but also focus on how to communicate what you think and how to adapt to what might be asked of you.
The latter is pretty useful in general, right?
