Seems reasonable to me. The article doesn't say to trust the LLM blindly, as many early commenters seem to think, instead it suggests an evolution to a set of practices that provide similar guardrails at a faster cadence.
The argument in the comments about lack of determinism is just weird because humans are not deterministic machines and they're arguing about keeping one non-deterministic thing in the loop but scoffing at another.
And the pedantry about reviewing compiler output is just as silly. Yes it happens but in the broad world of software engineering unless you're working on the tools themselves, or chasing a really tricky bug, no one looks at the byte code.
For guitar I followed Justin up into his intermediate level stuff but then switched to in person lesson and they made a big difference for me. I think I got lucky with my first teacher though, as I've not really gelled with teachers I worked with later.
I'm obsessed with Strongman style functional lifting.
One side of my brain agrees that's a dumb way to judge anyone but then when I think about the accepted filtering mechanism they really aren't any better or any worse. You cannot interview everyone and ultimately you're looking for some combination of competence, alignment, drive and social fit. Filtering on where you worked previously or where you went to school or whether you can pass some coding challenge only partially fills in the matrix. And the size and shape of the organization can drive how much people in the hiring loop look at each data point. This senior engineer's ideal for alignment and social fit probably favored people who think like them or their department's head.
I don't think you're wrong so much as you've tread into some semantic muddy water. What did the OP mean by 'inevitable', 'political' or 'everything'?. A lot hangs on the meaning. I lot of words could be written defending one interpretation over another and the chance of changing anyone's mind on the topic seems slim.
I've had them. They're fine. But this is overselling the variety angle. The meat eater equivalence of forage like this would be game animals. In my experience and extrapolating, the taste difference between game and farm animals is generally greater than among the green vegetables.
I think most actually know and don't think it's all that much different from what other have done for decades. I'm not saying they are correct to think it, just that they do think it. They think it's refreshing that the corruption is in the open. It's a societal boy-cried-wolf numbness. People are tired of the of finger pointing and screaming about every thing and now don't listen when the real stuff goes down.
I believe it was always more myth than fact. There's always been rough edges in Apple products line. If anything its more an indication of where the real focus is now. And it's not iOS.
The standard screen was 80 by 25. There were two addresses you needed to know 0xb000 for monochrome displays and 0xb800 for color. For monochrome you could just blast characters/attributes to the address and everything looked great. For color you had to add a little bit of assembly so writes didn't happen when the monitor was doing certain things (or else you would get some flickering). The little hacks were all well known.
Then you could build your own 'windowing' system by just maintaining separate screen buffers and having a little bit of code to combine for buffers when writing the actual hardware.
In the early days everyone code was synchronous and code would start listening for keyboard events and react and repaint in a very ad hoc fashion. Mouses made things a bit more complicated as you needed to maintain a persistent model of the UI to process their events.
So the UI code was simple and easy to work on, but you had to squeeze these programs into tiny memory footprints so you would spend a lot of time trying to find more memory. One of the bigger projects I worked on had a memory manager that relocated blocks to create contiguous space but since there was no OS support for things that like the code was actually updating pointer in the heap and stack - which was a great source of complicated bugs. Whoa onto anyone that tried to use a linked lists in such an environment.
But yeah, it was a fun time.
I believe the pedantry label was sufficient acknowledgment of fact, while also pointing out that in the context of the larger conversation we are really talking about whether his leadership decisions led to success.
I hope this was more of a philosophical musing than career advice. I've not worked at every big company, but I have worked at a few.
I agree that in the context of a big companies, "done" is a metric; and career success at that big company depends on moving the metrics those leaders track. But in my experience modern big companies also look at peer review and if you're always committing junk, those reviews are not going to be kind. So like everything, it's a balance. Please your boss by closing tickets. Please your peers by writing good code.
Spotify has not viewed itself as a music company for longer than that. It's a platform for audio. And, while there are still music first people at the company, they are not in the power positions that they used to be.
The transition didn't start when they laid off Glenn MacDonald, but that sort of cemented it. They had already gutted curation before that and by this time you were far more likely to find people talking about AI in the halls than music. If you've never heard of Glenn, check out his book: "You Have Not Heard Your Favorite Song: How Streaming Changes Music." Or his old online projects at https://everynoise.com/.
In those early days the Spotify user experience needed to try and differentiate and put up barriers to being copied. Later it suffered from being purely metric driven and tracking things like user-engagement thinking it's a proxy for happiness with the platform. And then later still they start to mostly care about the cost of delivery.
The argument in the comments about lack of determinism is just weird because humans are not deterministic machines and they're arguing about keeping one non-deterministic thing in the loop but scoffing at another.
And the pedantry about reviewing compiler output is just as silly. Yes it happens but in the broad world of software engineering unless you're working on the tools themselves, or chasing a really tricky bug, no one looks at the byte code.