Screencasting Code Reviews is Hard

I’ve been trying to record myself performing code reviews for The MarkUs Project.

It’s a lot harder than I thought it’d be.  The screencasts are really only useful if I’m saying what I’m thinking, and I’m finding it difficult to maintain stream of consciousness and perform an effective/thorough review.  The last few times I’ve tried it, I find myself blurting an expletive, stopping the recording in frustration, and then starting the review over so that I can do a good, proper job.

I think this is going to take more practice.

4 thoughts on “Screencasting Code Reviews is Hard

  1. Mike


    Ha! I’d seen that posted up in the sweatshop – I have to agree. 😉

    I may have represented myself in this post though – when I give up in frustration, it’s not because I’m swearing into the mic – but rather because I don’t feel like I’m doing a thorough enough job when I’m talking instead of thinking.

    Thanks for posting!


  2. Jesse Gibbs

    I’d be interested to hear your thoughts on performing code review over screencast as opposed to using an ‘inline commenting’ style that most tools support. My gut feeling is that since people write code rather than speaking it, code review is more easily done via writing than talking.

    If there are benefits to audio/video format for reviews, perhaps as a complement to inline commenting, I’m very interested to hear them!

  3. Andrew Smith

    This reminds me of a podcast I listened to recently (can’t remember which one). Something about recording solutions to math problems.

    The point was that making it perfect is a bad thing. The point is to show the viewers how one arrives at a solution. That includes mistakes, dead ends, stumbling, etc.

Comments are closed.