As a software engineer, I have found that I must continue to learn new tools and techniques to stay relevant (and engaged) in my field. I’ve had more than my share of dry periods where work seemed boring, until I was brought a challenge… something that I had no idea how to handle, which forced me to learn new methodologies to accomplish the task. These periods of sink-or-swim, grow-or-fall-behind (sometimes lasting months) are undeniably the most exciting periods of my career to date.

A colleague of mine over at docix.net recently published a blog post on the methods he uses to continue his self-education in his field of game development. He coined the term “Process Prototyping“, which he explains as the process by which you create the prototype.

For many software engineers, the term prototyping usually means something completely different, so let me add a little clarity. The term ‘prototyping’ in this case does NOT refer to the Object-Oriented principle of prototyping, but rather comes from more of an engineering background. That is to say that prototyping does not mean a process of “cloning existing objects that serve as prototypes“, but rather the first workable iteration of a final product. The term “Process Prototyping” then refers to the process which a creator uses to get to his first prototype.

Now, I know this doesn’t yet sound like a learning tool. It sounds like the creation of version 0.1 alpha of your new software package. But within the bounds of “Process Prototyping”, whether or not a final product is ever created is irrelevant. The process is the point.

That’s where Process Prototyping comes in.

As it was explained to me, the idea is to focus on how you get to your initial prototype, and repeating that process over and again. If your paying gigs aren’t challenging you, it’s up to you to challenge yourself. Find something–anything–that looks like a cool project, then recreate it on your own. The theory can be applied to design, development, art, strategy, what have you. Rebuild it yourself. The goal is not necessarily to have a perfect copy, but to understand the thought processes of the original creator, or to create your own thought processes to reach the same (or similar) goal(s). Learn from this, and integrate anything you glean to your updated toolbox… your unique skill-set.

Whereas I know many software engineers who learn very well by reading books and following tutorials, this isn’t always the case for everyone. I find that I learn best by DOING, which means that I require a challenge. If you tell me something in a book, I’ll think, “that’s great, how nice of you to explain that,” but until I can visualize it in real-world terms, and see what it adds to a project, it won’t really become a part of my process.

So, when you’re sitting at home wondering how to improve at your craft, consider somebody else’s work; not to be a copy-cat, but to learn. The difference between being good at your craft and being great at it is the ability to continue pushing your own boundaries, and therefore (hopefully) staying relevant in your field. Staying engaged and excited about what you love is just an added bonus.