I don't think it's satire, this guy is actively defending this on Linkedin: https://i.imgur.com/SlJPG85.png

I think the latter makes clear that this is a joke account, doesn’t it?

Yes, especially the newbies who don't know what they're doing.

I don't know if sarcasm because there are actually maniacs like that in this world

Oops boss just did a git push --mirror

But Elon's annoying!

The best thing you can do with that shithole of a site is ignore it as best as possible. Don’t give them any engagement. They’re no better than rage-baiters on Reddit and TikTok

I wouldn't even do it anonymously if I still had a linked in account

pete's a fucking genius

Another benefit is you never have to worry about merge conflicts

Why review at all when the users will do this for you? Merge, deploy and move on. If it's broken they'll tell you.

I'm definitely going to start doing this at work. We don't want our embedded firmware for medical devices to get stale.

Unironically worked for a company that did this. Don't test it, don't even run it, just put it in prod.

I miss when internet services was literally down because it was being developed in place

🫠

The amount of times where I had to fix things in live production servers is not a small number. Then again, we are only humans. Backup often and you are golden.

Imagine if you will: You have a red button and a green button. You are allowed 10 seconds to review the code before rejecting or accepting & merging. Think fast.

Wash your hands after cooking, never let food products sit stale

Except instead it’s: Developers: fuck ops, they stuck at their job

it's NewGame+ for when you 100% programming

A real thing, believe it or not.Though I don't think what that guy said fits in it.

It's when you write everything in l33t WITH CAPSLOCK ON.

It's agile based around rapid prototyping. You build a thing, then you do it again, but better

It's not a new idea... But I've never heard of anyone doing it professionally

Pair programming? Then the code is already reviewed.

you are supposed to have written the tests and to have written your code with pair programming,

I commented out the tests because they were failing, pipelines were green so I merged. Now it's running on prod. What do you do?

You lost me at "pair programming". Having tests for what you can test is fine. But there's code that simply can't be tested, or at least not easily at which point you are just wasting time. Open source mantra is always great in my opinion... release early, release often. In addition to that have a test version of your software before you push it to production if there's sensitive data. That's usually good enough to catch issues.

And he's right, reviewing changes before merge just takes time and resources away from project while the master branch keeps moving. Merge, if there are issues, whoever submitted the change is obliged to fix it. You can always checkout earlier version.

Call it “container orchestration” and charge an extra 20% to the customer

Oh hey a fellow game dev, how long you been in the industry?

Modern agile is just waterfall with steps.

It compiles = it goes to prod!

have the author address issues after the merge.

Hahahahahahaha. Sorry, you've merged, next ticket, PM needs shiny results for execs this QBR!

This is how bug backlogs grow.

This only works if the merge is being done to staging builds that are continuously tested by a QA team before they go to production, with carefully planned production milestone releases. I work for an emergency management SaaS company. If we just merged all lightly reviewed code into production without thorough QA testing, there’s the possibility that our software would fail in production. This could cause aircraft in major airports to crash into each other on the runway, or a university to respond poorly to a live shooter situation, or the deletion of customer data about COVID vaccine efforts, etc

Get the value to production

Ugh, not this SAFe Agile (tm) cultist bullshit. The "value" is working, bug free code, which you get when you put it through review and QA before it gets to production.

This is some poe's law shit. I can't tell if you're serious or just committing to the bit.

I'm with you. I've worked on a few teams, one of the first was a company where two teams were contributing code changes to the same product. The other team "owned" it and as a result it took ages, sometimes months, to get code changes merged. It meant more time was spent just rebasing (because merging wasn't "clean") than working on the actual feature.

My current role, we just do TDD, pair programming, and trunk-based development. We have a release process that involves manual testing before live deployment. Features that aren't ready for live are turned off by feature flags. It's quick and efficient.

Fundamentally I think the issue is the right tool for the job. Code doesn't need to be managed the same way in a company as it does in an open-source project.

Huh

Peer reviews can catch bugs that tests can't catch.

I won't disagree that peer reviews are overrated, but they're a great way to train and onboard less experienced devs (who are just more fun to work with, anyway). Like I'm a platform dev, so I don't have a "home" project - if I had to know every project before I opened a PR for it, I'd get hardly any work done. Review help other knowledge experts weigh in on my changes.

Anyway, one case for being pro

I operate from the presumption that code's first job is to be as easy for a human to understand as possible. It should clearly communicate what it's attempting to do. If your code isn't written so that your colleagues, or you 2 years from now, can read it and understand it, it's bad even if it's whip tight, fits all the AC and has 100% test coverage with a perfect mutation score. That's what I focus on when I review code: does it communicate intent semantically. Code that can be understood is code that can be reused, optimized, altered when use cases change, generalized out into even more reusable code, and provide insights that technically perfect but incomprehensible code can't. I, like you, assume that the coder knows what they were trying to do and how to test for it, so that only gets a cursory glance to spot common errors like missed nullables, inverted conditionals and shit like that. I look at it from the perspective of "If I had to add functionality to this, could I do so easily". Because I'm gonna one of these days.

If coders are good AND know the project

Those are some pretty big ifs.