How to think like a programmer

The difficulty in programming, at a large scale, inevitably comes from the need to use computational thinking to correctly break down a problem until it can be solved. So how does a programmer think about a problem?

An example of a problem might be:

1. finding the square root of a number
2. shooting a projectile from a cannon when the player presses the spacebar
3. checking if the user input the correct password without letting the password be visible from the source code

Abstraction

For the first example, a programmer is unlikely to need to solve this themselves, since it is such a common problem that someone else will have already encountered it, and added it to a library of procedures to solve similar problems. This strips away the unnecessary detail of how the procedure works, and can just be thought of as a mysterious machine that turns the inputs into the outputs. If instead you make your own, you should be careful:

• If there's a set of inputs you didn't account for, like square root of a negative, the program can unexpectedly break. To fix this, specify the preconditions as well as the inputs and outputs.
• Then, if you end up with inputs that wouldn't necessarily match the preconditions, you either have to make sure they do, or rewrite the procedure to account for them.
• If your procedure isn't thoroughly tested, then its outputs might not be as expected. This kind of bug can fly under the radar for a very long time.

Decomposition

Let's look at the second example - this is a very complex problem, so a programmer would start breaking it up into smaller problems. This is called decomposition. For instance, you would need a way to detect that the spacebar is pressed, a function that renders the cannon and projectile based on their positon, a function that calculates the trajectory of the projectile... and each of these can be broken up into smaller problems. So we need to use abstraction to think about each of the components individually and then use those components to build bigger structures of code. This is heavily used in hardware, which can decompose into huge trees of problems.

In the last example, it isn't obvious how to start building this at all. Computational thinking often involves stripping a problem down to its core issue - here, that would boil down to a hashing algorithm. Without that algorithm, it's impossible to attempt this, so if you just try breaking this up into parts, you will waste time making the simple parts before having to overhaul them when you realise that your method won't work. You can't, for example, break this problem into "check if the password is correct" and "hide the real password" because the algorithm that checks if the password is correct doesn't work after the algorithm that hides the real password happens.