Pranavvv

We have access to more educational material than any generation before us, and somehow deciding what to learn has become a problem of its own. There’s always a better course, another roadmap, a new AI tool, or someone explaining why your current approach is outdated. At some point, consuming advice starts competing with the actual work.

I spend a ridiculous amount of time staring at screens. Code editor, Teams, GitHub, X, YouTube, and then back to the code editor because apparently I haven’t had enough. And one of the things I enjoy most outside all of this is riding my Duke 250. Not because riding through Pune traffic is some peaceful, cinematic experience. Anyone who’s been on these roads knows it’s usually the opposite. But there’s something I appreciate about having one very obvious thing to concentrate on. When you’re working on a laptop, you can have twelve tabs open, three conversations going on, music playing, and a notification arriving every few minutes. You feel busy even when you’re barely making progress. Riding doesn’t give you that luxury. You have to pay attention to what’s happening around you. I find it funny that I spend so much time looking for productivity tools, better apps, better workflows, and clever ways to organize my attention. And then one of my favorite activities is something where the important part is simply paying attention to the road. Pune traffic is a terrible meditation app, but it makes a convincing argument for doing one thing at a time.

we don't count money, we count onions.

my type of concerts👀

I’m starting to appreciate engineers who can explain complicated systems without making them sound complicated. It’s easy to throw around terms like eventual consistency, distributed consensus, and fault tolerance. Being able to explain why a particular system needs any of those things is a much more useful skill.

Nobody warned me that getting a software engineering job would make finding time to study software engineering significantly harder. You spend the day working with code, come home wanting to learn more about code, and then your brain decides it has fulfilled its contractual obligations for the day.

everyone's dumping, so here's my contribution to the TL

There’s a very specific disease among developers where a weekend project somehow ends up needing seven different services before it has a single real user. I’ve experimented with Next.js, Prisma, Supabase, authentication providers, background workflows, and AI APIs across my projects. And I genuinely enjoy learning how these things fit together. But I’ve started questioning how often we confuse an interesting tech stack with an interesting product. It’s remarkably easy to spend an entire evening setting up authentication, database schemas, deployment pipelines, and background jobs without making the actual feature any more useful. Of course, these tools solve real problems. The issue isn’t using them. It’s introducing complexity before there’s a problem that justifies it. Every additional service gives you something useful, but also something new that can fail, cost money, or require maintenance. And when you’re building alone, you’re the entire engineering team responsible for all of it. I’m increasingly interested in the developers who can look at a complicated architecture and confidently remove half of it. Adding another technology to a project is usually the exciting decision. Knowing when not to add one is a much less glamorous skill.

The dangerous thing about DSA sheets is that they can make you feel productive without necessarily making you better at problem-solving. You recognize a problem, remember the pattern, implement it, and move on. Then someone changes the constraints slightly and suddenly you’re back to staring at the screen. I’ve started valuing the reasoning more than the number of problems solved.

👀🖤

As a developer getting into video content, I've discovered an entirely new category of problems. Captions that look terrible. Visuals that don't match the narration. Animations that distract instead of explaining. And editing tools that seem determined to make simple things complicated. I started making tech videos because I wanted to explain interesting ideas. Somehow, I've also become deeply concerned about font positioning.

great weatherrr

If you’ve ever generated a website with AI and thought, “Why does every AI website look the same?” This is worth exploring. A design-focused skill toolkit that helps AI coding assistants produce and review better interfaces. github.com/pbakaus/impeccabl…

Everyone knows boys love their cars and bikes. But not everyone understands why. It’s not always about the horsepower, the exhaust sound, or how expensive it is. Sometimes, it’s about having a place where you can be yourself. A boy sits inside his car after a long day. The engine is off, the music is low, and he’s just staring at nothing. Maybe he’s overthinking. Maybe he’s holding back tears. Maybe he’s trying to figure out his life. And for a few minutes, nobody expects anything from him. No questions. No explanations. Just him and his little world. A bike gives him the same feeling on an empty road. The wind hits his face, the city slowly disappears, and somehow, the things that felt so heavy begin to feel a little lighter. That’s why we love our machines. They’re not just vehicles. They’re our escape, our therapy, our freedom. Sometimes, the destination doesn’t even matter. We just need a place where we can feel like ourselves again.

When I was a kid, I used to be so excited about Diwali. The firecrackers, the lights, the noise… everything felt magical. I’d wait for the day just to burst crackers. But now? I barely even look at them. Not because I can’t afford them, but because the excitement just isn’t there anymore. And that made me realise something. Everything in life has its own time. There are things you’ll desperately want today that might not excite you a few years from now. The bike you dream of riding, the car you want to buy, the Goa trip you keep postponing, or even the simplest experiences you think you’ll have someday. Sometimes, we keep waiting for the “right time” when we have more money, a better job, or fewer responsibilities. But what if, by the time you finally get there, the feeling you were chasing is already gone? So if you can afford it, and it genuinely makes you happy, go for it. Buy that bike. Take that trip. Experience the things you’ve been dreaming about. Because money can always be earned again, but the version of you that wanted that experience so badly might not be around forever. Some things are worth doing not just because you can, but because right now is when they mean the most to you.

One of the nastiest bugs in backend systems is a request that succeeds but looks like it failed. Imagine you’re transferring ₹1,000. The server receives your request, processes the transfer, and commits the transaction to the database. But just before sending the response, the network connection drops. Your app sees a timeout. Naturally, it assumes something went wrong and retries. Congratulations. Without proper safeguards, you might have just transferred ₹2,000. The original code could be completely correct. The database could be working perfectly. Every individual operation could behave exactly as intended. And the system still produces the wrong outcome. This is why idempotency is such an important concept. A retry shouldn’t accidentally create a second financial transaction when the user only intended one. You need mechanisms like unique request identifiers, durable deduplication records, and carefully designed transaction boundaries. I find problems like this much more interesting than another discussion about which backend framework is faster. Writing code that works once is relatively straightforward. Writing code that behaves correctly when networks fail, requests repeat, and operations happen concurrently is where things start getting interesting.

If I hadn’t been there then, I wouldn’t be here now.