News for hackers. Stuff that matters.
Re:When hiring developers, have the candidate read existing ... by actually_a_dog on Saturday April 16, 2022 @04:37AM (#31050736)
Anyone who can't handle having their code reviewed before it goes into production is not welcome on my team. You can call that antagonistic or not, but I have always found that the best engineers are the ones who are able to separate criticism of their code from criticism of themselves. Get that type of people on your team, and code review is no longer antagonistic: it's just an egoless feedback process that improves the end product, which is what all members of an engineering team should be working toward.
Re:When hiring developers, have the candidate read existing ... by jseban on Saturday April 16, 2022 @04:57AM (#31050821)
I'm not criticising the review itself as much as rather the PR workflow and the tools of github, especially the blocking mechanism. It's my opinion that collaboration should happen much sooner rather than being pushed to the end with the review of a PR, and that you should have designated people who have the power to sign something off as production ready.

If a team inside a company want to gather inspiration from the open source world, they should look at how the owner teams of open source projects work internally, not how they work together with outside contributors.

And, it's a very common "solution" in tech to just simply not have any feelings, but people have feeling and that you can't turn off, and that's a very important contributor to work satisfaction.

Re:When hiring developers, have the candidate read existing ... by actually_a_dog on Saturday April 16, 2022 @05:03AM (#31050857)
There is nothing about github hat prevents you from working that way. I don't see what your issue is. But, I will say that I don't want people who can't separate criticism of their code from criticism of themselves on my team. You can certainly have whatever feelings you want, as long as it doesn't get in the way of producing the best possible product, all things considered.
Re:When hiring developers, have the candidate read existing ... by jseban on Saturday April 16, 2022 @05:08AM (#31050878)
Yeah there's nothing that prevents you from using a tool in exactly the opposite way that it's designed to be used, but it's also pretty unlikely that it's going to happen or that it's going to be successful.
Re:When hiring developers, have the candidate read existing ... by Jensson on Saturday April 16, 2022 @10:44AM (#31052721)
Just make a PR early and discuss the code as you build and make changes, not sure in what way the tool wasn't made to do that. Then you also get the discussion interleaved with changes, resulting in basically perfect documentation of how the code was made and why.

The only thing PR's lack in that regard is that if the reviewer accepts it then it gets added automatically, while ideally you should re review things after the reviewer has accepted it. That way they wont accidentally accept prototype changes.

Re:When hiring developers, have the candidate read existing ... by actually_a_dog on Saturday April 16, 2022 @08:02PM (#31057199)
I'm beginning to think you've never actually used github. Are you trolling?

The tool does not stop you from working in the way you suggest. Maybe it's not what the engineers who wrote it originally envisioned, but it's both simple and easy to work in the way you suggest.

Re:When hiring developers, have the candidate read existing ... by forgotusername6 on Saturday April 16, 2022 @01:33PM (#31054245)
If I want early feedback on something I create a draft PR and ask for comments. I can then let people consider my approach asynchronously, in their own time.
Re:When hiring developers, have the candidate read existing ... by jseban on Saturday April 16, 2022 @05:11AM (#31050894)
> I don't want people who can't separate criticism of their code from criticism of themselves

Yeah good luck with that, nobody can completely separate criticism of their work from criticism of themselves. You are making your job as the team leader way to easy for yourself, "I only hire robots, that's how I solve all these pesky people issues".

Re:When hiring developers, have the candidate read existing ... by sethammons on Saturday April 16, 2022 @08:46AM (#31051877)
In over a decade of enforced code review experience, I've had one developer who was too immature to take feedback. Some folks take it personally and they shouldn't as long as the feedback is about the code. This requires some work on both reviewer and reviewee.

The guy who couldn't take feedback (person A) had code merged in that wasn't properly tested. Person B said, "hey A. I could use some help. We wrote some tests around $feature that were missing and the tests show the feature doesn't work. We see $unexpected results. Wanna make sure we agree on how this should work."

Person A: no, it works, I tested it.

B: could you help us identify the flaw in the tests then - they seem rock solid.

A: no, my code works.

B: ... ok, can you join us and talk through it?

A: no, it works.

A was removed from the team after management came in and A continued to not acknowledge his code could be wrong.

This was aberrational. We, as an org and as a team, constantly strove to keep the focus on the quality of the code. And, yes, his code was borked.

Re:When hiring developers, have the candidate read existing ... by jseban on Saturday April 16, 2022 @09:14AM (#31052049)
In this example, of course person A is completely in the wrong, but this is a bigger problem of being so immature that you can't admit any fault.

My suggestion is more along the lines of: use a pairing session for review so that you can bring your empathy as well as your technical expertise, and make it a step in the process just like any other steps (testing, PO approval) etc, and just trust people to do it.

I don't think there's any reason to use a tool from open source, to make code review enforced and with passive aggressive online communication and "blocking". Just seems to make work more painful, and less efficient as well actually.

Re:When hiring developers, have the candidate read existing ... by SilasX on Saturday April 16, 2022 @11:13AM (#31052944)
Oh wow, kudos to you, not just for having to deal with that, and getting A removed, but for being so diplomatic about approaching him on the issue.

And yes, someone that lost is pretty rare, but I'd say lower-grade versions of non-transparency and making their work hard to follow is pretty typical (and frustrating).

Re:When hiring developers, have the candidate read existing ... by jen20 on Saturday April 16, 2022 @07:37AM (#31051527)
> nobody can completely separate criticism of their work from criticism of themselves

Yeah I really hate those pesky automated linters running in standardised environments telling me I’ve screwed something up.

(/sarcasm, hopefully clearly!)

Re:When hiring developers, have the candidate read existing ... by olliej on Saturday April 16, 2022 @06:15AM (#31051173)
and yet many people on this subthread alone have worked in review-required jobs, and have not had a problem with it. They've also provided reviews for other people's patches, and presumably were also able to do it without personal attacks.

It's the bare minimum of professionalism.

If you are unable to separate feedback on your work, from attacks on your person, you are lacking some fairly fundamental skills needed for professional engineering.

Re:When hiring developers, have the candidate read existing ... by leaflets2 on Saturday April 16, 2022 @10:35AM (#31052661)
> If you are unable to separate feedback on your work, from attacks on your person, you are lacking some fairly fundamental skills

Or for any job role at all?