How to Use This Book

There’s no Python in this chapter. Not one line. That might seem like a strange way to start a programming book, but think of it as the five minutes before a long drive, when you move the seat, fix the mirrors, and decide which route you’re taking. Skipping that part doesn’t get you there faster. It just makes the trip more uncomfortable.

This chapter is about how to read the rest of the book: how it’s put together, what it expects from you (less than you’d think), and what to do on the days when nothing makes sense. Here’s what’s coming:

#Who this book is for (and who it isn’t)

We wrote this for a particular kind of reader, and you might recognise yourself. Maybe you’ve opened a programming tutorial before, scrolled for five minutes, and thought, “This isn’t written for me.” Maybe you’ve watched a colleague type commands with total confidence while you were still wondering what a “variable” actually is. You’re curious about Python, perhaps even excited, and also a bit nervous, the way you feel walking into a party where everyone else seems to know each other.

Our readers include students, office workers, researchers, teachers, people changing careers, and people who simply want to stop doing the same tedious task by hand every Friday afternoon. You don’t need to be “technical,” and you don’t need to have written code before. Patience helps. Even that comes and goes for everyone, us included.

Picture Amara, who teaches geography at a secondary school. Every term she spends two evenings copying marks from one spreadsheet into another and building the same charts for parent meetings. She’s not trying to become a software engineer. She just suspects a computer could do this for her, and she’s right. If you have your own version of Amara’s two evenings, this book was written with you in mind.

Learning to cook is a good comparison. Nobody starts with a recipe written by a professional chef who assumes you own twelve knives and know what “chiffonade” means. You start by learning to hold the pan without burning yourself. This book stays at that level for longer than most programming books do, and it does so on purpose.

Now, who might want a different book? If you’d like a fast tour of syntax, or you’re keen to race ahead to advanced frameworks, this one will probably feel slow. We stop to explain why things work. We come back to ideas more than once. Some readers love that. Others find it frustrating, and there are good books that move faster.

It’s also the wrong book if you believe that being confused means you’re bad at this. Programming simply doesn’t work like that, and we’ll spend a whole section on why. Nobody understands everything the first time through, including the people who wrote the book you’re holding.

If, reading this far, you feel slightly relieved that nobody is going to rush you or talk down to you, you’re in the right place.

#How to read without getting stuck

Here’s something most programming books don’t admit: this isn’t a book to read the way you’d read a novel, from start to finish at a steady pace. It’s even less like reading documentation, where your eyes race down the page and your brain pretends to keep up. It works better as a walking companion. Sometimes you’ll walk together. Sometimes you’ll stop. Now and then you’ll wander off for a bit and come back.

When you hit a line of code that makes no sense, you’ll probably feel a small tightening in your chest. It’s the same feeling as assembling flat-pack furniture and finding two screws left over. It doesn’t mean you’ve done it wrong. It means you’re in the middle of something. Instead of trying to understand every detail at once, try asking a simpler question: what is this part trying to do in real life?

If the code mentions a list, picture a shopping list. If it mentions a function, picture a small machine that takes something in and hands something back. If it mentions a loop, picture telling a child, “Keep brushing until the timer goes off.” You don’t need the full theory to keep moving. You need just enough of a picture to take the next step.

A surprisingly effective trick is to read code with your finger, or your cursor, on the line. Go slowly. Read a paragraph twice if you need to. Understanding sometimes turns up late, like a joke you only get five minutes after everyone else has laughed.

Being confused doesn’t mean stop. It means slow down. A lot of beginners think the aim is to get rid of confusion completely, and they get upset when it keeps coming back. Experienced programmers aren’t free of it. They’ve just had enough practice sitting with it that it no longer frightens them. One warning, though: rereading the same sentence ten times rarely helps. If something won’t click after two goes, carry on. Many ideas in this book only make sense a few pages later, when you see them doing a job.

You can also skip around. Read a project before the chapter that explains it, if that’s what keeps you interested. Jump back. Nobody is checking.

#Why confusion is normal

Here’s a slightly uncomfortable fact. If you’re confused, you’re probably doing it right. Confusion is what the edge of your knowledge feels like from the inside, and the edge is the only place where anything new gets learned.

We’ve watched a lot of beginners hit their first error message. The reaction is nearly always the same: a sigh, a long stare at the screen, and then some version of “I broke it.” Usually they’ve broken nothing at all. Python found a missing bracket on line 4 and said so, in its rather blunt way. The second time it happens, the sigh is shorter. By the tenth time, they read the message, fix the bracket and keep typing, without even noticing they’ve got better at it.

At first, Python will look like a language where you know all the words and none of the sentences. for name in names: is made of perfectly ordinary English, and on day one it still means nothing. That’s normal. It’s what reading something new feels like.

Something beginners are rarely told: professional programmers are confused most of the working day. They look things up constantly. They paste error messages into search engines. The difference is that they’ve stopped taking it personally.

Some confusion comes from trying to take in too much at once. You don’t need to know every function Python has. Nobody does. You need the ten or so you’ll use this week, and the rest can wait until a project asks for them.

And then there’s the voice. You know the one: “Everyone else gets this faster.” “Maybe I’m not a programming person.” It’s extremely common, and it’s wrong. There’s no such thing as a programming person, only people who kept going for long enough. Speed doesn’t matter here. Coming back tomorrow does.

So when you’re confused, and you will be, don’t fight it and don’t give it a label. Read the next paragraph. Run the next example. One day a loop that looked like random symbols will just look like a loop, and you won’t remember when it changed.

#How projects work

The projects in this book aren’t tests. Nobody grades them. They exist for one reason: an idea you’ve only read about fades by next week, and an idea you’ve used to build something tends to stay.

Each project uses what you’ve just learned, plus a little from earlier chapters. If it needs something from much further back, we’ll remind you. Forgetting is fine. Everyone forgets split() at least once.

Most of the projects are small. A script that renames files. A tool that adds up expenses. Nothing that’ll impress anyone at a dinner party, and that’s on purpose, because finishing something small does more for your confidence than starting something huge. Some of them are a bit messy, too. You’ll write something, find it doesn’t quite work and change it. That isn’t you failing. That’s literally what a programmer’s day looks like.

If a project looks scary, ask what it’s for. Sorting some files? Keeping track of habits? Saving you from a dull Friday job? Once you know the purpose, the code is just a list of steps towards it.

You’ll like some projects more than others. That’s fine. Skim the ones that bore you and spend longer on the ones that make you curious. And don’t wait to understand every line before you start one. Understanding mostly shows up while you’re typing.

By the bigger projects near the end, you probably won’t feel “ready.” Almost nobody does. You’ll just be less nervous about trying, and that turns out to be what skill feels like from the inside.

#How the book is organised

The book is split into ten parts, and each one builds on the parts before it:

A few things repeat in every chapter, so it helps to know them by sight. Short notes set apart from the main text, like the one a few paragraphs above, hold the ideas most worth remembering. Notes that begin If you’re stuck describe the exact places where beginners most often get stuck, with the fix; if something isn’t working, look for one nearby. Most projects come with a flowchart, a simple drawing of the steps the program takes, so you can see the plan before you read the code. And every chapter ends with an On the Job section and a set of Exercises, which you’ll meet in a moment.

Parts 1 to 3 are the foundation, so read them in order. After that you can move around a little: if you need spreadsheets for work next week, it’s fine to jump to Chapter 15 and come back. The recipes in Part 9 are written to be dipped into whenever you have a job you’d like to hand over to the computer.

One last thought before we begin. Learning to program is a lot like getting to know a new neighbourhood. At first every street looks the same and you take wrong turns. Then one day, without noticing exactly when, you start recognising landmarks. You know where you are, and you know how to get home. That’s what this book is trying to do for you.

So as you turn to Chapter 1, don’t ask yourself whether you’re ready. Ask whether you’re willing to start. If the answer is yes, that’s enough.

#On the Job

Every chapter in this book ends with a short section like this one, marked with the briefcase. Its job is to connect what you’ve just learned to what happens in real workplaces: how the skill shows up in an actual job, what employers expect, the interview questions you’re likely to meet, and one small piece of work worth adding to your portfolio. You can skip these sections on a first read. If you’re hoping Python will lead to a new role, or a better one, they’re where the book earns its keep.

Here’s the first thing worth knowing. When a team hires a junior developer, a data analyst or someone to automate their reports, they rarely ask where you learned. They ask what you’ve built. A certificate shows you finished a course. A GitHub page with twenty small programs that actually run shows a lot more, and it costs nothing.

What employers expect: Visible progress, a bit at a time. When people hire beginners, they’re mostly checking three things: are you curious, do you keep going, and can you get yourself unstuck? You can show all three with your projects, which beats just claiming them in a cover letter.

Interview questions you might meet: “How do you learn something new?” and “Tell me about a time you were stuck. What did you do?” There’s no perfect answer to either. What interviewers want is a real story, with a beginning and an end. Your learning log (see below) will give you plenty.

Portfolio task: Make a free GitHub account today, before you’ve written a single line of code. Your first program, in Chapter 2, will be your first upload. Keep adding to it as you go, and by the last chapter you’ll have months of work that anyone can see.

Professional habit: Keep a learning log. It’s just a text file. After each session, write two lines: what you learned, and what confused you. It takes a minute. A few months from now, it’ll be the best interview preparation you’ve got.

#Exercises

No code yet, and no right answers. These are about setting up the habits that get people to the last page. From Chapter 1 on, the exercises are proper programming ones, and the solutions are on GitHub and on the book’s website.