I did not mention this in my blog post, but I have actually done similar. That's incredible. Thanks for sharing this comment. Our tenures were almost the exact same length too.
a) How to make it stick
b) How to maximize its efficacy/efficiency
Would be awesome.
I initially thought it was a misspelling of exorcism, and OP was making a joke.
Considering rather good quality APIs they expose to the external world, this is shocking to read.
Public facing products have competition. Internal tools have a captive audience that must use them, no matter what.
The entire CodeBuild suite kind of sucks when you stack it up to options available on the market including GitHub Actions, GitLab Runners, Azure DevOps, literally almost anything.
If the internal analogue is worse than the CodeStar suite, then yikes.
FWIW, I don't miss Quilt, or VersionSets, or Apollo, or Hydra, or TOD, or NAWS Pipelines bridge. But Pipelines itself, brining all of those tools together is amazing!
Most of the time its somewhere in between. You'll speak with the manager, speak with the team, you each review each other's artifacts, and if everyone's happy, you swap over. The balance of power is pretty nice. I've dropped out of the process many, many times after starting talking with management. Or even just learning more about what the team itself does (I couldn't live with myself if I worked on pre-roll ads, for example. So I noped out of that one).
And from what I understand at Amazon, it's kind of the same thing, but PIPs have been aggressively weaponized.
Not familiar with Amazon culture so I don't know if that'd be considered acceptable behavior. I hope not!
The manager should put those bad things _in writing_ during performance reviews instead of trying to prevent their employees from leaving by dunking on them after they are informed about the fact.
Whiskey team? Ok, probably somewhat stressful but doable. Wine team? Plush and cushy, with a line of people who want to be on that team out the door. Vodka team? Oh hell no. Etc.
... I'm kidding. Sort of. But not entirely.
There are so many data sources that are all queryable via API. There are a couple basic greasemonkey scripts already floating around but as an SDE it really isn't that hard to write something yourself... It does take a bit of experience to get a good heuristic on weighting the different data points but you can do way better than blindly guessing.
I will say as someone who HAS intelligently looked through this data for most teams at Amazon, there is an absolutely MASSIVE difference between the top 10% of teams and the median, and an even larger difference between than and the bottom 10%, which by all metrics appear to truly be hell on earth.
Tech survey results??
OP was making it sound like you could get the results for a specific team you'd want to transfer to.
Btw this happens in most companies, tons of tech debt. And those who created that st are off onto new projects recreating the exact same mess all over again.
It is a cycle that never ends.
Only chance is to join early and be in for the long run.
It's s lot of fun with the right attitude.
And hopefully no one else regrets it...
Thus is the circle of (engineering) life.
Just kidding. Please write maintainable code.
Not in the requirements, sorry.
Most people don't know how to do this, because it's actually hard, and I don't think it's being taught much in programmer education.
I certainly had to learn "on the job", and probably spent 10 years before I got good at it.
I learned the most by fixing bugs. After a while, I started seeing the patterns of why this bug had occurred, and started writing code do avoid the traps.
I prefer the term troubleshooter specialising in legacy code, but "code janitor" definitely has felt more appropriate at times.
I was an L5 with about 5-6 years of experience, 1.5 at that point at Amazon.
IME, the best managers are the ones who trust and enable their teams to make the right decisions. It would be a red flag if the manager was just giving out offers without allowing the team to provide their input.
Sometimes I get frustrated at my own job for some reason or another, but I appreciate learning that the grass isn't really greener anywhere else & even places where tech is the core business are having a lot of the same problems.
I figured this was pretty common. I've only had one job where I didn't feel the need to do this.
Well ... maybe?
N1 doesn’t really help, but it’s a start.
I'm battling something for weeks now which is a completely broken ass piece of shit inside AWS. I spent the first 3 weeks trying to get attention for this via support tickets and someone to take it seriously, resulting in escalating to account management. I've been on calls with the programme managers, been apologised to constantly and absolutely nothing has been done that is productive. Not only that they sheepishly suggested other customers were in the same shit.
My conclusion at the end is that critical bits of AWS are held together with only a couple of people who actually know how it works and they don't even have the ability to do fix anything...
Not that the consuming company I work for isn't a complete mess either but I expected better from AWS.
At least you have that.
My skills have atrophied and my pay is meh.
If you do the math on their TC to see how it actually works out from month to month, it makes sense. Unless you get more RSU's, you take a huge hit in pay, unless you weren't cashing in on them to make ends meet.
With the flat share price, there's no 4 year cliff anymore...
Another guy on the team intimated once in a while that he didn't like the team dynamics, but he played his cards pretty close to the chest. After he gave notice, on what we all thought was supposed to be his last day, we showed up in the morning just to find his computer and all of his equipment in a pile on a desk. We never did figure out if we or he were off by one or it was his middle finger to the team.
All the more mysterious because later that day we did discover his middle finger: The lead dev, who seemed to be one of the more reasonable people on the team, and the resident know-it-all both discovered that someone had fiddled with their configurations in ways that broke the system but produced obscure errors and hard to notice differences (like punctuation).
I took a couple lessons away from that project, and reinforced some that I'd already had. Perhaps the most important of which is: Bragging rights for being first mover are very, very short-lived. Once everyone else has copied it, the most accurate adjective for your version is 'old', or 'primitive', not 'first', and absolutely under no circumstances 'best'. Developers don't like bullshit. Don't pretend like your liabilities are assets.
When I quit Amazon, they ran to my desk and unplugged my dev machine, since they thought I was going to leave a software "time bomb". I thought that was the stupidest concern in the world, but maybe it does actually happen.
I never understood that “shut them out” reaction for people giving notice. Getting laid off, maybe. But I pick the time and place where I hand over my 2 weeks. I have all day or even a few days to do it, but I have known for a month or three that this was coming, I’ve known for days when it was likely to come, and I’ve known for hours or even days that it was happening today.
You don’t think if I was going to do something shitty that I would have done it first? You guys are really underestimating my intelligence, or at least my ability to plan. But then that’s probably part of why I’m leaving.
Also they say that liars think everyone else is lying, thieves think everyone else is stealing. So I wonder what this says about the paranoid person? Are they a danger to the company?
I am glad I am doing a master's in parallel because outside that I haven't written code in a while ...
I’ve seen work slow down across a few teams and it just leaves me in a place of boredom and complacency with a major technical itch. Despite this itch looking to be scratched, I cannot seem to find the time/energy to pursue coding regularly outside of work in the limited free time I have. Maybe if I were single, no kids, dogs…
Poorly designed, failure-prone, brittle internal tooling was a time and energy sink to the point where even the most trivial deployment change was a nail-biter. Automated tooling and tests that were ostensibly created to make life easier were the number one pain point and constantly failed in obscure ways that required cutting tickets to teams responsible for the automation.
More often than not these tickets would be ignored and issues would persist for weeks beyond what's reasonable.
I'd actually force myself to write even trivial code on weekends to ensure my ability to develop didn't atrophy as a result of lack of use.
That, paired with the awful corporate culture and constant fear of PIP/job loss forced me to finally leave.
Generally a very unpleasant experience all around, sans the compensation and name on the resume.