Forem: Karan Prajapati

Lost In Tech? Here's How To Find Path (Without Burning Out)

Karan Prajapati — Thu, 29 May 2025 05:40:49 +0000

If you've ever opened Twitter (x) or Reddit and felt like you're already behind in tech, you're not alone. Everyone's learning Rust, building AI, mastering React, learning Go, and you're just trying to print "Hello World" without breaking your terminal. Even if you've past the "Hello World" phase, the confusion doesn't always go away, and that's okay.

The Problem

Over the last few years tech has evolved and is evolving at a very rapid rate, everyday we see new technologies coming, new solutions being introduced for existing solutions, so a constant change is felt in the field of tech.

Now in order to stay relevant in this field, it is important to keep track of the change in the field and also adapting to the change, which is something good developers do everyday i.e they keep learning new things that are being used in the current times and they keep themselves updated with the change.

But what about someone starting out in the field of tech? It can feel like like stepping onto an F-1 track mid-race and expecting to keep up with the cars. That's the same state of a beginner in this field we want to learn those hot and trendy technologies thinking we will be matching the speed of the overall field. But that is far from the reality.

Even for working professionals and experienced developers, it is often a daunting task to pick something to learn from the tech, thinking whether it is the right investment of their time or not? And that's a valid question.

The Myth of the "One True Path"

The One True Path or Road map is probably one of the biggest mistakes that beginners and even experienced developers make, is to follow what just works for that one guy.

If you will ever try to simply look for some path or road map to become something in the field of tech, maybe a web developer, back-end developer or front-end developer etc. You will see a jargon of guides and road-map by various people from tech coming from different backgrounds and sharing their ideas.

So let's say that a person working in Amazon for the last 5 years, shares a road map for becoming an back-end engineer saying something like,

Java -> Spring Boot -> Database -> System Design

Most people would tend to trust this roadmap simply because it's coming from someone experienced or someone who made it. And that's where the mistake begins.

That is the exact mistake that most of us make, while choosing the right path

Here, it's not that what the person is saying is wrong, it is a completely valid road-map to become a back-end engineer, but the crucial part to understand is the context of the road-map. For every path or learning journey an context is associated with it which simply means,

"Where is it relevant and for who is it relevant?"

Now for a back-end engineer wanting to work in a company might need to work in Java or maybe Python or Node.js, which depends upon the companies technology stack, so based on the context that the company works in Java and Spring boot, this road-map is relevant.

The point is that there is no one right solution or path that solves all the problem, in the field of tech there is no right one solution to any problem, the right solution or path is the one that suites the context of the problem.

What's Hot Might Not Be Right (For You)

Everyday new technology comes in, instantly becoming a hot and trendy technology and also sometimes when a big tech company migrates its existing application's code base to some different programming language or framework, then that language and framework becomes the new normal when creating such applications.

The technologies and frameworks or even any general solutions that get created are there to solve an existing problem or are created for a very specific use case or even provide an improvement over what the existing solutions give, so,

If it is the better solution then shouldn't we learn it?

Not necessarily, as we talked earlier that context is super important to consider when looking at any solution or technology, in the same way here also it is important to understand that what problem does the solution or technology solves and is it relevant to us in any way?

For example, currently AI is the trendy and hot technology in the field, now if you are aiming for becoming a web developer or a back-end developer, where does the skills in AI fit in,

It can be relevant for this context if,
- You want to create a application which needs to use AI, like user personalization or recommendation systems.
- You want to automate things inside the application using AI.
It cannot be relevant for this context if,
- You want to just create applications which don't involve AI involvement like CRUD apps, CRM softwares etc.
- You want to just work on the front-end part, where you don't really need any AI.

So again it falls down to considering the use case or the context of the problem or things you are trying to achieve and based on that you should decide whether you should learn it or not.

Choosing the Right Path (With Purpose)

Okay we understand that now, but how to actually choose? So here are some practical questions that you should ask yourself first,

What do you enjoy: front-end, back-end, systems, AI etc?
Do you want to build things fast or learn deeply?
Do you want a job soon or explore broadly?

This questions will help you filter out choices giving you a broader perspective to what do you really want to do? And often times that is really the main thing we don't really know and mindlessly chase either the currently trending or what everyone is doing, without really considering the motive behind the choice.

As I have kept on emphasizing the word context throughout this blog and the reason is simply because that is the most crucial aspect of choosing the right path and this questions will give you an clear context of what's going on and what needs to be done.

Let's take an example of how can one use this questions to choose their direction,

"Let's say you are a beginner student just starting out in the field of tech and aspire to become a full stack web developer."

So a beginner might answer these questions as following,

Case One:

I aspire to be an full stack web developer then surely I enjoy that
I want to learn deeply as I am student and have time
No currently I am not in a hurry for a job so I would like to explore broadly

Case Two:

I aspire to be an full stack web developer then surely I enjoy that
I want to build things fast.
Yes I am in a hurry because my internship or graduation is near.

Possible Paths for Case One:

Java -> Spring Boot -> Database -> HTML & CSS -> React
Java -> Spring Boot -> Git -> Database -> HTML & CSS -> React -> Docker
Java -> Spring Boot -> Git -> Database -> HTML & CSS -> React -> Docker -> Kubernetes
Java -> Spring Boot -> Git -> Database -> HTML & CSS -> React -> Typescript -> Docker -> Kubernetes -> AWS (or any cloud services platform)

The same path can be used if you want to use python or JavaScript, the idea is the same it just depends on your use case, maybe you want to work in python then you can go with Django instead of Spring boot with Python. So the point is consider your context.

The basic framework for this context is:

(Any programming language with backend support) -> (Backend framework) -> Git (a necessity) -> (Any Database) -> HTML & CSS (fundamental for web development) -> (Any Front-end library or framework) -> (More skills can be added like devops skills and working with widely used cloud services)

Possible Paths for Case Two

Python -> Django -> Database -> HTML & CSS -> React
Node.js -> Database -> HTML & CSS -> React

Here based on the context we are in a hurry so we want to be ready as soon as possible, so we are focusing on the most crucial technologies needed to create websites, now this is a valid choice because it suits the context of the case.

The basic framework for this context is:

(Any familiar programming language) -> (Backend framework) -> (Database for crud operation) -> HTML & CSS (fundamentals) -> (Any front-end library or framework)

Create Your Tech Roadmap (Step-by-Step)

Here are some general guidelines and tips that has helped me personally constantly improve and thrive in the ever evolving field of tech and above of all maintain my sanity.

If you're a beginner,

Focus on the fundamentals, they will pay you way more than learning a trendy technology in the long run.
Focus on one thing at a time, don't jump on multiple things at the same time, it will burn you out.
Start slow and embrace the initial frustration, it will soon make more sense, just give it some time.
Practice is everything, the rule of thumb to stick to is,

Build, Break, Reflect, Iterate

If you're a experienced player,

Identify gaps, not trends. At your level, don't just chase trends. Instead do a tech audit, look for job roles above you.
Revisit the Fundamentals (Yes, Again), with experience, revisiting core concepts (OS, networks, architecture, design patterns) will hit differently.
Build systems, not just features. You should change your perspective from thinking about a single feature to an whole system.
Experiment, but with constraints. Trying something new? Don't commit months, your time is valuable. Choose wisely where to invest it.
The rule of thumb to stick to,

It's not "Where do I start?" but rather "What's worth my time now?"

Final Takeaway

If you've made it this far, thank you really. The tech world can feel loud, confusing and fast-paced, but the fact that you're reading, reflecting and trying to make sense of your path already puts you ahead.

Remember: There's no rush, no perfect path, and definitely no single right answer. You don't have to chase every trend or follow someone else's road-map blindly. What matters most is understand your context, your goals, and moving forward with intention.

Keep learning, keep building, and most importantly enjoy the journey.

If this helped you or gave you something to think about, feel free to share it with someone who's feeling just lost. Let's help each other figure it out.

If you have any questions feel free to ask, I would also love to hear suggestions. Thank you for reading.

"5 Things I Wish I Knew Before I Started Learning C++"

Karan Prajapati — Wed, 28 May 2025 05:38:45 +0000

Learning C++ was one of the most challenging and rewarding parts of my journey as a student. But like many others, I jumped into it without a few key things. That led to countless hours lost to confusing compilation errors (segmentation faults became my old enemy!!) and frustrating debugging sessions.

**Here are the five lessons I wish I had learned earlier.

1. Understanding Pointers Takes Time (And That's okay)

When you're first learning pointers, you're told this classic line:

"A pointer is a variable that stores memory address of another variable".

Sure, sounds simple until the * and & comes into play and makes you rethink you choices.
Try to reference a memory address that doesn't exists.

Here's the deal:

& is the address-of operator, it gives the memory address of a variable.
* is the dereference operator, it lets you access the value stored at a memory address.

Now the tricky part is knowing when to reference and when to dereference. Most pointer-related errors happens because you:

Try to dereference a pointer that points nowhere (nullptr).
Try to reference a memory address that doesn't exists.

The Warehouse Analogy That Helped Me

Think of your computer's memory as a big warehouse.

Variables, objects and data are items on shelves, each with a unique address.
A pointer is like a warehouse worker who doesn't carry the item, they just know where it is.

When you use &, you're asking:

"Hey, what shelf is this item on?"

And when you use *, you're asking:

"What's sitting on this shelf?"

Now imagine asking your warehouse worker to grab something from the shelf that's either empty or doesn't exist anymore. That's exactly what happens when you dereference an invalid pointer, you get undefined behavior, or more commonly, a segmentation fault.

2. The Standard Library Is Your Best Friend

One of the biggest mistakes I made was not understanding and learning the tools that the C++ Standard Library provided. Now we understand std::vector, std::map and maybe even std::set, but there is much more the STL provides, some of them are:

std::multimap, std::multiset, std::unordered_map, std::unordered_set
std::pair, std::tuple
The <algorithm> header which contains various useful functions like, std::sort, std::transform, std::remove etc...

The main reasons to use STL is because the methods it provides are,

Highly optimized.
Very Flexible.
Provides a much cleaner interface.
Saves a lot of time.

Investing time in understanding the different features of the STL, truly will save you a lot of time and energy while working with different problems.

3. Compilation Errors Are a Learning Tool

C++ error messages are known to be notoriously complicated and daunting to read through, especially template errors. But there are actually a lot of things you can learn from those error messages and actually use them to debug the error. It all matters to looking at the right place.

You might be wondering, how can errors even be useful? And that is a valid point, how can something that didn't go or run as expected be good or useful. But the thing is that when our program runs into an error there are couple of benefits to it especially when talking about C++,

They help spot the bug (obviously)
For template errors, they actually allow us to detect the template related errors which are not detected by our code editors given the generic nature of templates.
For segmentation faults, they allow to spot potential leaks which we are luckily able to spot, because segmentation faults are not some fixed patterns, they can happen anywhere if memory is not managed properly somewhere.

In-order to use errors messages, go all the way to the top (at the beginning) of the error message there you will see a clear stack of different files from where error is being evoked and that is really helpful to spot from which file and line did the error actually emerge.

And also some instructions are given for the reasons for why the error is happening which can be really helpful while debugging. If you will also try to read closely you will find some methods where being called internally and they failed, for example when using std::unique_ptr if we try to copy such a std::unique_ptr, then we would get some logs like calling an explicitly deleted constructor, which means we are calling a copy constructor which is not allowed in std::unique_ptr.

So the point is, if your fundamentals are clear about the features you use in C++, the errors will start to make some sense. But still C++ errors are not the most intuitive things to look at, so its okay to feel confused when looking at them.

4. Don't Ignore Memory Management

Coming from languages like Python or JavaScript, one doesn't have to worry much about memory much. But in C++, you have to.

One of the great features of C++ and what makes it so powerful is the immense level control it gives to user over the memory, using which very memory efficient application can created (and are created!), but with that being said we all know that famous line,

With Great Power Comes Great Responsibility.

If you don't manage you memory properly, not only will you waste resources but will introduce memory leaks and tracing and fixing memory leaks is no trivial task.

Here are few ways and good practices to manage memory properly in C++,

Understand RAII (super important!)
Understand stack vs heap memory
Avoid raw pointers wherever possible and use smart pointers.
Use STL containers and methods.
If you using raw pointers make sure to delete that memory when it goes out of scope using the delete keyword.
Don't mix new/delete with malloc/free, they work very differently.

5. You Don't Need to Master Everything At Once.

Trying to learn every feature, template, lambdas, multi-threading, all at once will burn you out. Focus on writing small programs. Use what is required by those programs and slowly build the muscle memory first.

When I was learning C++, I was also tempted to write that advanced level of code, where you use lambdas, templates etc, all the cool stuff that you see in existing C++ code bases for applications. As a result I tried to force myself to use this advanced features in relatively simpler application where a simple solution would be optimal, resulting in over-complicating the relatively simple program.

So here's the thumb rule that I stick to,

"The deeper and complex stuff will make more sense when you need it".

For example, I had this temptation to write such template based function which can be generic and can pass in callbacks (lambdas) and take n number of parameters of different types. And at the beginning I didn't find a place where such an implementation was really required but, when I was working on a multi-threaded application ones, I had to implement my own thread-pool, so there I had to create a function which would take in a callback and that callback can have n number of parameters of different type, and that callback had to be registered to the thread pool.

So the point is that every single features exists for a specific use case and you will know when you need it and you will be required to use it, so rush on using the advanced features where its not needed, in complex projects you will have plenty of opportunities to use them.

Final Thoughts

C++ is hard, but that's also why it's beautiful. It forces you to understand what's happening under the hood. And once things start to click, its incredibly empowering.

If you're just starting out: take it slow, embrace the STL and don't fear error messages, they're teachers in disguise. You're not alone, we've all been confused too.

Now if you read till this point, rest assured because you are well on your way to becoming an C++ addict (like me!!).
Let me know if you're also learning C++, I'd love to hear what you're struggling with or what helped you!