A while back, we wrote a Python software sketch that implements a GUI for inspecting GStreamer plugins and features. Let’s revisit the code, and clean it up! Looky here:
There are many ways to develop software. One interesting thing that I notice is that once many people learn to program, they don’t “practice” programming any more. Not surprising, as many people code in their jobs and don’t feel the need to take on additional work.
I have found over the years that taking part in “recreational” programming helps me better understand different, sometimes new, concepts that are being introduced in to computer science. Once you are a senior software engineer on up, you realize that you are not being paid to code, but to have meetings, manage people, answer emails and write design documents. Adding recreational programming to the mix helps get a better handle on new technology as it is being introduced.
What is recreational programming? It is small project or snippet(s) of code that you write. There should be a very specific purpose, or have investigation value. You can think about it as a study, or a sketch. The intent is to learn, throw it away, and take what you have learned and apply it to your next sketch or project. This frees you from being ‘married’ to the code, and encourages you to experiment.
This is the same way many artists work when they draw or play music. Athletes too. You tend to only see finished work, you rarely see the process that gets to that work. If you don’t believe me, watch the 8.5 hours of the Beatles ‘Let it Be’ film. Watch how many times they run through each song and change them.
When you’re on take 47 of a 3 minute piece, that’s work! The people who made the film? They had more than 55 hours of never before seen footage and 150 hours of audio to piece together. The original ‘Let It Be’ documentary cut down the footage to 80 minutes.
Typically people don’t sit down and create finished pieces. Instead they gather up bits and pieces, crafting and editing them together. You have to be a little ruthless at times, and throw away some very good parts to better serve the ‘story’. Editing be difficult!
Typically I plan on 1-4 hour projects, though a day or three may be a useful range too. When you first start out, you may not know have enough time estimating skills to predict how long any given task may take. You can use this technique to help hone your time estimating skills.
Block out an appropriate mount of time in your schedule, and turn off your phone, no email, web browsing and so forth. You are concentrating on one task, coding! You can web browse for documentation and so forth, but be cognizant to do only that.
Write down a task list on a pad of paper. The first task is defining the task list. Estimate how long you think that should take.
Next, write down the tasks that you will undertake. Whether that’s to refactor some code, write new routines, introduce new ideas or programming constructs. Write down how long you think each task will take you.
Once you are down writing the task list, compare the amount of time with your estimate you began the list with. Close or not? Cross task one off the list.
Now you are ready to start programming, or researching if that’s one of your tasks. Time each task, and as you complete them cross them off the list and compare the estimated versus actual time. As you get more experience, you should be able to estimate how long any given task may take and some of the variables to take into account. This is a valuable skill, as it is always one of the first questions asked about any project.
In general, you should always know how much work you can do in an hour. It’s important to be only doing the work at hand in a concentrated manner. Get in the zone!
In the video, we revisit a sketch that I wrote a month or so previously. Of course, you will want to revisit such things much sooner so you don’t have to ‘relearn’ the code that you wrote. I have found that this is good practice when working with programming languages or frameworks which I am not all that familiar. Do a little bit of study, go back and clean up.
For most of the code studies I do, I tend to write ‘pseudo code’ which tends not to take into account specific language features. By revisiting the code, I can add some of the niceties that a given language can provide. Tools play a part in this, for example you notice in the video I lean quite heavily on the Visual Studio Code refactoring facilities.
It Ain’t About Me
But this isn’t about me coding, but rather sharing a technique that you may find useful. Over the years, I have found it very helpful.
A Little Bit More
To be honest, this video is also testing a new technique in recording these tutorial videos. With the proceeds of the JetsonHacks videos, I acquired a BlackMagic Design ATEM Mini Pro recording to a Samsung SSD. Thank you for watching the videos! As time goes on, I can start adding in some more of the advanced features that this kind of workflow provides.
The video was recorded directly from the HDMI out of a NVIDIA Jetson Xavier NX Developer Kit, with an Aspen Mics Lavalier Microphone. The Jetson is running JetPack 4.6, L4T 32.6.1.