Merge then review

Having a hard time determining whether this is sarcasm or not. Then I see the phrase "JavaScript Engineer" and become doubly confused.

Having to go through the process of merging hurts morale and slows performance. Give everyone on your team the right to force push to master.

Stop transfering people from sales to engineering!

I really wish LinkedIn would add an anonymous cringe emoji. I would use it on like 90% of the content on that site.

I'm having a hard time figuring out whether this guy is a fucking moron or a fucking idiot.

No integration is as continuous as editing in prod.

Amateur. You want real performance? Code in prod. Literally could not be better for collaboration to have the whole team working directly from production servers. Best part? You get INSTANT feedback.

I just commit directly to master with auto-deploy like a real cowboy, yee-haw!

What does "stale code" even mean in this context?

Does that mean it falls behind stable? Just merge stable into your branch; problem solved.

Or is this just some coded language for "people aren't adopting my ideas fast enough". Stop bitching and get good.

Do we have a Linked In Lunatics sub on Lemmy?

My old boss (at a sturtup with some ten ppl) loved to do this. When you’re done with your work, merge to master. Boss-man would then revert the commits if he didn’t like the result. Since the branches all were merged, no-one knew what was actually in prod. Fun times.

If somebody actually did that it would be grounds for removing their privileges to merge into master. THIS, THIS is why the JavaScript ecosystem has gotten so bad, people with mentalities similar to his.

'i help JavaScript engineers become framework architects by getting them forcibly reassigned.'

Better yet just edit files live on prod from Notepad (not plus plus) over Samba for "xtreme moral" boost

I dunno but xtreme programming sounds like something straight outta Musk's wettest teenage day dreams.

This is why I include those preservative libraries in my projects. My code doesn't go stale for a whole three weeks longer.

This is satire, right? Surely no one would put their name on that publicly?

Like someone working in a kitchen boasting about a life hack of not wasting time with hygiene.

Developers: "Move fast and break things."

Things: break

Developers: surprised Pikachu face

What in the shit is "xtreme programming"?

Bet you $50 we later learn this guy was orchestrating a supply chain attack.

At my company we're so agile that we directly deploy branches from developers' local machines to customers for A/B testing.

Before everyone loses their minds, in Extreme Programming there are safeguards other than PR reviews. Before you submit a PR, you are supposed to have written the tests and to have written your code with pair programming, so your code already has some safety measures in place. On top of that, when you merge and deploy, more tests are run, and only if all of them are green do your changes go into production.

LinkedIn "influencers" are insufferable, dear god

I help JavaScript engineers become framework A...

ssholes.

If you’re working in a context where it’s okay to make mistakes so long as they get fixed later, you’re not working on anything important.

Permanently Deleted

this made my heart rate go up a little bit in a way that doesn't feel good

Nothing improves morale like the on-call having to unfuck production for the third time that hour because mUh VeLoCiTy decided code review and testing in CI was too slow.

Techbros are fucking cultists.

Kinda acceptable if you have a slow release cadence. Everything needs to be reviewed and fixed/accepted (with defect/US raised) before production though.

Needs to be in a smaller team with decent Devs too though!

It’s insane to me that gitflow won over TBD and Continuous Integration to the point that this is now considered an extreme position. Not all projects are open source with many remote collaborators.

What if instead of continuous integration we had continuous Disintegration, where you code while listening to The Cure on repeat

Let the users do the testing

Am not sure I disagree but I don't agree completely. It's insane to merge things that go to production without testing. However at the same time I don't like continuous integration one bit. Open source mantra is great in my opinion. Release early, release often. If code chews some important data, have a test version of it that needs to run some time before it gets pushed to production.

Delaying merge of someone's code means branches get further and further apart. At the same time code in main branch gets fixed and tested the most. I would merge often but only full features. None of the half-done stuff. Let humans test it a bit before it reaches target audience. That is usually good enough to catch most bugs. Those that do happen to leak into production are easily fixed since you have fast development cycle and deployment pipeline. And backup frequently.

Something like that happened to me yesterday. I reviewed one PR, then some Important Guy came in and said:

• it is nice you reviewed my work, but we need to push this to production right now.
• just fix these things, I described you how. Just copy/paste these snippets
• these are cosmetics, I don't care
• "cosmetics", huh? Your shit may just crash
• gfy and push this to production right now
• well, ok

Of course, lack of these "cosmetics" caused crash in production. It's my fault of course.

Ah, yes, the Agile approach.

"Xtreme programming practices".

Lmao what!

I mean this is basically a wiki, isn't it.

Does he work at Rivian?

Didn't knew KenM was on LinkedIn.

Test it? Meh. Just ship it.

I kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production

The "send it" school of PRs.

Pete was Heard, but was he Listened To?

I wonder how many programmers out there have intentionally set out to subtly sabotage the system. Anyone doing that, good luck to you.

You guys review?

As a SOC auditor you programmers are going to make me scream at the exceptions you guys cause.

This explains what is going on a facebook.

@agilob code is like wine. You let it out in the cold and it gets better over time by itself.

It can work if you have a test zone and only a small amount of people work on a given code base.

Also checks to ensure the code compiles and tests pass before merging, as some quality gateway.

Probably unpopular opinion, but peer reviews are overrated. If coders are good AND know the project, the only thing you can do in a PR is nitpicking. They are more useful for open source collaborators because you want to double-check their code fits with the current architecture. But people here are reacting as if peer reviews could actually spot bugs that tests can't catch. That happens rarely unless the contributor is junion/not good.

The subtle Linux-flex in the screenshot.

That's nice but it goes against our quality standards and the international quality standards we are charging the client extra for adhering to, the line you're trying to merge into is stability and needs CCB approval for the merge, and the client has specifically requested only showstopper-level bugs be addressed for stability lines. You know what, I have neither the time nor the crayons to properly explain this to you, a consultant that supposedly knows the business. Pack your shit, you're gonna have a wonderful time posting this crap on LinkedIn instead. #gitshiton

2 days before, at Pete Hurrd former job