this post was submitted on 08 Jun 2024
719 points (97.1% liked)

Programmer Humor

31163 readers
1941 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 4 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 142 points 2 weeks ago (5 children)

I mean, you're not hired to "code", you're hired to do software engineering. That usually means working with other people. Reviewing code is a win win situation because both get a second pair of eyes on their code and prevent each other from committing dumb shit that you might have to fix later.

I feel like these memes of hating everything other than lone coding is because you keep working for toxic companies. Ffs you're programmers, it's probably super easy to get another job. It doesn't have to be like this.

[–] rockSlayer 26 points 2 weeks ago (3 children)

I think QA engineering needs to become more widespread. The "extra pair of eyes" can't compare to a department of people dedicated to code review and testing.

[–] [email protected] 30 points 2 weeks ago (1 children)

QA and Code reviews do different jobs. Manual and automated testing will not notice your code is shit, so long as all test cases pass.

[–] rockSlayer 6 points 2 weeks ago (1 children)

That's what QA engineering is for. They are integrated into the dev team and they pull double duty with QA and code review.

[–] [email protected] 11 points 2 weeks ago (8 children)

In my company QA is dedicated to manual and automated tests. I haven't met many QA engineers who could effectively review any of my code.

load more comments (8 replies)
[–] Windex007 13 points 2 weeks ago

You don't want a department that you throw it over the fence to, you want them embedded on your team. Keep those feedback loops TIGHT bois

load more comments (1 replies)
[–] [email protected] 18 points 2 weeks ago (1 children)

I feel like these memes of hating everything other than lone coding is because you keep working for toxic companies.

No, it's because we are working with humans and their deeply flawed organizations. As much as people hate corporations and love startups, both are always a mess. Every organization I've seen from the inside is barely functioning. Cruft, interpersonal conflicts, incompetence, or simply very bad market situations.

Software engineering kind of has to get involved with almost all of that. If you need to get approval from department A and Stacy just keeps changing what she wants, you'll have to carry that chaos into the development and it will usually percolate through half the engineering department, because hardly any interface is actually a stable attack surface. That means meetings, calls, meetings, reviews, meetings, and fucking Stephen again wants to pitch this weird framework he's so in love with, meetings, budget calls, because there's no way, simply changing the field length can take that much work, meetings, .....

[–] [email protected] 13 points 2 weeks ago (6 children)

It's not about corps vs startups. It's about having processes, good communication, dialogue, empathy. And it's also your manager's job to protect the team from externals that keep interrupting and making adhoc requests. If you don't feel safe in ignoring calls and replying with "I'm busy now, schedule smth today please", I consider that a highly toxic workplace.

[–] Alexstarfire 7 points 2 weeks ago (1 children)

For real. All the stuff that person complained about is something a manager should be handling. Mine do. It's very rare for requirements to change for things I'm working on. There's typically going to be some small changes, e.g. wording of a message or moving things around in the UI, that happen but that's to be expected and one of the better parts of working in agile. You make something and find it doesn't work as well as you hoped? Tweak it.

I think the only time things can change drastically is when I'm working on a priority event, AKA something really bad happened for a customer and we've got to fix it ASAP. There's no time to do in depth research beforehand. You just dive in and sometimes you think it's one thing but it's really something else or it's just more involved than you thought.

load more comments (1 replies)
[–] [email protected] 4 points 2 weeks ago (9 children)

I guess every job I've ever had has been toxic then. Juniors and to some degree mid-levels don't usually have any say in things like when to meet

load more comments (9 replies)
load more comments (4 replies)
[–] [email protected] 4 points 2 weeks ago (2 children)

But testing... Is that really necessary?

[–] [email protected] 13 points 2 weeks ago

…we haven‘t been sued by our customers for bad code!

Yes thats due to testing.

Can you prove that?

load more comments (1 replies)
[–] SpaceNoodle 4 points 2 weeks ago

Not to mention the fact that the more code there is, the more bugs you have.

[–] fubbernuckin 4 points 2 weeks ago

Ffs you're programmers, it's probably super easy to get another job. It doesn't have to be like this.

Who's gonna tell them?

[–] kaffiene 51 points 2 weeks ago

Coders who complain about documenting and tests are coders I don't want to work with

[–] MisterFrog 38 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Problems caught early are much easier to fix than problems caught later. This applies to any project (I'm not a programmer, but an engineer in the traditional sense).

Just "doing it" without coordination and review is a great way to waste a bunch of effort down the line with re-work.

Edit: typo

[–] [email protected] 8 points 2 weeks ago

While i agree with the principal statement, this also requires two things to work:

First: The scope should be defined properly, so people can contextualize what they are actually doing and reviewing.

Second: If the scope is subject to change, or parts of it are unclear, there needs to be room to consider, develop and try different variants

This is were good management is crucial, which includes giving breathing room at the start. What we tend to experience is the expectation of already good detailed results, that can be finalized but still work if things change significantly.

[–] thesporkeffect 37 points 2 weeks ago (2 children)

Honestly documentation is at least as important as code , but I get you

[–] [email protected] 21 points 2 weeks ago (3 children)

And isn't testing even more so!?

img

[–] thesporkeffect 12 points 2 weeks ago (2 children)

Agree, I would put tests higher than documentation, I just got to documentation first and was triggered enough to comment immediately

[–] [email protected] 4 points 2 weeks ago

Hehe, no hate here - I likewise was spinning off of what you said, carrying it forward:-) (bc those are quite important matters indeed!)

load more comments (1 replies)
load more comments (2 replies)
[–] themeatbridge 9 points 2 weeks ago (1 children)

Code Review is also critical and worth every minute you actually spend on it. "Code review" not so much.

load more comments (1 replies)
[–] [email protected] 37 points 2 weeks ago (1 children)

Documentation and testing are fundamental parts of writing code.

[–] iarigby 8 points 2 weeks ago (1 children)

Also, tests ARE THE code, and equally important too! However so many people make the mistake of writing tests after the function, when the benefit is less immediate. They also have the illusion that they are done and have to do extra work. And since they didn’t write the test first, they most likely wasted a ton of time and energy on extra work of testing changes manually

load more comments (1 replies)
[–] ChickenLadyLovesLife 28 points 2 weeks ago

I solved this dilemma by quitting and becoming a school bus driver. Now I only have to worry about middle-schoolers threatening to shoot me.

[–] [email protected] 24 points 2 weeks ago (2 children)

Oh man, the "quick call?"s are the worst

[–] [email protected] 6 points 2 weeks ago

"Got a sec?"

load more comments (1 replies)
[–] [email protected] 20 points 2 weeks ago (3 children)
[–] [email protected] 24 points 2 weeks ago (3 children)

That would imply that people check your calendar before randomly calling. I get calls on Teams even when setting it to appear offline.

[–] [email protected] 22 points 2 weeks ago

Lol I get calls during calls

[–] [email protected] 13 points 2 weeks ago (1 children)

People call you directly without asking? Ignore them ffs.

[–] [email protected] 10 points 2 weeks ago (2 children)

Direct co-workers usually ask, it's mostly higher-ups that do it. I guess they think that they're important enough to do it. I absolutely ignore it if I don't have time or are on break.

[–] [email protected] 6 points 2 weeks ago

even those higher ups need to learn that their underlings can only be productive when they aren't being prevented/distracted from being productive.

[–] Restaldt 4 points 2 weeks ago

FYI teams has a setting to block direct calls and an automated voice message for missed calls.

Mine has been set to reject calls and play an automated message letting the caller know to ping me first on teams ever since my company decided it was an amazing idea to forward every employee's office phone number/calls to our God damned teams account.

I despise spam calls and refuse to take calls unless asked first

load more comments (1 replies)
load more comments (2 replies)
[–] Bye 19 points 2 weeks ago (3 children)

Imagine actually going to daily standup, wow

I made a daily meeting invite, and told my team to never show up to it. Lets them show up to work an hour later since I put it in the calendar for 930-10.

[–] [email protected] 16 points 2 weeks ago (3 children)

Depends on the team. My team do daily standup and it helps. A lot. "What are you working on today and do you need any help to get it done" is a super powerful question to make sure we're all focusing on the same priorities and sharing the knowledge we have, especially in a team of mixed disciplines.

[–] [email protected] 5 points 2 weeks ago (4 children)

Why not reach out to reach to each team member on a daily or semi daily basis to ask that question?

These meetings REALLY get in the way of progress and we've been killing it ever since our new manager started doing it like this

[–] [email protected] 10 points 2 weeks ago* (last edited 2 weeks ago)

I actually tried a daily slack bot instead. The team HATED it with a passion. And the amount of productivity lost on other teams to a backend engineer blocking a systems designer being blocked by a UX flow etc is insanely large. We have never missed a deadline, hit all our revenue targets, and get much. much larger features done in 2/3rds of the time of the next nearest team. Part of that is because we've made sure to reinforce the concept that we are a single team instead of a group of server engineers, backened engineers, frontend engineers, system designers, [removed to protect identity] designers, econ specialists, UX designers, UI artists, and QA working in their own bubble.

load more comments (3 replies)
load more comments (2 replies)
load more comments (2 replies)
[–] [email protected] 19 points 2 weeks ago (1 children)

Docs and testing have no bravado, but they're important. If they're dragging you down, use your problem-solving brain and find a way to make them work for you.

[–] [email protected] 4 points 2 weeks ago

(Sincerely, someone who doesn't floss)

[–] Tenthrow 10 points 2 weeks ago

Yes testing is such a big problem for those coders.

[–] [email protected] 10 points 2 weeks ago
[–] [email protected] 7 points 2 weeks ago

The first 3 are why I can't get any work done anymore. The last 3 I would absolutely love to have more time to do.

[–] [email protected] 7 points 2 weeks ago (4 children)

I worked freelance for like a decade. Then I joined a “real” studio. Literally 80% meetings, team meetings, morning stand ups, presentations, documentation, and senior reviews, then 20% actual work. My old boss was great with time management but he left and the new leads would lock you into a 3h meeting, most of it to discuss other people’s work, then expect you to make 3 days worth of edits in 3h.

I feel this meme hard.

load more comments (4 replies)
[–] [email protected] 5 points 2 weeks ago (1 children)

Less time is spent handling on-call issues if you do the code reviews, documentation, and testing...

[–] [email protected] 4 points 2 weeks ago

Not necessarily. Also depends on competency of whoever is looking at using your software/investigating and the legacy of the things you described. A whole different scenario if it's because you forgot to write something in a ticket and someone coming to call for help with docker when you have a docker setup guide they never look at.

[–] Matriks404 4 points 2 weeks ago

That's why I only code as a hobby.

load more comments
view more: next ›