What Happens Behind the Code?

Rosebella Wandere — Mon, 10 Aug 2026 06:28:43 +0000

Compilers vs. Interpreters: What Really Happens Behind the Code?

As developers, we spend a lot of time writing code, but how often do we stop to think about what actually happens after we write it?

Understanding how computers work behind the scenes is not just theoretical knowledge. It can help us understand why programs behave the way they do, where errors come from, and how to approach debugging more effectively.

Compiler vs. Interpreter

At a high level, both compilers and interpreters help a computer understand and execute the code we write, but they do it differently.

A compiler translates the entire program into machine code before the program is executed.

An interpreter, on the other hand, translates and executes the program as it runs, rather than producing the complete machine-code program beforehand.

A simple way to understand it

Imagine you have a book written in French, but you only understand English.

With a compiler, you would translate the entire book first. Once the translation is finished, you can sit down and read the English version without having to stop and translate every sentence.

With an interpreter, you would translate the book sentence by sentence while reading it. You translate one sentence, read it, then move on to the next sentence.

The first approach requires more preparation upfront, but once the translation is complete, reading can be much faster.

This is a simple analogy for why compiled programs can generally have better execution performance as much of the translation work has already been done before the program runs.

Understanding this distinction has become particularly interesting to me as a go lang beginner.
Go is a compiled language. When I write Go code, the Go compiler translates the source code into machine code that the computer can execute.
For example:
go build main.go
This compiles the Go program and produces an executable file.
I can then run that compiled program without having to translate the source code every time it executes.
Compared with an interpreted language, this gives compiled languages some important advantages:

Faster execution: The translation into machine code happens before execution.
Early error detection: The compiler can catch many errors before the program runs.
Efficient execution: The computer executes compiled machine code directly rather than repeatedly interpreting the source code.
Standalone executables: Go can compile programs into executable binaries that can be distributed and run on compatible systems.

Interpreted languages also have their own advantages, particularly when it comes to flexibility and rapid development. However, because interpretation happens during execution, there can be additional runtime overhead compared with already-compiled code.

Why Does This Matter to Developers?

Understanding concepts such as compilation, interpretation, memory, processes, and execution gives developers a better mental model of what happens between writing code and seeing the result.

This can make debugging easier because instead of treating errors as random problems, we can start reasoning about where and why something went wrong.

Learning to code is not just about learning syntax or memorizing functions.
I am beginning to realize that becoming a better developer also means understanding what happens underneath the code we write.
As I continue learning Go, concepts like compilers and interpreters are helping me connect the code I write with what the computer is actually doing behind the scenes.
And I think that understanding is just as important as knowing how to write the code itself.

Git is Much bigger than I ever Imagined

Rosebella Wandere — Wed, 29 Jul 2026 08:40:07 +0000

Over the past few days, I've been diving deep into Git, and one thing surprised me the most:

Git is much bigger than I thought.

Like many beginners, I used to think Git was mainly about commands like:
git clone
git pull
git push
git branch
git merge
git status

They're important, but they're only scratching the surface.
Working through a comprehensive Git project pushed me beyond the everyday commands. I learned about branching strategies, merge conflicts, rebasing, tags, remotes, bare repositories, reflog and even explored what actually lives inside the .git directory.

One of the biggest eye-openers was exploring the .git folder. Before this project, it was just a hidden directory I never paid attention to. Now I understand it's the heart of every Git repository. It stores commits, trees, blobs, references, configuration, and everything Git needs to track a project's history.

Another fascinating discovery was Git Reflog. I had no idea Git keeps a record of where your branches and HEAD have been, making it possible to recover work that seems "lost." That completely changed how I think about mistakes in Git.

One of my biggest takeaways was realizing how Git enable teams to collaborate efficiently. Understanding merges, rebases, conflict resolution, branch tracking, remotes and shared repositories has given me much greater confidence in contributing to collaborative software projects.

This journey reminded me that learning Git isn't about memorizing a handful of commands. It's about understanding how Git works under the hood and knowing which tool to use for different situations.

I'm still learning, but I can already see how this knowledge will make me a better developer and teammate.