DEV Community: Rohan Mirjankar

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

🎨 Gradecraft – 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 Gradecraft, 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/

Gradecraft 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

Gradecraft 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