DEV Community: Mayan Okul

The Room Where Everyone Except Me Knows What's Happening

Mayan Okul — Mon, 06 Jul 2026 11:36:27 +0000

You know that feeling. You walk into standup, everyone's talking about "the migration," someone says "just check the logs," another person laughs at a joke about Kubernetes, and you're standing there nodding like a bobble-head, understanding zero but performing "yes, this makes total sense to me too."

That was me. Three months into tech, surrounded by people who clearly knew what they were doing, while I was still googling what a "log" even meant in this context (spoiler: not the wood kind).

Here's what I've learned since — mostly by getting it wrong first.

What I tried first, that did not work

Nodding along. I nodded in so many meetings I basically qualified as furniture. Then someone asked me directly what I thought, and I had nothing, because I hadn't actually been listening — I'd been performing understanding. Lesson learned fast: nodding doesn't buy you time, it just delays the moment you get caught.

Using words I didn't fully own. I once said "let's make sure this is scalable" about a feature literally three people would ever use. A senior dev just looked at me. That look taught me more than any course.

Fixing my mess in silence. I broke something once and spent forty-five minutes quietly trying to undo it before anyone noticed, sweating like it was the last day of a deadline. Someone noticed anyway. It's always noticed. I might as well have said something at minute two.

Apologizing for existing. "Sorry, this is probably a stupid question, sorry to bother you" — I said some version of this weekly. Nobody needed the apology. They just needed the question.

What actually started working

Asking the real question, not the safe one. Instead of "I don't get this," I started saying exactly where I got stuck: "when I run this command, the error says module not found, but I've already installed it — here's my package.json." Suddenly people could actually help me, because I'd stopped hiding the specific place I was lost.

Saying "I don't know that word"out loud. The first time I asked "what's a log, actually, just plainly," I expected to be laughed at. Nobody laughed. Someone just explained it in one sentence and we moved on. Turns out most people have a list of things they also once didn't know and quietly figured out — asking just gets you there faster.

Talking about what I broke, immediately. "I broke the build, here's the fix" became my new default sentence. Nobody remembers the bug a week later. Everybody remembers whether you told them or they found out themselves.

**Building small, rough things instead of waiting to feel ready. **I stopped waiting until I "understood enough" and just built stuff — small, rough, sometimes embarrassing. Turns out a finished small project you can explain beats a half-finished big one you're still "planning."

Saying "I don't know, but I'll find out" instead of guessing. This became my favorite sentence in the whole room. Not knowing was never the problem. Guessing wrong and getting caught was.

The actual realization

Everyone in that room once sat exactly where I was sitting — lost, nodding, terrified someone would ask them something direct. They just stopped hiding it faster than I did.

You don't walk into the room already knowing what's happening. You walk in, admit you don't, ask the specific question, own the mess when you make one, and — slowly, without noticing exactly when — you become one of the people who knows what's happening. Somebody else is now the one nodding at the back, hoping nobody asks them anything.

Be kind to that person. You were just them.

HTTP Status Codes Explained with a Resturant Analogy

Mayan Okul — Tue, 30 Jun 2026 10:09:52 +0000

You order food.The kitchen responds.That's literally what HTTP is - and once you get this, servers will never feel mysterious again.

A little backstory

I'm a newcomer to web development, and for the longest time, servers and HTTP felt like some dark magic I wasn't supposed to understand yet. That changed when I started working on my ASCII-ART-WEB project at Zone01.

The project required me to build an actual HTTP server from scratch — handling requests, sending responses, setting the right status codes. Suddenly all of this wasn't theoretical anymore. I had to understand it. And when it clicked, it clicked hard.

This article is me passing that click on to you, using the analogy that finally made it stick.

The internet is a restaurant

Seriously. Every time you type a URL into your browser, you're basically sitting at a table and calling a waiter over.

HTTP stands for HyperText Transfer Protocol. It's just the agreed-upon language that lets your browser and the server talk to each other. Nothing more mysterious than that.

Every page load is a tiny round-trip conversation:

Browser → [HTTP request] → Server → [HTTP response + status code] → Browser renders the page

Step by step:

You type a URL and hit Enter
Your browser sends an HTTP request to the server at that address
The server receives the request and processes it
The server sends back an HTTP response — which includes the data (a webpage, an image, JSON, etc.) and a status code
Your browser reads the status code, then renders the page

That status code is the kitchen's way of telling the waiter how the order went before the food even leaves the counter.

What an HTTP request actually looks like

When your browser asks for a page, it sends something like this under the hood:

GET /menu HTTP/1.1
Host: restaurant.com
Accept: text/html

And the server replies:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3456

<!DOCTYPE html>
...

That 200 at the top? That's the status code. It's the first thing the browser checks.

The four status codes every dev must know

There are over 60 official HTTP status codes, but these four will cover 90% of what you encounter day-to-day.

200 — OK

"The food arrived hot and exactly as ordered."

The happy path. The server found what you asked for, processed everything correctly, and sent it back. This is what you want to see on every request.

400 — Bad Request

"You ordered in a language the kitchen doesn't understand."

This means the request itself was broken — maybe it was missing required data, had invalid formatting, or sent something the server just can't parse. It's a client-side error, meaning the problem is in the request you sent, not the server.

404 — Not Found

"We checked the whole fridge. That dish doesn't exist here."

The server is working fine, but the specific thing you asked for — that URL, that file, that route — simply doesn't exist. Classic example: you mistype a URL, or someone deleted a page that used to exist.

500 — Internal Server Error

"The oven exploded. It's not your fault — something broke inside the kitchen."

The server tried to handle your request but something went wrong in its own code. This is a server-side error. As the user, you did nothing wrong. As the developer, this is where you open your logs and start debugging.

The golden rule of status codes

4xx = The customer's fault
5xx = The kitchen's fault

Memorise this. When you're debugging and you see a 4xx, look at what you're sending. When you see a 5xx, look at what the server is doing with it.

The full status code family tree
Status codes are grouped by their first digit:
1xx-Informational-"Hold on,still cooking.."
2xx-Success-"Here's your food,enjoy"
3xx-Redirection-"Wrong table-they're at table 7 now"
4xx-Client error-"Your order is the problem"
5xx-Server error-"The kitchen is having a moment"

A few other useful ones you'll bump into:

201 Created — used in APIs when something new was successfully created (like a new user account)
301 Moved Permanently — the URL has changed forever, the server redirects you
401 Unauthorized — you need to log in first
403 Forbidden — you're logged in but you're not allowed to access this
422 Unprocessable Entity — the server understood your request but couldn't process it (common in form validation)

How ASCII-ART-WEB helped me understand all of this

When I was working on the ASCII-ART-WEB project at Zone01, I had to build an HTTP server in Go that:

Received a POST request with text from a web form
Converted that text into ASCII art using a banner file
Sent back the result as an HTTP response

At first, I was just copying status codes without understanding them. Then I hit a bug: my server was sending 200 OK even when the input was invalid.

A user would send an empty form — technically a bad request — and my server was responding like everything was fine. That's when the restaurant analogy hit me: if a customer orders nothing, the kitchen shouldn't just send back an empty plate with a smile. It should say "400 — your order doesn't make sense."

Once I fixed that, my server started behaving like a real server.

HTTP is just two sides talking to each other — a customer and a kitchen. Status codes are how the kitchen reports back. Once you stop thinking of them as mysterious numbers and start thinking of them as kitchen updates, the whole web starts making more sense.

If you're working on any project that touches a server — even a small one like ASCII-ART-WEB — I'd genuinely encourage you to try building a basic HTTP handler yourself. Reading about status codes is one thing. Returning the wrong one and watching your app break in a confusing way is what actually teaches you.

Thanks for reading! If you found this helpful or you're also a newcomer grinding through your first server project, drop a comment — I'd love to hear what you're building.Alsoo don't forget to fllow and connect with me on linked in @mayan okul

Status:200 OK.This article:served

Git Will Humble You (And That's Okay) 😭🔥

Mayan Okul — Wed, 17 Jun 2026 06:10:04 +0000

Hey fam

This is my first ever dev article, and yes - I'm nervous.

So real talk — nobody warned me that learning to code would sometimes feel like arguing with a robot that's always right and never explains why you're wrong.

That robot? Git.

If you're a first-time developer, you've probably already had that moment. You type some command with full confidence, hit enter, and then... chaos. Your files are gone. Or duplicated. Or you're somehow on a branch that doesn't exist. Or the classic — you pushed to main when you absolutely should not have.

We've all been there. This post is for you.

What Even IS Git?

Git is a version control system — basically a time machine for your code. It tracks every change you make, lets you collaborate with other developers, and (in theory) saves you from destroying your own project.

The key word there is in theory.

The Commands That Will Ruin Your Day (If You're Not Careful)

git push --force

Oh, this one. This is the "delete everything and ask questions never" command. If you force push to a shared branch without knowing what you're doing, your teammates will find you. Don't do it until you really understand what it does.

git reset --hard

Hard reset sounds powerful because it is. It throws away all your uncommitted changes — no warning, no undo. Ran it once thinking it would fix my mess. It made a bigger mess.

git merge vs git rebase

These two will have you in a full philosophy debate at 2am. Both combine branches. Both will cause merge conflicts that look like ancient hieroglyphics. Learn the difference early — your future self will thank you.

Committing with no message (or a terrible one)

git commit -m "fix" — said every developer who regretted it 3 weeks later. Be descriptive. Always.

Why Mastering Git Early Actually Matters

When you're just starting out, it's easy to think Git is just a way to upload your code to GitHub or Gitea and look productive. But here's the thing — Git is your safety net. The better you understand it:

The less likely you are to lose work
The easier it is to collaborate without chaos
The more confident you look in team settings (yes, employers notice)
The faster you can recover when things break — and they will break

Git isn't just a tool. It's a habit. Build it early.

Resources to Actually Get Good

Here are some solid places to level up your Git, Go, Shell, and Rust game:

Git:

Pro Git Book — free, thorough, the bible
Oh My Git! — learn Git through a game (yes, really)
Learn Git Branching — visual and interactive

Go (Golang):

Go by Example — clean, no fluff

Shell / Bash:

The Linux Command Line by William Shotts — free online

Rust:

The Rust Book — the official one and it's actually great

Now I Wanna Hear From YOU

Drop it in the comments:

What was your first Git disaster?
What's the command that made you question your life choices?
Are you learning Go, Shell, or Rust right now? How's it going?

Let's laugh about it together — because if you're not breaking things, you're not learning.

If this helped you even a little, drop a comment, and let's connect!

Find me on LinkedIn → Mayan Okul — @mayan Okul — come say hi, seriously.

#git #golang #shell #rust #Zone01 #codenewbie #devjourney #programming #firstpost

"Push code, not limits — unless it's a feature branch. Then push everything."
— stay debugging, stay dangerous ⚡

— Mayan, your fav developer__