this post was submitted on 09 Apr 2025
195 points (98.0% liked)

Programmer Humor

24111 readers
1600 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
 
all 39 comments
sorted by: hot top controversial new old
[–] flamingo_pinyata@sopuli.xyz 82 points 2 months ago (3 children)
[–] DScratch@sh.itjust.works 61 points 2 months ago

Tell me you commit your dependencies without telling me you commit your dependencies.

[–] pastel_de_airfryer@lemmy.eco.br 43 points 2 months ago

"updated package-lock.json"

[–] gravitas_deficiency@sh.itjust.works 14 points 2 months ago* (last edited 2 months ago)
[–] Susaga@sh.itjust.works 26 points 2 months ago (1 children)
[–] cute_noker 10 points 2 months ago

Only one dude reviewed it. In one minute.

[–] eskuero@lemmy.fromshado.ws 22 points 2 months ago (1 children)

Make sure to send all the code minified to make it small and easier to review.

[–] cute_noker 4 points 2 months ago (3 children)
[–] 4am@lemm.ee 8 points 2 months ago (1 children)

Tell me you’re not a web developer without telling me you’re not a web developer

[–] cute_noker 1 points 2 months ago
[–] funkless_eck@sh.itjust.works 1 points 2 months ago

ctrl+h

\s+

enter

[–] BeigeAgenda@lemmy.ca 12 points 2 months ago
[–] fckreddit@lemmy.ml 7 points 2 months ago

These are rookie numbers. Any commit less than 100k lines changed is.

[–] hddsx@lemmy.ca 4 points 2 months ago (5 children)

Because my company works on archaic infrastructure, should PRs be as small as possible with sub-issues sorted into smaller PRs?

[–] Lysergid@lemmy.ml 21 points 2 months ago

PRs should be exactly as big (or small) as task requires. It’s task that needs to be split into smaller task, if it makes sense to split of course.

[–] DScratch@sh.itjust.works 8 points 2 months ago (2 children)

Small PR are easy to review and parse. Work gets broken down in to small, shippable changes. If you couple that with feature flags, you can get to a point where shipping a release is as easy as building whatever the latest commit is on Main and pushing it out the door.

Automate that, do it every week or two.

[–] bluGill@fedia.io 3 points 2 months ago (1 children)

Easy to say if your code doesn't matter. If you work for regulated industries (FAA, FDA) you can't ship it out the door.

I have been working on automating our tests for years. Manual testing still finds a lot of things despite passing all the automated tests. I'm now convinced anyone who says "automate that" doesn't care about quality, humans are too good at finding things.

[–] DScratch@sh.itjust.works 3 points 2 months ago

I completely agree. Not mentioned in my spiel is the constant human QA effort, each ticket merged gets checked, releases get a week of testing before release to the public.

Also, yeah. I’m iOS frontend. I make pixels dance. Either I leave security to Keychain or I hope (read: confirm) backend is sanitising inputs.

[–] thejml@lemm.ee 1 points 2 months ago (1 children)

I completely agree, but every week or two is too long. At one point we had ours running builds + automated regression testing => release twice or more a day. Along with automatic change logs and monitoring, It was so nice. Tiny updates are always better to test and know exactly what/where/how a failure or positive change occurs when the cadence is that fast. The devs loved it, the QA loved it, and as a DevOps, I loved it. We were even able to do AB testing and rolling updates.

It only got worse when management changed hands and some people decided on going agile in a “Scrum-but” method and it’s been a drag that sprints are 3 weeks long. Now releases take longer, have larger impact for better or worse, and regression testing is much more complex and I have to be more involved in releasing new code. The faster cadence meant it happened so often it was fully automated and I didn’t even know when most went out unless I was watching a dashboard.

[–] DScratch@sh.itjust.works 2 points 2 months ago

Mobile app users get annoyed if you push too many updates. So you gotta pace yourself.

[–] cute_noker 3 points 2 months ago

This took me a month to make. Moving from docker swarm to kubernetes.

"Containers are platform independent, and can run on anything" - yes... But...

[–] aleq@lemmy.world 2 points 2 months ago (1 children)

If you're organisation is small/flexible enough, maybe look into using some kind of stacked diff system. We used graphite at my previous company and it's amazing for working with these kinds of things where you have a million little things to fix and they're all kind of dependent on each other.

[–] hddsx@lemmy.ca 3 points 2 months ago (1 children)

I’m slowly pushing my team to git. It’s stupid that we can’t work when the server goes offline

[–] cute_noker 1 points 2 months ago* (last edited 2 months ago) (1 children)

It can be quite overwhelming if nobody knows how to use git.

I know software teams that went back to share code on teams folders after having used git...

Please get a git course for all the developers

[–] hddsx@lemmy.ca 2 points 2 months ago (1 children)

I mean, I dabble in got on my own. But I’ve never managed a git for a team.

Thankfully I’ve set up Forgejo to abstract some of the details away.

I desperately want to get my team out of the 80s, but I’m not the manager so sometimes my pushing goes nowhere

[–] cute_noker 1 points 2 months ago

Oh I know that feeling. But when you get the hang of it you will never go back

[–] onlinepersona@programming.dev 2 points 2 months ago* (last edited 2 months ago)

It's not the size of the PR that counts!

Anti Commercial-AI license