I work on Django projects both at work and at home, in the form of side projects (I created HTMLify as a first experiment in full-stack developing and am now working on a minimalistic feed reader). The other day I got really bummed out at work. At first, I didn’t really understand why - I was just depressed. I got talking with a co-worker and he suggested that I introspect and try to pin-point why. After a while of thinking about it, I realized what was wrong. I am embarrassed by the product I’m making.
This is a companion discussion topic for the original entry at http://amir.rachum.com/blog/2013/10/15/i-want-to-fix-it-now/
We don't practice scrum, per se. It's championed as a hybrid of Scrum and Agile, but I've come to call it WILEY: whomever is loudest elicits 'yes'. Our priorities are often entirely customer-driven, and more often than not, the customers have no idea what they want. The point I'm trying to make is that the important problems (from my perspective) rarely have the highest priority.
I work entirely on our backend, which appears to contribute nothing to user experience, but I've noticed an odd phenomenon. When the backend is improved by N times, and the user experience sees NO improvement, brows begin to furrow. In our case, the user interface is rapidly called into question. Most importantly, it is called into question by the management responsible for scheduling and priority. As individual elements improve, they often act as a foil for any other elements that are not up to the same standard.
As a result, my introspective question has transformed from "am I embarrassed by the product WE'RE making?" to "am I embarrassed by the product I'M making?" On the surface, it may seem a standoffish, short-sighted cop-out, but improving seemingly unrelated parts of the system has repeatedly had a knock-on effect. That type of positive reinforcement is obviously hugely dependent on the coupling between front and backend, the size of the team, the current satisfacation of end-users, and the maturity of the product.
On a tangent of personal growth, it may not be the worst thing to accept the idea that 4 features at 75% can sometimes be better than 2 at 100%. Perfect is often the enemy of good. In our particular case, we've spun off entire (profitable, industry-leading) product lines from a side-feature that BARELY limped along in its infancy. Once that feature became the next 'big thing', it naturally got all the attention it needed to become rock solid.
I guess my advice would be to trade in a bit of idealism and perfectionism for patience and tolerance. That's not to say lower your standards... just relax their timeline. Things may not get any better from a product standpoint, but you'll almost certainly be happier.
I have a firm limit of 100,000 lines. Right now, it's 98,000 lines. I'll bet you now understand why things are the way they are. (We don't do silly stuff that adds lines needlessly.)
With regards to wanting to fix things you spot as you go, you should apply the boyscout approach to coding, and always leave code nicer than when you found it. Some padding for refactoring should be built into your estimates, and if that refactoring happens to include refactoring away a bug, so be it :)
YMMV. Does QA and UAT have time to test it? Were there third parties who depended on that behavior?
FIX ALL THE THINGS is usually only acceptable if you have very few users or direct control over all the users.