> This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available.

does anyone know where these "detailed root cause analysis" reports are shared? is there maybe an archive?

They get posted to the incident log (https://www.githubstatus.com/incidents/n07yy1bk6kc4) for example https://www.githubstatus.com/incidents/lcw3tg2f6zsd.

There are also monthly availability reports: https://github.blog/tag/github-availability-report/

Would be interested in an article about stopping OOP. I see myself often drifting towards classes and abstractions once my code grows in complexity

This is the video that's been going around. It's a bit long and could have been compacted into a 20 minute video, but if you have the time, it's a good overview for people without a computer science background.

"Casey Muratori – The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025" https://youtu.be/wo84LFzx5nI

But if your point is there aren't any written articles about stuff like this, I agree. If they're out there, they're a bit outside the mainstream.

You go into work and discover that a coworker isn't happy with some code you wrote because they don't like it. They go to your manager and tell them that you're being a problem by writing code they don't like. Your manager, being very skilled in conflict resolution, makes a technical decision to avoid whatever tool you used which caused the problem. In your case it was OOP.

That's it. You've been told. No more OOP.

The manager has figured out what's good for the business and you figure that listening is what's good for your job.

Though honestly, having a manager that's interested in how software is made is a gift. My managers for the last 20 years have all been like "okay, let's do planning poker and everyone make sure that all the fields in your JIRA tickets are filled out."

google richard feldman (roc lang creator) talk about using just functions and data.

don't remember exact title, sorry, but description i used above is close, iirc.

link to the repo: https://github.com/KallDrexx/DotnetSnes

WSA is a great feature for developers. not having to deal with sluggish Android emulators was a big plus for me.

Are you not using an x86 emulator or something? Forget to install or enable your CPU virtualization extensions?

Because the emulator ain't sluggish, and if it is you'd get that same sluggishness with WSA since it's largely the same underlying tech. It's still using a virtual machine and emulation, it's not like a simulator.

i am using an x86 emulator - booting it up takes about twice as long though compared to WSA. Also being able to dynamically resize the Window as need was nice to test different sizes directly within WSA instead of having multiple emulators running

What’s being emulated? You can’t install Arm Android apps in x86 WSA.

Also the foundation for MAUI, the native bindings for .NET are incomplete and broken. Back in the Xamarin days the promise was that "everything you can do natively you can do in .NET" - this hasn't been true for a long time. Most of the new frameworks, especially on the iOS side don't have a binding and Microsoft doesn't have a story for Swift based libraries at all

i can recommend the .NET 101 series on YouTube. If you want to quickly write .NET code you should try the .NET Interactive extension for VSCode