Comprehension Is Key

Coding is a lot like building a box or working some other piece of furniture

We can all envision six sides of wood and the nails that hold them together, but so long as we're not actually working the wood ourselves, we can miss out on so many crucial details.
Do we miter our edges so that angled cuts of each side can meet more neatly? Will we glue all walls but the box's opening in order to provide more stability? Should we go with the dark stain or something lighter?
But before then even: Is it more important that the box be cheap, or strong? Are we making one, or many? How many materials do we need? Do we have all the equipment?

Details are important because while some of them won't hold you back (like the color of the stain), others certainly will (do we have enough wood?) and it's crucial that we suss out which details are which.

This is where understanding can be the biggest struggle for new programmers like myself. To date, I have completed roughly a dozen tutorials on Unity and C#, Unreal Engine 4, programming in C++, Java, HTML and a couple others I've forgotten. And yet it wasn't until just the other day that I worked through a tutorial that I actually remembered.

Jason Weimann, who has credentials longer than my name, produced this tutorial early this year, taking new programmers through a series of steps toward understanding not just C# and Unity, but programming and game design in general.

Whereas before I had barely understood what tutorials were showing me, Jason's video left me grinning at every turn because for the first time I was comprehending the code I was writing.

Unity as an engine is relatively easy to understand. There is a GUI that your eyes can relate to myriad other things if you have ever touched a computer before, and it's far easier to connect the various inputs and outputs (when I turn this off, that happens). The coding aspect is different, it's abstracted from the actual game you're creating, and runs in the background.
I found myself pouring over my own code just to read it again, high on the fact that I was comprehending what I was reading. I could take liberties with my own code because I was understanding enough to piece it all together.

Others have shaken their heads at the idea of a "Eureka!" moment, and while I want to eschew this as a universal experience for new coders, I must confess it certainly felt like one to me.

So why did it finally click?

What factors came together to help promote my comprehension of written code? I have struggled even with graphical coding interfaces like PS4's Dreams (an astounding program if you own a PS4 you owe it to yourself to buy this software), because wrapping my head around the coding mentality was a struggle itself.

Now, I'm still no expert. Thinking to code for me has come to mean being able to "think beneath the reality in which I live." Running and jumping are no longer as black and white as they once were. Now they are forward movement and balance and gravity and force. Because with coding in games we are crafting the reality by which the player will live their experience, we have to understand what the builder's mentality is.

And to this, I credit several things. First and foremost, Jason's tutorials are informative in a way that few others have been. He knows what new coders do not know, and he remembers what it was like to be a new coder himself. He did not forget the questions and confusions he endured when he first got started. As a result, he knows exactly what pace a lot of us think and move at starting off.

Secondarily, I credit my own father. He was a carpenter when I was a kid, and taught me a lot about woodworking that a lot of people simply don't know or understand these days. Learning to transplant that knowledge and experience over to coding helped a lot when I was looking at Jason's guidance.

Thirdly, I have to credit myself. When I was trying to learn to make games before, over the passed few years, it was always with a stark lack of conviction. I was still dealing with nursing school, trying to make something of my Guard career (my active duty years were not the most productive), raising children, and struggling to be the husband my wife needed me to be.

Where This Leaves Me

Now, I am in a much better place. I am a working professional, I'm no longer making my military career a needless priority**, and my children are growing up before my very eyes and I know them well. I still struggle in my relationships, as do we all, but I am in a place where I can make design the passion of my daily life, and so when I sit down to learn something, I'm not doing it because I managed to find an hour here and there and want to distract myself from the rest of it all. I'm doing it because I'm wanting to thrive in my own passions.

The Game I Made

It's an Angry Bird clone. Very simple, very unpolished, but I can explore the code and the structure behind the game and understand every bit of it. I even found myself figuring out work-arounds to certain issues before needing to look for help, and while these work-arounds sometimes caused more problems than they solved, I learned something else sorting them out.

And most important of all...I understood what I was learning.

**Quick note: My active duty career only lasted roughly 4 years, as I was more than ready to get out by the time I returned from Afghanistan in 2012. I eventually regretted rushing myself out of the service, and the leadership I had in the Guard in Washington had inspired a desire in me to do something more prestigious with the military. As a result, I spent several years focusing on trying to make the most of my Guard career, which led me to ignore or sideline this part of myself that was begging me to make games.