DEV Community: Wassim bd

The Data Structure That Finally Made Recursion Click For Me

Wassim bd — Sun, 02 Aug 2026 04:24:04 +0000

Data structures and algorithms in C++ was probably the course that pushed me the hardest this year. A lot of it clicked eventually, but one topic in particular — linked lists combined with recursion — took me way longer to understand than I expected. Here's what finally made it make sense.

Why linked lists felt harder than arrays

Coming from arrays, linked lists felt unnecessarily complicated at first. With an array, everything is sitting right next to everything else in memory, and you just grab an element by index. A linked list is different: each element (a "node") holds a value and a pointer to the next node. To get to the 5th element, you can't just jump there — you have to walk through the first four nodes to reach it.

struct Node {
    int value;
    Node* next;
};

At first this felt like a downgrade from arrays. Why would I want something slower to access? It took a while to appreciate that linked lists trade fast access for cheap insertion/removal — you don't need to shift a bunch of elements around like you would in an array.

Where recursion comes in

Recursive functions work naturally with linked lists because a linked list is, structurally, a recursive definition: a list is either empty, or it's a node followed by another (smaller) list. That's basically the definition of recursion already baked into the data structure.

Here's a simple example — counting the nodes in a list:

int countNodes(Node* head) {
    if (head == nullptr) {
        return 0; // base case: empty list
    }
    return 1 + countNodes(head->next); // one node + the rest of the list
}

The part that confused me: the call stack

I could write recursive functions like the one above without fully getting why they worked. What clicked for me was visualizing the call stack. Every recursive call to countNodes doesn't run and finish immediately — it pauses, waits for countNodes(head->next) to return a value, and only then adds 1 to it.

So if you have a list A -> B -> C -> nullptr, the calls stack up like this:

countNodes(A) waits on countNodes(B)
  countNodes(B) waits on countNodes(C)
    countNodes(C) waits on countNodes(nullptr)
      countNodes(nullptr) returns 0
    countNodes(C) returns 1 + 0 = 1
  countNodes(B) returns 1 + 1 = 2
countNodes(A) returns 1 + 2 = 3

Once I actually traced through it call by call like that, instead of just trusting that the code "worked," recursion stopped feeling like magic.

Why the base case matters so much

I also learned the hard way (with a stack overflow crash) what happens if you forget the base case, or write it wrong. Without if (head == nullptr) return 0;, the function keeps calling itself forever since there's nothing to stop it. Every recursive function needs a condition that eventually stops the calls — otherwise you're just building an infinitely tall stack until the program crashes.

My takeaway

Linked lists and recursion reinforced each other for me: understanding recursion made linked list operations (counting, searching, reversing) way easier to write, and working through linked lists by hand made recursion finally feel concrete instead of abstract. If recursion still feels like a black box, I'd suggest picking a small linked list problem and literally tracing the call stack on paper, call by call — that's what did it for me.

Final-year software engineering student, writing about what I'm learning in my courses.

What I Learned Writing Assembly After Only Knowing Java and JavaScript

Wassim bd — Sun, 02 Aug 2026 04:22:56 +0000

Before this semester, the lowest-level language I'd written was Java, with some JavaScript on top. Then my computer architecture course threw RISC-V assembly at me, and it completely changed how I think about what's actually happening when my code runs. Here's what stood out to me.

No more "just call a function"

In Java or JavaScript, you write something like:

function add(a, b) {
  return a + b;
}

You don't think about what happens underneath — you just call add(2, 3) and move on. In RISC-V assembly, there's no add() function waiting for you. You work directly with registers (small storage slots inside the CPU) and explicit instructions:

li a0, 2      # load value 2 into register a0
li a1, 3      # load value 3 into register a1
add a0, a0, a1  # a0 = a0 + a1

Every single step is spelled out. There's no hidden machinery doing work for you — you are the machinery, in a sense.

Variables aren't really "variables" anymore

In JavaScript, a variable is a name that holds a value, and you don't worry about where that value physically lives. In assembly, you're constantly aware of where things are: which register holds which value, or where in memory something's stored. You run out of registers fast, so you have to be deliberate about what you keep close (in a register) versus what you push to memory.

This made me appreciate something I never thought about before: every time I write let x = 5; in JavaScript, the language is quietly handling register allocation and memory management for me. In assembly, that's my job.

There's actually a lot more to registers alone than I can fit here — what each one is typically used for, how many you actually get to work with, which ones are "yours" to use freely versus reserved for specific purposes. That's probably worth its own post at some point.

Functions calls are a whole production

Calling a function in a high-level language feels free. In RISC-V, a function call means manually:

Saving the values in registers you care about (so the function you're calling doesn't overwrite them)
Setting up the arguments in specific registers
Jumping to the function's instructions
Making sure the function knows where to return to
Restoring everything once it's back

Seeing this made me understand why function calls have a performance cost — something that's usually invisible in JS or Java, where it just feels instant.

Control flow without if/else

There's no if statement in RISC-V. Instead, you use branch instructions that jump to different parts of the code based on a comparison:

bge a0, a1, label   # if a0 >= a1, jump to "label"

Writing an if/else block or a loop in JavaScript suddenly felt like a small miracle once I saw how many branch instructions and labels it takes to build the same logic manually.

Why this actually helped me as a web dev

I'm not planning to write assembly for my career, but this course changed how I think about high-level code:

I have a much better sense of why certain operations are "cheap" and others are "expensive" — it's less abstract once you've seen the actual instructions behind them.
Debugging feels different now. When something breaks in JavaScript, I have a mental model of what's happening underneath, instead of just treating it as a black box.
I have a lot more respect for what languages like Java and JavaScript are doing for me automatically — memory management, function call overhead, type handling — all of that is work I used to take for granted.

My takeaway

Assembly stripped away every convenience I didn't know I was relying on. It's slower to write and a lot less forgiving, but it made the "magic" of high-level languages a lot less mysterious. If you've only ever worked in high-level languages, I'd genuinely recommend trying even a small assembly exercise — it changes how you read your own code afterward.

Final-year software engineering student, writing about what I'm learning in my courses.

Java References vs Values: The Mistake That Confused Me

Wassim bd — Sun, 02 Aug 2026 04:14:57 +0000

When I started learning object-oriented programming in Java, I hit a wall that I think a lot of beginners hit: I thought I understood how variables worked, until objects entered the picture. Here's the mistake I made and what actually clarified it for me.

The mistake

In Java, primitive types (int, double, boolean, char, etc.) work exactly how you'd expect — when you assign one variable to another, you get a copy.

int a = 5;
int b = a;
b = 10;

System.out.println(a); // 5
System.out.println(b); // 10

Changing b doesn't touch a. Simple enough. But then I ran into this with objects:

class Dog {
    String name;
}

Dog dog1 = new Dog();
dog1.name = "Rex";

Dog dog2 = dog1;
dog2.name = "Max";

System.out.println(dog1.name); // Max ??

I expected dog1.name to still be "Rex", the same way a stayed 5 earlier. But it printed "Max" instead. That's the moment it clicked that objects don't work the same way as primitives.

What's actually happening

With objects, the variable doesn't hold the object itself — it holds a reference (basically an address) pointing to where the object lives in memory. When I wrote Dog dog2 = dog1;, I didn't copy the dog. I copied the address. So dog1 and dog2 were both pointing at the exact same object in memory. Changing dog2.name changed the only Dog object that existed — the one both variables were pointing to.

It's the difference between copying a letter versus copying the address written on an envelope. If you copy the address and someone repaints the house at that address, both copies of the address now point to a freshly painted house — because there was only ever one house.

Why this matters in practice

This isn't just a theory question — it causes real bugs. A common one: passing an object into a method, modifying it inside the method, and being surprised that the original object changed too.

public static void rename(Dog d) {
    d.name = "Buddy";
}

Dog myDog = new Dog();
myDog.name = "Rex";
rename(myDog);

System.out.println(myDog.name); // Buddy

Since myDog is a reference, passing it into rename() passes a copy of the reference, not a copy of the object. Both point to the same Dog, so modifying it inside the method affects the original.

The one exception that confused me more: Strings

Strings in Java are objects too, but they behave a bit differently because they're immutable — once created, a String's content can never change. So this works the way you'd intuitively expect:

String s1 = "hello";
String s2 = s1;
s2 = "world";

System.out.println(s1); // hello
System.out.println(s2); // world

This looks just like the primitive example, but for a different reason: s2 = "world" doesn't modify the existing String — it makes s2 point to a brand new String object entirely, leaving the original one (and s1) untouched.

My takeaway

The rule that finally stuck for me: primitives copy their value, but object variables copy their reference (the address), not the object itself. If two variables point to the same object, changing the object through one variable will show up through the other too — unless the object is immutable, like Strings, in which case "changing" it actually creates a new object instead.

Once I stopped thinking of object variables as "boxes holding values" and started thinking of them as "sticky notes with an address on them," the rest of OOP made a lot more sense.

Final-year software engineering student, writing about what I'm learning in my courses.

Processes vs Threads: What's the Actual Difference?

Wassim bd — Sun, 02 Aug 2026 03:39:44 +0000

In my operating systems course, we spent a good chunk of time on processes and threads. I knew the words before, but I didn't really get the difference until I saw them compared side by side. Here's what I learned.

What's a process?

A process is basically a program that's running. When you open a web browser, a game, or a text editor, the operating system creates a process for it. Each process gets its own chunk of memory, and it's isolated from other processes — one process can't just reach into another process's memory and mess with it.

Think of a process like a separate apartment. It has its own space, its own stuff, and what happens inside doesn't directly affect the apartment next door.

What's a thread?

A thread is a smaller unit of execution that lives inside a process. A single process can have multiple threads, and all of those threads share the same memory space.

Going back to the apartment analogy: if a process is the apartment, threads are like roommates living in it. They share the same fridge, the same living room — they can see and use the same stuff, which is convenient but also means they can accidentally interfere with each other if they're not careful.

The key differences

Memory

Processes have separate, isolated memory.
Threads within the same process share memory.

Communication

Processes need special mechanisms to talk to each other (like pipes or sockets), since they can't directly access each other's memory.
Threads can communicate more easily since they already share memory — but that also means bugs can happen if two threads try to change the same data at the same time.

Cost of creation

Creating a new process is relatively expensive for the OS (new memory space, new resources).
Creating a new thread is cheaper and faster since it reuses the process's existing resources.

Isolation and safety

If a process crashes, it usually doesn't take down other processes.
If a thread crashes badly enough, it can take down the entire process (and all its other threads) with it, since they all share the same space.

A concrete example

A web browser is a good real-world example. Each tab you open is often its own separate process — that's actually why one crashing tab doesn't crash your whole browser. But inside each tab's process, there are multiple threads running at once: one might handle rendering the page, another might handle network requests, another might handle user input. They all share the tab's memory, which is why they can work together so smoothly.

Why this matters (even if you're not doing OS-level programming)

I'm mostly doing web development right now, not systems programming, but understanding this actually helped me make sense of things like:

Why some bugs in concurrent code are so hard to track down (shared memory between threads)
Why spawning a new process is heavier than spawning a new thread or an async task
Why some frameworks talk about "worker threads" or "child processes" differently

My takeaway

Before this course, I used "process" and "thread" almost interchangeably in my head. Now I get that a process is like a container with its own space, and threads are the workers inside that container sharing the same resources. It's a small distinction, but it explains a lot about how modern software actually runs.

If you're learning this too, I'd say the apartment/roommates analogy is what finally made it click for me — hope it helps you too.

Final-year software engineering student, writing about what I'm learning in my courses.

Express vs Django: What I Learned Comparing the Two

Wassim bd — Sun, 02 Aug 2026 00:45:00 +0000

As a software engineering student, I recently had to compare Express and Django for a web development course. Both are popular frameworks for building web apps, but they work pretty differently. Here's what I learned.

What's the difference?

Express is a framework for Node.js (JavaScript). It's very minimal — it doesn't force you to organize your project in a specific way. You basically start with a blank page and add whatever you need (database, authentication, etc.).

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World');
});

app.listen(3000);

Django is a framework for Python. It's the opposite philosophy: it comes with a lot of stuff already built in, like an admin panel, a database system (ORM), and user authentication. You follow its structure instead of building your own.

from django.http import HttpResponse

def hello(request):
    return HttpResponse("Hello World")

Both of these do the exact same thing, but you can already see the difference in approach.

A few things I noticed comparing them

Getting started fast
Django feels quicker for basic apps because so much comes ready to use. The admin panel especially — you get a working interface to manage your data without writing it yourself.

Doing things your own way
Express doesn't tell you how to structure things. That's nice if you want full control, but it also means more decisions to make when you're just starting out (which database? which auth library?).

JavaScript everywhere
If you're already using React or Angular on the frontend, Express lets you stick with JavaScript for the backend too. That felt like a big plus to me since I didn't have to switch mental gears between languages.

Python's ecosystem
Django comes with Python, which is huge if your project ever needs data analysis or machine learning down the line.

Learning curve
As a beginner, I found Django a bit easier to follow at first, just because it tells you where things go (models, views, templates). With Express, you have more freedom, but you also have to make more decisions on your own.

When would you use each one?

From what I've learned so far:

Express seems better for real-time apps (like chat apps), or if your team already works in JavaScript everywhere.
Django seems better if you want to build something fast with less setup, or if your project touches data/ML.

My takeaway

There's no "best" framework overall — it really depends on the project. I'm still learning both, but comparing them like this helped me understand why a team would pick one over the other, instead of just knowing the syntax.

If you're also learning web dev and have thoughts on this, I'd love to hear them in the comments!

Final-year software engineering student at UQAM, writing about what I'm learning in my web development courses.