DEV Community: bramwelM

Building ls in Go, Best Two Weeks So Far

bramwelM — Tue, 07 Jul 2026 13:47:15 +0000

There are projects that teach you a programming language, and then there are projects that teach you how computers actually work. Building my own implementation of the Unix ls command in Go belongs firmly in the second category.

Going into it, I thought I was building a small command-line utility. After all, ls simply lists files in a directory. How difficult could it be?
It turned out to be the most technically challenging project I've worked on so far, and easily the most rewarding. This is why I am writing this article.

The project took my teammate and me two weeks to complete. Surprisingly, nearly half of that time was spent debugging. Every time we solved one issue, three more seemed to emerge. We'd celebrate matching the output of the system's ls, only to notice that a single column had shifted by one space or that a directory had the wrong color. It was frustrating at times, but looking back, those debugging sessions taught me more than writing the initial code ever did.

Complexity

One of the first lessons was that even something as familiar as ls hides an incredible amount of complexity. Supporting flags like -a, -l, and combinations such as -la wasn't just a matter of checking whether a character appeared on the command line. Each flag represented a different behavior, and those behaviors had to work independently while still interacting correctly with one another. Parsing the flags cleanly, deciding what each one enabled, and keeping the implementation maintainable became an exercise in software design rather than simply writing conditionals.

Architecture

As the project grew, we naturally separated responsibilities. One part of the program handled configuration and flags, another dealt with traversing the file system, while another focused entirely on formatting the output. That separation made debugging significantly easier because we could reason about one piece of the program without worrying about everything else breaking at the same time. It reinforced the importance of designing software around clear responsibilities instead of letting everything accumulate inside a single file.

The biggest revelation, however, came from exploring the Unix file system itself. Before this project, I'd heard the phrase "everything in Unix is a file" countless times. I understood it intellectually, but I don't think I truly appreciated it until I spent hours working with directories like /dev, which I now know is where device files are.

I wasn't just looking at regular files and folders anymore. Character devices, block devices, symbolic links, sockets and named pipes all appeared through the same file system interface. The operating system wasn't hiding behind layers of abstraction but rather exposing itself through files. Understanding why /dev/null exists (operating systems and automation scripts frequently need a way to discard unwanted data or simulate a completely empty file), why device files have major and minor numbers, or why symbolic links behave differently from regular files made Unix feel far less mysterious than it had before.

Trying to replicate the behavior of GNU ls introduced an entirely different set of challenges. It wasn't enough for the program to produce similar output. We wanted it to match the system utility as closely as possible. That meant paying attention to details most users never notice. Permissions had to be formatted exactly right. Symbolic links needed to display their targets correctly. Device files had to show major and minor numbers instead of file sizes. Columns had to line up perfectly regardless of file type. Even the tiny + symbol that indicates an Access Control List turned out to be surprisingly difficult because adding a single character without accounting for spacing threw the entire output out of alignment.

Coloring the output became another unexpected rabbit hole. At first, it seemed sufficient to color every directory blue, but that assumption quickly fell apart. Certain directories, such as mqueue and shm, receive entirely different colors because they are sticky, world-writable directories. Learning that even terminal colors follow specific Unix conventions reminded me that mature software rarely contains arbitrary decisions. There is usually a reason hidden beneath every detail.

My Key Takeaway

What made the experience so valuable wasn't simply solving those problems but learning how to approach them. We spent countless hours comparing our output against the system's ls, reading documentation, testing edge cases and questioning every discrepancy instead of accepting "close enough." It was the first project where I truly appreciated that engineering isn't just about making software work. It's about making software behave correctly under conditions you didn't originally think about.

This project also changed the way I think about debugging. I used to see debugging as something standing between me and finishing a project. Now I see it as part of the project itself. Every bug forced us to understand another aspect of the operating system or our own implementation. The solution was rarely to write more code. More often, it was to understand the problem more deeply.

Looking back, I can confidently say this has been my favorite project so far. Not because it was easy, but because it wasn't. It challenged the way I think, exposed gaps in my understanding, and pushed me to learn concepts I probably wouldn't have encountered otherwise. Those are exactly the kinds of problems I hope to keep solving as I continue working towards backend engineering, DevOps and payment infrastructure.

If this project taught me anything, it's that I genuinely enjoy technically demanding work. The more a problem forces me to understand what's happening beneath the surface, the more satisfying it becomes to solve.

The complete project is available on GitHub. Find it here to compare notes.

Django Was Just the Excuse

bramwelM — Sun, 05 Jul 2026 17:50:07 +0000

This weekend I stood in front of a room of developers to give a talk that was advertised as being about backend development with Django.

The funny thing is, I planned on talking about something most beginner backend developers often overlook.

I begun by asking a rather unexpected question: "As an aspiring backend dev, what will you be doing in a real world scenario, what would your typical day in the life look like?" The answers I got was just as I expected, and that right there was what I wanted to bring to light in my talk.

Somewhere along the way, many of us start believing that learning backend development means memorizing a framework. We learn models, views, serializers, authentication, migrations, and enough commands to build an application that works.

But eventually you realize that none of those things answer the questions that actually matter. How do you decide where business logic belongs? What happens when two people try to buy the last item at exactly the same time? What if a payment succeeds but your server crashes before saving the transaction? What if a user keeps clicking the payment button because nothing seems to be happening? Those aren't Django questions. They're backend engineering questions. That's what I wanted my audience to leave with.

Throughout the session, we explored the idea that backend development is really about making decisions. Every endpoint represents a business process. Every database table represents something that exists in the real world. Every bug is usually an assumption you forgot to question.

One idea kept coming back throughout the talk:

*Frameworks help you write software. Thinking helps you build systems.
*
Preparing for the session also taught me something about myself. Building projects is one way to learn. Explaining those projects to other people is another level entirely. It forces you to strip away jargon and ask whether you actually understand the ideas underneath the code.

Walking off that stage, I was happy because the talk went well. I was also happy because it confirmed something I've been working toward over the past year.

I don't just want to write backend software.

I want to understand how great backend systems are designed.

And then help other developers think that way too.

Here's to more code, more architecture diagrams scribbled on whiteboards, and hopefully many more conversations about why the most important question in backend development isn't "How do I build this?" but "What happens when this breaks?"

📝 Slapping It on the Wall: What the Invention of the Sticky Note Taught Me About Coding

bramwelM — Tue, 26 May 2026 19:59:12 +0000

A while back, I stepped away from my IDE and onto a stage at Pint of Science Kisumu. If you aren’t familiar, Pint of Science is a global festival that brings researchers and techies out of their labs and into local spots to talk about their work over a drink. No jargon, no dense slide decks—just raw stories of discovery.

My talk was titled "Sticky Note."

Initially, the audience looked a bit confused. Why is a developer talking about stationery?

But as it turns out, the history of the humble sticky note is the ultimate metaphor for the chaotic, beautiful reality of building software.

The "Failed" Project

In 1968, a scientist named Spencer Silver was trying to develop a super-strong aerospace adhesive. Instead, he ended up with a weak, sensitive glue that could barely hold two pieces of paper together.

The project failed. It was discarded as a failure.

It sat on a shelf for years as a useless mistake. It wasn't until years later that his colleague, Art Fry, frustrated by his bookmarks constantly falling out of his hymnal during choir practice, remembered the "weak glue." He applied it to the paper, and the world’s first Sticky Note was born. Even its iconic canary yellow color was a complete accident—the lab next door just happened to have a stack of yellow scrap paper lying around.

The Illusion of "Seamless" Code
Lately, I’ve been diving deep into logic and system architecture. One major thing I’ve discovered is the massive amount of hidden detail that goes into building any functioning system.

From an outsider’s point of view, a finished application or an elegant script looks seamless. It feels automatic. But as anyone who writes code knows: everything you see is highly intentional.

Behind that smooth user experience is a chaotic trail of:

Fatal errors and broken loops

Hours spent staring at a terminal screen

"Weak glue" solutions that didn't work the way we expected

The real magic of engineering isn't about getting it right on the first try. If it were, none of us would have a job. The magic lies in having the patience to stare at a mistake, slap it on the wall like a sticky note, and look at it from a different angle until we find its true purpose.

Don't Delete the Broken Script
My main takeaway—and my encouragement to the crowd last night—was simple: Do not stop.

When you're working on a feature and the logic completely breaks, or when your data looks incredibly messy, don't just panic and scrap the code. Development is rarely a straight line. It is a process of accidental discoveries disguised as bugs. If we delete our work the moment it goes wrong, we might just be throwing away the foundation of our next big breakthrough.

I am incredibly humbled to say that the audience voted my talk the People’s Choice for the night! 🏆

It was an amazing reminder that whether you are in a high-tech research lab or debugging a local server in Kisumu, we are all just trying to navigate the chaos of creation.

The next time your code crashes or a project falls apart, embrace it. Trust your process, look at the error from a new perspective, and keep pushing forward. Your greatest bug might just be the feature that changes everything.

Have you ever turned a massive coding mistake into a successful feature? Let me know your best "accidental discovery" stories in the comments below! 👇

Confessions of a Git Beginner: Why the Terminal Stopped Scaring Me

bramwelM — Sat, 23 May 2026 12:49:07 +0000

When I started my coding journey, I thought writing code was the hard part. Then I met Git and the command line. At first, it felt like a series of incantations I had to type perfectly into the terminal, or my entire project would vanish. But after breaking a few things and pushing through the confusion, I realized Git isn't just a tool only, it's also a mindset shift.

To be completely honest, the terminal terrified me. It felt like a cold, unforgiving void where typing a single wrong character could accidentally delete my entire project or break my machine. For the first few weeks, running commands felt like shouting magic incantations into the dark and praying everything didn't blow up. But a funny thing happens when you use Git every day: the fear fades, and the mindset changes.

I’m still very much a beginner, but Git has completely changed how I think about building software. Here are the four biggest lessons version control has taught me so far.

1. Making Mistakes is Part of the Process (The Safety Net)
Before I started using Git, writing code felt incredibly high-stakes.

Git completely flipped that script. It taught me that software development, it’s about having a safety net that allows you to fail safely.

Realizing that I can ruthlessly experiment, completely mess up a file, and then simply run a command to discard those changes and reset back to safety was a massive breakthrough. Git didn't just save my code; it gave me the psychological freedom to break things on purpose just to see how they work.

2. The Art of Breaking Things Down
Git forced me to stop, breathe, and think modularly. It taught me to break big problems into micro-steps:

Isolate the feature:
Instead of working on everything in the main branch, I learned to spin up a dedicated feature branch for a single specific task.
Work in tiny increments:
Fix a small bug? Commit it. Format a file? Commit it.
Write meaningful histories:
Wrapping my head around why git commit -m "fixed stuff" is a bad idea made me a better critical thinker. Writing a clear, structured commit message forces you to explain what you changed and why.

It made me look at projects differently. I now view coding as a series of small, manageable stepping stones.

3. Communication & Collaboration
Even if you are working on a solo project, you are never truly coding alone. At the very least, you are collaborating with Future You.

There is nothing quite like looking back at a project you wrote three weeks ago and trying to figure out what your past self was thinking. Git taught me that code isn't just written for computers to execute; it's written for humans to read.

Maintaining a clean Git history, naming branches logically, and writing a solid, detailed README.md file aren't just administrative chores. They are essential communication tools. Git taught me that being a good developer means being a good teammate to whoever reads my repository next—even if that person is just me in a month.

4. Navigating the "oops" Moments

Git will throw errors at you that look like complete gibberish at first. You'll run into an unexpected merge conflict, a permission issue, or a 403 Forbidden error when trying to push to a remote repository.

In my first week, those errors made my stomach drop. I assumed I had broken everything beyond repair.

But navigating those "uh-oh" moments taught me the most valuable lesson of all: senior developers don't have fewer errors; they just have more practice solving them.

I learned to slow down, read the terminal logs closely, check my remote configurations, and realize that every single error is fixable. The terminal isn't an enemy looking to punish your mistakes; it’s just a tool waiting for clear instructions.

Repetition Builds Muscle Memory
If you're a beginner reading this and you still have to look up how to update your branch from main, delete a local branch, or fix a detached HEAD state—that is completely normal.

I still keep a cheatsheet open on my second monitor. The commands don't stick overnight, but the confidence does. Git stopped being a scary obstacle and became the ultimate developer tool. It keeps me organized, gives me permission to make mistakes, and reminds me that every big problem is just a collection of tiny, committable pieces.

If you’re hiding from the terminal, take the leap. Type git init, embrace the errors, and let yourself break things. It's the only way to learn!