DEV Community: Rohan Mirjankar

Building GitHub Authentication: From GitHub App Setup to OAuth Callback

Rohan Mirjankar — Sun, 25 Oct 2026 13:12:48 +0000

Ever wondered what actually happens when you click "Continue with GitHub" on a website?

For JSCrafts, I needed a way to identify users through their GitHub accounts and connect that identity to my application's user database.

I decided to use a GitHub App and implement the authorization flow in Next.js. In this article, I'll walk through the setup, environment variables, authorization redirect, callback handling, and how I connect the authenticated GitHub profile to my database.

Let's break it down step by step.

A GitHub App is like a formal partnership agreement between your application and GitHub users.

Imagine building a passport automation system where you need to authenticate new users. Forget the technical jargon for a moment. Think of it this way: just as a Social Security Number (SSN) can help uniquely identify an individual, GitHub authentication allows your app to identify and verify users through their GitHub accounts.

GitHub offers several ways to authenticate users and access its resources, including Personal Access Tokens, OAuth Apps, and GitHub Apps. Each serves a different purpose, but I needed an approach that would support user authentication while allowing my application to request specific permissions for GitHub resources.

I chose a GitHub App because it offers granular permissions and supports acting both as an application and on behalf of authorized users. This made it a suitable fit for my application's authentication and integration requirements.

I started by navigating to:

GitHub → Settings → Developer settings → GitHub Apps → New GitHub App

GitHub Apps are registered through the Developer settings section of a GitHub account or organization.

Configured the basic details:

Tha callback URL:

The callback URL is the address GitHub sends the user back to after they approve (or deny) login on GitHub's site.

Where do you want the user to be sent after github app does its job?

I registered every URL I will be using
Development: http://localhost:3000/api/auth/github/callback
Production: https://jscrafts.vercel.app/api/auth/github/callback
Permissions

Permissions determine what a GitHub App can access or modify. Granting excessive permissions increases the potential impact of a compromised application.

For the initial setup, I kept repository access read-only and limited the permissions to the requirements of the integration.
Webhooks

GitHub webhooks allow an application to receive event notifications, such as repository-related changes, without continuously polling the API.

I planned to use a webhook endpoint for future repository integration, but the endpoint had not yet been implemented.

Therefore, I deferred webhook configuration until the application had a working endpoint. When webhooks are enabled, the webhook URL and secret must be configured appropriately.
Creating the .env.local File
I added the following environment variable names:

    GITHUB_CLIENT_ID=
    GITHUB_CLIENT_SECRET=
    GITHUB_APP_ID= 
    GITHUB_PRIVATE_KEY=
    GITHUB_WEBHOOK_SECRET=

Value	Meaning	Usecase
GITHUB_CLIENT_ID	A public identifier for the github app. Like a username.	It appears in the URL when redirecting users to GitHub
GITHUB_CLIENT_SECRET	A secret password for the app. Like a password paired with the client ID.	Exchanging the authorization code for an access token
GITHUB_APP_ID	A numeric ID for the GitHub App itself	When your application wants to read repositories on its own behalf.
GITHUB_PRIVATE_KEY	A cryptographic key (.pem file) that proves "I really am the GitHub App."	Generating JWTs to authenticate as the GitHub App itself, used later
GITHUB_WEBHOOK_SECRET	A shared password used to verify that incoming webhook requests actually came from GitHub.	The eventual /api/github/webhook route

Before implementing, understand the actors in our implementation.

The browser is the user, your app server, GitHub's website and GitHub's API.

We need two separate routes to complete the entire flow.

Route 1: Send the user to GitHub.

The URL looks like this:

    https://github.com/login/oauth/authorize
    ?client_id=[GITHUB-CLIENT_ID]
    &redirect_uri=[CALLBACK_URL]

The file you need create is src/app/api/auth/github/route.ts:

export async function GET() {
  // 1. Read the client ID from env
  const clientId = process.env.GITHUB_CLIENT_ID;
  if (!clientId) {
    return NextResponse.json(
      { error: 'GitHub client ID is not configured' },
      { status: 500 },
    );
  }

  // 2. Figure out which callback URL to use
  const redirectUri =
    process.env.NODE_ENV === 'production'
      ? 'https://jscrafts.vercel.app/api/auth/github/callback'
      : 'http://localhost:3000/api/auth/github/callback';

  // 3. Build the GitHub URL
  const githubUrl = new URL('https://github.com/login/oauth/authorize');
  githubUrl.searchParams.set('client_id', clientId);
  githubUrl.searchParams.set('redirect_uri', redirectUri);

  // 4. Send the browser there
  return NextResponse.redirect(githubUrl);
}

When the browser lands on that URL, github checks the client_id and responds to the real Github App.

If they approve --> redirect to the callback url along with ?code=ABC123

If they deny --> redirects back with ?error=access_denied

The code that it sends back when approved is important, its short-lived, single-use and is used with CLIENT_ID for fetching github user details for initial profile building.

Route 2: Receive the user back from GitHub

The file you need to src/app/api/auth/github/callback/route.ts

This is the meat of the login. It does four things in order:

Part 1: Read the code or error

export async function GET(request: NextRequest) {
  const searchParams = request.nextUrl.searchParams;
  const code = searchParams.get('code');
  const error = searchParams.get('error');

  if (error) {
    return NextResponse.redirect(new URL('/?error=github_denied', request.url));
  }

  if (!code) {
    return NextResponse.redirect(new URL('/?error=missing_code', request.url));
  }
  // ... continue
}

Part 2: Exchange code for access token

const tokenResponse = await fetch('https://github.com/login/oauth/access_token', {
  method: 'POST',
  headers: {
    Accept: 'application/json',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    client_id: clientId,
    client_secret: clientSecret,
    code,
    redirect_uri: redirectUri,
  }),
});

const tokenData = await tokenResponse.json();

if (!tokenResponse.ok || !tokenData.access_token) {
  return NextResponse.redirect(new URL('/?error=github_token_exchange', request.url));
}

Part 3: Fetch the user's profile

const githubUserResponse = await fetch('https://api.github.com/user', {
  headers: {
    Authorization: `Bearer ${tokenData.access_token}`,
    Accept: 'application/vnd.github+json',
  },
});

const githubUser = await githubUserResponse.json();

GitHub returns something like this:

{
  "id": 12345678,
  "login": "rohan",
  "name": "Rohan",
  "avatar_url": "https://avatars.githubusercontent.com/u/...",
  "html_url": "https://github.com/rohan"
}

Part 4: Create the JSCrafts user

await connectDB();

const user = await User.findOneAndUpdate(
  { githubId: String(githubUser.id) },
  {
    githubId: String(githubUser.id),
    username: githubUser.login,
    displayName: githubUser.name ?? githubUser.login,
    avatarUrl: githubUser.avatar_url,
    profileUrl: githubUser.html_url,
    email: primaryEmail,
  },
  {
    new: true,   // return the updated document
    upsert: true, // create it if it doesn't exist
  },
);

What findOneAndUpdate with upsert: true does:

1. Look for a User with githubId = "12345678"
2. If found → update its fields, return it
3. If not found → create a new User with all these fields, return it
This is the classic "find-or-create" pattern. It handles both first-time and returning users in a single query.

Why use githubId as the key?

It's stable — usernames can change, IDs can't.
It's unique — each GitHub account has exactly one ID.

Why new: true ?

Without it, MongoDB returns the old document (before the update). With it, you get the new one, which is what you want for the session step.

What I Learned

Building GitHub authentication for JSCrafts helped me understand three important things:

Permission scoping matters: Request only the access your application actually needs.
OAuth security matters: State validation, secure credential handling, and proper error handling are essential parts of the flow.
Authentication has multiple layers: Authenticating a user through GitHub is different from authenticating the GitHub App itself.

This is an important step in building JSCrafts. The next step is to ensure that the authorization flow is backed by secure session management and that every protected route checks the user's session.

Stop Shipping Broken Env Configs — I Built a Fix

Rohan Mirjankar — Fri, 08 May 2026 14:26:51 +0000

We've all been there. You push to production, the server crashes, and after 20 minutes of debugging you realize DATABASE_URL was never set. Or you've got a .env file with 30 variables and no idea which ones your app actually uses anymore.

I got tired of it, so I built envguard — a zero-dependency environment variable validator and codebase analyzer for Node.js.

What it does

envguard has three main jobs:

1. Validate & coerce at startup — define a schema, and envguard throws a single combined error listing all broken variables before your server even boots.

2. Analyze your codebase — scan your entire project to find variables that are defined in .env but never used in code (dead weight), and variables used in code but missing from .env (silent bugs).

3. Dev Dashboard — a local UI that visualizes your env health in real-time, including type mismatches against an optional schema file.

How it works

The architecture is pretty straightforward — three core modules:

guard.js — validates env vars against a schema at runtime, coercing types ("3000" → 3000, "true" → true) and throwing one combined error if anything's wrong.
scanner.js — recursively walks your project files using three regex patterns to catch every usage style: dot notation (process.env.VAR), bracket notation (process.env['VAR']), and destructuring (const { VAR } = process.env). It also strips comments first so you don't get false positives.
server.js — a lightweight Node http server that runs the scanner on every poll and serves the dashboard UI.

No dependencies. Just native Node.js all the way down.

Usage

npm install @rohansm14/envguard

If anything's wrong, you get one clear error at boot — not a mystery crash at runtime.

CLI scan:

npx envguard

This prints a report of unused and missing variables across your whole codebase.

Dev dashboard:

npx envguard dev-ui

Opens http://localhost:3000 with live polling, type mismatch detection, and status badges for every variable.

What I learned building this

Regex is trickier than it looks. Handling all three usage patterns (dot, bracket, destructuring) while also stripping comments to avoid false positives took a few iterations. The destructuring regex in particular — parsing aliases like const { DB_URL: db } = process.env — was the most fiddly part.

Proxies are powerful but need careful handling. The guard() result is a ES6 Proxy that throws on access to undefined validated keys. Getting that to play nicely with things like toJSON, then, and Symbol properties (which Node and various frameworks probe for) required a bunch of edge case handling.

One combined error > many errors. Throwing all validation failures at once instead of stopping at the first one was a deliberate DX choice — and honestly the thing I'm happiest about. Nothing's worse than fixing one env error, restarting, and hitting another.

The code is open source on GitHub. If you've ever lost time to a broken env config, give it a try — would love feedback!

🌍 I Built an Interactive Climate Simulator Where You Control Earth's Fate

Rohan Mirjankar — Sun, 19 Apr 2026 12:59:34 +0000

This is a submission for Weekend Challenge: Earth Day Edition 🌍

What I Built

I built the Earth Condition Simulator — an interactive, browser-based climate model that puts the fate of our planet directly in your hands.

You control six critical environmental parameters — Temperature, Sea Level, Forest Cover, Pollution, Ice Caps, and Clean Energy — and watch Earth respond in real time. The globe visually reacts to every change: ice caps melt, toxic smog rolls in, forests burn, and oceans turn murky. And yes — Earth has feelings about it.

The core idea was to make climate data feel visceral rather than abstract. Instead of graphs and tables, you get a living, breathing, emoting globe that literally makes a face when things go wrong.

Demo

🔗 Live Demo → rohan-shridhar.github.io/earth

Rohan-Shridhar / earth

Earth Condition Simulator

🌍 Earth Condition Simulator

An interactive, high-fidelity browser-based simulator that puts the fate of our planet in your hands. Adjust environmental factors in real-time and witness the immediate visual and biological consequences on a global scale.

🚀 What I Built

I built an interactive climate model and survival simulator. Users control six critical environmental sliders—Temperature, Sea Level, Forest Cover, Pollution, Ice Caps, and Clean Energy—to observe their real-time impact on Earth's vitality.

The project features a custom-rendered SVG globe that reacts visually to your settings (melting ice caps, toxic oceans, spreading smog) and includes a professional-grade simulation engine that projects human population changes over a 10-year period based on your ecological choices.

🔗 Demo

Live Demo →

✨ Features

Animated SVG Earth: A custom-built globe with organic bezier-path continents and real-time visual updates.
6-Axis Environmental Control: Fine-tuned sliders for a wide range of climate scenarios.
Live…

View on GitHub

Features at a Glance

🌍 Animated SVG Globe — Custom-built with organic Bezier-path continents, real-time ocean color shifting, smog overlays, fire particles, cloud layers, and polar ice caps — all reacting live to your slider input
😊 Earth's Emotional Face — The globe has animated eyes, eyebrows, cheeks, and a mouth that morph across 5 emotional states as Earth Health changes — from rosy-cheeked happiness to X-eyes and a wobbling distressed mouth at near-extinction
🌕 Orbiting Moon with Personality — A textured SVG moon orbits the globe in a proper elliptical path, correctly rendering behind Earth on the far side and in front on the near side. The Moon has its own reactive face — it gets increasingly worried with sweat drops as Earth's condition worsens
🎉 Earth Day Banner — A vertical side panel with a drop-bounce letter reveal animation and SVG confetti explosion (click to trigger again!) celebrating April 22
6 Environmental Sliders — Temperature (−2°C to +10°C), Sea Level, Forest Cover, Pollution, Ice Caps, and Clean Energy
Earth Health Score — A unified 0–1000 vitality meter with reactive color-coded status labels (from Thriving Paradise to Near Extinction)
Real-time Population Ticker — A frame-by-frame world population counter (8.2B baseline) that ticks up or down based on current planetary health
Event Feed — Contextual alerts that surface climate events based on your settings
10-Year Simulation Engine — Year-by-year population projection with animated reveal and color-coded survival verdict
Zero Dependencies — Pure Vanilla HTML5, CSS3, and JS. No frameworks, no libraries, no build step.

How I Built It

This was built using Antigravity — a vibe coding tool powered by Google Gemini 2.0 Pro — with a deliberate "Single File → Split Architecture" workflow.

The Globe Rendering Pipeline

The globe is a layered SVG with groups for ocean, land, clouds, ice caps, smog, fire, and now a face-group on top. Each requestAnimationFrame tick, the renderer recomputes ocean color, shifts atmosphere hue, translates continents and clouds for rotation, calculates biome visibility, and renders fire particles when conditions are right.

Earth's Emotional Face

The face is a set of SVG elements (<ellipse> eyes, <rect> brows, <path> mouth) that get imperatively updated on every slider change. The calcScore() result drives which expression state is applied — 5 tiers from happy to dying. Eyebrows rotate via CSS transform, the mouth path d attribute changes shape, and at critical danger the mouth switches to a wavy path with a wobbleMouth CSS keyframe animation for that extra distress effect.

The Orbiting Moon

The moon orbits on an ellipse (rx: 155, ry: 45) centered on the globe using a moonAngle counter that increments each frame. The depth-sorting trick: if moonY > 130 (front half of orbit), the moon group is appendChild-ed to the end of the SVG so it renders above Earth; otherwise it's insertBefore the ocean layer so it appears behind. The moon's own pupils shift horizontally to always look away from Earth — a small touch that makes it feel alive. Animated sweat drops (slideSweat keyframe) appear on the moon's face when Earth's score drops below 50.

The Simulation Math

The 10-year engine applies weighted penalties per variable per year:

let growth = 80; // Base +80M/yr
growth -= (temp / 10) * 200;
growth -= (poll / 100) * 150;
growth -= (1 - forest / 100) * 100;
growth -= (sea / 10) * 80;
growth -= (1 - energy / 100) * 60;
growth -= (1 - ice / 100) * 40;

The UI

Orbitron + Space Mono for a command-center sci-fi feel. CSS starfield background, reactive glow shadows on the globe, and all slider tracks fill dynamically with the current condition color.

Challenges

SVG Depth Sorting for the Moon — SVG renders in document order, not by Z-index. Getting the moon to appear behind Earth on the back half of its orbit required dynamically re-inserting the moon group into the SVG DOM each frame based on its Y position.

Face Expressiveness in SVG — Making emotions readable at 260px required careful tuning of path coordinates. The eyebrow rotation pivot point matters a lot — transform-origin had to be set relative to each brow's center, not the SVG origin.

Balancing the Simulation Math — The formula needed to feel consequential without being instantly catastrophic. The current weights were iterated ~8 times to hit the right dramatic tension.

Single-File 60fps Performance — Keeping the entire render loop smooth without any virtual DOM or external state management meant being surgical about what gets recomputed each frame vs. what's event-driven on slider input.

Prize Categories

🏆 Best Use of Google Gemini — Built using Antigravity, powered by Google Gemini 2.0 Pro as its underlying model for code generation and iteration.

NotJS: If It's Not JavaScript, It's a Teapot

Rohan Mirjankar — Sun, 05 Apr 2026 16:29:22 +0000

This is a submission for the DEV April Fools Challenge 🫖

What I Built

NotJS — a dead-serious code analyzer that does exactly one thing: tells you whether your code is JavaScript or not.

Does it compile your code? No. Does it run it? Absolutely not. Does it parse an AST? Not even close. It reads your code, runs it through a highly sophisticated™ scoring algorithm (keyword spotting + vibes), and either congratulates you for writing JavaScript or hits you with an HTTP 418 I'm a Teapot for daring to submit Python/Java/Rust/literally anything else.

Features include:

A fake "analysis" progress bar with fake terminal logs that say things like "Cross-referencing ECMAScript spec..."
A confidence meter that always hits 99.99% NOT JAVASCRIPT for non-JS code
A "Convert to JavaScript" button that redirects you to Google Translate
A toast that just says "Just learn JavaScript bro."

Built on the core belief that JavaScript is the only language that matters.

Demo

🔗 Live Demo

JavaScript submitted: 200 OK — JavaScript Detected Successfully. Excellent choice. Superior language.

Submitted some other language: 418 I'm a Teapot — Cannot process non-JavaScript input

Code

Rohan-Shridhar / NotJS

JS code recogniser - Build something completely useless

NotJS 🚫

If it's not JavaScript, it's a teapot.

A dead-serious code analyzer that does exactly one thing — detect whether your code is JavaScript or not.

Features

Fake terminal analysis with fake logs
Scoring engine based on JS keywords, APIs, and vibes
418 I'm a Teapot for Python, Java, Rust, and all other inferior languages
"Convert to JavaScript" button (opens Google Translate)
Toast message: "Just learn JavaScript bro."
99.99% confidence. Always.

Stack

React 18 (no build step)
Vanilla CSS
IBM Plex Mono
Zero backend. Maximum bias.

Built for

DEV April Fools Challenge 2026

License

MIT — but morally, only JavaScript projects should use this.

View on GitHub

How I Built It

Built with React 18 (via Babel standalone, no build step), vanilla CSS, and a deep personal vendetta against other programming languages.

The "analysis engine" (computeScore) is a scoring function that awards points for JS keywords (const, let, =>, async/await), built-in APIs (console.log, fetch, localStorage), and syntax patterns (template literals, optional chaining, spread). It deducts points for anti-patterns from Python, Java, C++, PHP, and Rust. Score ≥ 3 = JavaScript. Score < 3 = teapot.

The UI is a fake terminal — yellow/black JS branding, typewriter headings, animated progress bar, scrolling fake logs. Every screen has an entry animation. The error screen has two buttons: one that shames you before letting you retry, and one that pretends to "convert" your code while opening Google Translate.

Stack:

React 18 (UMD + Babel standalone)
IBM Plex Mono, Space Grotesk, Syne (Google Fonts)
Vanilla CSS (no Tailwind, no UI libs)
Zero backend. Zero actual analysis. Maximum confidence.

Prize Category

Community Favorite — because nothing brings developers together like the shared delusion that their language is the best one. NotJS is a love letter to JavaScript supremacy, a participation trophy for JS devs, and a gentle (aggressive) nudge for everyone else.

Best Ode to Larry Masinter — Larry Masinter authored RFC 2324, the original 418 I'm a Teapot joke RFC from 1998. NotJS is essentially a shrine to that bit. The entire error screen is built around 418, complete with a fake HTTP response payload, a confidence meter, and a redirect to Google Translate as the "conversion engine." Larry planted the seed. NotJS watered it with JavaScript bias.

Most Developers Misjudge Their Skill Level — Here’s How to Actually Know

Rohan Mirjankar — Mon, 16 Mar 2026 10:34:57 +0000

TL;DR for busy folks

Developers often wonder when they stop being beginners and become intermediate or advanced.

This article explains the real differences between these stages, how problem-solving and thinking evolve as developers gain experience, and why factors like imposter syndrome and job titles can make it difficult to judge your level accurately.

The key idea: growth in development is defined by how you think about problems, not just the tools you use.

The Question Every Developer Asks

At some point in every developer’s journey, the same question appears:

“Am I still a beginner?”

Unlike traditional professions, software development doesn’t have clear milestones. There’s no official exam that upgrades you from beginner → intermediate → advanced.

Most developers try to measure their skill level based on:

Years of experience
Number of programming languages known
Complexity of projects
Job titles

But these metrics are misleading.

A developer with 5 years of experience can still be a beginner in mindset, while someone with 2 years of focused problem-solving may already operate at an intermediate level.

The real difference between levels isn’t about how much code you write.

It’s about how you think about problems.

What “Beginner Developer” Actually Means

A lot of developers misunderstand what “beginner” really means.

It doesn’t mean you’re bad at programming.

It simply means your brain is still learning how programming problems work.

Beginner developers usually operate at the syntax level.

They think about questions like:

What function should I use?
What syntax fixes this error?
How do I implement this feature?

Their workflow often looks like this:

Idea → Search Tutorial → Try Code → Error → Debug → Works

And that cycle repeats many times.

What matters most at this stage is practice through projects.

Not courses.

Not theory.

Projects.

Because every project teaches you:

debugging
reading documentation
connecting different tools together

Those skills are what slowly move a developer from beginner → intermediate.

The Turning Point to Intermediate

The transition from beginner to intermediate developer doesn’t happen when you learn a new language or framework.

It happens when you start understanding problems instead of just copying solutions.

At this stage, developers begin to recognize patterns in programming problems. Instead of searching for exact solutions, they start thinking:

“I’ve seen something similar before. I know how to approach this.”

This shift usually happens after building several real projects.

Signs You're Becoming an Intermediate Developer

1. You Can Debug Without Immediately Searching the Internet

Beginners often search the exact error message.

Intermediate developers usually:

read the stack trace
identify where the problem originates
isolate the issue step-by-step

Debugging becomes a logical process rather than trial and error.

2. You Start Writing Cleaner Code

Intermediate developers begin to care about things like:

code readability
proper function structure
meaningful variable names
avoiding duplicated logic

Example:

// Beginner style
let a = users.filter(u => u.age > 18)

// Intermediate style
const adultUsers = users.filter(user => user.age > 18)

The functionality is the same, but the code communicates intent more clearly.

3. You Stop Relying Completely on Tutorials

A major turning point happens when developers stop building projects only by following tutorials.

Instead, they start doing things like:

reading documentation
designing their own project features
experimenting with different approaches

Tutorials become references, not step-by-step guides.

4. You Understand Why Code Works

Beginners often focus on what works.

Intermediate developers begin asking:

Why does this algorithm work?
Why is this API structured this way?
Why is this approach faster?

This deeper understanding helps them solve completely new problems.

5. You Start Thinking About Structure

Instead of writing everything in one file, intermediate developers start organizing code into:

modules
reusable functions
components
services

This is usually the first step toward understanding software architecture.

Things Advanced Developers Do Differently

Advanced developers aren’t defined by the number of languages they know.

What really separates them is how they approach systems, trade-offs, and long-term maintainability.

At this stage, developers move beyond writing features and start thinking about designing software.

1. They Think in Systems, Not Just Code

Beginners focus on functions.

Intermediate developers focus on modules.

Advanced developers focus on systems.

Instead of asking:

“How do I implement this feature?”

They ask:

How will this feature affect the system?
Will this scale with more users?
How maintainable will this be in 6 months?

2. They Make Decisions Based on Trade-offs

There is rarely a perfect solution in software.

Advanced developers understand trade-offs such as:

performance vs readability
simplicity vs flexibility
speed of development vs scalability

3. They Write Code for Other Developers

Beginner mindset:

“Does the code work?”

Advanced mindset:

“Will other developers understand this?”

They prioritize:

clear naming
modular architecture
documentation
maintainability

4. They Anticipate Problems Early

Advanced developers often detect issues before they happen.

Examples include:

performance bottlenecks
scaling problems
security vulnerabilities
tightly coupled code

5. They Focus on Architecture

At this level, developers think about questions like:

Should this be a microservice or monolith?
How should the API be structured?
How will data flow through the system?

Their thinking moves from writing code → designing solutions.

Why Most Developers Misjudge Their Level?

One of the biggest problems in software development is that developers often misjudge their own skill level.

Some beginners think they’re already advanced.

Some experienced developers still think they’re beginners.

This happens because of two major factors:

Psychology
Industry expectations

The Psychology Problem (Dunning–Kruger Effect)

In psychology, there is a concept called the Dunning–Kruger Effect.

It explains why people with low experience sometimes overestimate their ability, while people with higher experience often underestimate themselves.

The journey often looks something like this:

Beginner → “Programming is easy”
Intermediate → “Programming is harder than I thought”
Advanced → “The more I learn, the more I realize I don’t know”

The Imposter Syndrome Trap

Even skilled developers sometimes feel like:

they don't know enough
someone will expose them as "not a real developer"
everyone else understands things better

This is extremely common in development.

Job Titles Are Misleading

Different companies define levels very differently.

For example:

someone with 2 years of experience might be called Senior Developer at a startup
someone with 8 years of experience might still be called Mid-Level Developer at a large tech company

Job titles are not reliable indicators of skill level.

Technology ≠ Skill Level

Knowing many tools doesn’t necessarily mean understanding software engineering deeply.

Advanced developers focus more on:

problem solving
architecture
scalability
design patterns

A Simple Self-Check Framework

Instead of judging your level based on experience or technologies, try evaluating how you approach the same problem.

Example problem:

Build a Task Manager API where users can create, update, and delete tasks.

Beginner Approach

Typical workflow:

Idea → Search tutorial → Copy example → Modify code → Make it work

Example:

app.post('/task', (req, res) => {
  const task = req.body.task
  tasks.push(task)
  res.send("Task added")
})

It works, but may lack:

validation
structure
scalability

Intermediate Approach

Intermediate developers focus on structure.

Example:

router.post('/tasks', taskController.createTask)

export const createTask = (req, res) => {
  const task = taskService.create(req.body)
  res.json(task)
}

They introduce:

controllers
services
modular structure

Advanced Approach

Advanced developers start thinking about system design.

Questions they ask:

How will this scale?
Should caching be used?
What about authentication?
How should services communicate?

Example architecture thinking:

Client → API Gateway → Auth Service → Task Service → Database

Final Thoughts

In software development, the difference between beginner, intermediate, and advanced developers isn’t defined by years of experience or the number of technologies you know.

It’s defined by how you think about problems.

What matters most isn’t how fast you progress, but whether you keep improving your thinking.

Because in the end, great developers aren’t defined by the tools they know.

They’re defined by the problems they can solve.

Where do you think you are right now — beginner, intermediate, or advanced?

I’d love to hear your thoughts and experiences in the comments.

Rise, Shatter, Lead.

Rohan Mirjankar — Mon, 16 Mar 2026 09:00:32 +0000

This is a submission for the 2026 WeCoded Challenge: Frontend Art

What did I build ??

What inspired me ??

The glass ceiling is one of the most enduring metaphors in gender equity — and I wanted to make it visible.

"Rise. Shatter. Lead." is an animated tribute to the women who built the technologies we take for granted every day: Grace Hopper, who invented the compiler; Radia Perlman, whose spanning-tree protocol underpins the modern internet; Kimberly Bryant, founder of Black Girls Code; and Reshma Saujani, who launched Girls Who Code. The central figure — You — sits among them deliberately. Because the next pioneer is still writing their story.

The cracked glass ceiling at the center of the piece isn't decorative. It's a reminder that 27% of the tech workforce being women, and only 18% of tech leadership, isn't a ceiling we've broken yet — it's one we're still cracking.

How I built it ??

The latest version of this piece is built entirely in pure HTML and CSS — no JavaScript whatsoever. Every effect you see is driven by the browser's rendering engine alone:

Star field — 70+ stars rendered using nothing but box-shadow on a single CSS pseudo-element, drifting upward with @keyframes
Glass ceiling crack — SVG lines drawn with animated stroke-dashoffset, each crack radiating outward with a staggered animation-delay
Flying shards — clip-path: polygon() triangles that float and rotate away via keyframe animation
Cinematic headline reveal — each word clips and slides up from a hidden container, staggered for a theatrical entrance
Scrolling pioneers ticker — a seamlessly looping translateX animation across a duplicated flex row, no JS scroll listeners
Hover tooltips & progress bars — pure CSS :hover cascade triggering child opacity, transform, and scaleX transitions

I wanted the code itself to be as accessible as the message — no frameworks, no libraries, just the web platform doing what it was built to do.

My Code

Full source on CodePen: https://codepen.io/Rohan-Shridhar/pen/raMygbG

If you want to contribute, check out my repository on GitHub:

Rohan-Shridhar / womens-day

Frontend Art: Gender Equity

Draw what comes to mind for you when you think of gender equity in tech.

Whether it's a symbolic representation of the "glass ceiling" being shattered, a detailed portrait of a pioneer who paved the way, or a piece of abstract art representing the strength of a diverse community, we want to see your interpretation through code. You may use any frontend tools for this prompt.

View my post

View on GitHub

I Let AI Write My Code for a Week — I Stopped Understanding My Own Project

Rohan Mirjankar — Sun, 08 Mar 2026 17:19:46 +0000

Mistakes Programmers Do While Using AI For Development

TL;DR for Busy Developers

AI can generate code faster than you can think
But debugging AI-written logic is 10× harder
AI hides complexity behind confident answers
If you stop thinking, your skills degrade quickly

The Experiment

Like most developers right now, AI has slowly crept into my workflow.

Autocomplete from Copilot, debugging with ChatGPT, and occasionally asking Gemini for alternative solutions.

Then a slightly dangerous thought crossed my mind.

What would happen if I stopped thinking first… and let AI do most of the work?

So I decided to run an experiment.

For one full week, I let AI write the majority of the code for a small MERN stack application.

The twist?

This was a real college project.

And at the time, I only knew basic HTML and CSS.

No backend experience.

No React experience.

Just AI tools and a deadline.

The stack looked like this:

MongoDB
Express
React
Node.js

My AI toolchain:

GitHub Copilot → inline code suggestions
ChatGPT → debugging and code generation
Gemini → alternative solutions and explanations

The rule was simple:

If AI could generate the code, I wouldn't write it manually.

At first, it honestly felt like cheating.

Features appeared instantly.

Backend routes? One prompt away.

React components? Generated in seconds.

But after a couple of days, something weird happened.

I stopped understanding my own project.

The Rules I Set

Before starting, I needed rules.

Otherwise I would just fall back to writing code myself.

So I created four:

i. Let AI write first

Don't type code until Copilot or ChatGPT generates it.

ii. Only debug using AI

No Stack Overflow or documentation unless AI suggested it.

iii. No outside help

No classmates.

No tutorials.

iv. Don't refactor working code

If it works, move on — even if it's ugly.

The goal was simple:

Can AI carry a beginner — with just HTML and CSS — through a full-stack MERN project?

At first it looked like the answer was yes.

But the more I followed these rules, the more I noticed something strange.

The less I thought about the code…

The more problems started appearing.

Day 1: The Magic Phase

Day 1 felt like magic.

Instead of writing code, I started writing prompts.

Example:

"Create an Express server with MongoDB connection."

A few seconds later — done.

Next prompt:

"Write an Express route to add and fetch users."

Done again.

When I switched to the frontend, AI started generating entire React components before I finished typing.

For someone who only knew HTML and CSS, this felt unreal.

Within a few hours I had:

a running Express server
a working MongoDB connection
multiple API routes
React components displaying data

Normally learning all this would take days.
AI made it feel effortless.

For a moment, I genuinely thought:

"Why do people even struggle with full-stack development anymore?"

Unfortunately…
That confidence didn’t last long.

Day 4: Debugging AI Code Is Painful

By Day 4, something interesting happened.

Writing code wasn’t the problem anymore.

Debugging it was.

Small issues started appearing:

API responses returning wrong data
React state not updating correctly
MongoDB queries behaving strangely

But most of the code was written by AI.

Which meant something uncomfortable:

I didn’t fully understand the logic anymore.

So I followed my experiment rule — ask AI to fix it.

That’s when the real problem started.

The AI would suggest a fix.

Sometimes it worked.

Other times it introduced a new bug somewhere else.

Which created a loop:

Ask AI for a fix
Apply the solution
Something else breaks
Ask AI again

Instead of debugging my project…

I was debugging the AI's suggestions.

The Biggest Mistakes Developers Make With AI

After a week of letting AI write most of my code, I noticed a few patterns.

These mistakes weren't just mine.

A lot of developers are probably making them.

Mistake #1 — Copy-Paste Programming

When AI generates working code, it's tempting to paste it and move on.

But if you don't understand it, debugging later becomes extremely difficult.

Working code without understanding is just delayed confusion.

Mistake #2 — Trusting AI Explanations Too Much

AI rarely says "I don't know."

Instead, it gives confident explanations.

Even when they aren't completely correct.

Sometimes ChatGPT and Gemini even gave different explanations for the same bug.

Both sounded convincing.

Only one could be right.

Real Example from the Experiment

Prompt I used:

Fix this React state bug where the component doesn't re-render
after updating MongoDB data.

AI suggestion:

Use useEffect to re-fetch data whenever state changes.

Result:

Infinite re-render loop.

Mistake #3 — Letting AI Design Your Code

AI is good at generating pieces of code.

But it's not great at designing clean architecture.

Over time this can lead to:

messy logic
redundant functions
inconsistent patterns

Mistake #4 — Losing the Learning Opportunity

Debugging, reading documentation, and experimenting are how developers learn.

AI removes a lot of that struggle.

Which sounds great.

Until you realize you finished the project without fully understanding the stack.

When AI Actually Helps 🌟

Despite the problems, AI was still extremely useful.

The key realization:

AI works best as a productivity tool, not a decision-maker.

AI helped most with:

Boilerplate

Express server setup
MongoDB connections
React component templates

Explaining Errors

Instead of decoding long stack traces, I could ask:

Explain this error and possible causes.

Even if the answer wasn't perfect, it often pointed me in the right direction.

Learning Syntax

AI helped explain:

React hooks
Express middleware
MongoDB queries

Which made learning new concepts faster.

My New Rules for Using AI

After this experiment, I didn't stop using AI.

But I changed how I use it.

Rule #1 — AI Writes Boilerplate, Not Architecture

AI can generate repetitive code.

But developers should design the system.

Rule #2 — Never Run Code You Don't Understand

If you can't explain it, don't run it.

Rule #3 — Debug Yourself First

Try solving the problem manually before asking AI.

Rule #4 — Use AI to Learn, Not Skip Learning

Instead of asking AI to solve everything, ask it to explain.

Example:

Explain how Express middleware works.

Final Thoughts — AI Should Amplify You, Not Replace You

This experiment started with a simple question:

What happens if AI writes most of the code?

After one week, the answer was clear.

AI can speed up development dramatically.

But relying on it too heavily creates new problems:

harder debugging
less understanding of your code
weaker learning of new technologies

AI is an incredible tool.

But it should amplify developers, not replace their thinking.

Demo:

attendance-tracker-seven-kappa.vercel.app

Discussion

Have you ever relied too much on AI while coding?

What was the weirdest bug AI helped (or failed) to fix?

Curious to hear other developers’ experiences.

Building a Browser-Based Pixel Art Tool with Gemini

Rohan Mirjankar — Tue, 03 Mar 2026 17:18:06 +0000

🎨 Gridcraft – A 16x16 Pixel Art Creator Built with Gemini

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built Gridcraft, a clean and simple 16x16 pixel art creator that runs directly in the browser.

The goal was simple:

Create a smooth pixel drawing experience
Keep the UI minimal
Allow exporting without gaps or visual glitches
Make it beginner-friendly but still polished

Google Gemini wasn’t just generating code — it acted like a thinking partner.

I used Gemini to:

Debug CSS grid behavior
Refine canvas export logic
Optimize UI interactions
Improve project structure

Demo

🔗 Live Demo: https://rohan-shridhar.github.io/gridcraft/

Gridcraft allows you to:

Draw on a 16×16 grid
Change colors instantly
Erase pixels
Download your artwork cleanly in .png(no grid borders, no spacing issues)

The downloaded image renders exactly as drawn — no weird gaps between cells.

That detail took real problem-solving.

What I Learned

1. AI Is a Thinking Accelerator

When I asked vague questions, I got vague results.
When I asked precise technical questions, I got precise solutions.

2. UI Details Matter More Than You Think

Tiny things like:

Grid spacing
Cursor size
Border radius
Export rendering

These make or break the feel of a creative tool.

3. Iteration > Perfection

Instead of trying to build everything perfectly at once, I built → tested → refined.

That workflow worked far better.

Google Gemini Feedback

What worked well:

Fast debugging help
Clear explanation of CSS and grid behavior
Helpful suggestions for structuring logic
Great for restructuring messy thoughts

Where I needed more effort:

I had to refine prompts multiple times
Some UI suggestions needed manual adjustment

Overall, it felt less like “generate everything” and more like “co-build and refine.”

That’s the right way to use AI.

Final Thoughts

Gridcraft started as a small idea.

Now it’s a working creative tool — deployed, usable, and something I’m proud to ship.

If you try it, I’d love feedback.

And yes — it’s open on GitHub.

Hack, Reflect, Look Forward: Building My Portfolio with Google Gemini + Antigravity

Rohan Mirjankar — Tue, 03 Mar 2026 10:24:40 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Instead of building yet another template-based portfolio, I decided to experiment.

I built my personal Portfolio using Google’s Antigravity along with Google Gemini as my thinking partner, debugger, and architecture assistant.

The Problem:

Most student portfolios:

Look the same
Focus more on design than depth
Don’t clearly communicate thinking

I wanted mine to:

Show my technical journey (not just projects)
Feel modern and interactive
Reflect how I think as a developer
Be AI-assisted

The Role of Google Gemini

Gemini helped me break the portfolio into meaningful sections instead of randomly stacking components. It felt like having a design-thinking partner on demand. It helped me reason through problems instead of just pasting solutions.
Gemini helped me in three major ways:

1. Architecture Clarity

Before writing code, I asked Gemini to help structure:

Hero section narrative
Projects showcase logic
Skills grouping strategy
GitHub integration ideas

2. UI + Microcopy Iteration

I used Gemini to:

Refine section headings
Improve project descriptions
Make my copy sharper and less generic
Generate alternative layout ideas

3. Debugging + Refinement

While working with Antigravity, I hit issues around:

Component structuring
Responsive tweaks
State management patterns

Demo

View demo

You can explore:

My skills and projects
GitHub integration
Clean responsive UI

What I Learned

1. AI Is a Thinking Tool, Not a Replacement 🚀

I realized the quality of output depended on the quality of my thinking.
When I asked half-baked questions, I got half-baked answers.
When I explained the problem properly — what I tried, what failed, what constraints I had — the responses became much sharper.

2. Prompting Is a Technical Skill ✨

Prompting turned out to be a skill of its own.

I learned to break big problems into smaller, focused questions.
I requested explanations, not just code, so I could actually understand what was happening.
This improved how I solve problems even without AI.

Gemini helped me move faster — but deciding when something was “good enough” was still my responsibility.

Google Gemini Feedback

What Worked Well:

Clear explanations when I asked conceptual questions
Fast iteration cycles
Helped me refine ideas instead of just outputting code
Great for restructuring messy thoughts

Where I Hit Friction:

Sometimes responses were too high-level
Occasionally I had to rephrase prompts for clarity
Needed to cross-check certain implementation details

That friction improved my clarity. It forced better thinking.

Let’s keep learning and building 🚀

My first Dev community post 😊

Rohan Mirjankar — Sat, 28 Feb 2026 04:41:57 +0000

If you are a developer and not aware of github