Don’t code today what you can’t debug tomorrow.

Programming, How To

Posted: January 11th, 2011 | Author: | Filed under: Tutorials | 5 Comments »
Problems in Programming

Problems in Programming

Good programmers, especially game programmers have this mystique about them.  They seem to be able to juggle ginormous amounts of machine gibberish and cobble it into an application or game that does all sorts of wonderful things, almost as if it has a life of its own. People think that they must be really really smart, and for the most part, they let them think that. Hey, if you can’t be handsome or muscular, at least you can be clever, right?

What they told us

Most courses introduce programming as a set of instructions that the machine follows. “Look, the computer looks for this keyword called ‘main’, then it does whatever you put in between the brackets.” And thus they are introduced to the wonder that is… “Hello World!” Hey look! you can make a couple of words appear on screen, therefore you are making progress! Wonderful! After that, they are introduced to constructs like branches and loops, maybe even functions and classes. The programs the student writes becomes more complex until they get stuck.

“Yeah, I get how these programming constructs work, but how do I put them together to make the program do what I want?” At this stage, they get taught UML. Yeah, this is what we call software engineering, where we plan out how the program will work by drawing pretty pictures! This gives rise to two new problems. First, how the hell do you know if your pretty picture is correct, given that you could draw it any number of ways and still be a somewhat decent representation? And after that, how do you translate it into actual usable code?

This is when they get introduced to design patterns. Hey look! These are like standard answers thought up by some four very smart people? How do we know there are only four people? They are called the Gang of Four, duh! Come see their voluminous tome of knowledge! For each problem that you are trying to solve, find the pattern that fits and plug it in. Hey presto! We end up with a group of programmers who think that programming is really really hard, cobbling programs together out of disparate pieces of other peoples’ code and tweaking the variables, hoping that everything will magically come together.

Take a deep breath…

and forget all that for now. Let’s go back to the basics. What is a programming language? This is the medium through which you direct the computer to do what you want. Plain and simple. It comprises of two parts, the “Programming” and the “Language”. Let’s go through the easiest part first.


Language is exactly what it sounds like. It’s just a different way of speaking/writing. It still does the same thing, which is conveying information from one party to another. There is no difference between a programming language and a normal language like Japanese or English, except that it is much much easier to learn. Why is it easier to learn? The vocabulary many times smaller than a traditional language. For example, if you want to understand C, all you need to understand are less than a hundred words. Compare that to the 171,476 (as listed in Oxford) words in common use for the English language.

If you want to learn Java, all you have to figure out is what words correspond to what you are used to using in C, and voila, you are a Java programmer! In fact the only time you find real major differences is when they don’t support certain features. These however are easy to categorise.

  1. Is it a generic programming language? That means you can use all the good stuff like templates to get around data types. (e.g. C++, Java)
  2. Is it an object-oriented programming language? That means you can use classes and objects. (e.g. Python)
  3. Is it a procedural language? That means you can use functions. (e.g. C)
  4. If it is none of the above, you are probably coding in assembly and have to conceptualize all those nice features by your onesome.

Whatever the case, the art of using a language is merely translating from your native tongue (which I presume is English since you are reading this), into the programming language of your choice. What’s that stuff that was in your native tongue that you have to translate? Why, that is the instructions you wanted to give the computer to tell it what to do, and this stems from the next big part… the “Programming” part.


Now that you know how to express yourself properly, you now need to tell the computer how to do stuff. Unfortunately, in spite of decades of technological progress that boasts of multi-core processors and terabytes of memory, computers are still as dumb as a brick. You need to explicitly tell them what to do each and every single step of the way. Unfortunately, due to our poor conditioning thanks to our exposure to ambiguous languages like English, most people struggle in drilling down to the absolute steps that are necessary to accomplish the task. It is, however, not a complicated process.

It starts of with a problem. (If you didn’t have a problem to solve, why are you writing a program? For fun? Blasphemy!). You take this problem, and you break it down into the steps you need to solve it. Each step then in itself, poses a problem. So you take all of those, and break those down, until the instructions become atomic enough for the computer to execute. That sounds a bit abstract so lets make an analogy.

Assume that you are on the couch, watching TV, when you get the overwhelming urge for a beer. So there you have a problem, need a beer. Let’s further assume that you, as the thinking programmer, are the brain, and you have instruct the stupid non-thinking computer, which is the body. So being so smart, you say, “Go to the kitchen, get the beer from the fridge and drink it.”. The body goes, “Go?” So you have to clarify, “Get up, turn right, walk two steps, turn right again, walk five steps, then turn left.” To which the body haughtily replies, “Get up?” So you have to go, “Flex both quadriceps, while pushing arms forward to maintain balance, until fully extended and upright.” Maybe this is something the body is finally capable of doing, so hurrah! Now you can go through the process of instructing it how to walk…

If you are lucky, some guy in the past might have already figured out that walking is a good ability to have. So he compiled as set of instructions on how to walk, which you can then feed to the body, merely having to tell it where to walk to. Well, isn’t that easier! These pre-made instruction packs, commonly called APIs or SDKs save you from having to laboriously go through each and every minute detail. However, before you use these instruction packs, buyer beware! The walk might not be perfect… it might have a limp! Or it might be only good for the first ten steps. Or it might leave you prone to falling down on certain terrain. Always read the fine print and test it to make sure it does what you think it is doing and be aware of any side effects.

So now you have the gist of how to program, you might find yourself encountering a couple of problems. The first is that you can’t figure out how to properly break down a problem or part of a problem. The second, particularly for game programmers, is that your set of instructions is so long and convoluted that the machine simply can’t execute it fast enough. Regardless of which, programmers tend to apply the same solution… “Think harder!”.  So you end up with these zombie programmers staring mindlessly at the screen, wracking their brains at the problem till their heads hurt and they slowly lose their minds.

The secret that eludes these programmers is that it isn’t matter of finding a solution. It is instead perceiving the problem. That’s right, it’s a matter of perception! Oh yes I see you, the artist giggling in the corner about our silly programmer post. Indeed, the artists have known these for years. Before an artist learns to draw, he is first taught to see. Once he can perceive the objects in our world in the correct way, he can apply it to canvas. Similarly, depending on how you perceive the problem, different solutions will become apparent. How do you change your perception? You have to identify and challenge your presuppositions. Tear down the things that you always take for granted and ask what if? Ask yourself what the problem is really about, and what else can it be about instead? The first few times, this can be really hard, but as you go on, it gets easier because *gasp* you are becoming a rational creature! And that is really difficult for a human being.

Good programmers take this concept and push it even further. Even when they are not stuck, they will view the problem from several different angles, and pick the best and simplest solutions that present themselves. That is why it seems that their code is always ten times shorter than yours, simpler, and faster to execute. The more angles they cover, the better pick they will have, and the less code they will eventually have to write. This is why when writing code, 90% of your time should be spent thinking about the solution, and 10% of the time typing it out in code. (Yeah, I pulled those numbers out of my ass, but you get the idea)

So back to our beer analogy, challenge your suppositions. Do we necessarily have to go over to the beer? Can we make the beer somehow come to us instead? Thus we fire up our trusty speech API and yell the magic words, “Bitch! Get me a beer!”. Wait ten seconds (during which you can do other stuff), and a freshly opened beer appears magically in your hand. That, my friends, is what we call elegant programming!

5 Comments on “Programming, How To”

  1. 1 stan chang khin boon said at 11:51 pm on January 11th, 2011:

    Great post about programming.

    I would like to add some of my thoughts.

    * All programming languages ultimately is the same with different concept, syntax and services.

    services are things the programming language will do for you, like memory management and stuff but some services come with implication, these services can introduce new problem.

    its like english, mandarin, italian, different of of saying the same things. The same things here are instructions. There’s not really one language that is harder than the other. Its usually just that one language provide some service which the other don’t.

    * Reading is a important part of a programmer job and if you want to excel. I felt strongly that anyone who don’t read and shun away from even trying to read getting started guide will never be a good programmer.

    Programmer are problem solver and usually need to find solution on a daily basis. In the real world, you can’t really solve much problem without reading for more knowledge.


  2. 2 Eugene said at 1:52 am on January 12th, 2011:

    Hey KB! I’d agree heartily with the first point but defer on the second. While having domain knowledge certainly helps, past a certain point it just clutters your brain with ideas that may or may not be related to your problem.

    Programming problems, being (usually) logic problems, can be solved in the absence of additional knowledge purely via critical thinking. Text provides more ideas, but it provides it without forcing you to think through all the considerations that resulted in the proposed solution, and that is something I’ve found wanting in most junior programmers.

  3. 3 stan chang khin boon said at 10:35 am on January 12th, 2011:

    i agree that it can take away critical thinking as i am a victim of such.

    i had not much solution for critical thinking except for practicing.

    on the other hand, reading sometimes reinforced some of my doubts. when I designed something the first worry is that I am doing it wrongly so when you see yourself doing something close to what others is doing is a calming feeling. Although this might be interpreted as good and bad, i then to think of it as a good thing while also fully aware of its issue.

    I think thinking are like steps, if you skip any, you won’t arrive at the end point that steps lead you too. true that some converge but some diverge too. reading kinda open options, so i could choose wisely. but it will definitely take critical thinking away. its kinda a balancing act. and it can be a bad addiction as you will be always be looking for solution that hasn’t quite yet develop.

    For me I felt I didn’t have the foundation to be creative in my thinking yet. I took the simple approach of absorb rather than think though. In long run it might have hurt my chance though.

  4. 4 Eugene said at 1:34 pm on January 12th, 2011:

    Ha, as they said in Hollow Man, true genius is being able to get from A to D without going through B and C. But the rest of us… we need our B’s and C’s.

    One thing I will give to acquiring knowledge is that it is incredibly good for design. While it’s not so critical in the “this will solve your problem” kind of way, I really like it in the “but you could do so much more if you did it this way” kind of way. It’s stuff from outside your box that opens up avenues that you may not have uncovered while hacking through your previous problems.

    As game programmers, I think this gives us the edge to not merely satisfy our users, but amaze them. To this end, I’m not only a fan of reading, but a big fan of daydreaming too. After all, that’s what we do as game developers, isn’t it? Turn dreams into reality!

  5. 5 stan chang khin boon said at 3:18 pm on January 13th, 2011:

    yup. i agree and i’m addicted to the “but you could do so much more if you did it this way” and that’s why i put reading high on my list though.

    i know what ya means saying turning dreams into reality but over the years i been beaten down by reality. thinking back, i use to have so much passion and i day dream a lot about all the stuff i can create (mostly games) with programming.

    luckily i still love programming. its such an exciting time ahead for many of us programmer. no matter how low we are in the stack of cooperate structure, if we believe in programming, some lucky guy might just be the next to shape not just the virtual world, but the real one.

Leave a Reply