Guess what? A conversation I was having on Twitter got me excited enough to blog again. Perhaps reading Twitter isn't such a depressing waste of time after all.
The problem with code reviews is that it is too easy to end to end up with code targeted at the lowest common denominator of the ability of the reviewers.
— Ihe Onwuka (@mazihe) October 21, 2020
As developers, we all know that code reviews are a good thing in theory. They should help us:
The reality is that code reviews can frequently be an uncomfortable experience for everyone involved, leading to reviews that are combative, ineffective, or even worse, simply not happening.
Here is a quick guide to help you to create an effective code review process.
It's been a while since I wrote a conference write up. The short version of "why" is because I got a bit bored of doing it. Plus, I found I was attending conferences as a speaker "on the circuit", and my experience of hanging out, catching up with my friends, chatting to other attendees to see what they're up to and so forth, didn't seem as useful to share with people who might want to find out whether a conference is worth attending from a content or atmosphere point of view.
But I feel compelled to blog about JavaZone. I presented there back in 2013, but every year since then haven't made it for one reason or another (the fact that it's near my birthday in no way impacts my scheduling…). I made the effort this year, and I'm so pleased. Now I've been to many more conferences, of various sizes, various themes, all around the world, and I can definitely state that JavaZone is up there as one of the best conferences around.
Why?
I wrote a post for the JetBrains Upsource blog about some of the things you should be looking for when you do code reviews (and some of the things you should not be looking at). I’d love to get feedback in the comments for the post of things that you look for in code reviews.