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.
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 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
Yeah, I see your point. Maybe my employers are different, it’s never been an issue explaining why the ticket isn’t closed just because the PR is merged
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
Sorry about the confusion. It’s not sarcasm. I’m just sick and tired of people blocking my PR because of an argument about wether the function should be called X or Y or Z or D
Ah. Yeah those kind of nitpicks are annoying. We try to specify when comments are blocking or non blocking on reviews.
But I definitely block a lot of reviews over no tests, bad tests, no error handling, failed linting. And the occasional “this doesn’t do what the ticket asked for”
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.
Code doesn’t need to be managed the same way in a company as it does in an open-source project.
Open-source projects are usually longer lived more maintainable, more stable, and more useful than any closed source code I’ve ever worked on for a company. Partially because they’re not under contract deadlines which create pressure to “deliver value” by a certain date, but still. Might be helpful for companies to consider adopting practices the open-source community has shown to work, rather than inventing their own.
Ugh, not this SAFe Agile ™ 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.
There’s often features and bug fixes worth more than the ones introduced in the PR. I’ve yet to see bug free code just because it’s went through review and QA.
Surely you’ve seen bugs caught because code went through review and QA though. Those are bugs that would go into production if following the “advice” in this post.
There is no value in spaghetti piled on top of rotten spaghetti. Tech iCal debt is real and if you’re just shippin it and plan to fix it later, y’all gonna have a bad time. Nothing more permanent than a temporary workaround.
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
It very well might be a real exploit. Lemmy was briefly taken down by an XS attack using the emoji library… so who knows, maybe a 3000% smiley face is all that is needed
I think there a lot of phone scammers that use font size to hide all the shit they’re doing. Like they make shit so small so that the old people can’t see anything
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.