Back at work for one of my teams, we were struggling to get code reviews somehow included into out ways of working. People would always work on individual areas, and getting on someone else's area was deemed hard.
The team's architect had been contributing on code review front a lot, and was at a point where he said the work needs to be shared. So the team was discussing how to get that done, without being able to significantly put time into reviewing.
Many voiced out the concern that reviewing without understanding what the change is about (feature this adds) is like proofreading and not really the thing they'd be into. And understanding the change - as they tended to not be that small - would take an effort, as even the basis that was being changed was not well understood by others.
I would throw out various suggestions from pair programming (continuous code review, really) to people presenting the change and code to another developer, and we went for this: agreeing a pair for a sprint (month) and having at least one one-hour present and discuss session. And as it turned out, the pairs without me would be uneven, so I would of course volunteer in the circle, not really looking forward to it.
With names picked out of a hat, I would have my pair. We'd schedule a time, with the difference to other pairs that there would not be my code to show as I did not produce any. So we went for half the time.
At time of review, there was nothing indicating that the developer thought that the whole pairing up with me was silly - except things going on in my own head. I "knew" he'd rather have some of the more advanced developers with him. I "knew" he did not really want to explain stuff to me. And I kept all my discomfort inside me, and did what I could.
He showed the code and his changes, and I was mostly just puzzled. His code seemed very straightforward, his explanations made sense to whatever degree I could judge, and we kept browsing. We very soon run into code that had been commented out, many times. I would ask why that was there, and after a few of those questions his "I might need this later" turned into "let's take them out while we're at it, I always forget to clean them up later".
As our time was up, I felt I had been very little use again. But now six months later, that developer having left the company to be replaced by another, I started appreciating even this little contribution: removing the clutter that really made it harder to read.
I also realized that in situations like this, I tend to be my own worst enemy. I'm the one who expects more of me, while others do not. I mirror my own insecurities into others, and forget to celebrate the little successes and learnings.
The team's architect had been contributing on code review front a lot, and was at a point where he said the work needs to be shared. So the team was discussing how to get that done, without being able to significantly put time into reviewing.
Many voiced out the concern that reviewing without understanding what the change is about (feature this adds) is like proofreading and not really the thing they'd be into. And understanding the change - as they tended to not be that small - would take an effort, as even the basis that was being changed was not well understood by others.
I would throw out various suggestions from pair programming (continuous code review, really) to people presenting the change and code to another developer, and we went for this: agreeing a pair for a sprint (month) and having at least one one-hour present and discuss session. And as it turned out, the pairs without me would be uneven, so I would of course volunteer in the circle, not really looking forward to it.
With names picked out of a hat, I would have my pair. We'd schedule a time, with the difference to other pairs that there would not be my code to show as I did not produce any. So we went for half the time.
At time of review, there was nothing indicating that the developer thought that the whole pairing up with me was silly - except things going on in my own head. I "knew" he'd rather have some of the more advanced developers with him. I "knew" he did not really want to explain stuff to me. And I kept all my discomfort inside me, and did what I could.
He showed the code and his changes, and I was mostly just puzzled. His code seemed very straightforward, his explanations made sense to whatever degree I could judge, and we kept browsing. We very soon run into code that had been commented out, many times. I would ask why that was there, and after a few of those questions his "I might need this later" turned into "let's take them out while we're at it, I always forget to clean them up later".
As our time was up, I felt I had been very little use again. But now six months later, that developer having left the company to be replaced by another, I started appreciating even this little contribution: removing the clutter that really made it harder to read.
I also realized that in situations like this, I tend to be my own worst enemy. I'm the one who expects more of me, while others do not. I mirror my own insecurities into others, and forget to celebrate the little successes and learnings.
