It’s been six years since I started my journey as a software engineer, and let me tell you—it’s been a ride. From getting lost in endless tutorials to arguing with bugs that seemed to have a mind of their own, I’ve learned a lot (sometimes the hard way).

Along the way, I’ve picked up a few lessons, some practical, some philosophical, and a few that might save you from pulling your hair out. This blog is my way of sharing those experiences—because if I can help someone skip a few headaches, why not? Let’s jump in!

# Don’t stop learning, ever

Software engineering is like riding a wave that never stops evolving—if you’re not paddling forward, you’re falling behind.

If you say you know it all, you’re either lying to yourself or you’ve lost the hunger to grow. In tech—an industry that’s evolving faster than you can say “new framework”—staying updated is critical. Whether it’s frameworks, languages, or tools, the moment you stop learning, you risk falling behind.

Keep reading articles, follow people in the field who are building cool things, and talk to folks with more experience—they’ll give you fresh perspectives.

I started with HTML, CSS, and JavaScript, but over the years, I’ve added Svelte, Flutter, Next.js, Go, Docker, React Native, databases, self-hosting, Linux, CLI tools, and more to my skillset. It didn’t happen overnight—it took consistent learning through blogs, talks, and experimenting with small projects. Even spending 10 minutes exploring a new language or testing a library can add up over time.

# Always strive for deeper understanding when you’re using or learning any language or tool

Using a tool is like driving a car—it’s great to know how to start it, but understanding the engine helps you fix it when things go wrong.

If you don’t understand the framework or tool you’re using, you’re setting yourself up for failure—or worse, replacement by AI.

Many developers dive into React first without understanding why it exists or what problem it solves. They miss out on the underlying principles of JavaScript—like why the event loop exists or how JavaScript’s quirks work.

If you have 3 years experience in Next.js but don’t know what hydration is, you’re just a “frameworker,” not a programmer.

# Don’t be a frameworker!

React is cool. So are Svelte, Vue, and the other thousands of frameworks that exist today. But here’s the thing: they’re just tools—means to an end, not the end itself.

It’s funny when I see debates online about whether React is a library or a framework, or which UI tool is “the best.” Spoiler: Nobody cares! What matters is picking the right tool for the problem you’re solving.

If you’re starting your blog with React/Next.js without considering simpler alternatives, you’re using the only tool you know—not the best one for the job. Be a problem solver, not just a “React Developer” or “MERN Developer.” Learn the language, not just the framework.

# Don’t be in tutorial hell, learn by building

Tutorials are like training wheels—they help you get started, but you won’t learn to balance until you try riding on your own.

Start with the official documentation! Tutorials are fine, but they come with limitations. If you’re learning from someone who only understands 70% of a tool, you’re getting a filtered perspective. Instead, dive into the docs for the complete picture. Use tutorials sparingly—more as supplementary help when you’re stuck.

Early on, I consumed tutorials like snacks, but I’d forget half of it because I wasn’t applying what I learned. Things changed when I started building my own projects. Hands-on practice is the only way to move beyond the basics.

# Start with minimal abstraction

I used to think “more abstraction = better code.” I was obsessed with avoiding repetition, so even small code blocks went into utility functions. Once, I built a modular API wrapper, convinced it was reusable for multiple apps. Turns out, it was so rigid we rewrote it for every app anyway.

Abstractions can slow you down, make debugging harder, and overcomplicate your code. It’s okay to copy-paste logic a few times! Focus on getting things done before worrying about perfect architecture.

# Strive for simplicity

Complexity is not a flex!

Whether it’s writing functions, designing APIs, or structuring an app, simplicity should always be the goal. Simple code is easier to read, debug, and maintain.

For example, if you’re starting your portfolio website with Next.js, you’re either over-complicating or just using the only tool you know. A basic portfolio needs just HTML and CSS. That’s it!

# Focus on user experience (even if you don’t work on UI)

I once met a developer who thought showing users an error like duplicate key value violates unique constraint "constraint_name" was acceptable. That’s a hard no.

We build products for “normal people,” not developers who understand cryptic error messages or complex UIs. A good user experience means intuitive design, clear error messages, helpful hints, and minimizing steps for any action.

# Popular doesn’t mean it’s right

Things are wild on social media—people dunk on tech tools and give blanket opinions like they apply to everyone. For instance, developers love to hate WordPress, but it’s one of the easiest ways to build a website.

Take Vercel as another example: it’s super popular and makes deployments effortless, but it’s expensive and not right for every project. No tool is perfect—each has pros and cons. Choose what works best for you, not what’s trending.