I work for an agency whose clients include big 5 automakers. Since last April I've been assigned to do maintenance and feature requests on a JS-heavy mobile/tab

I work for an agency whose clients include big 5 automakers. Since last April I've been assigned to do maintenance and feature requests on a JS-heavy mobile/tablet build-and-price web app for one auto manufacturer. The codebase itself seems to originate in 2009; there's some kinds of controllers, but no consistent model to speak of (just lots of service calls, with JSON/data markup stored in and retrieved from the DOM). It has its own not-jQuery DOM manipulation function(s) which, of course, are more poorly conceived and missing significant chunks of the utility of jQuery, and the codebase largely never rises to a level of abstraction above DOM manipulation. Because bad code is a bit like abuse -- there's a cycle of transmission -- I tend to write pretty bad code for this project. If nothing else, even when I'm writing good-ish code I'm still writing at the DOM manipulation level, which isn't so good. And that's the high point I can aspire to without taking on a significant rewrite (assuming anybody would pay for it). So, day to day, when I'm not reading terrible code, I'm writing it. Good times. (Also: not to say that I've never written terrible greenfield code... I have, and some of my never-show-this-to-anyone newbie C code may still be in production as part of an not super popular but nevertheless enduring e-commerce product. Sometimes you start the cycle. :/ )