I'm sure I can one up you with the kind of code that goes into a trading system.

I think production code in any realtime environment, whether it be at Amazon or a trading desk at a bank, tends to converge towards crap just because of the time pressure on the developers.

You're probably right. So far in my experience, that's pretty prevalent -- and the industry really does go out of its way to reward failure by rewarding heroics.

I read a bank security audit report once... it made me very concerned about banking in general. It was astonishing how many glaring security blunders these banks were making -- and this was pervasive, neither isolated nor limited to small banks...

Learning what not to do is pretty valuable in itself.

You don't 'learn what not to do' by going to a place with shoddy practices as your first gig... Unless you're bright enough to look at what they are doing and realize that it's shoddy, you'll end up adopting the practices (and have to spend the time to un-learn them).

Really, I think that's the only way to learn some things.

Good documentation and comments always seem like a hassle... until the first time you have to go fix a bug on something you wrote 18 months ago and have no clue how it works.

I think that the best way to learn would be to first go some place that has good practices, then go somewhere shoddy. You'll learn to appreciate the good practices a lot more without having to un-learn bad habits.

In my experience, that's much more common. Everyone at amazon complained about how bad the tools and systems were, and yet continually repeated the mistakes that were to me blindingly obvious.

But they topped it off with extra special levels of stupidity: The vast majority of amazon's software ends up being written by juniors, and when they finally bring in seniors, they put the juniors on new systems and stuck the seniors with the task of adding features to the crap (because seniors are "good at wading into bad code").