He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.
But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.
The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.
You measure the output of one person while ignoring the cost they impose on their team.
If I generate 10 PRs in a day but three engineers now have to spend the next two days reviewing them, figuring out what I changed, correcting bad assumptions, debugging regressions and explaining why half of it needs to be redone, I haven’t become 10x more productive. I’ve just moved the work onto other people.
Worse, I’m consuming the time of the people who are usually the hardest to replace and whose attention is already scarce.
That’s why PR count, lines changed or features “completed” are terrible measures of productivity. You can make your own numbers look incredible while reducing the throughput of the entire team.
Taken how some companies award promotions and bonus this is actually a double win. You not only improve your own numbers but also make this of your competition worse! /s
Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.
Just look at how they're merging ~300 commits a week into bun.
Natural consequence: Then they never grasped the concept of computational complexity.
O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!
The missing part of mathematics education, IMO, would be to focus more into developing the intuition of what something means, instead of the current focus on getting some (numeric) results.
But the core question of “how does this behave as N -> \infty?” is asymptotic behavior (ie: limits) which were developed for calculus and are very much part of the foundational calculus canon.
I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).
Not necessarily, great engineers do also ship temporary code they didn't have the time to trim.
Our process is of 1) make it work, 2) make it right and 3) make it fast; not necessarily that engineer had time for the 3rd step.
AI disease is encouraging "sketchy process and minimal checks on the software quality." QA has been eliminated from my team, and the QA engineers that are left have been declared to be developers now.
Gotta move fast, and I guess making sure the stuff we ship works was "slowing us down."
i've gone this route a few times in my career, it's very stressful and involves angry/panicked people and many all nighters. Also, the glory fades fast. would not recommend.
Hiring pipelines that tested the wrong thing have existed for years but the problem is magnified 10x when you test for something that weakly correlates with ability at best which an AI can do better than a human.
This is leading to stuff like incompetent junior-level engineers being hired as principals.
That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.
You assume those people haven't already left, been kicked out, or were hired to begin with. We're not in a rational job market right now.
You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.
Trace the increase back to specific deployments, call out those teams, and make them fix their shit.