this post was submitted on 08 Jun 2024
724 points (97.0% liked)
Programmer Humor
32558 readers
528 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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.
That's what QA engineering is for. They are integrated into the dev team and they pull double duty with QA and code review.
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.
I'm thinking of it not as a title, but a role. Often times the 2 are not related
Sorry, I'm not native English. What would be the difference?
A title is just something a company calls a particular job. A role is what that job actually is. So a lot of jobs might be called "QA engineer", but not fitting the intended role
Gotcha. I mean, all software engineers should do some QA engineering, but we have QA engineers who are the experts and "QA coaches".
As a qa engineer this makes me feel better about myself. Because I'm included on reviews but never know what I'm looking at.
I've worked in places where QA we people with no coding knowledge who just clicked around looking for bugs, as well as places where QA never did that, only automated tests. And then there are places that believe hiring QA is useless, because "everyone should do QA".
This is my first big career job and in my limited experience I think I support the idea of a second pair of eyes, with a hybrid on automated testing. It seems more comprehensive and thorough than having a single person work on a task (minus code reviews).
In the end it comes down to the size of the team/company.
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
Dedicated to testing, absolutely, but they don't necessarily require expertise regarding implementation.
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, .....
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.
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.
Exactly. Shit happens, and we might need to adapt and even scrap a whole sprint plan. But that's super rare, or it should be. But changing the Roadmap after each sprint is just something that happens.
Either way, none of that warrants random calls at all times from colleagues.
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
That's what retros are supposed to be for. To discuss how to improve the process.
lol that's funny, you're funny
from what you describe it does sound like a nightmare, but you’re ignoring or mocking people that tell you that it is not the norm
How am I ignoring or mocking anyone?
I got that impression from your reply “lol that’s funny, you’re funny” to a completely non humorous comment
Then you took it incorrectly, its mocking my employer more than anyone.
got it, apologies
No worries, it happens
Nah, I think you're mixing things up here.
"Toxic" is just a label you're putting on everything you don't like and you're also putting a ton of implications behind it.
If Stacy wants a feature, and she's the official representative, I need to clarify what that feature means. A manager can't shield me from having to research the technical implications, that's my job.
Also, you can ignore calls all you want, if there is a genuine need to communicate, you need to have that call at some point. That's actually your first point in the list above.
I think you never worked in a role above code grunt. As a senior developer, my job is to do all what I described above. I need to do all the technical legwork a manager can't. I need to write everything down. I need to get feedback from stakeholders. That's nothing a manager can do and that's nothing a junior can do.
I code something like half an hour a day.
It's not a label im making up. Toxic here is a synonym for unhealthy. If someone keeps calling you, interrupting you, micromanaging you, disrespecting your working hours or your focus times, that's an unhealthy relationship.
Stacy is entitled to regular details, sure. That's why we have tickets, and daylies and retros. She's not entitled to asking multiple times day if you're done yet.
I work above senior, have done management and tech lead. I've seen toxic workplaces, and I've seen good ones. I recognize the need for all the agile rituals. But that still doesn't entitle people to call all the time and interrupt you.
None of the things you mentioned were in my description. You made that up completely. I talked about meetings, no scheduling information.
Did I even imply that? No. You made that up.
Hearing only what you want, not what the other person said makes you almost perfect management material.
Seriously, look at my comments and your replies. You answered to a completely different reality.
I might... Have mixed multiple thread. I'm sorry
Who's gonna tell them?
But testing... Is that really necessary?
…we haven‘t been sued by our customers for bad code!
Yes thats due to testing.
Can you prove that?
…
Yes. But I don't really count testing as part of code review.
Not to mention the fact that the more code there is, the more bugs you have.