That's the appealingly-cynical view, but it's not really correct.

Of course keeping payroll down is important if the business is going to remain profitable, but the other piece of the profitability puzzle is productivity, and in this case that's the more important piece. Raises and promotions are limited because if they weren't there would be no financial motivation for good job performance, because why wouldn't you just give raises and promotions to everyone, or at least everyone you like? Creating that motivation is why raises and promotions exist. The best way to keep payroll as small as possible is not to give any raises or promotions. The best employees will leave and you'll be dealing with a continual treadmill of cheap replacements, of which only the worst would stay, and productivity would be in the toilet, but it would minimize payroll.

No, the reason for giving raises and promotions is the same reason that raises and promotions must be limited: to create an incentive for high performance, and to be very specific, an incentive for outperforming other employees.

In Google, and most large companies, peer feedback is the largest part of the evaluation, so helping everyone else is almost certain to generate lots of good feedback... though if you do it so much that you don't get your own work done and that causes problems for your peers, you will get that negative feed back, too.

As to your question about defending their reports... what alternative approach would you suggest? Let the manager just decide without anyone testing those decisions? Not only would that give managers way too much power, it would result in the corporate equivalent of grade inflation. Why wouldn't I just always rate all of my employees outstanding, except those I dislike and want to fire? There needs to be some pushback, to ensure that the standards are applied as fairly and as accurately as possible. Bonus, raise and promotion budgets are all finite, both because money is finite and because there needs to be some scope for rewarding performance.

A common (perhaps near-universal) strategy is to define a curve and require that curve to be applied at the level of a large-ish organization, say, several hundred employees. Among a large population, you'll have all levels of performers, ranging from those who need to improve or be let go to those who exceed all reasonable expectations. Experience shows what the percentages of each typically are, so, you define a "grading" curve and require that the ratings allocated roughly follow that curve, with any exceptions well-justified.

But, inevitably, because managers generally like their reports and want to reward them, you end up with too many people with top ratings, and this is where the manager has to be able to defend the rating they think their report deserves in a meeting with all the other managers who need to defend the ratings they think their reports deserve. So, the group talks through each case one by one, discussing the details of the individuals' work and the contents of their peer feedback, trying to achieve consensus. Ideally, you want to get consensus rather than decide by voting, because voting tends to produce horse trading (I'll vote for yours if you'll vote for mine, etc.). But either way, the group has to produce a set of decisions that align with the expected curve, or (more often), a set of decisions that mostly aligns with the curve plus documented rationale for the borderline cases.

Promotions require a similar process, except instead of a curve there's a promotion budget; only so many promotions are available.

If this all sounds tedious and time-consuming, it absolutely is. But it's necessary to achieve a semblance of fairness and accuracy in the application of the performance rubric for each job level.

Neither, really. They didn't eliminate jobs so much as make new rules that mostly eliminated the "Tech Lead / Manager" (TLM) role.

There used to be a lot of software engineers (people on the software engineer job ladder, as opposed to the engineering manager job ladder) who had 2-3 people reporting to them and were considered TLMs. These people divided their time between engineering work and management. Google made a new rule that every manager has to have at least 5 direct reports. This rule has flattened the hierarchy by mostly eliminating TLMs, who all had to decide whether to lose the "TL" part and be a pure manager or lose the "M" part and be a pure SWE. Well, "pure" is too strong. Some SWE managers still keep their hands in the code but they generally don't have time for significant projects.

Is this an improvement? Dunno. There are pros and cons. The TLM role has some significant benefits to a company. It enables the existence of small, close-knit teams where the team's manager is also the pre-eminent expert in the area. Being managed by the expert has a lot of advantages for the reports, especially when it comes time for the manager to defend the team's performance ratings or promotions, because the manager deeply understands their work. It has advantages for the company, too, because in a small team led by the project expert it's impossible for low-performing employees to hide their low performance or blame it on others.

On the other hand, TLMs can end up overwhelmed by the administrative overhead. This can cause them to be less effective as managers because they don't navigate the system on behalf of their employees as effectively. Some of them may not be very good at defending their reports' ratings and promotions because they don't have the skills to do that, even though they deeply understand the team's contributions. It can also definitely make them less effective as SWEs, and these people were generally top-performing ICs (individual contributors) before taking a manager role. Some might argue that any time they spend on management rather than engineering is a waste of their talents.

Pure engineering managers can be and often are better managers. Better at helping their reports develop important non-technical skills and knowledge and better at working the system for their reports. And some top-performing SWEs are such excellent managers that even as good as they are at building stuff, their positive impact as managers is larger yet.

From the upper management perspective, there's another advantage: Fewer managers to train and manage. Managing managers is harder in many ways than managing engineers, because the output of managers is harder to measure and evaluate. Also, managers are officers of the company which attaches greater legal and PR risk to their actions. Having fewer of them to manage is beneficial.

(Saving money isn't really a benefit, at least not the way Google does it. SWEs who also manage people don't get paid any more than SWEs who don't, holding all else constant.)

On balance, I don't think either approach is ideal, and the best strategy is probably a dynamic balance between them that mostly favors managers being managers (though with the rule that all managers must have been highly competent SWEs) and SWEs being SWEs, but with plenty of scope for exceptions where a project needs a small team of 3-4 people and there's a clear leader with deep technical ability and good people skills.

Anyway, Google has pushed the pendulum away from TLMs and as a result there are many fewer managers, and each manager tends to have a larger team.

(Disclaimer: I work for Google. I used to be a TLM but opted to switch back to an IC role years ago, before the rule change.)

It isn't just buzzwords, it's jargon with specific meaning... but your comment highlights the problem, because you didn't understand it.

One part you didn't understand was "bandwidth", which in the management context means "available work capacity". This means it's a discussion about resource staffing and constraints. Also, "align" means there's going to be some two-way negotiation, in this case to figure out whose employees are going to take on what part of the work based on their availability. (Well, probably. "Align" could have been used out of politeness, implying a fictional intention to negotiate when in reality the speaker does plan to dictate.) In addition, the use of "workflow" implies that the plan to be developed isn't just for one project, but for an ongoing effort.

Try translating all of that nuance to standard English, and you'll convert a ten-word sentence into a paragraph or two. Like all jargon, its purpose is to increase communication by compressing a lot of detailed information into a few words that have context-specific meaning that goes beyond their normal English definitions.

Of course, the downside of the jargon is that it prevents those who don't understand the contextual definitions from understanding, causing them to come away with interpretations like "Let's meet after this and make sure you understand how I want that to work."

In fairness to you, I have to point out that often the users of business jargon don't know what it means either, and are just using it to make themselves sound "businessy". That's less a jargon problem than evidence that the company isn't hiring the best people.

It will not kill off most coding jobs, it's probably going to make them more necessary over time.

All this is doing is creating an experience gap. Junior programmers don't get a chance to learn what it takes to ship something. There's a lot of on-the-job experience that's hard to replicate, which seems like a facile observation—if it weren't true, we'd just teach it—but I think it's something that gets forgotten now and then.

LLMs simply do not write good code right now. They don't. It's code that needs reviewing, often it needs refactoring. It requires a lot of supervision, and crucially, it doesn't learn from its mistakes in any meaningful way. So this sounds like a junior programmer but worse—I can never train it to be better, I have to rely on external forces to do that.

How do LLMs get better? By ingesting more GOOD code. But less good code is being written because more of it is being written by LLMs, and there are going to be fewer and fewer good programmers available as time goes on, because as we're discussing, there are fewer junior programmers learning to be good senior programmers.

The issue is that right now, AI Coding agents give the ILLUSION of productivity. They can only automate away the simplest of jobs; every large-scale analysis of whether or not they actually make people more productive shows that they absolutely do not, unless the only thing you count is 'lines of code produced'. But as any experienced programmer will tell you, that's a stupid metric; most good solutions are shorter. They're easier to debug and the maintenance burden is lower.

Anyone that says that a coding agent makes them more productive is saying that entirely based on vibes, not long-term analysis.

I'm not blind to the utility of LLMs; I think they make some things much easier. Learning programming languages is much faster with an LLM to help me. But they still consistently get things wrong and hallucinate APIs and function calls. You absolutely cannot trust anything they give you, and they will not notice that they checked in bad code and need to fix something on their own.

tl;dr Junior programmers will have a rough go of it for a while, but we'll need experienced programmers more than ever. LLMs have done nothing but kicked the can down the road and made future hiring more expensive.

Cite?

That seems extremely unlikely.

All of the other strategies for responding to Trump have failed. Outrage at his antics (which is, granted, the most sensible response) just encourages him and his supporters. Ignoring his behavior just normalizes and enables it. Mockery works best, but direct mockery hasn't been very effective because the GOP leadership and his supporters simply pretend that his comments and language are normal and that the people making fun of him are being elitist. What Newsom is doing actually does work, because they can't ignore either the message or the mockery, but they also can't really attack it because that would obviously and implicitly criticize Trump, too.

The only other option I see is passively waiting for Trump's bad policies to convince the voters that he's an idiot. In fact, they're not going to be convinced until they see the results, but the Democrats need to do something to make it clear that he is an idiot with bad policies so they're positioned to capitalize on souring sentiment, and the normal ways of doing that aren't working. Voters are getting quite angry about Democrat passivity. Ridiculing Trump in this way is working, at least for now, similar to but better than Walz' comments about how Trump and Vance were weird. The effectiveness may fade, and Newsom will stop. Or maybe it'll keep being effective as long as Trump keeps posting his incoherent rambling, which isn't going to stop until Trump himself is no longer relevant. But either way, it will stop being effective, and continuing after that would just make Newsom look like an idiot. There is no way Democrats are going to adopt Trump's style as the new thing, though I hope they will take the hint to move away from repetition of carefully-wordsmithed and thoroughly focus group-tested talking points and toward something a little more authentic.

I was using the term "dialer" to refer to a native application that responds to a challenge issued by a network access control server on a LAN or WLAN. When the user connects to the ISP through a LAN or WLAN, the user's machine is initially quarantined behind a captive portal offering only downloads of the dialer for Windows and macOS. The dialer then assesses the device, ostensibly to ensure that an antivirus approved by the ISP is running, and relays this information to a server that grants access to the network. Users of iOS or Android can download the ISP's dialer through cellular data.

If "dialer" is inappropriate for the client side of a network access control protocol, what term is appropriate?

See also "Trusted Network Connect" on Wikipedia.

I may or may not be to the right of you. I'm a classical liberal, what some call a neoliberal, and I usually describe myself as a pragmatic libertarian.

Indeed.

And yet they never seem to see the humor in it!

I think a lot of us are just waiting for MAGAts to realize that the corrupt, fascist, populist regime they've chosen is really not what they wanted. They won't listen to us until they come to that realization on their own, and until they do, the GOP is just going to continue its slavish devotion to Trump.

Uh, no. I, for one, am writing a lot of emails and letters to my (GOP) representatives, trying to remind them that the Constitution they've sworn to uphold really matters and that they shouldn't just let Trump walk all over it. They're ignoring me, and I'm sure they'll continue to do so until their constituents wake up. I'll keep sending the emails and letters, though.

Newsom isn't turning himself into a clown show, he's just playing, to shine a light on how big of a clown show Trump is. As soon as everyone stops ignoring the Trump's illiterate and incomprehensible posts, Newsom will stop, because for him it's just a performance to poke fun at Trump. For Trump, it's who he is.

Newsom's posts say nothing one way or the other about whether he can beat Trumpism, nor whether he would be a good president. But he's doing a public service by highlighting the way Trump gets sanewashed by the media and his idiocy ignored by his followers.

Unless the cable and fiber ISPs for your area require a dialer application that is exclusive to macOS, iOS, genuine Windows, and certified Android.

Welcome to my Foe list. Not because you disagreed with me, heck you might even have had some good points. But you chose ad hominem rather than productive engagement, which makes you not worth talking to, so I'll just have /. hide your posts from me.

How about a one-year study instead?

Man, I'm not asking for a lot, just technology that's almost 200 years old, is super efficient at moving people and things even over long distances, and that can also be very lucrative. You don't need to invent shit, just lay the track down and run some goddamn trains like we used to.

One of my neighbors whoâ(TM)s in his eighties wound up switching to a recumbent tricycle because he had balance issues. Which sucked. But the tricycle is awesome and probably would be comfortable for you to sit on.

Nevertheless, you should ride what works and is enjoyable for you. The point is not to punish 80-year-olds by forcing them to ride bikes they arenâ(TM)t safe on. I have an Azore city bike that I really like. Wouldnâ(TM)t mind still being able to ride it at 80.