When it comes to traditional programming languages, no. Thanks to test driven development, static analysis, and experience I feel like I very rarely have to tra

When it comes to traditional programming languages, no. Thanks to test driven development, static analysis, and experience I feel like I very rarely have to track legitimate errors and more often than not either something changed elsewhere or the requirements have changed (which is a feature, not an error in my mind). With CSS in particular but JavaScript to a degree, yes it can get frustrating. You will often deploy something which works fine on all current gen' browsers, only for months to years later have it break in unexpected ways and maybe then in only one major browser (but now the "fix" has to be tested in all of them). I will say JavaScript is getting "better." If you stay away from bleeding edge stuff and use things like "use strict" and popular libraries (e.g. jQuery) not only is it largely now "someone else's problem" (e.g. jQuery updates the library with the fix) but you also see less breaking changes because a lot of features and functions are locked. CSS, to me, hasn't improved as browsers continue to break fairly old functionality and libraries only add competing styles rather than supersede and simply things. It is also impossible to write tests against, and even if you could one browser version later and your test can be wrong. Just recently Firefox broke because of how an overflow: auto was handled. No other browser, just Firefox, and even then just during a random normal browser update not a major update revision. We had to fix by adding a float: left to that element and then test it in Safari, Chrome, IE10/Edge, and Opera. We only discovered this issue by luck, otherwise it would have entirely broken a major user facing menu. That's the problem with having no tests for CSS, there's no red flags to warn when stuff breaks.