[HN Gopher] Laying myself off from Amazon
___________________________________________________________________
Laying myself off from Amazon
Author : dimmke
Score : 168 points
Date : 2022-11-16 18:00 UTC (5 hours ago)
(HTM) web link (daniel.do)
(TXT) w3m dump (daniel.do)
| latchkey wrote:
| Writing tests is dysfunctional? Funny, I thought that was part of
| the job.
| Smaug123 wrote:
| You appear to have forgotten, for example, the "40% of my time
| trying to tame the bad internal tooling I was forced to
| use...".
| latchkey wrote:
| Did you read any of his other posts on his blog?
|
| He's a digital nomad who took off to Mexico (and Belize) and
| seems a bit lost in where he is going (he says it himself).
| I've been there myself (except I moved to Vietnam), so I
| understand it.
|
| This is a lot deeper than just writing tests or 40% internal
| tooling issues. I also suspect that being remote, he feels
| like his hands are tied in a company that isn't used to
| working remotely. Or at least, if I was struggling with
| tooling, I'd work to find a way to make it better.
|
| I also never complain about writing tests. I can't tell you
| how many times tests have saved my bacon or resulted in
| writing cleaner code.
| ender341341 wrote:
| it is when the focus is on having 100% coverage and not on test
| quality. When 100% becomes the metric it tends to get gamed
| pretty heavily with tests that have such a huge amount of mocks
| as to make the tests useless, or doing something to make it hit
| a branch, but ignoring actually verifying it cause that branch
| is just a log statement.
| mnd999 wrote:
| That was the biggest red flag for me. It's basically
| impossible to achieve without writing tests for the sake of
| it.
| slipshady wrote:
| I work closely with the CR-time coverage/enforcement tool.
| The tool expects 70% new line coverage. The number was chosen
| arbitrarily, but individual teams/managers can choose to
| avoid the rule or set a different threshold.
|
| It's not ridiculous to expect some, *configurable*, amount of
| test coverage for newly generated code, is it?
| latchkey wrote:
| I seriously doubt it is actually 100%... let's verify that
| number.
| yazaddaruvala wrote:
| When I was at Amazon, the general consensus was 90-95% but
| not higher. We also excluded all of our Java Spring/Guice
| configs.
| iLoveOncall wrote:
| If you're thinking of joining big tech, try to join a team that
| develops an internal tool.
|
| You have as much impact and are exposed to as much scale (maybe
| not in terms of TPS but in terms of data, etc.), but you usually
| have much lighter development processes and a much more frequent
| release cycle. Your ops will also be a lot lighter.
| scubbo wrote:
| I left Amazon in June of this year, in a similar-ish position to
| the author. I didn't have anywhere near that level of problems
| with the internal tooling[0], my frustrations were more related
| to seeing poor product prioritization decisions, neglect of tech
| debt, and repeated inefficiencies and mistakes in org-wide
| projects. Nonetheless, the feeling choosing to prioritize one's
| own mental health and recovery really resonates. Good for you,
| author! Take a break, get back in touch with yourself and what
| you care about, prioritize your joy, and I wish you all the best
| of luck in your next project!
|
| [0] which I've found to be pretty-to-extremely-good compared with
| what I've discovered since leaving, and would actively welcome
| new perspectives on what flaws I'm missing.
| sakopov wrote:
| Curious, did you go somewhere that at least matched your
| salary? I know Amazon compensates very well, so much so that
| it's probably difficult to find something else unless it's
| another FAANG company. I have a friend working there who
| basically deals with all the not-so-good things mostly because
| the compensation is so good.
| adamwk wrote:
| Amazon's internal tooling really is the ninth circle of hell. It
| seems unsalvageable too; ostensibly the teams are supposed to be
| customer obsessed and the developers are the customer, but
| there's no accountability for anything to work well at all.
| philsnow wrote:
| Well what are they (the developer-customers) going to do, buy
| from another vendor?
| mabbo wrote:
| > I also know that every team at Amazon is different, so please
| don't take my description for what it's like working there as a
| whole.
|
| No, no, this sounds pretty much like every team I was on for the
| nearly-decade I was there.
| stuff4ben wrote:
| How was the work/life balance though? Did you find you were able
| to have downtime and rest or were you constantly worrying about
| unfinished work and looming deadlines?
| dangerwill wrote:
| I don't think I've ever heard a testimony of Amazon having good
| work life balance. The best you hear is that some people get
| lucky and things are "ok" on that front.
| scubbo wrote:
| Hi, recently ex-Amazonian here. It very much varies team-to-
| team. I was both careful and lucky enough to always be on
| teams where work-life balance was actively prioritized, with
| managers literally telling people to take more PTO, ensuring
| that stressful oncall experiences were a) compensated with
| unofficial time-off and b) taken as a prompt to invest in
| paying down tech debt to avoid repeat experiences. My
| experiences seem to have been better than the industry
| average.
|
| But then I saw how some teams (predominantly, but not
| exclusively, based in Seattle) worked, and....yeah. Overall,
| not great.
| belval wrote:
| My work life balance at Amazon as an SDE is great but I don't
| have 24/7 oncall, make of that what you will.
|
| That being said, I agree that the internal tooling at Amazon
| is not that great. It's actually a place where newer
| employees tend to clash with older Amazonian because it
| compares unfavourably with GitHub actions or any modern CI/CD
| while being significantly better than anything that existed
| in the early 2010s.
|
| I've heard a lot of testimonies of SDEs maintaining pipelines
| that are making them miserable.
| scubbo wrote:
| This is really baffling to me. In fact, since leaving
| Amazon in June, I've been really frustrated by how much
| extra work setting up a CI/CD pipeline is in (say) Drone
| and Argo/Flux than with Amazon's internal tooling. You can
| set up a standard Amazon pipeline with a single command and
| answering a few prompts about naming, whereas with the
| open-source systems you have to hand-craft everything
| yourself, hack in a way to update the infra repo every time
| the source repo changes (I blogged more about that here:
| https://blog.scubbo.org/posts/ci-cd-cd-oh-my/), and it
| seems like Drone literally doesn't have metrics that
| indicate broken builds. To say nothing of how well-
| integrated Pipelines is with alerting and ticketing - yet
| _another_ integration you would have to build for yourself
| in OSS-land.
|
| Literally the only advantage I'm aware of for OSS systems
| is that they allow you to use whatever language,
| dependencies, build system, etc. that you want - which,
| yes, fair, if that's something that you need, then that's a
| deal-breaker, but for the 99.99...% of internal cases that
| Pipelines works for, it (seems to me to) work flawlessly
| and smoothly.
|
| What are some unfavourable comparisons that I'm missing?
| [deleted]
| newaccount2021 wrote:
| swyx wrote:
| same reasons here that contributed towards deciding leaving
| Amazon despite it being a dream job entering the industry (i did
| have a significant "pull factor" to another job that accelerated
| the timing). when you realize you wouldn't be happy even with the
| best case, it's time to go. However, i've heard many reports of
| talented, smart people doing fulfilling, challenging work at
| Amazon and its probably the luck of the draw on what team you get
| staffed on. So the case could be made that you couldve simply
| tried for a transfer.
|
| i suspect that, if you work on a "slow and kludgy product", the
| responsible thing to do would have been to write a memo laying
| out why it sucks and what needs to be done. I've seen a rare few
| folks actually get heard and get the mandate to do what needed to
| be done. but I know it can feel overwhelming for most and
| ultimately its the responsibility of the GM/PM to know whether
| this is true or just the whining of an underling with no context.
|
| also kudos for having the guts/integrity to do this before
| thanksgiving. make it count!
| bogomipz wrote:
| Does anyone know what role or title the the author might have had
| there? They mentioned DevOps but then also in another paragraph
| they mentioned front-end development.
| bolt7469 wrote:
| https://www.linkedin.com/in/danielimmke/
| outside1234 wrote:
| Why does anyone work there?
| mkl95 wrote:
| Resume would be my first guess. Even if the actual job sucks
| it's a solid career investment.
| danrocks wrote:
| Former Amazonian here. The learning is unmatched. I've been in
| different FAANGs but the way that Amazon pushes one to learn
| and challenge the status quo is unthinkable. I never saw "no,
| you can't do that, that system/business/area is sacred".
| Everything is up for grabs all the time. While there are
| pathological side effects to this (AWS promotion-per-launch,
| constantly battle for scope), the amount of knowledge one can
| gain in different areas from world-class people is pretty
| incredible. One of my systems at Amazon had more traffic in one
| day than my system at another FAANG had in 5 years. Working on
| a system that needs to support 5, 6, 7 MILLION TPs to perform
| complex operations was a great lesson for me.
| atlgator wrote:
| How does this compare to your experience at CDC?
| amzn-throw wrote:
| Amazon has a lot of bad internal tools, but this person's
| experience doesn't match mine (being here for 8 years) at all
|
| > 40% of my time trying to tame the bad internal tooling I was
| forced to use to submit my code, get it merged, deploy it, check
| logs, etc...
|
| The tools for code submission, pull requests, pipelines, metrics,
| and logging are fantastic. Google is better. Most companies
| aren't.
|
| I have never spent 40% of my time battling internal tools....
|
| > 20% of my time in meetings
|
| Developers complain when they're not invited to meetings, and
| they complain when they're invited. On my team we brutally
| introspect the value of every meeting, and if it looks like it's
| not delivering value, we find a new process.
|
| > 20% of my time writing unit tests to hit the 100% coverage
| requirement of the codebase I worked on.
|
| This makes no sense. This isn't a company mandate, every team is
| free to determine what code coverage percentage makes sense for
| them. Give this feedback to your tech lead, nearest Sr. SDE or PE
| -> 100% test coverage should never be "required"
|
| > 10% of my time tracking down bugs in other team's codebases for
| either internal tools or frameworks and trying to get them to
| acknowledge the problem by filing tickets.
|
| So, software engineering?
| scubbo wrote:
| > The tools for code submission, pull requests, pipelines,
| metrics, and logging are fantastic.
|
| THANK YOU. I feel like I'm taking crazy pills whenever I see
| people bash Builder Tools - Pipelines in particular. Compared
| with what seems to be available in the Open Source world, it's
| fucking stupendous, and has silky-smooth integration.
| fdgsdfogijq wrote:
| Yeah I actually think this guy was just underperforming
| zeroonetwothree wrote:
| I've never complained about not being invited to a meeting. I'd
| be happy never going to a single one.
| marcinzm wrote:
| >I have never spent 40% of my time battling internal tools....
|
| In my experience, not at Amazon, long tenure employees get used
| to the quirky tools but the impact on new employees can be
| massive. Same with bad code bases, bad documentation and so on.
| gruffle wrote:
| > On my team we brutally introspect the value of every meeting,
| and if it looks like it's not delivering value, we find a new
| process
|
| Oh yeah I love the multiple hours we have spend every week
| 'introspecting' processes, just to throw out one of the dozen
| we'd already defined and add another one. And this
| 'introspection' typically boils down to the loudest, most
| ambitious mouthbreathers forcing their BS down everyones
| throats so that they can jot down their amazing process
| contributions in their promo doc. Brutal is the right word.
| techsupporter wrote:
| > This is not counting the weeks where I was "on call" and forced
| to drop all of this to work on a backlog of DevOps related
| issues.
|
| I want to say sorry at the beginning if I misread what the author
| (you?) intended when you wrote this. And I'm coming at this from
| someone who is not a developer and who, compared to the lofty
| Software Engineer salaries in this industry, feels underpaid and
| underappreciated for doing the operations/administration work.
|
| With that said: I truly wish those who are leaving their roles
| where this kind of requirement exists--feels "forced"--would
| speak more loudly about the need to have actual people doing
| system administration work. This is especially true, I feel, in
| large companies who operate "the Cloud" and who ought to know
| better; _someone_ needs to be doing that work and it can 't
| always, or usually, be the people who are writing the features
| and implementing the updates to the core product you are selling.
|
| But what seems like has happened is everyone in the tech industry
| has forgotten it, or named it "Site Reliability Engineer" with a
| job of 55% failure analysis, 35% coding, and 10% "are the
| infrastructure and products actually online and functional." And
| then this role gets looked down on and paid less because the
| people in the role--people like me--are not seen as "delivering"
| "value".
|
| Which culminates in the _proper_ software developers seeing it as
| a thing they are forced to do, resulting in disdain, and
| furthering the cycle.
| titanomachy wrote:
| The SRE role comes from Google, where they are neither looked
| down on nor underpaid. Perhaps other companies have corrupted
| that title to mean something else.
| lightbendover wrote:
| I hated the internal tooling so much that I switched to a manager
| role almost immediately and only went back to IC when I was
| sufficiently situated to not have to code anything that wasn't a
| flashy proof-of-concept.
| olladecarne wrote:
| My experience has been similar at other large companies (MSFT,
| Google). My advice is to look for founder-led teams (not
| companies). If there are plenty of founders still on the team,
| they will likely care a lot about the product and code and hold
| everyone to high standards which make the work easier in the long
| run. On the other hand when I've been on teams where all the
| original founders left, it's been a constant struggle to make
| anyone care about anything. At that point there is no ownership
| and most people are there for a paycheck. Lots of sloppy code
| gets shipped, everyone approves anything that looks like code,
| and eventually adding a single line anywhere feels like playing
| Russian roulette. Extreme short term thinking takes hold and no
| one cares that in 2-3 years the code will be unmaintainable
| because they don't plan to be on the team by then.
| yodsanklai wrote:
| > My experience has been similar at other large companies
| (MSFT, Google).
|
| I would expect Google to have better engineering discipline
| than Amazon or Meta.
| gruffle wrote:
| Yup, and the other flipside is devs being extremely nitpicky
| and regurgitating irrelevant Amazon principles BS in code
| reviews because they're trying to get promoted.
| dilyevsky wrote:
| Is this just me or aside from 40% spent on tooling (which I don't
| know what the deal is in this case but tbh I've seen some folks
| really spent their time inefficiently trying to make everything
| perfect) the breakdown looks completely normal for an established
| project at medium to big corp?
| leros wrote:
| It's really difficult getting hundreds or thousands of people
| working together. Tooling, communication, etc become really
| critical. Otherwise, it's just chaos. As a result, you spend a
| lot less time "actually working" and a lot more time
| "collaborating" and "project managing". Spending less than 50%
| of your time on "actually working" is very normal in large
| companies
| francisofascii wrote:
| Was thinking that same. The 40% spent on tooling to deploy code
| and of course on call time is never fun, but the other time
| seems normal. But leaving only 10% of real development is not
| great and the author can probably do better. It is a good
| reminder that if you get to do greenfield development or
| generally enjoy your work, don't be quick to jump ship just for
| higher pay/prestige.
| TheRealPomax wrote:
| While it's not just you, and there are lots of folks who think
| that's just fine: if someone hires a dev and then make them
| spend only 10% doing the job they applied for, whoever hired
| them lied about the job, and the product they're hiring for has
| fundamental problems that you can either commit to solve, or
| burn bodies over in the hopes that you get transferred out to a
| different position and it's not your problem anymore. One of
| those may be good for business, but it's not the one that makes
| for a good company.
| perpil wrote:
| You must have not tried god mode, the internal tool that flips
| the table on all of that SDE-0 bullshit. If you work at AMZN,
| search broadcast for "god mode hackathon" and start using it. If
| you are external, watch the hype videos here:
| https://photos.app.goo.gl/8enVGZLYFvpcgj2V9
| d_burfoot wrote:
| > 40% of my time trying to tame the bad internal tooling I was
| forced to use to submit my code, get it merged, deploy it, check
| logs, etc...
|
| This gives the lie to Jeff Bezos' whole "Day 1" philosophy. If
| you're at a Day 1 company you don't spend 40% of your time
| fighting with the crappy internal tools.
| munchler wrote:
| "Day 1" is just motivational poster nonsense, anyway. No
| company can reinvent itself every day.
| dilyevsky wrote:
| Not sure what the Amzn situation is but something I've noticed
| at few previous gigs that there're some folks who _claim_ they
| spent significant time wrestling with tooling but when you
| actually go in and make them formulate the issue it 's either
| something really obvious or a 10-min google/github search like
| 9/10 times. These also weren't coming from people who I
| considered lazy or unintelligent (well, for the most part) so I
| can't really explain it logically. I suspect it may have
| something to do with motivation or cultural issues ("not my
| job" sort of folks).
| zug_zug wrote:
| I've seen people complain about it who were wrong, but I've
| also seen people fail to complain about it when they really
| should have been.
|
| I just worked at a fang company, and here's an example - to
| search CI logs to see if a certain log happened frequently
| you would : WRITE A SCRIPT to download 100MB CI logs and
| search them for you.
| dilyevsky wrote:
| Your example does not sound as outrageous as you seem to
| think - I can imagine a number of scenarios where this
| would be totally acceptable solution assuming we're talking
| about software engineers here. Consider the fact that most
| startups don't even have dedicated teams running CI unlike
| at fangs and it's up to devs to set everything up. Yet I
| don't really hear about folks complaining about internal
| tooling at early startups
| adamwk wrote:
| When it's an internal tool you can't google it. You search
| through internal wikis that haven't been updated in years
| gruffle wrote:
| Or you reach out to the owning teams/oncalls and half the
| time they have no idea how their own code/product works for
| anything nontrivial because most of it was written several
| generations of attrition ago.
| dilyevsky wrote:
| When I worked at google you could =) j/k moma was terrible
| but most issues were easily searchable via a combination of
| email list/bug tracker/codesearch
| pinewurst wrote:
| I think what "Day 1" means at Amazon is that you're always
| still finding your footing, until you quit.
| mandeepj wrote:
| > This gives the lie to Jeff Bezos' whole "Day 1" philosophy.
|
| You can also interpret it like - "always start from scratch.
| You don't have anything"
| Yhippa wrote:
| To be completely honest, what he describes seems to be what I've
| run into at nearly every stop I've been at as a consultant. I
| honestly never thought of it as hell, but I've also never been in
| a much better, tech tooling-friendly environment like at one of
| the FAAMNGs.
|
| I suspect the people who end up leaving those environments for a
| more normal F500 company are going to be in for a shock in terms
| of work ergonomics and pay. This guy was lucky that he was able
| to squirrel away so much tech-worker money to be able to quit
| without a backup plan.
| ElijahLynn wrote:
| The key word here is "savings".
|
| And good on you for doing it and great you don't have obligations
| to provide for others. What a freeing decision you made for your
| self!
| muh_gradle wrote:
| I completely understand where the author is coming from. I did
| literally the same thing. I am fortunate to be in a similar
| circumstance where I have the savings to weather the storm. The
| only difference is I was working for a highly dysfunctional
| manager and team. Towards the last days before I resigned, I was
| nearly on the brink of panic attacks from every meeting I had
| with my manager. I could see that my skills as a developer in
| doing actual, meaningful work had severely atrophied in a short
| period of time. To anyone that had to make difficult decisions
| like this, do what is best for you and your loved ones because a
| job shouldn't define you.
| nyarlathotep_ wrote:
| Worked for AWS for just under a year and a half; this mirrors my
| experience exactly.
|
| 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.
| fdgsdfogijq wrote:
| You should have just switched teams. Amazon has amazing teams
| working on deep technology, they also have huge systems with
| technical debt and stress. People dont realize how different it
| can be inside the company.
| mr_tristan wrote:
| How easy is it to transfer between teams? Some companies make
| this easy, others make it almost harder to apply internally
| then externally.
| goostavos wrote:
| I've been on 4 different teams at Amazon (now migrating to
| a 5th). It depends entirely on the team and as well as your
| current level. Some do loops just like with external
| candidates. Others barely require more than a conversation
| with someone on the team -- though this one is a huge red
| flag. Teams looking for warm bodies are seldom good teams.
|
| 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).
| bb88 wrote:
| I've seen a lot of red flags in my career where managers
| put people on PIPs -- when in reality it's not a PIP but
| a personality conflict.
|
| And from what I understand at Amazon, it's kind of the
| same thing, but PIPs have been aggressively weaponized.
| gruffle wrote:
| I believe you also need approvals from your current
| manager(s) to switch teams?
| ldjkfkdsjnv wrote:
| Nope no approval required
| twelve40 wrote:
| that can't be right (but i have no idea). In the new
| group, nobody has any desire to at least do a reference
| check with the previous group? That would be the first
| thing as a hiring manager i would try to check for, say
| "this person is a d-bag that the entire group hated, and
| we were about to pip him/her anyway"? That would be kind
| of an equivalent of an approval, even if there is no
| formal approval.
| gruffle wrote:
| Interesting, I was told the opposite by my managers...
| Patrol8394 wrote:
| They all look shining from the outside, problems start when
| you join the new team and realize the pile of s _t you will
| be dealing with.
|
| Btw this happens in most companies, tons of tech debt. And
| those who created that s_t 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.
| [deleted]
| lozenge wrote:
| How can you tell ahead of time if the team you're switching
| to has it any better?
| Syonyk wrote:
| Find out what they drink for "Team alcohol evenings."
|
| 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.
| dfxm12 wrote:
| _Poorly designed, failure-prone, brittle internal tooling was a
| time and energy sink_
|
| 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.
| buremba wrote:
| I thought that the deployment pipelines are part of their core
| business considering AWS has such products that are meant to be
| used by customers. I assume that the internal tools are
| different than what AWS customers use for deployments?
| dimmke wrote:
| A lot of internal teams don't use the AWS software for
| various reasons. So like, CodePipeline might be great, but
| there's an internal analogue (I'm not sure the detail I can
| go into here) that is awful that a lot of teams use. There's
| been an internal movement to try to get all teams onto AWS
| services, but it's incredibly slow moving and there's no
| timeline that I know of.
| yazaddaruvala wrote:
| Oh man, we disagree! I miss Pipelines (the internal version
| of CodePipeline). Having worked at startups and now at
| Google, that tool is honestly best in class.
|
| 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!
| dimmke wrote:
| I was referring to Apollo specifically, since we're
| naming things.
| bb88 wrote:
| Clearly a mistake. They should be dogfooding their
| offerings. A lot of tooling will probably just be better if
| they can host it on AWS.
| fdgsdfogijq wrote:
| CharlieDigital wrote:
| > So like, CodePipeline might be great
|
| 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.
| bitL wrote:
| You are pretty much validating that Amazon is a 2-year company,
| as reflected in their vesting schedule.
| dimmke wrote:
| >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.
|
| 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.
| scruple wrote:
| When I worked for a BigTechCo, I was doing exercism every
| single morning for ~30 minutes for the same reason. It really
| is incredible. I know a few of my former colleagues were
| doing the same. Today I'm on a team with 4 other engineers,
| so I keep busy coding.
| arcturus17 wrote:
| I cannot code in prod anymore and have definitely been
| looking to develop a habit like this. Any tips from you and
| others on:
|
| a) How to make it stick
|
| b) How to maximize its efficacy/efficiency
|
| Would be awesome.
| pbronez wrote:
| Thanks for the tip - Exercism looks great.
|
| https://exercism.org/
| chrsw wrote:
| >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.
|
| I figured this was pretty common. I've only had one job where I
| didn't feel the need to do this.
| gruffle wrote:
| Completely agree. Interesting how the internal dev satisfaction
| polling always shows that the vast majority of devs just
| absolutely love the internal tooling and processes. Might have
| something to do with the polls not actually being anonymous.
| When hr/polling teams are asked about anonymity they generally
| skirt or ignore the question, but I've learned that enough
| metadata is collected to identify any responder in pretty much
| any internal poll.
| [deleted]
| giantg2 wrote:
| "Generally a very unpleasant experience all around, sans the
| compensation and name on the resume."
|
| At least you have that.
|
| My skills have atrophied and my pay is meh.
| gw98 wrote:
| This is the general feeling of what I see from AWS support as
| well as a consumer of the platform.
|
| 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.
| rad_gruchalski wrote:
| > 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.
|
| Considering rather good quality APIs they expose to the
| external world, this is shocking to read.
| robofanatic wrote:
| You should have waited few days for the package.
| keyle wrote:
| You can't wait for what you don't know.
| unnouinceput wrote:
| This mirrors my experience with my prestigious job I had at
| SiemensVDO in 2005/2006. Same stuff of wasting time on anything
| else than coding. He said 10% of his time was coding. I suspect
| mine was like 20% and I felt miserable after a year. The
| honeymoon of getting to write embedded code for real cars, cars
| that would be driven by millions of people only lasted like 3 to
| 4 months. After that the job had nothing else to teach me and
| over a little year later I quit too, with a total of one month
| shy of 1.5 years there.
| bryanlarsen wrote:
| No voluntary layoff plan you could take advantage of to get some
| severance pay? Might have been worth holding off a week to see if
| they rolled one of those out. Water under the bridge now, though.
| yumbrand wrote:
| Literally today -- about three hours ago, Amazon extended
| voluntary buyout offers to some employees.
| CelticBard wrote:
| This was a good read. I guess we do have to rip off the bandaid
| sometimes.
| dimmke wrote:
| Thanks. An upvote would help, I'd love to have more people read
| it.
___________________________________________________________________
(page generated 2022-11-16 23:00 UTC)