Visual Studio Toolbox

Code Reviews and Presentations with Visual Studio, Part 2

Last time we looked at presentation tools that you can use to show off your work to an audience or to a team. This time, we look at tools that might be more suitable for use in code review. I also share some of my experiences using these tools.

• By Terrence Dorsey
• 04/19/2017

Last time, I covered a number tools for sharing your coding experiences. Being able to present code to a team or even to audience, such as at a user group meeting, isn't often as simple as it sounds, but the tools I covered last time can help streamline the process. 

Code Reviews
This is a bit of a stretch, but code reviews might be another area where presenting may be relevant, though most teams I've worked on do one-on-one code reviews with either a direct peer or senior developer. Still, there are some tools that help smooth the process.

If you're not already doing code reviews -- and even if you are, but want to fine-tune your review process -- take a look at Microsoft's "Guidelines for Conducting Design and Code Reviews" and "Best Practices: Code Reviews." These articles contain some great tips.

Devart's "Review Assistant" code review extension for Visual Studio allows you to generate code review requests or respond to requests directly in the Visual Studio editor. Post-commit review flags, comments, and discussions happen right in the editor, and Review Assistant allows for multiple comment-fix-verify cycles. The tool supports Team Foundation Server (TFS), Subversion, Git, Mercurial and Perforce source code repositories. Devart offers a 30-day trial for unlimited users and projects, and a free version restricted up to three users and one project. Yearly license subscription programs are available.

ConQAT Peer Review is a simple Visual Studio extension that provides colored review state status for CQSE's ConQAT software quality analysis toolkit.

Likewise, the Code Dx VS Extension provides direct Visual Studio integration with the Code Dx Software Vulnerability Correlation and Management System, enabling quick and efficient code security and quality checks.

All three of these tools provide reporting capabilities that you could further incorporate into team presentations, and I definitely think regular discussions about code standards quality should be a part of every team's best practices, but I think I've strayed a bit from the original point here.

Presenting Done Right
To finish up this series, I want to include a few comments and resources on how to choose and prepare a topic, and some tips for effective public speaking.

First, take a look at two of my old blog posts, "Writing About Code: Getting Started," and, "Writing About Code: Structure." While not directly related to presenting, I think they cover the concepts of topic and audience relevance fairly succinctly.

Next, and far better, is Lara Hogan's excellent recent writing and, er ... presentation, "On Giving Presentations." Hogan is an author and an engineering director at Etsy. Definitely check out her book, "Demystifying Public Speaking," published by A Book Apart. Or just watch her talk, "Demystifying Public Speaking," on YouTube.

Any Tools for Stage Fright?
Finally, some words of advice from my own experience as a presenter.

A little anxiety is to be expected when you're preparing to stand up in front of a group of peers and talk like you're some sort of expert. I've presented many times and still get near-crippling anxiety right up to the point when I stand up and start talking. Don't worry, you'll be fine -- nobody else knows. Be prepared. Stand up. Start talking. From that point on I'm always just fine.

Tuning your presentation to your audience is really the key point, I've found. When talking to peers, I generally know their familiarity with the project and associated technology, so have a good idea which bits to gloss over and which need more explanation. When presenting up the management chain or to other groups that don't know my team's work in detail, I tend to ease up on the technical detail and focus instead on organizational or business context. In other words, I want to tailor the details of my presentation to what my audience knows and what is of specific interest.

A few years ago, I gave a conference presentation on the topic of the "Writing About Code" articles that I linked earlier (in fact, those articles sum up much of my presentation). I focused my presentation on experiences common to most developers and inexperienced writers, and I think the presentation was well received.

More recently I gave a different presentation to roughly the same audience, but this time on some technical details of a publishing system I'd been using for API documentation. This time, while my end of the presentation went as planned, it clearly bombed with the audience. So what happened?

First, I didn't freak out. It was too late to change course too wildly during the presentation, so I carried on as planned. I tried to stay cool, and definitely turned up my radar as to what points seemed to land with the audience and what was clearly not working at all. Once I realized the presentation was not being received as planned, I quickly decided to turn it into a learning experience.

Second, this particular talk failed primarily, I think, because the subject matter was in fact far more complicated than I realized. In retrospect, it was complicated when I spent six months figuring it out in the first place, and only seemed "simple" in hindsight. My audience was excited to learn my "simple" publishing tricks ... until they became bewildered by the actual complexity. That was 100 percent my mistake and I learned a lot from it.

Was I disappointed? Yes. Will I tackle the subject again, in a different format? Definitely.