Of the 200K workers laid off in the past year why are close to 40% according to the article Indian? In the US a predominately non-Indian country where Indians make up 1.35% of the population almost half of the laid off were from a single nationality. What factors explain these statistics?
There are a very large number of trained tech workers in India & good business networks for getting them to the U.S. where their skills are highly valued.
In my experience reliance on feature flags tends to turn any application into a mess of interwoven state. Feature flags are hardly ever removed and unintentionally creep more and more into the development future features as they depend on older features guarded by flags. If you use feature flags you must have a process of deprecating them to maintain sanity in the codebase.
Yes, this occurred at the initial stage of using feature flags. It's important to adhere to best practice guidelines and employ effective tools for their management. This includes implementing notifications for stale feature flags and conducting regular cleanups. Nowadays, some independent tools offer features for automatically cleaning up dead feature flags.
What I've learned of "good" program design in my career has come mostly from watching people maintain systems after the original authors have left the project. Compositional systems with well defined abstractions and ownership boundaries seem to fair better over time. They are generally easier to extend while maintaining the abstractions. Unfortunately, most systems in production aren't designed this way. The majority of systems designed at the companies I've worked for are done so by entry or junior level developers. This usually has do with how the promo process works at these companies but thats a separate discussion. Dealing with the pain that poorly designed systems cause really highlights the properties that make certain systems well designed. To gain the experience here get on a project team that has an oncall rotation, preferably a 24hr rotation. If the team has a group of dedicated support engineers even better. This to me is an indication that the team's systems have a high operational load which is usually caused by poor design choices. You'll quickly start to identify the pain points in the system. Next, try to address those pain points. Rinse and repeat for years and you'll understand "good" design.
I think this is an X/Y problem. The problem isn't pinning to latest. The problem is lack of automation that makes builds reproducable. In at least one FANG company I've worked for if you aren't building from latest no one will listen to your issue. Too much software changes to quickly to be pinning to specific versions. However, the build system keeps track of the build audit details and can rollback any build to any state. Teams are required to add the necessary layers of unit, integration, stress, crush, and chaos testing to validate each build. Its not cheap but when you need to do a monthly firedrill of 'emergency update this dep because of Z vulnerability' its worth it.
I have no problem with the 6% number for URA. The problem I have is that the 6% never seems to include managers. So when your manager bad hire bungles the OP1, constantly randomizes the team, and then jets to another team in 18 months the manager keeps their stock grant and the poor pleb dev that worked under those conditions gets the axe for their 'poor performance'.
For any action, there's an equal and opposite reaction.
What often happens as a result of such policies is that the weaker or newer managers simply become an unwitting separation/firing mill, or the people who have to be managed out are simply those that are inconvenient in some way for the org, or are too new for the team (the infamous hire-to-fire phenomenon).
Also, as in this leak, what happens is that in order to reach a 6% URA target, they may have to put 15% of people through performance improvement, and some of these people simply leave Amazon to successfully work for Google and Facebook, defeating the notion that they had unrecoverable performance issues to begin with.
At the end of the day, if success in improving performance, is a fail in the metric, isn't that itself a fail? (This in turn provides an incentive for the managers to finish up anyone they put for performance improvement, making the whole process a sham, since it's virtually impossible to get out of.)
I think the fact that all Amazon corp employees still sign a non-compete yet there is an LP titled "Strive to be Earth’s Best Employer" whose definition includes "Leaders have a vision for and commitment to their employees’ personal success, whether that be at Amazon or elsewhere." highlights what the company actually values, i.e. internal propaganda and external litigiousness. Good luck quoting LP's to an Amazon lawyer.
One could be extremely generous and assume that the LPs date from before Amazon sprawled into so many market segments (ie. it looks rather different if the noncompete only constrains a former employee from working for other online book retailers).
Is there a revision history for the LPs? In fact, have they ever been revised at all?
The phrasing in the quote reads like corp speak madlibs. For instance, I don't see how 'Earn Trust' by writing code aligns with the stated definition of the LP.
'Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.'
When your promo/PIP process is almost exclusively framed in terms of these tenets it makes more sense why "suddenly people understood what you meant". Specifically, do what i want or these will be the checkboxes you will miss on the next promo cycle.
