[Mg6yDfjp5U]

I recently left Google having worked on a number of projects with various YouTube teams. I think I can explain why it's being handled this way by YouTube.

This is a fairly nuanced/involved issue, so the task of classifying the bug likely made it's way to one of the engineers responsible for the implementation of this feature.

That engineer has already launched this project, and filed it away under their GRAD (performance) artifacts for when promo/annual review talks roll around. There's no motivation for this engineer to waste time fixing this bug because it won't benefit their promo packet, and they are already being put under pressure to launch other projects which _will_ benefit their promo packet.

So they do what they can to sweep it under the rug because that's what the promo/annual review framework (GRAD) incentivizes and rewards.

[throwrioawfo]

I feel like things have become so much more cynical in the last 5 years, in this regard.

I feel like part of it is the "over-systemization" of promos. I see the logic behind it to some extent - if there's a system, it's "fairer"/"more democratic". But, then we end up with ridiculous gamified promo systems.

[campbel]

objective systems become gamified

subjective systems become politicized

pick your poison

[ismailmaj]

I'll pick small company, thank you.

[bartread]

This isn’t a bad approach but it’s not a panacea: small companies can be pretty messed up too, albeit perhaps in different ways.

[manquer]

The impact is local though, it would be only a problem if the median small company is more messed up than the large co.

It not likely to happen because being small there are more threats or market forces to deal with so they cannot do as they please. Monopolies or just economies of scale affords large co and the small number of executives that control them outsized influence - both good and bad.

[doctorpangloss]

Yeah... there are no systems that are not political. Even if you agree objectivity is a thing, someone has to persuade others to buy into whatever that objectivity is, and that's still politics, and not cynical at all.

[anonymars]

This is great. I'd begun to conclude the pendulum swung too far towards "moneyball" and both approaches have trade-offs, but this is perfectly succinct

[BadBadJellyBean]

Why not both?

[lacunary]

it is both because the "objective" system is also rife with subjective judgements

[ikiris]

5 years ago they had the same incentives.

[tmoertel]

But five years ago they had a stronger engineering culture. The old values were rapidly eroding, but some still held.

[tgma]

It's funny whenever you talk to anyone their "five years ago" maps almost to the time they joined the company.

[tmoertel]

For me, it maps to pandemic, which was midway through my time at GOOG. That's when the COVID-sparked Zero Interest Rate Policy caused the company to hire engineers and PMs like crazy. There were suddenly too many new hires to inculcate with the old leadership and engineering ethos—especially via remote work—and the values got diluted, probably beyond the point of recovery.

[wahnfrieden]

It’s not about fairness or democracy (maybe you meant meritocracy?) at all although it’s sold that way to participants - it’s primarily about ownership’s ability to cascade management duties, including mitigating latent negotiation powers by individual workers and groups of workers

[jambalaya8]

Eh, clearcut promo paths used to be a bigger thing in the 90s and they did work for a little while, they just didn't handle exceptions well, and then the whole developed world up and thought they were also exceptions. Certifications used to matter more, now they are so cheapened that you cannot do much without them.

[NamTaf]

[flagged]

[brailsafe]

> This is a prime example of why programmers are not seriously considered engineers.

Seems to me like your comment is simply an example of prejudice.

You're just describing another standardized incentive structure that you're operating in, and using that as a basis to extrapolate that programmers of all kinds—whether they work on a video platform or on machinery that could cause catastrophe if it fails—are implicitly careless careerists who refuse responsibility by nature.

[digdugdirk]

Other fields of engineering usually have a regulated licensure, upon which they can call themselves a Professional Engineer. This gives them the ability to make final approval/sign-off on designs and technical reports. It's most common in civil engineering, where a PE license is required for all publicly funded projects (and most privately funded ones as well, due to local/regional/national regulations) to be approved.

This license requires the holder to uphold code of professional ethics, and makes the engineer themselves be personally responsible for the safety and viability of the design itself. Losing a PE license is rare, but it does happen. The industry board (usually a regional board) can also discipline/reprimand engineers who fail to meet the professional standard - rubber stamping projects, personal misconduct, etc. Losing a license is a huge deal, but even reprimands can have a serious negative impact on someone's career.

In the industry the previous commenter works in their hypothetical would absolutely meet the bar for discipline or reprimand.

[AnthonyMouse]

The incentive structure you're describing is also a major contributor to cost disease.

Every decision to increase the cost of a product is taking that money out of the customer's pocket which they then can't use to buy more nutritious food or medicine or make rent and avoid becoming homeless. Every additional tax dollar spent on inflating the cost of an infrastructure project is one that can't be spent on cancer research or Pell grants or catching pedos. Moreover, that type of "tax" is highly regressive because when you make e.g. housing cost more, only the poor become unable to afford it.

Meanwhile the system you're referring to gives the engineers the incentive to be excessively risk-averse. Give someone the authority to command that resources be allocated to something and liability for not allocating them but no liability for what happens to the people the resources were allocated from and the result is not an optimal system.

[jorvi]

It goes beyond engineering. An account just out of university isn't allowed to sign off on anything, only after a next step can they co-sign, and they need yet another step to be the primary signer.

Depending on the country, there's also a level you need to attain as lawyer to argue in higher courts.

[miki123211]

The problem with software is that software doesn't care about where it's built. Jurisdictions need to balance safety and quality regulation with the fact that you can just make the software somewhere where the regulations aren't so onerous, and most software is made very far from the place where it is used.

If you're making a bridge usable by residents of Springfield, that bridge has to be in Springfield, and it has to be made by Springfield engineers following Springfield laws.

[inigyou]

You also don't need one of these to build a garden shed in many jurisdictions. So there is a spectrum. And the question is, is YouTube more like a skyscraper or a garden shed?

[sixtyj]

The prejudice seems to be everywhere. Unfortunately, to my knowledge.

Eg. architects vs construction engineers vs land surveyors vs construction designers vs urban planners… anyone of them thinks that their profession is more valuable than the others…

[zelphirkalt]

By now there seem to be unfortunately more careless careerist programmers on the job, than dedicated engineers. In a proper CS degree we do learn about engineering methods. It is up to us to also make use of them. Someone who graduated from a bootcamp likely will not have the tools to actually engineer this stuff, unless they got some prior experience in engineering.

[throwup238]

> You're just describing another standardized incentive structure that you're operating in

Yeah, that’s the point. That incentive structure includes going to prison, and employers aren’t willing to die on that hill because it exposes them to insane liability if they go against a certified Professional Engineer.

[daveguy]

It's because the first sentence of the American Society of Civil Engineers code of ethics is:

Members of The American Society of Civil Engineers conduct themselves with integrity and professionalism, and above all else protect and advance the health, safety, and welfare of the public through the practice of Civil Engineering.

The first tenant of a software engineers code of ethics is:

fuck it, make the boss some money.

Or, formally, according to the ACM:

Contribute to society and human well-being.

Which means fuck-all and includes absolutely zero enforcement like it does for real engineering professions. So do us all a favor and don't whine about our discipline's lack of standards while dipshits who call themselves software engineers are tokenmaxxing a pile of shit and SEO optimizing manipulative user environments for profit.

[j45]

I understand the direction of your comment, engineering doesn't guarantee security either.

Hubris is the single biggest downfall, whether it's pegged on insecurity, or a false sense of knowledge, superiority or entitlement.

The very best and most experienced people I know have deep expertise, and maintain a healthy mistrust of their own work to keep an eye on it and improving it.

Real world experience and run history is a big thing, and people can re-learn the lessons of the past over and over with their egos, or also be open to learning from others to learn quicker.

[HenryBemis]

It's not hubris (for the engineer) in this case though. It is the fact that company X knows that its dept Y can thrive with 10 engineers, and stay afloat with 5 engineers, so the magic number is 5. And then it is down to the individual to convince their manager (or resign) that problem_A is bad, but problem_B is worse, but not in my P&D objectives.

  The hubris comes from the fact that the CEO doesn't hear the problems that Directors don't disclose.
  The hubris comes from the fact that the Directors don't hear the problems that Senior Managers don't disclose.
  The hubris comes from the fact that the Senior Managers don't hear the problems that Managers don't disclose.
  And Managers simply don't care to hear the problems that Engineers face because "shuddup and close that Jira ticket within 48 hour or else".

I am ~50, I have worked (now..) 20? 20+ years in Audit/Compliance, and I laugh-cry inside.... and I am NOT surprised when I read about cases like this, it's another day in the office/life..

(definitions)

The terms hubris, ate, nemesis, and tisis originated in ancient Greece and had specific meanings and roles in everyday life.

  Hubris
  “Hubris” was a fundamental concept in the lives of the ancient Greeks and was used to describe someone who overestimated their abilities and behaved in an arrogant and offensive manner toward others, toward the laws of the state, but above all toward the gods.
  According to ancient beliefs, such acts of hubris offended and enraged the gods.

  Ate
  “Hubris” consequently provoked the intervention of the gods, and especially Zeus, who sent “ate”—that is, a clouding or blinding of the mind—upon the hubristic person.

  Nemesis
  “Ate” led the hubristic person to commit further acts of hubris, until they committed a grave folly or fell into a very serious error, which provoked “nemesis”—that is, the wrath and vengeance of the gods.

  Tisis
  Next comes “tisis,” that is, the punishment and ruin or destruction of the person who committed hubris.

[kshacker]

Have seen this so many times. And like you, having spent decades in tech, I know the cycle well. Some engineers know the problem today, but the directors will arrive at the same conclusion / concern 1-3 years later, when it becomes obvious that ... "oh this was wrong all along". But to be fair to them, they are dealing with a 1000 problems, not just this one, and that's where the management hierarchy you describe is completely liable (if someone could hold them liable).

[vintagedave]

An example of prejudice? What an extraordinary statement. It’s an example of ethical, competent, responsible professionalism.

The ‘incentive structure’ is non-financial and based on the ethics of valuing other humans. This is a professional duty. To even call it a ‘incentive structure’ feels like it’s missing the point.

[djmips]

The comment is prejudice to conclude from the Google Engineer's supposed thought process as fact and to say that it's an example of why he isn't an 'engineer'. But you can find classic engineering fields where due process is ignored due to systemic pressures - like the Challenger incident. They were engineers but the system was broken. So it's not good enough to spit on the ground and say this is why they are not engineers.

[ruined]

consequences like delicensing, and civil or criminal liability, are all significantly financial.

the ethical objectives are supported by disincentives, offsetting the financial incentives to misbehave.

and none of that exists in software engineering (yet).

[abustamam]

While I do think there needs to be regulation of some sort for SWEs, I can't fathom how it'd be enforced. Non-coders can use replit to build whatever they want and sell it to whomever they want. That kind of scale doesn't exist in the physical world.

[UqWBcuFx6NV4r]

The prevalence of calling software development “engineering” was 100% a con job by either self-important nerds or the companies pandering to them in tight job markets.

[zelphirkalt]

That's why trains work, but Google's shitty YouTube often does not: Terrible, terrible video player, tons of crap on the page, broken buffering all the time, huge memory and CPU hog, need to log in to even watch a video if using a VPN, insane key bindings that are switched around depending on full screen mode or not, stupid and manipulative ads that only the uninformed or simple minded can tolerate, and the list goes on. Found a bug? Keep it! You won't reach another human at Google being to tell them about it anyway!

[Yajirobe]

I find YouTube player better than any other online player

[zelphirkalt]

I find even standard HTML5 player better than YouTube's player. So many issues with YouTube's player. Sometimes not even the play button works properly.

[chii]

> That's why trains work

and that's why trains work but you have to pay a higher price to use it, while youtube is shitty, and breaks often, but it's free to use.

It is about the trade offs - not the trade offs that someone talks about passively, but actual action based trade offs; ala voting with their feet.

[chiefalchemist]

> but it’s free to use

This is false. Nothing is free.

We watch ads. We are tracked like animals. That time, attention and loss of privacy *is* payment. For this, it’s reasonable to expect a service that aspires to rise above shit-show.

[kmoser]

Is free software free?

[dtech]

You pay either just with money (Youtube premium) or by watching ads...

[inigyou]

And if you have YouTube Premium and don't have Sponsorblock, you're still watching ads.

Which proves something about ads: there's a law of conservation of ads. If you're not claiming the ad space, your upstream suppliers will.

[mlrtime]

NYC subway has tons of ads and is constantly have problems, this thread comparison is horrible.

[Root_Denied]

>my engineering licence would be revoked and I would be kicked out of the industry.

This isn't because you're a "real" engineer, it's because of regulation and industry licensing around specific engineering disciplines that didn't exist until the start of the 20th century. Railroad engineers in the 1800's didn't have the same set of regulations to follow, or the same liability for mistakes.

Software engineering could have similar regulation and licensing set up, though I think you'd find it to be an impossible uphill battle in today's world against the lobbying power of the big tech companies.

[term333]

I think the general hacker culture of most programmers prevents this. There's an undercurrent of anti-establishment, anti-authority, anti-management, etc... To think that the industry might choose to self enforce a license system seems very unlikely.

[jongjong]

I've come to dislike hacker culture. Worst part is that when the hackers succeed with their objectives and take over systems; they become the authority coordinating others and they are often 10x worse than the authorities who came before them. They just focus on extracting money for themselves, pulling up the ladder behind them and building moats instead. There's nothing anti-establishment about it at the end of the day, they just join the establishment and make it much more oppressive for the next generation.

[elzbardico]

Classical example:

Bill Gates who became a billionaire out of writing software built a company that always had as a mission commoditizing software engineering work

[numpad0]

I think another reason this hasn't happened is sheer complexity of the modern software stack. No one fully understand how everything works, in principle or in details. You can't certify someone or establish principles for things no one understands anything about.

[classified]

That's just laziness. Analog systems are even messier, but they have procedures and regulations that keep the catastrophes to a minimum.

[ungreased0675]

It’s because they’re a “real” professional.

Professionals (members of a profession) self-police, something software engineers don’t do.

[Root_Denied]

So no one working on railroads before 1907 was a "real" professional? That's more than 100 years after the railroad was invented and took off.

The Bar exam in the US didn't start until the 1780's, so lawyers before then weren't "real" professionals either?

It's a ridiculous argument.

A better one might be that the externalities and opportunities for software engineering to kill people, or be directly tied to deaths or negative outcomes, didn't exist or weren't well enough documented until recently. As an immature field/industry that's not surprising, but it does point to a responsibility by the community to push for standards that don't currently exist.

[miki123211]

Software engineers have a widely-shared belief that most software issues are far less severe than those found in civil engineering. Even a security breach — arguably the worst issue there is — rarely results in any meaningful consequences for those whose data has been breached.

I don't think this belief is entirely justified, but as programmers, it's really hard to predict when our actions suddenly become life-threatening, so the belief persists.

My college ethics professor told us a story where a few people died at some concert somewhere in South America, because a software developer at a data analytics company pushed a config change that made all apps with their SDK crash on launch, and that included the ticket app needed to get into the concert venue. The mob, when learning that they wouldn't be seeing their favorite artists due to a software bug, got very agitated and trampled a few people to death.

[classified]

> at a data analytics company

So it wasn't even anything related to the app's purpose, it was a frivolous surveillance SDK that got people killed.

[fathermarz]

I think there is a fine line. YouTube is not critical software and no one’s life depends on the safety (putting mental health aside) of the code running. Some software engineers do however write code that is critical, but to your point, I don’t think they are ever considered liable.

I went through an acquisition as a Canadian software developer getting acquired by an American company. They wanted us to be called engineers like the rest of their SWEs but in Canada it’s a protected namespace. It’s illegal to call yourself an engineer without having the ring and the papers. Which personally I can appreciate.

[cess11]

Once I worked in a company that had an ex-Googler on the board, who insisted on calling us engineers and wanted us to call ourselves that. In swedish, of course, 'ingenjörer'.

It's not a protected title in Sweden, but we still refused, because we were nothing like engineers. We were a minuscule team of mostly self-taught hackers who happened to be employed to solve business problems in a system for managing other companies and their customers. I had some idea of the rigour of engineering but my colleagues did not, still, they also weren't willing to appropriate the title.

This lead to meetings with this person being quite uncomfortable at times, embarrassing even. To me it was an obvious sign that they were unfit for managing roles. Two thirds of the team, me included, resigned at the same time after they had been increasingly active in the management of the technical department.

Since he was on the board the CEO could not get rid of him even though he knew that this person was destroying the dev team.

[1313ed01]

I worked for several American companies in Sweden an all of them insisted on calling us engineers. Many I work with happen to be engineers, but I dropped out before getting my (computer) engineering degree. It's embarrassing. I would never call myself a software engineer or any other kind of engineer (or a doctor or lawyer or anything else I am not).

[cess11]

If I must I call myself a software or systems developer. I make changes aimed at some improvement to software systems involving machines and people in a way that is more like a craft than engineering. In my view I'm closer to a plumber than someone with a degree in technical engineering. I take some inspiration from engineers, but unlike them I work in an environment where simulation can be as good as the real thing, because both are virtual, and simulation is exceedingly cheap. It is not when you're building an ocean going ship or a bridge or a nuclear reactor.

I can also tell my tools to automate my work once I understand it well enough.

One of my more senior colleagues at that company called himself a 'fixer', because to his understanding, what he did was fix things.

[m00x]

Youtube should consider their engineers responsible for the software they write. Big companies these days are just bureaucracy tricks and politics. There's a small handful of real talent, but they're quickly moving to new startups.

Also, I'm Canadian as well, and almost everyone calls themselves "software engineer" these days. You just can't say P.eng. in your title. You could be forced to remove it from linkedin/etc if you're called out, but it rarely happens.

[eldaisfish]

Your latter point is legally incorrect. The protected term in Canada is “engineer”. If someone calls themselves an engineer without a P.Eng, that’s an offence.

[fathermarz]

Thank you for the education. What is the consequence of an offence?

[eldaisfish]

at least in Ontario, fines, starting at $ 25,000.

[rvba]

I disagree. People's lives depend on money earned from youtube.

[fathermarz]

Revenue generating services aren’t the same as critical infrastructure. This bug, I would argue, does not hurt creator’s revenue in a substantial enough way to call it “safety”.

[abustamam]

People's lives depend on money earned from lots of things, criminal and otherwise.

[dietr1ch]

> This is a prime example of why programmers are not seriously considered engineers.

Yup, most don't have the spine to stand up for their moral as they grew up creating low-stake toys. On top of that we have been unable to establish the rigour (proofs, automated-verification, proper design thinking beyond the next 2 quarters) and doing so is really hard and often doesn't have drawbacks comparable to losing speed against teams that just keep throwing stuff at the wall.

[HelloMcFly]

"The rat is always right." - B.F. Skinner.

When the rat presses a lever, don't blame the rat. This is super reductionist of course, but I always keep it in mind.

[bagels]

It's worse than that. Google will get rid of you if you are just fixing bugs. Ergo, the people who are inclined to fix are forced out or forced not to fix.

[lostlogin]

> because of a performance review my engineering licence would be revoked and I would be kicked out of the industry.

Does this happen because train companies just decided to care or because regulators got involved? I believe it was the later. Regulation is often derided here on HN but good regulation does improve things.

[inigyou]

Europe has the Cyber Resilience Act and of course the more well known General Data Protection Regulation. They do not mandate licensing but they do establish liability when something goes wrong

[consp]

I am pretty sure my job would be on the line if I neglected to report a security issue. It is Google's incentives which are not aligned.

[sourdecor]

Engineering and math follow logic - they model reality / self-consistency and always correct themselves because of the scientific method. However, computer science is a chase of what is the most popular at the moment. Those are decisions based on the crowd, not anything close to an objective opinion, and the wrong choices are compounded every day[0][1].

[0]: https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf

[1]: https://dl.acm.org/doi/10.1145/1622123.1622147

[Robdel12]

You compared trains to YouTube videos, I cannot take _you_ seriously.

[mardifoufs]

The issue is a bit more nuanced. Where I live, software engineering is regulated in the same way civil engineering is. The main difference is that you don't usually need an engineer to sign off for software projects, but I dont see a big difference between PE certified projects and those that are more "agile". And we aren't some sort of SWE quality haven either.

Generally speaking i agree that we need better control over titles and competence but youtube is still an incredibly massive engineering achievement as a platform, has been extremely reliable all things considered, and it's been mostly built by people without those certifications or regulations.

[stavros]

> This is a prime example of why programmers are not seriously considered engineers.

I'm a programmer working in healthcare. If I ignore a safety issue anyone discovered, people die and we go to prison. Am I an engineer now?

[marking-time]

I used to be a sysadmin at hospitals. There is software in everything like biomed devices, imaging machines and even the humble email system that I maintained.

Other examples of critical software systems include banking and voting.

I have never _ever_ called myself an engineer even when I was encouraged to.

It is foolish to leave this field unregulated.

[stavros]

Medical device software is very strictly regulated.

[marking-time]

Yes, of course you are correct. I should have been more specific in my response. I can print("Hello World") and I am not an engineer. I have a BS in accounting but am not a CPA, and that is also highly regulated.

The point I am trying to make is that we are building a society on software that has no legally binding standards but has serious impacts to all of us.

[thin_carapace]

"engineering - the application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems"

agentically vibe coding a website with some minor manual tweaks? adding bullshit to a product for the pure purpose of profit maximization at the detriment of the end user? moving fast, testing user engagement instead of user safety, and being okay with breaking things? .... not engineering !

following an agreed set of processes to formally maximise product safety & consistency eg. adhering to medical device standards for software development? .... engineering!

[rvba]

Closer to an engineer than the hacks described above.

[macinjosh]

> This is a prime example of why programmers are not seriously considered engineers.

The civil engineer who builds a great suspension bridge probably looks down on the one who builds a bridge over a irrigation ditch in a rural county using a big metal pipe covered with dirt.

Much like you may look down on train builders who make the novelty trains for kids parks.

Software engineering happens to be useful everywhere and most stuff in life is low stakes and the economics do not exist to make it perfect.

However, in aerospace, banking, and other high stakes industries software engineering projects are met with the rigor that is called for.

[rippeltippel]

In the country where I live there are two university degrees: Computer Science (depends on Mathematics) and Information Engineering (depends on Engineering). I took the latter, where there is more maths (despite not depending from the Maths department), physics, electronic, automation. I now work with healthcare data: a highly regulated field. Can you please explain what is _not_ engineering, given this context?

[ses1984]

No one is saying all programmers lack engineering discipline. It is simply not required for all programmers, even in many situations when it probably should be.

[g-b-r]

You're certain that there's more math in the information engineering degree than in the CS one? It's usually the opposite

[tearwear]

It's YT creators vs people on/in front of/around trains. People with real jobs and real impact. Nobody would have invaded Iraq if those planes back then crashed into a Hollywood studio. ( exaggeration, chill out )

If a programmer fucked up something "train leaks" related and he ignored that because of xyz, there would be trouble.

[cadamsdotcom]

The analogy doesn’t work.

Train safety issues kill people.

[blini-kot]

yeah, and somebody mounting i.e. some sort of audio/video equipment might make a mistake of putting flammable wire through firewall, while a software engineer in a different field (i.e. embedded or network firewall) might get lawful action in case of a design flaw

Licenses and reprimands are not bulletproof as those are often portrayed: take 737MAX for example, or Ford Pinto, or bridges, which fail every day as it seems

the only good investigation on the matter I've seen is this one: https://www.hillelwayne.com/talks/crossover-project/

and it states that yes, software engineers are in fact engineers -- and some investigation of the same order of magnitude is needed to disprove it

[fragmede]

The post-mortem on an incident is where it's at. Unfortunately most of those are proprietary and unseen by the rest of the world, but when a load bearing (are humans allowed to user that phrase still?) website like Google or Stripe went down, there's a level of rigor that isn't seen by the public to ask the five why's, or another framework that makes software look like real engineering. Problems are going to happen. Things after going to come up. The question is what you do after that, which determines if it's a serious thing or not.

[cucumber3732842]

Programming is is serious engineering because we take ourselves seriously.

Programming is not serious engineering because real engineers don't half ass everything. <- you are here

No wait, programming is serious engineering because the way they do things is shit too.

Source: Aerospace employmennt

[Der_Einzige]

Software should always be treated as the artisanal, crafts-person like work that it is. There is far more subjectivity and design/aesthetics (not relating to GUI, etc) in the design of software than most will admit.

[thi2]

> This is a prime example of why programmers are not seriously considered engineers.

Jumping to a pretty general conclusion there. Incentive packages like the parent described are not the norm.

[burnte]

If a train crashes, people die. If Youtube crashes, no one dies.

[cube00]

Unless some sensitive private footage leaks then who knows.

You can blame the subsequent action on the individual but if the footage leaked due to a bug Google refused to fix are they completely blameless?

[burnte]

1. If youtube crashed then presumably NO video would be available.

2. If you upload sensitive footage to a public video sharing website, I don't really have any concern for that footage being leaked.

[beambot]

The entire rail industry suffers from massive deferred maintenance issues that manifest as serious safety concerns. This shit happens in every industry: dieselgate, 737max, flint water crisis, PG&E camp fire, etc. Let's not pretend one engineering discipline is holier than thou -- especially when the consequences are derailments versus some leaked youtube videos.

[cynicalsecurity]

Don't blame programmers, blame the insane annual review system at IT corporations.

Introduce the same system at train engineering companies and you'll get the same result.

[thaeli]

At an operational level for the railroads, we have PSR, which is even worse.

[rurban]

No, that's why Google does not do engineering. It's an ad company afterall.

Us engineers do have our priorities straight.

[moffkalast]

Well you're not wrong, saying this as a programmer. Incompetence is unfortunately the norm in our industry.

[solumunus]

It’s pretty much the norm in all industries.

[moffkalast]

Less so in those that actually have any barrier for entry, you do need an actual degree to be an engineer, an MD to be a doctor, a forklift cert to operate them in a warehouse, while anyone without any certification can write software.

[throwaway819782]

I wish I could upvote you more. A-fucking-men. The regard this group has for itself is so adorable at times.

[philwelch]

If we're going to gatekeep the word "engineer", you're not in the most defensible position as a train designer. If you want to go back to the original definition, engineers were soldiers specialized in siege warfare, which has nothing to do with designing trains. Alternately, "engineer" can be broad enough to include someone driving a train, which presumably required some understanding of how the locomotive worked but was more of what we'd call a skilled technician.

[globalnode]

i always have a little chuckle inside when i see someone using the term software engineer - i always thought it was a term they used to pick up chicks.

[dexterdog]

How is this remotely related? This is not a safety issue.

[0xdeadbeefbabe]

There's more than one variable here, but nice try.

[mschuster91]

> This is a prime example of why programmers are not seriously considered engineers.

The problem isn't the programmers ffs. In your industry, if your superior orders you (or creates the incentive) to hide bad stuff under the rug, you have the ability to push back, at least to some degree.

Programmers? We don't have that. Maybe the few of us who actually work on security critical stuff, but some generic AI BS? No chance. You're being treated as a cog.

[Arainach]

All sorts of employees are treated as disposable. The issue is absolutely that software engineers have no culture of responsibility or safety and no professional licensing group to enforce it for them.

[dolkycape]

The professional licensing group is what creates the culture of responsibility. Most developers would be happy to have that as it would limit supply and increase wages considerably.

[brailsafe]

> no culture of responsibility or safety and no professional licensing group to enforce it for them.

Naturopaths and chiropractors are licensed to do various things too, physicians, etc.. a license does not imply that there would otherwise exist a culture of responsibility, foundation in evidence or anything of the sort. It's an incentive structure and regulatory practice. One may even keep their license while being a monster and abusing other incentive structures that don't have a bearing on that license.

Software engineers are not typically licensed as engineers, that's all one can say without dipping into prejudice.

[qznc]

I'm working on automotive safety-critical security-critical stuff. There is structure and bureaucracy around this stuff.

For example, a project gets a safety managers assigned who has to sign off the release. Project management is explicitly not superior to this safety manager. In most cases these safety managers are just there review stuff according to some process guidelines. If there is pressure (project is late, etc), there are more senior safety managers to call in and they will usually make more nuanced safety arguments (in this specific case, violate this guideline, but at least do X as mitigation).

In the end there is bureaucracy. Things need to be signed and archived for potential law suits. Not having archived things will be even worse in the law suits.

The upside: As a programmer, you don't need to argue that you need some time for unit testing.

The downside: 100% test coverage is mandatory and it really gets enforced.

[nickserv]

Programmers work on trains too, you know. Some of the busiest metro lines in the world are fully automated, pretty sure that code is held to a higher standard than some shitty YouTube feature.

[justinclift]

> This is a prime example of why programmers are not seriously considered engineers.

Alternatively, perhaps Google has a culture problem where it encourages crap like this?

[richardfey]

I remember hearing this perspective when I first started in the software industry, and I agreed with it for quite some time. But frankly, we’ve never been further from it.

[jp_sc]

Last year alone, 40 people died in Spain in a train derailment. In total, how many people have died over the last 100 years because of something a software engineer did?

[urbnspacecowboy]

Software defects are the #3 cause of medical device failures, and growing: <https://meddeviceguide.com/blog/medical-device-recall-trends...>

ETA: Admittedly the above is getting off-topic from YouTube, but I can easily imagine a scenario where an instructional video was deleted due to a spurious copyright strike or some other stupidity.

[YorickPeterse]

Probably more than we'd like to admit. This isn't new either (https://en.wikipedia.org/wiki/Therac-25 for example).

Thinking software developers have done no wrong (deliberately or not) ever is just borderline naive.

[bentcorner]

Not just accidental, there are many tools/processes/weapons that are powered by software written by engineers who knowingly write their code to do harm.

But people gotta eat and all so who am I to blame.

[wildzzz]

Probably many, but how many is the result of the title of someone's IP leaking? Other than private video titles, what can this AI actually access? I doubt it has bank account information or any other PII that could cause actual damages. The risk is real but the impact is incredibly low.

[LtWorf]

Probably way more.

[sutibb]

Take a look at the software integration in the average hospital and you'd be horrified

[ronbenton]

Glad to hear this is a universal big tech experience. The promo process is entirely antithetical to shipping good products

[gguncth]

Shipping great products is about the details that almost nobody will notice

A good promo process needs to notice the invisible

Apple did it for decades

[tgma]

Haha, almost everything at Apple that is not seen by the user is full of crap (and increasingly you see user facing bugs and schedule slippage too). Possibly still somewhat true in hardware, but in software, they have far worse engineering practices than Google: remember "goto fail"?

Back in Snow Leopard days you could instantly crash the kernel with a fuzzer. In fact I managed to do that accidentally by hand. NT kernel had much more systemic hardening than XNU.

Apple also treats employees capriciously and in non-standard ways. Your experience is almost entirely dependent on who your manager is. I have never heard any of big tech make so many false promises to employees. I have friends who negotiated for an immediate green card application upfront, but they later found out they were bait and switched, etc.

[a34729t]

It depends heavily on your manager and skip. My boss values operations and getting things done (including both doing things right from the beginning, and fixing things when we have to cut corners to launch quickly due to exogenous pressure), and that means people get promoted for being good engineers. Of course this falls apart for higher levels where it is entirely politics, but that is beyond my boss' influence.

[Aunche]

I don't think it's the promo process itself. If the bug was something that actually affects Google's bottom line, I guarantee that Google would find a way such that the engineer would be incentivized to fix it.

[tiahura]

Sweep it under the rug is not limited to any paticular industry.

[citizenpaul]

What do you mean? Youtube is unquestionably one of the most successful projects ever launched? Seems like the process works astoundingly well.

[strictnein]

Youtube wasn't launched by Google, it was purchased.

[UnlockedSecrets]

Youtube launched 1 year and 8 months before being acquired by google.... It's largely semantics to say that what Youtube is today, isn't a direct result of Google's ownership for nearly 20 years now....

[ismailmaj]

From talking to someone that worked at YouTube for 15 years, they still had a lot of core Python code in 2016 that was legacy from the OG company/team and that code needed to be transitioned to follow the Google way of doing things in C++/Go.

I don't think it was distinct enough from the Google culture like Android was at the start of the acquisition but it seems they had leeway to do their own thing.

[grg0]

Google had Google Video and couldn't hold up, that's why they bought Youtube.

[sdevonoes]

What YT is now:

- ads every now and then

- addictive shorts no one needs

- suggested videos nobody asked for

- geo ban of videos

[dizhn]

No concept of language in a user facing way. No filter by language no search by language. On the contrary searches are translated before running and return all languages, videos are dubbed even when you speak the original language, same but with titles being translated etc. Search being shit is kind of on par with being a Google product though. I wonder if they had any language preferences before Google bought them. I don't remember that far back.

[strictnein]

Huh? It's not semantics to point out that a project wasn't launched by Google, when the point was about a successful project launch from Google.

[OtomotO]

Good != Successful.

I assume that's why they wrote good and not successful.

It's an average software product with incredible scaling behind it and a lot of elbow grease to keep it chumming along, but it's not great software by the definition of "bugs actually get dealt with"

[jascha_eng]

It's great software in the sense that it makes a shit ton of money though. In the end software that doesn't get used and doesn't make any money but has no bugs is not valuable either.

Not saying that this is the trade off you have to make but if you have a working mode in place that achieves usage and money somewhat consistently i can understand being hesitant about changing it to optimize for less bugs instead.

[estaroc]

The only people for whom it makes sense to define "great" as "makes money" are the people who produce and sell said product.

Similarly, most people don't put much stock in the salesmen of a product describing their own product as great.

Stop debasing all of quality to profitability.

[OtomotO]

That's just two different scales.

Weapons are a great product for weapon dealers and manufacturers as well, just not so much for the people killed by them (or their families, or survivors)

So sure, if making a shitload of money is the metric, YouTube is a great product.

That wasn't the point of the person you answered to though.

[ori_b]

Surely the Therac would have made more money if they had covered up the deaths instead of fixing the bugs and owning up to them.

Why do you think they would compromise how good their software is merely to save lives?

[mid-kid]

Youtube survives on google's massive repertoire of products being vastly more profitable, not because it's the best of its kind.

[thx67]

And free bandwdith. Free bandwidth is nice.

[BetterThanSober]

Google definitely doesn't have free egress

[thx67]

Google owns the backbone. They definitely have free egress.

[ghurtado]

And you honestly believe the main factor in YouTube success was the quality of the code?

That's a thought that doesn't even deserve further comment.

[dooglius]

Did the promo process exist at YouTube's creation?

[cdbdbspt]

I also used to work at Google and what you have described is not the way the VRP works at all.

1. The engineers on the VRP teams set the severity of the bug based on impact. The engineering team responsible for the fix can argue the severity but only if they can show there is some other mitigating factor that the VRP team wasn't aware of.

2. Google has a great security culture and while it may be true that maintaining existing code may not be as sexy as building new features, fixing vulnerabilities does look good on GRAD (performance) because the impact is already well documented.

3. Believe it or not, the VRP team does like to give away rewards. However, to do this, they have to follow a rubric to keep all of the payouts consistent and fair.

4. Constructive and polite discourse is welcome and a researcher may reply to their bug asking for more details or to make their case in the event that they think the VRP team did not understand the severity. The team is made up of humans who are open to the idea that they missed something in the initial report. They, like all other bug bounty programs, are also struggling to keep up with the huge influx of AI generated slop so mistakes can happen.

[jonahx]

My first thought when reading the article was: "The generous interpretation here is that whoever is fielding reports gets so many false positives that they miss true positives (like this report), especially if there's any gray area."

I'm not saying that excuses it, but it is one likely explanation for how it happened. When looking at just one report, the response seems negligent. When looking at a pile of 1000 nonsense reports, with a handful like this, I understand the difficulty.

[mlmonkey]

This is what you get when the MBAs are in charge. They just go with P&L, Spreadsheets, etc. and care only about the current quarter and meeting the goals.

[wahnfrieden]

Google leadership has been from research/engineering and product backgrounds. This is how hierarchical businesses operate

[lesuorac]

Except leadership is largely not from employees moving up the rank

Sundar (CEO) is from Mcksinsley.

Ruth (President) is from Morgan Stanley.

TK (Cloud CEO) is from Oracle.

Mohan (YouTube CEO) is from DoubleClick which is Google at this point (~15 years).

---

Largely the story of the past several decades is that "doing your time" is a bad strategy. Always move to another company to go upwards.

[magicalist]

Wait, but Sundar Pichai was there pre google IPO as a Chrome PM, and Neal Mohan was there for 18 years. How are they examples of "doing your time" being a bad strategy?

[foltik]

Not really, in such large companies there's enormous selection pressure favoring career politicians. Maybe some of the survivors did some engineering at one point, but expertise fades fast when you stop getting your hands dirty. Most are empty suits.

[ghurtado]

Of all the fucked up things in this comment, giving a single Engineer lifetime responsibility for all bugs in code they wrote is probably the dumbest.

And it's slowly becoming the norm. The last place I worked at, a large and well known Tech company, didn't even roll with QA's. That just wasn't a role anywhere in the division. You are fully responsible for all the bugs in all the code you ever wrote

Cute at first. Unsustainable in the long term

[weitendorf]

I disagree with this pretty strongly. If you’re not going to take responsibility for your bugs I don’t want to work with you.

Don’t make other people QA your work; if you’re not able to figure out how to do that yourself while you work you’re legitimately bad at your job.

Once you leave an employer obviously you have no obligation to fix bugs in IP you don’t own or anything.

[tredre3]

I think it's reasonable to have a culture where you're encouraged to consult the IC who wrote the code even after they've moved on to other projects. But I don't think they should be responsible for fixing the bugs.

And I don't mean this to excuse the bad code written by ICs. I just think it's not sustainable from the POV of the org itself to depend so heavily on individuals, especially ones who aren't familiar with the entire codebase anymore.

The team currently in charge needs to have full ownership and be responsible for the code, even if they didn't write it.

[nomel]

That works as long as there's a finish line. If you make a framework, or a set of libraries, it's easy to get pigeon holed into all new features/tangential work around those.

[deathanatos]

I'd go more with their last statement of,

> The team currently in charge needs to have full ownership and be responsible for the code, even if they didn't write it.

That's honestly a high enough bar — many orgs I've worked in do what I call "zero-staffing", which is where an in-use / deployed-to-production project has no team, no engineers (or so few engineers, such as one, as to be a pittance). That one eng, if they even exist, is often just trying to hold everything together.

There's a middle ground, of course: an engineer who has accomplished too much might be underwater with questions, but at the same time, they need to pass the torch to the next team that is maintaining it.

… but too often, there just isn't a next team. People get burnt out, leave for greener pastures, and stuff gets decommed (maybe) because people are like "what even is this?" b/c the knowledge has walked.

The industry is not rewarding experience or knowledge at the moment, so that trend will continue.

[mk89]

OP used the word "lifetime" which makes a key difference.

I don't want to be responsible for a bug in my 8 years old code, which I probably even forgot how it worked etc. I probably don't even work anymore in the same team or on the same service.

Why the hell should I be responsible and how is this sustainable?

I am not even sure if your criticism makes any sense at all anymore nowadays. AI is writing 80% of the code, if not more. It's technically not even your code anymore, although there is your name on the commit. Why should I be responsible for that 3 years from now, when I have again moved team or service etc.

Accountability ok, but you should not retire with your code.

[mschuster91]

> Why the hell should I be responsible and how is this sustainable?

Well, it works for professional engineers, you know, the people designing bridges, tunnels, heavy machinery, aircraft, spacecraft or medical instruments. When something happens and they can't show that their work adhered to the generally accepted best standards at the time... they're held liable. And sometimes, that liability includes jail time, particularly when people are seriously injured or die.

And how it is sustainable? Simple: legal requirements that force managers to allot enough time and tooling to their engineering teams, because engineers whose professional license is on the line will rather quit than be forced to sign off something that is unsafe.

In the software world, this might result in AI not being used at all - simply put: no matter what, AI in its current form is always going to be vulnerable to in-band attacks, or to use an older term... phreaking [1]. It might result in software having to go through formal proof programs, fuzzers, whatever. It might result in entire programming languages just being outright banned in production code in favor of programming languages that eliminate entire classes of vulnerabilities.

And before the usual "but China/India/... would outcompete us" complaints come... well, have you ever seen a Chinese widebody airliner in Western airspace? No. Because China is not able to pass over the engineering gates we have set in place. We could easily do the same with software.

Requiring at least some sort of quality gates on software would not be bad for you as a programmer. Quite the contrary: it would hand you power over your incompetent beancounter boss.

[1] https://en.wikipedia.org/wiki/Phreaking

[jerojero]

I think the problem I see with your argument is that people simply do not value reliable and secure consumer software as much as they'd value reliable and secure airplanes.

Of course, software that is in charge of things where people value security a lot, such as the software in airplanes, is much more scrutinized and adheres to better standards. This is the case precisely because when it goes bad people die in ways that attract a lot of attention.

You can't enforce those same policies on most consumer software because people consume it the same way they do food. You can have Michelin starred restaurants with the best practices but most people can't afford to eat there so instead they will buy hot dogs on the street.

The idea of "high quality hand crafted artisinal software" is closer to luxury products than it is to the engineering of planes, trains and bridges.

[BetterThanSober]

> people simply do not value reliable and secure consumer software

Because the incentive to care is not there, we'll see things changing when self-driving cats is mainstream

[mschuster91]

> You can't enforce those same policies on most consumer software because people consume it the same way they do food.

The government can. GDPR was an attempt in that direction, it wasn't enough of a hint to software developers, that's how we got the Cyber Resilience Act that's beginning to take first effects in a few months.

[SoftTalker]

It's interesting you bring up airliners. Whose engineers developed MCAS? Were any of them held liable? Are any in prison?

[mschuster91]

> Whose engineers developed MCAS? Were any of them held liable? Are any in prison?

Given that Boeing had been granted wide leeway to audit itself and write its own standards... the engineers couldn't be held liable and the corrupt US government dropped the corporate case [1].

[1] https://www.bbc.com/news/articles/c891k875x3qo

[Jach]

> If you’re not going to take responsibility for your bugs I don’t want to work with you.

Depends on what "taking responsibility" means.

> Don’t make other people QA your work; if you’re not able to figure out how to do that yourself while you work you’re legitimately bad at your job.

At a distance I agree with this, but closer to the details, eh... Having worked with excellent QA and QE people, they just think differently than I and other programmers I've worked with do, in a useful way, so I think it's a shame (even if understandable) how such roles have been killed industry wide for over a decade. "Hybrid" doesn't really cut it. But yes, I get pissed when a code review comes my way and the author clearly didn't bother to even run their own code because when I notice something wrong and try it, lo and behold it doesn't work. I imagine some even less competent places throw over reviews (or just push straight to master) that don't even compile. I won't get into basic automated testing. I believe programmers should have a professional ethos to learn new things to make themselves better at their craft, with or without management support or even paid company time for it, this includes ways to think about better achieving quality goals.

> Once you leave an employer obviously you have no obligation to fix bugs in IP you don’t own or anything.

This is the crux of the issue: the employer always owns the code, not the individual, and so to me it's the employer's job to be responsible for any defects. A sensible employer probably recognizes that often the author of the code is the best one to fix it -- but this is also part of why it's so important to have code reviews, because then in theory you have at least two people who are somewhat familiar with the code. At the same time, coding, like everything else, is subject to stochastic quality issues. Employees work within a system, many issues are caused by the system, and only management can change the system. Take some lessons from Deming's red bead experiment: https://www.youtube.com/watch?v=7pXu0qxtWPg (Write-up: https://web.archive.org/web/20251212234933/https://maaw.info...)

[vlovich123]

Ok. So QA finds a bug. Who’s responsible for fixing it? The only value of QA is to try to make sure you become aware of issues before customers find them

[episteme]

The company, not the individual

[ShrootBuck]

And who in the company do you propose should fix it

[jareklupinski]

someone hired by the company to understand the application and fix the bug

ive inherited a lot of code

[SoftTalker]

Fixing bugs is a great activity for new hires. Gets them familiar with the codebase.

[dizhn]

QA probably has their own promotion path that doesn't involve finding bugs. :)

[dfxm12]

It's even worse when you don't work at a tech. Even the simplest of Excel formulae, power automate flows simply go abandoned once the creator moves on, or maybe a very expensive consultant is onboard to maintain what amounts to a handful of lines of code. It's embarrassing how little initiative the average information worker has when it comes to stuff like this.

[boredatoms]

Lifetime is too much. One or two re-orgs at most.

People only spend a couple of years at each company anyway

[goosejuice]

It's not cute, it's a sensible way to build greater understanding by learning from mistakes. The thing is, it has to be engrained in the culture and that also means it may need to take priority over other work. Responsibility doesn't need to mean you have to write the code, just see it through.

[lnrd]

In my company, user reported bugs get triaged and once they are confirmed they end up in the board of the team owning that part of the system (often they also built it, but is not necessarily the same people). Then there's a team bug threshold and if it gets reached then the whole team can't merge anything else until X amount of bugs are fixed and the number goes down. It's very annoying system and in cases of emergency it can of course temporarily be lifted by someone above, but honestly is very effective in making sure that bugs are fixed in a reasonable amount of time. This makes fixing bugs "part of maintenance work that is a given and expected to be done between new initiatives".

[lordie]

It's easy to cynically generalize and attribute to the broken promo process when it is more likely either a non-engineer reviewing the report or someone else not really understanding the nuances of prompt injection. I work at YouTube, and I've escalated it to the appropriate TLs and TnS leads to take a look.

Bugs in existing projects and a sense of ownership and leadership are absolutely a part of GRAD, having been in several calibrations and promo committees myself. So while this understanding has a grain of truth, it is far from what's evaluated, at least in my VP's org. I can't speak to Cloud or any other PAs.

[dfxm12]

It's ultimately Google's responsibility to ship bug free products. I don't care who implements a fix, but Google management should make sure someone fixes it.

[wahnfrieden]

Spoken like a user and not an owner

[carl_dr]

No, it’s really not, it’s none of our jobs to do that. It’s our job to make our employer (even if you are your own employer) money.

It’s incredibly rare you have the luxury of even trying to deliver bug free code, let alone achieve it.

[nxc18]

And this attitude is why we have the software we have in 2026. The profession used to recognize value beyond next quarter’s dividend (jk, we only do stock buybacks now for tax reasons).

[dfxm12]

People eventually stop using, and paying for, buggy code.

[ZiiS]

ROFL this has not been my experience. Many more people stop paying because of some featuritis request you snubed to keep the bugs under control.

[deathanatos]

Because big tech companies are oligopolies, and there isn't enough competition in the market. If you're dissatisfied with the 2 choices out there, you cannot vote with your wallet.

[thi2]

> It’s incredibly rare you have the luxury of even trying to deliver bug free code, let alone achieve it.

What? Every company I worked for wished for bug free code. Mistakes happen but there was no acceptance for yolo-ship features.

[sscaryterry]

The rot is deep.

[BrenBarn]

Those are many words to say "no one feels an obligation to do the right thing".

[tgma]

Obviously what you said is not some unheard-of secret or deep analysis. It is a running joke inside the Google system.

But... many Googlers who have a tendency of repeating these things have (1) not seen how shittier things are on the outside (2) are not in management and do not know how much manager lies to them (3) have unrealistic expectations of how well any process applied to 100-200k people can work. If you see a place that has a better overall promo system, you'll almost certainly find that it is a much smaller shop and things are decided more ad-hoc at the top with higher information flow.

Specifically, for (2) the manager and their adjacent group can clearly flag the slipping under the rug behavior and ding one's promo. However, sometimes when they message it back they would lie about it to the employee and blame some other management or requirement or complexity, etc. Other times, the manager is a "people manager" moron and non-technical, and can't really evaluate (in which case it's not the process that's at fault, but useless management.)

It's also not clear that the optimal quality is achieved by spending more time "perfecting" things. At Google, people already work much less than other companies. Perhaps the answer is in fact the opposite: pushing to ship more milestones per unit of time and driving harder to then perfect it. My bet is if the promo packet was accepted without a full "launch"[1] they would have still shipped the same half-baked crap at a later point in time.

[1]: many years ago, they wanted to reduced half-baked "launches" and said we want "landings" not "launches" and wrote some documents explaining the difference and self-congratulated themselves. Net result: s/launch/landing in promo packets.

[alfiedotwtf]

Holy shit working at Google sounds depressing AF

[varispeed]

> This is a fairly nuanced/involved issue

Is it though?

[Mg6yDfjp5U]

Definitely. The front line support agents handle only the most basic requests. Anything even remotely complicated, such as this, would be internally kicked around until they found someone familiar with the project to give input. Which most likely is someone who worked on the original implementation.

[esrauch]

In 2026 things have changed, there's literally whatever tens of thousands of "security" reports that are almost all bogus as a raging crap river.

I think theres very little chance this particular report made it to any engineer who works on product at all, because if they did they would be completely overwhelmed by reports, the filter which has to handle the many thousands of reports based on a playbook almost definitely filtered it out before it made it that far.

[jskeicjwkxjwkd]

It isn’t though. Just fix the goddamned thing. Fuck promo packages—fix your shit.

What’s the point of saying you “work at Google” if all you ever do is work on half-baked, unfinished, unpolished slop?

Fix your shit.