1,150 karma · joined October 29, 2025
I've worked at a FANG where I had the opportunity to personally witness a few teams being summarily fired after they delivered the project.
In one case they had their team manager motivate them with pep talks that if they did a fantastic job delivering the project then higher ups could be swayed to preserve their roles. So they delivered ahead of schedule, only to be fired ahead of schedule too.
Gentle reminder that Tesla itself opted to call Tesla's sham of a FSD as "Tesla assisted driving" after regulators from multiple European countries made it very clear that at best ist assists drivers and still require drivers to never take their attention off the road.
Are we in agreement that all this talk of "memory safe languages" is a red herring? I mean, who is foolish enough to believe that rewriting something in a different language makes is magically safer?
If you bother to check, you'll eventually notice that even "memory-safe languages" have accumulated a good share of CVEs, inclusive for memory safety issues. Check out RustSec.
It's worth noting that Anthropic claims 30k merges/day, but they state it's in a monorepo. This alone suggests to me that they are needlessly creating their own problem.
Instead of doing trivial and obvious things such as "perhaps we could peel off a project or two into their own repo" they decide to proclaim it makes sense to them to create their own version control system.
It's like they shoot themselves in the foot, and then announce they are going to develop armoured shoes to address issues with standard shoes regarding projectile resistance.
I can't help to wonder where the competent engineering ends and self promotion starts.
This. Since forever was I told that the term "software" was coined because, contrary to hardware, it was easy to change, adapt, and mold into your needs.
I'm very surprised to hear people in this day and age claim it wasn't.
How can you tell?
Rigging a car to do a flip is a clear way to tell the world they officially ran out of ideas and are desperate to get a sale.
I'm sorry to say, but it is. Is your manager responsible for managing workloads, task assignments, and priorities?
> It’s absurd that the immediate response to friction is to offload it to someone else.
That doesn't sound right. A PR review literally requires you to dump your workload onto someone else. Often times a PR requires significant amounts of time to review. Your team members need to set aside significant amounts of time out of their schedule to look at your work.
You cannot frame a problem that fundamentally revolves around dumping work onto someone else as being absurd to dump your work onto someone else. I mean, what do you think happens when you ask someone to review your work? Do you expect your team members to blindly sign off?
It's obviously about offloading work. And it's the Manager's job ro set those priorities.
If your place of work had no one responsible for setting work priorities of managing task delivery and then find yourself blocked by mundane things like a PR then it seems you are developing novel ways of being dysfunctional. Perhaps you PR process is indeed not the problem but a symptom.
Dude, you're the one talking about talking down to people telling them they are not doing their job. Relax.
> I have never worked somewhere that ran things as you describe.
What do you think a PR reviews process is? It is literally "I will be prevented from merging my work so that all of you may have a say on what I'm doing".
This is precisely how and why it is designed to work.
In basic scrum, you know that part where the scrum master asks in daily meeting whether people are blocked? What do you think it is used for?
Pray tell, what do you think a PR is used for, and how does the process work?
If that's how you interact with your team members, no wonder they refuse working with you.
What any competent developer does is a) update ticket to move it to review, b) call out the PR in whatever system you guys use, c) after a reasonable amount or time inform your scrum master/manager that your task is code-complete and is blocked by the review, d) update ticket with a notice that PR is still pending review. Go back to step b) and repeat until the PR is merged.
Done.
Updating the ticket and making a best effort to get the ticket moving is all that's expected from you. By design. That's how things are supposed to work. If your manager doesn't care, it's nothing they want to push anyway, as proven by the ticket history.
You are responsible for delivering tasks, but if you are blocked by the process then it's not you who is preventing the task from being delivered. Whether it's the scrum master or sdm or project manager, someone else is responsible for keeping the tasks moving. Once you mark a task as pending review, you are blocked. From that point onward all you have to do is raise awareness of reviewers to the task pending review, and raise visibility with stakeholders that your deliverable is being blocked by the review. As long as you don't slack in raising awareness, it's not your problem anymore.
It isn't. It's your scrum master's/Manager's problem, because the ticket is blocked in review.
In the meantime you moved on to another task. Because the review is not your problem.
This.
I'd also add that not bothering to book a meeting means that people treat you like a low-value work queue that they use to dump low-visibility and low-accountability work. They invoke you to handle silly tasks that no one but you accept.
By requiring a meeting, you're increasing the threshold of effort that your requester is willing to invest in getting it done. If they can't be bothered doing a meeting, you shouldn't bother doing the work for them.
I don't think that firing people is an intelligent solution to a problem that boils down to your personal inconvenience.
If you posted a PR and it's awaiting review, it is no longer your problem. You are literally blocked by others. Who knows what they are dealing with? Perhaps they have higher priority items than reviewing your work? I mean, would you stop making this complain after they review your 3rd or 30th PR? Everyone around you also has work to do.
If PR reviews are slow, escalate the issue with your manager.
Nazis have this thing where they depict any political target as being both too weak and too strong, and too dumb and too smart.
I agree. This is what baffles me the most about USians. They know Watergate was one of the lowest points in the US history in terms of corruption and anti democratic maneuvers by a high level political group in the country.
Yet, the Trump administration outcorrupts any Watergate scandal very much each week. Yet, the US population is so docile and controlled that they barely react.
Perhaps one day you'll grow to understand that complaints about "flashing their bolt-ons" is dog whistle for moralist hypocrisy, whereas openly taking bribes, threatening close allies with invasion while launching economic war in the form of tarifs, and eliminating foreign aid programs causing hundreds of thousands of deaths digs a far deeper moral, ethical, and geopolitical hole to claw from.
Grigiri Perelman, who was awarded the Fields Medal, notoriously refused the prise because he stated no other recognition was needed.
This is a disingenuous framing. I've "built" more in academia than in some jobs I had, and some VC-backed startups are renowned not for building but for their lack of ethics.
"Building" is not the discriminating factor.
What? You do understand that in Europe Tesla was forced to market their feature as "Tesla assisted driving" instead of FSD because regulators in multiple European countries determined that it is unable to drive the car on its own and the FSD claim is misleading.
https://www.wired.com/story/tesla-full-self-driving-becomes-...
Even in the US Tesla markets it as FSD (supervised), which you must admit is a contradiction.
Tesla in particular and all Elon Musk's ventures aren't exactly renowned for being sound investments. Even snake oil salesmen were seen as proper entrepreneurs at one point.
Personally I can't shake off the feeling that every single announcement is a con job, starting with the autonomous driving claims. I'm baffled why people still put any trust into anyyhing coming out of that field.
The C and C++ standards people are you and me. The proposal to standardize debugging calls comes from a long time contributor to Boost.
I don't think this is a fair assessment. Submissions from specific sources are more frequent in niche forums, as this helps them stand out. So once a blog is found to be spamming, it's easier to target the blog and not individual submissions.
This is much harder to do on generalist forums such as HN.
It doesn't seem you even bothered to read the article. It shows quite clearly that following the strike post from populist far-right figures had literally a residual level of engagement, which includes both views, comments, reposts, likes, etc.
The screenshots clearly show posts preceding the strike showing literally an order of magnitude more comments, reposts, etc.
I'm not personally tracking there metrics, but I'd expect engagement to normalize a few days after the strike as Russia's propaganda arm is expected to scramble to get it's operation back online. Therefore, "just by time" can accommodate for Russia getting their botfarms back online. But the snapshot covered by this article alone are clear and obvious.
That's quite the militantly ignorant statement.
https://www.thelondoneconomic.com/politics/reform-figures-se...
Does it, though?
What problem do they actually have that requires redesigning a whole new vcs?
Merge conflicts? That's not exactly a vcs problem but a "we changed the same code at the same time" problem. No tooling on earth eliminates the need to verify conflict resolutions if agent A renames int foo to int bar while agent B renames int foo to int baz.
Growing repo size? They should take a long hard look at what they are doing. How is their software architected? Is every single little change and half-baked AI churn commit pushed to the main repository, or does the main repo only receive the deliverable? Is everything under the sun tracked in a mono repo or are projects stored independently?
Do they take any precaution at identifying churn and taking steps to minimize it?
Frankly, this reads like a bullshit PR stunt, much like the bullshit curl vulnerability findings. They have a self-inflicted problem, and their solution is to persist the problem and mitigate the problems by rolling out ad-hoc tooling? It reads like "if all you have is a hammer" kind of situation.