The Amazon Technology Platform
Don420 writes "Jim Gray has an interview with Amazon CTO Werner Vogels for ACM Queue. It is filled with a lot of details about the Amazon architecture that we have not seen before: 'If you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you.' But also quite a strong statements about developing software at Amazon: 'Developers of our services can use any tools they see fit to build their services. [...] Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs. [...] Developers are like artists; they produce their best work if they have the freedom to do so, but they need good tools.'"
'If you hit the Amazon.com gateway page, the application calls more than 100 services to collect data and construct the page for you.'
and this a good thing ?
My father always said it was a poor craftsman who uses his tools as an excuse.
I worked at Amazon. It was a nightmare. And I can say this: absolutely none of the above. Amazon tools are largely undocumented, not requiring any kind of standardization on platform/libraries/processes, are totally heterogeneous and are often scary bits of random code floating out in the ether.
This attitude sounds like it's great, but something that this attitude absolutely encourages is non-standardization and a huge lack of planning for the future. They encourage you to go 'just do it' - and then 10 different people have done the same thing because they had no idea that someone else did it first. Or more likely, they looked at what someone else did, saw the horrible documentation and support and decided it was easier to do their own thing.
I currently work at Amazon, and typically most projects aren't done using obscure technologies, they're usually pretty standard technologies. However, there are a *lot* of standard technologies, and every project really does use a different one. So if you're on one team and you're using Java/Spring/Hibernate, you may move to another team and be using Perl, or be using Java/Struts/SomethingElse.
Good documentation, however, is something that is definitely *not* required and something that I hope will change in the near future at Amazon. Without that (and dedicated support teams), you end up with a bunch of developers doing tech support and maintenance work and never getting any actual development done.
Move away from the coasts. I make $75,000/year working 40 hour weeks. I'm not on-call, have flex hours, get 3 weeks of vacation, and unlimited sick time. Quit working for IT sweat shops. Move somewhere where family time is valued and it's impossible to hire people unless you are willing to give them that flexibility. I've been through four employers in the St. Louis area and been able to land jobs with a deal akin to this one at all four. Developers are "poor"? No. Elementary school teachers are "poor." Starting salary for a developer in a low-watt market is close to $40K without a degree. That's not "poor." That's not starving, and that's not living for their work, unless by "living for their work" you mean that you're expected to show up on time and do your job.
"I have never won a debate with an ignorant person." -Ali ibn Abi Talib
I started at AMZN as a dev - hoped to do development of the kinds I never did. And I'm not saying I didn't. However, in retrospect, what I think fucked me up the most is my inability to estimate the time needed between being on a pager 24 hrs/day, 6-7 days out of every month and the time needed to maintain/fix old legacy (perl-based mostly) code - which left me with little time to do any project work. I suppose I've got no one to blame but myself for not knowing how to predict time required for projects, however, one thing I can say is that the environment at AMZN, especially for devs, is untenable at best (hostile, at worst, I'd say). Now, I'm no longer there - I get to sleep at night and not walk in to work like a zombie, I have the weekends/holidays to myself and my family, and my work is of higher quality, and on time. I have AMZN to thank for teaching me a lesson - 1) know thy limits between pager-duty/dev work/maintenance work, 2) be ultra-pessimistic when giving time estimates, 3) say 'no'/complain a lot/cover your ass.
If you do that well, you will survive at AMZN. To get ahead, you need to be an illusionist.