London .NET User Group - April 2025 Meetup
- erinvh620
- Apr 23
- 5 min read
Updated: 2 days ago
TL;DR Here are the slides and transcript for a talk I gave at a Meetup event.
Last night, I presented the second iteration of my talk "Code Review: The Missing Manual" at the April meetup of the London .NET User Group. LDNUG is a well-established and well-organized meetup that I very highly recommend (even if you are not a .NET developer). Sessions generally feature two talks: a more technical talk (often .NET specific, but not always) and a tech-stack agnostic talk. I have attended three of their meetups so far, and I'm loving them!
A friend and co-worker recommended this meetup to me when I told her that I was looking to do talks about code review. She introduced me to the organizer, Dylan Beattie, over email and I asked him if I could do a talk at a future meetup. That's how I managed to get a spot at their April session. If you are interested in giving a talk at one of their meetups, get in touch with Dylan! You can find him on LinkedIn.
As is my habit, to ensure attendees could fully engage in the moment, I promised to make my slides and a full transcript of my talk available online. That way, no one had to worry about scrambling to take notes—though anyone was, of course, welcome to snap photos of the slides if they wanted to.
If you'd like me to give this talk at a Meetup you organise or attend, at your office, or remotely over Zoom, feel free to reach out to me at erin@thepassionatecoder.com! I'm happy to travel anywhere in London (maybe even further!) to discuss how we can make code reviews a smoother, more productive experience—without the unnecessary friction, antagonism, or misery that too often comes with them.
Slides
Here are the slides as promised, available in three formats—each complete with speaker notes that serve as a transcript:
Keynote: This file includes all the speaker notes.
PDF: If Keynote isn’t your preferred format, here’s a PDF version with the same speaker notes.
PowerPoint: Finally, here’s the PowerPoint version. Please note that I haven’t verified its quality, as I don’t have PowerPoint installed.
Feel free to use these slides and speaker notes for your own talks—whether at your organisation or another Meetup. The goal is to improve the software industry by getting software developers, team leads, and other tech leadership talking about code review. I only ask that you credit me for the ideas and effort behind them, and please do share any questions or feedback you receive!
Q&A
Here is a record of the discussion that followed my presentation. This is not an exact transcript, as I've edited for better readability and for more helpful answers than I gave in real-time! Thank you to those who went to the pub afterwards and helped me find better answers to some of these questions!!!
Question What support tooling do you recommend? What kind of metrics do you recommend? And do you have any recommendations for handling temporary environments for testing?
Answer
I am aware that I haven't touched on any automation in this talk, but I want to be clear that I am a huge fan of automation. Any part of your process that can be automated should be. This is GREAT for reducing friction between colleagues (and it's really important to not waste people's goodwill towards each other because we all have a limited amount!).
As for supporting tools, I think that in general, what you want is a CI pipeline that builds and runs your code, as well as scans it, before any human reviewer gets involved. Here are some things that pipeline could do:
build the code
run the code
build and run any sample apps that are used to aid in development
It's important not to break these! Breaking them blocks other developers
build the tests
run the tests
run a linter and surface warnings and errors (your team would of course have had to agree to a style guide before putting a linter in place)
run a code coverage tool and output a percentage
in this case, maybe there is a minimum percentage that you want your code coverage number to stay over?
or maybe you want to see the code coverage percentage before and after your changes and simply surface those numbers so a human can decide if they are reasonable??
run static analyzers
run a tool that calculates cyclomatic complexity
if this is code for a user-facing application that is available in multiple languages, you can run a check to make sure no translations are missing
performance tests
maybe you want to see how much memory certain "user flows" take
or see how quickly the application starts up, and keep startup time under a certain maximum
security checks
I am planning to write a more in-depth blogpost on this topic in the future.
As for temporary environments, I wish I had a good answer for you but I don't. I'm way out of my depth on that topic, as I've spent my entire career as an iOS developer, and don't know the first thing about Terraform! I will try and hunt down someone to answer this one.
Question Can you explain the term "happy paths"? It seems like something that is only valid when there is a user interface. . .
Answer Yes! When I used that term earlier, I realised it was a bit of industry jargon, so let me explain what I mean. "Happy path" refers to a scenario where all inputs are valid and everything works as expected (as opposed to testing for edge cases or failure scenarios).
Now, as for whether happy path testing only applies when your application has a UI: When your application has a graphical user interface (as with mobile apps, desktop apps, or websites), the happy path can feel very obvious. However, this concept also applies to command-line tools or other applications that don’t have visual output.
For command-line tools, the output can be used to verify the happy path. For back-end code, you can check the happy path by looking at logs, metrics, or other observability output, depending on the situation.
Ultimately, testing the happy path does not require a UI, although a UI can make testing easier in many cases. In some situations, it might even make sense to create a simple UI just for testing your back-end code.
Question
What is the purpose of code review? How about knowledge-sharing? And do you believe there are any scenarios where code review is not needed?
Answer
Coming soon
Comments