As we close out the new year, some of you may be starting a new programming course of one kind or another - in college, a university, or one that you found online. It is always exciting and somewhat nerve-racking to start learning something new. Even for me, after eleven years in the industry.

I am leading an online course for Utah Valley University beginning in January of next year and thought I would share a few tips here that I like to share with my students. This particular course I will be teaching is a sophomore-level class, but these tips are ones that we can all stand to be reminded of - veteran and novice alike.

The best programs are rarely the biggest ones

A trap that I’ve fallen into in the past when I was first starting out programming was thinking that the best programs are the ones that had a lot of code in them. A lot of code must mean that the program can do a lot right? Maybe, but probably not. It could also indicate that there is a lot of crap code in it. The best programs are rarely the longest ones.

When beginning a new project, always look for the simplest way to implement it. It can be really easy once you get going to start down a path and just rush forward writing code as fast as you can. However, once you start doing this it can be really tricky to step back and make sure you are still going in the right direction. Always remember to take a step back and review the project requirements again to make sure you are staying focused.

Debug smarter, not harder

I see more and more (even in high-level programming classes) that students are not comfortable with debugging their code. I get it - debugging is never fun. First, you have to admit to yourself that you have made a mistake. That can be hard enough as it is. Worse is that bugs can be incredibly hard to find.

That said, software bugs are unfortunately a part of our lives as developers. We never write them on purpose (hopefully), but we will always need to fix them.

How do you reduce the inevitable time you have to spend debugging something? First - isolate the problem as much as you can. Can you replicate it consistently? Is there a specific combination of things that happen to make the bug manifest, like a certain kind of data, or a certain user action?

Once you have isolated where the bug occurs in the program, find the code that is closest to where it happens, and start from there. I have seen way too many students put breakpoints in their code editors right at the beginning of their programs and then proceed line by line until they encounter the bug. Please don’t do this. Modern IDEs and code editors will let you put a breakpoint just about anywhere you want to. Drop one in the function that is relevant, and start from there - as close to the bug as you can figure.

If you can’t put in breakpoints, then find some other way to log data from your program out to the screen or some equivalent as close to the location of the bug as possible.

Developers tend to joke about putting non-sensical log messages all over the place when trying to track down a bug, but the reason we joke about it is because we’ve all done it. Probably more than once.

Break Problems into smaller components

The ability to decompose problems and programs into small, workable components is probably one of the most useful skills that you can have as a developer. When you can build a project in small pieces at a time, you can drastically reduce the complexity of what you have to think about.

For example, think about implementing a linked list data structure - one of the projects that the students of my Data Structures and Algorithms students do near the beginning of the course. A linked list needs to be able to chain nodes of data together, one after another. If a list is long, it needs to be able to traverse the list to find the end (or use a pointer to the end) to do so. If an element is removed, the structure needs to be able to fill the gap when a node is removed from the middle of the list.

All of these things put together make for a complicated program. So start with something basic. Instead of thinking about how you are going to patch holes when something is removed from the middle of the list, think about how to put data into the list in the first place. Implement that, and only that. Make it bulletproof. Then, once you are happy with that small piece, move on to the next part of the program.

I once had a student that took the “build it all at once” approach, without even trying to run the program until the code was “finished”. They would then spend a huge amount of time debugging and redesigning their code to work. They managed to get the first two projects of the course completed, but when they got to the third one, they came to me on the due date and told me after over 10 hours of working on it, they were completely stuck.

Upon some investigation, I discovered his method of development, which I just explained - write all the code, and debug it until it worked. Long story short, I showed them how to break the programs into smaller pieces and to test that small piece completely before moving on to something else. By doing this, they aced the rest of the projects of the course with time to spare on each of them.

Break projects and problems into small pieces, and work on those individually until they are bulletproof before moving on to the next piece.

Embrace the struggle

Programming is hard. Some days will try and break you. I like to compare programming and software development is like learning to play an instrument. You simply have to put in the time to get good at it.

All the things that boot camps tell you about how you can “master” something in 30 - 90 days are complete garbage. Though it makes a good plug line.

Of course, you can get good at something in that space of time - but you will not master it. I used to teach an introductory web development class at a technical college - an excellent school with a good program. It was a rigorous program and asked a lot from the students, and in the end, they had some good projects as a result and a lot of knowledge.

Would I call any of those students masters of web development?

Not even close. They haven’t put in the time to master it yet. There is just too much to learn. I’ve been writing software for 11 years and I still feel like a novice some days.

Learn to embrace the struggle that is software development. When you get stuck on something - do not try to plow through it. Get up and take a break. Stretch your legs out. Go on a walk. Get away from the computer for at least 10 minutes. When you come back, you’ll be surprised by how fresh your mind feels.

I once had a problem I was debugging for over two hours. After a break for lunch, I sat back down and found and fixed the one-line bug in less than five minutes. Things like that happen more often than you would think.

Remember your “why”

What made you interested in software development in the first place? Do you enjoy the creative process? Is it because you heard how much money there is to potentially be made in software development? Was it just curiosity? These are all perfectly valid reasons in my book.

For me, I’ve always been a bit of a computer nerd, but for most of my young life, I was just interested in the hardware. I liked building computers, installing operating systems, and configuring them to do things. And yes, there was plenty of gaming mixed in there as well.

I had initially intended to go to college and major in Computer Engineering, where I expected I would end up building and designing computer hardware. When I took my first programming class and wrote my first few programs, it was like a whole new world opened up to me. I had been using software all along, but this was the first time I created something like this.

I was hooked.

The rest is history - I’ve been a professional developer for eleven years. It’s not all been paradise, but I can with certainty say that my love of software and the creative process has been what keeps me going on the days when I just want to throw the computer out the window. Because when I fix a major bug or complete a large project, the fulfillment and satisfaction it gives me are hard to describe.

Good luck, have fun

If you’re starting off the new year with a new course or semester, I wish you all the best. Remember to take your time, and don’t rush it. You cannot learn to be a skilled developer any faster than you can master a musical instrument.

Put in the time, and be patient with yourself. You’ll figure it out.