Why you suck at programming

Man with vacuum cleaner by Justin Horrocks @iStockphoto

Do you know why you suck at programming? Because you don’t understand the process involved in programming.

There are 3 phases in programming

  • understanding the problem
  • formulating a solution
  • converting solution into code

Failing at any one (or more) of those phases, and you end up with wrong implementations, bugs and nasty results. There’s a common syndrome where programmers freeze up, unable to come up with what to do next, and don’t know how to write the code needed. It all comes down to failing at one of the phases.

Generally speaking, programming problems have little to do with technical knowledge, and more with problem understanding and solution formulation.

Understand the problem

If you’re a student, you’re probably looking at an assignment question from your professor. If you’re a professional programmer, you’re probably looking at user requirements. Either way, you’re figuring out the intention of what you’re tasked to do.

This is important because if you don’t understand the problem, you might end up solving the wrong problem or provide an inappropriate solution.

When I was in university, there was this assignment question about pointers. I can’t remember the exact question, but I remember that the question specified that only pointer syntax to be used (and not array syntax). Although my solution was correct, I wasn’t given the full credit because I failed to understand what pointer syntax was.

The problem might require you to call upon your other pieces of knowledge, like math or physics or music or colour representation. If you’re a professional, then this “other pieces of knowledge” will include your business logic, such as how your business works and how your users will interact with your software.

Formulate a solution

Once you understand the problem, you can then go about formulating its solution. There are 2 types of solutions. The first type requires a user interface, or an automation procedure, or a new way of handling data. Basically you need to write code. This is the one you’re probably familiar with. The second type is independent of code, or more specifically, you don’t have to write any code.

For example, the user wants to sum up all the values of a column in an Excel spreadsheet, and put the sum at the end of that column. If you just jump into writing code, you’ll probably call on OleDB functions and Microsoft Office helper functions and DLLs. Your program might work, but that’s not the point. The fact is, you can just educate the user of the summation function in Excel.

Part of your job as a programmer is to know when not to code.

In my case, my team leader goes through the user requirements, and decides if another existing system is capable of handling the requirements. This isn’t laziness, because as a whole, the company strives to minimise duplication of software systems. The user might not know that another existing software can handle his request. That’s why we as programmers have to help do that. (Which is probably why my job title is “systems analyst”…)

Convert solution into code

A solution is usually easier to describe than to code. Ever had those “just need to retrieve data, do some calculations, sort them and then dump them back into the database” moments? There are 2 ways to approach this. The first is to talk out the solution into pseudo code, and then figure out how to replace the pseudo code with real code. The second is to come up with every programming skill you have, and force feed them into the solution.

For example, let’s take finding the maximum number in an array of numbers. The first method’s pseudo code might be

  • have a variable to store maximum number
  • loop through array
  • while looping, compare current element with variable
  • while comparing, if greater than variable, then replace variable value with current value

Note that, it’s “loop through array”, so you’re free to choose any looping mechanism, be it a for loop or while loop or do-while loop.

What if you just learned sorting, and it’s the first (and only) programming skill you could think of to solve the problem? Hey, we could sort the array in ascending order, and then the last element would contain the maximum! Problem solved!

So you follow the second method, force feeding the sorting algorithm to the array, taking note of the last element, and then getting the maximum. It works. It’s just … excessive. There’s a Chinese saying that goes something like, “you don’t need a butcher knife to slaughter chickens”.

There are pros and cons to either method. The important thing is that you’re aware of what they are. Make sure you’re solving the right problem. You could be fixing bugs in that sorting algorithm when it’s not necessary in the first place.

Example: Sum of arithmetic progression

Let’s bring all 3 phases together. Suppose you’re tasked with finding the sum of the following series

1 + 2 + 3 + 4 + 5 + ... + 95 + 96 + 97 + 98 + 99 + 100

In understanding the problem, you’ll have to ask questions. Questions like

  • Is it always an increasing sequence?
  • Does it always increase by 1?
  • Is the number of terms fixed?
  • Does it always start with 1 and end with 100?

You might have found a solution. The point is, is the problem a one-time thing, or is it variable? Maybe the user needed the answer with the question phrased like this. What if the user wanted to increase by 2 the next time? Can you generalise your solution?

Sometimes, the scope of the problem is not given by the user, but is implied. The user expected it, but because you’re so logical and follows strictly to rules, you fail to see the bigger picture (and hence bigger problem).

The solution could be (using the first method of solution approach from above)

  • have a variable to store intermediate sum
  • do a loop, starting with 1, end with 100
  • sum up values in the loop, one iteration at a time

You can probably come up with working code for this, so I’ll leave that to you.

Now what if you’re also a math wiz, and you realise that the series is actually an arithmetic progression? Then using the math formula for arithmetic series (toning some terms down)

S = n(2a + (n-1) d) / 2

where S is the sum
n is the number of terms, which is 100
a is the first term, which is 1
d is the difference between terms, which is 1

Notice there’s a formula, which means it’s easy to translate into a function. And you have an instant generalised function to handle any arithmetic series. This is much better than the looping solution presented before this. But you will only get this better solution if you know the math formula for arithmetic series, which is outside of most programming education.

Alright, fine, maybe during your programming education, you did learn some math. My point is, programming is a tool to solve problems. The solution can come from another place, in this case, the math formula for arithmetic series. You’re a better programmer because you knew math as well.

Now, what if the user really wanted to solve the original problem only once, and only this specific instance? Here’s an ingenious solution, and no coding required. Let me put the series here again for better illustration.

1 + 2 + 3 + 4 + 5 + ... + 95 + 96 + 97 + 98 + 99 + 100

Notice that 1 can be paired with 99 to add up to 100. Notice that 2 can be paired up with 98 to add up to 100. Can you see the pattern? The pairs, (1,99), (2,98), (3,97) … (49, 51) add up to 100 each. And there are 49 such pairs. The only terms without a partner are 50 and 100.

So what do we have? 49(100) + 50 + 100, which is 5050. Compare it with the math formula, where you have 100(2(1) + (100 – 1) 1) / 2 which is 5050. You get the same answer, even without using the formula.

If you really understood the problem, then solutions vary, and sometimes, solutions don’t require code at all. Solve the real problem. And that’s how you can suck less at programming.

Endurance coding

Jogging in winter by Wojciech Gajda @iStockphoto

You know what the user interface looks like. You know what needs to be coded. You can even see it in your mind. But you’re stalling. Why?

Because there’s a lot of boring code to be typed out.

This isn’t standard code that can be created by code generators. This isn’t code that involve sophisticated algorithms. This isn’t code that require meetings with other developers, managers and users.

It’s just tedious. And there’s a lot of them. And it’s boring the heck out of you.

Taking the bore out of boredom

Focus on milestones. Small ones. Like completing that one function that has to be copied and pasted and hand-altered for customisation (my bind datagrid functions are a case in point…).

Completing milestones, even seemingly insignificant ones, boost morale and the sense of achievement. This allows you to take on the next boring code task. And the next. And the next…

Moving with the rhythm

I like playing Gran Turismo on the PlayStation. I’m not into cars, really. Constantly tinkering with gear ratios doesn’t make any sense to me. Despite being barely able to tell the difference between a front wheel drive and a back wheel drive, I still like the game.

There’s this endurance race course type. It’s long. It’s like 30 laps or something. The tracks take anywhere between half an hour to 2.5 hours.

And when I’m on the endurance course, I’m just mindlessly ploughing the asphalt, swerving around curves, speeding past a tree here and there. After a few laps, the curves become familiar, and I drop into a lull, rhythmically tapping the controller to brake a little here or turn a little there. That’s when I need to jerk my senses back into alert mode.

When you’re coding dull and boring things, you tend to lower your alertness, and that’s when bugs make their way into your code. So how do you stay alert? Move with the rhythm.

If you hand type those code as much as I do, you’ll probably get into a rhythm or beat when you type certain swatches of code (mine’s the string.Empty code phrase). Particularly if you’ve got Intellisense or autocompletion facilities in your IDE. Add tapping your feet to the music, and you’ve got a surefire way of remaining engaged in your code.

It’s not a sprint

Remember, it’s a long journey when you’ve got lots of boring code to churn out. The trick isn’t to wear yourself out by bludgeoning through the code and hope that you’ll finally reach the end. Because you’ll never make it. Usually. Maybe. Or if you’re lucky.

What you need is to slowly build up a coding momentum. Once you’ve got a big enough momentum, inertia will take most of the bore out of the chore. You might take a little more time starting, but it’s the end results that count.

Remember, you’re in an endurance race. Your only opponent is yourself.

SimCity Societies review

SimCity Societies (SCS) is a city simulation game by Electronic Arts. I did a search, and the general feeling from gamers and reviewers was this: It sucked.

That said, I went against all popular public opinion and bought the game anyway. And it’s fun!

There were basically 3 points the fans of the SimCity series didn’t like. The 1st one is that the societal values don’t make sense for some of the buildings. For those of you who don’t play the series, it involves

  • laying out roads
  • laying out electric lines and water pipes
  • zoning residential, commercial and industrial areas
  • building homes, cash-cow skyscrapers and factories

Basically you’re playing mayor.

SCS threw most of that out. There are now 6 societal values: productivity, prosperity, creativity, spirituality, authority and knowledge. Buildings now contribute and consume one or more of those values. And some don’t make sense.

For example, one of the “home” buildings consume (take away) prosperity points. It looks moderately modern. It allows moderate freedom (not sky-rise, not cramped). Yet it makes your city “less prosperous”. I don’t quite understand it either, but it’s a game, and it’s not a big deal to me.

The 2nd point invited more clamour; there’s no laying electric lines from power stations and water pipes. Power stations can be placed as far as needed and the city continues to function. There’s actually no water pipes. Buildings simply have water!

Frankly speaking, I hated laying out electric lines and water pipes. It was the least fun activity when I did play in the past (can’t remember which incarnation of the series). The lines and pipes don’t have to run along roads, though it seemed logical to do so. When buildings go down, I’ve got to remember to repair lines and pipes. If I don’t, then the new building won’t have power and water. A building must be connected to a line and pipe, or it’ll fail its intended function.

The 3rd point was no zoning for areas. You simply plop down buildings. If an area has a high density of homes, then you can think of it as residential areas.

I think fans of the (older) SimCity series just need to rethink how they play this version. I like this new way. Cities don’t have this clear a demarcation between residential and commercial areas anymore.

I’ll be honest. I like this game because it allows me to build any city I can imagine. Free of electric lines and water pipes, I can just lay out roads and plop down buildings to my heart’s content. Aesthetics matter more than function.

I still like making sure of efficiency, balancing expenses and profits, and other micromanagement stuff. It’s just that, I’m taking a break from programming, I’ve done enough thinking!

If I want micromanagement, I’ll go play The Sims 2. Managing a virtual life’s activities is more fun than juggling numbers.

See your code in your mind

Are you a visual person? Even if you aren’t, have you ever been so clear about your algorithms and your logic and your code, that you see that code in your mind’s eye? You feel like if you close your eyes, the code is etched on the back of your eyelids.

Sometimes, after I’ve thought through the programming logic, the code just started to appear. Line after line of code. And I knew that if I didn’t have it on the screen, it would disappear. So I typed. My fingers danced around the keyboard, feverishly capturing the slowly fading code from my mind.

Racing across the screen were the characters I knew, from somewhere deep within me, would form the correct code.

Depending on the complexity of the problem, the elusive code could very well be one line. But it’s a line of code that came from the efforts of careful thought and much deliberation. The vision of the line of code could even come with syntax highlighting!

I guess in the end, it’s not really about whether you can see your code, but whether you’re confident about your code. Closely related is your sense of responsibility, but that’s another post. So, are you confident about that line of code you just typed?

A mouthful of hurt

Hi this is Yesterday Vincent. Amazing time travel abilities aside, as of writing this (yesterday), I’m in a world of pain.

I just had two wisdom teeth taken out.

One of them’s been bothering me for the past few days. It hurts to eat. So I’m hungry a lot of the time. To quote a wise friend of mine, “A hungry man is an angry man“.

Being grumpy most of the time means it’s hard to think. When it’s hard to think, it’s hard to come up with fantastic program algorithms or solve problems or fix bugs.

Ok, I’ve got to stop. I’m starting to drool, and the anesthesia’s wearing off. So I’ll leave you with one word.


I’ll go curl up in pain now…

A new day has come

A new day has come

Alright, first post in a new year! For the benefit of old and new readers alike, I’ve decided to write a short introduction on what this blog is about and what you can get out of it.

Who are you?

I’m Vincent Tan, a Singaporean Chinese (and told on many occasions that I don’t look like a Singaporean). You can read more about me here, because you have a more burning question…

Who is a polymath programmer?

A polymath is someone knowledgeable in a wide variety of topics. A polymath programmer is someone who knows a lot about a lot of topics, usually centred around programming.

I don’t proclaim I’m the best programmer. I’ve made mistakes before. I’ve coded monstrosities before.

Yet the polymath programmer is an ideal I strive towards. Because in the few recent years I’ve done professional programming work, I’ve learnt that being the best is no longer enough. Being 2nd best at everything, is.

So what’s this blog about again?

Curiosity. It’s about learning and experiencing as much as you can, because you never know if something is useful, particularly in programming.

You will find articles about programming, software management and coding theories (not the math kind, though it can be…). There are also articles on graphics, 3D and image editing. There are math articles (such as Bezier curves), web articles and even singularities like chalcography or demos or AI in game development. I also write stuff about working in a corporate office environment, like handling user queries and shared thoughts on not talking while in toilets.

I strive to be a better programmer. There was commotion about programming jobs going overseas, so I went ahead to see what it’s like to outsource a blog design job, to my utter horror and was a complete disaster. There was talk of integrating media into blogs, so I went ahead to do my first podcast, learning how to edit audio with Audacity and sprucing audio with purchased tracks from Soundrangers. I learnt to go beyond the boundaries of my own blog, and wrote a guest article on coaxing creativity with music.

If you want to know more, subscribe to my blog feed to get my latest articles as they’re published. RSS feeds were new to me when I started writing, and you can read up on what I learnt and wrote on RSS subscriptions.

I learn something, experience it, and then discuss it here.

What do I get out of this?

Interesting ideas and experiences. Some readily put to practical use. Some, not so. You might find something uproaringly hilarious. You might read something groundshakingly insightful. You might come across something that’s deeply resonant with your core belief.

I can’t tell you exactly what you’ll get, because ultimately you decide what you learn out of something. Besides, polymaths don’t restrict themselves to any one topic. And if you don’t get anything out of this post, then get this:

Programmers nowadays, don’t just do programming anymore.

In my professional work, on any one day, I’m expected to

  • work with and administer Sybase, SQL Server and Oracle databases
  • write SQL commands for the 3 aforementioned databases
  • write C# and VB.NET for web applications
  • work with C, C++ and Unix shell scripts for backend applications
  • design look and feel of web applications
  • work with graphic files (I’m the designer remember?)
  • do HTML, CSS, Javascript

And that’s just programming related tasks. I’ve installed applications for users, done paperwork for SSL certificate renewals (and installing them), and clarifying business logic for users (who should know the business logic anyway, but hey…). I’ve created programming specs for my offshore colleagues, and I’ll review their code.

I want to highlight one point to you. The majority of my time is used on activities that have nothing to do with coding. Not one line of code. If it was about code, then it’s usually about maintaining code, like checking up on messages, bug fixes and explaining programming logic.

I want to be a polymath programmer too!

Let’s help each other then. I am only one person, so the breadth and depth of any topic discussed can be limited. So I’m asking for your help, your input. You can

  • ask about anything you don’t know
  • tell me about anything you do know
  • offer your comments on articles
  • submit your own articles

You can contact me on my contact page, or email me using vincent [the at sign] polymathprogrammer [the period character] com, or leave comments on articles. Topics preferably programming-related, but anything goes.

Like “Why are there 24 hours in a day?“. The Egyptians came up with the idea. They decided there should be 10 hours for daytime, corresponding to our 10 fingers and thumbs. Then they added one hour for dawn, and one hour for dusk. That’s 12 hours. Then they multiplied by 2 for night. And that’s how you have 24 hours.

Rounding this introduction, I’ll tell you 3 rarely known facts about me.

  • I brush my teeth with my right hand in the morning and with my left hand at night, to train ambidexterity
  • I juggle 3 tennis balls for fun sometimes
  • I used to play a Chinese orchestral instrument called the zhong ruan

It’s a new year, with new challenges to face and new things to learn. So get ready, because a new day has come.