You're viewing a single thread.
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.
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.
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?
Not to mention the fact that the more code there is, the more bugs you have.