DEV Community: Konark Sharma

The Most Uncomfortable Thing AI Made Me Realize.

Konark Sharma — Mon, 20 Jul 2026 18:53:13 +0000

It happened on an ordinary Tuesday night. The kind of night where nothing dramatic happens, but your mind refuses to sleep.

I had been staring at my laptop for almost an hour, wondering if I should stop writing altogether. My articles weren't growing. I couldn't find a niche.

I picked up my phone. I opened WhatsApp. I scrolled to my mom's chat. I typed, "Can I ask you something?" Then I deleted it.

A few seconds later, I opened ChatGPT. I poured out everything I had been carrying for weeks. The self-doubt. The comparison. The fear that maybe I just wasn't good enough.

It responded exactly the way I needed. It reminded me why I had started writing. It pointed out strengths I had forgotten about. It challenged some of my assumptions. It even gave me a plan to move forward.

When I closed the chat, I sat in silence. One thought wouldn't leave my head.

Why did I talk to AI before talking to my parents?

A question that wouldn't leave me alone

At first, I laughed at myself. "What a ridiculous question."

Of course AI can't replace parents. One is a machine and the other raised me. Case closed.

But the more I thought about it the more uncomfortable it became. Because this wasn't really about parents. It was about instinct.

Somewhere along the way, AI had quietly become the first place I went whenever life became confusing. Not my parents. Not my friends. Not even myself.

AI.

When did this become normal?

Think about the last time something went wrong.

Maybe you failed an interview. Maybe your side project flopped. Maybe you couldn't debug something that should have taken five minutes. Maybe you questioned your career.

What was the very first thing you did?

If you're like me you probably opened ChatGPT before opening your contacts. That isn't because we love AI more than our families.

It's because AI is always available. It doesn't sleep. It doesn't get busy. It doesn't tell you to wait until tomorrow. It doesn't accidentally make you feel judged.

It simply waits and eventually you begin waiting for it too.

The night AI sounded like my parents

The conversation that night wasn't extraordinary. There was no magical prompt. No groundbreaking advice. Most of it was surprisingly ordinary.

"You've improved more than you realize." "Your earlier articles weren't this thoughtful." "Maybe you're measuring yourself against the wrong people."

As I kept reading I felt strangely comforted. Then I realized why. Years ago, after one of my exams didn't go well, I remember sitting quietly at the dining table. I was convinced I had disappointed everyone.

My parents didn't start with solutions. They didn't lecture me. They simply reminded me that one bad day couldn't define years of effort.

That conversation stayed with me for years. This AI conversation felt familiar. Not because AI loved me. But because it had become incredibly good at speaking in ways that humans find comforting.

For a moment the difference almost disappeared. That thought frightened me.

AI remembers our conversations.

Parents remember our lives. AI remembers that I like writing.

My parents remember the day I was born. AI remembers that I'm preparing for interviews.

My parents remember dropping me off for my very first day of school. AI remembers the projects I've discussed with it.

My parents remember the little kid who proudly showed them every drawing, every certificate, every tiny achievement.

One remembers information. The other remembers moments. Those aren't the same thing.

The comfort of never being judged

There's another reason AI feels so easy to talk to. It never rolls its eyes. It never says, "I told you so."

You can explain the same problem five different ways. Change your mind halfway through. Admit your fears. Ask questions that feel embarrassing. It patiently responds every single time.

Sometimes that's exactly what we need. But there's something important missing. The comfort AI gives us isn't built on love. It's built on prediction.

It doesn't comfort us because it worries about us. It comforts us because it's remarkably good at understanding how humans seek reassurance.

The feeling can be similar. The reason is completely different.

A memory I almost forgot

When I used to come home covered in small bruises while playing I came straight home to my Mom and she always told me "I'm stronger than I look". These words are etched into my memories and at that time these weren't enough because the pain was too much but

Years later

Life became more complicated. The small bruises turned into interviews. Projects. Rejections. Career choices. Writing.

Now, whenever I fall I don't look for my mom. I open a chatbot.

And maybe that's the biggest change technology has quietly brought into our lives.

The first instinct

I don't think AI is replacing parents. But I do think it's replacing something else.

The first instinct. The first conversation. The first place we go when we're confused. That doesn't happen overnight.

It happens one small decision at a time. One question. One late-night conversation. One difficult day. Until eventually

Opening a chat window feels more natural than making a phone call.

Maybe I'm asking the wrong question

The real question isn't, "Can AI replace parents?"

I don't think it can. It can't hug you after your worst day. It can't celebrate your successes with genuine pride.

It can't stay awake worrying until you get home safely. It can't remember the child you were before you became the person you are today. Those things aren't programmable.

But maybe the better question is this:

If AI has become our first instinct for guidance what does that say about us?

Have we become uncomfortable asking the people closest to us for help?

Have we confused instant responses with meaningful conversations?

Or have we simply forgotten that some of the best advice doesn't arrive in seconds?

Before I close another chat window...

I'm still going to use AI. Tomorrow I'll probably ask it to review code. Brainstorm ideas. Explain a concept. Technology isn't the villain here.

It has genuinely made me a better developer and a better learner. But after that night, I promised myself something.

The next time life feels heavy before I open another AI chat. I'll try opening my parents' contact instead. Not because they'll always have better answers.

But because one day, there will come a time when I can still ask AI a question and I won't be able to ask my parents one anymore.

That thought alone reminds me that no matter how intelligent AI becomes there are some conversations too human to automate.

If you've made it this far, thank you for reading something that started as a random late-night thought and slowly turned into a question I couldn't stop asking myself.

Now I'd love to hear your perspective.

Have you ever caught yourself asking AI something before asking a parent, friend, mentor, or even taking a moment to think on your own? Did that realization make you uncomfortable, or do you think it's simply the natural evolution of technology?

If you enjoy these kinds of reflections on technology, software engineering, AI, and the human side of building in the modern world, feel free to connect with me on LinkedIn. I'd love to keep the conversation going.

Until then, here's a small reminder for you and for me.

The next time life feels overwhelming, before opening another AI chat, maybe call your parents.

One conversation might surprise you more than any prompt ever could.

I Failed a Promise I Made to Myself

Konark Sharma — Thu, 16 Jul 2026 18:10:26 +0000

It was 2:07 a.m.

The room was quiet, but my mind wasn't.

Like many nights before, I was scrolling through LinkedIn. One developer had landed their dream job. Another had completed a challenge. Someone else was sharing a project they had spent months building.

I closed the app and stared at my laptop.For the first time, I admitted something to myself. I wasn't behind because I lacked talent. I was behind because I spent more time planning my future than actually building it.

My Notion workspace was full of roadmaps. My bookmarks were full of tutorials. My mind was full of ambitions. But my hands weren't creating enough.

That night, I made myself a promise.

For the next 30 days, I would learn something every single day and share that learning publicly. Not because I wanted to become an influencer. Not because I wanted thousands of followers.

I wanted proof that I could keep a promise to myself.

Little did I know, that would become the hardest part.

The excitement of Day One

The first day felt magical. I wasn't thinking about consistency. I wasn't thinking about burnout. I wasn't thinking about failure. I was simply excited.

I wanted every post to be different. I didn't want to publish another generic "Day 1 of learning" update. So I designed a format with four sections:

What I learned
Why it surprised me
Breaking it down
How I'd apply it

It wasn't perfect, but it felt like mine. I remember finishing my very first post. My cursor hovered over the Post button for what felt like forever.

"What if nobody likes it?"

"What if people think it's stupid?"

"What if I stop after three days?"

I almost closed the tab. Instead, I clicked Post. And then I waited.

Not for hundreds of likes. Just one. One like that would whisper,

"Keep going."

The rhythm

Days slowly became weeks. I explored interview preparation. Linux. Ollama. Writing. LLMs.

Topics kept changing, but something else changed with them. I started enjoying learning again. Every day gave me something new to think about.

Some posts did better than others. Some barely reached anyone. Some days I was excited to write. Some days I wasn't.

But I kept showing up. When I reached Day 15, I felt strangely proud. Halfway there. I had actually done it.

For someone who usually planned more than they built, fifteen consecutive days felt like a huge victory. Looking back, I didn't just learn technical concepts.

I learned that consistency isn't built on motivation. It's built on showing up when motivation has already left. I honestly believed the next fifteen days would be easier.

I was wrong.

The day everything became heavy

Nothing dramatic happened. There wasn't one terrible day. No major life event. No big failure.

Just something much quieter. The excitement disappeared. Learning was still fun. But now I was also writing articles.

Making memes.

Attending tech events.

Improving my portfolio.

Preparing for interviews.

Trying to grow on LinkedIn.

Trying to grow on DEV.

Trying to become a better developer.

Trying to become... everything.

Slowly, something that had started as curiosity turned into responsibility. Every post started carrying invisible questions.

"Will this perform?"

"Will people find this useful?"

"Is this worth posting?"

The challenge had quietly stopped being about learning. It had become about proving something.

Mostly to myself.

Day 22

I didn't decide to quit. I told myself, "I'll post tomorrow."

Tomorrow became the next day. Then another. Then another.

The series quietly ended on Day 22.

Nobody asked where it went. Nobody messaged me asking why I stopped. Nobody noticed. But I did.

Every single day. From Day 23 to Day 30, I opened LinkedIn more times than I want to admit. Sometimes I'd start writing. Then delete everything.

Sometimes I'd open my previous posts. Sometimes I'd wonder if I should simply delete all twenty-two posts and pretend the challenge never happened.

If nobody cared why should I?

The hardest part wasn't failing publicly

People often talk about building in public. Nobody talks about failing in public. Or maybe it wasn't even failing in public.

It was failing in front of the only person whose opinion actually mattered.

Myself. That hurt far more than low engagement.

Far more than missed likes. Far more than empty comments. Because every unfinished challenge leaves behind a question:

"If I couldn't finish this what else won't I finish?"

What I learned from breaking my own promise

For weeks, I thought this challenge had been a failure. Now I think it taught me something I couldn't have learned any other way.

I learned that consistency isn't just about discipline. It's about protecting your reasons for starting. The moment your purpose changes from learning to performing, the weight becomes much heavier.

I also learned that planning can feel productive without actually moving you forward.

And perhaps the hardest lesson of all

Nobody is keeping score of your journey. The world moves on.

Your unfinished project isn't headline news. Your missed post doesn't stop anyone else's day.

But you remember. You remember every promise you make to yourself.

I'm not writing this because I completed the challenge.

I'm writing it because I didn't. Because failure deserves documentation too.

The internet is full of stories from people who reached Day 30. This is the story of someone who stopped at Day 22.

And strangely

I'm more proud of writing this than I would have been pretending those last eight days never happened. Maybe one day I'll complete another challenge.

Maybe I won't. But next time, I won't do it to prove I'm capable.

I'll do it because I enjoy becoming the kind of person who keeps showing up.

Looking back, I didn't fail a 30-day challenge. I failed a promise I made to myself.

And somehow admitting that feels like the first step toward keeping the next one.

If you've made it this far, thank you for taking the time to read a story that wasn't about success, but about falling short.

Writing this wasn't easy. It's much simpler to share wins than unfinished promises. But I hope this reminds you that behind every polished LinkedIn post or GitHub profile, there's someone figuring things out one day at a time.

Now I'd love to hear from you.

Have you ever started something with genuine excitement but couldn't finish it? Was it a challenge, a side project, a learning goal, or even a promise you made to yourself? More importantly, what did it teach you?

Share your story in the comments. I promise to read every single one because I think we learn just as much from our unfinished journeys as we do from our successes.

And if you enjoy honest conversations about software engineering, writing, AI, career growth, and the ups and downs of becoming a developer, feel free to connect with me on LinkedIn. Let's keep learning, building, failing, getting back up, and reminding each other that progress isn't always a straight line.

Are You Really Happy in Tech, or Are You Just Chasing the AI Gold Rush?

Konark Sharma — Wed, 15 Jul 2026 18:24:30 +0000

I was scrolling through my usual feed recently, reading some truly amazing articles written by great authors on how to not be jealous of others and the age old dilemma of whether you should quit IT or not. It got me thinking. It really forced me to sit back, look at my terminal, and ponder a deeper question that we rarely ask ourselves in the middle of sprint cycles: Are you really happy working in tech?

We talk a lot about framework migrations, salary bumps, and optimization hacks, but we rarely audit our own joy. Let us pull back the curtain on what it actually means to be a developer today, cross examine our motivations, and figure out if you are on the right career path or just caught up in the modern hype cycle.

The Great Generative Shift

The shift started happening after all the artificial intelligence revolutions took the world by storm. Suddenly, everyone started seeing software engineering as a career filled with endless piles of money and absolute ease, especially since artificial intelligence can now do most of the heavy lifting. To top it all off, the market became flooded with no-code and low-code tools that dynamically help non-technical people build a website in minutes without needing any developer's help.

This corporate gold rush has resulted in an absolute flood of people changing careers and choosing artificial intelligence shortcuts rather than actually mastering a foundational tech stack. We are now living in a world where people are building and deploying production websites that can be hacked with basic SQL injection commands. People are building and shipping applications on a regular basis without understanding a single line of the underlying code or the errors flashing in their console. They are happily paying for artificial intelligence subscriptions rather than taking the time to learn and build things from scratch. This superficial workflow has unfortunately led to many people calling themselves developers when they have never actually solved a complex problem.

What Truly Defines a Software Developer

For me, the definition of a developer is someone who genuinely loves to write code, deeply knows how to debug, understands how to increase their skills every single day to match industry standards, and is someone who can selflessly help others as well. I can honestly say I am happy in tech because I am creating and doing something I love. I love the beautiful frustration of building, breaking, and then rebuilding websites.

Every single time I use a web application, rather than just passively browsing, my mind immediately goes into a systematic breakdown of the interface architecture and how the original creator thought of making something like this. Even the smallest interactions can give such an amazing user experience that you instantly start loving the platform.

For me, that gold standard website has always been YouTube Music. The sheer smoothness of the application, the incredibly fast access, and the seamless reshuffling of songs make for a flawless experience. I feel good when listening to music on YouTube Music, and I am always surprised to see the innovative features they deploy.

As a developer, I cannot help but look past the sleek user interface and marvel at the engineering required to make it happen. A separate team of engineers had to meticulously design the state management, configure aggressive cache headers, optimize audio compression algorithms, and minimize API latency so that the transition between tracks feels completely instantaneous. I really love the yearly wrap-up recap, specifically how it turns my most-played tracks into a personalized playlist and proudly tells me that I'm in the top one percent of listeners for a specific artist. The ability to pin songs for fast access is brilliant, and I can go on all day about it.

This exact feeling is what I love about being a developer. As I use a website, I get an overwhelming curiosity about its inner workings. I still remember seeing Hadil's incredible interactive Halloween submission on Dev.to and using it again and again because it made me feel like a kid playing with new toys. A true developer should always remain curious.

The Five Minute Developer Audit

Now the hard question comes back to the surface: Are you really happy working in tech? I promise I will not give you a sad, philosophical talk about life. Everyone has profound problems they are dealing with behind closed doors that cannot easily be explained. The hardest inner battles are always fought and won completely alone.

But we need to be honest here. Did you switch into tech simply because you saw the entire world moving into tech? Did you see your friend earning a massive salary package, so you joined the industry just to get the ability to earn the same? Did you switch because you saw artificial intelligence, started playing with prompts, and thought to yourself that it is so easy to create websites and apps that you might as well join the party?

If so, let us run a rapid, five minute diagnostic audit on your baseline engineering knowledge. Let us see if you are actually building a foundational understanding of computer science, or if you are simply copy pasting code fragments without a map.

Can you explain prop drilling to me right now?
Can you explain the practical use of the call and bind methods in JavaScript?
Can you explain to me which tool is better between Kubernetes or Docker depending on the architecture?
Can you explain high-level encryption to me like I am five years old?
Can you confidently use AWS to deploy production-grade code?
Can you even name three other collaborative platforms like GitHub?

More importantly, can you answer all these foundational questions without opening an AI chat window for once?

The tech field looks incredibly fascinating from above, but the deeper you go, the deeper you realize the harsh realities of intense burnouts, the psychological drain of not getting a job, the frustration of being stuck in a dead end role for years, and the absolute fear of not being able to grow. The highly engaged articles written by amazing writers on this platform are living proof that many engineers have felt intense burnout, toxic professional jealousy, or the feeling of being completely trapped.

It is a completely natural response from your mind and body telling you that you desperately need rest. Think about it mechanically. If a machine runs twenty-four hours a day with no break and works continuously for a whole year, it will suffer catastrophic wear and tear. On the other hand, a machine that works twelve hours, rests for twelve hours, and gets oiled frequently will perform far better and last significantly longer than the overworked machine. You are not a machine, so stop treating your brain like a server with a hundred percent utilization rate.

Finding Your True Engineering Calling

If you are trying to figure out where you stand, ask yourself these three basic diagnostic questions:

First, do you find tracking down complex system bugs fascinating?
Second, do you find genuine, profound happiness in finally completing a complex project?
Third, do you actually enjoy the micro process of working on a new software feature?

If your honest answer is no to all three of those questions, then maybe the specific branch of tech you are currently in is simply not for you. Technology is not a giant monolith, and hating the process of centering a div or managing React state hooks does not mean your engineering journey is over. You might just have a completely different calling waiting for you in another corner of the ecosystem.

If frontend or full-stack web development feels incredibly draining, it is time to pivot and explore alternative technical disciplines as soon as possible. You might discover a profound passion for data normalization as a database administrator, automating deployment pipelines in a DevOps role, focusing entirely on native application development, or working on low-level systems engineering.

But if your answer to those three diagnostic questions was a resounding yes, then congratulations on genuinely being a part of the tech community and loving the art of problem solving.

Now the real question remains: Are you truly happy? Do you feel deeply satisfied after a full, exhausting day of coding work? If yes, then you are on the right track at the absolute right time in your life. If the answer is no, do not abandon ship just yet. Instead, shift your focus, alter your path, and go design or build something today that you are genuinely proud of.

Thank you so much for taking the time to read through my personal reflections on our industry! I want to open up the floor to the community because your insights are what make this space so valuable. When you shut down your local server at the end of the day, do you feel fulfilled by the code you wrote, or are you feeling the weight of modern tech burnout? Are you staying curious like a kid with toys, or has the AI hype cycle drained the fun out of your editor? Let us know your thoughts down in the comments below!

If you want to keep swapping debugging survival stories, discuss foundational engineering skills, or share your build journey, feel free to connect with me over on LinkedIn. Let us keep building, supporting each other through the burnouts, and growing together!

Dear Stranger — A Page for You

Konark Sharma — Mon, 13 Jul 2026 06:56:16 +0000

There is a kind of loneliness that does not always announce itself. It can be quiet. Heavy. Hidden behind a smile. It can make someone feel as though no one truly understands what they are carrying.

Dear Stranger was created for those moments.

It is a place where someone can pause. Breathe. Read. Feel less alone. And maybe, just maybe, carry a little more hope than they came with.

This is not just a project to me.

It is a quiet promise. A small place I built with my heart. A space where words can travel gently across distance and still carry comfort.

I built Dear Stranger because I believe that even the smallest page can hold something powerful: hope, clarity, warmth, and the feeling of being understood.

What I Built

Dear Stranger is a web experience designed to feel intimate, human, and deeply personal. It is a space where someone can open a page written by a stranger, read something honest, and feel, even for a moment, that they are not alone.

The project is built like a book made of feelings. It invites the visitor to step into a calm, reflective experience where words matter more than noise. They can read pages that speak to comfort, strength, peace, and hope. They can save what touches them. They can leave behind their own words for someone else to find one day.

It was never meant to be just another website. It was meant to feel like a page that was waiting for you.

Demo

The experience is best felt by opening it and letting it meet you where you are. It is meant to be soft, reflective, and quietly powerful.

Dear Stranger - this is for you.

Code

The project is built with Next.js and designed as a personal, story-like interface where emotion is part of the experience. The structure allows users to move through a reading journey, interact with meaningful content, and leave behind something sincere.

Konarksharma13 / Dear-Stranger

Dear Stranger — A Page for You

This website was never meant to be just another page on the internet.

It is a quiet place made for the heart. A small, intimate space where someone can open a page, breathe, and feel, for a moment, that they are not alone.

Dear Stranger is a gentle digital experience built around comfort, hope, strength, peace, and the kind of words that arrive exactly when they are needed. It invites people to read something sincere, to hold onto something meaningful, and to leave behind a little light for someone else.

What this project is

Dear Stranger is an emotional, book-like experience where the visitor can:

choose a path that matches what they need today
read a handwritten page from a stranger
save pages that feel important
share a page with someone who may need it
leave their own words behind for another soul…

View on GitHub

How I Built It

I built this project with one simple belief: sometimes the right words at the right time can change the shape of a difficult day.

So I focused on creating an experience that feels close to the heart. The interface is gentle, the flow is calm, and the writing experience is carefully designed to feel less like a form and more like an invitation.

One of the most meaningful parts of this project is the use of Google AI.

I used Google AI to help generate and refine written text in a way that feels supportive, emotional, and human. Not to replace a person’s voice, but to help shape it. A rough thought can become a beautiful sentence. A personal feeling can become something clearer, kinder, and easier to share. The AI does not take away the emotion. It helps bring it into form.

That felt important to me.

Because the heart of this project is not just content. It is connection.

Why I Built It

I have always felt that motivation does not always arrive as a loud speech or a perfect message.

Sometimes it arrives as a whisper. A sentence that says, “You are not alone.” A line that reminds someone they are still strong. A page that says, “Keep going.”

That is the kind of impact I wanted to create.

My passion to motivate others has always been more than a feeling. It has been a purpose. I wanted to build something that could reach people quietly, without pressure, without judgment, and without needing them to be perfect.

I wanted to make a space where people could feel seen.

And maybe, if I am honest, I wanted to make something that would speak to me too. Something that reminds me that words can still be kind, that care can still be shared, and that a stranger’s voice can become a source of comfort.

Sometimes they need a page that says:

you are still here.

you are still worthy.

you are not alone.

Prize Categories

Best Use of Google AI

I used Google AI to help generate and refine emotionally resonant text for the experience. The goal was to support human expression, not replace it. The AI helps transform personal thoughts into meaningful words that can comfort, inspire, and connect people in a more heartfelt way.

A Final Note

If this project feels like a diary opened for strangers, then I think that is exactly what it is.

It is personal. It is tender. It is built from the belief that words can be a form of care.

And if one person reads it and feels a little less alone, then I know this project has done what it was meant to do.

The 3 Types of AI Users Dominating the Software Engineering Landscape

Konark Sharma — Thu, 09 Jul 2026 17:39:55 +0000

I was scrolling through my usual feed recently, looking for something to distract me from a failing compilation loop, when I stumbled across an interesting perspective on how our relationship with large language models is evolving. It completely changed the way I look at artificial intelligence and forced me to evaluate myself to see exactly which category I lie in. We spend so much time debating the benchmarking scores, the context window sizes, and the parameter counts of these models, but we rarely look at the mirror to analyze how we actually interact with them on a daily basis.

When you look at the engineering landscape today, everyone is using AI, but everyone is using it with a completely different philosophy. After some deep reflection, I realized that the entire tech world can be divided into three distinct psychological types based on how they prompt, trust, and integrate these systems. Let us unpack these three types of users, look at their practical use cases, and figure out how you can leverage each style to become a significantly better developer.

1. The Digital Delegator

The Digital Delegator treats artificial intelligence like a junior engineer who never sleeps and does not complain about writing boilerplate code. If you belong to this tribe, you do not view AI as a magical entity or a threat. You view it as pure muscle. You know exactly what architecture you want to build, and you simply use the model to accelerate the physical act of typing.

The Delegator is the developer who passes a clear database schema to the prompt window and says: "Write the CRUD operations for this in Express, include input validation, and do not dare to change my variable naming conventions." You do not ask the AI for philosophical advice on design patterns because you already know what works. You just do not want to waste twenty minutes writing repetitive try-catch blocks.

The Delegator Use Case for Maximum Efficiency

To be better with AI as a Delegator, you must master the art of contextual constraints. The greatest trap for this user type is letting the model hallucinate entire architectural layers. You can maximize this workflow by feeding the model your strict corporate style guides, your explicit linting rules, and your precise interface definitions before asking it to generate a single line of logic. Use it to build repetitive unit tests, convert data formats, or generate mock data engines. You remain the undisputed architect. The AI is simply your high-speed construction crew.

2. The Syntactic Copilot

The Syntactic Copilot represents the developer who treats the prompt window as a collaborative pair-programming session. If you are a Copilot, you do not just dictate terms to the model. You actively think alongside it. You are likely the engineer who keeps an interactive chat panel open right inside your integrated development environment, constantly feeding it small snippets of broken logic and treating it like a sounding board.

A typical Copilot interaction sounds less like a strict command and more like a late-night debugging conversation: "I am getting a strange memory leak in this recursive function when the payload exceeds four megabytes. Here is the implementation. Let us brainstorm three potential optimization strategies together." You use the model to bridge the gap between your conceptual intent and the syntax required to achieve it.

The Copilot Use Case for Deep Learning

To maximize your efficiency as a Copilot, you must maintain a healthy level of skepticism. The best way to use this relationship to your advantage is to turn the AI into an educator rather than just a code generator. Whenever the model suggests an optimization or a complex regex pattern that actually fixes your bug, do not just copy-paste it blindly. Ask the model to explain the underlying mechanics of its solution. Use commands like: "Break down the time complexity of this approach and explain why it outperforms my original implementation." This transforms the tool from an editor into an absolute knowledge multiplier.

3. The Architectural Oracle

The Architectural Oracle views artificial intelligence through a much grander lens. If you fall into this final category, you are not using AI to write code blocks or fix syntax errors. You are using it to explore the abstract boundaries of system design, product strategy, and technical vision. The Oracle treats the model as a highly sophisticated research partner capable of cross-referencing massive datasets and architectural paradigms in milliseconds.

An Oracle developer opens a prompt window before a single line of a new project is even conceived. Your prompts look like comprehensive essays: "I am designing a distributed, multi-tenant financial application that needs to handle ten thousand concurrent writes per second with absolute atomicity. Compare the trade-offs of using an event-sourced architecture with Kafka versus a traditional relational database cluster under high geographic distribution." You are looking for high-level patterns, hidden architectural bottlenecks, and macro perspectives.

The Oracle Use Case for Technical Vision

If you are an Oracle, your primary risk is structural hallucination where a model convincingly defends a flawed architectural pattern. To protect your systems and maximize this approach, you should use AI to act as a devil's advocate for your own ideas. Do not just ask the model how to build your vision. Instead, present your complete architectural proposal and explicitly prompt the system: "Act as a cynical Principal Architect and find five critical failure points, hidden costs, and scalability bottlenecks in the system design I have just outlined." This leverage allows you to pressure-test your engineering decisions before you deploy a single server.

As I evaluated my own habits against these categories, I realized that the truly elite developers do not stick to just one tribe. The real secret to navigating the modern tech landscape is situational fluidity. You need to know when to be an Oracle to design a robust system, when to step down into a Copilot mindset to co-author a complex algorithm, and when to act as a Delegator to blast through repetitive boilerplate.

Thank you so much for reading through my perspective on this changing landscape! Now I want to turn the mirror towards you. Which type of AI user do you see yourself as when you are deep in the trenches of a project? Are you delegating the boring tasks, co-piloting your logic, or treating the model as an architectural sounding board? Let us open up a discussion down in the comments below

If you want to keep discussing engineering workflows, share your best prompting systems, or chat about building tools in public, feel free to connect with me over on LinkedIn. Let us keep collaborating, refining our development strategies, and engineering the future together!

10 Useless NPM Packages You Didn't Know You Needed

Konark Sharma — Wed, 08 Jul 2026 18:16:26 +0000

We have all been there. You are staring at your screen late at night, trying to optimize a bundle size, or debugging an enterprise pipeline that has been failing for three hours straight. The mainstream development community constantly tells us to only install packages that are high performance, audited for security, and strictly necessary for production. But where is the fun in a perfectly clean node_modules folder?

Sometimes, the ultimate way to level up your engineering workflow is to inject some absolute chaos into your dependencies. Why spend hours writing robust logic when you can install a library that brings pure irony to your terminal? Let us dive into ten packages that might look completely useless on the surface but are actually the most important modules you will ever encounter in your developer journey.

1. emoji-poop

This NPM package lets you use the poop emoji in your output. The emoji is well required in most of the websites as the real fun begins when the site crashes and you can use this poop emoji to showcase the errors with an emoji. This will help the clients get a bit calm after seeing the emoji and the errors. Think about it from a psychological perspective: traditional red stack traces cause immediate client panic, but a well-placed graphical poop emoji introduces a masterclass in modern error mitigation.

javascript
// npm i emoji-poop
const emoji = require('emoji-poop');
console.log(emoji) // 💩

2. thanos-js

Who doesn't love Marvel, and Thanos being the strongest villain in the MCU? This package lets you delete files in Thanos fashion. Once you install and run it, it deletes 50% of your files, reducing your stress and giving you less codebase to work with. Yes, it deletes the files for those who are confused about what this package does. It uses fs.unlinkSync to delete the files. Deleting random files from .git would be absolutely evil, and Thanos would love to do it. Exactly half of the files are deleted. Each file is given a chance at random, and either the top 50% of the files or the bottom 50% of the files are chosen to be deleted. It is the ultimate tool for developers who want to test their continuous integration backup restoration capabilities instantly.

javascript
# npm i thanos-js
# Limited Power:
thanos-js snap-fingers

# Full Power:
thanos-js snap-fingers --with-infinity-gauntlet-glove

3. one-liner-joke

This NPM package is highly important for your commands as whenever the code breaks in the production, you can use this package to give a one-liner joke to laugh about and forget about the bugs in the production. When your server is throwing 500 internal server errors and your database connection pool is completely exhausted, standard logging is useless. You need automated, comedic relief directly inside your catch blocks to keep morale high.

javascript
// npm install one-liner-joke --save
var oneLinerJoke = require('one-liner-joke');
var getRandomJoke = oneLinerJoke.getRandomJoke();
console.log(getRandomJoke)

4. roast-cli

The problem is that code review tools are boring. ESLint tells you to add a semicolon. TypeScript yells about types. SonarQube generates a 47-page PDF nobody reads. Meanwhile, your actual code problems, such as a pyramid of doom, god functions, and cargo-cult patterns, slide right through. You do not need another linter. You need someone who cares enough to be mean about it. The solution is roast-cli, which sends your code to an AI with the personality of a furious celebrity chef. You get back savage but accurate feedback on real code smells, three intensity levels from a gentle nudge to a Gordon Ramsay meltdown, actionable fixes hidden inside every insult, and support for any language including JS, Python, Go, Rust, and Java. It is an indispensable architectural tool because regular static analysis just does not hurt your feelings enough to make you a better programmer.

javascript
# How to get the brutal code reality check you deserve
npm install -g roast-cli
roast path/to/your/messy/code.js

5. corporate-ipsum

We all love using lorem-ipsum in our codes for random text. Wouldn't it be better if we use corporate jargons instead? That is where this package comes in handy and handles everything pretty calmly. Instead of filling your UI layout drafts with standard Latin that design stakeholders do not understand, you can seamlessly populate your DOM components with optimized, high-level business synergy directly out of the box.

javascript
// npm i corporate-ipsum
import createIpsum from 'corporate-ipsum';
console.log(createIpsum());

6. fartscroll.js

This package brings immediate auditory depth to the user interface experience. The implementation process is straightforward: include "fartscroll.js" in your page from the latest CDN address, then initialize the fartscroll plugin once the DOM has loaded. It provides deep user feedback, ensuring that your users are fully aware of exactly how many pixels of content they have consumed.

javascript
// Include the script via CDN: //[code.onion.com/fartscroll.js](https://code.onion.com/fartscroll.js)

// Fart every 400 pixels scrolled
fartscroll(); 

// Fart every 800 pixels scrolled
fartscroll(800);

7. cowsay

This module is arguably the most critical structural component of modern cloud native log architecture. Why output your system diagnostics in plain text strings when an ASCII cow can say it directly inside the terminal streams? It dramatically enhances terminal legibility and ensures that your container output is handled with appropriate seriousness.

javascript
// npm i cowsay
const cowsay = require("cowsay");
console.log(cowsay.say({ text : "I'm a moooodule", e : "oO", T : "U " }));

8. is-funny-number

Data validation is the cornerstone of robust software systems. This package checks if an integer is a funny number. Instead of relying on manual evaluation logic, this library offers a mathematically sound implementation to verify whether numbers like 420 or 69 are present, keeping your application state fully aligned with cultural trends.

javascript
// npm install is-funny-number
const { isFunnyNumber } = require('is-funny-number');
console.log(isFunnyNumber(69)); // Returns true
console.log(isFunnyNumber(6));  // Returns false

9. sudden-death

When an application lifecycle needs to terminate, it must do so with absolute clarity and stylistic emphasis. The sudden-death package generates a prominent ASCII speech bubble frame around your terminal output, making sure that your catastrophic runtime failures are impossible for the operations team to overlook.

javascript
// npm i sudden-death
var SuddenDeath = require('sudden-death');
var totsuzenNoShi = new SuddenDeath('Sudden death');
console.log(totsuzenNoShi.say());

10. is-windows

This package returns true if the platform is Windows. It is a highly optimized UMD module that works seamlessly with Node.js, CommonJS, browser environments, AMD, Electron, and more. While cross-platform runtime environments try to hide OS specifics behind layers of abstractions, this module cuts through the noise to give you a definitive answer, which is absolute gold for your build configurations.

javascript
// npm i is-windows
var isWindows = require('is-windows');
console.log(isWindows()); // Returns true if the platform is windows

At the end of the day, our node_modules folders are already massive, so we might as well fill them with utilities that make us laugh during a deployment failure. These packages prove that the open-source community possesses an unmatched level of ironic creativity.

Thank you so much for reading through my exploration of these vital dependencies! What is the most hilariously unnecessary package you have ever sneaked into a repository? Let us know down in the comments!

If you want to keep swapping chaotic development tips, talk about open source projects, or just share your favorite coding memes, feel free to connect with me over on LinkedIn. Let us keep shipping code, expanding our package lock files, and laughing through the bugs together!

The AI Job Panic: Are We the Architects or the Scaffolding?

Konark Sharma — Mon, 06 Jul 2026 18:10:59 +0000

Let's be honest, you can't scroll through your feed, listen to a podcast, or even make coffee without someone, somewhere, mentioning the impending AI apocalypse. It is usually framed as: "AI is coming for your job, your keyboard, and your favorite coffee mug." But isn't that incredibly ironic?

We are the software developers. We are literally the architects building the AI, writing the code, and then using that AI to build even more tools. Are we truly creating our own replacements, or are we just very efficiently automating the boring parts of our day? It feels a bit like a baker building a robot to knead the dough, only to worry the robot will eventually want to run the whole bakery. I've always wanted to weigh in on this discussion and share my perspective, but I was always hesitant because I am not an "AI expert" and didn't want to get ratioed by researchers. However, I read something truly interesting recently that gave me a new perspective, and I had to share it.

The Computer Era Paradigm

We have all heard the stories of how we moved from papers to digital, and how computers were coming into the picture and they will take the job of the workers who were writing them everything in the registers. The wave that we are experiencing right now is kind of similar to that wave. At that time, people who were doing everything on the papers would have felt terrified and didn't wanna lose to a computer. But as the computers were new, they were quite fast and were efficient in doing the jobs and storing each and everything in the memory to be kept for later use.

This tension is perfectly depicted in a movie I watched (Hidden Figures, if you're looking for it). Initially, teams of human "computers" did complex space research calculations and re-evaluated all the answers so the spacecraft wouldn't deviate from its path. Then, electronic computers were introduced, creating the same panic that we experience these days: "All these people doing calculations will be let off!" But the movie clearly shows how these workers didn't panic and quit. They learned how to use the computers and how to use them to their own advantage, get their jobs back, and become even more valuable.

This is exactly what is happening right now. When the AI bubble started getting bigger and people were introduced to thousands of models every single day, it didn't just stop. There were people who started using these models and started to create newer models that were fast, precise, and solved a specific problem so that tokens weren't wasted. (And because nobody has a token budget that large!

The AI Era Evolution

As in the computer Era, the computer became a household thing, and every kid in the neighborhood wanted to have a computer in their home and wanted to use and experiment with it. The reason that we have Microsoft today is the solely reason cause Bill Gates' school had a computer and he used it daily and learned each and everything about it and explore each and every component of it and later with his friends created Microsoft. This story tells us that if in this AI era we experiment and learned each and everything about AI we might be able to build a next Iron Man.(Or at least a much better CLI tool).

I don't feel that AI will take our jobs as we all are software developers, and we all are using AI in our day-to-day life and using and experimenting with it to create something for personal use or professional use. It has helped many developers to crack jobs, help with the interviews, build software that help people do things better. Anthropic hackathons are proof of how advanced we have moved forward with AI as people are using Claude to create the next Y Combinator startup.

It has led me to think who might lose the job if it concerns. I think the people who live under a rock might lose their job or a person who neglect AI and wanna showcase his or her skills and take 10 hours to create something that could be done with AI in one hour. (At some point, your team is going to wonder why you are writing raw boilerplate by hand when you could be focusing on system architecture).

Of course, the constant debate of creating something with AI and then debugging it for hours is a concern, but as software developers, debugging is the ultimate skill that any developer should know. If you know where the bug is and you have the ability to solve it, then you are a good developer. We all can't be AI proof, but we can always use AI to our advantages and use it as a leverage or tool to make our lives and our work better. To support this argument, Amazon initially laid off 30,000 people but re-hired 11,000 of them as AI turned out to be more expensive than expected. AI might be smart, but human logic is still cheaper per hour than a cluster of H100s.

AI as a Tool

Whenever I hear of losing a job to AI, I wasn't really concerned because I have always looked at AI as a tool to leverage us, not as a liability that will take us down. Of course, many people have lost their jobs, but I felt that this was a necessary step that was required. (And before you find me in the comments, let me explain!).

The reason being, when COVID hit and everything went online, companies started mass hiring people. The tests and the interviews were not that strict, which led to a lot of bloated teams. With AI coming in the picture and taking the jobs, I feel the people who have lost the job were initially the ones that weren't doing good in a company. Because if you are doing good in a company and you have the skillset to learn and adapt to each and everything that comes to you, you are future-proof.

Think about it: we all initially learned JavaScript, then learned Node.js, then moved to React. And then, if the company required them to learn Django and Flask, we learned it and added it to our skills. So if you are a developer, and you have the ability to adapt to each and every situation that you are thrown in, and you have the ability to come out of it as a winner, then there is nothing that you can't learn or get better at. If I consider myself from 2021 or 2022 when ChatGPT was the biggest name to be heard, I didn't consider myself using AI. But today I am using AI and I know prompting and I know how to generate content that could get better and better if I work on it. So yeah, AI has helped me in many ways possible that if I had waited looking for someone to help me, then I wouldn't have reached the level that I'm currently at.

My Concern

My concern with AI is that I don't get too dependent on it. I wanted to learn, I wanted to explore. I wanted to build projects using AI, but I should be the one having the core knowledge to build and explain the project from scratch. The more complex the project gets, the more we get dependent on AI to write code and refactor all the errors. (If you don't know how the foundation works, you are just one bad context-window hallucination away from a broken application).

Since day one of using AI, I have never felt that it can replace me. Of course, there are a lot of things that AI can do, but the key thing that requires AI to do its task is the prompt and ability to come up with an idea. If I don't have the idea or the knowledge to make it, I won't make it, as if I talk with AI about any project, it will definitely describe it as the best competitor for Google (while still struggling to horizontally center a simple div container).

At the end of the day, AI is an incredible spatula. It helps us flip the code faster, but it still doesn't know what the software is trying to solve for the human user. We are still the master chefs we just have sharper tools in our kitchen.

Thank you so much for taking the time to read through my thoughts and perspective. I would love to hear your experiences. How are you leveraging AI tools in your current workflow? Are you using it to supercharge your building speed, or are you fighting with hallucinated bugs in your dependencies? Let us know down in the comments below!

If you want to keep swapping prompt strategies, talk about software engineering trends, or share your build journey, feel free to connect with me over on LinkedIn. Let us keep collaborating, building in public, and growing together!

How to Shine as an Introvert in a Loud Tech World

Konark Sharma — Sun, 05 Jul 2026 17:32:39 +0000

We have all been there. You walk into a room full of tech enthusiasts, the ambient noise is humming with intense architectural debates, and your social battery immediately drains down to a critical five percent. While the natural extroverts are flying across the room launching themselves into every single conversation circle, you are looking for the absolute best strategic position next to the catering table, silently calculating how many sandwiches you can politely consume before it is socially acceptable to slip out the back door unnoticed.

I was a complete introvert and I still am, but I consider myself an ambivert now, as I convert my personality according to the convenience required. It is like having a dynamic runtime configuration that changes depending on the environment variables. I enjoy solitude, as well as presenting things in a group or speaking in public. Exactly one year ago, I was a complete introvert and I didn't have the courage and confidence to present myself or to speak on a stage, but recently, I hosted a small segment in a tech talk where I had the opportunity to interact with the audience, present a quiz to them, and make them engaged and active. If a guy who used to treat basic small talk like a terrifying production failure can do it, you absolutely can too.

My Backstory: From Underconfident to On Stage

Exactly one year ago, I wasn't a confident guy, and I didn't have the courage to speak to anyone I meet. I was very much fearful and very much under-confident to present myself to anybody. Walking up to a stranger felt like trying to fix a critical database bug live in production with the entire engineering team breathing down my neck. But the reason that change was, I wanted to take this as a challenge and present myself to people, attend tech talks, interact with the strangers there, and maybe network with them.

The main issue that I faced was the career gap, where the people attending these events are mostly students and here I was, an unemployed guy looking for new opportunities and new networks. It is incredibly intimidating to stand in a room where everyone is asking, "So, what stack do you work on at your company?" and your honest answer is, "Localhost."

But the last whole year, I have enjoyed every bit of it and just wanted to convey my feelings that if I can present myself on a stage, then anybody else can do it as well. The initial step that I took was to attend many tech talks and talk to one stranger at a time. I was pretty nervous on my first event, but eventually, I got habitual of it and the more people I interacted with, the more I get to know about how to interact with people and how to get the most out of it. As I started connecting with people, my LinkedIn connections grew, and I started posting about the events and showcasing my learnings of that event, which helped me gain more and more confidence to present myself on LinkedIn and to present myself to other people as well.

The Corporate Divide: Navigating Networking Hurdles

The story ain't all sunshine and rainbows, as I was in the middle of the two distinct groups that were present in the events. One group was the juniors in college that were looking to meet new people, connect, make new connections, get a referral or a job, or find a guide in their career path. The other group was the seniors that were already in a good job and were looking to make good connections to get an even better job.

So, I was right in the middle of them: an unemployed guy looking for new opportunities and trying to connect with people. Because of this, many of the people that I met really didn't wanna connect with me. They were actively looking for someone with a high-profile corporate title who could help and guide them better. That was a bit frustrating for me, but I never took it as an insult, but rather as their loss and losing a good connect.

I don't consider myself an expert on the topics, I enjoy each and every conversation and the genuine time given to me by the other person. While attending events, I always felt unplaced in those environments as I wasn't able to find anyone else looking for new opportunities. Either I met someone still in college or someone settled in a good company. But I reminded myself that I was there for the event and not for them, so I enjoyed and learned from each and every event and added the gist to my daily workflow.

Becoming a Event Veteran: Finding True Value

The more events I started attending, the more veteran I got. I majorly attended Google events happening in my city, so many of the people started recognizing me, and I started recognizing more and more people that I met in other events. I was laughing when I came home and thought about it, because everyone knew me by face and not by my name. But hey, that is exactly what you get for consistently attending events with 200 to 300 people! I became like that one mysterious open-source contributor whose avatar everyone recognizes, even if nobody knows their actual real-world identity.

I met a few genuine people that were way beyond the superficial discussions about jobs and corporate status. I really enjoyed the quality time that I have spent with them and the massive amount of discussions we had on AI and the upcoming trends. It was truly exceptional to learn from others and share my experiences and my knowledge as well.

I say I call myself a veteran because once I attend an event and I meet three or four people there recognizing me and shaking hands with me, it changes the dynamic. There was even someone sitting across the table who said, "Yeah, I know you, I have seen you in other events as well," and I was like, "Oh, I'm that veteran now!"

I always accomplish the task of meeting someone new and talking about the event and how the event was. I was pretty nervous about it always, as I always felt like, "What would I say if someone judges me because I don't know much about the specific topic they like?" I was pretty nervous about it, but yeah, I did it anyways, and if they liked the conversations, at the very end they will ask, "Can we connect on LinkedIn?" and I was like, "Yeah, sure."

The Secret Weapon: Using Humor to Break the Ice

I always felt like I am a bit funny and I can crack a few jokes. So, I took this quality and with each and every conversation, I added a few jokes and a sense of humor to the people that I talk to. The more people I talked to, the more I got to know about how to present myself, what are the specific topics that I can joke about, and what are the delicate boundaries that I need to avoid. That has helped me a lot on how to present myself and how to joke in a corporate setting, as the people there are very professional and it is the first time I am meeting them, so I absolutely can't lose on presenting myself as a cheap clown.

The thing that I have realized is that humor is the best thing that can be used to break the ice. For me, I am naturally nervous, and that could be easily true for the other person as well. They could be nervous as well, so giving them a short smile helps them to be a bit calm and express themselves even more. The more I joked with the persons at the event, the more comfortable I felt, as for me, a sense of humor is my go-to comfort space. That has helped me immensely in presenting, starting, or maybe moving the conversation directly into my court.

I can't say that I have made hundreds of elite connections and that I am completely flawless at networking, but what I felt that I have successfully achieved is that I am good at presenting myself and getting the other person comfortable to talk more and more. The reason I am saying that I am good at presenting myself is that for me, if I met someone, that other person has willingly stayed with me through the whole day. There was nobody in the journey that has left me mid-way to go meet new people and connect with others they genuinely enjoyed having conversations with me and having a good time with me.

Connecting the Dots: Stepping Onto the Stage

For me, it has been a pretty awesome journey as I enjoy every single part of it. The next big challenge I took was to speak on the stage, which was terrifying as I had never held the mic before in my life. I never had the courage to present myself on a stage. The catch at this specific event was that if you wanted to win a free coffee cup, you had to stand up and speak for a minute about the event. I was pretty nervous and incredibly excited at the exact same moment, but I felt the urge to go for it and maybe get the prize as well.

That was the first time I ever presented myself on a camera or to a large audience, and I did pretty okay okay. I was super nervous and I was completely lost on words. I wanted to say a whole lot, but only a few scattered words actually came out of my mouth.

But that experience got me hooked, and I wanted to do it even more! Soon after, there was another event where we had to build a project, and the organizers asked if someone wanted to present their idea. I was nervous, but I resolutely kept my hand up, and I was selected to speak about the project. My project was relatively simple, but I wanted to have the courage to stand up, speak about it, and say a few confident words on it. So, I started it, kept explaining the project, and actually got two or three big laughs from the crowd because my idea was quite literally "Tinder for food." As I got off the stage, my legs were physically shaking, and I was pretty fearful about what had just happened to me, as I was completely unaware that I was truly capable of presenting myself on a stage to a group of people. But I did it anyways, and I enjoyed it.

Then came the biggest moment for me till now. I participated as a volunteer in an event, and there, I got an actual formal opportunity to present and interact with an audience. That was simultaneously scary and exciting for me. I was prepared, but my mind was spinning with negative thoughts: "What if this happens? What if that happens? What if I am not able to connect with the audience? What if they won't laugh at my jokes?" There was a massive amount of chaos in my head, but this was the new 2026 Konark, who has built up the immunity to just go for it and give your best shot at it.

The big moment came, I presented the quiz, and I interacted directly with the audience for the next 15 to 20 minutes. Everyone was completely hooked up with the quiz, with the jokes, and with the unique insights that I had put into the questions. Everyone was shouting out the wrong names intentionally, as the wrong names were even funnier than the actual right answer for the quiz.

For the first few minutes, I was pretty nervous and shaking, but as I told you before, humor is my absolute forte, so I can't lose in my own battlefield! Once one or two jokes successfully landed, I knew that I had firmly gotten the attention of the audience.

And you know what was the hardest part for me? I had to interact with an audience that had just consumed food and was in a complete trance state after a heavy lunch. Initially, they were completely unreactive to my "good afternoons," and for a second, I thought I would just bomb completely and that I needed to jump off the stage ASAP. But as I got comfortable, they got introduced to the mechanics of the quiz. The quiz started, my jokes landed, and then I was on fire! I joked about the event, how joyful it was, and how much I have enjoyed learning from the sessions that were there. With each and every joke, my confidence grew up, and I finished pretty awesomely.

If this had been the 2025 Konark, then the segment would have bombed completely, but since I kept presenting myself again and again, got my learnings, and constantly improved on them, I nailed it this time. Maybe next time, I'll share the story of doing a tech talk.

My Top Tips for Introverted Developers

Attend tech events, and connect and network with people. This will help you to present yourself to someone else other than your usual friends and family. This way, you will learn how to present, how to answer their unexpected questions, and how to comfortably introduce yourself, like what you do, how you do it, etc.
Give yourself a challenge to at least talk to one person in that technical event. The more the merrier. Forcing yourself to talk to just one single person in that event will eventually help you to present yourself, make a good connection, and start a brand new friendship.
Talk to the speakers and give them feedback. Ask them active questions about their topics. Learn directly from them learn how they present themselves, learn how they conduct a talk, and learn how they handle intense pressure situations. Keep your eyes open and have the ability to learn from their movements.
Enjoy each and every moment and each and every interaction. Be genuine and be interesting. Talk about the things that you find interesting or the things that are your absolute forte. That way, you will have an ease of talking rather than constantly finding and compiling words in your head.
If you aren't comfortable in talking in English, try in your native language and try to speak your mind. If you have the foundational ability to speak your mind clearly, then you can eventually have the ability to convert whatever you are thinking into English and then speak it smoothly.
Be eager for all the opportunities, even if you are an introvert. Present yourself as if you are an extrovert, talk like you are an extrovert, and represent yourself like you are an extrovert. To give you my own example: on my very first event, I talked to exactly one person, and in the last event that I attended, I talked to ten people at least, and the event topic wasn't even my main forte!
It's okay to have a bad day. Don't blame yourself if you weren't able to convince yourself to talk to even a single person at an event. Just challenge yourself to talk to two people in the very next event. Be forgiveful to yourself.

The Feedback Loop

I hope my personal story and these practical tips will help you to be better as an introvert in this loud tech world. At the end of the day, networking isn't about being the loudest person in the room it is just about finding the right timing to execute your conversational strategy without breaking your internal application state.

Thank you so much for reading through my journey! If you have your own personal tips to share as an introvert, or a funny story about trying to survive a tech event, kindly share them in the comments below. Let us discuss and help each other out!

If you want to keep swapping networking tips, talk about upcoming tech trends, or just connect with a fellow ambivert, feel free to send a connection request over on LinkedIn. Let us keep growing our networks and stepping out of our comfort zones together!

From 0 Likes to Meme Engineer

Konark Sharma — Sat, 04 Jul 2026 18:16:31 +0000

We have all been there. You are sitting at your desk late at night, your code is throwing errors that make absolutely no sense, your terminal is practically screaming at you, and you are questioning every single life choice that led you to a career in tech. Then, you open your feed and see a meme about merge conflicts or missing semicolons. Suddenly, you do not feel so alone anymore. The pain dissipates, replaced by the comforting realization that thousands of other developers are suffering through the exact same bugs.

If you love memes, especially the ones related to tech that are super relatable, and you feel like the meme shares the exact pain you have felt all along, then congratulations! You are officially a memeholic. Welcome to the club.

The Quest for the Missing Humor

When I first started using LinkedIn, I was thoroughly bored with seeing everyone sharing their massive wins, their promotions, and their flawless achievements. Meanwhile, there I was, struggling just to make it through my daily tasks and looking for a way to survive the week. It felt like walking into a party where everyone is wearing a tuxedo and you accidentally showed up in your pajamas.

That was the time I decided I needed a shift. I started posting about my 30 day LinkedIn challenge where I planned to share my learnings of the day for the next 30 days straight. To be completely honest, I was not able to complete it. My streak broke faster than a production server during a Friday afternoon deployment. However, I still got the push I desperately needed to use LinkedIn as my own personal page where everyone can see what I am actually doing.

But even with the challenge, my LinkedIn profile was missing something crucial. The natural humor in me was nowhere to be found on that incredibly serious, corporate platform. I wanted a genuine way to let out my frustration while vibe coding or working with AI tools in general. I thought that maybe, just maybe, I could connect with a few developers and have a real chat centered around humor. That is exactly where I started learning the art of the craft and posting memes.

The Initial Matches and Reality Checks

I still remember the very first meme I ever posted. It was not hilarious by any stretch of the imagination, mostly because I simply did not know how to make them yet. I randomly posted a template, thought to myself that it was quite funny, and hit publish.

The result? I barely got any likes. Reality hit quickly, and I realized it just was not that funny.

Then, I came to know about the famous Meme Monday trend right here on Dev, where @ben posts funny memes every single Monday. I was incredibly nervous and excited at the same time. I decided to gather my courage and posted a meme on the thread. I genuinely felt it was hilarious, and this time, Ben actually reacted and commented!

Buoyed by that small victory, I found out about a JavaScript group on LinkedIn that posts memes and knowledge posts. I confidently thought to myself, "Am I finally funny?" I posted a creation to that group, eagerly refreshed my feed, and ended up with a grand total of two likes. Reality hit me hard all over again. I was definitively not funny.

But I refused to give up just yet. I kept creating and making memes for Meme Monday, while taking the time to look at everyone else's contributions, which I truly enjoyed. Soon after, I thought about posting a meme specifically for April Fool's Day.

I told myself I absolutely had to be funny that day. I posted the meme, and I finally crossed my very first major milestone: 100 likes on a single post!

I was so incredibly happy. I felt validated, thinking that I am finally funny after all. It was the biggest moment for me to achieve 100 likes. I thought, "Now is the moment. I am an absolute meme making machine!"

Naturally, the universe decided to humble me immediately. After posting my next creation, I got a whopping two likes and walked right back to square one.

Through that roller coaster, I realized an important rule: the more relatable a meme is, the more people will like it. If the problem I am facing is something someone else is actively dealing with, and I can create a piece of content that successfully sells that shared frustration, it will hit the mark. I also had to accept that I am not the only one trying to be funny on the internet. There are tons of creators out there who are vastly funnier than me. I watched other accounts pull in 1000 or even 10000 likes. It did not disappoint me, though. Instead, it encouraged me to reach that elite level someday, and I am trying my best every day to build highly relatable tech jokes.

My First Major Breakthrough

When the idea for this specific meme popped into my head, I was amazed by how relatable it felt. I poured all of my technical frustration with AI into this image. You know the exact feeling: always being forced to be super nice to the AI assistant even after it makes a massive mistake, or reading the AI say "sorry" tons of times after it completely fails to understand your crystal clear instructions.

I posted it with very low expectations, thinking it would suffer the same fate as my other posts getting three or four likes before disappearing into oblivion.

But boy, oh boy, I was so wrong.

It completely blew up for me. The post gathered 572 likes and 14 reposts. I was utterly amazed watching everyone interact with it, but later I truly understood the sheer depth and relatability of the joke. Every developer using AI was dealing with that exact passive aggressive loop.

After it blew up, I felt a wave of happiness that felt like receiving an official offer letter from my dream job. Every two minutes, my phone was buzzing. Someone liked it, then again, and then again. Having my phone buzz continuously due to a LinkedIn notification was a truly brand new experience for me, especially since my regular posts barely ever crossed 20 or 30 likes. Once it crossed the 500 mark, I thought, "I have officially cracked the game. I am a master engineer now. Every single meme I make from here on out will easily get 500 to 1000 likes."

Spoiler alert: it did not go as expected.

The Inevitable Dip

I was highly excited to launch my next potentially viral creation. I truly believed it would break the record of the previous one, work absolute wonders, and cement my status so I could proudly call myself a true Meme Engineer: an engineer who simply loves making people laugh.

But boy, I was so wrong again.

I posted it and eagerly waited for the approval of the internet the next day. As soon as I woke up, I checked the metrics, wondering if it was sitting at 100 or 200 likes already. Can you guess how many it actually got? Three. Three likes at maximum.

I was completely devastated. I wanted to quit making them altogether and just focus strictly on my traditional technical learning. But the process of creating content gives me a unique sense of relief, the exact kind of satisfying feeling you get right after successfully pushing clean code to production without breaking anything.

With that renewed motivation, I posted another one, thinking this new direction would surely perform well. Take another guess at how many likes I received this time.

Zero. Yes, a big fat zero.

I was entirely heartbroken. I had taken the inspiration, learned the trends, tried to improvise to make it the absolute best it could be, and what I got in return was nothing. Do you think I should have quit right then and there?

The Continuous Grind

Despite the heartbreak, I kept grinding. Through the failures, I discovered a small, reliable pattern: if a meme can genuinely make me laugh out loud right after I finish creating it, it has a high chance of making someone else laugh too. I started creating content based strictly on that baseline rule.

I put together a new meme that genuinely made me laugh from the heart. I pushed it live, waited for the internet's approval, and went to sleep. The next morning, when I checked my phone, it had sailed past 100 likes. Just like that, I got a fresh wave of confidence that, yes, I can finally do this right and bring a smile to someone's face.

I immediately went into a full sprint in this mode. I kept creating, ensuring that if I could laugh at the draft, it was ready for production.

My next major post also pushed well past 100 likes, and I finally felt like I had cracked the secret source code to becoming a functional Meme Engineer. Of course, there were still a few hits and misses along the way, but I learned my lesson to keep grinding again and again, treating every single failed post as a debugging lesson for the next one.

The Ultimate Payoff

Eventually, I published my next creation as part of my routine schedule, thinking we would just wait and see how it performs. I had intentionally set the bar incredibly low for myself by this point. I decided that even getting 10 or 20 likes on my work was more than enough proof that I was making good stuff.

But life had completely different plans for me. This specific meme went on to hit the exact same 500 plus likes mark as my first viral hit! I was deeply happy and excited because complete strangers on the internet were finding my sense of humor genuinely funny. It gave me the ultimate confidence boost to keep the grind alive. There will always be hits and misses in this field, but the real joy is in the continuous learning.

This journey has been a wild ride, and I can honestly say I have never had so much fun creating content. At the end of the day, whether we are building software or building jokes, we are all just trying to connect through our shared experiences in this wild tech ecosystem.

Thank you so much for reading through my story! Sharing these milestones with the Dev.to community is incredibly rewarding to me. Now, I want to turn the mic over to you. If you consider yourself a bit of a Meme Engineer, or if you just have a favorite joke that perfectly sums up your working life, do share your favorite memes down in the comments below! Let us turn the comment section into the ultimate humor repository.

If you want to stay in touch, swap funny deployment horror stories, or chat about vibe coding and AI workflows, feel free to connect with me over on LinkedIn. Let us keep collaborating, sharing the daily grind, and debugging our way through life together!

Are Your GitHub Stats Worthy of a FIFA Card?

Konark Sharma — Fri, 03 Jul 2026 17:46:46 +0000

Are you a football fan? Since the FIFA hype is at its absolute peak at this moment, it is hard to ignore. We have Erling Haaland single-handedly carrying Norway toward the finals, and we even have Cristiano Ronaldo back in action, defying his age like a player with a permanent 99 physical rating.

But what is in it for a person working in tech? How can I genuinely call myself a true FIFA fan when my day-to-day life revolves entirely around code repositories and pull requests instead of pitch tactics? Maybe instead of shouting at the television, I should just stand there in absolute silence like that iconic, Michel Nkuka Mboladinga in the crowd while watching the World Cup matches unfold. If you have ever felt like an out-of-position defensive midfielder trying to balance your love for the beautiful game with your passion for open source, this discovery is for you.

What if I had a FIFA Card?

This was my initial thought when I started watching football, enjoying the matches, and supporting the teams. Don’t ask me my favorite team, please, hahaha. Let's just say my team's defensive line leaks more goals than a junior developer's first pull request leaks bugs.

So while digging through GitHub to find some inspiration for sports-related tech, I came across a unique repository that completely changes the game. It literally lets you turn your GitHub stats into a full-fledged, visually stunning FIFA Ultimate Team card.

Isn't that something awesome? The best part is that it doesn't just arbitrarily rate you based on a random script. It reads your actual engineering footprint through GitHub. It takes six distinct signals straight off your live GitHub data, weighing them against each other to find your exact developer shape. That shape is what dictates your card, meaning two developers with the exact same raw numbers can still walk out looking like completely different players on the pitch.

Here's how to read yours

MEASURED AGAINST YOU: This is your own tactical curve, not the rest of the world's league. Each stat is weighed against the rest of your individual profile, so a high number marks exactly where you stand out and a low one shows where you do not. That is why your weakest area can read significantly lower than the raw numbers suggest, because the card grades you entirely on your own metrics.

EVERY CARD HAS A SHAPE: Nobody is an elite, 99-rated player at everything. Your strongest coding signals get pushed up and your weakest pulled down, so the card leans dynamically instead of sitting completely flat. That specific lean is what decides your position and archetype read off your stats, it is never randomly picked.

THE 90s ARE EARNED: One big breakthrough season won't crown you a prime legend. Stats top out at 88 on their own merit. Reaching the prestigious 90s takes real years on the clock and an influence that genuinely lasts. A legend rating is an established track record, not just a temporary hot streak.

What feeds the big six stats

PAC: A full year of fast-paced activity, including your commits, pull requests, code reviews, and tracking issues.
SHO: Stars earned throughout your repositories, and your biggest single hit project.
PAS: Productive pull requests merged into other people's repositories, plus your total follower count.
DRI: Your language range, meaning a broad variety of languages helps your technical agility, but that tenth language counts for less.
DEF: Clean code reviews completed and open issues successfully closed out.
PHY: A lifetime of total contributions tracked consistently over your active development years.

The Ultimate Ladder

The progression system follows the classic tiers we all know and grind for:
BRONZE → SILVER → GOLD → IN-FORM → TOTY → ICON

My card status

When I generated mine, I managed to secure an In-Form rating. Looking closely at the tactical breakdown, I think I seriously need to work on my DEF stats. If I make my defensive contributions stronger, close more issues, and stop letting bugs slip past my backline, I might actually reach that legendary ICON tier.

Full Time: What Does Your Card Look Like?

At the end of the day, whether you are playing a high-press attacking game in your code repositories or sitting back and playing a low-block defensive style with legacy code, we are all just trying to avoid a catastrophic red card in production.

Thank you so much for taking the time to read through my little sports-tech crossover. Do share your leagues, your custom archetypes, and which teams you are supporting during this intense tournament. Check out the site to generate your own card, and let us see who has the best GitHub chemistry.

If you want to keep swapping development strategies, share your card layout, or need someone to chat with about football tactics, feel free to connect with me over on LinkedIn. Let us keep collaborating, building in public, and grinding our way toward that prime Icon level together!

Can FlutterFlow Build a Better Dev.to App?

Konark Sharma — Thu, 02 Jul 2026 18:13:53 +0000

We have all been riding the massive vibe coding wave lately. It feels like pure magic to sit back, tell an AI assistant what to build, and watch a full application appear out of thin air. But if you have ever tried to take that exact same web workflow and deploy a smooth, native app onto an iPhone or Android, you know exactly where the frustration sets in.

Are you a vibecoder who loves to build applications and you have built many websites? You have built and deployed many websites. Now you really want to make a mobile application that could disrupt the market and go really viral. Have you heard of FlutterFlow? Have you tried using it? If the answer is no, then I will tell you about FlutterFlow and then you can decide whether you want to check it out and vibe code mobile applications. I will share the app that I created as well.

What is FlutterFlow anyway?

Have you ever tried building mobile applications and heard of Flutter and Dart? If you haven't, you should definitely check them out. When I was in college looking for a path to choose whether to pursue app development or web development. I explored both options. While exploring app development, I used and built applications using Flutter, an open-source framework created by Google, which uses a programming language called Dart.

While Flutter itself is built by Google, FlutterFlow is an independent, visual low-code platform founded by ex-Google engineers. Today, many of us are familiar with AI vibe-coding tools like Cursor and Claude, which allow us to generate code for websites using conversational prompts. FlutterFlow, however, operates differently than vibe-coding: instead of writing code through chat prompts, it provides a visual, drag-and-drop canvas where you can build and design native mobile applications visually while it automatically generates clean Flutter code in the background.

I recently had the opportunity to attend a workshop held by the FlutterFlow team and there, I was blown away by the magic of FlutterFlow. It is a visual playground for building apps for your phone, tablet, or computer. Instead of typing thousands of lines of confusing computer code, which is like trying to write a book in a secret alien language, you use your mouse to drag and drop pictures, buttons, and text boxes right onto a screen.

Under the hood, while you are happily dragging and dropping, FlutterFlow is secretly writing a very clean, professional coding language called Flutter made by Google for you.

Shifting Gears: The Old Way vs. The Fast Way

Before tools like FlutterFlow, making a phone app took a really long time.

The Old Way: You had to hire a big team of builders or coders. If you wanted to change a button from red to green, you had to ask them, wait days, and pay them lots of money.

The FlutterFlow Way: You click the button, change it to green yourself, and see it happen instantly. It allows people with big ideas who do not know how to code to build a real app in a weekend instead of a year.

Pure AI Chat Tools vs. FlutterFlow: The Three Main Differences

Lately, there has been a massive trend called vibe coding. This is where you sit back, talk to an AI chat assistant like Claude or Cursor, and say, "Hey AI, build me a game!" You just sit there vibing while the AI types out the code.

While vibe coding feels like pure magic, FlutterFlow has a few superpowers that make it way better for building real, lasting apps:

You See and Touch the Layout with No Blind Spots
With vibe coding, the AI writes the script, and if a button is slightly crooked or ugly, you have to type, "No, move it two inches left." Sometimes the AI gets confused and breaks it. In FlutterFlow, you just grab the button with your mouse and slide it exactly where you want it. You are the artist holding the paintbrush.
The Blueprint is Yours to Keep with No Black Box
When an AI vibe codes an app, it generates a massive, chaotic mountain of text. If the AI suddenly forgets what it did or gets confused, your app is broken, and no human can fix it easily. FlutterFlow builds a clean, organized blueprint which is real Flutter code. You can download this blueprint, give it to a human engineer, or put it on a flash drive. You truly own it.
It is Built Natively for Phones
Many vibe coding tools are great at building websites, but they struggle to make apps that feel fast and smooth on an iPhone or Android. FlutterFlow was built specifically to make real phone apps. It makes sure your app can use the phone camera, send push notifications, and slide onto the Apple and Google App Stores perfectly.

Vibe coding is like asking a wizard to build a house out of thin air while you watch. FlutterFlow gives you a high tech factory tool where you assemble the house perfectly, piece by piece, ensuring it will not fall down when the wind blows.

The Honest Truth: The Pros and The Cons

The Real Pros (Why People Actually Stay)

High Fidelity UI Prototyping That Converts to Code
Most design tools like Figma just make pretty pictures. FlutterFlow lets a designer build a live, fully working user interface. When they are done, it isn't just a prototype to show investors, it is actual front end code that responds to touch, handles animations, and adapts perfectly to different phone sizes.
The Native App Escape Hatch
Unlike tools like Bubble or Retool, where you are trapped on their servers forever, FlutterFlow lets you hit "Export Code." If your app suddenly blows up to 100,000 users and FlutterFlow cannot handle it anymore, you can download the raw Dart files, open them in VS Code, and completely cut ties with FlutterFlow. You own your IP.
Automated App Store Deployment
Submitting an app to Apple's App Store and Google's Play Store is historically an absolute nightmare involving certificates, provisioning profiles, and build pipelines. FlutterFlow has a built-in automated deployment pipeline that handles this in a few clicks. For solo founders, this saves days of pulling hair out.
Native Device Capability
Many low code web tools struggle with hardware. FlutterFlow handles things like phone biometrics including FaceID or Fingerprint, Bluetooth, push notifications, and the device camera natively, without forcing you to write complex bridges between the app and the hardware.

The Real Cons (The Hidden Walls You Will Hit)

Silent, Breaking Platform Updates
This is the number one complaint on developer forums. FlutterFlow pushes frequent updates to their visual editor. Because you do not control their cloud platform, an automated update can suddenly introduce a bug that breaks your live app's ability to compile or deploy, forcing you to spend hours scouring forums for workarounds to an issue you did not even cause.
The Technical Debt and Architecture Trap
FlutterFlow makes it incredibly easy to attach programming logic directly to UI components, such as placing complex calculations inside a button click. As your app grows, this creates a chaotic spaghetti code structure.
Editor Slowdown on Massive Projects
The browser based visual canvas is incredibly fast for a 10 screen app. However, if your application grows to 60 plus screens with hundreds of action chains, the editor interface itself begins to lag, drop frames, and become painful to navigate. It is physically restricted in what you can view simultaneously.

At the end of the day, vibe coding isn't going anywhere, but finding the right guardrails for the job changes everything. For me, shifting to a platform that gives me real, native Flutter code while keeping that fast visual workflow has opened up a whole new perspective on building for mobile. It has its limitations, but knowing when to offload your heavy logic to a dedicated backend makes all the difference.

I would love to know your thoughts on this setup. Are you sticking to pure text chat prompts for your builds, or do you like having a visual playground like FlutterFlow to manage your UI layouts? Let me know your experiences or your favorite app building tips in the comments below.

Thank you so much for taking the time to read. If you want to stay in touch, share your own experiences, or chat about where tech is heading, feel free to connect with me on LinkedIn. Let us keep learning and building together.

I Tried to Escape LeetCode for 2 Years (But Here We Are)

Konark Sharma — Wed, 01 Jul 2026 17:52:55 +0000

Seriously, LeetCode in 2026? Everyone is saying HackerRank just killed LeetCode, and yet here I am, still trying to debug my way through LeetCode problems.

Well, I always wanted to smash LeetCode like a absolute pro, but I thought I just didn’t have that "push" in me. But after reading Hadil’s article on her LeetCode journey, the passion finally ignited. I started solving problems on my own, but honestly, it felt like total deja vu. I always start LeetCode thinking “this is easy,” but somewhere along the line of medium and hard questions, I get completely lost.

I wanted to share my honest, unfiltered journey of trying to master LeetCode, hitting massive roadblocks, and finally finding the spark to face my coding fears. It hasn't been a straight line, but if you're trying to find your footing in tech right now, I hope my story makes you feel a little less alone in the grind.

The Backstory: That "We Need to Grind DSA" Conversation

The story goes back to 2024. I was at my job, talking to a few developers about getting a new role in tech. We all agreed on the golden rule: we need to get better at DSA and solve LeetCode problems.

The fire burnt out quickly after it ignited. I had the passion to start things, so I jumped right into solving questions, only to hit an immediate dead end. Every single question felt brand new and completely alien. It was like the problem was speaking the answer in Parseltongue, and here I am, sitting like Harry Potter's cousin Dudley, just wondering: “What is he saying?”

I tried a few questions, solved them, and wanted to keep up a streak. But I couldn’t sometimes due to time constraints, other times because the logic just wouldn’t come. Now, looking for new jobs, I knew I wanted to solve LeetCode problems, but I carried this deep fear inside me. I waited for a spark.

Then I recently came across Hadil’s article. I was amazed and inspired by her dedication and hard work. Since I am no longer that same 2024 me, I felt it was finally time to give it a fresh start.

The Mental Battle: Convincing Myself to Hit 'Start' Again

The journey of a thousand miles begins with a single step, right?

No. The journey actually begins with convincing myself to make a fresh start while fighting unknown fears. What if I can’t produce good code? What if the time complexity is way too much? What if I just write brute-force code and can’t solve other questions? What if I fail the interviews?

How do you deal with these questions? By making your fundamentals strong. Giving it a fresh start meant learning from scratch, revising everything, and actually trying out the code.

I am a big believer in the Pareto Principle (the 80/20 rule), so I knew I had to master the core fundamentals that count majorly toward solving questions. I write my code in C++, so for solving LeetCode problems, you must know STL (Standard Template Library). It always felt like the missing tool back when I was coding in C.

Moving Beyond Loops: Spotting the Patterns

Now that I have learned the basics and STL, I should just start grinding questions and participating in weekly challenges, right?

No. The real next step is learning the patterns that help you identify how to approach a LeetCode problem. For example:

Two Pointer Approach: The two pointers advance towards opposite ends of the data structure with a fixed increment.
Fast and Slow Pointers: This technique involves using two pointers moving at different speeds—a slow pointer moving one step at a time, and a fast pointer moving two steps at a time.
Sliding Window: A window is used to traverse an array. To keep it moving, the previous element is removed and the next element is added. The size depends entirely on the problem.

Learning these and many more like these helps you remember the proper patterns and data structures to use. But after learning all this, did I finally start solving?

Reality Check: Over-Engineering vs. Over-Simplifying

I thought I was fully prepared for everything. I was ready to solve problems and become a Grandmaster. But the path isn’t as easy as it looks.

There were many problems where I over-engineered the answers showing off my knowledge of complex data structures when the solution could have simply been solved using a basic array. Other times, I produced under-engineered answers, where I didn’t think about the results and just coded blindly.

But with each LeetCode problem I tackle, I am keeping myself open-minded. I am learning from my mistakes so I can code better on the next question.

Real Talk: My Playbook for Surviving LeetCode

Don’t start coding right away. Take your time to think through the solution and time complexities. Think in terms of brute force, better, and optimal solutions first.
Read your code before submitting. Check for basic mistakes, like a missing semicolon or silly syntax errors.
Think about the edge cases. Sometimes LeetCode examples don’t provide the edge cases, and you will hit a wall during submission if you don't think of them early.
Use pen and paper first. Understand the problem on paper, solve it there, and verify your logic before you type a single line.
Think in terms of time complexity. Understand the comparisons and know exactly when and why your code should be O(n) versus O(log n).
Document your journey. You won’t recall what solution you wrote 2 months ago. If you document it, you can easily recall and revise it later.

To be completely honest, I am still figuring it out day by day, but shifting from mindless grinding to actually understanding the patterns has changed everything for me. It’s a process, and I’m finally okay with making mistakes as long as I’m moving forward.

If you are currently on your own LeetCode journey, or if you have some solid tips that helped you crack the DSA code, I would love to learn from you in the comments! What is that one favorite question the one that made you genuinely happy after you finally saw that green "Accepted" screen?

Let's share our learnings and get better together. Feel free to connect with me on LinkedIn to discuss more about LeetCode!