DEV Community: Nelvin Ochieng

The Beginner's Dilemma: Too Many Paths in Tech, Not Enough Certainty

Nelvin Ochieng — Mon, 12 Oct 2026 14:06:42 +0000

When I started learning software development, I thought one of the hardest things would be learning how to code.

Understanding variables, loops, functions, debugging errors, and figuring out why something worked on one occasion but failed on another seemed like challenges I would eventually overcome with enough practice.

What I didn't expect was how difficult it would be to decide what to focus on.

There are so many paths in tech. Frontend development, backend development, mobile development, cybersecurity, cloud computing, data science, machine learning, AI engineering, DevOps, and many more.

Every path has its own tools, languages, communities, and success stories.

And if you're a beginner, it can be difficult to look at all these possibilities without wondering whether you're choosing the right one.

Every time I discover something new, I start questioning my direction.

Imagine spending weeks learning backend development. You're writing code, working with databases, fixing bugs, and slowly beginning to understand how things fit together.

Then you come across someone building AI-powered applications.

Their project looks interesting. The possibilities seem endless. You start watching videos about AI engineering, reading about the skills required, and exploring the tools people are using.

Suddenly, you have questions.

Should I be learning AI instead? Is backend development still the right choice? Am I spending too much time on one thing when there are other opportunities I could be exploring?

Before you know it, the thing you were working on no longer feels like the most important thing to learn.

You haven't necessarily lost interest in backend development. You've just discovered something else that looks equally interesting, perhaps even more promising.

And now you're divided between continuing what you started and pursuing something new.

I think this is one of the confusing parts of being a beginner in tech. You don't always have enough experience to know which direction suits you, but you feel pressured to choose one anyway.

The internet makes it harder.

Technology communities can be great places to learn. People share projects, learning resources, career advice, and opportunities that you might never have discovered on your own.

But there is another side to this.

Every day, you can encounter someone learning a new programming language, someone building an AI agent, someone contributing to open source, and someone announcing their first developer job.

It can feel as though everyone is moving forward in a clear direction.

Meanwhile, you're still trying to decide what to learn next.

The problem isn't that these people are doing something wrong. The problem is that constant exposure to other people's progress can make your own journey feel inadequate.

You start measuring your progress against things you haven't done rather than recognizing what you've learned.

You might have spent weeks understanding a difficult concept or completed a project that once seemed impossible. But instead of appreciating that progress, you find yourself thinking about another technology you haven't touched.

There is always another framework, another language, another tool, and another skill you could be learning.

If you measure your progress by how much of tech you've covered, you will almost always feel behind.

Am I exploring, or am I avoiding commitment?

This is a question I've found worth thinking about.

Exploring different areas of technology is not a bad thing. In fact, it can help you discover interests you wouldn't have found by following a single learning path from the beginning.

The problem begins when every new interest makes you abandon your current direction.

You start learning Python, discover JavaScript, and wonder whether you should switch. You begin building web applications, discover machine learning, and start questioning whether web development is worth pursuing.

Each switch introduces new concepts, new tools, and new things to understand.

Eventually, you may know a little about several areas without having developed enough experience in any of them to understand what the actual work involves.

And sometimes, the desire to switch has less to do with genuine interest and more to do with discomfort.

Learning something difficult can make you question whether you're suited for it. Seeing another field where people appear to be doing exciting things offers an easy distraction from the struggle you're currently experiencing.

Of course, not every desire to switch is avoidance. Sometimes you genuinely discover that a different field interests you more.

The challenge is learning to distinguish between the two.

Am I changing direction because I've learned something meaningful about my interests, or because the path I'm on has become difficult?

Those questions deserve different answers.

You don't have to choose your entire future right now.

One thing I'm learning to appreciate is that choosing a direction doesn't have to mean committing to it forever.

You can focus on backend development today and explore AI later. You can learn the fundamentals of web development and eventually discover an interest in data engineering.

Skills also overlap more than they might initially appear to. Programming fundamentals, problem-solving, debugging, databases, and understanding how software works can be useful across different areas.

Your learning isn't necessarily wasted just because your interests change.

However, this doesn't mean you should constantly start over.

There is a difference between changing direction after gaining experience and abandoning a path every time something new catches your attention.

The first can be an informed decision. The second can prevent you from getting far enough to make an informed decision at all.

Instead of trying to identify the perfect career path before you have enough experience, perhaps the better approach is to choose one direction and give yourself time to explore it properly.

Build projects. Solve problems. Read documentation. Experience the frustrating parts, not just the exciting ones.

Pay attention to the work itself.

You might discover that you enjoy it. You might discover that you prefer another area. Either way, you'll be making your next decision with more information than you had before.

Maybe progress is learning to stay curious without constantly starting over.

I don't think the solution to indecisiveness is to stop exploring.

Curiosity is one of the things that makes technology interesting. There will always be something new to discover, and I don't want to lose that excitement.

But I also don't want every new discovery to make me doubt the progress I've already made.

Perhaps the goal is to learn how to be curious without feeling obligated to pursue everything.

I can save an interesting AI project for later without abandoning the backend project I'm working on. I can admire someone's progress in cybersecurity without deciding that I should immediately become a cybersecurity engineer.

I can acknowledge that another path might be interesting without assuming that my current path is wrong.

Most importantly, I can accept that I don't yet know exactly where my journey will lead.

Being a beginner means there is a lot I haven't experienced. It doesn't mean I'm already behind.

I don't need to learn every technology. I need to learn enough to build something meaningful, understand what I'm doing, and keep growing from there.

And perhaps the most important thing is this: I don't have to make the perfect decision today. I just need to make a reasonable decision, give it a genuine effort, and learn from the experience.

There will always be another path to consider.

The question is whether I will spend my time constantly looking for a better direction or give myself the opportunity to discover what I can accomplish in the direction I'm already taking.

For now, I'm learning that it's okay not to have everything figured out.

I'm still learning. I'm still exploring. And I'm trying to remember that progress doesn't require me to know every possible destination before I take the next step.

A question for other beginners in tech:

Have you ever found yourself questioning your learning path after discovering another area of technology? How do you balance exploring new interests with staying consistent enough to develop your skills?

I'd genuinely like to hear how other people are navigating this.

The Bug Wasn't in the Code. It Was in My Assumption.

Nelvin Ochieng — Wed, 07 Oct 2026 13:21:39 +0000

Sometimes you spend an hour looking at a piece of code, convinced that something complicated must be wrong. You check the logic. You check the database. You add print statements. You restart the application. You question your entire career.

Then you discover the problem.

Your assumption was wrong.

Not the algorithm. Not the programming language. Not the framework.

You simply expected something to behave differently from how it actually behaved.

I have started noticing that a lot of debugging is really just this: finding the assumptions hiding inside our code.

We make assumptions all the time

When writing software, we have to make assumptions.

We assume a value will exist.

We assume a user will enter the correct format.

We assume a database query will return a result.

We assume an API will respond successfully.

We assume a file will be where we expect it to be.

We assume something that worked yesterday will still work today.

Most of these assumptions are reasonable. The problem starts when we forget that they are assumptions.

For example, imagine you write:

name := getUserName()

fmt.Println("Hello", name)

You might look at this code and think, "That's fine."

But what happens if getUserName() doesn't find a user?

Maybe it returns an empty string.

Maybe it returns an error.

Maybe it returns a default value.

The code itself might be completely valid. The problem is that you assumed getUserName() would always give you a name.

This is where bugs become interesting.

The code is doing exactly what you told it to do.

You just didn't tell it what to do in every situation.

"It works on my machine"

This is probably one of the most famous sentences in software development.

"It works on my machine."

And sometimes it genuinely does.

You test your application locally. Everything works. You push your changes, someone else runs the project, and suddenly something is broken.

At first, it is tempting to think, "What did they do differently?"

But that question can hide another assumption.

You assumed your environment was the same as theirs.

Maybe you had a different version of Go installed.

Maybe your database already contained some data.

Maybe an environment variable existed on your machine.

Maybe you had a file locally that wasn't committed to Git.

Maybe your application depended on something that you didn't realize was installed.

The code didn't necessarily change.

The environment did.

That is why developers use things like environment variables, dependency management, containers, configuration files, and reproducible builds.

They help reduce the number of things we silently assume.

APIs are another good example

When working with APIs, it is easy to assume that a successful request will always return the response you expect.

You send a request.

You get a response.

Everything is good.

Until the API returns an error.

Or an empty response.

Or a different status code.

Or the service is temporarily unavailable.

Or the request takes longer than expected.

If your application only handles the "everything went perfectly" situation, it might work beautifully during testing and fail when a real user interacts with it.

The important question becomes:

"What else could happen?"

Not because we expect everything to fail, but because reliable software is built around handling the situations we didn't expect.

Databases can expose assumptions too

Databases are another place where assumptions can quietly cause problems.

Suppose you expect a query to return exactly one record.

You write your code around that expectation.

But what if there are no records?

What if there are multiple records?

What if the data is NULL?

What if someone deleted the record between two operations?

Again, the SQL query might be correct.

The problem is the expectation surrounding it.

This is something I have found especially important while working on back-end projects. When you are dealing with users, transactions, and stored data, you cannot simply assume that everything will always be in the state you expect.

You have to check.

Question the assumption

One of the most useful changes in my approach to debugging has been learning to ask simpler questions.

Instead of immediately thinking:

"What complicated thing is breaking?"

I try asking:

"What am I assuming here?"

What value do I think I have?

What value do I actually have?

What do I think this function returns?

What does it actually return?

What happens if the value is empty?

What happens if the request fails?

What happens if the user does something I didn't expect?

What happens if the database doesn't contain the record?

These questions can sometimes solve a problem faster than staring at the same five lines of code for twenty minutes.

The computer isn't always the problem

This is probably one of the biggest things I am learning as I continue building software.

When something breaks, my first instinct used to be to look for something complicated.

Maybe there is a bug in the framework.

Maybe I misunderstood the language.

Maybe the database is doing something strange.

Sometimes that is true.

But sometimes the explanation is much simpler.

I thought a value was one thing, but it was another.

I thought a function was being called, but it wasn't.

I thought the database contained a record, but it didn't.

I thought the request succeeded, but it returned an error.

I thought my code handled a situation, but I had never actually tested that situation.

The code wasn't necessarily "bad."

My understanding of what was happening was incomplete.

And that distinction matters.

Good debugging isn't just fixing code

I used to think debugging was mainly about finding the broken line and changing it.

Now I think it is more about finding the gap between what I believe the program is doing and what the program is actually doing.

That gap is where many bugs live.

Sometimes the solution is one line of code.

Sometimes it is adding an error check.

Sometimes it is changing a database query.

Sometimes it is reading the documentation instead of guessing.

And sometimes the solution is simply realizing:

"Oh. I assumed that."

That might be one of the weirdest parts of programming.

The computer is usually not confused.

We are.

And that's not necessarily a bad thing.

Every wrong assumption is an opportunity to understand the system a little better.

So the next time you spend an hour debugging something that seems ridiculously complicated, try stopping for a moment.

Before rewriting everything, ask yourself:

"What am I assuming is true?"

You might find that the bug was never hiding in the complicated part of the code.

It was hiding in something you thought was obvious.

But It Works on My Machine🤔

Nelvin Ochieng — Tue, 29 Sep 2026 18:00:14 +0000

There is a sentence almost every developer eventually says:

“But it works on my machine.”

You run your application. Everything looks fine. The buttons work, the server starts, the database connects, and you are feeling pretty confident.

Then someone else runs the exact same project.

It breaks.

Suddenly, you are staring at the same code wondering how two computers managed to disagree.

The funny part is that the code might actually be the same.

So what changed?

The code is not the whole environment

When we think about running a program, it is easy to imagine something simple:

Code → Run → Application

In reality, there is a lot happening underneath.

Your application is running inside an environment. That environment includes the operating system, programming language version, installed dependencies, environment variables, file structure, permissions, databases, ports, and other configuration.

So two people can have the same repository but still have different environments.

For example, maybe I am running Go 1.26 while someone else has an older version.

The code hasn't changed.

The environment has.

And sometimes, that's enough to cause a problem.

“But it works here” might mean “my computer has something yours doesn't”

Imagine cloning a project and running it for the first time.

You type:

go run .

It works perfectly.

Your friend does the same thing and gets an error.

One possibility is dependencies.

Your machine may already have certain tools, packages, or configuration available. Their machine might not.

This is one reason projects usually have ways of declaring their dependencies and required versions. The goal is to make the environment less of a mystery.

But dependencies aren't the only problem.

Then there are environment variables

This one can be especially sneaky.

Your application might need something like:

DATABASE_URL
SECRET_KEY
API_KEY

Those values may exist on your machine but not in the repository.

So when you run the application, everything works.

Someone else clones the repository and gets:

“Why can't the application connect to the database?”

Because your computer knows something theirs doesn't.

This is also why configuration and secrets are normally kept separate from the actual source code.

The application isn't necessarily broken.

It just doesn't have the information it expects.

Your database isn't necessarily their database

Here's another classic.

You have been developing locally for weeks.

Your database contains users, groups, test accounts, transactions, and whatever else you've created while testing.

Then someone else runs the project.

Their database is empty.

The application technically works.

It just doesn't behave the same way.

This is an important distinction:

Running the same code does not mean running against the same data.

That can make debugging surprisingly confusing.

“Localhost” is not the same everywhere

There are also smaller differences that can cause surprisingly large problems.

Your application might be running on:

localhost:8080

But what if another application is already using port 8080 on someone else's machine?

The code is fine.

The port is the problem.

File paths can cause similar issues.

A path that works perfectly on Linux may not behave the same way on Windows because operating systems handle paths differently.

Even permissions can get involved.

Your machine might allow an application to read or write a particular file while another machine refuses.

Suddenly:

“But it works on my machine.”

isn't a joke anymore.

It is a clue.

So how do developers make environments more predictable?

The goal isn't to make every computer identical.

That would be difficult.

Instead, developers try to make the important parts of the environment explicit and reproducible.

That can mean documenting the required language version, declaring dependencies, providing configuration examples, using consistent database setup instructions, or using tools such as containers.

This is one reason Docker is so popular.

Instead of telling everyone:

“Install this, then this, then configure that, and hopefully it works…”

you can package much of the application's environment into a container.

It doesn't magically solve every problem, but it reduces the number of differences you have to worry about.

The bigger lesson

One thing I'm learning as I spend more time building software is that writing code is only part of making software work.

The environment around that code matters too.

When something works on one machine but fails on another, the first instinct might be to stare at the code and look for a bug.

Sometimes that's exactly what you should do.

But sometimes the better question is:

“What is different between these two environments?”

Different versions?

Different dependencies?

Different configuration?

Different data?

Different permissions?

Different operating systems?

Once you start asking those questions, the mysterious error becomes a little less mysterious.

So the next time a project refuses to cooperate on another computer, don't immediately blame the code.

Maybe it really isn't the code.

Maybe...

it just works on your machine.

What Really Happens When You Press "Run"?

Nelvin Ochieng — Mon, 17 Aug 2026 12:14:02 +0000

We press Run almost every day, but have you ever wondered what happens behind the scenes?

After attending a conference on Compilers and Interpreters, I learned that our code doesn't go straight to the computer. It first goes through several stages: tokenization, parsing, Abstract Syntax Tree (AST) generation, semantic analysis, and finally compilation or interpretation before it can be executed.

It's amazing to think that what starts as human-readable code is transformed into machine instructions in just a fraction of a second.

As someone still learning software development, this gave me a new appreciation for what happens every time I press Run. Sometimes, understanding what's happening behind the scenes is just as exciting as writing the code itself.

What happens after you press "Run" on your machine?

My First Experience Learning Go During the Piscine

Nelvin Ochieng — Tue, 28 Jul 2026 11:05:43 +0000

I started learning Go out of curiosity and because I wanted to experience a peer-to-peer learning environment. My journey began during the LakeHub Piscine, an intensive one-month coding program where we learned through daily quests, weekly projects, checkpoints, and collaboration with fellow learners.

At first, concepts like variables, loops, functions, and slices were challenging to understand. However, the peer-to-peer learning model made a big difference. Discussing ideas, solving problems together, and learning from one another helped me build confidence and understand Go much better.

After successfully completing the Piscine and joining the cohort, I worked on my first Go project, Go Reloaded. The project reads text from a file, processes embedded text commands, formats the text correctly, and writes the processed output to another file. Completing this project was a rewarding milestone because it allowed me to apply the concepts I had learned during the Piscine to a real-world programming challenge.

Challenges

One of the biggest challenges was learning how to break a large problem into smaller, manageable tasks. Debugging also required patience, as even a small mistake could lead to unexpected results. Understanding the project requirements before writing code was another skill I had to develop.

How I Overcame Them

I overcame these challenges by practicing consistently, carefully reading the project instructions, and asking for help whenever I got stuck. The support from my peers and the habit of testing my code step by step helped me identify mistakes and improve my solutions.

Lessons Learned

This experience taught me that programming is more than writing code. It requires patience, persistence, teamwork, and continuous learning. I also realized that making mistakes is part of the learning process, and every bug I fixed helped me become a better programmer.

Conclusion

The LakeHub Piscine gave me a strong foundation in Go, while the cohort projects have allowed me to put that knowledge into practice. Completing my first Go project has motivated me to keep learning and take on more challenging projects. I'm excited to continue growing as a developer and to share what I learn along the way.