DEV Community: Anal Jyoti Goswami

The Dirty Secret of Senior Engineers: They Just Got Better at Hiding It

Anal Jyoti Goswami — Wed, 20 May 2026 19:30:53 +0000

When I was a junior developer, I had a theory about senior engineers.

I thought they were a different species.

Not smarter exactly — just wired differently. Like their brain had some extra module installed that mine was still waiting on. They walked into meetings and casually said things like:

“We should probably use a lazy-loaded module federation setup with a shared Angular state layer.”

…with the same energy I use to say:

“I’ll grab coffee.”

No hesitation. No visible effort. Just answers appearing fully formed.

I spent years waiting for my brain to install that module.

It never did.

What I eventually realized was much more uncomfortable:

The module doesn’t exist.

What I was watching wasn’t certainty. It was a performance of certainty — polished over years until it became indistinguishable from the real thing. And like most junior engineers, I was sitting in the audience learning completely wrong lessons about what competence was supposed to feel like internally.

I Didn’t Start as a Developer

My first role wasn’t software engineering.

It was end-to-end business process testing for SAP systems. Procure-to-pay. Order-to-cash. Walking through workflows and figuring out where systems broke, where configurations failed, or where reality diverged from what people thought the software was doing.

It was not glamorous work.

But looking back, it quietly shaped the way I think about systems more than almost anything else in my career.

Because you cannot test what you do not understand.

You have to understand:

the process flow
the data
the edge cases
the integrations
the user behavior
the failure modes

…all at the same time.

Otherwise you miss things.

I never formally became “techno-functional,” but that experience gave me something incredibly valuable early on:

A testing mindset.

The habit of thinking about downstream effects, weird user behavior, integration gaps, and all the places reality quietly diverges from architecture diagrams, requirement documents, and happy-path user flows.

I think that’s part of why I feel technically confident today.

Not because I always know the answer.

But because I learned early that systems only really make sense once you understand how they fail.

At the time though?

Watching senior developers and architects in meetings, I just felt behind.

What Senior Engineering Actually Feels Like

Ten years later, I’m the one in the architecture meetings.

Lead engineer. Fullstack. AI systems. Cloud infrastructure. Distributed systems. DevOps. Product architecture.

And I can tell you honestly:

The performance is still happening.

I just understand it better now.

Picture a typical Tuesday.

We’re designing a platform architecture that will affect deployment decisions, release pipelines, scaling behavior, and operational workflows across multiple teams.

Someone draws boxes and arrows on a whiteboard.

Someone says “event streaming.”

I nod slowly — partly because I’m thinking, partly because I’m buying time.

Inside my head:

Okay, the backend itself is fine. But the event routing for this service mesh is going to become a nightmare:

dead-letter queues,
retry handling,
multiple queues feeding the same service,
eventual consistency issues…

and I haven’t actually implemented this exact combination before.

I really hope nobody asks me about the x-requirement implementation right now.

This is not a crisis.

This is Tuesday.

The Hidden Part of Code Reviews

Then comes the code review.

I open a pull request from a junior developer and see this:

List<UserDTO> result = users.stream()
    .filter(u -> u.getStatus().equals("ACTIVE"))
    .map(u -> new UserDTO(u.getId(), u.getName()))
    .collect(Collectors.toList());

I leave a clean, confident review comment:

“Maybe use Collectors.toUnmodifiableList() here to avoid accidental downstream mutation.”

Professional. Concise. Senior-engineer-like.

What the comment does not show is the actual process that produced it:

// What actually happened:

1. Read the code twice
2. Mentally simulated execution flow
3. Opened documentation again
4. Remembered a production issue from years ago
5. Asked AI whether I was overthinking mutability
6. Still not entirely certain this belongs in the service layer
7. Left comment anyway because it feels directionally correct

The feedback improves the code.

But the process stays invisible.

And that invisibility does damage.

Because someone with two years of experience is reading that review and thinking:

“Senior engineers already know the answers.”

They do not see:

the uncertainty
the memory recall
the docs tabs
the debugging history
the pattern matching
the verification process

They only see confidence.

That creates a very different story.

The Lie Junior Engineers Accidentally Learn

I know this because I was that person.

Fresh out of testing, moving into fullstack development, watching senior engineers move effortlessly between Angular frontends, backend classes, HANA procedures, internal tables, BSP deployments, and debugging sessions like the entire stack was just sitting neatly inside their heads.

Every confident review comment.

Every architecture decision.

Every:

“We should split this into a separate service.”

…felt like evidence that I was behind.

The cross-functional meetings were the worst.

You’re sitting in rooms where half the people speak business and half speak technology, and somehow the senior engineer appears fluent in both.

What you don’t see:

the preparation beforehand
the requirement documents they read the night before
the conversations with product owners
the internal confusion they resolved privately before the meeting started

You only see the final polished version.

There’s actually a name for this phenomenon:

Pluralistic ignorance.

Everyone privately feels uncertain while publicly assuming everyone else is fine.

Engineering culture accidentally amplifies this.

Junior engineers stay quiet because senior engineers seem certain.

Senior engineers stay quiet because they learned that uncertainty should be hidden.

And eventually the silence itself gets mistaken for competence.

The Part Nobody Talks About

The cruelest part is how this gets passed down.

It’s 2021.

A mid-level engineer is staring at a brutal production issue.

A service keeps failing under load for reasons that don’t fully make sense. Memory usage looks normal until suddenly it isn’t. Requests timeout inconsistently. Thread pools behave strangely. Logs are noisy but somehow useless.

This is still pre-AI.

Stack Overflow is basically a religious institution at this point.

So it becomes:

two days of reading logs
reproducing failures in sandbox environments
digging through obscure Stack Overflow posts from 2014
testing theories nobody else can see
slowly narrowing uncertainty until something finally clicks

Then the issue gets fixed.

The sprint moves on.

Nobody talks about the confusion beforehand.

Nobody talks about the dead ends.

Nobody talks about the panic.

That part quietly disappears from the story.

What survives instead is the mythology:

Senior engineers see answers faster
Senior engineers feel less lost
Senior engineers are naturally confident

Five years later, that same engineer becomes the lead.

A junior developer looks at them during another production issue, waiting for some signal that confusion is normal.

But by then the performance has become automatic.

Not because anyone is malicious.

Because nobody ever modeled uncertainty honestly for them either.

What Actually Helps

The funny thing is that fixing this culture does not require massive organizational change.

It requires tiny moments of honesty.

A lead engineer saying:

“I’m not fully convinced this integration approach will scale the way we think it will. Let’s validate it first.”

An architect casually admitting:

“I had to re-read the event routing docs this morning because I forgot how this edge case behaves.”

A code review comment saying:

// Works correctly.
// I'm not entirely convinced this belongs in the service layer though.
// Would like a second opinion.

Tiny things.

But those tiny things change entire team cultures.

Because the biggest thing junior engineers almost never get to see is this:

Senior engineers are not people who stopped feeling lost.

They are people who got better at functioning while lost.

Better at narrowing uncertainty.

Better at pattern recognition.

Better at asking targeted questions.

Better at surviving the moments where they have absolutely no idea what they’re doing.

The confidence was never the skill.

The skill was learning not to panic inside uncertainty.

How the Internet Actually Works: Understanding Client-Server Architecture with Real Code

Anal Jyoti Goswami — Tue, 19 May 2026 19:27:34 +0000

How the Internet Actually Works: Understanding Client-Server Architecture with Real Code

The Big Picture: What Happens When You Visit a Website?

Every time you type a URL into your browser and hit Enter, a surprisingly complex chain of events kicks off in the background. Most people never think about it, but understanding this process is the foundation of everything we'll cover in this guide.

Let's walk through what actually happens when you visit something like https://www.example.com.

Step 1: Your browser looks up the address

Your computer doesn't understand domain names like www.example.com. It needs an IP address, which is basically a numerical home address for a server somewhere in the world. To get it, your browser contacts a DNS (Domain Name System) server, which works like a giant phone book for the internet. It translates the human-friendly name into something like 93.184.216.34.

Step 2: Your browser opens a connection

Now that your browser knows the IP address, it reaches out to that server and says "hey, I'd like to talk." This happens using a protocol called TCP (Transmission Control Protocol), which sets up a reliable back-and-forth channel between your machine and the server.

Step 3: Your browser sends an HTTP request

Once the connection is open, your browser sends a message to the server. That message looks something like this:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

This is a raw HTTP request. It's just text, following a specific format. The GET part means "please give me this resource." The / refers to the homepage.

Step 4: The server sends back a response

The server receives your request, figures out what you want, and sends back a response:

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

<!DOCTYPE html>
<html>
  <body><h1>Hello, World!</h1></body>
</html>

The 200 OK means everything went fine. The server then sends the actual HTML content your browser will display.

Step 5: Your browser renders the page

Your browser reads the HTML, fetches any additional files it needs (like CSS, images, or JavaScript), and paints the final page on your screen.

The whole process typically takes under a second, but it involves your computer, at least one DNS server, and a web server potentially located on the other side of the planet.

This request-and-response cycle is the heartbeat of the web. Everything else we cover in this tutorial builds directly on top of it.

Clients vs. Servers: Who Does What?

Before we write any code, let's get one thing straight: a client and a server are just two computers (or programs) having a conversation. That's it. No magic involved.

Here's the simple breakdown:

The client is the one asking questions. Your web browser is a client. When you type a URL and hit enter, your browser is saying "Hey, can I have that webpage?"
The server is the one answering. It sits around waiting for requests, and when one arrives, it figures out what to send back.

Think of it like ordering food at a restaurant. You're the client, you make a request ("I'll have the burger"), and the kitchen is the server, preparing and sending back exactly what you asked for.

A Client Sends Requests

A request has a few key pieces:

A method (like GET or POST) that says what kind of action you want
A URL that says where you want to do it
Headers that carry extra info (like what kind of data you can accept)
A body (optional) that carries data you're sending along

Here's what a dead-simple client looks like in Python using the requests library:

import requests

response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

print(response.status_code)  # 200 means success
print(response.json())       # The actual data sent back

Run that and you'll see a dictionary of data come back. Your script just acted as a client.

A Server Listens and Responds

The server's job is to:

Listen on a specific port for incoming connections
Read the incoming request
Process it (look up data, run some logic, whatever)
Send back a response with a status code and some data

A status code is just a number that tells the client how things went. You've probably seen 404 before, which means "I couldn't find what you asked for." A 200 means everything went fine.

Here's a quick cheat sheet of the most common ones:

Code	Meaning
200	OK, here's your stuff
201	Created successfully
400	Bad request (you messed up)
404	Not found
500	Server error (they messed up)

Neither side can do the other's job. The client can't serve data, and the server doesn't go out looking for things to do — the client always starts the conversation, and the server always responds. That boundary is also why you can swap out a Spring Boot backend for FastAPI without touching the Angular frontend, as long as the contract — the API — stays the same.

Next up, we'll actually build one of these servers from scratch.

Building a Basic HTTP Server in Python from Zero

Alright, let's get our hands dirty and actually build something. The good news is that Python comes with a built-in HTTP server module, so you don't need to install anything extra to get started.

Open up your terminal and try this one-liner first, just to see the magic happen:

python3 -m http.server 8080

Point your browser to http://localhost:8080 and you'll see a file listing for whatever directory you ran that command in. Cool, right? But that's cheating a little. Let's build one ourselves so you actually understand what's going on.

Create a new file called server.py and paste in this code:

from http.server import HTTPServer, BaseHTTPRequestHandler

class MyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # Send a 200 OK response
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()

        # Write the response body
        message = "<h1>Hello from my server!</h1>"
        self.wfile.write(message.encode("utf-8"))

# Start the server on port 8080
server = HTTPServer(("localhost", 8080), MyHandler)
print("Server running on http://localhost:8080")
server.serve_forever()

Run it with python3 server.py, then visit http://localhost:8080 in your browser. You should see a big "Hello from my server!" heading. You just wrote a web server.

Let's break down what each part does:

BaseHTTPRequestHandler is the class we inherit from. It handles the low-level networking stuff so we don't have to.
do_GET is a method that gets called automatically whenever someone sends a GET request to your server. The name matters here, so don't rename it.
send_response(200) tells the client "everything went fine." That 200 is an HTTP status code.
send_header and end_headers package up the metadata about your response before the actual content.
self.wfile.write() is where you actually send the content back. It needs bytes, which is why we call .encode("utf-8").

Want to serve different content based on the URL? You can check self.path to see what the user requested:

def do_GET(self):
    self.send_response(200)
    self.send_header("Content-type", "text/html")
    self.end_headers()

    if self.path == "/about":
        message = "<h1>About Page</h1>"
    else:
        message = "<h1>Home Page</h1>"

    self.wfile.write(message.encode("utf-8"))

Now visiting /about gives a different response than visiting /. That right there is the core concept behind routing — something every web framework like Flask or Django builds on top of. Worth noting: this raw http.server approach is useful for learning, but in production you'd reach for FastAPI or Spring Boot, where routing, validation, and serialization are handled for you. For now, though, knowing what happens underneath those abstractions is exactly the point.

Press Ctrl+C in your terminal to stop the server when you're done experimenting.

Making Your First API Request: Sending and Receiving Data

Now that you have a server running, let's actually talk to it. This is where things get fun.

An API request is just your code asking another computer for data. Think of it like ordering food at a restaurant: you (the client) tell the waiter (the HTTP request) what you want, and the kitchen (the server) sends it back.

We'll use Python's requests library to do this. If you don't have it yet, install it with:

pip install requests

Fetching Data with a GET Request

A GET request means "give me some data." Here's the simplest possible example:

import requests

response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

print(response.status_code)   # Should print 200
print(response.json())        # Prints the actual data

Run that and you'll see a real JSON response come back. The status_code of 200 means everything went fine. You'll also notice response.json() automatically converts the raw text into a Python dictionary you can work with right away.

Sending Data with a POST Request

A POST request means "here's some data, do something with it." This is how login forms, sign-up pages, and chat apps send information to a server.

import requests

new_post = {
    "title": "My First Post",
    "body": "Hello, internet!",
    "userId": 1
}

response = requests.post(
    "https://jsonplaceholder.typicode.com/posts",
    json=new_post
)

print(response.status_code)   # Should print 201 (Created)
print(response.json())

Notice the status code here is 201 instead of 200. Servers use different codes to tell you what happened:

Code	Meaning
200	OK, here's your data
201	Created successfully
404	Resource not found
500	Server had a problem

Reading the Response

Every response has two important parts:

Headers: metadata about the response (content type, server info, etc.)
Body: the actual data you requested

print(response.headers["Content-Type"])  # Tells you the data format
print(response.text)                     # Raw response as a string
print(response.json())                   # Parsed as a Python dict

One quick tip: always check the status code before trusting the data. A simple habit is:

if response.status_code == 200:
    data = response.json()
    print(data)
else:
    print(f"Something went wrong: {response.status_code}")

That's genuinely all there is to making API requests. You're sending a message over the internet and reading the reply. Everything else is just details built on top of this foundation.

Understanding Stateless vs. Stateful Communication

Here's one of those concepts that trips up a lot of beginners, but once it clicks, everything starts to make more sense.

HTTP is stateless by default. That means every single request your browser sends to a server is treated as a brand new conversation. The server has no memory of you from one request to the next. It's like calling a customer service line where the agent forgets you the moment you hang up, and you have to re-introduce yourself every single time you call back.

Let's make this concrete. Imagine you log into a website. On request #1, you send your username and password. The server checks them and says "yep, that's valid." Now on request #2, you ask to see your profile page. The server has absolutely no idea who you are anymore. Stateless. Clean slate.

# Every request arrives with no memory of previous requests
# The server just sees raw data each time

from http.server import BaseHTTPRequestHandler, HTTPServer

class StatelessHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # The server has zero context about who called before
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Who are you? I have no idea!")

So how do websites actually remember you're logged in? They fake statefulness by passing identity information along with every request. The two most common tricks are:

Cookies - The server sends a small token to your browser after you log in. Your browser then automatically attaches that token to every future request, like wearing a name badge.

Tokens (like JWTs) - Similar idea, but the token itself contains encoded information about who you are, so the server can verify it without even checking a database.

# Simulating stateful behavior by reading a token from headers
class TokenHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        token = self.headers.get("Authorization")

        if token == "Bearer secret-token-123":
            response = b"Welcome back! I recognize your token."
        else:
            response = b"Access denied. Who are you?"

        self.send_response(200)
        self.end_headers()
        self.wfile.write(response)

Notice what happened there. The server itself still has no memory. But because the client sent a token, the server could figure out who was asking. The state lives in the token, not in the server.

This is actually a really smart design. If the server held everyone's session in memory, it would get overwhelmed fast and become nearly impossible to scale. By keeping things stateless and pushing identity into tokens or cookies, you can run dozens of servers and any one of them can handle any request. In practice, this is exactly the pattern you see in Kubernetes-based deployments — pods can be added, removed, or replaced without any of them needing to share session memory, because the client carries its own identity on every call.

The takeaway: stateless does not mean insecure or forgetful from the user's perspective. It just means the client is responsible for proving who they are on every single request.

Common Pitfalls Beginners Make and How to Avoid Them

You've made it this far, which means you're ready to start building real things. But before you do, let's talk about the mistakes that trip up almost every beginner. Learning these now will save you hours of frustration later.

Pitfall #1: Forgetting to Handle Errors in Your Requests

A lot of beginners write code that assumes everything will work perfectly. Spoiler: it won't. Networks fail, servers go down, and URLs get mistyped. Always wrap your requests in error handling:

import requests

try:
    response = requests.get("https://api.example.com/data", timeout=5)
    response.raise_for_status()  # Raises an error for 4xx and 5xx status codes
    print(response.json())
except requests.exceptions.Timeout:
    print("The request timed out. Try again later.")
except requests.exceptions.HTTPError as e:
    print(f"HTTP error occurred: {e}")
except requests.exceptions.ConnectionError:
    print("Could not connect. Check your internet or the URL.")

Notice the timeout=5 parameter too. Without it, your program could hang forever waiting for a response that never comes.

Pitfall #2: Hardcoding Sensitive Data

Never put API keys, passwords, or tokens directly in your code like this:

# BAD - don't do this!
api_key = "my_super_secret_key_12345"

If you push this to GitHub, the whole world can see it. Instead, use environment variables:

import os

api_key = os.environ.get("API_KEY")

Then set the variable in your terminal before running your script:

export API_KEY="my_super_secret_key_12345"

Pitfall #3: Ignoring Status Codes

A request can "succeed" in the sense that it got a response, but that response might be a 404 Not Found or a 500 Internal Server Error. Beginners often skip checking the status code and then wonder why their data looks weird.

Always check response.status_code or use raise_for_status() as shown above.

Pitfall #4: Not Closing Your Server Properly

When you run a local Python server during testing, always stop it with Ctrl + C when you're done. If you just close the terminal window, the port can stay occupied. Then the next time you try to start the server, you'll see something like:

OSError: [Errno 98] Address already in use

You can find and kill the process using:

lsof -i :8080   # Find what's using port 8080
kill -9 <PID>   # Replace <PID> with the process ID shown

Pitfall #5: Assuming JSON is Always the Answer

JSON is super common, but not every API returns it. Some return XML, plain text, or even HTML. Always check the Content-Type header in the response before blindly calling .json(), or you'll get a confusing parse error.

print(response.headers["Content-Type"])

Avoiding these five mistakes puts you way ahead of where most beginners start. Keep them in your back pocket and your debugging sessions will be a lot shorter.

DEV Community: Anal Jyoti Goswami

The Dirty Secret of Senior Engineers: They Just Got Better at Hiding It

I Didn’t Start as a Developer

What Senior Engineering Actually Feels Like

The Hidden Part of Code Reviews

The Lie Junior Engineers Accidentally Learn

The Part Nobody Talks About

What Actually Helps

Tags

How the Internet Actually Works: Understanding Client-Server Architecture with Real Code

How the Internet Actually Works: Understanding Client-Server Architecture with Real Code

The Big Picture: What Happens When You Visit a Website?

Clients vs. Servers: Who Does What?

A Client Sends Requests

A Server Listens and Responds

Building a Basic HTTP Server in Python from Zero

Making Your First API Request: Sending and Receiving Data

Fetching Data with a GET Request

Sending Data with a POST Request

Reading the Response

Understanding Stateless vs. Stateful Communication

Common Pitfalls Beginners Make and How to Avoid Them