Turning Personal Programming Dreams Into a Reality

by Dakota Larson

It happens. You start a programming project, filled with dreams of its completion. You can picture the interface you will design, the exciting complexity of the logic in your code, how it will benefit you, and how great it will be to use.

Then, a short while, maybe a month, a couple weeks, or worse just a few days later, you no longer have the ambition to keep working. This dream that you thought was going to be so easy to attain suddenly feels like it’s slipping through your fingers. Shortly thereafter, all progress comes to a standstill. You are no longer creating content, you stop writing code, then, the project fades away, buried with all the other files on your computer.

How did this happen? Why the sudden change? Believe it or not, there are reasons why this happens, and most importantly, there are ways to get around them; to give yourself the best chance to make the projects you dream of come to life!

Hi, my name is Dakota Larson, and I am the Software Engineering Intern here at Sundog for the Summer of 2017. Being a Software Engineer here means that I work with code. Lots of code. And yes, I have run across the same problem detailed above. For me, personal projects are truly as good as it gets. They are a place where I can truly make the magic happen. I can create completely custom programs of any complexity, and design them exactly how I want. I can choose the layout, how data is input, and what exactly the program does with the data. With this power comes a large amount of responsibility. And when this responsibility is mishandled or misunderstood, problems arise, very quickly.

One of the biggest sources of the problem (and unsurprisingly, the focus of this article) is design. Are you designing anything at all? If you aren’t then this is likely the source of your problem. Think about it. Once you start coding, your mind is going to be focused almost entirely on what you are writing, not the design of what you are creating. Therefore, if you don’t have a design to follow, then you are going to create one on the fly. This gets messy, a lot quicker than you would think. Your code will become untidy, your logic won’t follow a set pattern, and your head will soon begin to swim trying to follow everything you are doing. Worse yet, what happens when something inevitably goes wrong? Every programmer makes mistakes, and debugging code is challenging enough as it is, even with compact, well-designed code. Don’t make your life more difficult by having to debug a figurative disaster. I am speaking from personal experience there.

Now when I say “design”, what am I really referring to? By itself, this sounds quite ambiguous. Unfortunately, there is no best answer. Use a strategy that works for you. If you don’t know what that is, experiment! If you are creating a web application, design the front page. If you are creating a game, then start by designing the first level you will play in. Next, choose your tool. Pencil and paper is probably the easiest tool to use, however, there are digital tools as well. If Microsoft Paint isn’t to your liking, then do a quick search online. There is sure to be a solution out there that will work for you.

Once you have your tool selected, make a very high-level design, with as little detail as possible. Make it so you can identify what the major components of your project are without any detail about what is contained in them.  Do you like the design? Is this something you can use? Is this something you can create? If you answer no, then make changes. It is easy to erase on paper (or whatever tool you have chosen). Having to delete and alter code (even if it is simple HTML) is far more challenging. Once you are pleased with your design implement it, and nothing more. Yes, it is easy to start adding some logic to make what you created have some character. DON’T! It comes later. Now ask yourself again, is this something I like and can use? If you aren’t happy, then revise the design outside of the application first with your design tools. Once that is done, then make the changes to your code. Once you are pleased with how it worked out in code, then proceed to add some additional complexity to your design. Add additional components to your design, or if there are none to add, then start implementing some of the logic at a very high level. Repeat this process continuously until you feel satisfied that your work is “complete”.

There is no single way to go through this process. Programmers who are more capable logically may implement larger amounts of code in each iteration. On the flip side, those who are more artistic may implement more visual details in each pass through. It is all about finding the balance. What is challenging enough so that you aren’t bored with these iterative steps, yet easy enough so that you don’t get lost when trying to implement your design in code.

One of the best effects of this system is that you will be able to see soon into development whether the project has true potential. Do I have the passion, time, and skills required to complete this? If the answer is unfortunately no, and you have already tried rethinking your design, then you may have to step away from the project. It doesn’t mean that you can’t ever work on it again (perhaps when you have more time, greater ambition, or a larger skillset), but if you choose not to, at least you know why it didn’t work out.

In the end, I invite you to try this system and see how it works for you. Personal projects are where you can truly be yourself, and let your creativity roam. If you love the thought of being able to code your own projects, but have been having trouble seeing them to completion, then try giving your design a little more attention. A little more work now may pay off well in the end.

-Dakota Larson

Sundog Software Engineering Intern (Summer 2017)