Making software is hard. Every once in a while we find some code that really helps the process. It makes our own code intelligible: almost fun! Sometimes the magical code is of our own making but often we are using someone else’s code. In either case the next step should be to share the joy.

My preferred mechanism to share the joy is through videos. Videos are a powerful way of humanizing the types of problems software solves. With video, you can get in the thick of it code-wise while still adding a literal face. You can see the excitement, the technology, and most importantly: the code.

Recently I penned the following:

I've noticed some frustration about visibility with .NET OSS - I *want* to feature your work on @ch9!! Tell me about your project!

— Seth Juarez (@sethjuarez) January 28, 2016

The response was overwhelming! As an effort to pay off the request and promise I am looking for your help! As part of what we are doing at //BUILD this year I wanted to run 5 minute featurettes on .NET OSS projects. I am happy to work with whomever sends a request. As a way to maximize our collective productivity I thought I would write a general outline of what I think is a great technical video.  Now the obligatory disclaimer: these are my opinions. You may have a completely different idea of what the contents of a great technical video should be – that is great! In my experience however, there are certain elements of a technical presentation that I’ve found to be successful and wish to share.

The Outline

As in all things in technology I was forced by the Internet Elders to create an acronym in order to solidify these four elements. PSEC is born.

• Problem
• Solution
• Example
• Conclusion

The Problem

This is the part of the video where we say something like “don’t you hate how we always have to ____ when we write software?” “Remember the time that ______ happened when you deployed the first time?” “How often have you run into _____ the last time you ______?” Essentially we want to inflict pain upon the psyche of our listeners by reminding them of the sheer difficulty of accomplishing an important development task. This pain is not created by you of course, it is simply inherent because the forces of the universe have conspired to make this particular task, well, simply painful. Not to worry though, we get to be the heroes in the next section.

The Solution

In this part of the video we describe how we actually have taken the universe on and altered the cosmic forces to alleviate the pain it wishes to inflict upon unsuspecting programmers. This bit needs to be concise and to the point. A rambling description of the solution will only serve to have Sue dev to think she’s being conned. We are naturally skeptical people so this should be to the point. The conciseness and consistency of the solution (as you describe it) should elicit some skepticism. Enough to get people to want to watch the section that comes next.

The Example

This is where we pay off how we described the solution. This is where the rubber meets the road. <Insert another cool saying here that says do something here in flowery tones with poetic gusto>. Devs want to see something working. They want to be able to say: “wow, I should be using this to solve the problem they described.” If during your demo you’ve found some difficulty, then this tells you more about whether or not your solution is ready for prime-time. If the example does not really speak to the problem or work as you describe in the solution section, then you should see red flags. Time to rethink the previous sections and/or make the example better.

The Conclusion

Now to add the nice bow at the end. To summarize: restate the problem, the solution, and the example in short form. Also add the phrase “to learn more please visit ________” – or something to that effect. This marketing people use the term “call to action.” The reason you’re making the video is because you want someone to do something. Ask them to do it in the conclusion of the video.

A Caution

The principles I’ve outlined are just a set of guidelines that should help inform the content of whatever technical video you make. Just like all great artists, principles are used as a foundation to unleash creative genius: go and do likewise.

Those Who Have Reached Out

You may already have an awesome video (send me a link!) To those on my list (see below) who have reached out (and don't have a video) I make the following plea: please make a 5-minute video and send it to me. I will review it and give you suggestions and/or comments. I am obviously not the arbiter of what good content is or isn’t – I am happy to give feedback but I will put whatever you want up as long as it is not in bad taste. I am not the tone police either – just pretend that my kids will be watching the videos and I’m sensitive to certain kinds of content.

The List

This is my (likely incomplete) list of everyone who has reached out. I tried to add links where I could find them. I am happy to make amendments where required.

• Event Store
• NancyFX
• FluentMapper
• MaterialDesignInXamlToolkit
• OSVR
• Pyjion
• Odin
• libgit2/LibGitSharp
• azure.security
• azure.storage
• Wyamio
• Cake
• Paket
• FAKE
• WebApiProxy
• Pomona
• GitReleaseManager
• AutoFixture
• GitVersion
• Serilog
• ReactiveUI
• SharpPcap/Packet.net
• Chocolatey
• CodedUIFluentExtensions
• Duality
• wixtoolset
• StyleCopAnalyzers
• OrigoDB
• Dryloc
• Spreads
• MockHttpServer
• LongPath
• StuntMan
• Fixie
• Polly
• Sandcastle
• TSqlFlex
• ImageProcessor
• NetMQ
• GitTools
• FluentAssertions
• Cosmos
• Rocks
• Immutable.net
• BugNET
• Exceptionless
• Elasticsearch
• Beehive
• PerfIt
• AllReady
• FluentRibbon
• ControlzEx
• xBehave.net
• CSLA

Looking forward to watching some awesome content! If you're wondering about how to get started with video, there's an awesome perk if you're an MVP with Techsmith - the fine makers of Camtasia that you should definitely look into.