DEV Community: PRANTA Dutta

AI Persona — Build, share, and chat with your custom AI companions

PRANTA Dutta — Sat, 31 Jan 2026 14:50:18 +0000

TL;DR: I built AI Persona — an open-source Android app that lets you create, customize, and chat with AI companions (with voice and knowledge base support). Try it on Google Play, check the repo, and read on for why I built it, how it works, and how you can help.
Play Store: https://play.google.com/store/apps/details?id=com.pranta.aipersona
GitHub: https://github.com/theprantadutta/ai_persona

Why I built AI Persona

A lot of AI chat apps feel one-size-fits-all: a single assistant, a single tone. I wanted something more playful and modular — the ability to spin up a creative writing partner, an assistant who knows only your project docs, or even a fictional character that talks like it stepped out of a movie script.

So I built AI Persona to be:

Personal: each persona has a personality, memory, and optional knowledge base.
Creative: use it for brainstorming, roleplay, practice, or productivity.
Open: you can inspect and contribute (repo linked above).

What it does (features at a glance)

The app’s Play Store description highlights these core capabilities:

Chat with unique AI personas that remember context and adapt to your style.
Create custom personas from scratch — personality, expertise, response style.
Add custom knowledge bases (documents) that a persona can reference.
Voice features: speech-to-text and text-to-speech for natural conversations.
Community & social features: browse, follow, like, clone, and remix community personas.
Cross-device sync, privacy controls (export/delete data), and subscription tiers for heavier usage. ([Google Play][1])

(Play Store also shows recent updates like Picture-in-Picture support and Android 15 edge-to-edge improvements.) ([Google Play][1])

Pricing & limits (as listed on Play Store)

Free: 25 messages/day, up to 3 personas, 3-day history, 50MB storage.
Basic ($4.99/mo): 200 messages/day, up to 15 personas, 30-day history, voice input.
Premium ($9.99/mo): 1,000 messages/day, 50 personas, 90-day history, full voice features.
Pro ($19.99/mo): Unlimited messages, unlimited personas/history, larger storage and features. ([Google Play][1])

Screenshots / visuals

You’ll find screenshots and the app icon on the Play Store listing (use them in the dev.to post if you want visual context). The Play Store listing also includes the “About this app” copy that summarizes the experience. ([Google Play][1])

How to try it

Install from Google Play: https://play.google.com/store/apps/details?id=com.pranta.aipersona. ([Google Play][1])
Create a persona (or browse community personas).
Add a small document or two if you want the persona to answer from your knowledge base.
Try voice input and TTS to test the multimodal experience.

How to contribute (for open-source folks)

NOTE: I tried to fetch the GitHub repo at the link you provided, but it returned a 404 on my side. Make sure the repo is public or the URL is correct so contributors can reach it.

Suggested repo structure and CONTRIBUTING tips you can add to the repo (copy/paste into a CONTRIBUTING.md):

# Contributing to AI Persona

Thanks for wanting to help. A few ways to contribute:
- Bug reports & feature requests: open issues labeled `bug` or `enhancement`.
- PRs: branch from `main` and open PRs against `main`. Keep changes focused.
- Localization: provide translations for strings.xml (or i18n files).
- Persona marketplace: add a few example persona JSONs in `/examples/personas`.
- Docs: improve README with architecture, deployment, and API docs.

Testing:
- Unit tests for core logic
- Integration tests for networking and storage
- Manual test plan for voice / TTS features

If you want, I can generate a polished CONTRIBUTING.md and README sections for you now.

Developer notes (what to include in README / tech notes)

Instead of guessing the exact stack, here’s a safe template you can fill in and add to your README:

Platform: Android (min API 24 / target SDK X).
Language & frameworks: (e.g., Flutter / Kotlin / Jetpack Compose — fill in what you used).
AI: Describe if the app uses remote LLM APIs (OpenAI, Anthropic, local LLMs) or a hybrid. Mention how prompts, persona metadata, and custom knowledge bases are stored and retrieved.
Voice: Describe TTS/STT providers (Google Speech-to-Text, Android TTS, or cloud provider).
Auth & Privacy: Token storage, encryption in transit, export/delete endpoints.
Billing: Play Billing integration notes and how subscription states are enforced client-side vs server-side.

Putting these details in the README helps developers decide whether they can run the app locally or contribute features.

A suggested dev.to post body (copy-ready)

Below is a ready-to-paste article body (same as above but reformatted slightly shorter for dev.to readers who skim). Use the longer text above if you prefer — both are publish-ready.

Roadmap ideas (nice-to-have / next steps)

Desktop/web client or PWA for cross-platform use.
Persona versioning and diffs (see history of edits).
Import/export marketplace formats (JSON or YAML).
End-to-end encryption option for private knowledge bases.
Offline/edge LLM support for local-only personas.

Closing / Call to action

If you enjoy building with AI or want to try weird persona ideas (an NFL coach who only gives motivational quotes, or a 1920s detective who solves debugging problems), download AI Persona and create one. If you want to contribute, check the repo and open an issue — or ping me and I’ll draft CONTRIBUTING/README sections to make onboarding smoother.

Play Store: https://play.google.com/store/apps/details?id=com.pranta.aipersona. ([Google Play][1])
GitHub: https://github.com/theprantadutta/ai_persona

I Built a Privacy-First Note-Taking App with Flutter — Here's What I Learned

PRANTA Dutta — Fri, 09 Jan 2026 16:39:42 +0000

I just released my second app on the Google Play Store — Pinpoint, a privacy-focused note-taking app built with Flutter. After months of development, countless iterations, and learning a ton about encryption, cloud sync, and the freemium business model, I wanted to share the journey.

🔗 Links:

Why Another Note-Taking App?

I know what you're thinking — the world doesn't need another notes app. But here's the thing: most note apps either sacrifice privacy for features or sacrifice features for privacy. I wanted both.

The goals were simple:

End-to-end encryption that actually works
Beautiful, modern UI (not just functional)
Multiple note types beyond just text
Cloud sync without compromising privacy
A sustainable freemium model

The Tech Stack

Here's what powers Pinpoint under the hood:

Core Framework

Flutter 3.6+ — Cross-platform goodness
Dart — Modern, type-safe language
Material 3 — Latest Material Design guidelines

Local Database

Drift 2.24 — Type-safe SQLite with reactive queries. This was a game-changer for real-time updates.

Security

AES-256 Encryption — Using the encrypt package
Flutter Secure Storage — For secure key management
Local Auth — Biometric authentication (fingerprint/Face ID)

State Management & Architecture

Riverpod 3.0 — Modern reactive state management
Go Router — Declarative navigation
GetIt — Dependency injection

Cloud & Backend

Firebase Authentication — Google Sign-In
Custom FastAPI Backend — For cloud sync and usage tracking

Features I'm Most Proud Of

1. Multiple Note Types

Not just plain text. Pinpoint supports:

Rich text notes with formatting
Audio recordings with playback controls
Todo lists with real-time auto-save
Reminders with timezone-aware notifications

2. The Glassmorphism UI

I spent way too much time on this, but the frosted glass effects throughout the app just feel right. Combined with 5 accent color themes (Mint, Iris, Rose, Amber, Ocean) and smooth animations, it's genuinely pleasant to use.

// Example: Glassmorphism container
Container(
  decoration: BoxDecoration(
    color: Colors.white.withOpacity(0.1),
    borderRadius: BorderRadius.circular(24),
    border: Border.all(color: Colors.white.withOpacity(0.2)),
  ),
  child: BackdropFilter(
    filter: ImageFilter.blur(sigmaX: 10, sigmaY: 10),
    child: // content
  ),
)

3. Real End-to-End Encryption

Notes are encrypted on-device before they ever leave your phone. The encryption key is derived from your master password and stored securely — I never see your notes.

4. OCR & Voice Transcription

Using Google ML Kit, you can extract text from images. Speech-to-text lets you quickly dictate notes when typing isn't convenient.

5. The Freemium Model

I implemented a fair usage-based model:

Feature	Free	Premium
Synced Notes	50	Unlimited
OCR Scans	20/month	Unlimited
Exports	10/month	Unlimited
Voice Recording	2 min	Unlimited
Folders	5	Unlimited

Usage is tracked both locally and on the backend to prevent bypassing limits.

Architecture Decisions

Clean Architecture with Service Layer

I went with a service-based architecture that keeps business logic separate from UI:

lib/
├── screens/           # UI screens
├── components/        # Reusable UI components
├── services/          # Business logic layer
├── database/          # Drift database
├── entities/          # Database tables
├── design_system/     # Colors, typography, theme
└── navigation/        # Go Router config

Database Schema (Drift)

The schema supports many-to-many folder relationships:

// Simplified schema
tables:
  - notes (id, title, content, type, encryption, timestamps)
  - note_folders (id, title)
  - note_folder_relations (note_id, folder_id)
  - note_todo_items (id, note_id, title, is_done)
  - note_attachments (id, note_id, file_path, type)

Stream-Based Reactivity

Drift's watch queries made real-time updates trivial:

Stream<List<Note>> watchAllNotes() {
  return (select(notes)
    ..orderBy([(t) => OrderingTerm.desc(t.updatedAt)]))
    .watch();
}

Challenges I Faced

1. Google Play Billing Integration

Setting up in-app subscriptions was... painful. Between base plans, offers, and tags, I spent a solid week just understanding the terminology. Pro tip: read Google's docs three times before you start coding.

2. Cloud Sync Conflicts

When the same note is edited on two devices offline, which version wins? I implemented a "last write wins" strategy with timestamps, but this is still an area I want to improve.

3. Todo List Auto-Save

Getting todo items to auto-save without losing the user's cursor position or creating race conditions was trickier than expected. I ended up using debouncing with temporary IDs for unsaved items.

What's Next?

The roadmap includes:

Collaboration — Share notes with others
Tags System — Beyond just folders
Markdown Editor — Full markdown support
iOS Release — App Store deployment
Web Clipper — Save content directly from browser

Try It Out!

If you're looking for a note-taking app that respects your privacy without compromising on features, give Pinpoint a try:

📱 Download on Google Play

💻 View Source on GitHub

The app is open source, so feel free to poke around the code, open issues, or contribute. I'd love to hear your feedback!

Wrapping Up

Building Pinpoint taught me a lot about Flutter, encryption, cloud architecture, and what it takes to ship a real product. If you're thinking about building your own app, my advice is simple: just start. The learning happens in the doing.

Thanks for reading! Drop a comment if you have questions about the implementation or want me to dive deeper into any specific part.

Tags: #flutter #dart #mobile #opensource #privacy

Anthropic: Brilliant Models, Bullshit Pricing

PRANTA Dutta — Mon, 06 Oct 2025 18:25:01 +0000

Let’s get one thing straight — Anthropic makes some of the best damn AI models on the planet.
Their Claude lineup — Sonnet, Opus, and Claude Code — feels like coding with a genius friend who actually listens and doesn’t gaslight you when you typo a variable.

But then… they charge you like you’re leasing a Ferrari by the hour.
So let’s dive in — first the praise, then the pain.

🚀 The Praise: They Built Literal Magic

Anthropic’s Claude models are technical masterpieces.

Claude Sonnet 4.5 — currently hailed as “the best coding model in the world”
→ It nails 77.2% on real-world coding benchmarks.
→ Handles 30+ hour coding sessions like a champ.
→ And can refactor entire multi-file projects without losing its mind.
Claude Opus 4.1 — the “big brain” model.
→ It’s designed for advanced reasoning and agentic tasks.
→ Comes with a monstrous 200K-token context window, expandable to 1M tokens.
→ You can literally throw an entire codebase at it — it won’t blink.

Developers get spoiled with all this.
Claude Code has a native VS Code extension, CLI interface, code checkpoints, and even a Claude Agent SDK for building custom dev agents.

You can create files, edit spreadsheets, manage docs, and refactor code directly in chat — it’s like having ChatGPT, Copilot, and a senior engineer all rolled into one caffeinated model.

Even the big boys are hyped:

“Sonnet 4.5 soars in agentic scenarios.” – GitHub
“Anthropic’s most intelligent model and best performing for coding.” – AWS

And to top it off, Anthropic frames itself as a public benefit corporation “building AI to serve humanity’s long-term well-being.”
That’s wholesome. Almost suspiciously wholesome.

💸 The Pain: Price Tag from Hell

But then… they hit you with the pricing.

Holy. Shit.

Claude isn’t free — it’s painfully premium.

Here’s what we’re looking at:

Plan	Price	Prompts per 5 Hours	Notes
Pro	$20/month	10–40	Claude 3 Sonnet
Max 5x	$100/month	50–200	Unlocks Claude Opus
Max 20x	$200/month	200–800	Full access (with limits 😒)

And before you ask — yes, those “prompts” vanish faster than your will to live after debugging for 4 hours.

For comparison:

GitHub Copilot → $10/month, unlimited usage.
Cursor → $20/month, predictable pricing.
Claude → “Maybe you can code today, maybe you can’t — depends on your prompt quota.”

Developers everywhere are screaming:

“The cost, the cost, the cost!”

Even tiny bug fixes can burn a few dollars.
Long refactors? Boom — your balance is gone.

And the usage-based billing is a total gamble. You don’t even know how much you’ll pay until it’s too late.

To make it worse, Anthropic quietly changed usage limits for the $200 plan — without warning anyone.
Cue the Reddit meltdowns.
Immediate backlash.
Developers furious about “opaque tiers” and hidden caps that “undermine the value” of their top plans.

So yeah. The models? Genius.
The pricing? Highway robbery in a cashmere suit.

🎭 The “Mission”: Safety or Sales Pitch?

Anthropic loves to say they’re “dedicated to securing AI’s benefits and mitigating its risks.”
They remind us constantly that they’re “a public benefit corporation” with humanity’s well-being at heart.

Cute.
But the real well-being they seem to care about is their profit margin.

You don’t partner with Amazon, AWS, and enterprise platforms just to “serve humanity.” You do it to cash in.
And fair enough — business is business.
But maybe don’t hide behind moral philosophy while charging $200 a month to write Python scripts?

🧑‍💻 Verdict for Developers

Let’s break it down:

✅ Cutting-edge models:
Sonnet 4.5 and Opus 4.1 are legit top-tier. They handle multi-file projects, deep reasoning, and long contexts that leave GPT and Gemini sweating.

🧰 Dev-friendly tools:
The VS Code extension, CLI, checkpoints, and Agent SDK are chef’s kiss. Truly next-level dev experience.

💀 Nightmare pricing:
The tiered pricing is an absolute wallet massacre. $20 for limited access, $200 for maybe enough prompts. Predictability = 0.

🚩 Red flags:
Secret usage limits, vague caps, and vague plan descriptions. Users feel scammed — with good reason.

💔 Final take:
Is Anthropic garbage?
→ No. Their tech is god-tier.
→ But their pricing and communication are utter trash.

Anthropic gives you a Ferrari for coding… and then charges rent every time you hit the gas.

So yeah, we love Claude — but we also hate that we’re paying for it like it’s AWS Lambda in 2012.

⚡ TL;DR

The Good	The Bad
Best-in-class AI for reasoning & code	Stupidly expensive
Powerful dev tools & SDK	Hidden caps & weird limits
Massive context windows	Unpredictable usage pricing
Safety-first vision	Feels more like profit-first execution

Anthropic’s Claude Sonnet and Opus are incredible.
They’re smart, intuitive, and ridiculously capable.
But they’re also the kind of models that’ll make your accountant cry.

So if you want stellar AI, Anthropic’s your hero.
If you want a good deal... brace yourself.

At the end of the month, you’ll be mumbling:

“God damn it, Anthropic — I love you, but fuck these prices.”

Also if you want to learn how to make your own Claude, click here and start today with CodeCrafters, you will help out a fellow dev as well, thanks.

Oracle vs. Google: The API Battle That Shook the Coding World

PRANTA Dutta — Wed, 24 Sep 2025 14:19:15 +0000

If you’ve ever copy-pasted StackOverflow code at 2 AM and thought, “Is this legal?”, then buckle up. Today we’re diving into one of the most legendary tech lawsuits of our time: Oracle v. Google — aka the court case that tried to decide whether an API is a recipe, a love poem, or a copyrightable Mona Lisa.

Spoiler: It took over a decade to settle. Yup, this case dragged on longer than most Netflix series, with more plot twists than Game of Thrones. Let’s break it down.

☕ Setting the Stage: Google, Java, and the Birth of Android

Picture this: It’s the mid-2000s. Google is building Android, a new mobile operating system. They want developers to hop on board fast, and what better bait than a language devs already knew and loved: Java.

But here’s the catch — Java belonged to Sun Microsystems, the company behind everyone’s favorite System.out.println("Hello World"); moments.

Instead of buying a license, Google went: “Nah, we’ll just write our own version of Java’s engine. But hey, to make it familiar, let’s reuse some Java API declarations and structure.”

Translation: They copied about 11,500 lines of code — not the meaty code, but the API structure (method names, class organization, etc.). Think of it like writing your own restaurant menu but keeping the same dish names so customers don’t get confused.

Sun Microsystems kinda shrugged. They wanted Java everywhere anyway. But then… Oracle swooped in and bought Sun in 2010. And Oracle was like, “Wait, someone’s making billions using OUR secret sauce? Lawyer up.”

⚖️ The Lawsuit: Copyright or Not?

Oracle sued Google in 2010, claiming two things:

Google copied Java APIs — that’s copyright infringement.
Google also infringed on some patents.

The patent part fizzled out. The real spicy meatball was the API copyright question:

Oracle’s stance: APIs are creative works. If we wrote it, we own it.
Google’s stance: APIs are functional — more like a keyboard layout or a dictionary. You can’t copyright function names.

And thus began a legal rollercoaster.

🎢 The 10-Year Rollercoaster Timeline

2012 (Trial Court)

Jury: “Nah, no patent infringement.”
Judge: “Also, APIs aren’t copyrightable.” (Google wins!)

2014 (Appeals Court)

Federal Circuit: “Actually, APIs are copyrightable.” (Oracle wins!)

2016 (New Trial: Fair Use)

Jury: “Even if they are copyrightable, Google’s use was fair use.” (Google wins!)

2018 (Appeals Court Again)

Federal Circuit: “Nope, still infringement. Not fair use.” (Oracle wins!)

2021 (Supreme Court Final Boss)

Supreme Court: “We won’t answer if APIs are copyrightable, but even if they are, Google’s use is fair use.” (Google wins!)

End of saga. Oracle didn’t get their \$8–9 billion payday. Google kept Android running as-is.

🚀 Why This Case Mattered (Big Time)

This wasn’t just a corporate slap-fight. It was about the future of programming freedom.

For developers: Imagine if APIs were fully locked down by copyright. That means you couldn’t write your own version of, say, Python’s math library or React’s hooks without begging for permission (and probably paying royalties). Innovation would slow to a crawl.
For open source: The entire open source ecosystem thrives on compatible implementations. Linux clones UNIX APIs. PostgreSQL mimics Oracle DB features. Even your favorite npm packages often re-implement existing ideas. If APIs were off-limits, open source would become open-what?
For tech companies: It clarified that using APIs in transformative ways can be fair use. That gave startups and giants alike the confidence to build new systems without worrying Oracle’s lawyers would show up like the copyright police.

Basically, this case set a precedent: APIs are fair game if used reasonably. Without it, Android (and probably half the apps on your phone) wouldn’t exist the way they do today.

🥊 Oracle vs. Google in Meme Form

Oracle: “You copied my homework!”
Google: “Yeah, but I wrote all my own answers, I just used the same section titles.”
Supreme Court: “Looks like fair use. Now stop wasting our time.”

📌 Final Thoughts

The Oracle v. Google saga is a cautionary tale of how legal battles can drag on forever in tech — and how the fate of APIs (and billions of dollars) can hang on whether a judge thinks code is like a recipe or a novel.

At the end of the day, developers breathed a sigh of relief. APIs remain a shared language of the coding world, and you can keep copy-pasting those sweet sweet library calls without losing sleep.

Well, except when your code doesn’t compile. That’s still on you.

💡 Want to sharpen your coding chops with real-world systems (without getting sued by Oracle)? Check out Codecrafters here. It’s like gym for developers — but instead of lifting weights, you’re lifting entire databases, Docker, Git, and more.

Why Apple’s “Liquid Glass” and Google’s “Expressive” UIs Might Be Missteps

PRANTA Dutta — Mon, 15 Sep 2025 18:22:22 +0000

Apple’s new Liquid Glass design and Google’s Material 3 Expressive update promise to make our phones look fancier – but many designers and users are already grumbling. These see-through, glassy effects and over-the-top animations sound exciting on paper, but can they hamper usability in the real world? After combing through tech blogs, reviews, and dev communities, here are the key problems critics have found (with a humorous twist):

🍸 Apple’s Liquid Glass: All Show, Hardly a Shaker

Apple bills Liquid Glass as a “translucent material that reflects and refracts its surroundings” (Apple WWDC session). In other words, buttons and panels look as if they’re carved from actual frosted glass (think of iOS floating above a pretty wallpaper everywhere). The idea is to give the UI “a new level of vitality” across controls and icons.

Apple’s Liquid Glass makes app icons and buttons look like frosted glass layers. It *sounds sleek – but early testers note it has already “resulted in challenges in terms of readability.” (TechCrunch)*

The Problems

Legibility Nightmares: Wired’s design critics say Liquid Glass currently “veers into distracting or challenging to read” territory. Beta testers noted that “text and icons could get lost on busy or high-contrast backgrounds.” In plain terms: if your wallpaper has pink flowers behind your chat bubble, your words might vanish. Accessibility advocates are already worried about contrast issues.
Wallpaper Obsession Over Function: One Reddit designer joked that while Liquid Glass looks nice in screenshots, it feels like a PITA (“pain in the UI”) to actually use, since it treats the home screen as your wallpaper portfolio. It’s as if Apple is saying: “Don’t mind the text—just admire the background!”
Developer Headaches: For app makers, adapting to Liquid Glass isn’t trivial. Wired quotes a small-team dev fretting, “I’m scrambling to make our designs work.” Many third-party apps lag behind Apple’s own, creating a fragmented, Frankenstein UI.

💡 Summary: Liquid Glass is undeniably pretty, but critics fear it’s “beautiful in theory, terrible in real life.” If your phone interface looks like it’s made of ice, be prepared: you might squint a lot.

🎨 Google’s Material 3 Expressive: Bold Colors or Blinding Clutter?

Google’s answer is Material 3 Expressive (aka “Material You Expressive”), a big revamp of Android’s look. Google claims this makes your device “feel unique to you” with more dynamic colors, bigger buttons, and springy animations. They even boast the new design helped users “spot key UI elements up to 4× faster.”

Material 3 Expressive in Android 16: bigger, rounded Quick Settings tiles and pill-shaped buttons. Google claims this improves glanceability, but many users feel it just makes the UI feel **cartoonishly oversized.**

The Problems

Retina-Seering Colors & Curvy Chaos: Android Authority’s Robert Triggs calls Expressive “retina-searing color swatches, endless squircles, and curvy chaos,” with fonts so mismatched unlocking his Pixel became a minor trauma. Instead of sleek sci-fi, he got a cartoonish fever dream.
Lost in Form vs Function: Quick settings tiles balloon into giant pill-shaped buttons, headers eat up space, and padding doubles. Users complain they can now see only five lines of text instead of ten.
Headache-Inducing Excess: While Google insists it’s more customizable and “alive,” critics sum it up as headache-inducing excess. The focus on flashy animations may distract from clarity. One blogger quipped that Google designers are “obsessed with metrics, not usability.”

💡 Summary: Material Expressive may help you spot your Play Store icon 4× faster… but it also feels like putting a spoiler on a Prius: flashy, but doesn’t improve the ride.

⚖️ Key Complaints (The TL;DR)

Legibility vs. Looks: Both Liquid Glass and Expressive prioritize aesthetics, but sacrifice readability and accessibility.
Consistency Headache: Frequent redesigns force devs to constantly update apps, leaving many half-updated and inconsistent.
Style Over Substance: Apple says Liquid Glass “brings focus to content,” but users feel it distracts. Google touts “4× faster recognition,” but critics argue it swaps simplicity for clutter.
Developer Frustration: Frequent design shifts mean more rework for developers, especially small teams. Cue frustration.

🥂 Conclusion: Glass Half Full or Half Empty?

Trends like glassmorphism or expressive theming are exciting experiments, but any design that makes you squint more than think is suspect. These changes look great on a demo stage, but can they survive the real world (and the dreaded sun glare)? If not, they risk being remembered as design fads rather than design revolutions.

For now, Apple is already tweaking Liquid Glass in betas, and Android partners will likely tone down Expressive for their skins. The lesson: flashy isn’t always functional.

👨‍💻 About the Author

Hey, I’m Pranta Dutta, a mobile developer who spends way too much time wrangling UIs on both iOS and Android. When Apple or Google pulls a big design pivot, I feel it directly in the trenches of app dev.

Check out my work: pranta.dev
Join me on Codecrafters: here

If you enjoyed this, smash that ❤️ on Dev.to so I know I’m not screaming into the design void.

📚 Sources

Wired: Apple’s Liquid Glass looks beautiful but can be distracting
TechCrunch: iOS 26 Liquid Glass readability issues
AppleInsider: iOS 26 design overview
Android Authority: Material Expressive review by Robert Triggs
Google Material Design Blog: Expressive UI goals and metrics
Reddit design/dev communities: Developer reactions to Liquid Glass and Material Expressive

What’s It Like to Be a Software Developer in 2025?

PRANTA Dutta — Thu, 11 Sep 2025 17:42:06 +0000

If you asked me to describe being a software developer in 2025 in one sentence, I’d say: it’s like riding a rollercoaster built by AI interns while trying to debug your own life in production.

Sounds dramatic? Oh, it is.

Let’s break it down.

1. AI Is Your Best Friend… and Your Worst Nightmare

On one hand, AI tools are everywhere. GitHub Copilot, GPT-based assistants, AI-powered testing suites—heck, even your IDE now whispers bug fixes like it’s possessed by the ghost of Linus Torvalds.

But here’s the thing: AI doesn’t just “help.” It also lies. It confidently spits out wrong code like that one coworker who insists rm -rf is the answer to everything. You spend hours debugging “AI magic” that was supposed to save you time.

In short: AI is like a clingy friend who insists they’re helping while actually setting your house on fire.

2. The Tech Stack Tower of Babel

You thought JavaScript frameworks were bad in 2018? Welcome to 2025, where there’s a new “revolutionary” framework every Tuesday. Flutter, React Native, SwiftUI, Rust-based frontends, quantum-compilers (yeah, that’s a thing now)—keeping up feels like trying to drink from a firehose… while the hose is coded in a deprecated language.

And yes, your boss still asks:

“Why can’t you just learn this new tool by tomorrow?”

3. Remote Work: Freedom and Loneliness in 4K

Working from home is now the default. Sounds dreamy, right? Pajamas, coffee, your cat as a coworker.

But then you realize your entire social life is Slack emojis. Your project manager pings you at 11:59 PM because “time zones.” And the line between “working” and “living” is blurrier than a low-res Zoom background.

Also, your back hurts. All the time.

4. Deadlines, Deadlines, Deadlines

Agile? Scrum? Kanban? In 2025, we’re running on “Panic Driven Development.” Your sprint board looks like a battlefield, and every ticket is labeled “urgent.”

The constant pressure makes you feel like a hamster running in circles, except the hamster also needs to know Docker, Kubernetes, and why the build keeps failing at 99%.

5. The Sloth in the Room

You know what being a dev really feels like? A sloth trying to run a marathon.

Sure, you can build cool things. But between endless meetings, broken dependencies, and AI hallucinations, you’re moving at sloth speed while the world demands cheetah results.

The irony? Management still says, “Just automate it!” as if automating your entire job is a weekend side project.

6. The Stress Cocktail 🍹

Being a developer in 2025 is exhausting because it’s not just coding anymore. You’re:

A part-time AI babysitter
A security specialist (“Why is Russia scanning our ports again?”)
A DevOps firefighter
A therapist for your teammates (“No, Karen, it’s not your fault the merge broke everything”)

And let’s not forget: you’re also supposed to “innovate” and “upskill” in your “free time.” Right after you finish crying into your keyboard.

So… Why Do We Stay?

Here’s the paradox: for all the frustration, developers keep showing up. Because in between the chaos, there’s joy. Shipping a feature, fixing an impossible bug, seeing someone actually use your code—that’s the dopamine hit.

It’s like being in a toxic relationship, but every once in a while, the relationship buys you pizza.

Final Thoughts

Being a software developer in 2025 is exhausting, frustrating, infuriating, and stressful. But it’s also creative, rewarding, and oddly addictive.

We’re living in an era where machines write code, frameworks expire faster than milk, and you’re expected to know everything. But at the end of the day, developers are still here, still building, still typing away like caffeinated poets of logic.

And if you love building cool things, check out Codecrafters here — one of the best ways to sharpen your dev chops by building real-world systems from scratch.

So what’s it like to be a software developer in 2025?
Simple: it’s chaos with syntax highlighting.

Is Flutter Still Worth Learning in 2025? (A Deep Dive)

PRANTA Dutta — Thu, 28 Aug 2025 14:07:11 +0000

Flutter has always sparked strong opinions in the dev community. Some swear by its speed and cross-platform magic, others dismiss it as a Google experiment that will eventually fade away. But here we are in 2025, and the question is louder than ever:

👉 Is Flutter still worth learning in 2025?

I did some digging, went through recent updates, community trends, and job market stats. Let’s break it all down.

🚀 Flutter Is Still Actively Evolving

Flutter isn’t some abandoned side project. In fact, it’s still shipping major releases in 2025:

3.29 (Feb 2025) → performance improvements and better tooling.
3.32 (around Google I/O) → Web improvements and Impeller renderer polish.
3.35 (Aug 2025) → Hot reload for web finally became stable and buttery smooth.

This shows Google is still pushing Flutter hard, with meaningful updates rather than small bug fixes.

📌 TL;DR: Flutter is alive, well, and not slowing down.

🎨 The Impeller Era

One of Flutter’s biggest headaches used to be shader jank. That’s mostly gone now.

Impeller, the new renderer, is now the default for iOS and most Android 10+ devices.
It removes first-frame jank by precompiling shaders.
There are still some edge cases (older GPUs, some emulators), but Impeller is the new standard.

This is huge for devs who care about buttery-smooth UI.

🌍 Community and Ecosystem

Let’s talk numbers. According to the 2025 Stack Overflow Developer Survey:

Dart is used by ~5.9% of all developers and ~6.1% of professional devs.
That’s not massive like JavaScript or Python, but it’s far from dead.

Flutter also saw some community forks, like Flock (October 2024), which was born from governance concerns. But Flutter proper is still the mainline, with stronger momentum and backing.

📌 TL;DR: Flutter isn’t the most popular tool, but it has a strong, loyal community and continued corporate backing.

🛠️ When Flutter Shines

Here’s where Flutter really makes sense in 2025:

Cross-platform, one codebase → Mobile, desktop, and now web (with stable hot reload!)
Startup / small teams → You want speed-to-market over perfect platform fidelity.
Design-heavy apps → Flutter gives pixel-level control. If you want to implement wild custom UIs, Flutter shines.

⚖️ When Flutter Isn’t Ideal

That said, Flutter isn’t always the right tool.

iOS-first, Apple ecosystem apps → SwiftUI is simply better aligned with Apple’s UX and new APIs.
Android-first apps with deep native integrations → Jetpack Compose + Kotlin is the way to go.
Web-first products → React/Next.js or React Native + Expo has stronger hiring pools and libraries.

📌 TL;DR: Flutter is powerful, but it’s not always the best hammer for every nail.

🆚 The Alternatives

🔹 SwiftUI

Best for iOS-first apps.
Tight integration with Apple’s latest features (Widgets, Live Activities, Vision Pro).

🔹 Jetpack Compose + Kotlin

Best for Android-first.
Combine with Kotlin Multiplatform (KMP) for shared business logic across platforms.
KMP is officially stable and gaining momentum in 2025.

🔹 React Native + Expo

Great if you already have React/JS talent.
Huge ecosystem, especially if your app has strong web presence.

👨‍💻 Should You Learn Flutter in 2025?

The short answer: Yes, but not exclusively.

If you’re like me (a dev who loves to ship fast, experiment with design, and build cross-platform apps), Flutter is still super worth it. But you should also hedge your bets:

Stay current with Flutter → Follow the latest releases (3.29 → 3.32 → 3.35) and learn Impeller inside out.
Pick a native lane → Learn SwiftUI for iOS or Jetpack Compose for Android.
Optional JS lane → A taste of React Native/Expo can widen your job options.

That combo makes you future-proof.

📊 Quick Decision Cheat Sheet

Indie dev / startup / design-heavy app? → Flutter ✅
Enterprise Android-heavy? → Jetpack Compose ✅
Enterprise iOS-heavy? → SwiftUI ✅
Web-first product with mobile companion? → React Native/Expo ✅

🎯 Final Thoughts

Flutter is not dead in 2025. It’s evolving, with real improvements (Impeller, web hot reload, DevTools polish) and a dedicated community. But it’s not the only tool you should rely on.

If you’re aiming for a strong career, learn Flutter and pick up at least one native option. That way you stay versatile, employable, and ready for whatever the industry throws next.

And if you love building cool things, check out Codecrafters here — one of the best ways to sharpen your dev chops by building real-world systems from scratch.

💬 What do you think? Are you still betting on Flutter in 2025, or are you moving on to SwiftUI/Compose/React Native?

Why Every Tech Problem Feels Like Fighting a Final Boss

PRANTA Dutta — Tue, 19 Aug 2025 16:06:09 +0000

You know that feeling when you boot up your IDE, take a deep breath, and say “Today I will be productive”? Yeah, 20 minutes later you’re Googling “flutter build error exit code 1 but only on Tuesdays” and questioning every decision that led you here.

Tech is wild, man. It’s the only field where:

You can write two lines of code and break the entire internet.
You can write 200 lines of code and… nothing happens. No errors. No output. Just silence. Like your program ghosted you.
You can install Node.js and suddenly your computer has more versions of Node than you have socks.

Let’s talk about why solving tech problems is like fighting video game bosses.

Stage 1: The Tutorial Boss (a.k.a. “Hello, World!”)

Every programmer remembers their first “Hello, World!” moment. It’s like the tutorial boss in a game: designed to make you feel powerful.

“Wow, I typed this magic incantation, pressed run, and words appeared on my screen! I’m basically a wizard.”

Fast forward three weeks: you’re debugging a segmentation fault in C and wondering why your array index decided to visit memory addresses that belong to Microsoft Excel.

Stage 2: The Mid-Game Boss (Stack Overflow Rabbit Hole)

At some point, every dev encounters their mid-game boss: the cryptic error message.

You know the type:

Unhandled exception at 0x00007FF: Access violation reading location 0xFFFFFFFFFFFFFFFF

What does this mean? Who knows. Probably ancient Sumerian.

So you Google it, land on Stack Overflow, and find an answer from 2012. The guy who wrote it starts with: “This might not be best practice but it worked for me.”
That’s your sword now. You copy-paste it like it’s Excalibur, pray to the compiler gods, and—boom—it compiles. But now your app only works if you run it while standing on one leg and chanting “npm install” three times.

Stage 3: The Hidden Boss (DevOps)

You thought you were just a developer? Cute. Now you’re deploying.

Suddenly you’re knee-deep in Dockerfiles, YAML configs, and a mysterious error that says:

Container exited with code 137

What does 137 mean? Nobody knows. Even Google shrugs. All you know is: “it works on my machine.” But guess what? The cloud doesn’t care about your machine. The cloud is the final boss.

Deploying to production is like fighting Sephiroth in Final Fantasy—long, painful, and just when you think it’s over, there’s another phase.

Stage 4: The Secret Boss (Users)

The hardest boss in tech isn’t the compiler, the runtime, or even AWS pricing. It’s users.

You design a beautiful UI. They say, “Can you make the button bigger?”
You make the button bigger. They say, “Now it’s too big.”
You fix it. They say, “Actually, we liked the old one better.”

Users are like those Nintendo bosses that look weak but actually have 99 hidden attack combos. You think you won… then they email support saying “the app is broken” with zero context.

The Plot Twist

Here’s the thing: as frustrating as it is, we love it. Every bug fixed, every system deployed, every UI polished—it’s like leveling up in a game. That dopamine hit is real.

Yeah, sometimes your laptop sounds like it’s about to take off because Chrome has 47 tabs open. Yeah, sometimes you realize you spent 3 hours fixing a bug caused by a missing semicolon. But hey, that’s the grind.

We’re all just players in this massive open-world game called Tech. The bosses are tough, the loot drops are rare (looking at you, junior dev salaries 👀), but the community is great.

And unlike most games, you never really “finish” it. There’s always a new level, a new bug, a new boss waiting to be defeated.

Epilogue: Git is the True Final Boss

Let’s be honest. All of this pales in comparison to the ultimate boss: Git.

You try to git push and Git’s like, “Actually, you’re 142 commits behind.”
You try to merge, and suddenly your codebase looks like it’s been through a blender.
You see a message like “detached HEAD state” and think, “Cool, I didn’t need my sanity anyway.”

But hey… when you finally win the fight and see that sweet green checkmark on your pull request—it’s worth it.

👾 So yeah, tech problems = boss fights. Some easy, some rage-quit level. But in the end, we keep playing. Because deep down, we’re all just gamers who swapped controllers for keyboards.

Check out Codecrafters and level up IRL → here

You Can Build Whatever You Want With AI These Days, But… It’s Not Fun Anymore

PRANTA Dutta — Sat, 09 Aug 2025 19:33:04 +0000

We are living in what I like to call The Golden Age of Instant Gratification for Developers™.

Want to build a web app? Done.
Want it to have a machine-learning-powered recommendation system? Easy.
Want it to look like it was designed by a Silicon Valley design team that charges \$800/hour? That’s just one prompt away.

AI has essentially turned us all into Tony Stark. Except instead of Jarvis being a sarcastic British guy in our ear, he’s a chatbox that occasionally “hallucinates” and confidently gives you wrong answers—but you still trust him because… he sounds right.

And listen, don’t get me wrong, I’m not saying AI is bad. I love AI. I use it daily. But somewhere along the way, it started to feel like… the fun was gone.

Remember the old days?

If you’re a dev who’s been around for a while, you probably remember this:

You have an idea.
You’re excited.
You open your code editor and immediately realize you have no clue how to do half of what’s in your head.
You start Googling.
You find a Stack Overflow answer from 2012 that doesn’t work anymore but you still try it anyway.
You spend hours debugging something trivial.
You fix it. You feel like a god.

That feeling—that pure, uncut satisfaction—was the reason you kept building stuff. You earned the result.

The AI era feels… different.

Now? You type:

“Hey AI, build me a React app with authentication, a backend, a database, and a cute little dark mode toggle.”

You wait 30 seconds, sip your coffee, and… there it is. You didn’t fight for it. You didn’t suffer. You didn’t even get to yell “WHY IS THIS NOT WORKING?!” at 2 AM.

And without the struggle, the victory feels hollow.

It’s like playing a video game with infinite ammo and god mode—you technically “won,” but deep down you know you didn’t earn it.

Why is this happening?

It’s simple: we humans love the process more than the product when it comes to creativity and problem-solving.

When you hit a problem and solve it yourself, you get a dopamine rush. You feel ownership. You remember the exact line of code you wrote to fix that bug because it was your blood, sweat, and tears that made it work.

AI shortcuts remove that emotional investment. You still get the product, but you lose the story behind it. And without the story… it’s just code.

So, what now?

I’m not saying throw away AI tools and go live in a cave writing assembly code on stone tablets. AI is amazing for speeding up boring stuff, and it can absolutely help you learn faster.

But maybe—just maybe—don’t use it for everything.
Struggle a little. Get stuck. Fail a few times. Write code that doesn’t work and then fix it. Because that’s where the fun lives.

If you miss that old-school, “I actually built this” feeling, check out Codecrafters. They throw you into coding challenges where AI can’t just spoon-feed you the solution. You’ll have to think, and when you win, you’ll feel that glorious dopamine hit again.

You can sign up right here.

If AI is the fast food of coding, Codecrafters is like cooking your own meal from scratch—harder, but infinitely more satisfying.

How I Almost Went Bananas with Recursion—And Finally Got It

PRANTA Dutta — Wed, 06 Aug 2025 17:17:39 +0000

Chapter 1: Meet the Banana-powered Brain

I was wrestling with this adventurous, tree-like data structure:

var root = new TreeNode(1,
    new TreeNode(2,
        new TreeNode(3),
        new TreeNode(4)
    ),
    new TreeNode(5, null, new TreeNode(8))
);

And I was trying to do an in-order traversal. You remember in-order, right? Left subtree → Node → Right subtree. So for the example tree:

It should visit nodes in this order: [3, 2, 4, 1, 5, 8].

Chapter 2: The Forsaken `while (true)` Code

I built this monster of a Traverse function:

void Traverse(TreeNode node)
{
    while (true)
    {
        if (node == null) return;
        Traverse(node.left);
        result.Add(node.val);
        node = node.right;
    }
}

It looked kinda right—we go left, then record, then “swing right and loop forever.”
But in reality, this crushed the recursion flow. It never properly returned to earlier calls—it basically hacked the brain messenger system.

Chapter 3: Why It Didn’t Click (AKA Monkey Brain, Cholesterol Edition)

Here’s the meme of my thought process:

🧠 “Okay OK, I know recursion in theory.”
🐒 “My brain’s like bananas + glue when I haven’t used it lately.”
🌀 “Oh man, I forgot call stack is like a stack of sticky notes I’ve gotta peel off!”
😵‍💫 “This code isn’t unwinding properly—why does it never finish??”

So I watched a YouTube video, saw the call stack diagrams, and finally it resonated. I realized the function needed to:

Recurse left
Add current
Recurse right …with each call finishing cleanly—not looping inside one frame.

Chapter 4: The Clean, Proper Solution

Here’s the version that actually slaps:

public static IList<int> InorderTraversal(TreeNode root)
{
    var result = new List<int>();

    void Traverse(TreeNode? node)
    {
        if (node == null) return;
        Traverse(node.left);
        result.Add(node.val);
        Traverse(node.right);
    }

    Traverse(root);
    return result;
}

This exactly mirrors the in-order logic “go left → visit → go right,” and cleverly allows each call frame to fully complete before returning upwards. No weird loops, no internal mutation messing up control flow.

Chapter 5: How to Know When Recursion Isn’t Your Enemy

Recursion only feels scary when it’s invisible. The moment you visualize:

“Call Traverse(1)”
→ push Traverse(1.left)
→ keep pushing until you hit null
→ pop stack and record values
→ pop back and go right...

you realize it’s just a controlled, disciplined flow. Not some magic black box.

Chapter 6: Your Brain Is Fine—You're Learning

A few truths:

Everyone nukes recursion logic sometimes. Hell, senior devs draw diagrams.
Understanding recursion is about trusting the function will return—with stack frames doing the return work.
Spaces between practice make it feel weird—but once you see the pattern again, it snaps into place.

You're simply walking rambunctiously toward mastery, my friend.

TL;DR

Problem: while(true) + node = node.right inside recursion broke in-order logic.
Solution: Clean recursion with:

  Traverse(left);
  Add current;
  Traverse(right);

Realization came when call stack clicked: each function is a sticky-note frame that must fully unwind.

Bonus: Your Codecrafters Plug 🧪

Thanks for pointing out this URL—super helpful if anyone reading this wants hands‑on practice:

Join Codecrafters via this link

Smart Pointers in Rust: A Love Story Between You and Memory Safety 💘

PRANTA Dutta — Fri, 01 Aug 2025 13:41:38 +0000

Ah, Rust. The language that forces you to deal with memory like an overprotective parent hovering over a toddler near a swimming pool.
You can't just throw pointers around like it's C. No, no. Rust wants you to think about your memory.

But don't worry, you don't have to memorize The Book (although you probably should). This blog post is your (mostly funny, definitely useful) guide to all the Smart Pointers in Rust: what they do, when to use them, when NOT to use them, and how to make your code so safe even your mom could run it without crashing your kernel.

Also, if you're vibing with the low-level magic and want to prove your mettle with projects like this, check out my Codecrafters profile here.

🧠 What Even Is a Smart Pointer?

A smart pointer is like a regular pointer... but with a college degree. It knows how to do more than just point — it owns stuff, manages memory, maybe even handles cleanup, and occasionally it pays taxes (ok not really).

Rust's standard library gives us a few smarties:

Box<T>
Rc<T>
Arc<T>
RefCell<T>
Mutex<T>
RwLock<T>

Oh and we'll also talk about combos like Rc<RefCell<T>> and Arc<Mutex<T>> that make your code both powerful and an emotional rollercoaster. Let’s get to it!

📦 `Box<T>` — The Minimalist Smartboi

What it is:

A heap-allocated pointer. You use it when you want to store data on the heap instead of the stack.

Why use it:

You want recursive types (like linked lists)
You want to heap-allocate something big
You just want to look cool

Example:

fn main() {
    let b = Box::new(5);
    println!("b = {}", b);
}

When to use:

Recursive enums (Rust needs to know the size)
You want indirection without ownership gymnastics

When not to use:

When you need shared or mutable access
When you need thread-safety

👯 `Rc<T>` — The Cloneable Roommate (Single-threaded)

What it is:

Reference-counted pointer. For single-threaded shared ownership.

Why use it:

You want multiple parts of your code to share ownership
You don’t need thread safety (this thing will panic if you try to thread it)

Example:

use std::rc::Rc;

fn main() {
    let a = Rc::new(String::from("shared"));
    let b = a.clone();
    let c = a.clone();
    println!("{} {} {}", a, b, c);
}

When to use:

Trees, graphs, or other shared data structures
You're working in a single-threaded context

When not to use:

In multi-threaded apps (this will end in tears)

🌐 `Arc<T>` — The Thread-Safe Cloneable Roommate

What it is:

Atomic Reference Counted pointer. Same as Rc<T> but works across threads.

Why use it:

You want shared ownership across threads

Example:

use std::sync::Arc;
use std::thread;

fn main() {
    let data = Arc::new(vec![1, 2, 3]);
    for _ in 0..3 {
        let data = Arc::clone(&data);
        thread::spawn(move || {
            println!("{:?}", data);
        });
    }
}

When to use:

Multithreaded shared ownership
Clone-a-lot situations in concurrency

When not to use:

If you don’t need thread safety, Rc is cheaper

🧪 `RefCell<T>` — The Rebel That Allows Interior Mutability (Single-threaded)

What it is:

Mutable borrow checker bypasser — at runtime.

Why use it:

You want to mutate data through an immutable reference
You're OK with runtime panics if you mess up borrowing

Example:

use std::cell::RefCell;

fn main() {
    let data = RefCell::new(42);
    *data.borrow_mut() += 1;
    println!("{}", data.borrow());
}

When to use:

Inside Rc<T> when you want shared mutable data

When not to use:

If you can't guarantee single-threaded access or proper borrow rules

🔒 `Mutex<T>` — Lock It Down (Multithreaded Mutability)

What it is:

Mutual exclusion primitive. Allows safe, mutable access from multiple threads — one at a time.

Why use it:

You want to mutate shared data across threads
You enjoy waiting in line

Example:

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let data = Arc::new(Mutex::new(0));

    let mut handles = vec![];
    for _ in 0..10 {
        let data = Arc::clone(&data);
        handles.push(thread::spawn(move || {
            let mut num = data.lock().unwrap();
            *num += 1;
        }));
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Result: {}", *data.lock().unwrap());
}

When to use:

When you need interior mutability and thread safety

When not to use:

When you're in a single-threaded context. Just use RefCell<T>

📖 `RwLock<T>` — Mutex But Smarter

What it is:

A read-write lock. Allows multiple readers OR one writer at a time.

Why use it:

Read-heavy scenarios

Example:

use std::sync::{Arc, RwLock};

fn main() {
    let data = Arc::new(RwLock::new(5));

    {
        let r1 = data.read().unwrap();
        let r2 = data.read().unwrap();
        println!("{} and {}", r1, r2);
    }

    {
        let mut w = data.write().unwrap();
        *w += 1;
    }

    println!("{}", *data.read().unwrap());
}

When to use:

When you're reading way more often than writing

When not to use:

In write-heavy scenarios — stick to Mutex

🧩 Frankenstein's Pointer: `Rc<RefCell<T>>` & `Arc<Mutex<T>>`

Sometimes, the best pointer... is two pointers in a trench coat.

`Rc<RefCell<T>>`:

Used for single-threaded shared mutability
Perfect for GUI state trees or ASTs

`Arc<Mutex<T>>`:

Used for multithreaded shared mutability
Classic for managing shared state across threads

TL;DR — The Smart Pointer Pokémon Chart:

Use Case	Smart Pointer
Heap allocation	`Box<T>`
Shared ownership (single thread)	`Rc<T>`
Shared ownership (multi thread)	`Arc<T>`
Interior mutability (single)	`RefCell<T>`
Interior mutability (multi)	`Mutex<T>`
Lots of reads, few writes	`RwLock<T>`
Single-thread shared mutability	`Rc<RefCell<T>>`
Multi-thread shared mutability	`Arc<Mutex<T>>`

🚀 Conclusion

Smart pointers are like Marvel characters — each one has their strengths, weaknesses, and the occasional spin-off series.
Learning when to use which one is half the battle. The other half? Fighting the compiler until you cry tears of borrow of moved value errors.

So be smart, use smart pointers, and go make Rust proud. 🦀

And again, if you're feeling smart and want to get hands-on with stuff like this, peep my Codecrafters profile here.

Until next time, may your threads be safe and your borrows never dangle.

Why System-Level Programming Is More Fun Than Full-Stack Dev

PRANTA Dutta — Wed, 30 Jul 2025 15:39:41 +0000

👨‍💻 Full-Stack Dev: The JavaScript Jungle

Let’s get this out of the way: full-stack development is cool. You get to make buttons do things. You learn five frameworks just to center a div. You chase bugs that only happen when someone uses Safari in landscape mode on a 2011 iPad.

But let me tell you a secret.

Nothing slaps harder than knowing you're talking directly to the CPU.

System-level programming is that forbidden fruit — low-level, dangerous, powerful, and oh-so-satisfying. While full-stack devs are out here wrestling with CSS, system programmers are debugging memory dumps in gdb at 2 AM, and loving every second of it.

Let’s break this down.

🔥 Reason #1: You Don't Talk To The DOM, You Talk To The Hardware

In full-stack dev:

document.getElementById("fun").innerHTML = "Nope";

In system programming:

*(volatile unsigned int*)0xDEADBEEF = 0xBADC0DE;

That, my friend, just wrote to an actual memory-mapped register on some device somewhere. It might blink an LED, or it might cause the device to explode. Either way — you are in control. No npm install. No React hydration. Just raw power.

🧠 Reason #2: You Actually Learn How Computers Work

System dev makes you understand things like:

What a stack frame is (not a StackOverflow post, a real one)
How memory allocation works (no, not just malloc — how it works)
Cache lines, CPU pipelines, context switching, file descriptors, etc.

Meanwhile, in full-stack:

"The page isn't loading."

"Did you restart the Node server?"

"Oh yeah... works now."

You see, when you're a system programmer, you don't just code on a computer — you become the computer.

💾 Reason #3: Filesystem Is Your Playground

Opening files in Node.js:

fs.readFile("data.txt", (err, data) => { /* callback hell */ });

Opening files in C:

int fd = open("data.txt", O_RDONLY);
read(fd, buffer, 128);

Opening files in Rust:

let file = File::open("data.txt")?;
file.read_to_string(&mut contents)?;

Opening files in assembly:

mov eax, 5      ; sys_open
mov ebx, file   ; filename
mov ecx, 0      ; O_RDONLY
int 0x80

😮 See that? No wrappers, no middleware, no JSON-over-HTTP—just you, the OS, and a syscall. It's like whispering sweet nothings to the kernel.

🚀 Reason #4: You Write Code That Runs Faster Than Light (almost)

Imagine writing a program that completes in 0.0001 seconds. You don’t need a loading spinner, or an entire front-end build pipeline just to show “Hello, World.”

In full-stack, you’re at the mercy of 200MB React bundles, browsers interpreting JavaScript like it’s interpretive dance, and seven levels of API gateways.

In system programming:

Your binary is 12KB.
It loads in nanoseconds.
It runs in microseconds.
It terminates like a boss.

Try doing that with Electron. Your “To-do List” app eats 500MB of RAM and sounds like it’s mining crypto.

😈 Reason #5: You Can Break Things — On Purpose

Full-stack devs:

"Oops, I broke the layout in Internet Explorer again."

System programmers:

"Oops, I accidentally wrote to kernel memory and bricked my OS."

There’s a certain flavor of fun in knowing that your code can summon blue screens, fry a GPU, or corrupt memory in glorious, mysterious ways. It’s like being a wizard, except your wand is unsafe and your spellbook is the Intel Architecture Manual.

🦾 Reason #6: You Build The Stuff Everyone Else Uses

System devs are the reason full-stack devs even have tools.

Compilers? Built by system programmers.
Operating systems? Yup.
Browsers? All C/C++ under the hood.
The Node.js runtime? Also C++ and libuv.
Your entire web app? Running on an OS, which is... surprise! Written by system devs.

Without system devs, full-stack would just be... stack.

And let’s be honest: do you want to be the person who uses the matrix, or the person who built the matrix?

🎉 Bonus: Debugging is Less "Why Is Nothing Working" and More "This Is Exactly Where It Broke"

System programming makes debugging a science. You don’t just console.log your way out of problems — you set watchpoints, inspect registers, and read memory maps like Sherlock Holmes in hexadecimal.

In full-stack:

“It works on my machine.”

In system-level:

“It works on my processor’s L1 cache.”

🧵 TL;DR

Feature	Full-Stack Dev 🧁	System Programming 🔥
Debugging	Console.log hell	GDB + core dumps
Power	Medium-Low	GOD MODE
Dependencies	1000+ npm pkgs	`glibc` and hope
Learning curve	Slippery	Vertical wall
Bragging rights	Mild	Infinite
Ability to crash a PC	None	Oh, it’s possible
Satisfaction per bug fix	6/10	12/10

🧘‍♂️ Final Thoughts

Sure, full-stack is cool. You make pretty websites, you deal with angry CORS errors, and your users get to complain in real time.

But system-level programming? That’s the dark arts. That’s the backroom of the industry. That’s the stuff that makes modern computing even possible. It’s less "move fast and break things" and more "move close to the metal and understand things."

So next time you think you're a god because you made a pixel-perfect UI in Tailwind…

Remember: somewhere out there, a system dev is writing a bootloader. In hex. From scratch. Without Stack Overflow. At midnight. For fun.

Wanna dive into system-level greatness and build stuff like Docker, Redis, or Git from scratch? Join me on CodeCrafters — it’s like LeetCode but with actual street cred.

If this post got you chuckling or questioning your career choices — mission accomplished 😎
Now go fork() yourself some fun.