Data structures and algorithms tutoring that starts with the logic, not the syntax

When writing code stops being the hard part

Early programming is mostly syntax: where the brackets go, how a for loop is written. The next step is different. Now you have to decide how to solve a problem before you write anything, and choose how to store the data while you do it. That's what data structures and algorithms, or DSA, are about, and it's where plenty of capable students suddenly feel lost.

The fix isn't more syntax. It's learning to think a problem through on paper first, then turning that thinking into code. That's how I work with you, whether your module uses Java or Python. The ideas are the same in both. Only the spelling changes.

• Programming logic: sequence, selection and repetition, done properly
• Pseudocode and flowcharts, and turning them into working code
• Object-oriented programming: classes, objects, inheritance, encapsulation and polymorphism
• Recursion: base cases, the call stack and tracing calls by hand
• Arrays, lists, stacks, queues and linked lists
• Searching, sorting and Big O notation

Pseudocode, flowcharts and programming logic

Programming logic and design modules ask you to plan an algorithm before you write a line of code, and many students treat pseudocode as a chore. It's actually where the problem solving happens. If you can't write the steps in plain language, the code won't save you, because you'll just be guessing in a different syntax.

Flowcharts help in programming for a similar reason. Drawing a decision as a diamond with two exits forces you to say what happens on both paths, which is where a lot of logic bugs live. We practise by taking a small problem, like checking whether a password meets three rules, and building it as pseudocode, then a flowchart, then real code.

If you're right at the start, in an introduction to programming logic and still finding your feet, have a look at coding for beginners as well. This page picks up once the basics are in place and the concepts get heavier.

How I break down one concept: recursion

Recursion shows how I teach. Most students are shown a factorial function, told it calls itself, and left wondering how that could ever end. So we don't start with code. We start with a set of nested boxes and one question: what is the smallest version of this problem I can answer straight away?

That answer is the base case. Then we trace factorial(3) by hand, writing each call on a new line that waits for the one below it to return. When factorial(1) hands back 1, you watch the answers travel back up: 1, then 2, then 6. Once you've seen the call stack unwind once, recursion stops feeling like magic.

Only then do we write it, and break it on purpose by removing the base case, so you recognise the error when you meet it: a StackOverflowError in Java, a RecursionError in Python. The same pattern of picture first, trace by hand, then code works for linked lists, sorting and inheritance too.

Object-oriented programming without the confusion

Struggling with object-oriented programming is common, mostly because it's taught as vocabulary. Inheritance, encapsulation, polymorphism, abstraction: four words to memorise, and no feel for why anyone would bother. I start with the problem OOP solves instead. Picture a booking system with students, tutors and admins who all share a name and an email but each do different things.

A Person class holds what they share. Student, Tutor and Admin inherit from it and add what's different. Keep the fields private and you have encapsulation. Make Person abstract, so the code only ever creates real students, tutors and admins, and that's abstraction. Give each class its own describe() method, call it on a list of mixed people, and that's polymorphism. Four words, one example you can actually picture.

OOP in Java and OOP in Python look different on the screen. Java spells everything out with access modifiers and types, while Python uses self and naming conventions. Underneath, the ideas are identical, so we practise in whichever language your module uses. Drawing the design as a UML class diagram is easy from there.

Data structures, sorting and Big O, drawn out

Linked lists are where diagrams earn their keep. We draw every node as a box with an arrow to the next one, then insert and delete by redrawing arrows before writing any code. Most linked list bugs are a lost arrow: a node you can no longer reach. Stacks and queues get the same treatment, so last-in-first-out and first-in-first-out mean something real.

For sorting, we sort a handful of numbers by hand with bubble sort, then insertion or selection sort, counting the comparisons as we go. That count is Big O notation in disguise. Once you've felt why comparing every item with every other item grows so fast, O(n²) stops being just a symbol on a slide.

Debugging help, and how sessions work

Debugging is part of every session. When your code breaks, I won't just point at the bug. We read the error message together, print values or trace variables by hand, and narrow it down until you find the problem yourself. The goal is working code and, more than that, a method you can use alone at 11pm before a deadline.

Sessions are usually 60 to 90 minutes, online over video call with screen sharing or in person in the Durban area. Bring the topic, the practical or the code that won't behave. If you want help with a language more broadly rather than one concept, see programming tutoring in Durban.

Why students choose me for this

I started my degree with no coding experience at all, so I learned every one of these concepts from zero, which is exactly why I know how to explain them to someone sitting where I was. I went on to graduate top of a class of 200+ in the IIE Higher Certificate in Mobile Application and Web Development, and I received the Full Stack Impact Award 2025.

Kayla Reddy (Higher Certificate, Mobile App and Web Development) put it like this: “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.”