I worked at Amazon from 2004-2007. On one hand, Amazon does some really excellent and novel work like Dynamo and AWS (S3, EC2, EBS, etc). They organize developer conferences and bring in really good people to lecture. They hire really solid distributed systems people like Pat Helland and give them reign to work with engineering teams to improve their designs.
On the other hand, when you're in the trenches of a product team at Amazon, good engineering takes a back seat to features, deadlines, and keeping everything running. There was an incredible amount of pressure from the top to maintain high levels of service, but not a lot of support for taking the time to refactor or rework those systems to address the underlying causes of service disruption. Everything was always an emergency, but we always had to make the shallow fixes.
Overall, I'm much happier at Google where there is a lot of support for good engineering at all levels of the organization, not just as a means to an end, but as an end in itself.
I bought an xbox and a game for it at the same time from amazon. The xbox was fine the game disk was defective. I contacted amazon via my account, got a call from a human in less than a half hour (mainly I'd say to confirm the xbox itself was OK), received the new game a couple of days later and a refund of my return costs for the game itself.
The only (very) slight quibble I'd have was that the postage on the return exceeded what they refunded. They made the return process itself simple by emailing me barcoded return labels and frequent reminders. I feel very confident buying off amazon a lot more so than ebay for example
Good engineering can't take a backseat to features, deadlines, and keeping things running. Good engineering IS features, deadlines, and keeping things running.
If you aren't making features and meeting deadlines you aren't engineering anything. You're just messing around. Features and deadlines are the difference between science and engineering. There's never enough time, that's what makes it hard.
Of course, Amazon might be pushing time tables too far. I have no idea, and it seems like you do.
I really didn't get the impression that the parent was disappointed he wasn't allowed to 'mess around'. If management doesn't give a flip about technical debt that's a problem.
There is a balance between shipping a good product with good technology. If you are constantly pushed by deadlines and make things just work, it breaks stuff in the future. Any engineer that is continuously working under pressure of tight deadlines cant ship anything creative, solid, simple and open to change.
Good engineers also have to be good analysts. What often makes a programmer better is his/her opinion to say yes and no to products people/designers. But yet again there is a balance. haberman mentioned Google but I personally don't like the over-engineered Google culture. It's too left-wing, if tight deadlines are too right.
On the other hand, when you're in the trenches of a product team at Amazon, good engineering takes a back seat to features, deadlines, and keeping everything running. There was an incredible amount of pressure from the top to maintain high levels of service, but not a lot of support for taking the time to refactor or rework those systems to address the underlying causes of service disruption. Everything was always an emergency, but we always had to make the shallow fixes.
Overall, I'm much happier at Google where there is a lot of support for good engineering at all levels of the organization, not just as a means to an end, but as an end in itself.