16 Jun 2015

Complexity Simplified

So I've been taking a programming course, which is coming to an end in the form of an exam two days from now. Well technically there is another course's exam tomorrow... and yet another one a few days later. But that's not the point. And yes I've studied.
Anyway one of the takeaways that the programming professor emphasised on was learning to manage complexity. Sure there were loads of techniques we picked up on that was specific to programming. A heck of a journey through recursion, loops, nesting, and so on. Again, not the point. Those techniques were merely tools to tackle problems that we attempt to solve through coding.

In fact, they really can extend beyond the coding box into "real life".

One important thing we learned - and often keep get reminded about - is to account for all possible cases that could crop up with our problem. There can be possibilities that we overlook because we either don't even realise they could happen - this can be remedied with experience - or we assume they're unlikely to happen, which may very well be worse. Even if the strategy you've thought up happens to work in this scenario, it may not necessarily work for other scenarios.

Another thing we learned is to make sure we're able to trace through our solution and identify what goes wrong in what way. This would be a way of debugging in the context of coding. But we could similarly trace through our thought processes. If we dissect our thoughts and test them carefully, we may just find that our thinking had hidden flaws that have yet to flare up and cause problems in your decision-making.

A third thing: it may be easier to start from the basic simplest case, and extend from there. This would be a common programming approach that can lead to recursive or iterative strategies. Similarly, what may appear as daunting challenges could just be longer extended versions of simpler problems that you already know how to tackle. Then you just simply need to adjust your basic strategy and scale it up accordingly.

Perhaps a final insight for this post: make your thought process clear. For programming, if your code is obfuscated, you'll have trouble understanding yourself, as would others who would look at it. Similarly, if you can't make your thought process explicitly clear, you'll likely have trouble finding out what's wrong with your thinking or how to fix it. And you won't be able to ask others to advise you either.

So the whole moral - if I should call it that - is that learning to code leads not just to proficient usage of powerful tools, but also refined ways of analysing and tackling problems. The former is what gets showcased more often in popular media - you know that typical fictional hacker that spouts technobabble and mashes the keyboard to create cryptic strings of words on the monitor screen - but the latter has potential application beyond coding.

It's probably easier to translate one's thinking into code though. I'm a bit biased now.