DEV Community: Aryan Choudhary

To The People Who Read My Weird Little Blogs

Aryan Choudhary — Wed, 24 Jun 2026 13:59:18 +0000

When I joined DEV, I had a very simple goal.

Learn in public. Maybe improve as a developer. Hopefully become employable enough to get a decent job. That was pretty much the entire plan.

10,000 followers was not part of it.

In fact, if you had told me back then that one day I'd be writing a post like this, I probably would've laughed and gone back to debugging whatever side project was currently breaking.

Yet here we are.

And honestly I'm still not entirely sure how it happened.

I didn't come here to build an audience

I came here because I had things I was trying to figure out.

Cloud computing.
Japanese.
Career decisions.
Freelancing.
Interviews.
Side projects.
The strange reality of becoming an adult and realizing nobody actually knows what they're doing.

Writing helped me make sense of those things.

Whenever life felt noisy, writing helped me slow down enough to understand what I actually thought.

At some point I realized I wasn't writing because I had answers.
I was writing because I had questions.

And somehow, a lot of you seemed to have the same ones.

The weirdest part isn't the number

The weirdest part is that people cared. I'm naturally a pretty introverted person. I've never been the loudest person in the room.

So the idea that thousands of people voluntarily read my thoughts about cloud computing, Japanese, career confusion, side projects, marketing, and whatever other rabbit hole I happened to fall into that week still feels slightly absurd.

But what surprised me even more were the comments.

The stories.
The messages.
The conversations.
The moments where somebody would say:

"I thought I was the only one who felt that way."

Or:

"I needed to hear this today."

Those are the moments that stayed with me.
Much more than any number ever could.

I thought I was joining a platform

Looking back, I think I accidentally joined a community.

Through DEV, I've gotten the chance to meet people from all over the world.

Some became friends.
Some became collaborators.
Some became mentors without even realizing it.

I got to build a fun little avatar project with @webdeveloperhyper.

I got to learn from @javz's fascinating projects and architect-level thinking.

I got to exchange ideas with @francistrdev, whose support and enthusiasm somehow always seem to show up exactly when needed.

I got to think outside the box when reading @shalinibhavi525sudo's blogs, learn about architecture and security reading @alifunk's blogs, and of course the interesting reads by @konark_13. And all their continuous support on my blogs as well.

I got to be part of Devengers and meet people who genuinely enjoy helping each other grow.

And these are only a few among many... and the names just keep growing lol.

One person I especially want to mention is Richard.

Some of you may remember him from DEV.

He left because of personal reasons, but his kindness, encouragement, and willingness to support newer writers left a lasting impression on a lot of people, including me.

I learned a lot simply by watching how he interacted with others.

I hope life is treating him well wherever he is now.

Life happened

At one point, I disappeared for a while.
Work got busy.
Office life happened.
Japanese happened.
Marketing happened.
Mainframes happened.

A lot of things happened all at once.

And honestly, I wasn't sure whether anyone would even notice I was gone.

When I eventually came back, I expected things to continue as if nothing had happened.

Instead, I was welcomed back with more warmth than I ever expected.

One comment, by Francis, in particular stuck with me.

It basically said:

"You'll always have a home here."

And for someone who originally joined DEV just hoping to become a better developer, that meant more than I can properly explain.

What I'm actually grateful for

The funny thing is that I originally came here looking for opportunities.

And I found them.
Jobs came.
Interviews came.
Projects came.
Collaborations came.

All of that was wonderful.

But looking back, I don't think those are the things I'm most grateful for.

What I'm most grateful for is the people.
The conversations.
The encouragement.

The feeling that even on the internet, genuine communities can still exist.

Because let's be honest. The internet doesn't exactly have a great reputation for kindness these days.

Yet somehow, this little corner keeps proving otherwise.

And I'll be honest,I almost didn't write this.

10,000 followers on the internet can feel oddly small when you're constantly seeing people with 100k, 250k, or even millions.

But then I stopped and thought about it for a second.

Imagine 10,000 people in a room.

Imagine 10,000 people standing in a stadium section.

Imagine 10,000 people showing up to listen to your thoughts about software, careers, Japanese, side projects, and whatever else you happen to be obsessing over that week.

Suddenly the number feels very different.
And honestly, a little overwhelming.

So... thank you

Thank you for reading.

Thank you for commenting.

Thank you for disagreeing respectfully.

Thank you for sharing your stories.

Thank you for teaching me things.

Thank you for making an introvert feel heard.

I still write weird little blogs.
I still overthink titles.
I still put anime references where they probably don't belong.
And I still have absolutely no idea where this journey is ultimately going.

But somehow, 10,000 of you decided to stick around and find out with me.

That's something I'll never take for granted.

So here's to more side quests.
More learning.
More weird little blogs.
More funmaxxing.

More people I'll be lucky enough to meet along the way.

And if you've been here for one post or one hundred...

Thank you for being part of the journey!❤️

The Microsoft Interview Question I Keep Thinking About

Aryan Choudhary — Thu, 11 Jun 2026 15:42:10 +0000

A few months ago, while interviewing for a Cloud Solutions Architect role at Microsoft, one of the interviewers asked me a question that stuck with me long after the interview ended.

Not because I couldn't answer it.
But because I kept thinking about whether I had answered it well.

The question was:

"What's the hardest part about working on mainframe technology?"

At the time, I was still relatively new to the world of mainframes.
And by "relatively new," I mean embarrassingly new.

Before joining my current company, I didn't even know something called a "mainframe" still existed. If you'd asked me what COBOL was, I probably would've guessed it was a Pokémon. Okay that is an exaggeration but you get what I mean.

I still remember early on hearing terms like KT (Knowledge Transfer) being thrown around and quietly wondering if everyone had received some secret corporate dictionary except me.

The good news is that I've never been particularly afraid of looking stupid.
So my strategy is simple:
Ask the question.
Then ask the follow-up question.
Then ask the question that reveals I didn't understand the previous answer either.

Surprisingly, people were usually happy to explain.

Anyway, after a few KT sessions and what I'd generously describe as a "bare minimum amount of research," my brain went where most developers' brains probably would've gone.

The technology
The age
The tooling
The learning curve
The fact that some of these systems were designed before I was even born

All perfectly reasonable answers.
But while I was sitting there in the interview, another thought appeared:

"This feels too obvious."

Interviewers at that level usually aren't asking for the first answer that comes to mind. They're trying to understand how you think.

And the more I reflected on that question afterwards, the more I realized something interesting.
The hardest part isn't the technology itself.

Before I started working around large enterprise systems, my mental model of old technology was pretty simple.

Old technology meant outdated technology.

And outdated technology meant something nobody had gotten around to replacing yet.

I don't think I ever consciously believed that. But I definitely acted like it.

Then I got exposed to the reality of these systems. And that assumption started falling apart surprisingly quickly.

Because whether we think about them or not, a ridiculous amount of the world still runs on technology most developers never talk about.

Banks
Insurance companies
Governments
Airlines
Large enterprises

Entire industries quietly depend on systems that have been running for decades.
Not because they're trendy. Not even because they're exciting.

But because they work.
Every day.
For years.

Sometimes longer than the careers of the people maintaining them.
No launch events
No Hacker News front page
No "look at my setup" posts

Just plain ol' reliability. And honestly, that's kind of impressive.

The more I thought about it, the more I realized the hardest part isn't learning how the system works.

Given enough time, most engineers can learn technology.
The harder part is understanding the responsibility attached to it.
When I'm building a side project, mistakes are annoying.
When you're working on systems that businesses depend on, mistakes become expensive.

Sometimes very expensive.
Suddenly the question changes.

It's no longer:

"Can I build this?"

It's:

"Do I fully understand the consequences of changing this?"

That's a completely different mindset.
And it's one I didn't fully appreciate until I started seeing these environments up close.

One thing I remember telling the interviewer was something along the lines of:

"The amount of verification and validation involved. Even small changes need to be checked carefully because the impact can be much larger than it appears."

Now at the time, I was thinking mostly about process.
Reviews. Testing. Approvals.

The sheer amount of caution involved.
Looking back, I think I was circling around the real answer without fully articulating it.
The caution exists because the responsibility exists.

As developers, we're constantly encouraged to move fast.

Ship.
Experiment.
Refactor.
Rewrite.
Try the new framework.
Try the new architecture.
Try the new thing.

Mainframe environments feel very different.

They force you to ask:

"Why does this exist?"

before you even think about replacing it.
And honestly, after seeing some of these systems, the replacement question becomes a lot less obvious than I once thought.

One realization I've had recently is that old doesn't automatically mean obsolete.

Sometimes old means battle-tested.
Sometimes old means reliable.
Sometimes old means thousands of decisions made by people solving problems I've never personally encountered.

That doesn't mean old systems are perfect. Far from it.

But it does mean they're usually far more interesting than they appear from the outside.

So if somebody asked me that interview question again today, my answer would be something like:

"The hardest part isn't learning the technology. It's understanding the responsibility that comes with it."

I know Uncle Ben I know

Looking back, I still wonder what answer the interviewer was hoping to hear.

If you've worked with mainframes, large enterprise systems, or have interviewed people for similar roles, I'd genuinely love to know:

How would you have answered that question?

What's a technology, tool, or system you underestimated at first, only to later discover there was far more depth hiding underneath it?

I Didn't Mean To Learn Marketing

Aryan Choudhary — Thu, 04 Jun 2026 06:43:17 +0000

A while back, when I was still job hunting, building mini-projects, and trying to figure out what I wanted my future to look like, I became obsessed with a weird question.

"How does someone build the next Apple?"
Or Tesla.
Or Nintendo.
Or Microsoft.

You get the point.

Because when you're younger, companies feel almost magical.
You see the products.
The launches.
The technology.
The cool presentations.
The success.

And it's easy to assume that great companies are simply built by great engineers.

Which, to be fair, is partially true.

But the more I looked into it, the more that explanation felt incomplete.
If engineering alone was enough, every team full of brilliant engineers would've accidentally built the next Apple by now.

Clearly something else was happening.
And that realization sent me down a rabbit hole.

At first, I started looking at businesses the same way I look at software systems.

Instead of seeing "a company", I started seeing components.
Engineering. Product. Finance. Operations. Sales. Marketing.

And then a question appeared:
What do these people actually do all day?

Without all the corporate buzzwords.
Without the LinkedIn jargon.

Because from the outside, most of them felt like black boxes.
Engineering was easy.
I was already living inside that box.
Marketing, however, kept pulling my attention.
Just because it felt interesting.

Every company seemed to have it.
Every successful business seemed to depend on it.
And I couldn't quite put my finger on why.

And then, almost comically, a connection I'd made a while back reached out and said:

"If your N3 result comes through, we might have something for you."

Fast forward a little.
N3 went well.

And suddenly I found myself working part-time in a marketing role.

I thought I was about to learn campaigns.
Ads.
Growth hacks.
Social media tricks.
The usual marketing stuff.

Instead, I ended up learning something completely different.

The weird part is that I thought I was studying marketing.
Looking back, I think I was actually studying people.

Why do some ideas spread?
Why do some products get ignored?
Why do some communities grow while others disappear?
Why do some people seem to attract opportunities wherever they go?

And perhaps the question that still bothers me the most:
Why do some genuinely valuable things fail?

Because if value alone determined success, the world would look very different.
Google Glass was technologically fascinating.
Kodak literally helped invent digital photography and still lost the race.

Sometimes being good isn't enough.
Sometimes being first isn't enough.
Sometimes being right isn't enough.

Which is both terrifying and fascinating.
Because somewhere in the middle, people have to understand the value too.

The funny thing is that while I was asking these questions, I realized I had already been doing marketing myself.

I just didn't call it that.

When I was looking for jobs, I wasn't simply applying.
I was trying to stand out.
The bilingual portfolio. The mascots. The animations. The blogs. The projects. The Japanese learning journey. The weird mix of things that made me... me.

I thought I was just being creative. But I was also trying to communicate something.
Not just what I could do. But who I was.
And surprisingly, that mattered.

Then came the part I didn't expect.

Negotiation.
Positioning.
Understanding incentives.
Communicating value.
Finding situations where everyone wins. Or at least where everyone leaves reasonably happy.

One lesson hit me particularly hard.

I used to think professionalism meant being agreeable.
Turns out those aren't always the same thing.

One time, after terms had already been discussed and agreed upon, an influencer came back wanting to re-negotiate.

Past me didn't say "no" outright. I did communicate our side and the agreed terms. The problem was how I communicated it.

I was so focused on being polite and professional that I came across as too accommodating. My manager pulled me aside and basically said:

"You need to stop being so mellow. Otherwise people won't take you seriously either."

At first I didn't like hearing that. But the more conversations I had, the more it made sense.

Being respectful doesn't mean being vague. Being professional doesn't mean avoiding firmness. If you don't clearly define the value you're creating and the boundaries around it, other people will eventually redefine them for you.

And chances are they'll define it in a way that benefits them more than you.

The thing that surprised me most wasn't that marketing was useful.
It was how similar it felt to engineering.

Both are ultimately communication problems.

In engineering:
You take requirements and turn them into software.

In marketing:
You take value and turn it into understanding.

Both fail when assumptions replace communication.
Both require empathy. Both require clarity.

And both are giant optimization problems.

You're constantly adjusting variables, testing assumptions, collecting feedback, and hoping the outcome moves a little closer to what you envisioned.

Even though the tools are different.
The thinking feels surprisingly similar.

The deeper I go into my career, the more I keep running into the same realization.

Freelancing wasn't just coding.
Corporate isn't just work.
Learning Japanese isn't just vocabulary and grammar.
And marketing isn't just marketing.
Everything seems to have an invisible layer underneath it.

A layer made up of people.
Expectations.
Trust.
Communication.
Motivation.
Incentives.

And somehow that layer ends up mattering just as much as the technical one.

Sometimes more.

I still wouldn't call myself a marketer.

I'm just a regular curious engineer who wandered into another department and started asking questions.

But I'm glad I did.

Because I originally started looking into marketing to understand how great companies are built.

Instead, I ended up understanding people a little better.

And that might've been the more useful lesson.

Of course the journey continues beyond this as well.
Because every time I learn something new, it feels like I discover three more things I don't understand yet.

And somehow that's becoming my favorite part.

What's something you started learning because you thought it would help your career...

...but ended up changing the way you think altogether?

Maybe it was psychology.
Maybe design.
Maybe public speaking.
Maybe sales.

Or maybe you accidentally wandered into a completely different field and found lessons you never expected.

I'd love to hear about it.

I Thought Coding Was The Job

Aryan Choudhary — Thu, 28 May 2026 14:19:06 +0000

Two years ago, when I got my first freelance client, I was still in my final semester of college.

A guy approached me on LinkedIn because he wanted an app built for some gym equipment he was selling.

To this day, he’s probably one of the most professional people I’ve worked with.

And being the naive amateur I was, I thought the hard part would be building the product.

You know… the actual coding part.

The React Native components.
The backend logic.
The deployment.
The bugs.

That was the “real work” in my head.

Everything else felt secondary.

I was wrong almost immediately.

As the project progressed though, things actually started going surprisingly smoothly.

Which was honestly lucky because life outside the project was kind of falling apart at the same time.

I had just gone through a heartbreak, my final semester was ending, career uncertainty was sitting in the background constantly… and somehow in the middle of all that, I was building this app with my friend @hisukurifu. Really grateful for his support, even today.

Looking back, I think having work to focus on genuinely helped me hold myself together during that phase.

And somehow, despite all the chaos, the project itself stayed stable.

The client paid on time.
The scope stayed reasonable.
Communication stayed respectful.

Hell, the guy even paid for renting a Mac because we needed it to build the iOS version and neither of us owned one at the time 😭

At that point, freelancing looked very simple from the outside.

A client needs something.
You build it.
You get paid.
Everybody wins.

Clean. Logical. Straightforward.

At least that’s what Instagram reels and “How I Made $10k Freelancing” YouTube thumbnails had convinced me of.

Reality felt very different.

Because suddenly there were things nobody really talks about when you’re learning development.

Things like:

figuring out what the client actually wants
discussing timelines
dealing with uncertainty
deciding pricing
revisions
feature changes halfway through
awkward conversations
scope creep
waiting for replies
wondering if the project will even go through

And honestly?

At the beginning, all of that felt more overwhelming than the code itself.

But slowly, we figured things out as we went.

One thing I still remember is that I never made a written agreement with that client.

Everything was done through pure verbal trust.

And thank GOD he didn’t suddenly increase the scope or disappear halfway through because looking back now… yeah that could’ve gone very badly 😭

Guess some small part of the world is still rainbows and sunshine lol.

But around five months after that project ended, another client opportunity came up.

This time we actually started properly planning things out beforehand.

Discussions.
Requirements.
Agreement drafting.

And then after about a week…

the whole thing just ended abruptly because the project itself was still being aligned internally on their side.

Nobody’s fault honestly.

But that experience finally made something click for me.

I remembered one piece of advice a friend had given me during my freelancing phase:

“You don’t get lucky twice with clients. Make agreements beforehand.”

At the time, that sounded overly serious to me.

Like bro… we’re just building websites 😭

But eventually I understood what they meant.

Because the more I zoomed out on freelancing as a career path, the more I realized I wasn’t just building software.

I was managing:

expectations
communication
trust
uncertainty

The code was only one part of the system.

And honestly, that realization changed how I looked at work entirely.

The strange thing is… I thought this problem only existed in freelancing.

Then I entered corporate.

And somehow the exact same realization came back wearing formal clothes.

Before starting my job, I still had this very simplified mental image of software engineering.

I thought:

“Okay, now I’ll finally work in a proper engineering environment.”

Meaning:

coding
solving technical problems
building systems
learning architecture

And yes, those things do exist.

But again, there was this whole invisible layer nobody really prepares you for.

Things like:

hierarchy
communication styles
meetings
visibility
asking questions correctly
understanding team dynamics
knowing when to speak
knowing when not to
learning how people actually work together

And once again, I realized:

The technical part was only one layer of the job.

Even learning Japanese started feeling the same way after I began using it professionally.

At first, language learning felt like:

vocabulary + grammar = communication

Simple.

Then workplace conversations arrived and suddenly communication became:

timing
confidence
hierarchy
context
listening
reading atmosphere
adapting to people

Different field.

Same realization.

Even marketing ended up teaching me this.

I originally got into it thinking:

“Okay this is probably just posting content and promoting things.”

But behind that was:

positioning
audience psychology
negotiations
understanding attention
figuring out why some things spread and others don’t

Again, the visible part was tiny compared to everything underneath.

And honestly, I think this pattern exists in almost every career.

From the outside, most professions look simple because we only see the visible output.

Everything is an iceberg.

We see:

the deployed app
the successful freelancer
the polished presentation
the fluent speaker
the viral post

But we usually don’t see:

uncertainty
communication
failed attempts
invisible coordination
emotional pressure
relationships
trust
adaptation

The deeper you go into anything, the more human it becomes.

And I think that was the biggest surprise for me.

Not that coding was hard.

But that almost every meaningful thing around coding involved people.

Looking back, I think younger me believed careers were mostly about skills.

Now I think they’re more about people skills.

Technical systems.
Social systems.
Communication systems.
Even emotional systems sometimes.

And honestly? That realization used to overwhelm me a little.

Now I weirdly find it interesting.
Because it makes every field feel deeper than it first appears.

So yeah.
Turns out coding wasn’t “the job.”
It was just the most visible part of it.
And maybe that’s true for a lot more things in life than we realize.

I’m curious now though:

Have any of you had a similar realization after entering a field professionally?

Where the thing you thought was “the main skill” ended up being only a small part of the actual job?

Working With Japanese Clients Humbled Me Faster Than I Expected

Aryan Choudhary — Wed, 20 May 2026 05:27:44 +0000

About three months ago, after clearing JLPT N3, which is considered a good level in Japanese and gets you entry-level jobs apparently, I genuinely thought:

“Okay… maybe I can finally communicate properly now.”

Not perfectly, obviously. But enough to survive conversations. Enough to work in Japanese if needed.

And honestly, after spending so much time studying grammar, kanji, listening practice, mock tests, and trying to decode conversations like Nico Robin reading poneglyphs, passing felt huge.

For a little while, I was floating on confidence, right there on the ninth cloud.
Then work happened :)
And workplace Japanese humbled me almost immediately.

The Japanese I studied wasn’t the Japanese I started working in

One thing I didn’t fully understand before joining this environment is that there isn’t just one “Japanese.”

There’s:

anime Japanese
textbook Japanese
daily conversation Japanese
polite office Japanese
technical Japanese
client-facing Japanese

…and your brain has to switch between them depending on context.

At some point I realized:

I wasn’t learning “Japanese.”
I was learning multiple versions of Japanese depending on where I was and who I was speaking to.

And the workplace version felt completely different. Most of which still goes over my head in some contexts... but slowly, it's starting to make more sense.

Speed changes everything

The weird part is… sometimes I do know the words being used.

If someone says them slowly.
If I see them written down.
If my brain gets two extra business days to process the sentence.

But meetings don’t work like that.

Real conversations happen fast. People interrupt each other. A lot of filler words are being used. Topics shift suddenly. Technical terms that you wouldn't see anywhere else. And I am there like:

And I think what makes it even more chaotic sometimes is that Japanese is technically the 5th language my brain has had to learn and actively switch between.

So there are moments where I know the meaning… but my brain is stuck in a linear search through English, Hindi, Maithili, Marathi 😭

And then the Japanese word arrives 3 business days late.

In meetings, my brain is almost all the time like:

“WAIT WHY CAN’T I REMEMBER ANYTHING”

And then randomly on the ride home, I’d think:

“Ohhh yeah! That was the worddd T_T”

Passing an exam and functioning professionally are VERY different feelings

This was probably the biggest reality check for me.
Passing N3 gave me confidence, but working with Japanese clients made me realize something important:

Understanding a language academically and functioning in it professionally are two completely different skillsets.

Because communication at work isn’t just:

vocabulary
grammar
translation

It’s also:

confidence
timing
hierarchy
listening
reading the atmosphere
knowing when to speak
knowing how to phrase things politely (especially when hierarchy matters)
understanding intent behind words

Being the junior-most person in the room doesn’t help either...

I’m currently the most junior person on my team.

Everyone around me already has N2 or N1 and years of experience working with Japanese clients.

Meanwhile I’m sitting there trying to:

follow conversations
not accidentally interrupt hierarchy
not sound disrespectful
not miss technical context
and ideally not embarrass myself in two languages simultaneously

So naturally, I became quiet.

Most of my communication initially happened only when I had doubts.

And even then, I’d usually confirm with my team lead first before asking onsite members directly.

In my head, I thought:

“I should only speak when necessary.”

Which honestly came from fear more than professionalism.
But then one of the intermediary managers told me something interesting.

They said I need to speak more often. Not just for work. Even casually. Even directly with clients sometimes.

Because communication isn’t only about transferring information.
It’s also about building confidence and familiarity.
And my immediate internal reaction was basically:

“BRO WHAT DO I EVEN TALK ABOUT 😭”

These are people with 15+ years of experience. I’m here trying to survive keigo and system terminology while they casually discuss things I’ve barely even encountered yet.

But the more I thought about it, the more I realized something:
They’re not expecting perfection. They’re expecting presence.

Technical Japanese is its own universe

Another thing I underestimated was how much vocabulary changes depending on your field.
Studying for JLPT teaches useful foundations.

But work introduces:

cloud terminology
system vocabulary
business phrases
client communication patterns
abbreviations
polite corporate expressions

And suddenly your carefully studied Japanese starts feeling… incomplete again.

It’s honestly very similar to programming.

You can finish tutorials and understand concepts.

But production environments introduce an entirely different layer of understanding.

Passing N3 felt a little like:

“I finished the tutorial.”

Workplace Japanese felt more like:

“welcome to production.”

I also had to deal with momentum loss

Around this same period, life became chaotic.
Job switching.
Office life.
Adjusting to new environments.
Trying to manage multiple things at once.

And somewhere in the middle of all that, I ended up taking around a 2.5 month break from serious Japanese study.

That slowed me down more than I expected.

Coming back after a gap feels strange because your brain remembers enough to know what you’ve forgotten.

But honestly, I didn’t really have a choice at the time.

So eventually I just accepted it.

And I started again.

Now I’m back to studying N3 properly again while slowly moving toward N2.
Much slower than before maybe.
But with a much more realistic understanding of what “knowing a language” actually means.

What changed most wasn’t my Japanese. It was my mindset.

Before this experience, I thought communication meant:

“Can I form correct sentences?”

Now I think it means:

“Can I help the other person understand me comfortably?”

That’s a completely different perspective. I’ve also realized listening matters far more than I originally thought. I mean I've always been a good listener but reading between the lines in corporate is still something I need to get used to maybe.

Sometimes understanding intent is more important than understanding every individual word perfectly.

And sometimes confidence matters more than perfect grammar. That realization changed a lot for me.

Still a long way to go

There are still meetings where I feel lost.
Still moments where my brain freezes.
Still situations where I replay conversations afterward.
But weirdly enough, I’m not discouraged anymore.

If anything, this experience made the language feel more real.
More alive. More connected to actual people instead of textbooks and exams.

And honestly? That makes me want to master it even more.

So yeah… workplace Japanese humbled me

Fast at that. But honestly, I am grateful for that too.
Because confidence built only on exams was always going to be fragile.
Now the goal feels different.

Not:

“pass the next level.”

But:

“become someone who can genuinely connect, communicate, and work comfortably in another language.”

That feels much harder. But also much more meaningful.

And honestly, if you're about to start working soon... just know this:
It probably won’t feel anything like you imagined it would.

Not the language. Not the pressure. Not the communication. Not even your own confidence.
Some things will humble you faster than expected. Some things will confuse you. And some things you thought you were “bad” at will slowly become strengths over time.

But I guess that’s also what makes the whole experience real.

And now I’m curious… Have any of you gone through something similar?

Doesn’t even have to be a new language specifically.
Maybe your first job humbled you.
Maybe moving into a new environment changed how you communicated.
Maybe you realized “knowing” something and actually using it professionally are two completely different experiences.

How did you adapt to it?

Two DEV Users. Two Countries. One Weird Little Avatar Project.

Aryan Choudhary — Wed, 13 May 2026 07:07:13 +0000

We Gave Our DEV Avatar Project a V2… and It Escalated Quickly

A few months ago, @webdeveloperhyper and I made a small side project where two VRM avatars talked to each other in a 3D scene.

At the time, it was just meant to be something fun. Two developers from different countries making weird little animated characters interact over the internet because… honestly, why not?

If you missed the first post, here it is:

How a DEV Friend and I Brought Two Avatars to Life

Back then, the project was much simpler. A conversation system, some VRM animations, a few gestures, and a surprising amount of time spent trying to stop avatars from snapping into cursed poses mid-animation.

We thought we were mostly done with it.

We were very wrong.

Somewhere along the way, the project became… alive

The funny thing about side projects is that they rarely stay contained.

You fix one thing, get one new idea, add one “small feature,” and suddenly a weekend experiment starts behaving like an actual system.

That’s pretty much what happened here.

While I was busy juggling office life, Japanese, engineering work, interviews, marketing side quests, and trying to survive adulthood without my brain overheating… WDH was quietly evolving the project in the background like some kind of sleep-deprived VRM wizard.

And every few days I’d wake up to messages like:

“Added music and music button. Then pushed."

“fix mobile speech bubble layout and responsive avatar positioning”

or sometimes just:

“fixed and pushed.”

And somehow the project kept getting cooler.

The avatars stopped feeling scripted

One of the biggest changes in v2 was that the characters stopped feeling like objects that simply played animations on command.

Now they actually react.

They blink naturally. Follow movement. Shift attention while listening. React while the other character is speaking. Small details, but weirdly important ones.

It turns out humans are very sensitive to tiny signs of life.

A static model feels dead immediately.

But add:

eye tracking
idle movement
small delays
slight reactions
facial expressions …and suddenly your brain starts treating it like a character instead of geometry.

That transition fascinated me way more than I expected.

At one point we spent an unreasonable amount of time adjusting tiny gesture timings that most users probably won’t consciously notice.

But that’s kind of the magic of interactive systems.

The invisible details are usually doing the heavy lifting.

The architecture quietly became more interesting too

The first version was mostly about “getting it to work.”

The second version became more about orchestration.

Now the scene handles:

dialogue sequencing
animation coordination
background switching
music control
expression timing
responsive layouts
costume switching
branching interactions

And because of that, hardcoding behavior stopped making sense very quickly.

So instead of writing giant chains of conditions everywhere, the conversation itself became structured data.

Each dialogue entry knows:

who is speaking
what animation plays
what expression appears
how timing should behave

Which made the system dramatically easier to extend without everything collapsing into spaghetti.

Ironically, the more playful the project became, the more important clean systems thinking became too.

The funniest bugs were always animation-related

There is probably a law somewhere stating that if you work with avatars long enough, something horrifying will eventually happen. And if not it should be.

At various points:

arms rotated into dimensions unknown to mankind
blinking broke and created sleep paralysis avatars
gesture transitions snapped violently
one animation froze mid-pose and looked like the character had emotionally given up on life
Classic side project experience honestly.

But weirdly enough, those moments ended up becoming some of the most memorable parts of the project.

Because every fix made the avatars feel a little more believable.

While all this was happening, @webdeveloperhyper was building something much bigger

And this is honestly the part I respect the most.

While we were experimenting with our collaboration project, WDH was also building something called AI Avatar — a VS Code and Chrome extension where VRM avatars react to AI activity, animate while you work, track your cursor, trigger expressions, speak through speech bubbles, and basically exist beside you like a tiny chaotic coding companion.

The interesting thing is that it never felt like one of those overly corporate “AI productivity” tools trying to optimize your soul.

It felt playful.

Like something made by someone who genuinely likes interactive characters and wants technology to feel a little more alive and personal.

And I think that mindset naturally spilled back into our collab project too.

A lot of the small interaction details, responsiveness ideas, animation handling improvements, and experimentation mentality came from constantly exploring these systems further.

Which honestly reminded me why collaborations matter so much.

You don’t just share workload.

You share ways of thinking.

The project accidentally became a tiny engine

That’s probably the strangest realization from all this.

At some point we stopped thinking:

“we’re making two avatars talk”

And started realizing:

“wait… this is basically becoming a reusable interaction system.”

Now there’s:

branching dialogue
modular animation logic
reusable scene orchestration
dynamic reactions
configurable backgrounds
audio systems
responsive UI behavior And suddenly your silly little side project starts looking suspiciously scalable.

That’s always the dangerous phase.

But honestly, the best part was still the process

The actual code matters, obviously.
But what I’ll probably remember most is:

random weekend debugging
async conversations across timezones
sending screenshots back and forth
testing weird ideas just because they sounded funny
slowly watching something gain personality
That feeling is hard to replicate in structured environments.

No roadmap pressure. No stakeholder meetings. No “business value alignment.”

Just curiosity carrying the project forward.

And honestly?
That’s probably why side projects stay fun.

Where this goes next

Right now, v2 still feels like the beginning.

There are already ideas floating around for:

interactive storytelling
user-triggered reactions
branching scenes
mini-games
dynamic conversations
more expressive characters
Or maybe something completely different. At this point, I’ve stopped trying to predict where these projects go.

The fun part is discovering it while building.

For the people interested in trying it themselves

WDH made a public version available here:

Vercel Demo (with VRMA + MP3)

GitHub Repo (without VRMA + MP3)

And honestly, if you build something weird with it, let us know.

Those are usually the best ideas anyway.

I Didn’t Stop Building. I Just Left My Laptop.

Aryan Choudhary — Wed, 06 May 2026 06:28:42 +0000

Hey there again guys!
It’s been almost two months since my last post. And in the back of my head, there was this constant thought:

“I need to get back to writing.”

But every time I sat down to do it, something else showed up.
Work. Office. Learning. Life just… sped up out of nowhere.

So this isn’t really a “comeback” post. It’s more like a checkpoint.

The pace changed faster than I expected

Since my last blog (the cloud one), things shifted pretty quickly. I started going to the office daily. Got pulled deeper into work. Started communicating with Japanese clients.

And suddenly, I wasn’t just “learning Japanese” anymore. I was using it. In real conversations. With real stakes.

I’m the most junior person on my team. Everyone else is already at N2 or N1 (which are almost the highest level of Japanese language).

So every interaction feels like:

try → struggle → catch one word → reconstruct meaning → survive → repeat

Not graceful. But effective. And weirdly satisfying when it works.

Also, apparently my coping mechanism is… sketching during office hours 😭
Here are a few:

From side projects to real systems

I also started working with mainframes. Can’t really talk about details, but the shift in mindset was interesting.

Before this, most of my experience was:

tutorials
side projects
building things from scratch

Now it’s:

existing systems
constraints I don’t control
decisions that already exist for a reason

And that forced a different kind of thinking. Writing code is one thing.
Understanding why a system is the way it is… is another game entirely. ^^;

Somewhere in between… marketing?

At the same time, I picked up a part-time role in marketing. Not for the money. (Honestly, the pay is minimal. ಥ_ಥ )

But I wanted to understand something I’ve always ignored:

How do you actually get people to care about what you build?

And this added a completely different layer to everything.

choosing the right people for the right tasks
understanding audience
positioning ideas
thinking beyond just “build and ship”

But the surprising part?
I actually enjoy it. I ended up talking to a lot of different people, negotiating deals, figuring out collaborations, managing an intern myself.

And somewhere in the middle of that, I had this random thought:

bro… this feels like something I used to watch in Suits

Like watching Harvey Specter close deals and thinking “damn that’s cool”…

…and then doing a tiny version of that yourself. (☆▽☆)

Not gonna lie though, it is exhausting. My introvert side takes damage every time. But it’s the good kind of damage. The kind you’d still choose again.

Some wins, some misses

I also interviewed for a Cloud Solutions Architect role at Microsoft.
Didn’t crack it. Didn’t impress them the way I wanted to.

But it was still a really good experience. It showed me the gap.
And more importantly, it made the path clearer.

Also… I made them laugh. ヾ(≧▽≦*)o
And weirdly, that’s what I remember the most.

Like yeah, I was nervous. Properly sweating at one point.
But if I can still land a joke in that situation… then I’m probably more capable than I give myself credit for.

Life outside the screen (but still learning)

Somewhere in between all this chaos:

I made some money trading stocks (very little yet very scary ToT)
Tried getting back into Japanese properly (Man ts tuff)
Worked on side projects (one with @webdeveloperhyper - will write about it soon, another with @hisukurifu - still in the planning phase)

And… I went to Comic Con dressed as Monkey D. Luffy 🐐
Which was honestly one of the best decisions I’ve made this year. Something about stepping out of your usual identity and just having fun hits different.

Me (center with one hand up) at comic con:

Something I didn’t expect

I haven’t done much “pure development” lately. And I kind of miss it. Like that feeling of just building something random at 2am for no reason. No requirements. No constraints. Just curiosity.

But at the same time…
I don’t think I stopped building. I just started building different things.

communication
systems understanding
decision-making
real-world context

Things that don’t show up on GitHub.
But probably matter just as much.

I also kinda missed this place

I lowkey missed Dev.to.

The writing. The discussions. Weekly wins by @jess. Meme Mondays by @ben.
Even when I wasn’t posting, I’d drop in sometimes.
Read a few posts. Leave a comment here and there.

@javz, @francistrdev, @webdeveloperhyper — some really good stuff lately.

Felt nice just being around.

What comes next

I still want to build something. But not just for the sake of building.
Something genuinely useful. Something that actually matters.

And I have this feeling…
that all these side quests are slowly connecting toward that.

So the next thing I build?
It won’t just be another project. It’ll mean something.

If you’re still here

I somehow have ~6k people following me here.
Which still feels a bit unreal if I'm being honest.
So I figured it’s only fair to say where I’ve been.

If you’re curious about anything:

working with Japanese clients
mainframes
cloud prep / interviews
balancing work + side projects
marketing & negotiations

Ask away and I’ll probably turn those into the next few posts.

And so… to wrap this up, it’s been a bit overwhelming.

New work. New expectations. New environments. Trying to keep up, trying to grow, trying to not fall behind. Some days it feels like everything is happening at once. But somehow… I’m still here.

Still figuring things out.
Still saying yes to things.
Still trying new stuff.
Still grateful for everything.
Still staying a little silly through it all.

I’ve learned to call it “funmaxxing.”
Because if things are going to be chaotic anyway… might as well squeeze as much life out of it as possible.

So yeah, still learning, still building (just in different ways), still confused… but moving forward anyway.

My Dad Said: Start With Compute. Now I See Why.

Aryan Choudhary — Sat, 07 Mar 2026 21:01:27 +0000

When I told my dad I had started learning Azure, he asked me one question.

“Where did you start?”

I mentioned tutorials, some documentation, and browsing the portal.

He said something simple:

“Start with compute. Everything else in the cloud builds on top of it.”

At the time, it sounded obvious. Of course applications need computers to run.

But when I opened the Compute section inside Azure, I started seeing what he actually meant.

The moment cloud stopped being abstract

In tutorials, cloud computing often feels very conceptual.

You hear words like scalability, high availability, distributed systems, and managed services.

But those are still ideas.

When you open the Compute section in Azure, the abstraction disappears.

Suddenly you see things like:

Virtual Machines
Virtual Machine Scale Sets
Images
Availability Sets

At first glance, it looks like a lot of different services.

But underneath, they all revolve around one question:

Where does your code actually run?

Because before anything else in the cloud can exist - databases, APIs, storage, authentication - something has to execute the code.

And that something is compute.

Virtual Machines: the cloud version of “another computer”

The first thing that stood out to me was Virtual Machines.

I already knew the concept. A virtual machine is basically a computer running inside another computer.

But seeing it in the cloud made it feel different.

Instead of running a VM on my laptop, Azure was essentially offering me a computer somewhere in a data center.
CPU. Memory. Disk. Operating system. All configurable.

Which immediately made me realize something:
Running a VM isn’t just about deploying code. It means you’re responsible for the machine.

That includes things like:

managing the operating system
updating dependencies
monitoring resource usage
handling crashes
planning for scaling

Suddenly cloud felt less like a magic deploy button and more like real infrastructure, And that's when it made sense for me...

Why abstraction exists in the first place

This also made me appreciate platforms like Vercel more.

When I deploy projects there, I never think about:

CPU
RAM
operating systems
load balancing

Those problems are handled for me.

Azure still provides those abstractions too, through services like App Service and Functions.

But it also lets you go deeper.
And that’s the interesting part.
Cloud platforms operate on layers of abstraction.

At the lowest layer, you have machines.
At higher layers, those machines disappear behind managed services.

Understanding compute is like seeing the foundation under the building.

The moment cloud felt more real

Before this, deployment always felt like the final step of building something.

You finish coding, push your repo, click deploy, and move on.

But seeing compute changed that perspective slightly.
Deployment isn’t the end. It’s the point where your code finally meets the machines that will run it.

And suddenly questions like these start to matter:

How many machines are running my app?
What happens if one crashes?
What happens when traffic spikes?
How much does it cost to keep these machines running?

I still have a lot to figure out

Ironically, I wasn’t even able to experiment much yet because I ran into an account issue while trying to explore the free tier.

So most of this realization came just from exploring the compute section and thinking through what these services represent.

But even that small exploration already made the cloud feel less mysterious and more tangible.

Where this journey goes next

This is the second step in a small series where I’m documenting what I learn while exploring Azure and cloud architecture.

Last time, I wrote about opening the Azure Portal and realizing how big the cloud ecosystem actually is.

This time, I realized something simpler:

Everything eventually comes back to machines.

Compute is where cloud stops being abstract and starts becoming engineering.

And now I’m curious:

If you’ve worked with cloud platforms longer than I have,
what was the moment when cloud finally “clicked” for you?
Was it compute, networking, containers, something else entirely?

Because I feel like I’ve only just found the first layer.

I Clicked ‘Azure Portal’ and Realized How Small My World Was

Aryan Choudhary — Mon, 23 Feb 2026 18:03:43 +0000

When I opened the Azure Portal for the first time, my first instinct wasn’t curiosity. It was panic.

There were hundreds of services. Compute. Storage. Networking. DevOps. Identity. Containers. Things I had never used. Things I didn’t fully understand. Things I didn’t even know existed.

It felt less like opening a tool and more like opening control panel for the internet itself. Up until now, my mental model of deployment was simple.

I build something in React or Node.
I push to GitHub.
I connect it to Vercel.
I click deploy.
It works.

My app is live. End of story. Yay.

I never really questioned what happened after that.
Not because I didn’t care, but because I didn’t need to.

Platforms like Vercel are designed to remove friction. They hide infrastructure. They give you a clean interface where deployment feels instant and effortless.

But that abstraction also hides something important: the system underneath.

Azure doesn’t hide the system. It exposes it.
And that’s when I realized how small my world had been.

Before this, “cloud” was mostly a conceptual idea to me.

I knew the definitions. I knew cloud meant running software on remote servers instead of your own machine. I knew it helped with scaling, reliability, and availability.

But those were just words. Opening Azure made it real.

I wasn’t just deploying code anymore. I was seeing the environment that makes deployment possible. I started seeing that every running application depends on multiple layers beneath it.

There’s compute: the actual machines that execute your code.
There’s storage: where your files, databases, and state live.
There’s networking: how different parts of your system communicate with each other.
There’s identity and access control: deciding who can access what.
There’s monitoring: tracking what happens when things fail.
There’s scaling: handling more users without crashing.

When I deployed to Vercel before, all of this still existed. I just never saw it.

Vercel handled it for me.
Azure showed it to me.
And seeing it changed how I think about software.

One thing that confused me initially was why Azure had so many separate services. It felt unnecessarily complicated.

Why couldn’t it just be one “Deploy App” button?

The answer became clearer the more I thought about real-world systems. Not all applications have the same requirements.

A personal portfolio might only need basic hosting.

But something like a banking system needs strict network isolation, encrypted storage, identity management, access policies, backup systems, regional failover, and detailed monitoring.

These aren’t optional features. They’re requirements.

Platforms like Vercel simplify things by making decisions for you. Azure gives you the ability to make those decisions yourself.

That flexibility is what makes it powerful. It’s also what makes it overwhelming at first.

This also helped me understand where DevOps fits into the picture.

Before this, my workflow ended at deployment. Once the app was live, I moved on. But in real systems, deployment isn’t the end. It’s part of a continuous lifecycle.

Code needs to be built automatically, tested automatically, deployed automatically, monitored continuously, and recovered automatically when failures happen.

DevOps connects development and production into a single, reliable system. It ensures software doesn’t just run once, but continues running reliably under real-world conditions.

Another realization was that Azure isn’t fundamentally different from platforms I’ve already used. The architecture is actually very similar.

A typical application I build might have:

A React frontend
A Node backend
A database

On Azure, those same pieces exist.

The frontend can run on Azure Static Web Apps.
The backend can run on Azure App Service.
The database can run on Azure SQL or Cosmos DB.

The structure is the same. The difference is visibility and control.

Azure shows you how everything connects. It exposes the building blocks.

This also made me understand the role of a Cloud Solution Architect better.

Initially, I assumed cloud providers handled everything.
But cloud providers don’t design your system. They provide the tools.

Architects design how those tools are used.

They decide how services connect, how systems scale, how security is implemented, and how failures are handled. They design the structure that allows software to run reliably in the real world.

Azure provides the pieces. Architects decide how to assemble them.

What surprised me most wasn’t how much I didn’t know.

It was how much existed beneath the surface of things I thought I already understood. Deployment had always felt like the final step.

Now it feels like the beginning of understanding how software actually lives.

I didn’t deploy anything today. I didn’t build anything new.
I just opened the portal, explored, and realized there’s an entire layer of software engineering I’m only beginning to see.

And honestly, my brain is fried.

I’m going to be exploring Azure more deeply over the coming weeks and documenting the most interesting things I discover along the way.
But for today, I’m done.

If you’ve been further down this path, I’d genuinely love to know:

What’s one thing you wish you understood earlier when you started learning cloud?

How a DEV Friend and I Brought Two Avatars to Life

Aryan Choudhary — Mon, 16 Feb 2026 06:31:42 +0000

I met @webdeveloperhyper on the DEV Community, and like most good internet collaborations, it started casually.

A few messages. Some feedback. Valuable guidance.

Then at some point, the conversation shifted from “this looks cool” to “let’s make something fun together.”

We didn’t over-plan it. We just started building.

They were in Japan. I was in India. Which meant most of this project happened in small pockets of time. Late nights. Random 20-minute windows during the day. Messages sent hours apart. Progress that didn’t look dramatic, but quietly accumulated.

Somehow, it worked.

From basic shapes to actual avatars

The project didn’t begin with polished characters. It began with simple shapes in a scene, just placeholders to test positioning, camera, and basic interaction.

The idea was simple. Two characters. A short conversation. Some animation.

Simple ideas tend to hide interesting problems.

My first real task was creating the avatar itself using VRoid Studio. That alone was a learning curve. Once imported, the avatar didn’t behave like a character. It behaved like a static object.

The default pose was a T-pose. Arms stretched out. Completely lifeless. Fixing that was the first small victory. Getting the avatar into a neutral stance, hands down, just standing naturally.

It sounds minor. But that was the moment it stopped looking like a model and started looking like a character.

From there, we began layering gestures.

Hello animations. Goodbye animations. Small movements during conversation. Even a sigh animation that became one of my favorite details.

There was also a failed attempt at overriding default gestures directly, which taught me very quickly that animation systems have their own rules.

Writing the conversation was harder than expected

Surprisingly, one of the hardest parts wasn’t technical. It was writing the conversation itself.

Short. Natural. Slightly funny. Not robotic.

When dialogue is too long, it feels forced. Too short, it feels empty. Too serious, it loses charm. Too silly, it loses believability.

Finding that balance took more iterations than expected.

I still think the punchline could be better. But maybe that’s a good thing, leaves room for evolution.

When rendering avatars becomes a systems problem

Rendering avatars is straightforward with modern tools. The real challenge was orchestrating behavior.

We needed the scene to manage:

• who speaks
• what animation plays
• when it starts
• when it ends
• when the next character takes over

So instead of hardcoding behavior, we defined dialogue as structured data:

const DIALOGUE = [
  {
    speaker: "A",
    text: "I'm Web Developer Hyper. I like to make fun things.",
    animation: "VRMA_03_peace_sign.vrma",
  },
  {
    speaker: "B",
    text: "Hello! I'm Itsugo. And I like turning ideas into something real.",
    animation: "VRMA_04_shoot.vrma",
  }
];

The scene simply interprets this sequence. This separation made the system easier to control, extend, and reason about.
Instead of forcing behavior, we orchestrated it.

The coordination problem

Animations don’t naturally tell your application when they finish.

But timing matters. The next line shouldn’t interrupt too early. And the system shouldn’t freeze if something goes wrong.

So the dialogue system waits for either:

• animation completion
• or a safe timeout fallback

Whichever happens first.

This tiny decision made the system resilient.

Small systems thinking like this often matters more than large features.

You can check it out here!

The invisible part of collaboration

What made this project meaningful wasn’t just the final result. It was the process.

Fixing animation timing. Cleaning unnecessary code. Improving readability. Adjusting gesture intensity. Adding beginner-friendly comments.

And doing it across timezones.

Huge thanks to @webdeveloperhyper for setting up the foundation, pushing the project forward, and tolerating my questionable Japanese during our conversations.(ˉ▽ˉ；)...

This project exists because of that shared effort and patience.

Where this could go next

Right now, it’s just two avatars having a conversation.
But it already feels like the beginning of something larger.

Interactive characters. Story systems. Dynamic dialogue. Maybe something we haven’t even thought of yet.

And that brings us to the real question.

How should we take this forward?

We have some ideas where this could go next, but we want to hear from our awesome followers.

How would you have fun with this project?
No matter how unrealistic it might sound.
Let’s have some fun with this side project.

Closing

This started as a small experiment between two developers who met online.
It became a reminder of why side projects matter.
Not because they are perfect.
But because they are alive.

And sometimes, that’s enough to start something meaningful.

One Month at a Startup: What Stayed With Me After I Left

Aryan Choudhary — Tue, 10 Feb 2026 12:16:15 +0000

I started my first job at a startup at the beginning of January.

The pay was low, the commute was long, and I knew it wasn’t ideal. I told myself it was temporary. I wanted exposure, real responsibility, and a chance to operate inside a fast-moving environment instead of just preparing for one.

At first, it delivered exactly that.

The early momentum

The first week or two felt exciting. Things moved quickly. Decisions were made fast. Features shipped almost immediately. I had responsibility, context, and a feeling of being “in the game.”

It was energizing to see something go from idea to production so quickly. I respected the ambition behind it. Speed, when it works, is intoxicating.

But once the product went live, a different pattern started to emerge.

When speed loses structure

Bugs began appearing in clusters. Not subtle edge cases, but issues that pointed to deeper instability. There was no clear ownership of the system, no consistent handover, and no stable structure to build on. Requirements shifted frequently, sometimes within the same day.

When I suggested slowing down slightly to break problems into parts, define responsibilities, or reduce over-reliance on automation while things were unstable, those suggestions didn’t land as technical input. They were taken personally.

Over time, certain comments started becoming routine.

Being referred to as “the engineer” in a mocking way, while I wasn’t allowed to touch the code and was instead expected to fix things through prompts alone. Being told that if I really knew what I was doing, I would just be handed the tool and everything would magically work. Or that the solution to recurring issues was simply to “write a better prompt.”

Individually, these comments might sound small. Together, they changed the tone of the environment.

What was hard wasn’t disagreement. It was the erosion of trust. I was expected to fix things end to end, but not trusted with real ownership. Responsible enough to take pressure, but not respected enough to shape the system. That gap matters more than people realize.

For a while, I did what most junior engineers do in situations like this. I started doubting myself. I wondered if this was just a skill gap I hadn’t closed yet, or if I was expecting too much too early.

But the doubt didn’t come from the work itself. It came from being held responsible without being trusted, and from being asked to deliver outcomes without being given ownership. Once I separated those things, the self-doubt lost its grip.

The day it became clear

There was one day, right around launch, when everything seemed to pile up.

A technical discussion turned tense. On the way home, my bike broke down and I spent hours just trying to get back. When I finally did, even something small at home failed in an oddly timed way.

None of these things were dramatic on their own. But together, they felt like a signal. Not in a mystical sense. Just a clear reminder that I was stretched thin, absorbing more stress than I had space for.

I took that day at face value, rested, and paid attention to what my body had been telling me for a while.

When my body reacted before my brain did

I didn’t immediately label the situation as unhealthy.
My body did that first.

I started feeling a constant sense of dread before going in. Nausea on the commute. Mouth ulcers showing up out of nowhere. Sleep that never really felt like rest. Anxiety spikes that didn’t match the size of the problems on paper.

That’s when I realized I wasn’t learning cleanly anymore.
I wasn’t curious. I wasn’t experimenting. I was bracing.

There’s a difference between being challenged and being stuck in survival mode. Once I noticed that line had been crossed, it became harder to ignore.

On top of that, payments were delayed. I had to follow up multiple times to get paid. I found myself counting days instead of thinking about growth.
That was the point where the decision became obvious.

Why I left

I didn’t leave because I can’t handle pressure.

I left because pressure without structure isn’t growth.

Speed without clarity isn’t learning.

And low compensation combined with high chaos and no ownership creates a negative return on effort, no matter how much ambition is involved.

The hardest part wasn’t resigning. It was accepting that endurance isn’t the same as progress.

What the month gave me anyway

Despite everything, the month wasn’t a waste.

Being inside an early-stage environment taught me things I wouldn’t have learned from the outside. I saw firsthand how important clear systems, ownership, boundaries, and basic respect in the workplace are for any business to function.

I learned how fragile things become when structure is missing, and how quickly people burn out when everything depends on one person’s control.

I also learned softer but equally important skills. How to communicate in high-pressure environments. How to detach emotionally when things aren’t in your control. How to extract learning even when the environment isn’t ideal.

I got exposure to how startups think about branding, pitching, hiring early talent, and approaching growth and funding. Even watching what didn’t work gave me a clearer picture of what I’d want to do differently in the future.

Those lessons will matter.

Ending in a better place

What made it possible to leave was knowing I wasn’t trapped. During this period, I kept moving forward elsewhere. I advanced through multiple hiring processes, secured an offer from a larger organization, and opened parallel paths that gave me real choice.

That changed everything.

I could step away without panic. Without burning bridges. Without tying my self-worth to a single environment. The decision came from clarity, not desperation.

I don’t see this month as a failure. And I don’t see it as a hero story either.

It was a systems mismatch.
A lesson in boundaries.

It reminded me that tools don’t replace discipline, and speed doesn’t replace structure. Engineering fundamentals, ownership, and clear systems matter more than how fast something ships.

Most importantly, it reinforced something I want to carry forward early in my career: bad systems can quietly make capable people doubt themselves. Good systems do the opposite. They expand confidence instead of eroding it.

Leaving wasn’t about quitting.

It was about choosing not to let the wrong environment define who I become next.

Why do you write?

Aryan Choudhary — Wed, 04 Feb 2026 05:41:16 +0000

A recognition

There is a line by @sylwia-lask that stayed with me when I first read it. She wrote about how writing can feel easier than coding after a long day.

I remember recognizing myself in that immediately. Not because coding is harder. But because writing asks something different from me.

After a full day of debugging, context switching, and holding systems in my head, coding can feel heavy. My brain is already full. Writing, on the other hand, feels like letting the noise settle.

That is why I keep coming back to it.

Writing does not drain me

When I write, I am not trying to solve a problem efficiently. I am trying to understand what I think.

There is no compiler. No correct answer. No pressure to be fast or precise upfront. I can move slowly. I can circle around an idea. I can admit uncertainty without it becoming a blocker.

Most importantly, writing clarifies thought instead of demanding it. I do not need to know exactly what I am saying when I start. The act of writing is how I find out.

That is very different from how I approach code.

Lowering emotional noise

A lot of thoughts do not need solutions. They need space.

When I do not write, those thoughts stay half formed. They repeat. They get louder. Everything feels heavier than it actually is.

Writing externalizes them.

Once something is on the page, it becomes quieter. Not solved. Just contained. That alone makes it easier to think clearly again.

This is especially true when I am tired. Writing helps me process without spiraling. It gives shape to things that would otherwise stay tangled.

Writing as explanation practice

Another reason I write is simpler. It forces honesty.

If I cannot explain something in plain language, I usually do not understand it as well as I think I do. Writing exposes that immediately.

This is not about dumbing things down. It is about removing unnecessary complexity.

The same instinct that makes me want clean systems in code makes me want clear sentences in writing. Both are forms of respect. For the reader and for myself.

Processing without ranting

I try not to vent while writing (ˉ▽ˉ；).... I write to understand why something affected me.

That distinction matters.

Writing lets me slow down emotional reactions and turn them into observations. It creates just enough distance to be honest without being reactive.

By the time something becomes a blog post, it is usually because I have sat with it long enough to see more than one angle.

That is also why I keep the tone simple and human. I am not trying to perform intelligence or confidence. I am trying to be accurate.

Memory, quietly

There is another side effect I did not expect. Writing helps me remember.

Ideas I write about stick longer. Experiences I reflect on become clearer reference points later. Writing turns moments into markers.

I do not always reread my posts. But I remember what I learned while writing them.

Why I keep writing

I do not write because I always have something important to say.
I write because it is how I think when thinking gets crowded.

Coding builds systems. Writing builds understanding. Both matter. But on tired days, writing is what keeps me grounded.

In that sense, writing is not productivity for me. It is recovery.
It is thinking out loud, slowly, without needing to ship.

(Some of these reflections live on DEV. Some live elsewhere, where I give myself more room to be personal)

If you write too, privately or publicly, what is your why?

A quiet thank you

One small thing I want to acknowledge.
Over the last three months, more people started reading what I write than I ever expected. I recently crossed 3,000 followers here, and that number still feels unreal to say out loud.

Not because of the number itself, but because of the conversations that came with it.

Some of the comments I have received made me pause, reread them, and honestly tear up. People sharing their own stories. Saying they felt seen. Saying something I wrote helped them put words to a feeling they could not explain yet.

I think that kind of response is not something you optimize for. You earn it slowly, by being honest and showing up consistently.

So if you have read, commented, or quietly followed along, a big THANK YOU. Your responses have helped me keep going.