this post was submitted on 14 Nov 2023
708 points (96.9% liked)

Programmer Humor

19821 readers
915 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

founded 2 years ago
MODERATORS
708
Merge then review (programming.dev)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
 

Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.

(page 2) 50 comments
sorted by: hot top controversial new old
[–] [email protected] 11 points 1 year ago (1 children)

Let the users do the testing

[–] [email protected] 9 points 1 year ago* (last edited 1 year ago) (1 children)

Oh hey a fellow game dev, how long you been in the industry?

[–] [email protected] 4 points 1 year ago

They're a Windows dev, clearly.

[–] [email protected] 9 points 1 year ago* (last edited 1 year ago)

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.

[–] [email protected] 9 points 1 year ago

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.

[–] [email protected] 6 points 1 year ago

"Xtreme programming practices".

Lmao what!

[–] [email protected] 5 points 1 year ago

Does he work at Rivian?

[–] [email protected] 5 points 1 year ago (1 children)

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

[–] [email protected] 9 points 1 year ago (1 children)

A typo in the first paragraph of the article in a wiki wont make the 5th paragraph tear down the entire wiki.

[–] [email protected] 3 points 1 year ago

you'd be surprised how complex MediaWiki syntax is nowadays, there are many ways to break things on a wiki

[–] [email protected] 4 points 1 year ago

Didn't knew KenM was on LinkedIn.

[–] [email protected] 4 points 1 year ago (1 children)

Test it? Meh. Just ship it.

load more comments (1 replies)
[–] [email protected] 4 points 1 year ago

Pete was Heard, but was he Listened To?

[–] [email protected] 4 points 1 year ago

The "send it" school of PRs.

[–] [email protected] 3 points 1 year ago

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

load more comments
view more: ‹ prev next ›