DEV Community: Walter Hrad

You Understand It. You Just Cannot Build It Yet.

Walter Hrad — Sat, 23 May 2026 11:42:06 +0000

At some point you will understand something completely and still not be able to use it.
This happens more than people admit. You read the documentation. You watch the tutorial. Someone explains it to you and you nod along and you genuinely follow every step. And then you open a blank file and your hands do not know what to do.
This is not a knowledge gap. The knowledge is there. This is something else and I think it matters to name it correctly because if you think it is a knowledge gap you will go read more documentation and that will not help.
The thing that is actually missing is a different kind of familiarity. Not understanding how something works but having used it enough times that your hands remember what to reach for. There is a difference between knowing that useState takes an initial value and returns a pair and actually reaching for useState without thinking when you need reactive state in a component. The first one lives in your head. The second one lives somewhere else, in your fingers maybe, or in whatever part of your brain handles automatic things.
Musicians talk about this. You can understand music theory completely and still not be able to improvise. The theory is in your head but improvisation requires something that bypasses your head. Athletes talk about it too. The gap between understanding a technique and executing it under pressure is not closed by more understanding. It is closed by repetition. A footballer who has studied penalty kicks all week still has to take thousands of them before his body knows what to do when the stadium goes quiet and it actually matters.
Programming culture is weird about this because we treat it as purely intellectual work. If you understand the concept you should be able to apply it. But that is not true and I think a lot of people quietly suffer from believing it. They understand closures but cannot write one without looking it up. They understand recursion but freeze when they need to use it in a real problem. They feel like frauds because the gap between their understanding and their output is visible to them and they think it should not exist.
It should exist. It always exists. For everyone. The only way it closes is by building things, specifically by building things where you do not fully know what you are doing. Not following a tutorial step by step. Not copy-pasting from a project that already works. Actually sitting in front of a blank file and figuring it out slowly, making mistakes, getting stuck, coming back the next day.
The stuck part is important and I want to stay on it for a moment because people treat being stuck as evidence that they are doing the wrong thing. They take it as a signal to go watch another video or find a better explanation. But getting stuck is where the second kind of familiarity forms. When you cannot remember the syntax and you have to look it up for the fourth time, your brain is doing something with that friction. The fifth time will be easier. Not because you read something new but because you went through the process of not knowing and then finding out again. That cycle is doing something that passive reading cannot do.
There is also something that happens when you make a mistake in code you actually wrote versus code you copied. When you copy code and it breaks you troubleshoot the library, the environment, the tutorial. When you write code and it breaks you are forced to understand why, because you cannot blame anyone else. That accountability is uncomfortable but it is also the thing that makes the knowledge stick. You remember the bug you actually caused in a way you will never remember a bug from a tutorial.
I think the reason people avoid this is that getting stuck feels like not knowing. And not knowing feels like failure. So they stay in the tutorial loop where everything works and they always know what to do next and they understand everything perfectly and they cannot build anything on their own. The tutorial loop is comfortable because someone else has already figured out all the places where things could go wrong and smoothed them over before you arrived. Real projects are not like that. Real projects have rough edges everywhere and no one has prepared the path for you.
This is also why side projects that you actually care about are more valuable than exercises you do just to learn. When you care about the thing you are building, you tolerate more confusion. You come back after the third failed attempt because you actually want the thing to exist. That motivation is what gets you through the part of the process where you do not know what you are doing, which is most of the process for most projects.
There is no comfortable path from understanding to building. The discomfort is the path. That probably sounds like something someone would put on a poster but I mean it practically. If you are comfortable, you are probably in a mode that is not building the second kind of familiarity. If you are uncomfortable, you are probably exactly where you need to be. The goal is not to eliminate the discomfort but to develop a tolerance for it, to learn that confusion is a stage and not a verdict.
The move is to build something you do not know how to build yet. Not something slightly outside your comfort zone. Something where you genuinely do not know how to start. Then start anyway and see what happens. Pick something small enough that finishing it is realistic but unfamiliar enough that you will have to figure things out. The specific thing matters less than the act of choosing and starting.
What usually happens is that you figure it out slower than you wanted to, with more mistakes than you expected, and you come out the other side able to do something your hands did not know before. And the next time you sit in front of a blank file it will feel slightly less empty. Not because you learned more. Because you built something once and your body remembers that it survived.
That is the whole game. Understanding gets you started. Building is what finishes it.

Nobody Wants to Read Your Code (And You Don't Want to Read Theirs)

Walter Hrad — Sat, 23 May 2026 11:36:02 +0000

There is a thing that happens when you join a new codebase. You open a file, read maybe fifteen lines, and then you close it. Not because you understood it. Because you stopped wanting to understand it.

I think about this a lot. We talk about clean code, readable code, well-documented code, as if the problem is always on the writing side. But the reading side has its own psychology and almost nobody talks about it honestly.

Reading someone else's code is uncomfortable in a way that is hard to name. It is not just that the logic is unfamiliar. It is that you are stepping inside someone else's head. Their assumptions are baked into every variable name. Their shortcuts make sense only if you know what they were rushing toward. Their weird choice of a for loop where a while loop would feel more natural is probably the result of a bug they fixed at 11pm six months ago and never bothered to refactor. You are not reading code. You are reading a person.

And most of us are not trained for that. We are trained to write, to produce, to ship. Reading feels passive. Reading someone else's bad code feels like losing. Reading someone else's good code feels even worse because then you have to sit with the fact that you would not have done it that way and you are not sure if your way is actually better.

There is also the time problem. When you write code, you have context. You know what the function is for, what came before it, what will come after. When you read, you have to build that context from scratch and the codebase usually does not help you. Comments are either missing or lying. Variable names like data and result and temp are everywhere. The folder structure made sense to the person who created it and to nobody else.

So you do what most people do. You read just enough to do your task. You make your change in the one file you actually understand. You submit your PR and you move on.

The problem is that this pattern compounds. The person after you does the same thing. And the person after them. Over time the codebase becomes a city where everybody knows their own neighborhood and nobody knows the roads in between. When something breaks in the space between neighborhoods, it takes three people and a long afternoon to figure out why.

I do not think the solution is to force people to read more code through code reviews or documentation requirements. Those things help but they do not fix the underlying discomfort. The discomfort is real and it deserves to be taken seriously.

What has actually helped me is reading code the way I read a book I am not enjoying. Not to finish it. Not to extract every piece of information. Just to follow one thread. Pick one function. Understand what it calls. Understand what calls it. Stop there. Do that a few times over a few days and the codebase starts to feel less like a foreign country.

The other thing that helps is accepting that confusion is not a sign of failure. The confusion you feel when you open an unfamiliar file is the same confusion the person who wrote it felt when they started. They just had more time. Time is the only real difference between a file that makes sense and one that does not.

We should probably talk more openly about how hard reading code actually is. Not as a complaint but as an acknowledgment. It is a skill that takes practice and patience in a field that rewards speed. That tension is not going anywhere. Might as well be honest about it.

When "It Works on My Machine" Stops Being Good Enough

Walter Hrad — Tue, 12 May 2026 12:16:43 +0000

There is a version of learning to code where the goal is just to make the thing run. You write it, you test it locally, it does what it is supposed to do, and that feels like the finish line.
For a while, that was me.
ascii-art-web changed that. The project was straightforward on paper — take the ASCII art CLI I had already built and put it behind a Go HTTP server with a browser interface. Same logic, new layer. I figured it would be a lighter week.
It was not.
The standard library in Go handles HTTP cleanly but it does not hide anything from you. Every route has to be defined. Every status code has to be intentional. The audit requirements were specific — 400 for bad input, 404 for missing routes, 500 when the server breaks. Not approximately right. Exactly right. I had written code before that worked in the sense that it produced correct output. This was the first time I had to write code that behaved correctly under conditions I had not planned for.
That is a different skill and I did not fully have it yet.
Getting the frontend and the server to actually talk to each other took more back and forth than I expected. Form data that seemed fine in the browser arriving malformed on the Go side. Routes that I was sure existed returning 404s. Small things that each took longer than they should have to debug because I did not yet have a clean mental model of the full request cycle.
By the end of the week I had something that worked and handled edge cases properly. That felt different from previous weeks. Not just "it runs" but "it holds up."

Then came Docker.
I had heard of Docker the way you hear about things in tech before you understand them — vaguely, as something that matters, without knowing exactly why. The ascii-art-web-dockerize project made the why concrete pretty fast.
The pitch is simple: your app runs the same everywhere because you are packaging not just the code but the environment it needs. A Dockerfile describes that environment. You build an image from it. You run a container from that image. Anywhere that container runs, your app behaves the same way.
In practice the first time you write a Dockerfile for a Go web server there are a few things that will catch you. Getting the build right inside the container. Making sure the port your server listens on is the port you actually expose and map when you run it. These are not hard problems once you understand the model but the model takes a minute to click.
What stuck with me from that week was less the technical detail and more the shift in thinking. Shipping is not the same as building. A lot of people can build something that works. Fewer can package it in a way that works for someone else, on a different machine, without needing to explain anything. That gap is real and Docker is one of the tools that closes it.

If you are learning and you have not touched deployment or containerisation yet — get there sooner than I did. Writing code is one skill. Shipping it is another. Both matter and the second one does not get talked about enough in beginner spaces.

From High School to Hello World: What Nobody Warned Me About

Walter Hrad — Wed, 25 Mar 2026 08:14:31 +0000

I did not plan to end up at a coding apprenticeship. I finished high school and my sister told me about Zone01 Kisumu. I applied. I got in. I showed up on the first day with genuinely no idea what I had signed up for.
That is the honest starting point.

Zone01 does not ease you in. There is no teacher, no syllabus handed to you, no "week one is for beginners." You get a project, a deadline, and a room full of other people who are also confused. The first thing I learned had nothing to do with code — it was that asking for help is not weakness. It is just how the place works.
The language we use is Go. I had never touched it before. Go is not forgiving. It will not compile if you have a variable sitting there unused. It will not let things slide. Early on that felt personal, like the language had decided it did not like me. I would stare at an error for an hour and feel like I was the problem.
There was one project that genuinely broke me. I kept running it, kept getting errors, kept changing things that made it worse. I do not even want to say how long I sat with it. What got me through was not a tutorial, not Stack Overflow — it was another person in the community sitting with me, not giving me the answer, but asking the right questions until I found it myself. That stayed with me more than the project did.
That is the thing about this environment. The people around you matter more than any resource you find online. A good peer will do what no tutorial can — they will watch where you are actually going wrong, not where you think you are going wrong.

Go still frustrates me sometimes. But I respect it in a way I did not expect to. It has made me slower in a good way — I think before I write now instead of just typing and hoping.
If you are just starting out and feeling like everyone else gets it faster than you, they probably do not. They are just not saying it. Find your people inside wherever you are learning. Be honest about what you do not understand. The confusion is not a sign that this is not for you. For most of us it is just what the beginning looks like.