Edited by Christopher Douce, Tuesday 30 September 2025 at 10:44
Although software engineering is what you call a technical discipline, the people element is really important. Software engineering processes are as much about people as they are about product. Some software engineering processes apply a process known a code review.
Code reviews
In SE Radio 400: Michaela Greiler on Code Reviews a code review is described as ‘a process where a peer offers feedback about software code that has been created’ (1:11). Greiler goes on to say that whilst testing can check the functionality of software, code reviews can help to understand ‘other characteristics of software code’, such as its readability and maintainability (2:00). The notion of these other characteristics relates to the notion of software quality, which is the subject of the next blog. Significantly, code reviews can facilitate the sharing of knowledge between peers. Since software is invisible, it is helpful to talk about it. Valuable feedback is described as feedback that leads of change.
Greiler’s podcast suggests that reviews can be carried out in different ways (8:00). They can be formal, or informal. Code can be emailed, or code could be ‘pulled’ from source code repositories. Feedback could be shared by having a chat, or should be mediated through a tool. The exact extent and nature of a review will be dictated by the characteristics of the software. The notion of risk plays a role in shaping the processes.
One of the parts of this podcast I really liked was the bit that emphasised the importance of people skills in software engineering. Tips were shared on giving (and receiving) feedback (19:20). I noted that a reviewer should aim add value, and the engineer’s whose code is being reviewed should try to be humble and open minded. A practical tip was to give engineers a ‘heads up’ about what is going to happen, since it gives them a bit of to prepare and be explicit about the goals of a review. The podcast also emphasised a blog post by Greiler that had the title: 10 Tips for Code Review feedback.
Towards the end, there was a comment that code reviews are not typically taught in universities (34:25). I certainly don’t remember being involved in one when I was an undergraduate. In retrospect, I do feel as if it would have been helpful.
A final question was ‘how do you get better at code reviews?’ The answer was simple: show what happens during a review, and practice doing them.
Reflections
When I was a software engineer, I spent quite a bit of time reading through existing code. Although I was able to eventually figure out how everything worked, and why lines of code and functions were written, what would have really been useful was the opportunity to have a chat with the original developer. This only happened once.
Although this conversation wasn’t a code review (I was re-writing the software that he had originally written in a different programming language), I did feel that the opportunity to speak with the original developer was invaluable. I enjoyed the conversation. I gained confidence in what I was doing and understanding, and my colleague liked the fact that I had picked up on a piece of work he had done some years earlier.
I did feel that one of the benefits of having that chat is that we were able to appreciate characteristics of the code that were not immediately visible or apparent, such as decisions made that related to the performance of the software. The next blog is about the sometimes slippery notion of software quality (as expressed through the conversations in the podcasts).
Software Engineering Radio: Code reviews
Although software engineering is what you call a technical discipline, the people element is really important. Software engineering processes are as much about people as they are about product. Some software engineering processes apply a process known a code review.
Code reviews
In SE Radio 400: Michaela Greiler on Code Reviews a code review is described as ‘a process where a peer offers feedback about software code that has been created’ (1:11). Greiler goes on to say that whilst testing can check the functionality of software, code reviews can help to understand ‘other characteristics of software code’, such as its readability and maintainability (2:00). The notion of these other characteristics relates to the notion of software quality, which is the subject of the next blog. Significantly, code reviews can facilitate the sharing of knowledge between peers. Since software is invisible, it is helpful to talk about it. Valuable feedback is described as feedback that leads of change.
Greiler’s podcast suggests that reviews can be carried out in different ways (8:00). They can be formal, or informal. Code can be emailed, or code could be ‘pulled’ from source code repositories. Feedback could be shared by having a chat, or should be mediated through a tool. The exact extent and nature of a review will be dictated by the characteristics of the software. The notion of risk plays a role in shaping the processes.
One of the parts of this podcast I really liked was the bit that emphasised the importance of people skills in software engineering. Tips were shared on giving (and receiving) feedback (19:20). I noted that a reviewer should aim add value, and the engineer’s whose code is being reviewed should try to be humble and open minded. A practical tip was to give engineers a ‘heads up’ about what is going to happen, since it gives them a bit of to prepare and be explicit about the goals of a review. The podcast also emphasised a blog post by Greiler that had the title: 10 Tips for Code Review feedback.
Towards the end, there was a comment that code reviews are not typically taught in universities (34:25). I certainly don’t remember being involved in one when I was an undergraduate. In retrospect, I do feel as if it would have been helpful.
A final question was ‘how do you get better at code reviews?’ The answer was simple: show what happens during a review, and practice doing them.
Reflections
When I was a software engineer, I spent quite a bit of time reading through existing code. Although I was able to eventually figure out how everything worked, and why lines of code and functions were written, what would have really been useful was the opportunity to have a chat with the original developer. This only happened once.
Although this conversation wasn’t a code review (I was re-writing the software that he had originally written in a different programming language), I did feel that the opportunity to speak with the original developer was invaluable. I enjoyed the conversation. I gained confidence in what I was doing and understanding, and my colleague liked the fact that I had picked up on a piece of work he had done some years earlier.
I did feel that one of the benefits of having that chat is that we were able to appreciate characteristics of the code that were not immediately visible or apparent, such as decisions made that related to the performance of the software. The next blog is about the sometimes slippery notion of software quality (as expressed through the conversations in the podcasts).