Java Child / The Machine Does Exactly What You Said

Thinking Like A Programmer Begins Long Before You Write Anything

Programming is not typing. It is the slow, learnable habit of breaking a wish into steps so small and so plain that a machine with no judgement at all can carry them out without guessing.

Most people arrive at programming expecting to learn a language, and they are half right. A language is the surface. Underneath sits something older and far more portable: the practice of turning a vague intention into an ordered set of unambiguous steps. That practice is what carries across every tool you will ever meet. If you learn only the surface, each new tool feels like starting again. If you learn the thinking, each new tool feels like an accent you have not heard before, strange for an afternoon and familiar by the evening. This publication is about the thinking. The site name is a small joke about a child object, an idea borrowed from the way programs describe things that inherit from other things, and that is the last we will say about it.

The first shift is accepting that the machine does not know what you want. It knows what you said. Every beginner discovers this the hard way, usually while staring at something that is obviously correct and obviously not working. The gap between the two is not a flaw in your character. It is the ordinary distance between an intention held loosely in a human head and an instruction that must be exact. Closing that gap is the whole job. Once you stop treating the machine as an adversary who misunderstood you on purpose, and start treating it as a very fast, very literal assistant with no life experience, most of the frustration drains out of the work.

The second shift is realising how few ideas are actually in play. You can do things one after another. You can do something only when a condition holds. You can do something repeatedly. You can wrap a chunk of work in a name so it can be used again without rewriting it. That is close to all of it. Everything else, every impressive system you have ever used, is those four moves layered, nested and combined until the structure becomes tall. Knowing this does not make hard problems easy. It does make them approachable, because when you are lost you can always ask which of the four you are looking at, and the answer is always one of them.

The third shift is about time. A program is not a picture, it is a process. Values change while the program runs, and the same instruction can mean different things at different moments because the surroundings have moved underneath it. This is where most genuine confusion lives, and it is why reading code as though it were a paragraph of prose fails so often. You are not reading a description of the world. You are reading a recipe for changing one, and to understand it you have to hold in your mind what is true at each point, not merely what the words say.

The fourth shift is emotional as much as technical. Things will not work, constantly, for as long as you do this. The people who get good are not the ones who avoid that, they are the ones who built a calm procedure for it. Read what the machine actually told you. Make the failing situation as small as it can possibly be. Check the thing you are certain about, because certainty is exactly where errors hide. Explain the problem out loud, slowly, to something that will not interrupt. None of this requires talent. All of it requires the willingness to slow down at the precise moment when everything in you wants to speed up.

So this is an invitation to be deliberate. Trace by hand before you run. Say out loud what each step is meant to achieve. Write down what you expect to be true before a step and what you expect to be true after. These habits feel painfully slow for about a fortnight and then they stop feeling like anything at all, because they have become how you think. The reward is not speed, though speed follows. The reward is that the work stops being mysterious. You will still be stuck often. You will simply know what to do about it.