I wasn’t born early enough to live through dial-up drama or the wild west of early forums, but I admire the people who did. They weren’t coding for Twitter followers or placement packages. They weren’t posting “Day 3 of learning code” reels. They were doing it because they were genuinely in love with computers. You can feel it in the old blog posts, in archived forums, even in the janky animations people hacked together with pure CSS before CSS was even supposed to do that.

The Era When Passion Was the Entry Ticket

The biggest thing I admire about that time is how the craft filtered itself. Coding wasn’t glamorous. It wasn’t a badge you wore. It wasn’t even remotely cool.

If you were writing C programs at 2 AM, or tweaking your PHP forum setup, you were doing it for one reason: you wanted to. There was no audience. No reward system. No algorithm pushing your tiny side project to thousands of people. You built things because the act of building things felt magical.

That sincerity is rare today.

Now almost every teenager is calling themselves a “dev,” and half the internet is convinced they’ll become the next Zuckerberg in seven days if they follow the right playlist. Code quality has nosedived in places where the motivation has become shallow. And trends…trends have taken over everything. Dark mode, glass morphism, neumorphism, UI kit after UI kit, people chase aesthetics more than understanding.

The Modern Coding Crowd and Their Answers

Here’s where it gets personal.

Whenever I ask people in my college or friend circle a basic question,
“Why are you pursuing B.Tech or BCA or anything in tech?”
the answers feel copy-pasted from some motivational reel.

“Because money.”
“It’s the future.”
“My uncle said so.”
“My friend is doing it.”

Seriously?

Almost never do I hear the one answer that actually matters:
“I love computers.”

It’s wild. We’re surrounded by people studying the most interesting field in the world, a field built by tinkerers, weirdos, late-night debuggers, people who genuinely enjoyed watching a compiler error disappear, and so many students today don’t even like the thing they spend years studying. They’re treating it like a default career track or a safe bet.

Maybe that’s why modern tech feels crowded but hollow. There are more coders than ever, yet fewer who actually feel connected to the craft.

The Handmade Internet vs Today’s Fast Food Coding

The older internet feels handcrafted because it was. People wrote code with their bare hands, broke their websites weekly, debugged alone, learned slowly and painfully. There was an innocence in it, a willingness to explore without needing applause.

Now things are different. Everything is templated. Everyone wants speed. Everyone wants results. Most tutorials promise “build X in minutes,” and most students follow them without ever asking why something works the way it does.

It’s not that accessibility is bad. More people learning is great. But something important got lost in the rush to make coding mainstream: the depth. The patience. The personal connection.

Maybe I’m Not Missing the Past, Maybe I’m Missing the Mindset

What I’m nostalgic for isn’t really the 90s or 2000s. It’s the culture that era naturally created: people who built out of curiosity, not pressure. The vibe of learning something because it felt powerful, not profitable. The simplicity of exploring computers without the noise of trends and deadlines and spectacle.

Even if I didn’t grow up in that era, I admire what it stood for, and I try to keep some of that spirit alive in how I learn, build, and write code today.

Passion shouldn’t be outdated. Loving computers shouldn’t feel rare. And curiosity shouldn’t be replaced by FOMO.

The old internet may be gone, but the mindset that built it is still worth holding onto.

Two days later: “bro what was that thing again???”

That was my entire life. I’d learn something, feel smart for 5 minutes, then boom brain empty. Developers call it “context switching”, but honestly, it’s just forgetting.

For a long time, I used whatever was in front of me:
Notion because everyone uses it.
Evernote because it sounded fancy.
Google Keep because it’s yellow.
OneNote because it came pre-installed.
Notepad because… well, developers and Notepad have a toxic relationship.

All of them worked… kinda.
But nothing ever stuck. I’d make pretty pages, then never open them again.

Then one day Obsidian came into my life. No big expectations. Just a “let’s try this too” moment.

A year later… it’s still the only note app I actually use. Daily.
Not because it’s perfect . but because it fits how my brain (and probably yours too) works.

Why Obsidian clicked for me

First thing: Markdown.

I didn’t need to fight UI just to make a heading bold. Writing notes feels like writing code. My hands stay on the keyboard. Things are simple. Clean. Fast.

Second thing: My notes are mine.
Not trapped behind a login. Not waiting for the internet. They’re just .md files sitting in a normal folder. I can open them in VS Code if Obsidian disappears tomorrow.

And plugins…
The best part about Obsidian is that it becomes your tool, not the other way around.

I have plugins for:

• Daily notes (my “what the hell happened today?” log)

• Code snippets I always forget

• Tasks so I don’t fail college assignments again

• Excalidraw for dumb little diagrams

• Obsidian Git, which commits my notes to GitHub automatically because I’m lazy

There’s something cool about knowing that even if I delete everything by mistake…
git restore says: not today, buddy.

How I really use it

I wish I could tell you I have a perfect “system” with aesthetic pages and magical workflows.

Reality:
I just dump everything into it. dev notes, college notes, ideas, goals, random rants. and somehow it all makes sense later.

Some days it looks like:

“Types of indexing in databases, future Gautam please learn this fully.”

Some days it’s:

“Fix that weird bug before it explodes in production.”

Some days it’s full life crisis:

“Should I move back to Village?”

Everything lives in one vault.
Not split across 7 apps and 14 brain cells.

The sneaky superpower

You don’t notice Obsidian working at first.
But after a month, you scroll back and see the timeline of your growth:

Things you learned.
Problems you solved.
Ideas you had at 2 AM.
That weird JavaScript behavior you actually understood.

It becomes a real documentation of your developer journey. not lost in thin air.

The more I use it, the less often I have that “I’ve seen this problem before…” moment.
Because now I actually wrote it down.

Final thought

Developers obsess over learning new tech.
But what’s the point if your brain drops it like a memory leak?

Taking notes is underrated.
Obsidian just makes it stupidly easy.

So yeah. this isn’t sponsorship.
This isn’t a productivity cult pitch.

It’s simply the first tool that made me feel like my knowledge wasn’t disappearing every week.

If you give it a try, let it feel messy at first.
Don’t aim for aesthetic pages.
Just start writing.

Your future self. stressed, debugging, sleep-deprived. will be very thankful.

The funniest part? They act like the internet doesn’t exist. Docs? Never heard of them. Stack Overflow? Apparently a myth from ancient times. Even AI is right there, literally begging to help, but somehow the default response is: “bhaiya error aa gaya, dekhlo.” It’s not even about being a hero and solving everything yourself. it’s about respecting the craft. Respecting the people around you. Seniors aren’t Google. They’re not a walking Stack Overflow clone with free time to babysit your missing comma.

I don’t get why some people treat debugging like a personal insult. As if the moment something goes wrong, it’s proof that they suck and someone else needs to come pat their head and fix it. Debugging is half the job. Half of engineering is staring at error messages and slowly negotiating with your own sanity until the code finally behaves. If you avoid that part, you never develop the instincts that make you a real dev.

And the worst part is when they skip the basics. They don’t isolate the issue, don’t try to reproduce it, don’t check what they changed five minutes ago. They don’t even read the error. They just panic. They just want someone else to tell them the answer as fast as possible so they can paste it, pretend they understand it, and move on without learning anything.

Meanwhile seniors have their own fires to put out. They’re juggling deployments, code reviews, deadlines, and their own bugs. and junior devs casually drop in like, “bro, help.” Some juniors are even busy with their own tasks. Time is expensive. Attention is expensive. Running to AI is fine, that costs no one anything. But running to a human for every hiccup? That’s just straight-up disrespectful.

This isn’t about gatekeeping or flexing. It’s about maturity. Writing code is easy. Searching for answers is easy. What takes maturity is the willingness to sit with your mistakes, poke at them, dig into the logs, question your assumptions, and slowly unravel the mess you made. The uncomfortable truth is: if you keep running from the discomfort, you’ll always be stuck at the same level.

Growing as a developer is not some magical jump. It’s built from tiny moments where you choose to think instead of panic, read instead of whine, experiment instead of complain. Debugging is not punishment. Debugging is training. And if you always outsource that part, you’re basically outsourcing your future self.

So yeah, stop behaving childish. Stop treating every error like a dead end. Slow down, breathe, investigate, try things, break things intentionally, learn why things fail. Ask for help when it’s truly needed, not when you’re just feeling lazy or scared. Be a developer, not a notification.

This industry rewards people who can think. Errors are invitations to think. If you keep running from them, you’ll never cross the threshold from junior to actual engineer. Debug with some dignity. That's where the real growth lives.

I’m writing this blog in real-time, which means I’m doing stuff and writing about it simultaneously. Expect chaos, typos, and maybe enlightenment.

Phase 1: The Realization

I was lying on my bed after 5 back-to-back boring college lectures when a thought hit me:

"Why the hell am I still using Windows when I hate it so much?"

A second later, the answer came to me: ASP.
Yes, ASP, as in Active Server Pages. Who the hell is using ASP in 2025???

And not just ASP, my college wants us to use Visual Studio 2010.
(Yeah, not VS Code. I’m talking about the OG Visual Studio. The parent, not the cool child.)

Why specifically 2010? No clue. The college just said so.
So, I can't ditch Windows completely.

But the irony?
One of those 5 lectures is about Linux OS (on Fedora). So we installed Linux on a VM just to learn a few basic commands. Cool, right?

Now I’m thinking: why not install a better Linux distro?

• Fedora? Ah, Hell no. (I want to insert that meme here)

• Kali? Nah, overrated.

• Ubuntu? Feels like Windows with extra steps.

So what’s the final call?

ARCH. Yes, you read that right. ARCH Linux.
In a VM, of course. I’m not that brave (yet).

Phase 2: Setup Vibes

Before diving in, I need music.
Currently vibing to:
🎧 Japanese Lofi: Midnight in Tokyo

I already have the VM ready. Just need the Arch ISO. Let's download it.

Abort mission?
Turns out most cool Arch setups need Hyprland, and that doesn’t work well in a VM.
(At least, that’s what they say.)

Nope. I won’t give up that easily.
Let’s go for pure Arch (no plugins, no fluff).

Free disk space: 20–25 GB available. We’re good.

Also... changing the music. That lofi got annoying.
Now listening to my personal playlist (no, I won’t share. Yes, I’m gatekeeping like a true Gen Z).

It’s happening! Download in progress...

And now… booting Arch into the VM.

Stuck at 35%...
Then BOOM! It started.
It’s 4 PM. I want chai. But I’m way too hyped to leave.

I’m acting like a child on Christmas morning. What’s happening to me?

Installing Arch (for real)

Reading the official Arch guide.

Set up keyboard layout:

localectl list-keymaps loadkeys setfont

Check network:

ip link

Weird output, but I’m pretending it's 2013, no AI, no help. Just me and the internet.

WiFi setup: iwctl

Interface seems blocked, so: rfkill unblock wlan

Eh, leaving the network setup for now.
(BTW, listening to underrated Indian rapper GhAatak, banger.)

Wait... am I already connected to the internet??

Set timezone:

timedatectl

It picked UTC+0000
Hello?? I’m from India, not the UK.

Partitioning time:

lsblk cfdisk /dev/sda

MAYBE?????? What do you mean???

I did the partition anyway.

Formatting:

mkfs.fat -F32 /dev/sda1 mkfs.ext4 /dev/sda2

Mounting:

mount /dev/sda2 /mnt mkdir -p /mnt/boot/efi mount /dev/sda1 /mnt/boot/efi

Whew. Now for the big one:

pacstrap /mnt base linux linux-firmware vim nano networkmanager

Hacker mode: ON

4:43 PM. I need chai.
Let’s make it while the system installs.

Done!

Phase 3: Final Setup

Generate fstab:

genfstab -U /mnt >> /mnt/etc/fstab cat /mnt/etc/fstab

Chroot into the system:

arch-chroot /mnt

Fix timezone:

ln -sf /usr/share/zoneinfo/Asia/Kolkata /etc/localtime hwclock --systohc

Locale setup:

nano /etc/locale.gen locale-gen echo "LANG=en_US.UTF-8" > /etc/locale.conf

Hostname & password:

echo my-arch-vm > /etc/hostname nano /etc/hosts

Add this:

127.0.0.1 localhost ::1 localhost 127.0.1.1 my-arch-vm.localdomain my-arch-vm

Set root password:

passwd

Install GRUB bootloader:

pacman -S grub efibootmgr dosfstools os-prober mtools grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB --removable grub-mkconfig -o /boot/grub/grub.cfg

Enable network manager:

systemctl enable NetworkManager exit umount -R /mnt reboot

Boom. We’re Done!

I know, I know… there’s still GUI, Hyprland, theming, all that fancy stuff left.

But you know what?

I installed Arch in one go.

Mic drop.

But at some point, it stopped working. I’d write and design so much that I ended up doing nothing. I'd plan an entire project’s structure, route files, database schema, and then never build it. I wasn’t shipping. I wasn’t learning. I was just stuck in this cycle of “feeling productive” while making zero real progress.

That’s when I did something that felt weird at first: I grabbed an old notebook and started writing stuff down.

No templates. No colors. No UI. Just raw, messy, handwritten thoughts. And for the first time in a while, I felt like I was actually thinking again.

From Fake Productivity to Real Clarity

When you plan digitally, everything is optimized for speed. You can drag things around, delete without friction, redo your whole layout in 2 minutes. That’s powerful, but also dangerous. Because when something is too easy to edit, you stop thinking before you write. You start mindlessly creating diagrams and checklists, without ever really questioning if they’re needed.

With a notebook, I have to pause. I have to think before drawing a line, because I can’t just hit undo. I find myself asking, “Is this even worth writing down?” And that small moment of hesitation actually helps. It forces me to be intentional.

Now, I use pen and paper to plan almost everything, app architecture, blog outlines, API flows, complex logic, even high-level product ideas. And sure, the pages look ugly. There are arrows going everywhere, notes squeezed into corners, crossed-out boxes, random thoughts in the margins. But for me, that chaos works. It mirrors how my brain works. I can actually see the connections. I don’t feel overwhelmed by structure. I feel free to think.

It’s not about making it look pretty. It’s about making it make sense.

One Page That Saved Me Days of Headache

There was this one project, a website I was about to launch. I'd been working on it for weeks, all planned digitally like usual. But just before shipping, I decided to draw out the entire architecture on paper, just for fun.

That’s when I spotted it: a major issue in how I was structuring the backend and handling user sessions. Something that could’ve broken the app under load. I had completely missed it while designing it digitally. But on paper? It jumped out at me in seconds.

That moment hit me hard.

It made me realize how often I’d been rushing through planning without really thinking things through. Just dragging and dropping components in Excalidraw doesn’t mean you understand your own system. Sometimes, your brain needs a slower pace to catch up with your ideas. And pen and paper force you to slow down.

Not Old-School — Just Underestimated

People say pen and paper is outdated. But I think it’s just underrated. In a world where we have tools for literally everything, diagrams, roadmaps, AI-generated code, the act of slowing down to think is rare. And valuable.

I’m not anti-digital. I still use Notion sometimes to organize things I’ve already processed. But that first draft? That raw idea phase? I always do it on paper now. No pressure to make it look clean. No distractions. Just me and my thoughts.

And I don’t digitize it later either. My notebook isn’t a system. It’s a sandbox. I write things down, think them through, and move forward. That’s it.

Final Thought

If you’ve ever felt stuck, like you’re planning too much and building too little, try unplugging. Close your tabs. Stop fiddling with your workflow. Pick up a ₹40 notebook and just start scribbling.

It won’t look nice. It won’t sync to the cloud.
But you might finally hear your own thoughts again.

And honestly? That’s all you need to get started.

“What’s next? How do I become a better developer?”

You're not a rookie anymore. But you're not an expert either. You're in that in-between phase — and trust me, it’s a good place to be. This is where real growth begins.

In this blog, I’m sharing what worked for me during this exact stage.
No “ultimate roadmap” or “industry best practices.”
Just real, messy, personal experience — maybe it helps you, maybe it doesn’t.

Stop Building Alone All the Time

If there’s one thing I wish I had done earlier, it’s this:
Start building with other developers.

The solo dev grind teaches you a lot, but after a point, it becomes a comfort zone. When you work on a project with other programmers, it pushes you in ways no tutorial ever will.

I like this quote a lot:

“If you’re the smartest person in the room, you’re in the wrong room.”

I’d actually go a step further:
Sometimes, be the smartest. Sometimes, be the dumbest.

When you're the best dev in the team, you get to lead. You review code, set structure, answer questions, make architectural decisions. You’re not just writing code — you’re shaping the project. And you grow by teaching others and taking ownership.

When you're the least experienced, that’s a whole different level of learning. You watch how senior devs think, how they debug, how they name variables, how they split files. You absorb everything — even the things they don’t do.

Also, let's be honest — when you're the least experienced, there’s no external responsibility... but the internal pressure is real. You want to keep up. You don’t want to be “the one who’s slowing it down.” That pressure? It pushes you.

Don’t Just Write Code — Read It

This is something nobody tells you early on.

When you’ve written enough code to feel comfortable, start reading other people’s code. Explore open-source repos. Skim through popular GitHub projects. Pick a library you use, and peek inside it.

Look at how things are structured. Look at how they handle edge cases. Try to understand a file without reading the comments first. You’ll start seeing patterns. Clean code isn’t just about writing — it’s about recognizing.

Refactor to Learn, Not Just to “Fix”

Sometimes I take old code — mine or someone else’s — and just try to improve it. Rename variables, break down functions, clean up conditionals. Not because it’s broken, but because I want to make it better.

That habit alone taught me how to think like a senior developer. It made me ask:
“Would I want to maintain this code six months from now?”

Don’t Obsess Over Perfect Roadmaps

It’s easy to get stuck looking for “what’s next” instead of actually doing it. The internet is full of roadmaps, and they’re great — but don’t let them paralyze you.

Instead, try this mindset:

• Learn just enough to build what you’re thinking about.

• Struggle a little, then go read docs or blogs.

• Build ugly first, then refactor once you know better.

Growth doesn’t look clean. It’s messy. But that’s how you improve.

Final Thought

You're past the basics. You want to get better. That’s a great place to be.

Here’s what helped me the most in this phase:

• Work on projects with others. Don’t always be the best — or the worst.

• Read good code. Not just write it.

• Refactor like it’s your job.

• Keep building. Even when it feels like you don’t know enough.

“You don’t level up by being ready. You level up by doing things you’re not ready for — yet.”

Again — this is just my take. This worked for me.
I’m still learning, still messing up, still trying to become better.

Maybe this helps you take that next step. Maybe it doesn’t.
But if you’re stuck in that “I know some stuff, now what?” stage…

This is what I’d tell you:
Find a team. Break something. Fix it. Repeat.

“Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.”

Read it again. Slowly.

It’s the kind of quote you scroll past until one day it slaps you in the face because it’s talking about you. And in my case? It hit like a truck.

Because that’s exactly what happened.

When I stepped into this field, I genuinely believed the key to becoming a good developer was sitting in my syllabus. That if I paid attention in class, revised DBMS notes, understood the difference between primary and foreign keys, and could draw all the layers of the OSI model from memory… I’d be ready.

Ready for what?
No clue.

I just thought, “This is what toppers do. This is what they expect from me. This must be the right path.”

And then... reality kicked in.

The Plot Twist: My First Wake-Up Call

Six months in, I started seeing patterns. Not in code — in people.

The students who did nothing beyond class were often the ones struggling the most when actual tasks showed up — like building a form, fetching data, or deploying a simple website.

On the flip side, there were these random guys who barely attended lectures but could spin up a full-stack app in a weekend. They weren’t memorizing definitions. They were doing things.

Meanwhile, I was still stuck solving “reverse a linked list” on paper and wondering if this was really helping me get anywhere.

That’s when it clicked:
Knowing the definition of a tool is useless if you never actually use the damn thing.

You can explain how recursion works in theory — but can you use it to solve a real problem? That’s where most students get stuck. And I was no exception.

The College Illusion

There’s this illusion every student is fed (especially in Indian colleges):
Just get your degree, and companies will line up to hire you.

Let me tell you what I’ve actually seen.

Hundreds of students graduating.
Decent marks. Some with CGPAs they were proud of.
And yet… they either:

• end up with ₹10–12k/month contract jobs that last 6–12 months, or

• stay jobless for months, applying everywhere and getting ghosted.

I’m not saying this to scare you. I’m saying this because I’ve watched it happen, in front of my eyes, to people I knew personally.

And it made me realize something very important:
Degrees don’t make developers. Work does.

How I Actually Started Learning (Not in a Classroom)

The switch happened the moment I started building my own projects. Nothing fancy. Just random ideas. Sometimes they worked, sometimes they flopped. But I kept building.

• I joined open-source projects.

• I worked in teams — sometimes I was the lead, sometimes just a contributor.

• I spent hours debugging silly issues, reading docs, and staring at the terminal like it owed me money.

• I broke stuff and fixed it.

That’s where real learning happened.

Not in unit tests.
Not in viva questions.
Not in “write the advantages of arrays vs. linked lists.”

But in building stuff. Shipping it. Watching it break. And fixing it again — slightly better this time.

What College Actually Is (At Least For Me)

College is like an old software update. It fixes some bugs, adds a few features, but it's still not ready for production.

And honestly? That’s okay. It’s not supposed to be everything.

Here’s how I see it now:
College is your break from real learning.
Use it to explore, not to depend.

Go to class. Take your notes. Do your minimum. But after that, log in to GitHub, spin up your IDE, and start getting your hands dirty.

Because no one’s hiring you to write notes. They’re hiring you to solve problems. To build real things. To take vague product ideas and turn them into something that actually works.

And that version of you?
That version doesn’t come out of a syllabus.
That version is forged in real-world experience, bad commits, and failed deployments.

Final Thoughts (This Part’s For You)

If you’re someone sitting in your second or third year of CS thinking:

“Once I finish my degree, I’ll figure everything out.”

You won’t.
Unless you start now.

Don’t wait till you graduate to build. Don’t wait for a college project to be your first actual project. Don’t wait for permission. Just start.

And stop treating college as your entire education. It’s not. It’s just one chapter. The real stuff — the good stuff — happens outside the classroom.

So yeah. Study pigments if you want.
But if you really want to paint?

Pick up the damn brush.

Honestly, I’ve gone through all of it. So here’s my POV — not what YouTubers say, not what random people on Twitter scream — just what I actually think based on what I’ve done till now.

How I Started

In my first year of college, we had C and C++ in the syllabus, so I learned that.
Also learned basic DSA — arrays, loops, recursion, sorting etc. Nothing too deep, just enough to understand how things work.

After that, I got into development.
Started building stuff — websites, UIs, backends, full projects. For like 1–2 years I was fully into dev. And now, recently, I’m also doing DSA side by side again.

So yeah, I’ve seen both.

Why I Like Dev More (But Still Do DSA)

If you ask me what I enjoy more — it’s definitely development.

Because when you build stuff, you actually solve real problems. You can say: “Hey I made this thing, it works, you can use it.” That gives you confidence. And tbh, that’s what most real jobs are about — solving real issues, not solving trees and graphs.

But DSA has its own role.
It helps you go a bit low-level. Makes you think in terms of logic, memory, performance. Gives you that "internal system" clarity that’s useful even in development.

So for me:
→ Dev = Confidence + Recognition
→ DSA = Clarity + Depth

Can You Get a Job Without DSA?

Short answer — yes.

If you know dev properly, made some decent projects, and actually understand what you’ve built — that’s more than enough to get a job. Especially at startups or companies that care about what you can build, not just what you can solve on a whiteboard.

But if you’re aiming for FAANG-type companies or big MNCs, they’ll expect DSA in interviews. So yeah — depends on your goal.

What I’d Suggest to Beginners

A lot of people ask: “What should I learn first — DSA or dev?”

My answer is simple:

1. Learn the basics of one language — C, Python, JS, anything.

2. Then learn basic DSA — arrays, loops, sorting, recursion.

3. Now move to development — frontend, backend, whatever you like.

4. After building some stuff, get back to advanced DSA — trees, graphs, DP, etc.

That’s it.
No rocket science.
No pressure to do everything together from Day 1. You’ll just burn out.

Final Thoughts

DSA vs Dev is not some “choose one forever” thing.
You don’t have to pick sides.

DSA helps you think better.
Dev helps you build better.

The best devs I’ve seen know how to do both — and they know when to use what.

So yeah, do both, but smartly. And don’t overthink it.
Just start, build, and improve along the way.

Hey Fellow Coding Wizards,

Whether you are about to embark on your coding journey or have already started. there is one question you have likely faced: Which language should I start with?Python? C? C++? Javascript? or Java? If you are feeling confused, don't worry - I was in the same boat when I began.

Choosing a programming language to start with can be subjective. Some will recommend Python for its simplicity, while others might suggest Java for its versatility. However, from my experience, I believe starting with the C language is a great choice.

Why C language?

1. Foundation of Programming Concepts

C language is often considered the backbone of modern programming languages. Learning C helps you understand fundamental concepts like memory management, pointers, functions, data structures, etc. These are crucial for grasping more advanced languages later on.

2. Portability and Versatility

Programs written in C language are highly portable. Once you master C language, you'll find it easier to pick up other languages since many modern languages borrow concepts and syntax from C language.

3. Logic Building

While C language doesn’t provide as many pre-written functions like python or javascript, the skills you develop from writing code yourself can be incredibly valuable. As you progress, you might find that this foundational knowledge enhances your ability to work with higher-level languages where you benefit from built-in libraries and functions. This also improve your problem-solving skills and make you a better programmer.

Conclusion

So, while Python and other languages have their own advantages, starting with C language offers a solid foundation for understanding programming at a deeper level.

Happy Coding !