Reading time: 5 mins
This man knows how to do this well…
Houston… We Have A Problem
But when it comes to creating a new project from scratch or when I am given a more complex challenge, I become stuck. I have reached what Eric Trautman said in his brilliant blogpost “Why Learning To Code Is So Damn Hard” the ‘Desert of Despair’. After a couple of months of scratching my head, I slowly realised that I was missing a key tool to help me survive this desert, Indiana Jones style…
This I discovered was the million-euro answer. It’s problem solving. The Oxford Dictionary describes ‘problem-solving’ as the “process of finding solutions of difficult or complex issues”. Although good coders can write decent code and through some programs together, great coders use their code to solve problems. Like giving dogs and cats typewriters and expecting them to produce Shakespeare, was like my method of writing loads of code and hoping that answer would reveal itself – there had to be a better way.
4 Steps To Solve Problems
Vicker’s book is extraordinary (book review coming soon) and he devised a 4 step framework that you could use to help you tackle most coding problems!
1) Understand The Problem
You know the catchphrase… I said it already!
Vickers believes that most of the coding problems that we have is simply because we do not have a enough of a grasp of it to solve it. Humans are good at ‘abstraction’ which means that we can look at something i.e a thing, an idea and a person and understand what it is without going to very specific details. For example, if I asked you to ‘think of a dog’, in general you would think of a small animal with four legs, fur and a tail without having to think about whether it was a poodle or a rottweiler.
But in coding, the issue is that these ‘abstractions’ lead to assumptions that can actual hinder us in solving the problem. A great personal example of this was once when I was teaching a school class, I had a video clip that I wanted to show them but it was showing without any sound. After 10 minutes of unhooking the speakers, checking the software drivers were up to date and turning the machine on and off, I realised that the actual volume in the Media Player was turned off! It’s only when I went through it step-by-step, did I realise the error in my thinking.
If you are confronted with a large, complex problem, break it down it smaller, simpler chunks and solve those instead. Another tip I gained from the book is that if you become stuck, explain the problem to yourself as you would a small child: this will force you not to think less abstractively and take it step-by-step and this really works!
2) Devise The Steps
As they say the Iron Man suit wasn’t built in one day…
Once you think that you have understood the problem and broke it down to it’s core components, not you can start planning the steps that will give you the solution. This is not a static process: while planning the steps, you may find that there still maybe flaws in your thinking and you may have to go back to Step 1. Don’t worry, as the planning helps strengthen your understanding of the problem and lead you to new possibilities that you just would not of known in the planning stage.
Vickers suggests that you should display plans in more than one way i.e flowcharts and pictures so that it forces you to look at your plan from at least more than angle and this can help you get a different perspective on how it can be done.
3) Execute The Solution
The Wright Brothers had the right idea…
Once you have done Steps 1 and 2, its now time to put the plan into action. So does that mean that as soon as you click ‘launch’, your job is done and you can sip your Tetley tea? Not on your life. To quote that great philosopher Mike Tyson, “everyone has a plan until they get punched in the face”. Remember as much as you plan, it’s not possible that you will perceive every possible outcome. Your code will have to go through a ‘testing phase’ where you will have to remove bugs and rearrange your code until everything runs smoothly.
At this point, it very easy to get discouraged when your program doesn’t work properly but remember this is normal when you ‘ship’ your solution. Good programmers understand this and don’t let the bugs and the failures hinder them and they keep on truckin’.
4) Reflect Upon The Solution/What Did You Learn?
This fella will have a lot of time to reflect now…
So you executed, everything works smoothly and you are ready to jump on your horse and ride into the sunset. Not so fast Clint. The best programmers will often look at their solutions and evaluate them to see what they could learn. Great programmers ask themselves questions like:
- What could I have done better that would make the program faster/more responsive/less bug prone?
- What did I do well?
- If I had time, what could I add/take away that will make the program better for the client/user?
Good coders don’t work in isolation. They allow peers and other users to critique their work and make suggestions on how they can improve. Throughout this phase, Vickers believes that good coders write documentation not just for other users but themselves which helps consolidate everything that they have learnt.
Although this framework is incredibly simple (as it should be), it has been a real eye-opener for me as it gave me a plan of attack in which to help create better solutions.
Another aspect I liked about this framework was that made me feel that it was OK not to have the right answer straight away and we have to sometimes have to fail many times before we get the ideal solution. Of late, while learning to build more complex programs, I felt frustrated much of the time and dare I say it, part of me was questioning whether I really had ‘the chops’ to learn coding and was feeling a little lost. This framework has given me confidence that ‘failure is not final’ and in fact is the true path to successful and happy coding!
Thank you for reading! What did you think? As always, leave your comments below or tweet at me @karlwebdev.
See You next Thursday