What do I do? I clean up after the cowboys are gone. We start a new project that has bells and whistles and does nifty cool things, and the young guys come in and work it because it's shiny, and they gladly put in the hours. They ship version 1.0. They add the tech TLAs to their resumes. And then they leave. Often times they go on to new shiny projects. Often times they go to newer shinier companies. And they leave their software behind.
We all know that time-to-market is everything. And the cowboys deliver the product. It may not be the highest quality work, and it may not be the most maintainable bit of code. But the product shipped, and that's what mattered.
Then comes sustaining. Time to address the warts, and when you address the warts, you see that the code has a lot of symbol names like "a1" and "b2". Yes, I know fireable offenses in some coding shops. But it shipped!
And this is where I come in. I clean up what the cowboys left behind. Usually this happens when we start addressing issues after the stabilization period is over, or start adding features the customers asked for but never got since we had to get the product out the door.
What do I do? Give symbols meaningful domain-specific names. Refactor code to remove antipatterns, mostly the copy-paste pattern. I also apply our company's coding standards with which the cowboys didn't want to be bothered. I add unit tests to code that changes. I comment the code (though it's mostly self-documenting when I'm done). I replace ad-hoc functions with calls to standard libraries our company uses that the cowboys didn't bother to learn. I apply idioms and frameworks that our company uses to allow code to take advantage of cross-cutting functionality, such as automated logging. I make the code aware of the daylight-savings-time transition. I remove egregious pattern uses people put in to say they used a pattern.
I also try to not be the expert at my applications, since I don't want to be called at 3am to resolve issues. So I maintain notes on our wiki pages as to what it takes for the software to run, and a list of frequent issues that have more to do with environment and upstream issues than with the code. I've trained our Ops people and given them analysis tools such that it's been years since I've been called at night. I also maintain a list of lower-priority code issues that weren't worth addressing, but that could use work some time.
I don't mind the cowboys. I've had a couple of them compliment me on my refactoring since they had long-forgotten what their code did. I still have this dream of being one. But for now, this is what I tend to do.
My only concern is that one day we'll get a shiny CTO who'll figure out that it's better to outsource all the IT to save money (and to give his buddies where he came from the outsourcing business), and I'll be on the street, after training my replacements. How marketable are the above skills? "Hi, I can keep your software running and maintainable." In another five years I figure I'll have made my numbers and the only thing I'll have to worry about is another 2008.