The GitHub website is slow on Safari

Can someone who's worked in an org this large help me understand how this happens? They surely do testing against major browsers and saw the performance issues before releasing. Is there really someone who gave the green light?

The way it works in tech today is that there are three groups:

- Project managers putting constant pressure on developers to deliver as fast as possible. It doesn't even matter if velocity will be lost in the future, or if the company might lose customers, or even if it breaks the law.

- Developers pushing back on things that can backfire and burning political capital and causing constant burnout. And when things DO backfire, the developer is to blame for letting it happen and not having pushed it more in the first place.

- Developers who learned that the only way to win is by not giving a single fuck, and just trucking on through the tasks without much thought.

This might sound highly cynical, but unfortunately this is what it has become.

Developers are way too isolated from the end result, and accountability is non-existent for PMs who isolate devs from the result, because "isolating developers" is seem as their only job.

EDIT: This is a cultural problem that can't be solved by individual contributors or by middle management without raising hell and putting a target on their backs. Only cultural change enforced by C-Levels is able to change this, but this is *not* in the interest of most CEOs or CTOs.

I cannot fully explain to you how little companies care about quality and performance. Feature-mills are a real place.

As someone who has worked in and with large orgs, the better question is "why does this always happen?". In large organizations "ownership" of a product becomes more nebulous from a product and code standpoint due to churn and a focus on short-sighted goals.

If you put a lot of momentum behind a product with that mentality you get features piled on tech debt, no one gets enthusiastic about paying that down because it was done by some prior team you have no understanding of and it gets in the way of what management wants, which is more features so they can get bonuses.

Speaking up about it gets you shouted down and thrown on a performance improvement plan because you aren't aligned with your capitalist masters.

At this point "ownership" is just a buzzword thrown around by management types that has no meaning.

If a developer has to put up a fight in order to push back against the irresponsibility of a non-technical person, they by definition don't have ownership.

The primary goal in deciding upon a tech stack is how easily the organization can hire/fire the people who write the code. The larger an organization becomes the more true this becomes. There are more developers writing React than Rails.

Don't listen to the opinions of the developers writing this code. Listen to the opinions of the people making these tech stack decisions.

Everything else is a distant second, which is why you get shitty performance, developers who cannot measure things. It also explains why when you ask the developers about any of this you get bizarre cognitive complexity for answers. The developers, in most cases, know what they need to do to be hired and cannot work outside those lanes and yet simultaneously have an awareness of various limitations of what they release. They know the result is slow, likely has accessibility problems, and scales poorly, and so on but their primary concern is retaining employment.

In the old days we had the saying: "Nobody ever got fired for buying IBM"

Todays version is: "You will get fired unless you use React".

So every site now uses React no matter if the end result is a dog slow Github.

Bad developers looks at "what are everybody else using?".

Good developers looks at "what is the best and simplest (KISS) tool for this?"

I've had some experience with Google here.

The short answer is: no, they don't. Google Cloud relied upon some Googlers happening to be Firefox users. We definitely didn't have a "machine farm" of computers running relevant OS and browser versions to test the UI against (that exists in Google for some teams and some projects, but it's not an "every project must have one" kind of resource). When a major performance regression was introduced (in Firefox only) in a UI my team was responsible for once, we had a ticket filed that was about as low-priority as you can file a ticket. The solution? Mozilla patched their rendering engine two minor versions later and the problem went away.

I put more than zero effort into fixing it, but tl;dr I had to chase the problem all the way to debugging the browser rendering engine itself via a build-from-source, and since nobody had set one of those up for the team and it was the first time I was doing it myself, I didn't get very far; Google's own in-house security got in the way of installing the relevant components to make it happen, I had to understand how to build Firefox from source in the first place, my personal machine was slow for the task (most of Google's builds are farm-based; compilation happens on servers and is cached, not on local machines).

I simply ran out of time; Mozilla fixed the issue before I could. And, absolutely, I don't expect it would have been promotion-notable that I'd pursued the issue (especially since the solution of "procrastinating until the other company fixes it" would have cost the company 0 eng-hours).

I can't speak for GitHub / Microsoft, but Google nominally supports the N (I think N=2) most recent browser versions for Safari, Edge, Chrome, Firefox, but "supports" can, indeed, mean "if Firefox pushes a change that breaks our UI... Well, you've got three other browsers you could use instead. At least." And of course, yes, issues with Chrome performance end up high priority because they interfere with the average in-house developer experience.

I've seen shops where ownership is used as a cudgel to punish unruly developers. If the task isn't done as specified and on time, the developer is faulted for not taking ownership, but that "ownership" is meaningless, as you note, because it does not extend to pushing back against irresponsible or unreasonable demands.

The answer is enshittification: https://news.ycombinator.com/item?id=41277484

That the optimization pressure imposed by "capitalist masters" can lead to perverse outcomes does not imply that the optimization pressure imposed by communist ones doesn't, surely?

For instance, the GP could be a proponent of self-management, and the statement would be coherent (an indictment of leaders within capitalism) without supposing anything about communism.

This is shockingly accurate - are you a Hubber? :)

Exactly this.

What's that, a Github employee? Not really, I'm in an YC startup.

But I guess the problem is that every single development position has been converging into this.

The only times in my career as a developer where I was 100% happy was when there was no career PM. Sales, customers, end-users, an engineering manager, another manager, a business owner, a random employee, some rando right out the street... All of those were way better product owners than career PMs in my 25 years of experience.

This is not exactly about competence of the category, it's just about what fits and doesn't. Software development ONLY work when there is a balance of power. PMs have leverage that developers rarely have.

I come from Electrical Engineering. Engineering requires responsibility, but responsibility requires the ability to say "no". PMs, when part of a multi-disciplinary team, make this borderline impossible, and make "being an engineer" synonymous with putting a target on your back.

Yet another new account that has only a single comment replying to me. I've noticed this is a pattern.

At any rate your point doesn't make any sense. The same point indicts all leaders, it has nothing to do with capitalism. It's like saying something indicts a specific race of people when it applies to all people equally.

The end-user experience is not of any concern in modern tech. None at all. The only thing that matters is engagement hacking and middle managers desperately trying to look like they're doing anything with any value or meaning at all.

> Good developers looks at "what is the best and simplest (KISS) tool for this?"

Good ol’ SSR - but eventually users and PMs start requesting features that can only be implemented with an SPA system, and I (begrudgingly) accept their arguments.

In my role (of many) as technical architect for my org, and as an act of resistance (and possibly to intentionally sabotage LLMs taking over), I opted for hybrid SSR + Svelte - it’s working well for us.

If the PM was also an ex-developer and has both product management and development skills this happens a lot less. When the PM knows the Engineering and complexity and code debt cost of shipping a feature then they can self-triage with that additional information and choose not to send it to the developers or to consult with dev and scale it back to something more managable.

Its these professional PM's that have done nothing else other than project mangement or PMP that don't have an understanding of the long term dev. cost of features that cause these systemic issues.

It's pretty much the same in every tech firm. When I worked at Facebook this same dynamic was playing out really badly. Amazon on the other hand had somewhat greater resilience against it due to a much tighter feedback loop with the c-suite.

Yep, that works 100%.

I'm still a big believer in "separation of powers" a la Scrum.

There should be a "Product Owner" that can be anyone really, and in the other side there is a self-managed development team that doesn't include this participant. This gives the team leverage to do things their way and act as a real engineering team.

The reason scrum was killed is because of PMs trying to get themselves into those teams and hijacking the process. Developers hated "PM-based scrum", which is not really scrum at all.

What about PMs that were developers but were awful at it and just played the politics game to get that promotion and never have to see code ever again?

I worked with a few of those where it was horrible, because they were incompetent and unwilling to work to improve across all disciplines. But that says more about the individuals.

IMO "Knowing enough to do damage" is the worst possible situation.

A regular user who's a domain expert is 100x a better PO.

This is a very accurate and concise summary of why I can't work in tech companies anymore. Recently I returned for a quick contract to develop a proof of concept app and almost immediately my stress levels whent through the roof. Just the whole thing is a recipe for erroding peoples's ability to produce anything of value.

Yea it can be done, but it requires thoughtful implementations and planning if you are working within a mature system.

We had/have a similar problem where things began with "a sprinkle of js here/there" and then over time those islands became much bigger and encompassed more and more functionality. Entire backend templates were ported to the JS framework and then the page with load and then stuff would pop in after the DOMReady event was fired and the JS booted.

I've been working backwards to remove many of these changes and handle them server side if possible or at least give a better UX while the frontend is getting ready. It's not easy!

In a perfect world, we could run the output of the PHP backend through a JS SSR endpoint and hydrate the few necessary components into full HTML, but unfortunately, many of today's JS SSR tools are only available if you use the meta framework as well.

What's going to be fun over the next year is finally deciding if we should go "all-in" on a JS frontend (using Inertia.js for the communication with the backend) or go back to PHP entirely and try to leverage more browser capabilities. There's not really a right/wrong answer but if marketing want's to keep adding flashy features, having the flexibility of JS would be handy.

> Is it your theory that working on large projects was better when you had communist masters?

It is. Unemployment was virtually non-existant in the ussr, and healthcare was not connected to employment status. So a worker there knew that saying no to their boss was not going to be a life-or-death decision. They might of course be less wealthy and so on but the worst case didn't look as bad.

This is false, striking was illegal in the USSR. If you refused to do work you were an enemy of the state.

If your town didn't meet the farming quota they would starve your entire town.

If you went on strike you would get murdered and sometimes your family would get murdered.

If you deserted from the army or retreated you would get shot by barrier troops.

If you were injured or sick you would be disposed of or hidden on an island.

If you were a female orphan under the age of 15 there was something like an 88% chance you'd be used as a prostitute.

The USSR was terrible for workers. Some of this was hidden by lying about statistics, same as it is today with authoritarian countries.

Are we talking war time russia or peace time USSR? It seems to me that you are conflating the two.