Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don’t let code become stale.
You must log in or register to comment.
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.
Yes, especially the newbies who don’t know what they’re doing.
Keep everyone awake and on their toes.
You’re not truly part of the team until you cause a massive outage.
New employees are responsible of at least 75℅ of documentation clarification and process overhaul.
I’m totally on board with process overhaul. Ours was stupid when I started, I said it was stupid, and nothing changed. If someone else comes in and can say it’s stupid more convincingly than me, that’s great.
Who me? No, must be someone else with my name you’re thinking of.
I honestly wouldn’t see this as a problem. But if you break something it’s up to you to fix it. But we also don’t do CI. We release features in batches after they have been tested and seen to be working.
Don’t hurt their morale!
I don’t know if sarcasm because there are actually maniacs like that in this world
Oops boss just did a
git push --mirror
Stop transfering people from sales to engineering!
But Elon’s annoying!
I really wish LinkedIn would add an anonymous cringe emoji. I would use it on like 90% of the content on that site.
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
I just commit directly to master with auto-deploy like a real cowboy, yee-haw!
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.
Right? Who needs a QA team when you can use real live customers for testing
It’s the Microsoft way.
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.
Another benefit is you never have to worry about merge conflicts
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.
‘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
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.
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.
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.
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?
Fire you for destroying the tests. It’s intentional sabotage.
Give you public kudos for moving fast and breaking things. We need more fearless cowboys like you around here
I would fire you for incompetence and sabotage. Problem solved.
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.
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.
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.
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.
I dunno but xtreme programming sounds like something straight outta Musk’s wettest teenage day dreams.
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.
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.
