https://mrshu.github.io/github-statuses github has reached the fabled 0 9s of availability
https://clojurians.slack.com/archives/C03RZGPG3/p1775140066084339?thread_ts=1775136165.572479&cid=C03RZGPG3 I'm not sure this is actually the case. Especially if it's a clojure library, I can always pop the hood and have a pretty decent understanding of how a library works. Black boxing library behaviour for the purposes of focusing on core application logic isn't necessarily reflective of how opaque the stack is.
I just meant that I have a certain amount of insight into the libraries I use. The deeper I go, the less I understand. I have no insight at all into the JVM codebase, for example. Not because it’s impossible, but because it’s insurmountable for me. I rely on a chain of trust, and to some extent, a community of trust at the Clojure level. For LLM-written code, there’s no such chain of trust, it’s up to me. But it’s also at the application level, which I should theoretically fully understand. I can’t apply chain of trust to my own code, but vibe coding seems to lean into that mindset.
Well, I put my trust into my past self (foolishly) and my colleagues, I suppose.
gee I wonder if there's a certain "innovation" contributing to a vastly increased velocity of poorly-understood code making it into production that's contributing to this 🤔
it moreso seems to coincide with microsoft acquiring them: https://damrnelson.github.io/github-historical-uptime/
Why is Microsoft unable to keep a functioning product?
SlopHub™ by Microslop©
As recently as today I had to rant for a bit that tech debt has nothing to do with tech, and everything to do with cognitive overhead. I don’t care about code quality or tech debt in some abstract way, only in the way that it impacts your ability to understand the system.
It’s not as such a problem that you’re using a tool to generate code. Libraries are also opaque to you in many cases, and contain code that you don’t fully understand. But how’s your ability to understand your system and its properties?
The MS problem started long before Slop (TM) It started around when Ballmer left
It happens whenever founders are replaced by extractive middle managers that only see the next quarter Counter example: Valve Another counter example: the recent deal between valve and gmod developer
Ben, I think the question that bothers me more is "Why Microsoft always makes things worse, and people still use their products anyway".
"Everybody else merely adopted the slop. MS was born in it, molded by it." Sorry, at this point, I can't add anything constructive to the conversation. Just watching the world burn.
Regulatory capture mostly
But sometimes you do see shifts off crappy products. Like how small startups prefer Linear over Jira
> Why Microsoft always makes things worse, and people still use their products anyway sales == masters of social engineering?
I understand the "sales" part, and the whole "inertia" on GitHub. What I don't get... is for example, GitHub is starting to become insanely "corp". It used to be a place for hackers to share code, and to keep some structure/contribution on forks. Now we have the whole "approval rules" and every new repo on GH kind of asks you to "protect your branch, add approval rules, enable deploy branches, add copilot to this" and then they automatically add stuff that you didn't ask like Dependabot opening up PRs and issues with security stuff...
I can understand why people want that - I don't like how this is pushed as the right way. I remember at my first jobs, there was a huge culture of trust - when somebody opened up PRs, we trusted them to not merge unless there was at least one person commenting "Approved" or "Looks good". This also allows for urgent, security, and bugs to bypass the rules (again, culture of trust)
Contrast to my job right now, that is trying some formal certification and one of the things they asked was for us to force reviews and approvals in GitHub, without any way to bypass that... ... which got us into problems more than once, because we pushed something that broke production and we had to scream for people to review otherwise production would stay broken facepalm
That's infatuation with process which is characteristic of big orgs
Which is an aspect of managerial risk aversion
Eg you can't be held liable if you followed The Process No one got fired for buying IBM, right?
I love how it also shows what Martin Fowler said about architecture. Those bad decisions and cutting corners take months, not years, to show up. From January 19' to May 19, it seems okay, which for most corporate metrics would show an increase in "developer productivity", probably much more code shipped, more PRs, etc. Than from May 19' to January 20' the decline is clearly visible. And after that, it's a nightmare. This is just uptime, but it's hard not to correlate it with the code, and my personal experience is similar; there is a threshold/time in play where those bad decisions are not visible. And than it's worse and worse, and entropy explodes
And the funny thing is, if you are measuring wrong things, you may never realize it. Because if you measure PR/commits/col the more problems you have the more you will ship of the "fixes". People rarely measure how much development time is spend on fixing those as a metric.