Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
Let the users do the testing
this post was submitted on 14 Nov 2023
732 points (97.0% liked)
Programmer Humor
19512 readers
339 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
Oh hey a fellow game dev, how long you been in the industry?
They're a Windows dev, clearly.
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.
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.
"Xtreme programming practices".
Lmao what!
I mean this is basically a wiki, isn't it.
A typo in the first paragraph of the article in a wiki wont make the 5th paragraph tear down the entire wiki.
load more comments
(1 replies)
Does he work at Rivian?
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
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
load more comments
(14 replies)
The "send it" school of PRs.
Pete was Heard, but was he Listened To?
Didn't knew KenM was on LinkedIn.
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?