Forem: infinull

My Hot Take On The Leetcode Obsession

infinull — Sun, 15 Mar 2026 06:05:28 +0000

Can we talk about leetcode for a minute?

Seriously, What the hell are we spending our time on?

The Problem With the LeetCode Grind

Give any LeetCode problem to an AI, and it can solve it in a couple of minutes.

If that’s the reality now, why are we still grinding hundreds or thousands of problems?

Honestly, I’m bored of solving the same patterns again and again. People talk about “mastering” problems, but the truth is:

Nobody remembers how to solve every problem they solved months ago

Unless you’re an AI… or an Asian. (those guys are just on another level)

It’s not even a skill issue. A lot of these problems require remembering subtle tricks or patterns. When you grind them repeatedly, you’re not really learning - You’re memorizing nuances.

Real problem solving requires time to analyze and think.

But grinding 1000+ problems forces you to recall patterns, not think.

We're Solving The Wrong Problems

Look around you

There's so much more interesting stuff:

Learning Linux
Understanding how OS works
Exploring AI, MCP, Orchestration
Diving into awesome Open Source Projects
Contributing to Open Source
Building Automations
Learning how to scale real apps

There's an entire universe of things that are actually interesting and useful.

And more importantly, there are real, unsolved problems.

Meanwhile we’re spending hours mastering interview puzzles. Not one, not two, but thousands.

But Recruiters Care About It, Right?

Yeah, sure. Many companies still use DSA interviews.

But honestly, what sounds cooler?

Solving 3000+ LeetCode problems
Or running Arch Linux, automating stuffs, building stuff, and having a crazy Neovim setup?

One is grinding puzzles.

The other is building and understanding real systems.

The Reason I Got Into Computers

I was excited about computers in my childhood, not because it would get me a job and pay well. I did, because it was fascinating, exciting and FUN.

Playing GTA Vice City, Doom was fun.
Setting cool wallpapers and screensavers in your old windows laptop was fun.
Opening the terminal for the first time was fun.
Writing your own tiny C++ programs in Turbo C that did some basic math and feeling ridiculously proud that it worked was fun.
Building your first little tool, like a GPA calculator cause you needed it, was fun.
Watching your site go live and refreshing the page 10 times, just to see it worked, was fun.

Computers were -- and still are -- fun.

The fun wasn’t in chasing optimization tricks or memorizing patterns.

Leetcode is not fun
(Atleast, not for me)

A Better Way To Look At This

Learning DSA Matters, But grinding 1000 problems Does Not

Let’s be clear about one thing: DSA is important.

Stuff like Trees, Graphs, Recursion, Hash maps, Linked lists are fundamental ideas in computer science, They show up everywhere.

Learning them is absolutely worth your time.

But there’s a big difference between learning something new and grinding same pattern again and again.

Solve a few problems to understand how these structures work.

That's valuable.

What isn’t valuable is solving hundreds or thousands of problems just to memorize patterns for interviews.

There are amazing competitive programming platforms like Codeforces, CodeChef, AtCoder.

If you enjoy competitive programming, go all in. Compete, Solve, Climb the rankings, become a Grandmaster or something.

But doing it not because it's fun, but only because companies demand it is where things become messed up.

So Leetcode is the problem, Right?

The problem isn’t even LeetCode itself.

The problem is the culture we built around it.

The culture where:

“Solve the Top 100 FAANG Repeated Questions”
“Comment CheatSheet to Get 2026 FAANG CheatSheet”
“Memorize these patterns and you'll crack any interview”

somehow became the holy grail of becoming a good engineer.

It isn't.

And honestly, the problem isn’t the platforms.

The problem is us.

We turned interview puzzles into the ultimate benchmark of engineering ability.

Personally, I’d take real system knowledge over a 3000+ LeetCode badge on LinkedIn any day.

Final Thoughts

I did waste my time on this for a long time.

Following a DSA sheet. Solving every problem. Taking notes. Then coming back after a month to solve them again.

But recently, I met some cool people doing things I actually found exciting. They knew a lot of stuff about systems.

running their own homelabs
customizing Linux setups
contributing to open source
understanding how systems really work All the stuff I always wanted to explore.

Yet I kept pushing those things aside because “I should probably solve a few more LeetCode problems first.”

Looking back, that was probably the wrong priority.

This post is mostly a reminder to myself that:

You have two choices

Follow the boring manual and be the 1001st guy, who did the same thing successfully.

Or take a leap of faith on what your heart says. Because in the end, all that really matters is that you had fun along the way.

Have fun.

The Skill of Reading Code

infinull — Sun, 25 Jan 2026 13:03:02 +0000

A developer's job is 90% reading code and 10% writing it.

Almost every course found online, or taught in university is about writing code. Clean code, best practices, class design patterns. All good stuff. But in reality we spend a huge chunk of our time in reading someone else's code, which is often neither clean nor documented.

Reading code isn't like reading a book, you go line by line, drop a single bookmark, and continue where you left off the next day. NO! It's messy, non-linear and you gotta load the entire flow into your mind.

I wanna quote the term Mind Map here. Imagine exploring a new city, you start somewhere, walk through a couple of streets, visit some important places the Supermarket, the Restaurant. Slowly build your own map. You don't know every street, but you know the places that matter. Some roads are familiar, some are just “I know it's around here”, rest you ignore.

Reading code is just like that.

Why Reading Code Feels Hard?

Think of our brain like a RAM.

Every new file, every function forces you to load context into your brain. Not only that, you're required to also understand the code's intent by looking at variable names like data, data_cleaned, data_cleaned_final and functions like process(), preProcess(), validate() and god knows what.

So now your brain isn’t just storing context. It’s resolving stuff like

“Is process() the main logic or a helper?”
“Why is data_cleaned_final still being modified?”
“Which of these functions actually does the important thing?”

At this point, it’s no longer just a Memory problem. It’s a CPU problem too.

Reading code isn’t free. It’s Computationally Expensive. And requires some patience

And this is where rewriting it from scratch starts to feel like a better idea. (or is it?)

Pros of Being Better at Reading Code

Makes you better at your 9-to-5 job

New project, new team, new repo - the fastest way to become useful isn't writing features. It's understanding flow.

Take a bugfix, for example, Your ability to write the perfect fix is secondary. What matters more is how fast you find the point of failure once the bug is discovered. That means loading context faster into your brain, identifying critical data from noisy logs, and tracing the buggy path through the codebase without getting lost.

The same goes when you're building a new feature. You’re not starting from a blank file. You’re navigating an existing system. Understanding edge cases, knowing which parts will be affected, and spotting where changes should happen versus where they merely could happen.

Nobody knows everything when they start. The real difference is how fast you can read and update your brain with the provided information, and update it as you go.

AI Changed Writing Code. Not Understanding It

I’ll argue that Reading code is a mandatory skill in the AI era.

We now have vibe-coding tools which can spit out huge amount of code in seconds. Right now you can one-shot an entire full-stack app with a decent prompt. On the surface, it looks like the problem of producing code is solved.

It isn't

AI didn't remove the need to understand code - it multiplied it. The Feeback Loop is the real bottleneck.

Every generated slop still needs to be read, reviewed, trimmed and given a feedback for update. If you can scan code quickly, spot bugs, notice repeated patterns, and identify unnecessary abstractions, you can make decisions faster - and faster decisions lead to better prompts, better iterations, and better code.

Until AI can fully understand your intent, or we invent a way to absorb massive codebases instantly - Reading code remains non-negotiable.

So How Do We Improve It?

Here's a few tips I learnt along the way, which helped me a lot

1. Better Syntax Highlighting

Use a good theme. It sounds like beginner advice, but it makes a real difference when reading code. Code is a mix of classes, variables, keywords, strings, and expressions - and your theme should help you distinguish these at a single glance, not make everything look the same for the sake of a “hacker vibe.”

Consistency matters too. Using one information-rich theme across all your tools reduces cognitive friction and helps your brain build familiarity faster. Personally, I find VS Code’s default theme surprisingly well-balanced and use it in IntelliJ and Neovim as well.

2. Use Every Context Available

The code you're reading is just the final snapshot. If your goal is just to understand the current behavior, that’s often enough. But if you’re trying to answer questions like - how a bug happened, why a flawed change was approved, or how it even reached production- the code alone won’t cut it. You need more data. You need context.

Start with Git History. Commit messages often contain intent, trade-offs, and time pressure. They explain why something changed, not just what changed.

Move on to Pull requests (PRs) and Merge requests (MRs) which contain even more info. Discussions, Rejected ideas, and edge cases that shaped the final code. Many confusing bugs make perfect sense once you read the conversation around them.

When needed skim tickets, design notes - even outdated ones, because they reveal assumptions the code was built on.

3. Know your tool

Modern IDEs aren't just for improving writing code - they're powerful navigation tools too. Use the built-in features to improve your code reading.

Use Find Usages and Find References to understand how a piece of code is used in the codebase
Visualize File history & Blame to understand how code evolved
Collapse / Expand code to see file structure at a glance
Use Zen mode to remove distractions and maximize code focus when reading

4. Annotate the code

Reading code is a process. You don’t sit down, read top-to-bottom, and walk away enlightened. You forget. You come back. You lose context after a tea break. Or worse - after a weekend.

That's why annotation matters.

Write things down. Mark things (bookmark) in IDE. Leave breadcrumbs for your future self.

Use pen and paper to jot down important flows, assumptions, and "ohh, i see" stuff.

Inside your IDE, bookmarks and pins are insanely effective. They save minutes every time you jump back to a specific piece of code

Days later, you reopen the file, see the note, and instantly know where you were, even after a sudden meeting or a bit of small talk.

Personally I use a mix of both, bookmarking references in IDE rather than writing them in note. I pin important files instead of maintaining a separate "remember this later" list. For understanding flow, drawings beat text every time - whether it’s a quick sketch on paper or a rough board in Excalidraw or Obsidian Canvas.

5. Try not to judge the code, but learn from it

This is the last and most important one.

Judging code too early blocks understanding. The moment you label something as “bad” or “messy”, your brain stops exploring and starts resisting. 9 out of 10 times, the mess has it's reasons. And you usually uncover those reasons only by reading through it.

Reading messy code is valuable too. It shows you what not to do, which cases cause bugs and where assumptions may break.

Starting from scratch isn’t always the right move

Rename before refactoring
Delete only after you know why it exists
Rewrite only when you can clearly explain why the current version fails

A few minutes spent humbly reading the code often saves hours of confusion, frustration, and unnecessary reimplementation.

Final Take

Reading code isn’t a secondary skill. It is the job.

So don't rush past reading. Every minute spent forming the mind map, saves hours of wrong implementation later.

Hope it helps!

The First Commit

infinull — Tue, 13 Jan 2026 03:52:54 +0000

Intro

Hey everyone, I'm Infinull, a Software Developer. If you're curious to know more about me, you can find that here.

I've decided to give blogging a shot.

In my day-to-day life, there a lot of stuff which I stumble across. This blog is a place to capture a few of them and make it public. The entire motive is to share stuff that might actually help somebody out there. (or atleast make em laugh)

The (Un)Plan

I honestly have no idea how this will evolve over time. It might change shape, tone or direction - and that's okay. What I do know is that I'd rather build, break and learn stuff in public than let it sit in a private draft forever. Whether it's a weird bug that ruined my sleep, a tool which saved me hours, or a random project idea which never saw the light of day - If i feel like sharing it, It'll be here.

No promises, no plans, just a developer sharing some stuff.

Outro

So yeah - Welcome. Stick around, explore, and hopefully you'll find some cool stuff here. If you wanna know the entire backstory behind the blog, kindly checkout this one.

Stay tuned. See ya around 👋🏻

How I Built My Own Blog - And You Can Too

infinull — Tue, 13 Jan 2026 03:48:54 +0000

How it all started

You know that feeling when you find something so cool, you have to tell someone? That was me a few weeks back. My first instinct? grab a few screenshots, head straight to Linkedin and hit post.

But something felt off. The post went live, got a few likes, and then... it disappeared into the endless scroll. That's when it hit me: what was I really trying to achieve here? A LinkedIn post has a shelf life of about 24 hours before it becomes digital dust. If someone needed this information next week, next month, or next year, how would they find it? The answer was clear: they wouldn't.

The Search For Something Better

After days of hopping between platforms, I realized I needed something structured, flexible, and more findable in this vast internet. I started where everyone does - popular blogging platforms. They were polished, powerful, easy to use, packed with features like SEO optimization, clean typography and much more.

Some of the hosted solution I found are : Medium / Dev.to / Hashnode

These are some really awesome sites, but they all felt kinda same, polished, yet not personal. So somewhere along the way, I stopped chasing The Best Blog 🏆, I just wanted my blog, even if it was a simple one.

Finding Astro

I explored a few self-hostable options like Ghost, WordPress and a whole world of static site generators like Jekyll, Hugo.

Ghost and Wordpress are powerful and feature packed - but heavy for my use case.

Jekyll & Hugo were tempting, fast and popular - but unfamiliar (Ruby & Go). That meant an extra learning curve I wasn't ready to climb.

ℹ️ Honestly, they’re excellent tools, but they didn’t quite fit what I needed for this one.

After a long search, I stumbled upon Astro - a modern static site framework that generates content directly from Markdown files, which I thought was super cool, since I was already using Obsidian (that’s a story for another blog 😅). I was impressed right away.

While digging deeper into Astro-based blogging setups, I found an awesome repo astro-erudite which was opinionated - but in a good way. Clean structure, sensible defaults, and just enough constraints to keep things elegant. I liked it immediately and started tinkering with it.

After a few sleepless nights, I'd shaped it to fit my own needs - learning Tailwind and Astro along the way.

And here it is: my own blog and portfolio, built exactly the way I wanted. Live Here!

Building Your Own Blog

Honestly, as I'm a backend guy and wanted a fast solution, so I picked this template as a good starting point. If you’re thinking about building your own site, here’s a no-nonsense path that works well:

1. Decide your goal

Blog? Portfolio? Both? Don't over-scope it - Be clear on what you want.

2. Pick a starting point

Use a template if you wanna move fast (like me)
Build one from scratch, if you enjoy design and setup
Use a CMS if writing is your only priority ### 3. Choose a stack you're comfortable with Familiar tools reduce friction. Static generators like Astro are a great balance between flexibility and simplicity. ### 4. Write in Markdown It’s portable, future-proof, and keeps content separate from presentation. ### 5. Iterate Slowly Add features only when you feel the need. A plain site you ship today is better than a perfect one running in your localhost.

How (and Where) to Host It?

Once your site is ready, the next big question is: where does it live?

For now, I went with Cloudflare Pages. It’s fast, generous with its free tier, and removes almost all the friction from deploying a static site. Push to Git, and your site is live—no servers, no maintenance, no stress.

As a bonus, it had excellent support with Astro, making the whole build-and-deploy flow feel effortless.

Here are a few alternate options :

Vercel - Great dev experience, free tier
Netlify - Easy deployment, free tier available
GitHub Pages - Free for public repos
Self-hosting - Full control (Planning to move here soon)

The good news? For a personal blog or portfolio, any of these free tiers are more than enough. Pick the one that helps you get online fastest - you can always switch later.

The Result

So yeah, finally here's the first version after a few sleepless nights and a plenty of tinkering.

It's not perfect and it doesn't has to be. It's mine.

If you find some bugs here and there, kindly drop an email to theinfinull@gmail.com.

❗ If you're thinking about starting your own blog, just do it. Pick a template, customize it, deploy it, and start writing. The best time to start was yesterday, the second best time is now. ☺️

Thanks for reading this!