By pitting them against each other I get much better design work, and then I've been happy to hand off the design file to Opus 5 for implementation. But some of the assumptions Opus 5 makes leaves me wary of relying on it too strongly. This might be fixable by prompting it to ground its answers.

If that's true, then I would think the emphasis in code review should be more on test quality and verifying that the spec is captured accurately, and as you suggest, the actual implementation is less important.

That is demonstrably false. As I type this comment I can hear the sounds of excavators digging out a station for a new subway line in Toronto.

I'll echo what others have said - if social media is dead, it's because they killed it themselves.

They do occasionally show up on eBay and Reverb though.

I'm personally more likely to trust Marketplace than not.

"Gamma" as a word is sciencey, which I like, and swapping out Netflix for Microsoft seems reasonable to me.

Around that time, whenever a new BlackBerry device was rebooted, it would take about 45 seconds for the OS to fully boot and become usable. I'm making up the actual times in this story because I can't remember the exact details now. Like in this video, the oldest devices would start up nearly instantly, but the boot sequence for modern devices was agonizing. Especially when you were an engineer trying to run a test that required rebooting the device!

One day, a pair of engineers finally became annoyed and curious enough to look into it and profile the problem. They found that a substantial portion of the boot time was spent parsing XML files that contained descriptions for device themes - that is, information about colors, icons, and text styles that users could choose from to customize their device. Something like a full 15 seconds was spent just on this one feature as part of the boot sequence!

So what happened? I suppose that no other engineers felt they had the responsibility or the time available to look into the long boot times until that point. But imagine being an engineer at a company like Microsoft, and one day saying to your manager or product manager: "Hey, can I spend a week on understanding why it takes a full second for Terminal to boot on Windows and see if we can speed that up?" How many managers are going to be enthusiastic about that when they're staring down a kanban board with enough tasks to fill 4 quarters?

The only reason these engineers at BlackBerry were able to look into the bootup times was because they didn't have to answer to anyone responsible for product. The team lead for this team at the time was "Engineer #2" at BlackBerry who had written all the apps for the first devices. His team was given permission to pursue whatever ideas or prototypes interested them, so they had the breathing room to chase leads like this that wouldn't necessarily pay off.

So part of the answer is that I don't think we as an industry are prioritizing performance. Once the performance is good enough, it's time to ship and move on to the next feature. But the other side is that we're building in more dynamic behaviour to our software. More customization, more flexibility, more behaviour that's defined at run-time. And this all probably makes software more useful and makes it easier for engineers to build more complex software. I think it's a similar kind of trade-off to choosing between python or Rust for a tool you're working on. What kind of performance do you need, and what kind of developer experience do you want?

As I recall, the development cycle for Storm wasn't two years - it was less than a year. At that point it was the fastest cycle that RIM had ever had for a device, and it was done at the request of Verizon. Back then the iPhone was still an AT&T exclusive in the US market and Verizon demanded something from RIM so that they could compete with it.

I'll echo the fact that nobody I knew internally seemed interested in using Storm as a primary device. I think everyone knew it was junk. But Storm 2 went a long way towards a device that I would actually be interested in using.

[1] https://pubmed.ncbi.nlm.nih.gov/33556972/

I ended up installing this Chrome extension to block the "Hot Network Questions" parts of Stack Exchange because I found that I was getting distracted by them too often.

https://chrome.google.com/webstore/detail/stack-block/oaimjd...