



JORDAN POULTON: Thinking like a programmer

Create a logical recipe first to avoid trial-and-error coding

Over the past few years we’ve had over 5,000 applications to Makers Academy, and between myself and my incredible colleague Nikesh, we’ve run around 3,000 interviews. I think it’s fair to say that we’re world-experts in predicting someone’s future potential as a programmer.

Most beginners tend to believe that the fastest way to ‘learn to code’ is to memorise syntax. Our (broken!) education system trains us to believe that mastery of a subject involves being able to regurgitate as many facts as possible. I’ve seen hundreds of students who can quote Chris Pine and who’ve memorised solutions to the Bowling Alley kata, but struggle to understand how to solve simple challenges like “build a function that takes a name and prints to the console ‘Hello #{name}’ ”.
Being a developer is not about having an encyclopaedic knowledge of all the class methods in a given language. Development is fundamentally an exercise in problem solving. Senior developers haven’t learnt the solution to every problem. In fact, they’ve learnt a methodology of how to solve complicated problems  —  a methodology with two key elements: breaking a problem down into a series of smaller and smaller problems until each individual problem is trivial to solve, and the ability to apply the scientific method to programming.
An example might help clarify my point. Let’s say I ask you to create a function that randomly selects which employee will be tasked with closing the office this evening. Your typical beginner will excitedly tell you that they “Used ‘rand’ or something on Codecademy” and proceed to throw code at the screen in the hope that something sticks. Rather than focusing on their problem-solving process, they try to remember code that they’ve learnt and shoehorn this specific piece of code into a solution. This, for me at least, is a big red flag if you’re interviewing for a space on one of our courses.
A developer will start by creating an entire solution that has nothing to do with actual code. They will focus on breaking the problem down into a sequence of simple steps  –  turning any action into a logical recipe of trivial elements. The real challenge is to come up with at least one, preferably a number of logical solutions to the problem, and only then to see if you know how to translate your logic into Ruby, JavaScript or whichever coding language is flavour of the month.
Here are two solutions off the top of my head:
Solution 1  –  Collect all the staff names together, mix them up and return one.
Solution 2  –  Put each name into an ordered list, choose a random number and whoever’s number corresponds to the random number is selected.
Here you can see that an entire logical solution is offered without mentioning code at all. By breaking a single problem down into lots of small steps, you can see that each individual step would require a trivial piece of code that doesn’t need deep knowledge of the Ruby documentation to overcome.
Taking time to work out your logical sequence of steps before you even touch the keyboard is one of the most powerful things a beginner can do to accelerate your coding journey.
It amazes me that so few people in the world really understand the scientific method, and how few of these people are able to apply it properly in real life.
What I tend to see is a lot of trial and error. A candidate will start writing a solution to a problem, decide halfway through that they don’t like it, or that they don’t think it will work, delete the whole lot and start again  –  before they’ve even tried running the program! There’s nothing more disheartening than seeing someone write a correct solution to a problem and then delete the code before having even tried running it, simply because they thought it was ‘too ugly’, ‘too simple’ or ‘wouldn’t work’.
Trying to solve problems without using the scientific method is like playing darts with a blindfold on. At the heart of the scientific method is the loop of Hypothesis-Prediction-Testing-New Hypothesis. In practice it’s even easier than this, because the ‘testing’ part is almost always just ‘run the code’, so all you really need to do is make sure that whenever you write a line of code, you have a hypothesis (or prediction) pre-execution of what that code will actually do when you run it.
It’s a simple but powerful concept. Every time you go to write a piece of code, ask yourself this  –  what’s my expectation? What do I actually think this code will do? Don’t allow yourself to run it until you’ve made a clear prediction. Then, when you run the code  –  were you right? If you were, you understand this coding concept and can move on. It didn’t do what you expected? Now’s the time to set about finding where the gap in your knowledge was by forming a new hypothesis on which part of the code is wrong.