DEV Community: Aryan Choudhary

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.

Why I Sometimes Leave Tech Events Feeling Smaller

Aryan Choudhary — Thu, 29 Jan 2026 17:40:01 +0000

I haven’t attended many developer events.
The few I have attended left me with a strange aftertaste. Not because anyone was rude. Not because the events were poorly run. But because I often walked out feeling smaller than when I walked in.

On paper, these are exactly the spaces I should enjoy. People building things. Talking about tools. Sharing ideas. Learning together. In practice, I’ve often felt out of place in ways I couldn’t immediately explain.

Yes, part of it is fear of being judged. Yes, part of it is feeling like I’m not good enough yet. But those feelings don’t come from not caring or not trying. They come from how a lot of technical conversations are shaped.

Many discussions move fast. Acronyms stack up. Context is assumed. If you don’t already speak the language fluently, you can fall behind quickly, even if you understand the underlying ideas.
That gap is subtle, but it’s real. And when you’re still building confidence, it can quietly turn curiosity into hesitation.
What I’ve noticed isn’t exclusion. It’s something quieter. Many spaces naturally reward performance. How fluent you sound. How confidently you drop terms. How quickly you signal that you belong.
That works well for people who are already comfortable. For people earlier in their journey, it can feel like you’re trying to keep up with the tone of the room as much as the content.

Over time, that changes how you show up. You ask fewer questions. You nod more. You carry confusion home instead of voicing it. Not because you don’t care, but because you don’t want to slow things down or look behind.
One thing I’ve learned on my own is this: how someone communicates is often mistaken for how much they understand.
Dense language can sound smart. Simple explanations can sound naive. But in my experience, the people who truly understand something can usually explain it clearly, without hiding behind terminology.
That’s the kind of engineer I want to become. Not the one who sounds impressive. The one who makes things easier to understand.

None of this means tech events are bad. They matter. They bring people together. They expose you to ideas and people you might not find on your own.

And I know many people in these rooms are generous and happy to explain things one-on-one.

My hesitation isn’t about rejecting them. It’s about learning how to show up in spaces that weren’t designed specifically for where I am yet.

Beginner-friendly doesn’t just mean allowing beginners in. It means creating room to slow down, to ask simple questions, and to say “I don’t know yet” without it feeling like a liability.
That’s how communities actually grow.

Instead of avoiding these spaces, I’m trying to change how I interpret them. Not as rooms I need to prove myself in, but as rooms I can learn how to be myself in.
That means asking the question even if it feels basic. Admitting when I don’t follow something. Choosing understanding over appearance.
I’m still learning how to do that.

If anything, I’m realizing that part of growing as a developer isn’t just learning tools. It’s learning how to exist in technical spaces without shrinking yourself.
I don’t want tech events to feel smaller. I want them to feel wider. Wider in language. Wider in patience. Wider in who feels like they belong.

I’ll keep showing up. Not because I’ve figured it out. But because I want to learn how to be in those rooms without losing clarity or curiosity along the way.

If you’ve been through this phase, I’d genuinely love to hear what helped you. How did you learn to show up in these spaces without either performing or disappearing?

Brainstorming time fellow devs!!!

Aryan Choudhary — Tue, 27 Jan 2026 16:07:44 +0000

shambhavi525-sudo

Jan 27

Let’s Architect the Future of Neurodiversity. Open Call for Ideas, Pain Points, and Devs. Building for ADHD, Autism, & Dyslexia.

#discuss #mentalhealth #productivity #softwaredevelopment

Comments 12

3 min read

The Hard Part of AI Isn’t the Model. It’s Everything Else.

Aryan Choudhary — Sat, 24 Jan 2026 18:23:43 +0000

When I first wrote about building Commentto, the focus was on why I built it.
This time, the story is different.

What changed over the past few weeks wasn’t the model, the API, or some magical prompt trick. What changed was how I started thinking about the system around the AI and how small, seemingly boring decisions affected whether the output actually felt usable.

I didn’t make the AI smarter.
I made the questions better, and the context more honest.

That turned out to matter a lot more than I expected.

Prompt tightness vs expressiveness

Early versions of Commentto were technically fine.

The comments stayed on topic, followed instructions, avoided hallucinations, and respected every rule I gave them. On paper, everything looked correct. In practice, the output still didn’t feel right. It sounded like what an AI should say, not like what a person would naturally write when reacting to something they just read.

The mistake wasn’t bad prompting.
It was over-constraint.

I was treating every part of the pipeline the same, even though the goals were very different.

So I split responsibility.

Summarization stayed strict, predictable, and conservative
Comment generation was allowed to be more expressive and flexible

To explain this without jargon:
temperature is simply how predictable the model is.

A lower temperature keeps the output stable and repeatable. A higher temperature allows variation in phrasing, tone, and rhythm. Neither is “better” by default. It just depends on what you’re asking the model to do.

So the setup became intentional:

// summarization (accuracy matters more than personality)
temperature: 0.2

// comment generation (personality matters more than precision)
temperature: 0.6

Summaries should be boring and reliable.
Comments should sound like a human reacting.

I also stopped writing long lists of rules and shifted toward behavioral guidance. Instead of telling the model what not to do, I focused on describing how this voice behaves when it speaks. That single change did more for output quality than adding another paragraph of constraints ever did.

Stability didn’t come from more rules.
It came from placing the right constraints in the right place.

And yes, at some point ChatGPT helped me rewrite the prompts, Groq’s API used those prompts, and the AI wrote comments with them. It’s AI all the way down.

Context isn’t universal. It has shape.

The next issue showed up once I stopped testing Commentto on just blogs.

Long-form articles are forgiving. Feeds are not.

Trying to summarize a short post or a tweet using the same logic as a blog almost always produces awkward results. You get things like “This post discusses…” which immediately gives away that something artificial is happening.

The fix wasn’t smarter summarization.
It was understanding what kind of content the user is actually reading.

So I moved to a progressive extraction strategy:

First, try to read what’s visibly taking up space in the viewport
If that fails, fall back to semantic containers like article or main
As a last resort, read the page body

Here’s the core logic:

function extractPageText(): string {
  const viewportText = extractViewportText();

  if (viewportText.trim().length > 300) {
    return viewportText.slice(0, 15000);
  }

  const articleText = extractArticleText();

  if (articleText.trim().length > 300) {
    return articleText.slice(0, 15000);
  }

  return document.body.innerText.slice(0, 15000);
}

Viewport extraction isn’t clever.
It’s just honest.

If something is visible, text-heavy, and occupying real screen space, that’s probably what the user is reacting to. The system shouldn’t pretend otherwise.

The bigger lesson here was simple:
AI pipelines should adapt to the shape of the content instead of forcing everything through the same mental model.

When generation became editing

One feature quietly changed how I thought about Commentto as a product.

Draft enhancement.

Instead of always generating comments from scratch, users can paste something rough and let the AI improve clarity and flow without changing what they meant. The constraint here was critical.

The AI edits.
It does not invent.

Task:
- Improve clarity, flow, and tone
- Preserve the original intent
- Do NOT add new ideas
- Do NOT turn this into a summary

This shifted Commentto from being just a generator into something closer to a writing assistant. Sometimes you don’t want new thoughts. You already know what you want to say. You just want it to come out cleaner.

That distinction mattered more than any new feature.

What this project changed for me

Iterating on Commentto reinforced a few things I’ll probably carry forward into other projects:

AI quality often improves when you remove features instead of adding them
Progressive enhancement beats clever one-pass logic
Small, low-noise affordances outperform heavy configuration
Real-world content is messy, systems should degrade gracefully

Most importantly, I learned to stop fighting the tool.

Understanding comes first. Code comes second.

Closing

Commentto didn’t improve because the AI got smarter.
It improved because the system around it became more intentional and more honest.

No accounts.
No persistence beyond the browser.
No pretending the AI knows more than it does.

I’m planning to release this as a full-fledged Chrome extension next month, and I’m curious what would actually make it more useful for you.

If you were using something like this regularly, what features would you want next?

Learning Starts After Graduation

Aryan Choudhary — Tue, 20 Jan 2026 18:30:58 +0000

Many of us have heard this quote before:
Real Learning Starts After Graduation
For me it started just a little bit before that...

I didn’t leave college angry.
(Actually, I did. ┻━┻ ︵＼( °□° )／︵ ┻━┻)

I also didn’t leave confident.

I had decent grades. I wasn’t struggling academically. I did what I was supposed to do. And yet, after graduating, the question that kept looping in my head was simple and uncomfortable:

Why was I still unemployed while others, not necessarily more skilled, were getting hired?

At first, I assumed I was missing something obvious: intelligence, adaptability, confidence.

Eventually, a harder realization set in.

A lot of early-career outcomes have very little to do with intelligence.
They have a lot to do with timing, access, positioning, and luck.

That realization didn’t make me cynical.
It made me stop waiting to feel “ready.”

Engineering was the default, not a decision

I didn’t choose engineering because I had a clear vision of the kind of developer I wanted to be. I chose it because it was the default serious option. The path was laid out: study, pass, get placed.

Academics were never the issue for me. Being average was acceptable then (not anymore). The system made it easy to coast if you wanted to, and I did.

My world only really expanded in the final semester, when college was already ending.

Six months later, I graduated. To this day, I’m not entirely sure what I wrote in some of those exams, but I passed with good grades. It felt like another fluke. A continuation of a system where outcomes didn’t always correlate with understanding.

The uncomfortable truth after graduation

I knew I would never feel fully prepared. But I also knew that preparation wasn’t coming from the system anymore.

Job applications made one thing clear very quickly:

resumes filter before humans do
interviews reward specific formats (DSA, patterns, buzzwords)
confidence often comes from claim, whether true or false, not capability

That’s when it clicked for me:

I didn’t need to know everything. I needed to know one thing well enough that learning everything else became possible.

So I slowed down.

Instead of chasing readiness, I focused on confidence in a single skill - building things end to end.

Where confidence actually came from

The real shift happened when I built my first app that shipped to the Play Store and App Store.

It wasn’t glamorous. It was a one-time freelance project I took because doing something felt better than doing nothing. But that project cracked the first layer of the iceberg for me.

For the first time, I wasn’t thinking in terms of tutorials or features. I was thinking in systems:

how the product works
how users move through it
how decisions compound

Once that clicked, coding became easier - not because I knew more syntax, but because I knew why something existed.

That confidence compounded. Not confidence in interviews, I still don’t fully have that, but confidence in using tools well and with intent.

Tools, AI, and the illusion of speed

I use AI to code. A lot of us do now.

But I only reach for it after I’ve designed the system the product will operate on. Once the thinking is clear, implementation becomes dramatically easier, with or without AI.

What worries me is seeing speed replace understanding.

I’ve had real conversations where shipping without AI was treated as unthinkable, where systems weren’t questioned because “prompts” could patch over the cracks.

To me, that’s backwards.

Good systems prevent obvious bugs. Tools should accelerate thinking, not replace it.

That emphasis on thinking before execution wasn’t something I learned in college.
It came from learning outside it.

Japanese taught me something college didn’t

Around the same time, I started learning Japanese seriously.

You can’t fake progress in a language. Either you can recall, apply, and adapt - or you can’t. That taught me two things college never emphasized:

consistency beats intensity
expression matters more than correctness

Japanese also gave me words when everything else in my life felt unstable. I was dealing with things I won’t (or can’t) fully write about here. Learning became a form of grounding.

More importantly, it taught me consistency, not as motivation, but as habit.

That consistency bled into how I learned development.

I stopped rushing. I stopped pretending. I started building slowly, deliberately, and imperfectly.

What I wish education focused on instead

Not more tools. Not more theory.

I wish college had focused on:

ownership - seeing things through without external pressure
communication - explaining ideas clearly, not impressively
building end to end - even small, messy projects

Most students optimize for survival because that’s what the environment rewards. Creation requires space, safety, and intent - things institutions struggle to provide.

Conclusion

The world I entered rewards people who can learn continuously, think in systems, and adapt without waiting for permission. I didn’t learn that in classrooms. I learned it afterward, slowly, often alone, and through building things I cared about.

And maybe that’s the transition no one talks about:

graduation isn’t the end of education, it’s the point where it finally becomes intentional.

What did you have to build on your own that formal education never really taught you?