DEV Community: Tarunya Kesharwani

Before Writing Code, I Reviewed 104 Pull Requests

Tarunya Kesharwani — Wed, 10 Jun 2026 21:46:35 +0000

Before Writing Code, I Reviewed 104 Pull Requests

My Community Bonding Journey as a GSoC 2026 Contributor for WebiU

Sometimes the most important code you write during GSoC isn't written during GSoC at all.

When people think about Google Summer of Code, they usually imagine coding.

Building features.

Opening pull requests.

Writing thousands of lines of code.

Getting things merged.

I thought the same.

Then my GSoC journey started with something completely different.

Reviewing 104 pull requests.

Not writing them.

Reviewing them.

And honestly...

I didn't expect that experience to completely change how I think about software engineering.

From Contributor to GSoC Contributor

A few months ago, I was just another contributor trying to understand an unfamiliar codebase.

WebiU, the project I now work on under Google Summer of Code 2026, is an open-source platform developed by C2SI to showcase repositories, contributors, projects, research work, publications, and community activity.

Like most contributors, I started small.

A few issues.

A few pull requests.

A few discussions.

Then more discussions.

Then architectural discussions.

Then feature planning.

Then roadmap discussions.

And somehow...

Before I realized it, I had become deeply involved in the project.

By the time proposal season arrived, I wasn't proposing random ideas anymore.

I was proposing solutions to problems I had already experienced firsthand.

Problems like:

GitHub API rate limits
Slow request-time data fetching
Scalability bottlenecks
Missing persistence layers
Future infrastructure concerns
Long-term maintainability

The proposal I eventually submitted focused on transforming WebiU from a request-driven GitHub data platform into an event-driven repository intelligence system.

At that point, it sounded ambitious.

What happened next was even more interesting.

The 104 Pull Request Audit

During Community Bonding, one of the first major tasks wasn't coding.

It was auditing pull requests.

A lot of them.

104 open pull requests.

Damnnn.

That number sounds much smaller until you actually start reviewing them.

Some were active.

Some were outdated.

Some solved issues that no longer existed.

Some duplicated each other.

Some conflicted with the future direction of the project.

And some were genuinely good contributions that had simply been sitting there waiting for attention.

The challenge wasn't technical.

The challenge was human.

Every pull request represented somebody's effort.

Someone had spent hours.

Maybe days.

Maybe weeks.

Trying to contribute.

Closing a pull request suddenly feels very different when you realize there's a real person on the other side of it.

For the first time, I experienced open source from the maintainer's perspective instead of the contributor's.

And that perspective changes everything.

The Funny Side of Open Source

Not every review was serious.

Thankfully.

Because after reading pull request number 63, your brain starts asking difficult questions like:

"Why am I doing this to myself?"

One of my favorite moments was opening a pull request discussion expecting serious implementation reasoning...

...only to find random laughing reactions in the middle of a completely serious technical conversation.

There we were discussing architecture decisions...

And somebody was apparently having the time of their life.

Those little moments remind you that behind every GitHub profile is an actual human being.

Open source communities are built by people.

Not repositories.

What Reviewing 104 Pull Requests Actually Teaches You

Reviewing code teaches lessons that writing code never will.

As contributors, we mostly see our own work.

As reviewers, we see everybody's work.

Different coding styles.

Different problem-solving approaches.

Different levels of experience.

Different interpretations of the same issue.

You start noticing patterns.

You start seeing why maintainers ask for seemingly "small" changes.

You begin understanding how tiny implementation details can become future technical debt.

Most importantly, you start appreciating how difficult maintaining a project actually is.

After reviewing that many pull requests, I became significantly more careful when creating my own.

Because now I understood what reviewers see.

Conversations That Changed The Project

Once the pull request audit was largely complete, Community Bonding shifted into something else.

Conversations.

Lots of conversations.

Google Meets.

Slack threads.

GitHub discussions.

Private architecture reviews.

Roadmap planning sessions.

Shoutout to Mahendra Bhaiya and Utkarsh Bhaiya here.

One thing I genuinely appreciated was how direct and practical every discussion was.

Nobody cared about fancy architecture diagrams.

Nobody cared about buzzwords.

Nobody cared about building something that simply looked impressive.

Everybody cared about one thing:

Building something that would actually work.

And that mindset changed how I viewed my own proposal.

The Proposal Was Just The Beginning

When I originally wrote my proposal, I focused heavily on architecture.

Webhooks.

Event-driven systems.

Background workers.

Caching.

Repository intelligence.

Persistent storage.

Queue-based processing.

All the fun distributed systems stuff.

The proposal aimed to move WebiU away from this:

Frontend
   ↓
Backend
   ↓
GitHub API

And toward this:

GitHub Events
      ↓
Webhook Layer
      ↓
Queue
      ↓
Workers
      ↓
Database
      ↓
Cache
      ↓
Frontend

At the time, it felt like the perfect plan.

Then mentor discussions began.

And oooh boy...

The proposal started getting challenged.

In a good way.

The people helping select the proposal were often the same people questioning parts of it the hardest.

Looking back, many of our meetings felt less like mentor meetings and more like architecture review boards.

And honestly?

That's exactly how it should be.

Nobody cared about protecting the proposal.

Everybody cared about improving the project.

Defining The Real P0 Priorities

One lesson became obvious very quickly.

Successful projects are not built by solving every problem.

They are built by solving the right problems first.

Together, we started identifying the actual P0 priorities.

The things that absolutely had to be done before anything else.

1. Deployment Strategy

Before building features, we needed deployment clarity.

Where does the frontend live?

Where does the backend live?

How do we keep costs low?

How do we keep maintenance manageable?

Turns out deployment decisions affect architecture far more than most people realize.

2. Long-Term Cache Strategy

Caching sounds simple until you have to maintain it.

Then suddenly you're discussing:

Cache invalidation
Data freshness
Expiration policies
GitHub API limits
Future scalability

And you realize there are entire careers built around solving these problems.

3. GitHub API Dependency

One of the biggest architectural concerns was reducing dependency on live GitHub API requests.

Every design discussion eventually came back to the same question:

How do we serve more data while making fewer GitHub requests?

That question influenced nearly every major decision.

4. Commitments To Project Leadership

This was probably one of the most eye-opening discussions.

Mentors don't just build features.

They are accountable for outcomes.

They make commitments.

They manage expectations.

They balance technical decisions against practical constraints.

Understanding that changed how I approached every discussion moving forward.

The Maintainer Access Moment

At some point, I noticed something unusual.

I wasn't only contributing anymore.

I was helping review work.

Helping make decisions.

Helping plan execution.

Helping close pull requests.

Helping shape project direction.

That's a level of trust I don't take lightly.

Because every merge.

Every review.

Every approval.

Every decision.

Eventually affects somebody else.

And that's a responsibility worth taking seriously.

Building The Roadmap

Once priorities became clear, I started planning the implementation roadmap.

One thing reviewing 104 pull requests taught me is this:

Large pull requests are painful.

Painful to review.

Painful to test.

Painful to merge.

Painful to maintain.

So instead of building everything at once, we broke the project down into focused phases.

Infrastructure Cleanup
Authentication Foundation
Deployment Preparation
Backend Improvements
Admin Features
Webhook Foundations
Repository Intelligence Systems

Each PR would have a single responsibility.

Each merge would move the project one step forward.

Simple.

Predictable.

Reviewable.

Maintainable.

Accountability

One message from GSoC's Community Bonding period stuck with me.

Mentors guide.

Contributors execute.

The responsibility ultimately belongs to the contributor.

And honestly, I think that's one of the best lessons GSoC teaches.

So I've been documenting everything.

Meeting notes.

Decisions.

Roadmaps.

Discussions.

Trade-offs.

Reasoning.

Not because anyone asked me to.

Because future contributors deserve context.

And because six months later, nobody remembers why a decision was made unless somebody writes it down.

What Comes Next

The funny thing is...

The coding phase has barely started.

The audits are done.

The architecture discussions are done.

The deployment direction is mostly finalized.

The priorities are clear.

Now comes the difficult part.

Execution.

Over the next few months, the goal is to transform WebiU into something faster, more scalable, easier to maintain, and less dependent on request-time GitHub API calls.

But regardless of what gets built next, one lesson will stay with me.

Open source isn't just about code.

It's about responsibility.

Responsibility toward contributors.

Responsibility toward maintainers.

Responsibility toward the people who trust your decisions.

And somehow...

That lesson started with reviewing 104 pull requests.

A Small Surprise

Over the last few weeks, quite a few people have messaged me asking questions like:

How did you write your proposal?
How detailed was it?
What architecture did you propose?
What actually gets someone selected?

And honestly...

When I was applying, I had the exact same questions.

I remember spending hours searching for accepted proposals, architecture documents, timelines, and implementation plans.

So instead of gatekeeping it, let's do the opposite.

Here's the exact proposal that got me selected for Google Summer of Code 2026.

Read it.

Critique it.

Learn from it.

Improve upon it.

Disagree with it.

That's how engineering gets better.

Proposal

https://drive.google.com/drive/folders/1xY4t65HgWwPl6TlEChYB4cvcGIL7i2eQ?usp=sharing

Just remember:

The proposal got me selected.

The real work started after that.

Let's Connect

If you're interested in:

Google Summer of Code
Open Source
Angular
NestJS
System Design
Distributed Systems
Building in Public

Feel free to reach out.

GitHub

https://github.com/TarunyaProgrammer

https://linkedin.com/in/tarunyakesharwani

Portfolio

https://tarunyaportfolio.vercel.app

DEV.to

Tarunya KesharwaniFollow

GSoC contributor building with Angular, NestJS & TypeScript. Interested in OSS, scalable systems, PR reviews, architecture, and developer tooling.

I'm always happy to discuss open source, review ideas, exchange feedback, or just talk about building things on the internet.

And if you're contributing to WebiU...

There's a decent chance I've already broken the thing you're trying to fix.

Stop Watching 40-Hour Tutorials: Here's How I'd Learn MERN Today

Tarunya Kesharwani — Thu, 04 Jun 2026 16:27:16 +0000

Every few weeks, I see someone asking:

"How do I learn MERN Stack?"

And almost every time, the advice looks something like:

Learn HTML
Learn CSS
Learn JavaScript
Watch a 40-hour React course
Watch a 20-hour Node.js course
Watch a MongoDB course
Build a project

Six months later, many people are still stuck in tutorial hell :')

If I had to learn MERN again from absolute zero, I would do things very differently.

Not because tutorials are bad.

But because most people spend far too much time watching and far too little time building xD

Step 1: Finish JavaScript Basics First

Before touching React, Express, MongoDB, or anything else...

Make sure you understand JavaScript properly.

If JavaScript feels confusing, React will feel even worse ._.

Do not rush this step.

Seriously.

You'll thank yourself later :))

Step 2: Learn Basic Git & GitHub

You do NOT need to become a Git wizard.

Just learn the basics.

Most beginners think they need to master Git before writing code.

You don't.

Learn enough to avoid accidentally deleting your work XD

The advanced stuff can come later.

Step 3: React — Don't Overdo Tutorials

This is where many people lose months T_T

If you want a deep, hands-on understanding of React, then watch the freeCodeCamp course.

But here's the thing:

You do NOT have to finish an 11-hour course before building.

A lot of people spend weeks collecting React tutorials...

and somehow never build a React project :')

That's the trap.

Watch.

Build.

Get stuck.

Repeat.

Step 4: Build React Projects

The goal isn't to make them perfect.

The goal is to get stuck.

Because getting stuck is where the real learning starts.

Nobody remembers the tutorial they watched.

Everybody remembers the bug that ruined their entire Saturday XD

Step 5: Node.js - Don't Spend Weeks Memorizing Modules

This might sound controversial.

But don't spend weeks trying to memorize Node.js APIs.

Nobody remembers every method from:

fs
path
stream
crypto
os

And if someone claims they do...

they're probably lying :))

Most developers check docs constantly.

I still do.

Step 6: Learn Express

This is where backend development starts becoming fun :D

Routes start talking to databases.

APIs start returning actual data.

Frontend and backend finally become friends instead of strangers XD

Step 7: Learn Axios

A surprisingly important skill.

This is usually the moment where people go:

"WAIT... my frontend can actually talk to my backend?!"

And suddenly things start feeling like real software :')

Step 8: Learn Testing

Most tutorials completely skip testing.

Then people join a real project and see hundreds of test files.

Their reaction is usually something like:

"What fresh hell is this?" XD

Learn the basics.

Future you will be grateful.

Step 9: MongoDB — Learn the 20% That Gives 80% Results

Many beginners overcomplicate MongoDB.

Honestly?

Just learn CRUD.

No, seriously.

Just CRUD.

Create.

Read.

Update.

Delete.

That's enough to build a shocking number of projects :))

Don't spend three weeks studying database theory before writing your first query.

Step 10: Build a Full MERN Project

Now combine everything.

React + Express + MongoDB.

At this stage you'll discover what you actually don't know.

And trust me...

that list will be longer than expected XD

Which is completely normal.

Step 11: Join Open Source and Get Scared Like Crazy

Seriously.

This was one of the biggest learning accelerators for me.

Find an organization.

Clone their repository.

Run the project.

Watch it fail.

Read the README.

Miss a step.

Watch it fail again.

See 500 folders.

See 20,000 lines of code.

Question your life choices.

Question your career choices.

Question reality itself.

Then slowly figure things out :')

That's where the real growth starts.

Not in tutorials.

Not in courses.

Not in roadmap videos.

In confusion XD

Lots and lots of confusion.

Click the image to explore some of the issues I've worked on in open source :))

The Biggest Mistake Beginners Make

They keep preparing.

Another course.

Another tutorial.

Another roadmap.

Another "complete guide."

Another YouTube playlist.

Another productivity system.

Another Notion page.

Another bookmark folder.

At some point you have to stop preparing and actually build something ¯(ツ)/¯

You won't feel ready.

Build anyway.

Resources I'd Actually Recommend

Instead of collecting hundreds of bookmarks, I'd focus on a handful of high-quality resources and repeatedly use them while building projects.

Express.js

Express Documentation
- https://expressjs.com/

Axios

Axios Documentation
- https://axios-http.com/docs/intro

MongoDB

MongoDB Documentation
- https://www.mongodb.com/docs/
MongoDB University
- https://learn.mongodb.com/

Testing

Final Advice

If I could give only one piece of advice:

Stop optimizing your learning roadmap and start building.

Most developers don't have a knowledge problem.

They have an execution problem.

Build projects.

Join open source.

Get stuck.

Figure things out.

That's where the real learning happens.

Let’s Connect

If you're also learning, building, or exploring software engineering beyond tutorials, feel free to connect.

LinkedIn: https://www.linkedin.com/in/tarunyakesharwani/
X/Twitter: https://x.com/TarunyaKesh
GitHub: https://github.com/TarunyaProgrammer

I regularly write about:

Open Source
GSoC
Angular
React
NestJS
TypeScript
Backend Engineering
Software Architecture

Still learning.

Still breaking things.

Still Googling error messages.

Still reading documentation.

Still wondering why the code worked yesterday but not today XD

And still convinced that building beats watching :))

Open Source Changed How I Think About Software Engineering

Tarunya Kesharwani — Thu, 07 May 2026 20:33:49 +0000

A few months ago, I thought software engineering was mostly about building features that worked.

If the app ran, the API responded, and the UI looked decent — I considered the job done.

Then I started contributing to open source.

And honestly, it completely changed the way I look at software development.

Suddenly, I realized how much tutorials usually skip.

Not just coding.

But things like:

understanding someone else’s code,
writing maintainable features,
reviewing pull requests,
handling feedback,
debugging strange edge cases,
and building software with other people.

“Working” Code Isn’t Always Good Code

One of the biggest mindset shifts for me was realizing that real engineering is full of tradeoffs.

Earlier, I used to think:

“If it works, it’s done.”

Now I catch myself thinking:

“Will this still make sense 6 months later?”

Things I barely paid attention to before suddenly started becoming important:

readability
architecture
API design
state management
scalability
maintainability
collaboration
PR review quality

And the more I learned, the more I realized software engineering is much bigger than just writing code.

Open Source Taught Me More Than Tutorials

Reading other people’s code teaches you things tutorials usually can’t.

You start noticing:

why naming matters,
why maintainers reject “working” code,
why folder structures matter,
and why small engineering decisions become important at scale.

Even a small PR review comment can sometimes teach more than an entire tutorial video.

That honestly surprised me.

What I’m Learning Right Now

Currently, I’m exploring:

Angular
React
NestJS
TypeScript
RxJS
Redis
backend systems
system design
OSS workflows

Recently, being selected as a GSoC contributor pushed me even deeper into understanding how collaborative software development actually works in real projects.

And I still feel like I’m only scratching the surface.

What I’ll Write About Here

I want this blog to become a place where I document:

lessons from open source,
frontend/backend engineering,
debugging experiences,
architecture ideas,
developer tooling,
PR review insights,
and mistakes I make while building projects.

Not as an expert.

Just as someone genuinely trying to understand how real software gets built.

Still learning.

Still curious.

Still occasionally overthinking architecture decisions.

Let’s Connect

If you're also learning, building, or exploring software engineering beyond tutorials, feel free to connect.

LinkedIn: TarunyaKesharwani
X/Twitter: TarunyaKesh
GitHub: TarunyaProgrammer

DEV Community: Tarunya Kesharwani

Before Writing Code, I Reviewed 104 Pull Requests

Before Writing Code, I Reviewed 104 Pull Requests

My Community Bonding Journey as a GSoC 2026 Contributor for WebiU

From Contributor to GSoC Contributor

The 104 Pull Request Audit

The Funny Side of Open Source

What Reviewing 104 Pull Requests Actually Teaches You

Conversations That Changed The Project

The Proposal Was Just The Beginning

Defining The Real P0 Priorities

1. Deployment Strategy

2. Long-Term Cache Strategy

3. GitHub API Dependency

4. Commitments To Project Leadership

The Maintainer Access Moment

Building The Roadmap

Accountability

What Comes Next

A Small Surprise

Proposal

Let's Connect

GitHub

LinkedIn

Portfolio

DEV.to

Tarunya KesharwaniFollow

Stop Watching 40-Hour Tutorials: Here's How I'd Learn MERN Today

Step 1: Finish JavaScript Basics First

Step 2: Learn Basic Git & GitHub

Step 3: React — Don't Overdo Tutorials

Step 4: Build React Projects

Step 5: Node.js - Don't Spend Weeks Memorizing Modules

Step 6: Learn Express

Step 7: Learn Axios

Step 8: Learn Testing

Step 9: MongoDB — Learn the 20% That Gives 80% Results

Step 10: Build a Full MERN Project

Step 11: Join Open Source and Get Scared Like Crazy

The Biggest Mistake Beginners Make

Resources I'd Actually Recommend

JavaScript

Git & GitHub

React

Node.js

Express.js

Axios

MongoDB

Testing

Final Advice

Let’s Connect

Open Source Changed How I Think About Software Engineering

“Working” Code Isn’t Always Good Code

Open Source Taught Me More Than Tutorials

What I’m Learning Right Now

What I’ll Write About Here

Let’s Connect