Dead Comment
Sadly "in stasis" is pretty generous. I know several people who were in that win of the Allen org and they've all said that Jody Allen viewed it as a waste of time and money and was delighted at the opportunity to close it and never reopen courtesy of the pandemic.
There was exteme organizational disinterest - partly for a bad but predictable reason (we made a lot of money off these fraudsters) and partly for a reason so bad it still makes me cringe (money recovered from identified fraudsters went into the balance sheet of a different SVP's org, so our org viewed it as a waste of time).
I made the case that the longer we let the problem fester, the less people would trust Amazon to buy anything. Leadership didn't really care but got sick of me constantly making noise about this and eventually signed off. That said, at my project's peak I had four engineers and one data scientist. Compare to consumer fraud and vendor fraud, both of which negatively impact Amazon directly, which were fought by entire VP-level orgs of hundreds of people.
In the end we put together a system that detected blatant fraud easily and in worrying volume, but as soon as I left - which meant there wasn't anyone in leadership sponsoring it - it was quietly mothballed.
But not too excited.
But the laid off workers have a lot more in common and a much closer standard of living with each other than with the billionaires whose wealth their layoffs are serving to marginally increase.
Of course badges stop working when you're let go. What possible good can come of leaving the badges on? All it takes is one in 12000 disgruntled ex-employees to make it not worth it.
I'm not convinced that announcing them in advance is actually better anyways. We have partner teams in Europe who get to spend a month or more after the announcement worrying about whether or not they still have a job. Morale on the teams in the US took a noticeable hit, but the teams in EU have seemed utterly miserable for the last week.
Loading parent story...
Loading comment...
Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently write 5000+ lines per code per week, regardless of how many features they actually ship and how many bugs they introduce.
As a team lead and engineer who has managed some complex projects, the idea of someone writing over 2000 lines of code per week terrifies me... That's over 100K lines of code a year. Think of the unnecessary complexity. There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time though that would only amount to 380 lines of code per week! Management won't like that.
I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.