I’m feeling pretty good about the debugability of what I’m working on at work right now. A combo of

• python. code.interact and pdb for the win.
• no frontend server state. er, excessive memcachery.
• some quality abstractions. back pat, back pat.

means I can just hop on a prod box and just debug away in python.

I hate code cruft. The remnants of code that might have been used at some point but are no longer in operation. It’s not just some weird OCD thing, the maintenance pain is quite real. As are the effects on development time. For many languages you can use static analysis tools to detect and remove unused code, but not for you Mr CSS. Maintaining CSS is the opposite of awesome.
For any random CSS rule, it’s too difficult to determine where the rule is being used or what depends on it. You see, you tend to use css classes to either annotate nodes or style them. You refer to css anywhere you generate or reference html. For web applications this means you end up referencing CSS classes in:

• Server side code that generates static html. These references likely live in whatever templates your framework uses. Or maybe you’re generating html by hand.
• Javascript. The terrible place. Maybe you’re using some javascript templating system, maybe you’re creating DOM nodes by hand. Maybe you’re doing both. You’re probably also manipulating nodes to change CSS classes dynamically.

The sum is that you’ve got references to class names and parts of selectors all over the place with no good way to tie the relationships together. A quickie solution is to name selectors so you can at least ack your source tree for references to them or parents. For whatever reason, this doesn’t really work in practice… so here I am grepping for ‘title’. Maybe it’s in some ${”) somewhere. Most likely it’s not.

You should know that there’s a pretty decent solution that some Google projects use internally. It requires a certain amount of discipline but gives back quite a bit in return. Someone should open source this. *cough