Tag Archives: programming

Learning To Code – Learn, Try, Fail, Repeat Until You Succeed.

Posted on by

I have been programming for longer than many readers of the blog have been alive. Learning new things has always and will always be a large part of what programming actually is. It is one thing to get comfortable with a language, it’s another to fully understand why things are working they way they work and how you can use that to better your code.

I started in the mid 1980 working on an Apple IIe using BASIC. It didn’t take long to learn that BASIC wasn’t considered a great language by any stretch. It had a tendency to create bad programming habits. But, it did solidify many central programming ideas. I fully understood loops, conditional statements, variable, and boolean logic among other topics. I could come up with an idea and build it in code within a short time. It’s great to have “perfect” code, but it’s even better to see your ideas working.

A basic template to succeed in learning: find a project, learn, read, try, fail, learn more, try again, repeat until done.

That’s why for this post I’m really pushing the idea that you find a project that interests you. It can be anything – ideally, not too complicated, but still a challenge. I don’t recommend trying to build a Facebook clone for your first project, but make sure it’s more involved than “Hello World.”

Once you have a project, then start to look into how to implement it. This is where you’ll have to pick devices and languages you plan to use. Sometimes, your initial goal will point you in a certain direction. If so, then follow that lead. If not, that’s okay. Look into your options and find out what will be the best suited for your project and also your future hopes. To rephrase that, don’t learn PASCAL if you hope to write mobile apps. It might be possible in some roundabout way, but it isn’t worth the extra hassle.

Once you have a basic idea for the project and how you plan to implement it, continue to read up on the language and how to use it. Once it begins to make a bit of sense, then start to write some code. Start small. To begin, focus on some aspect of your project that you can make work quickly and without much hassle. For me, this usually becomes obvious as I start to learn a new language or device. I will often learn some aspect of a language or device that will fit with my planned project. I can then use that information in order to make a part of it work. Sometimes, it’s just a part of the interface, other times it is a mathematical or logic part. But, the key is to make it something that you can play with and see the results quickly.

That is an important aspect of learning – seeing the results of your labors as soon as possible. It helps in a couple of ways, you solidify what you are learning, but more importantly you get to see the results of your lessons. Those two things make it easier to go onto the next steps in learning – failure. It is a given that your first attempts will have problems. They might run and kind of do what you want, but it is rare that they work fully right, or give you what you are hoping to have in the end. That’s okay. Failure is the best teacher.

The next key is to take your failure and turn it into a success. You do this by continuing to try. This will involve continuing to education yourself more on the language and the devices you plan to use. It will also involve you learning new things in order to improve your first attempts. You might not written the best program or made the best app, but you will have made something. And as long as you have something, you can improve it.

Just keep learning! Just keep failing. Just keep trying again and again. You can do this.

A quote that I found years ago:

“Make sure that your next project is beyond your skill and requires tools you don’t have. You won’t regret it.”

Groundhog Day – How To Escape From Development Hell.

Posted on by

I’ve talked about not repeating yourself before and just like a certain holiday, I’m going to repeat myself. In the movie GroundHog Day Bill Murray’s character is forced to repeat the same day over and over again. It isn’t until he begins to find a way to improve the day does he finally get to move on. As a viewer, we never know how many times he repeats this day, other than he was locked in this loop for weeks, if not years.

As a developer, it is important to not repeat the same unsuccessful ideas. If something isn’t working instead of just trying little changes with the hope that it will solve the problem, take the time to figure out why the problem is there is the first place. It might be something quick and easy to fix, but it might also be a fundamental problem that will require a more involved solution.

But, the important part is that each step should be bringing you closer to a solution. But, you won’t find that solution until you know what is causing the problem.

This also requires taking the time to know your code and the language that it is written in. Is the problem simply you misunderstanding something? Is the problem your solution being wrong? Is the problem simply a typo or a greater than that should have been a less than? If you understand the problem, then these solutions will likely become obvious. It also helps if your code is well designed and modular. That way you can test smaller parts of the program to see where the actual problem lies.

Yes, I did repeat advice from the past, but when you put the parts together they often lead to a quick solution to whatever problems you might be having.

Don’t Repeat Yourself. A Life Changing Obvious Idea In Programming.

Posted on by

In many ways, the idea seems simple, but it is easy to forget. When you are writing a program repeating code happens quite often. Sometimes it happens in various sections of your program so it isn’t always quick to recognize. Other times, we are just in a rush to get something done without thinking it through so code gets cut and pasted several times with few if any changes.

While, we have all made those mistakes, it makes your life easier to step back and find a way to fix it. Often, the fix involves pulling out a chunk of code and turning it into a function or a method. Other times, it involves rethinking why you are doing things the way you are doing them. Still other times, finding better ways to use the language will solve the problem.

A common fix in Swift is to replace a collection of if statements with a case statement. That doesn’t solve all of the issues, but it helps out more often than you’d think. As I am writing this, I can think of several areas in my own code that would be helped by this piece of advice alone.

If you can avoid the repetition, it will make your code more readable. But, beyond that, it will also make your code easier to update. It is far easier to change one function than to track down all the areas that you might have used the same code in order to make a simple change. Just think of how many potential bugs could be introduced by missing one or two areas.

Another way to avoid repetition is to set up constants for values that get used throughout your program. This allows you to change values in many places by only setting one variable. I use this many times with various values such as a scale modifier, or animation constants. It allows you to stay more consistent through the code, while also allowing you to make quick changes. If the value is limited in scope, then try to define it in that scope if at all possible. Also, make sure that you use variable names that are descriptive and make sense. It’s far easier to figure out why you used spriteScaler than a number 4.5 when you are reading the code.

So, take a few minutes to look through some of your code to find areas that you repeated yourself and take the time to fix that issue. You will thank yourself in the future.