For each project as it comes along, we are required to make a video explaining the functions of our project and showcasing all the details that we spent days putting into our project. The value from a user perspective is clear: It shows me how to use your product! However, the value from a creator perspective is even greater. As a creator, the videoing process does two main things for us: catches bugs and practices our communication.
BUGC4TCH3R.mp4
Joking title aside, videos get you to catch bugs. I cannot remember the number of times I have stopped recording a video because a function did not work as intended. Often, I would say something like, “And if we click on this…Or not.” and close out my recording. I would look into my code to find where the bug was, fix it and start the process over again. Often, I’d run into a second bug and a third. The process would repeat until I finally made it to the end of the video and took a deep breath.
The video process takes you a step back out of your code and back through the functions you wrote out on day one. That quick fix you put in to keep moving along that you said you would “come back to?” Now you have to come back to it and work out the kinks. Additionally, you can see things from a user perspective. Is there feedback? Would I know something happened if I didn’t code it myself? Why was I allowed to delete my account without any prompt? Finally, we get to see things from a regular user perspective.
Additionally, when you are searching through for the fix, you’ll often see how messy your code has gotten and begin cleaning. In this last project, I found that my view had 3 nested if statements that could be boiled down to a helper. Once they were replaced, it was so much easier to see where things were going wrong in my code and I could create the fix.
The Common Language
The second and just as important piece attached to the video process is speaking through your application. As programmers, we can get bogged down in language like “We use an instance method that takes in an argument of a Ruby Object and a boolean…” and can get lost in the technical side. It’s useful to be able to speak like that, don’t get me wrong, however it is just as usefull to be able to say “We call this method to get this result.” Speaking too technically can make people not want to use our program, or not understand what we are saying. Being able to describe your code to somebody that has no coding experience and getting them to relay it back to you in their own words is a crucial coder skill.
Watching back your video, make sure you listen out for moments where you think to yourself, “Man, what does that even mean?” and try to think about how somebody without experience might perceive that. The coders themselves will be the ones able to dig in to what you mean by looking at your code. Others will walk away with a headache.
If don’t already, make a habit of speaking your code out loud in both fashions. I have a coding rubber duck that I speak to when I’m working out a problem. Being able to look at it and say, “I want to click this button and go to the profile,” and then saying, “So that means I need to set up a button_to with a user_path(@user) and change it’s method to get,” is valuable!
Conclusion
Basically, what I’m trying to say is to make sure you get the most out of your videos. Many of us are catching things along the way in terms of bugs, but that’s the easy part of the video (perhaps the most frustrating, but the easiest nonetheless). Focus in on the language you use as you speak through the video. Make sure it’s equally technical and approachable.