There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

silencioso ,

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.

agilob OP ,
@agilob@programming.dev avatar

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?

silencioso ,

Fire you for destroying the tests. It’s intentional sabotage.

Blackthorn ,

I would fire you for incompetence and sabotage. Problem solved.

pomodoro_longbreak ,
@pomodoro_longbreak@sh.itjust.works avatar

Give you public kudos for moving fast and breaking things. We need more fearless cowboys like you around here

MeanEYE ,
@MeanEYE@lemmy.world avatar

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.

dbilitated ,
@dbilitated@aussie.zone avatar

I just made a github action that merges anything updated in master into feature branches automatically. you get pinged if there’s a conflict but the automerge keeps drift to a minimum so it’s less common and fixed sooner.

better than merging poorly tested/reviewed code.

and yeah, a small team of superstars doesn’t need reviews so much, but most teams have a range of devs with different levels of experience and time working with particular parts of a large codebase. Someone more senior or more expert derisks people picking up tickets and improves code quality.

it also leads to plenty of good conversations about the best way to implement, so overall it’s a win.

MeanEYE ,
@MeanEYE@lemmy.world avatar

Well, Git was designed to branch out, not be a single repo with bunch of users. So one team can have a local repo, that in turn gets merged into big one, etc. Structure matters as you say. Small experienced teams move fast. Big teams require a lot of management and supervision. I still think it’s better to split people up into small teams and give individual tasks, or let them pick tasks that need to be done.

redcalcium ,

Pair programming? Then the code is already reviewed.

hglman ,

Yes, that’s part of the point. Dumping all at once into a merge and asking people to comprehend it all isn’t particularly realistic.

petrescatraian ,

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

okamiueru ,

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.

DudeDudenson ,

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

affiliate ,

never chew before swallowing either. the food can still get stale in your mouth

fosforus ,

That would certainly explain some things in the nodejs culture.

https://sopuli.xyz/pictrs/image/5d2e098a-b867-4350-aab3-6cfaf753b37e.png

Nighed ,
@Nighed@sffa.community avatar

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!

dannym ,

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.

NigelFrobisher ,

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.

rainynight65 ,

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

enitoni ,
@enitoni@beehaw.org avatar

Both?

vox ,
@vox@sopuli.xyz avatar

pete’s a fucking genius

bier ,

Exactly, this is how you pay off your mortgage

Skates ,

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.

2 days before, at Pete Hurrd former job

Devi ,

This explains what is going on a facebook.

Manifish_Destiny ,

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

VantaBrandon ,

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

MeanEYE ,
@MeanEYE@lemmy.world avatar

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.

VantaBrandon ,

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

floofloof , (edited )

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.

VantaBrandon ,

Right? Who needs a QA team when you can use real live customers for testing

floofloof ,

It’s the Microsoft way.

DefinitelyNotAPhone ,

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.

intensely_human ,

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.

MJBrune ,

Honestly that’s okay. That’s how most of the games industry works and you know what? I sleep very well knowing that none of my code is actively hurting people. I do likely have some code in some defense simulator from my work on squad but so be it. Overall I make toys. Works of art and as long as the bugs are caught it really doesn’t matter when. As long as it’s before release. Even then you can just work at Bethesda and just never fix them no matter what.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •