Worked there for 7 years (left in 2021) and this is an accurate summary of my experience there.
Adding on thoughts:
One of my biggest gripes was that "make a good marketing opportunity at Re:Invent" seemed to become more important than "release beloved software that makes the lives of our customers easier" by the time I left (not that I was working on anything for reinvent in my final years there).
I will add that I learned a TON from AWS, and got to practice much of it too. It's the best boot camp one could ask for regarding general skill development imo (not particular frameworks etc but like, the theory and practice). There's also some things I miss like the weekly ops review and the general engineering culture, especially when it came to explicitly listing service limits, API specs, and cost up front in your design. Oh, and I honestly miss the docs culture. Quip wasn't as good as Google docs but the actual docs themselves and process of authoring them were SUPER valuable.
Coding wise, CDK was so much better than terraform (once we moved to CDK from lpt+cfn, which was way worse imo). Smithy and open API are neato too (@smithy externally everyone uses thrift it seems, but the overlap of functionality/use cases isn't identical).
Probably the biggest thing I miss was bones (kind of successor to octane), which is kind of like yeoman or create react app but would include so so much of the excellent internal tooling of ci/CD approval actions. I don't know of a real external equivalent, but would love to have one. If you ever see a Breland Miley or Ian Mosher apply to your company, HIRE THEM IMMEDIATELY. (There was another really solid guy on that team but their name escapes me at the moment, and here's hoping I got the spelling right)
Oh, also isengard is still easier to use than okta or AWS organizations to manage accounts imo.
We use projen where I work for the past year or so for new projects. It’s pretty good and the devs are pretty active in terms of responding to bugs and not being shit at documentation.
Pipelines, BT and Isengard are absolutely what I'll miss the most as well (I handed in my resignation notice last week, prior to all this RTO2.0 kerfuffle)
> One of my biggest gripes was that "make a good marketing opportunity at Re:Invent" seemed to become more important than "release beloved software that makes the lives of our customers easier" by the time I left (not that I was working on anything for reinvent in my final years there).
Was this something you knew was coming or did this behavior surprise you? I realize enshittification really ramped up over the 2010s but I have a hard time last remembering when I expected a company to aim for customer satisfaction over squeezing more revenue. Maybe tiktok? (Which has since enshittified in many ways.)
The rest hurts a lot, though. It's not fun to watch the culture of a company you once had pride in sour and rot.
I might have just drunken too much of the koolade and believed in the mythos of lowflyinghawk + customer obsession.
What I meant by this is, in my personal opinion, there were a bunch of half baked products they should have just not mentioned at reinvent because said products never really materialized or had significant usage oncerns for a long, long time after the announcement.
The pressure to announce more and more at reinvent while the quality of what was being announced dropped was the specific feeling I'm talking about.
Sorry kind of on a caffeine high and brain isn't working too well right now. I'm also reluctant to throw shade on the products/teams I'm thinking of because I didn't work on them and I don't want to give them any heat, but I'll say it was in the 2017-2019 era I felt it start to change.
I think it contrasts with the really cool launches like Lambda, Aurora, API Gateway, Sagemaker, etc that has just come out before then.
Neither, they're talking about the culture of writing documents as a form of sharing ideas. Where other companies might use powerpoint presentations or unstructured meetings to brainstorm on ideas, Amazon instead encourages people to write a document summarizing their thoughts, and then there is a meeting where people silently read and comment on the document, and then afterwards discuss it.
That's an extremely sensible idea in multiple dimensions. It prioritises clarity of thought over rambling discussion in conference calls. I wonder if there's a feasible path to gradually steer an existing organisational structure in that direction.
> if there's a feasible path to gradually steer an existing organisational structure in that direction
The path I took was to just start doing it and expecting it for critical topics within my team (which was around 200-250 people when I started it). It takes several iterations to get good at it and the first few feel like it’s quite foreign and even wasteful. (It puts a lot more work on the author, by design.)
Eventually, it escaped just my group and (with support from others, including the CEO, who liked the process after seeing some of the documents that I or others shared with them) and is now fairly common in the corporate center for our standardized processes, though not nearly as standardized as I perceive Amazon to be in its use.
Basically: start doing it and stick to it for at least 5 complete cycles. Make sure that influential people (not necessarily org leaders) are public in their praise of well-constructed and effective documents.
From experience, yes / kind of; for the project I'm on right now, I introduced ADRs (https://adr.github.io/madr/) as a not-too-formal, but still formal way to talk about technology. This was after ten years of working in more hype-driven culture, where the choice was made by one person, or it was the tech du jour, or some guy spent a weekend playing with it so obviously we should integrate it.
It's a simple shift where people have to do their homework instead of just yeet something over the fence. You want to solve X? Present us with three options and we'll talk about it. You want to introduce Y? But we already use X to solve that, present us with new insights and the justification to spend the time on it.
It's far from perfect and it requires buy-in and (self) discipline, but it's still better than what happened before. Because some companies are still paying the debt of hype-driven development even though the people that introduced it are long gone.
- People leave 2 bullshit comments like "justification needed" for participation points and then go drink coffee instead of actually reading the doc or googling for said justification
- People waste inordinate amounts of time writing docs for things that could be discussed in 10 minutes
People taking calls from cars (and thinking it's OK in the first place) is exactly why we're going back to 5 days in office. People are simply taking too much advantage. You're being paid to work those 40 hours a week, not do whatever the hell you want to during the day and try to cram in work while you're driving from one errand to the next.
Why does any comment always assume the average American is commuting ludicrous distances each morning. People do this, but its very, very rare. Hyperbole is getting in the way of discussion.
1-hour one way commutes are NOT rare at all in Amazon's hub locations. Housing near the office is supremely expensive, school districts are also not the best, and most people have partners and need to live in a location that balances 2 peoples' commutes. On top of that, Amazon is such a big employer that they single-handedly make the traffic worse in at least Seattle.
Also, keep in mind that it isn't just the commute time. For a 1-hour commute I also need to prepare for the 1-hour commute, which includes making and packing up a lunch (because many offices have no cafeteria or no options that I'm able to eat), packing up my electric toothbrush and water flosser (because I need to brush 3 times a day for my braces and they won't let me leave shit at the office). Others need to deal with feeding pets, blah blah. For people with train commutes they need to deal with uncertainty in traffic just getting to the train station, so they have to leave an extra 15-20 minutes early and kill time waiting for the train on the platform because the next train won't come for a fucking hour (this is America), and leave time to line up to buy the goddamn parking ticket for the train station.
For the past 2 years people were able to roll out of bed and into a meeting, grabbing something from the fridge on the way. That's why stuff was efficient. Now we're going back to an inefficient world with the same high expectations of an effecient world.
Again, if we are talking about FANG HQs, anything in the Bay Area, Austin, or NYC then yea sure. I'm just suggesting that rhetorically this is a losing strategy because it's such an outlier. Most Americans don't work at the headquarter(s) of the most successful company on Earth.
Counting the time to get dressed and brush your teeth towards the office is comically absurd, in my opinion, even if I take your point. THAT SAID good luck with the braces I don't miss the constant brushing. That would make me want to WFH. Cheers
I haven’t seen a single instance of someone taking a call from their car since working remotely, likely because no one was commuting. It was fairly common prior to the pandemic and I was in office.
but why be so controlling? imagine someone is so busy they have to commute at 45 min commute in the 15 minute gap between meetings. so you’re refusal to be more understanding is blocking progress. likely it’ll be you removed from the meeting and going forward you’ll be included less. have fun being a low level IC!
lol you have too many meetings. I don't care if the manager with back to back meetings listens in from transit or something. im literally suggesting being more flexible
> People waste inordinate amounts of time writing docs for things that could be discussed in 10 minutes
I’m very much a writing kind of person when it comes to organizing my thoughts and I worked at a place where we did a ton of written documentation kind of like this. Then I left there and worked remote with a different company whose CEO, when I sent him an email, would pick up the phone and call me. We would then have the 10 minute conversation you’re talking about here. I came to love it because it’s true, a short focused conversation can be a huge timesaver. Since then, I’m often really frustrated by vendors and partners who steadfastly refuse to get on a call, when it’s very obvious to me that a quick call would be a far better use of time than endlessly going back and forth on email.
These are informal quick chats work nicely, until it doesn't, then it's a disaster and docs are needed.
With certain people I can work like that. With others that I don't trust, have seen don't shoddy work, don't communicate well, then write a doc and we'll discuss it.
The doc culture is great and I prefer meetings having the time upfront to get everyone up to speed. However, I regularly saw six page docs written for 25 line lambda functions.
Was it an important lambda function though? How often would it be called, would it still be around in 10 years, etc? If the six page document justified the existence of a separate deployable, then clearly it was important enough to warrant it. If you claim six pages was excessive, did the lambda even need to exist in the first place?
> - People waste inordinate amounts of time writing docs for things that could be discussed in 10 minutes
What about if someone wants to know what was discussed? You end up telling and retelling the same thing over and over again to get people in the loop, vs pointing to the doc and its remarks. (Depends on the subject of course)
Technical things (algorithms, locations of docker images, code, data, checkpoints, things that were tried but failed) should be documented.
Unfortunately most of the doc culture is people trying to convince each other within the same team that we need XYZ even when everyone with half a brain already knows it. Like "we need more GPUs to get shit done" should be a 10 minute call, not a PRFAQ.
Beyond the initial publication of the doc, the peer review process is much more sane than trying to review a bunch of power point slides. Similarly, it's much much easier to refer to a well written document when it comes time to implement or reevaluate an idea than going over some power point slides and maybe an associated recording, to say nothing about searchability, discoverability, and maintainability of an actual written document vs PowerPoint slides.
Also, idle side speculation: I wonder how much (if any) one of the underappreciated early employees @ Amazon had a hand in proselytizing this, given she (MacKenzie) is an author.
Oof, must suck to work for a company who doesn't use technical design docs well. I quite like Oxide's RFD model, based off Joyent's I assume, given who their CTO is. https://rfd.shared.oxide.computer/rfd/1
In my experience these documents were actually never good. I’ve never seen anyone ask for estimates either. Surely it’s better than some other companies but if it were good they wouldn’t need this absolutely horrific oncall
Adding on thoughts:
One of my biggest gripes was that "make a good marketing opportunity at Re:Invent" seemed to become more important than "release beloved software that makes the lives of our customers easier" by the time I left (not that I was working on anything for reinvent in my final years there).
I will add that I learned a TON from AWS, and got to practice much of it too. It's the best boot camp one could ask for regarding general skill development imo (not particular frameworks etc but like, the theory and practice). There's also some things I miss like the weekly ops review and the general engineering culture, especially when it came to explicitly listing service limits, API specs, and cost up front in your design. Oh, and I honestly miss the docs culture. Quip wasn't as good as Google docs but the actual docs themselves and process of authoring them were SUPER valuable.
Coding wise, CDK was so much better than terraform (once we moved to CDK from lpt+cfn, which was way worse imo). Smithy and open API are neato too (@smithy externally everyone uses thrift it seems, but the overlap of functionality/use cases isn't identical).
Probably the biggest thing I miss was bones (kind of successor to octane), which is kind of like yeoman or create react app but would include so so much of the excellent internal tooling of ci/CD approval actions. I don't know of a real external equivalent, but would love to have one. If you ever see a Breland Miley or Ian Mosher apply to your company, HIRE THEM IMMEDIATELY. (There was another really solid guy on that team but their name escapes me at the moment, and here's hoping I got the spelling right)
Oh, also isengard is still easier to use than okta or AWS organizations to manage accounts imo.