DEV Community: Mahesh Cheemalapati

Building a Compute Node and Debugging My Assumptions

Mahesh Cheemalapati — Mon, 01 Jun 2026 01:26:27 +0000

A few months ago, if someone had told me I would spend three days trying to install an operating system on a computer the size of my hand, I would have assumed they were exaggerating.

After all, how difficult could it be?

The machine arrived, the SSD was ready, and I already knew where it would fit into my growing homelab. In my head, the process was simple. Install the drive. Flash the operating system. Connect it to the network. Start experimenting.

A single evening seemed more than enough.

Three days later, I had booted multiple operating systems, read more forum posts than I care to admit, learned far more about recovery modes than I ever intended to, and found myself sitting on the floor holding a piece of copper wire while trying to convince a tiny computer to reveal itself.

The strange thing is that none of that was supposed to be the story.

The story was supposed to be about adding another compute node to my homelab.

Instead, it became a story about assumptions.

Because every major problem I encountered over those three days began the same way: with something I was convinced I understood.

And almost every breakthrough arrived immediately after discovering that I didn't.

Curiosity Escalates

A year ago, I wasn't particularly interested in infrastructure.

That probably sounds strange coming from someone who now spends weekends setting up servers for fun, but most of my experience lived much higher in the stack. Applications, APIs, user interfaces, cloud platforms. If something needed to run somewhere, there was usually a service willing to host it and a monthly bill willing to remind me about it.

Then AI arrived.

Like many engineers, I started by experimenting with the models themselves. I generated code, asked questions, explored prompts, and spent time understanding what these systems could do.

What surprised me wasn't the technology.

It was my reaction to it.

The more I used these tools, the less interested I became in the outputs and the more interested I became in the machinery producing them.

Where was the model actually running?

How much hardware did it really need?

Why could one model respond instantly while another struggled?

What happened between a prompt and a response?

Those questions led to more questions.

Before long, I wasn't reading about models anymore. I was reading about GPUs, inference engines, networking, storage, virtualization, self-hosting, and hardware.

Somewhere along the way, curiosity quietly escalated into a homelab.

One machine became two. One project became several. Every answer seemed to create another rabbit hole.

The deeper I went, the more I realized that many of the things I had previously treated as abstractions were only abstractions because someone else had already solved the hard parts.

I wanted to see the hard parts.

Not because I planned to replace cloud services.

Not because I was trying to build a miniature data center in my office.

I simply wanted to understand the systems I was building on top of.

The Jetson entered the picture because it represented an interesting constraint.

I wasn't interested in buying the biggest GPU I could find. That would have answered a different question. What interested me was understanding how much useful work could be extracted from relatively inexpensive hardware.

Could a small, power-efficient device contribute meaningfully to local AI workloads?

Could it become part of a distributed setup?

Could it teach me something about the relationship between software and hardware that I wouldn't learn from a specification sheet?

Those were the questions I thought I was buying the Jetson to answer.

What I didn't realize was that before I could learn anything about AI workloads, the machine was about to teach me something much more fundamental.

Assumption #1: The Hardware Is Broken

The first evening started exactly as expected.

The SSD installation was straightforward. The board powered on immediately. The fan spun to life. A green LED appeared almost instantly.

Everything looked healthy.

There was only one problem.

Nothing could see it.

Windows couldn't detect it. The flashing software couldn't detect it. No matter what I tried, the board remained invisible.

At first, I wasn't particularly worried. Hardware projects always involve a little troubleshooting. I swapped cables, tried different ports, restarted machines, checked drivers, and worked through the usual list of suspects.

But as the hours passed, a theory began to form.

Maybe the board was defective.

It felt like a reasonable conclusion. If a machine refuses to appear, eventually you start questioning the machine itself.

The frustrating part was that the evidence never fully supported the theory. The board looked healthy. It behaved like healthy hardware. It powered on consistently. Yet every attempt to communicate with it ended in failure.

By the end of the night, I hadn't proven that the hardware was broken.

I had simply failed to prove that it wasn't.

At the time, that felt like the same thing.

Assumption #2: The Board Isn't Entering Recovery Mode

The second day began with a clue.

The Jetson needed to be placed into recovery mode before it could be flashed.

That sounded promising.

It also sounded like the answer.

I quickly learned those are not always the same thing.

What followed was several hours spent moving between documentation, diagrams, forum threads, videos, and search results. Every source seemed to assume I already understood the previous step.

Eventually, I discovered that the recovery pins were hidden on the underside of the board.

This led to one of the more absurd moments of the entire project.

At some point that afternoon, I found myself sitting on the floor with a small piece of copper wire, carefully connecting two tiny pins together while applying power to the board.

If anyone had walked into the room at that moment, they probably would have assumed I had abandoned software engineering entirely and started repairing electronics.

To my surprise, it worked.

For the first time, the board appeared.

A small entry in Device Manager confirmed what I had been trying to prove since the previous evening.

The machine was alive.

That moment felt surprisingly significant.

Not because the problem was solved.

Because the problem had changed.

For nearly two days, I had been operating under the assumption that the hardware might be faulty.

Now I had evidence suggesting the opposite.

The board wasn't broken.

The challenge was that I still didn't know what was.

Assumption #3: The Flashing Process Is Broken

Once the board was finally detected, I assumed the difficult part was over.

The next stage of the journey introduced me to an entirely different category of problems.

The hardware had finally started cooperating.

The software had not.

The flashing process became a maze of operating systems, compatibility issues, drivers, tooling requirements, and storage constraints.

Windows behaved one way.

Ubuntu behaved another.

One version of Ubuntu wasn't supported. Another appeared to work until the tooling decided otherwise. A live USB environment introduced storage limitations that I didn't even know existed.

Every apparent breakthrough seemed to reveal another problem hiding behind it.

The experience reminded me of preparing for exams back in school.

You spend hours learning one topic, convinced you're finally making progress, only to discover three more chapters you didn't know existed.

By the end of the second night and well into the third day, I felt like I was debugging multiple systems simultaneously.

The Jetson.

The operating system.

The flashing tools.

The storage environment.

The host machine.

Every layer had its own rules, assumptions, and failure modes.

And yet, something interesting was beginning to emerge.

Each failed attempt wasn't simply a failure.

It was information.

Assumption #4: The Jetson Is The Problem

By the third day, frustration had started to give way to curiosity.

Not because things were working.

Because I had run out of assumptions.

The breakthrough came when I noticed a pattern.

Every successful test pointed in the same direction.

The Jetson entered recovery mode exactly as expected.

The device appeared when connected correctly.

The SSD was visible.

The board responded consistently.

Every time I managed to isolate a variable, the hardware behaved predictably.

The failures were happening somewhere else.

That realization forced me to step back and look at the situation differently.

For almost three days, I had treated the Jetson as the primary suspect.

Yet every successful test kept proving its innocence.

The machine wasn't failing.

The environment around it was.

That subtle shift changed everything.

Instead of asking why the board wasn't working, I started asking which assumptions I was making about the systems surrounding it.

Suddenly, the path forward became much clearer.

The Realization

The final breakthrough wasn't dramatic.

There was no hidden command. No magical setting. No single moment where everything suddenly made sense.

Instead, the solution emerged from a growing pile of lessons.

The correct operating system.

The correct flashing workflow.

The correct storage configuration.

The correct understanding of how the process actually worked.

Once those pieces finally aligned, the installation process became almost disappointingly simple.

After three days of troubleshooting, I expected a triumphant ending.

Instead, the flash completed quietly.

The board rebooted.

Ubuntu loaded.

A login prompt appeared.

That was it.

There was no dramatic conclusion. Just a blinking cursor waiting for input.

Oddly enough, that simple cursor felt more satisfying than it should have.

Not because the installation was complete.

Because understanding had finally caught up with effort.

What I Actually Learned

When I started this project, I thought I was learning how to set up a Jetson.

Looking back, the Jetson was only the setting. The real lesson had very little to do with the hardware itself.

The machine was never the problem.

In fact, the machine spent most of those three days doing exactly what it was supposed to do.

The board wasn't broken.

Recovery mode wasn't broken.

The SSD wasn't broken.

The hardware wasn't conspiring against me.

What slowed me down were the assumptions I carried into the process.

Every troubleshooting session starts with a theory.

Sometimes the theory is right.

Most of the time, it isn't.

Progress comes from testing those theories and being willing to let them go when the evidence points elsewhere.

For nearly three days, reality kept telling me the same thing.

The Jetson was working.

I just wasn't ready to believe it.

When I think back on those three days, I don't remember the commands I ran or the documentation I read.

What I remember is the process.

The constant cycle of forming theories, testing them, discarding them, and starting again.

I remember how often certainty turned into doubt and how often doubt eventually turned into understanding.

The experience reminded me that engineering isn't really about always having the right answers.

It's about learning how to ask better questions.

What changed wasn't the machine.

What changed was my understanding of the system.

By the time the Jetson finally booted successfully, I knew far more about operating systems, flashing workflows, recovery modes, and infrastructure than I had when I started.

Ironically, if everything had worked on the first attempt, I probably would have learned far less.

And in hindsight, that's probably the reason I started building a homelab in the first place.

Not to avoid problems.

To understand how things work.

What's Next

Today, the Jetson sits quietly alongside the other machines in my homelab.

The excitement of getting it online has already faded, replaced by a different kind of curiosity.

The original question that led me to the machine still hasn't been answered.

How much useful work can a small, inexpensive device actually do?

Over the next few weeks, I'll be putting it to work as a dedicated compute node for smaller AI workloads. I want to see how it handles local models, embeddings, retrieval pipelines, and supporting tasks within a larger distributed setup.

Those are the questions that interested me when I bought the hardware in the first place.

The difference is that now I can finally start answering them.

And after three days of getting the machine online, that part feels surprisingly easy.

What Building a Home Server Actually Taught Me About Infrastructure

Mahesh Cheemalapati — Sat, 09 May 2026 04:43:16 +0000

“Infrastructure always felt like this invisible layer beneath software engineering — important enough that everyone depends on it, but abstract enough that most developers never really touch it.”

A few weeks ago, I wanted to deploy my portfolio and a few personal projects, so I started researching hosting options.

Like most developers, I went through the usual rabbit hole.

Cloud providers
Free tiers
VPS comparisons
Deployment tutorials
“Deploy in 5 minutes” videos

At first, everything looked straightforward.

Pick a provider.

Push your code.

Point a domain at it.

Done.

But the more I looked into it, the more I started wondering:

What actually happens underneath all of this?

If I deploy an application to the cloud, where does it really run?

How are servers secured?

How do applications stay online 24/7?

What exactly happens when traffic moves through a VPN?

As developers, we interact with infrastructure constantly, but most of the time we experience it through abstractions.

Cloud dashboards
Managed databases
Deployment platforms
Serverless runtimes

Convenient abstractions make building software easier.

But they also make the underlying systems feel invisible.

And honestly, at some point, the engineer in me got annoyed by how much of modern infrastructure I was using without fully understanding.

Because every large system started somewhere.

At some point:

Google was just servers in a room
Netflix was just an application someone deployed
Infrastructure was still infrastructure before it became “the cloud”

So I started asking myself a different question:

Could I build a small version of this myself?

Not enterprise scale.

Not production-grade infrastructure.

Not something that replaces AWS.

Just enough to actually understand the moving pieces.

That’s when I came across the Raspberry Pi 5.

Why the Raspberry Pi Interested Me

I remembered using Raspberry Pis during my Master’s program for smaller academic projects, but I had never seriously thought of one as an actual server.

The more I researched, though, the more interesting the idea became.

I wanted something small. Something constrained. Something that would force me to understand what I was doing instead of hiding everything behind a dashboard.

A mini PC would probably be more powerful. A cloud VM would probably be easier. But that wasn’t really the point.

I was not trying to build the most powerful server.

I was trying to build something that would teach me how servers actually work.

That’s what made the Raspberry Pi interesting.

It sits in this weird middle ground where it is:

cheap enough to experiment with
powerful enough to run real workloads
constrained enough to force you to learn

You have to think about networking.

You have to think about storage.

You have to think about power.

You have to think about reliability.

You have to think about security.

You don’t just deploy software.

You build the environment the software runs on.

And that changes the learning experience completely.

So I broke the project into phases.

The first goal was simple:

Build a secure home VPN.

Eventually, I want this setup to become a platform for:

hosting personal projects
running Docker containers
AI experiments
self-hosted tooling

But I wanted to start with the fundamentals first.

Because that’s where the real learning happens.

The Hardware Mistake That Immediately Humbled Me

The first lesson came before the server was even fully assembled.

I bought a Kingston NV3 1TB NVMe SSD for the Raspberry Pi M.2 HAT+ because, on paper, everything looked compatible.

It was NVMe.

The Pi supported NVMe.

Problem solved, right?

Wrong.

The SSD physically did not fit.

That’s when I learned something I somehow never paid attention to before:

Not all NVMe drives are physically the same size.

The Raspberry Pi M.2 HAT+ only supports 2230 and 2242 drives.

The Kingston NV3 was 2280.

The drive was literally too long for the board.

It was such a small mistake, but it perfectly introduced me to what infrastructure work actually feels like.

Tiny details matter.

When you work closer to hardware, assumptions become expensive very quickly.

And honestly, I’m glad I made the mistake early because it forced me to slow down and actually read specifications instead of trusting product labels.

Right now, the server is still running from a 64GB microSD card while I search for the correct 2242 SSD.

Ironically, the mistake taught me more than the successful setup probably would have.

“The fastest way to understand infrastructure is to break something you thought would just work.”

The Moment Security Stopped Feeling Theoretical

There’s something psychologically different about exposing a machine to the internet.

The second I enabled remote access, security stopped feeling like a theoretical checklist from tutorials.

This was not just me reading about firewalls anymore.

This was a real Linux machine connected to my actual home network.

That changes your mindset immediately.

Instead of thinking:

“How do I make this work?”

you start thinking:

“How do I make this safe to leave running 24/7?”

That shift ended up changing how I approached the entire project.

I started from a deny-by-default mindset.

Expose as little as possible.

Open only what is necessary.

Reduce the attack surface first.

So the Pi only exposes what it needs for SSH and Tailscale.

Everything else stays closed unless there is a real reason for it to exist publicly.

Then I installed Fail2ban.

Before this project, Fail2ban was something I had maybe heard about but never really understood why people used it.

Now it makes complete sense.

The idea is simple:

If repeated authentication failures happen, the offending IP gets banned automatically.

But what surprised me was not the tool itself.

It was realizing how quickly infrastructure work changes the way you think about systems.

Applications optimize for features.

Infrastructure optimizes for resilience.

That distinction feels obvious in hindsight, but building a server yourself makes you experience it directly.

What a Home VPN Actually Is

Before this project, my understanding of VPNs was mostly shaped by commercial VPN marketing.

Hide your IP
Watch region-locked Netflix
Use public WiFi safely

That was basically my mental model.

But then I started thinking about something more relatable.

Have you ever talked about a trip and suddenly started seeing travel ads everywhere?

Or searched for cookware once and then every website, app, and Amazon notification suddenly thinks you are building a professional kitchen?

It gets annoying.

And while a home VPN does not magically solve all tracking or privacy problems, building one helped me understand what parts of privacy I could actually control myself.

A home VPN is different from a commercial VPN.

Instead of routing traffic through some company’s infrastructure, you route traffic through your own home network.

That means when I am traveling or connected to public WiFi:

my traffic encrypts back to my house
my devices behave like they are home
I control the network path
I can use my own DNS filtering

That realization completely changed how I think about privacy and networking.

You are not buying trust.

You are building it yourself.

And honestly, that was probably the biggest conceptual shift of this project.

The Difference Between “Working” and “Infrastructure”

At first, everything seemed perfect.

Tailscale worked.

The VPN connected.

My Mac connected.

My iPhone connected.

Then I rebooted the Raspberry Pi.

That’s when things broke.

Exit node functionality disappeared
IP forwarding stopped working
Routing behaved inconsistently

And that taught me one of the most important lessons of the entire project:

There is a massive difference between:

“I got this working once”

and:

“this survives reboot reliably forever.”

The fixes themselves were not particularly complicated.

Some sysctl configuration.

Some systemd services.

Some persistent kernel settings.

But the lesson was much bigger than the commands.

Infrastructure is about persistence.

Reliable systems survive:

reboots
failures
unexpected states
power interruptions

That realization honestly felt like crossing a boundary from hobby scripting into actual operational engineering.

“Software runs. Infrastructure stays running.”

What This Project Actually Taught Me

Technically, I learned a lot.

Linux networking
Firewall management
VPN routing
SSH hardening
Service persistence
Infrastructure troubleshooting

But honestly, the deeper lesson had very little to do with individual technologies.

It was about systems thinking.

A lot of software engineering focuses on isolated components.

APIs
Frameworks
Databases
Algorithms

Infrastructure forces you to think differently because suddenly everything becomes interconnected.

Networking affects security.

Persistence affects reliability.

Hardware affects software behavior.

Routing affects user experience.

You stop thinking only in features.

You start thinking in systems.

And honestly, I think that mindset shift is the real reason home labs are so valuable for developers.

Final Thoughts

I originally thought this project would teach me how to run a VPN.

Instead, it taught me how infrastructure behaves.

It taught me why operational reliability matters.

It taught me how networking layers interact.

It taught me why security is about layers instead of tools.

It taught me what self-hosting actually means.

More importantly, it changed my relationship with technology.

Before this project, infrastructure felt abstract.

Now it feels tangible.

I can debug routing problems I barely understood a month ago.

I can trace how different layers interact.

I can see how much engineering exists underneath the simple act of “deploying an app.”

And honestly, that is probably the real value of building a home lab.

Not the server itself.

The understanding you gain from owning the entire stack.

Algorithms vs Architecture: Why LeetCode Alone Doesn’t Prepare Engineers for Real Systems

Mahesh Cheemalapati — Wed, 25 Mar 2026 01:01:30 +0000

"Premature optimization is the root of all evil." — Donald Knuth

Abstract

Coding interview platforms such as LeetCode have become a standard benchmark for evaluating software engineering candidates. They emphasize algorithmic efficiency, data structures, and isolated problem solving. While these skills are important, they represent only a fraction of what software engineers encounter in real-world systems.
Production engineering goes beyond writing correct code — it involves designing, operating, and evolving systems under constraints, failures, and scale. This article explores the gap between algorithmic problem solving and real-world engineering, and why understanding this distinction matters for both aspiring and experienced engineers.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Robert C. Martin

Most engineers encounter these ideas early in their careers.
And then spend hundreds of hours optimizing solutions from  O(n²) → O(n log n).
Because that’s what success looks like on LeetCode.

The World We’re Trained In

In that world, everything is clean.
You are given a problem. 
You are given constraints.
 You are given complete control.

Input → Function → Output

No network. No latency. No failing dependencies. No “it works on my machine.”
Just logic.

And if you’re good really good it builds confidence:
“I can solve hard problems.”

What Actually Happens in the Real World

You ship your first real feature and suddenly, the problem looks different:

At this point, the question is no longer:

“What is the optimal solution?”

It becomes:
Why is this request slow?
Why does this fail only in production?
Why does fixing one issue affect another system?

In interviews, constraints are defined.
 In production, constraints are discovered.

The First Time It Breaks

Most engineers encounter a moment that isn’t covered in any coding platform.

The code works locally.
 You tested it.
 You wrote unit tests.

And yet, in production:

Requests start timing out
Logs don’t match expectations
Another team reports unexpected side effects
Rollback doesn’t fully resolve the issue

At some point, something becomes clear:

The problem was never just the code.

Where the Gap Begins

LeetCode trains you to solve problems in isolation.

Production systems are the opposite they are interconnected, evolving, and often unpredictable.

| LeetCode                                | Production                                   |
| --------------------------------------- | -------------------------------------------- |
| You control the input                   | You discover the input                       |
| System fails only if your code is wrong | System can fail even if your code is correct |
| You debug a function                    | You debug an entire system                   |

This is where the gap begins.

A More Honest Comparison

Interview Model

function solve(input) {
    return output;
}

Reality

function solve(userRequest) {
    try {
        callServiceA();
        callServiceB();
        readCache();
        queryDB();
        handleTimeouts();
        retryFailures();
        logEverything();
    } catch (e) {
        // Often unclear what actually failed
    }
}

The difference is not just complexity, it’s context.

The Nature of Real Problems

In real systems, problems rarely present themselves clearly. They often appear indirectly.

A performance issue might not be a loop problem, it could be:

an extra network call
inefficient data aggregation
duplicated requests
a missing or invalid cache

In one system I worked on, we reduced API traffic significantly; not by changing algorithms, but by identifying redundant calls and improving caching strategies.

The problem wasn’t computational complexity. It was unnecessary work happening across the system.

Similarly, a bug may not be incorrect logic, but:

timing issues
state inconsistencies
race conditions
partial deployments

The challenge is not always complexity. It is often uncertainty.

Architecture as the Real Problem Space

“Architecture is about the important stuff. Whatever that is.” — Martin Fowler

In production systems, the “important stuff” is rarely just the algorithm.

It is:

how services communicate
how failures are handled
how data flows through the system
how changes are introduced safely

An algorithm can be correct, and the system can still fail.
Algorithms optimize functions.  Engineering, in practice, is about optimizing systems.

Where Algorithms Still Matter

Algorithms remain essential.

They appear in systems as:

caching mechanisms
queue processing
ranking logic
dependency resolution

However, they are rarely the source of system-level failures. In interviews, algorithms are the focus. In production, they are one part of a broader system.

The Real Skill Shift

A significant transition in an engineer’s growth is not just:
junior → senior
It is:
problem solver → system thinker
The questions change.
From:
“Is this optimal?”
To:
“What happens if this changes?”

Learning Beyond Isolated Problems

Solving algorithmic problems builds a strong foundation.

But it does not fully prepare engineers for:

debugging production issues
working across distributed systems
understanding latency and failure modes
deploying safely
reasoning under incomplete information

These skills are typically developed through experience. One effective way to build this understanding is to work on systems end-to-end, even on a small scale.

When you build something yourself from API to database to deployment — you begin to encounter challenges that don’t appear in isolated problem solving.

In many enterprise environments, work is distributed across teams and services. While this enables scale, it can limit visibility into the full system lifecycle.

Building independently, even on a small project, helps develop a more complete perspective of how systems behave in practice.

Conclusion

LeetCode is not the problem. It builds discipline, clarity, and problem-solving ability. But it represents a simplified model of software engineering. Real systems are not solved in isolation.
They are:

designed
deployed
observed
debugged and continuously evolved

Understanding this gap is not about rejecting algorithms.

It is about recognizing that:
Writing correct code is only the beginning. 
Building reliable systems is the real challenge.