01
Why is programming so hard in first year?
If programming feels hard, you're not imagining it. In first year you're learning two things at once: a strict language that cares about every bracket and colon, and a new way of thinking, where you break a problem into small, exact steps. Either one alone would take time. Together, they can make the first few weeks feel like nothing is sticking.
Programming is also cumulative. Conditions lead to loops, loops lead to functions, functions lead to classes. If a week goes by without practice, the next lecture sits on top of a gap, and that gap is usually why it suddenly feels impossible. I know that lost feeling from the inside. Feeling stuck in week four mostly says you're still new, and the fix is steady practice.
02
How to practise coding so it actually sticks
Watching your lecturer code, or reading a finished solution, feels productive. Mostly, it trains you to recognise code, not to write it. Tests ask you to produce code from nothing, so your practice should look like that too. Type every example yourself instead of copying and pasting it, because your fingers learn the syntax while your head follows the logic.
Then break things on purpose. Change one line and predict what will happen before you run it. Were you right? If not, work out why. A few days later, close the example and rebuild it from a blank file. The parts you can't remember are exactly what to practise next. Short sessions most days do more than one long, panicked weekend.
- Type examples out instead of copying and pasting them
- Predict the output before you press run
- Rebuild each practical from a blank file a few days later
- Redo the exercises you got wrong, not only the ones you enjoyed
- Keep a list of syntax you keep forgetting, and drill it
03
Get better at programming logic: plan before you code
Most first-year problems aren't really syntax problems. They're 'I don't know where to start' problems. The fix is to solve the problem in plain language first. Do one small example by hand, on paper, and notice exactly what you did. Those steps, written down in order, are your algorithm. Pseudocode just tidies them into short, code-like lines.
Say you need the highest mark in a list. By hand, you'd look at the first mark and remember it, then compare each next mark with the one you're holding, and keep the new one if it's bigger. Now the code almost writes itself: a variable for the highest so far, a loop, and an if statement inside it.
This is how you improve problem solving in programming: lots of small problems, each planned before it's coded. Start with the exercises your module gives you, then textbook questions and old practicals. Free practice problems online help too, once you can plan the steps yourself instead of reaching for the answer.
04
How to read error messages instead of panicking
An error message is the computer telling you what went wrong and roughly where. It looks hostile, but it's the most useful thing on your screen, so read all of it, slowly. In Python, read the traceback from the bottom up: the last line names the error, like NameError or TypeError, and the lines above it show the file and line number where it happened.
In Java, first notice which kind of error you have. A compile error appears before the program runs, with the file name, line number and a short message such as ';' expected. Fix the first one first, because one missing bracket can cause a whole list of others. A runtime exception, like a NullPointerException, happens while the program runs, and the stack trace shows the method and line involved.
Two more habits save hours. If the reported line looks fine, check the line just above it, where a missing bracket, quote or colon often hides. And if a message makes no sense, search the exact error text, without your own variable names. You're very rarely the first person to see it.
05
How to debug code that runs but gives the wrong answer
Debugging means finding and fixing the difference between what you meant and what you actually wrote. The hardest bugs are the silent ones: no error, just the wrong answer. Here the computer can't point at a line, so your job is to find the exact spot where your expectations and the program part ways.
Start by predicting what each variable should hold at each step, then check. Print the values inside your loop, or use the debugger in your editor to pause on a line and step through one line at a time. On paper, a trace table does the same job: a column for each variable, a row for each step. It's also the skill code-tracing questions test.
Still stuck? Explain the code out loud, line by line, to a friend or even a rubber duck. Programmers genuinely do this. Saying what each line does often exposes the one that doesn't do what you thought. And change one thing at a time, so you know which change actually fixed it.
- Reproduce the bug with the smallest input that shows it
- Print or watch variables inside loops and before if statements
- Check the edges: an empty list, zero, the first and last item
- Look for loops that run once too often, or once too few
- Undo random changes that didn't help
06
How to ask for help, and get a useful answer
Most students wait too long to ask, usually because the question feels too basic. In programming, waiting is expensive, because next week's work is built on this week's. When IOL Education featured my story, I put it simply: "It's about being consistent, asking questions, using the support around you." Lecturers' consultation times, tutors and classmates are all part of that support.
A good question gets a fast, useful answer. Include the exact error message, the few lines of code it points to, what you expected to happen, what happened instead, and what you've already tried. Often, writing all of that down solves the problem before you send it. If it doesn't, whoever helps you can see the issue in seconds.
AI tools deserve a word here too. If one writes your code, you skip the exact practice that tests measure, and you'll meet that gap in a closed-book practical. If your module allows AI at all, use it to explain an error or a concept, then close it and write the code yourself. Check your module's rules first, because they differ.
07
How to prepare for a programming practical test or exam
Practise in the conditions you'll be tested in. If the practical is closed-book, practise without notes. If there's no internet, switch it off. If the exam asks you to write code on paper, write code on paper, because nothing catches a missing semicolon there. Timed practice from a blank file is the closest thing to the real test you can do at home.
In the test, read the whole brief before you type anything. Note the exact names, inputs and output format it asks for. Then build in small steps: get a basic version that compiles and runs, save it, and add one feature at a time, running as you go. Working code that covers most of the brief usually earns more than ambitious code that won't run.
If one part has you stuck for more than a few minutes, leave a comment saying what you meant to do and move on. Come back at the end with fresh eyes. For theory papers and written exams, my guide on how to study for university exams covers planning, active recall and past papers.
- Memorise the patterns that come up every time: reading input, looping through a list, a class with a constructor
- Practise tracing code by hand and predicting its output
- Test with edge cases before you submit
- Save and run often, so one mistake doesn't cost everything
08
When a tutor helps, and what I won't do
Sometimes one blocked topic is all that stands between you and the rest of the module, and one-on-one help is the fastest way through it. In my programming tutoring sessions, online with screen sharing or in person in Durban, we work in your own code and I ask questions until you find the fix yourself. I guide; I don't write graded work for you. If you're right at the start, coding for beginners begins from zero.
Kayla Reddy (Higher Certificate, Mobile App and Web Development) wrote: "Coming into the Higher Certificate with zero coding background was terrifying. Jorryn broke down the logic in a way that finally made sense to me, and never once made me feel stupid for asking. By the second term I was the one explaining concepts to my group. That shift in confidence was worth every session."
