Comments on: Practicing effective self-review https://blog.beanbaginc.com/2014/12/01/practicing-effective-self-review/ Updates from the makers of Review Board Thu, 13 Oct 2016 16:25:50 +0000 hourly 1 https://wordpress.org/?v=6.2.14 By: Blog: Thoughts on version control from a game dev perspective • VGL Entertainment https://blog.beanbaginc.com/2014/12/01/practicing-effective-self-review/#comment-137 Thu, 13 Oct 2016 16:25:50 +0000 http://blog.beanbaginc.com/?p=285#comment-137 […] to committing you should conduct self-review or peer-review. Self-review is similar to peer-review, only you are reviewing your own code, […]

]]>
By: doug https://blog.beanbaginc.com/2014/12/01/practicing-effective-self-review/#comment-21 Wed, 03 Dec 2014 16:53:37 +0000 http://blog.beanbaginc.com/?p=285#comment-21 Self review is less biased when done not immediatly after producing the thing. “Wait at least 3 days” may be a tip for effective self review.

]]>
By: eltomito https://blog.beanbaginc.com/2014/12/01/practicing-effective-self-review/#comment-20 Wed, 03 Dec 2014 12:21:21 +0000 http://blog.beanbaginc.com/?p=285#comment-20 I agree with the general recommendation of this article that it helps to review your own code before passing it on to someone else to review and I find it helpful to look at it in the same tool the other guy will be reviewing it in.
But the rest of the recommendation seem to come from a fairy-tale world to me:

In reality, who has the time to “wait a day” before re-reading the code? (Imagine there’s no deadlines, and no clients, too. Imagine all the coders…)

“Pretend you’ve never seen your code before” – how do you do that? Bang your head against the wall really hard and hope to induce amnesia?

“Use checklists for code review” – and if you do, keep it to yourself because the next thing you know, it becomes the company policy, there’s a half-broken web tool your company requires you to use which randomly breaks other web tools it pretends to integrate with.

“Read documentation, comments, and displayed text out loud” – in an openspace, right. That calls for a Monty Python sketch.

“Take the opportunity to write more documentation.” – implying you have a lot of spare time and energy left after you have read your entire code submission out loud in the restroom to the accompaniment of your colleagues banging on the door to make you get the *#@! out of there.

But as I’ve said, I agree: let’s keep dreaming!

P.S. Don’t take this comment too seriously. It probably just means I need a vacation.

]]>
By: Cindy https://blog.beanbaginc.com/2014/12/01/practicing-effective-self-review/#comment-19 Wed, 03 Dec 2014 01:52:10 +0000 http://blog.beanbaginc.com/?p=285#comment-19 In reply to Bryan Eslinger.

I found that new hires often just don’t think to read their code in the code review tool, I always explicitly ask for it now. It really help catching mistakes if you see your code in the same tool as your reviewer. You don’t want to waste your reviewer’s time with simple formatting or spelling mistakes while they could be looking at more important things.

]]>
By: Bryan Eslinger https://blog.beanbaginc.com/2014/12/01/practicing-effective-self-review/#comment-18 Tue, 02 Dec 2014 01:18:20 +0000 http://blog.beanbaginc.com/?p=285#comment-18 Review code with a different tool than you write it…so simple, so brilliant. Becoming part of my workflow immediately.

]]>