Staff+ work is not that much (exclusively) coding anymore, but identifying correct big things to work on and keeping focus on it, making Bob and Steve from different teams talk to each other instead of building the same stuff twice, making opinionated decisions on things, blocking harmful initiatives, finding elephant in the room and saying things out loud that no one wants to say etc.
It's not really the work that LLMs currently do. I mean sure, maybe if you plug an LLM to read all emails and slacks and zoom transcripts of the entire company, it could do it at some point in the future. But would it have the same amount of influence compared to an industry & company veteran who has the company specific knowledge and experience that is nowhere written down?
Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects. Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed? Why going through the pain?
IMO telling "we deprecate now and let's see when we remove it" is counterproductive.
A better way: deprecate now and tell "in 12 (or 24?) months this WILL be removed".
After 12/24 months, cut a new semver-major release. People notice the semver-major through the dependency management tools at some point, an maybe they have a look at changelog.
If they don't, at some point they may want to use a new feature, and finally be incentivised to update.
If there's no incentive other than "do the right thing", it never gets done.
Having said that, I think LLMs are really going to help with chores like this, if e.g. deprecations and migration steps are well documented.
Alternative option: create a codemod CLI that fixes deprecations for the users, doing the right thing automatically. If migration is painless and quick, it's more likely people will do it.
> Fixing deprecations is unfortunately the lowest prio of any kind of work for majority of the projects.
... and the right answer to that is to make it entirely their problem.
> Part of the problem is probably lack of pressure to do so it if the timeline is unclear. What if this is actually never removed?
In this case, the warnings said exactly what release would remove the API. Didn't help.
> Why going through the pain?
Because you're not a feckless irresponsible idiot? I don't think it's an accident that the projects they said didn't react were an overcomplicated and ill-designed management layer for an overcomplicated and ill-designed container system, a move-fast-and-break-things techbro company, and what looks to be a consolation project for the not-too-bright.
You probably get an extra measure of that if you're operating in the Python ecosystem, which is culturally all about half-assed, 80-percent-right-we-hope approaches.
The right answer is to remove it when you say you're going to remove it, and let them pick up the pieces.
It also helps if you design your API right to begin with, of course. But this is Python we're talking about again.
> After 12/24 months, cut a new semver-major release. People notice the semver-major through the dependency management tools at some point, an maybe they have a look at changelog.
> “Take Paramount-Viacom-ABC-Disney, for example,” he said. “Disney makes the movie, Joel Siegel of Paramount-owned ABC-TV gives the movie a rave review, and Disney subsidiaries Blockbuster and McDonald’s promote the video release of the movie in their respective stores with mail-in rebates and Happy Meal action figures. It’s a win-win scenario.”
After rolling out a bad ruleset update, they tried a killswitch (rolled out immediately to 100%) which was a code path never executed before:
> However, we have never before applied a killswitch to a rule with an action of “execute”. When the killswitch was applied, the code correctly skipped the evaluation of the execute action, and didn’t evaluate the sub-ruleset pointed to by it. However, an error was then encountered while processing the overall results of evaluating the ruleset
> a straightforward error in the code, which had existed undetected for many years
Yeah the example they gave does feel like pretty isolated unit test territory, or at least an integration test on a subset of the system that could be ran in isolation.
From newspaper reporting on this, they are rolling back a software update. I wonder what was the original cause or the update? How often are flight computers software updated and why?
This ELAC version is 100-something, and the A320 first flew around 1988. Why the updates - for example, there are updates to flight control law transitions, like after 1991 where the aircraft would limit flight control inputs during landing, thinking it would be preventing a stall - because it would not go into the flare law appropriately. See https://en.wikipedia.org/wiki/Iberia_Flight_1456
The cause could have also been an extra check introduced in one of the routines - which backfired in this particular failure scenario.
In my first big job in a big legacy company, 30% of ongoing effort was "how to implement this feature which needs a database without a database".
We also paid some security company to use it as a proxy in front of our server to implement some server redirects because it was simpler than configuring our own servers. Simple one-liner conf changes were a week of emails with support staff.
Speaking as someone in the US, I've worked at multiple companies (some startups, some small businesses, some larger) that have either outright imploded or had mass department-level layoffs inside that 1-2 year timeframe. Some of them I would have stayed at longer than 1-2 years if I had the choice. I'm not claiming it's universal by any means, but there is a lot of volatility at US businesses in my personal experience.
And as usual, the employees get blamed. Maybe people wouldn't jump ship if companies didn't lay people off with reckless abandon, or hire sociopathic bosses to manage people, or screw them out of raises, or overwork them, or lie during the interview process.
The little people are going to do what they need to do to survive. If these multi-billion or even multi-trillion dollar companies feel some type of way about it, well, they're the ones with all the power, not us. They're more than welcome to change the culture at any time.
Companies at that level (fang,trillions) are like "alien" intelligences, like a form of slow moving AI - no human being has the ability to influence or change them in any significant manner.
Serving different contents to search engines is called "cloaking" and can get you banned from their indexes.
reply