> If you create a fizzbuzz application with good performance and clean code, you have solved one problem You haven't necessarily solved a problem if the defini

> If you create a fizzbuzz application with good performance and clean code, you have solved one problem You haven't necessarily solved a problem if the definition of "clean" is subjective and not actually associated with any real benefit to the client/user. In that case you've just scratched an itch or wasted time. Same goes for optimizing something that happens rarely or wasn't prohibitively slow to begin with. Crucially, it's not about what _you_ perceive to be a problem but what the _user_ perceives to be a problem. Again, I'm not saying you shouldn't strive to write clean code that performs well but it's important to know what that actually means within the context of that particular project. Some examples of a "pet" focus: * The designer gets absolutely up in arms because something doesn't match the wireframes, but doing it as shown in the wireframes is much harder. You show it to the client and it makes absolutely no difference to them. * A coworker spends time to refactor code to make it more Pythonic, aka rewrite look-before-you-leap code to ask forgiveness instead of permission. The code is now arguably worse. * A user adds memoization to part of the code that doesn't have any particular performance issue. That code is now harder to understand. The key is to focus on _real_ problems, not ones you want to work on.