DEV Community: Prayush Adhikari

Learning to Code Without Burning Out: How to Stay Consistent for the Long Haul

Prayush Adhikari — Fri, 16 Oct 2026 18:00:53 +0000

Week one, you were unstoppable. Six-hour sessions, three tutorials a day, a notebook full of plans, and a brand new GitHub account.

Week three, you haven't opened your editor in five days. You feel guilty about it, and the guilt makes you want to avoid it even more. So now you're not just behind, you're avoiding the whole thing.

If that's you, nothing is wrong with your brain or your discipline. You just ran into the most common pattern in learning to code, and it has very little to do with talent. This post is about staying in the game long enough for the skills to stick.

1. The Boom and Bust Cycle

Almost every beginner runs the same loop:

A burst of motivation, usually after a video or a big decision
An intense stretch of doing far too much
Exhaustion, or a hard concept that breaks the streak
Guilt, avoidance, and a quiet quit
A new wave of motivation, and back to step 1

The problem isn't step 4. It's steps 1 and 2. Motivation is a spark, not a fuel. It's great for starting and terrible for lasting. If your plan depends on feeling motivated every day, it will fail on the first bad Tuesday.

2. Think of Your Energy as a Phone Battery

Here's a picture that made this click for me.

Your focus and energy are a phone battery. Every coding session drains some. That's fine, that's what it's for. But there are two things that quietly kill the battery faster:

Background apps. Even when you're not coding, your brain is running apps: the worry that you're behind, five open courses, comparing yourself to someone your age with an internship, the endless scroll of "how I got hired in 3 months." None of it is on screen, yet all of it drains you.

Never charging. Sleep, rest days, food, walks, time with friends. These aren't rewards for finishing. They're the charger. Skip them and you're running at 5% and wondering why nothing sticks.

Staying consistent isn't about draining the battery harder. It's about never letting it hit zero, and closing the background apps.

3. Warning Signs to Watch For

Burnout tends to creep in rather than crash in. Notice if you're feeling:

Dread when you open your editor, not just difficulty
Everything you build feels pointless or not good enough
Irritability or a short temper about small errors
Trouble focusing or reading code you understood yesterday
Sleeping badly, or replaying bugs in your head at night
A constant background feeling of guilt about not doing enough

Catching these early is far easier than recovering from a full crash. If they're heavy, they last for weeks, or they spill into the rest of your life, please talk to someone: a friend, a mentor, a family member, or a professional. Nothing here is a diagnosis, and it's a sign to look after yourself rather than push harder.

4. Build a Minimum, Not a Mountain

The most powerful trick I know for consistency is embarrassingly simple: decide the smallest version of a study session that still counts, and never go below it.

Mine is 20 minutes: open the editor, do one small thing. Write one function, fix one bug, read one page of docs. That's a valid day.

Why it works:

Starting is the hardest part. Once you're in, you often keep going.
A tiny minimum removes the all-or-nothing trap. A bad day becomes a 20-minute day instead of a zero day.
It keeps the habit alive, and habits are what get you through the months where motivation disappears.

If you want a rule to live by: never miss twice. Missing one day is life. Missing two in a row is the start of a new habit. So after a skipped day, do the minimum the next day, no matter how small.

5. Schedule It Like a Class

"I'll code when I feel like it" is the plan that fails. Give your practice a time, like a lecture you've committed to.

A sustainable pattern for a student might look like this:

Day	Plan
Mon to Fri	1 focused hour at a fixed time
Saturday	2 to 3 hours on your project
Sunday	Full rest, no code

That's about 8 to 9 hours a week. It sounds small, and it beats the 12-hour weekend binge followed by two weeks of nothing.

A few extra habits that help:

Work in blocks. 25 minutes focused, 5 minutes break, or 50 and 10 if that suits you better.
Look away from the screen regularly. The 20-20-20 habit is easy: every 20 minutes, look at something about 20 feet away for 20 seconds.
Stop mid-task on purpose. End a session with the next step already written down. It makes tomorrow's start easier.

6. Close the Background Apps

You can't learn well with twelve tabs open in your head.

One learning path. One course, one main project. Not five.
A news diet. Checking tech news, trends, and "top 10 things to learn" every day is a distraction disguised as progress. Try once a week.
Mute the comparison feed. If certain accounts make you feel behind more than inspired, unfollow them. You're allowed to.
Write down the shiny ideas. New framework? New idea? Put it in a "later" list and go back to your work.

7. Track Wins, Not Hours

Counting hours makes you feel guilty when they're low. Counting wins makes you feel progress.

Keep a simple running list in your notes app:

A bug I fixed today
A concept that finally clicked
Something I built and shipped
A question I answered for someone else

Once a week, spend five minutes reviewing it: what did I ship, what did I learn, what's next? On the days when it feels like you're going nowhere, that list is proof that you are.

8. Everyone Feels Like an Imposter

That nagging feeling that everyone else understands things you don't? Almost every developer has it, including people with years of experience and impressive jobs. You only see other people's finished work, never their confusion.

You don't need to feel confident to make progress. You just need to keep showing up while feeling unsure. Confidence follows the work, not the other way around.

9. Look After the Body Running the Code

This part sounds boring and it matters more than any tool:

Sleep. Cutting sleep to study longer is usually a bad trade. Tired brains learn poorly.
Move. A walk, stretching, or a bit of exercise clears your head better than another hour of staring at a bug.
Eat and drink water. It's easy to forget both during a coding session.
Sit well. A better chair or a laptop stand can save you a lot of discomfort down the line.
See people. Time away from screens with friends and family is not wasted time.

10. Learn With Other People

Learning alone is the fastest route to feeling isolated. Find your people:

A study buddy you check in with weekly
A club or community where people build things together
An accountability partner to whom you say what you'll do this week
Teaching others, even a beginner behind you, which cements your own understanding

Sharing what you're stuck on cuts the stress in half, and someone else's small win can pull you through a slump.

11. When You're Stuck on a Plateau

Some weeks nothing seems to improve. That's normal, because learning isn't a straight line. When it happens:

Switch modes. If you've been watching tutorials, build something. If you've been building, read someone else's code.
Shrink the goal. Scale down instead of quitting. One small feature this week is fine.
Take a proper break. Two or three days fully off can do more than a week of forcing it.

Stalling is part of the process. Stopping for good is the only real failure.

12. Coming Back After a Long Break

Say you vanished for a month. Don't start with a guilty five-hour session to "catch up." That's the boom and bust cycle again.

Try a gentle re-entry instead:

Open an old project. Just run it and see it work.
Fix one tiny thing or add one small feature.
Do your 20-minute minimum for a week.
Then slowly build back up.

Nobody is keeping score of the days you missed. The only day that matters is the next one.

Tonight: Set Your Minimum

Before you close this tab, do two things. First, decide your minimum session, the smallest amount of coding that counts. Second, pick a time tomorrow and put it in your calendar.

Not a big plan. Not a new roadmap. Just a small promise you can actually keep.

The people who become good developers aren't the ones who worked the hardest in week one. They're the ones who were still showing up in month six.

Let's Connect

I'm Prayush Adhikari, currently grinding through computer engineering, leading an IT club, and building my own company on the side. I write about Linux, productivity, and the honest side of being a developer.

Tell me in the comments what your own minimum session looks like, or what usually derails your consistency. I read every one.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What should I write next: how to land your first freelance client as a student, or how to build a career network when you don't know anyone in tech?

How to Build Your First Portfolio Website (Even If You're Not a Designer)

Prayush Adhikari — Mon, 12 Oct 2026 16:23:03 +0000

Everyone says you need a portfolio website. Nobody tells you what goes on it.

So you open a blank file, write "Welcome to my portfolio!" at the top, and then spend three hours picking a font. Two weeks later it's still not online, and the folder is named portfolio-final-new.

Sound familiar? Good, because this post fixes it. I'll walk you through what to put on your portfolio, how to make it look decent when you're no designer, and how to get it live without paying anything. No fancy skills required.

1. Do You Even Need One?

Fair question. If you already have a clean GitHub profile (I wrote a whole post on that), you're ahead of most people.

But a portfolio site does something GitHub can't: it lets you tell your own story, in your own order, on your own terms.

GitHub shows your code. A portfolio shows your thinking.
You control what people see first.
You get one link to put on your resume, LinkedIn, and job applications.
It proves you can finish and ship something, which is exactly what employers want to know.

It doesn't need to be huge. One good page beats a ten-page site nobody finishes.

2. Think of It as a Movie Trailer

Here's the mindset that changed how I approach this.

A movie trailer doesn't show the whole film. It shows the best moments in about two minutes, leaves you curious, and makes you want more.

Your portfolio is your trailer. Nobody will read every project description or scroll through everything you've ever made. They'll spend about half a minute deciding whether you're worth a closer look. So show your best three or four moments, make them easy to understand, and give people a clear next step.

3. What to Put On It

Keep it simple. A strong beginner portfolio has five parts:

Hero section. Your name, one line about what you do, and a button that leads somewhere (like "See my projects" or "Contact me"). Example: "Computer engineering student building web tools and learning backend."
Projects. Three or four of your best. Quality over quantity.
About. A short, human paragraph. Where you study, what you're into, what you're learning. Add a photo if you're comfortable.
Skills. A short list of tools you actually use. Skip the progress bars that say "JavaScript 85%." Nobody knows what that means, including you.
Contact. Email, LinkedIn, and GitHub links. Make sure they work.

Optional extras: a link to your resume, and a blog or writing section if you publish posts.

4. How to Present Each Project

This is where most beginner portfolios fall apart. A screenshot and a title isn't enough.

For each project, answer these in a few lines:

What is it? One sentence.
What problem does it solve? Why did you build it?
What did you use? The tech, in a short list.
What was hard? One real challenge and how you dealt with it.
Where can I see it? A live link and a GitHub link.

That "what was hard" line is gold. It shows that you can reason about your own work, and it gives an interviewer something to ask you about. If you used AI tools in the process, say how and where you checked the results.

5. Choose How You'll Build It

You have three realistic paths. Pick one.

Path A: A template or website builder. Fastest. Great if you're short on time or don't want to touch code. The downside is you learn less and it looks less unique.

Path B: Plain HTML, CSS, and a little JavaScript. Slower, but you learn a ton and you fully control it. This is my pick for a first portfolio, especially if you're still learning the basics. A portfolio you coded yourself doubles as a project.

Path C: A framework like React, Astro, or Next.js. Powerful, but it's a lot to learn at once. Choose this only if you already know it.

If you're unsure, go with Path B. Here's how small the starting point is:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Your Name | Web Developer</title>
  <meta name="description" content="Student developer building web tools. See my projects.">
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <header>
    <h1>Your Name</h1>
    <p>Computer engineering student building web tools.</p>
  </header>
  <main>
    <!-- projects, about, contact go here -->
  </main>
</body>
</html>

That's a real starting page. Everything else is filling in sections and styling them.

6. Make It Look Good Without Being a Designer

You don't need talent. You need a few simple rules.

Two fonts at most. One for headings, one for body text. Free options on Google Fonts have plenty of good pairings.
Two or three colors. One background, one text color, one accent for buttons and links.
Lots of whitespace. Crowded pages look amateur. Empty space looks confident.
Consistent spacing. Use the same gaps between sections and cards.
Readable text. Dark text on a light background, or the reverse, with strong contrast. Don't put light gray on white.
Mobile first. Many people will open your link on a phone. Check it there before anything else.

Steal ideas shamelessly, in a good way. Browse a few portfolios you love, notice what they do (spacing, layout, how they show projects), then build your own version. Copying the approach is learning. Copying the code and content is not.

7. The Build Order That Works

Follow this sequence and you'll finish:

Sketch it. A rough wireframe on paper or in Excalidraw. Five boxes, no colors.
Write the words first. Your one-liner, About paragraph, and project descriptions. Design goes faster when the content exists.
Build one page. Get it working end to end, ugly is fine.
Make it responsive. Test on a phone-sized screen.
Add polish. Colors, fonts, a hover effect or two.
Deploy. Don't wait for perfect.

The biggest killer of portfolios is polishing something that isn't online yet. Ship the ugly version, then improve it.

8. Put It Online for Free

You can host a portfolio at no cost. Common options are GitHub Pages, Netlify, Vercel, and Cloudflare Pages. All of them can turn a folder of files into a live link in minutes, usually straight from a GitHub repo, so every update goes live automatically when you push.

Free plans and their limits change over time, so check the current details when you sign up.

Later, consider a custom domain like yourname.com or yourname.dev. It costs a little each year and looks much more professional than a long default address, but it's optional. Don't let it delay your launch.

9. The Small Details That Make You Look Professional

These take ten minutes and set you apart:

Page title and description. What shows up in Google results and browser tabs. Include your name and what you do.
A favicon. The tiny icon in the browser tab. Its absence quietly says "unfinished."
A preview image for link sharing. When you paste your link into LinkedIn or a chat, a good preview card makes people click.
Image descriptions (alt text). Good for accessibility and search.
Compressed images. Huge photos make your site slow, and slow sites get closed.
Working links. Click every single one. Broken links look sloppy.

10. Test It Before You Share It

Do a quick sanity check:

Open it on your phone and on a different browser
Ask three friends to look at it for five seconds, then tell you what you do. If they can't say, your hero section needs work.
Read every word out loud for typos
Make sure the contact links actually open the right thing

Then ask someone in the field for honest feedback. A senior student or a developer in your club works great. Honest feedback stings for a minute and helps for years.

11. Common Mistakes

Waiting for it to be perfect. It never will be. Launch and iterate.
Too many projects. Ten mediocre ones drown out three great ones.
Tutorial clones. Every to-do app and weather app looks the same. Add something of your own.
Fake skill bars and buzzwords. Show, don't claim.
Never updating it. An old portfolio with two-year-old projects says you stopped building.
Ignoring mobile. More people than you think will open it on a phone.

12. Keep It Alive

A portfolio isn't a one-time task. Every few months, add your newest project, retire the weakest one, and reread your bio. Set a calendar reminder so it doesn't rot.

Also, add your portfolio link everywhere: your GitHub profile, LinkedIn, Dev.to bio, resume, and email signature. A great site nobody visits does nothing for you.

Now Go Write One Sentence

Don't open a code editor yet. Open a plain text file and write your one-line intro: who you are and what you build.

Once you have that sentence, everything else gets easier. Then sketch five boxes, write the content, and build it in one weekend. You can improve it forever after that.

Let's Connect

Drop your portfolio link in the comments once it's live. I'd like to see it and give feedback.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What should I write next: how to stay consistent and avoid burnout while learning to code, or how to land your first freelance client as a student?

Git Explained for Beginners (Without the Confusing Parts)

Prayush Adhikari — Wed, 07 Oct 2026 13:35:52 +0000

You've heard everyone say "just push it to GitHub." You nodded. You have no idea what that means.

Or maybe you've memorized git add ., git commit -m "stuff", git push like a magic spell, and the day something goes wrong you have no clue what to do. Delete the folder and clone again? Yeah, I've seen that. I've done that.

Git isn't hard because the commands are hard. It's hard because nobody explains what's happening underneath. Once you have the right picture in your head, the commands stop being spells and start making sense. Let me give you that picture.

1. Git Is a Save System for Your Code

Think about a video game with save points.

Before a boss fight, you save. If you die, you reload and try again. You don't lose the whole game, just the last few minutes. Some games even let you keep multiple save slots so you can try a risky path without wrecking your main run.

Git does exactly that for your project:

A commit is a save point, with a note attached saying what changed
Your history is the list of all your save points, so you can go back to any of them
A branch is a separate save slot where you can try something risky
Merging is bringing the results of one slot back into your main game

That's the whole idea. Everything else is details.

2. Git vs GitHub (They're Not the Same Thing)

This trips up almost everyone at the start.

Git is the tool that lives on your computer and tracks your changes. It works completely offline.

GitHub is a website that stores copies of your Git projects online, so you can back them up, share them, and work with other people. GitLab and Bitbucket do the same job.

If Git is the game, GitHub is the cloud save. You can play without the cloud, but the cloud is how you keep your progress safe and let friends join in.

3. The Three Places Your Code Lives

This is the part tutorials skip, and it's the reason git add confuses people.

Your code moves through three areas:

Working folder. The files you're actually editing right now.
Staging area. A waiting room where you choose which changes go into the next save.
Repository. The saved history, where your commits live.

Picture packing a bag before a trip. Your working folder is your whole room. Staging is the bag on the bed, where you place only what you're taking. The commit is zipping the bag shut and putting a label on it.

Why bother with staging? Because sometimes you've changed five files but only two belong to the same idea. Staging lets you save those two together with a clear note, and leave the rest for another commit. That's what keeps a history readable.

4. Your First Five Minutes with Git

First, tell Git who you are, once per computer:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Now make a project and start tracking it:

mkdir my-project
cd my-project
git init

git init turns the folder into a repository. Create a file, then check what Git sees:

echo "Hello Git" > notes.txt
git status

git status is your best friend. It tells you what changed, what's staged, and what Git isn't tracking yet. Whenever you feel lost, run it.

Stage the file, then save:

git add notes.txt
git commit -m "Add first notes file"

Now look at your history:

git log --oneline

You just made your first save point. That's the loop you'll repeat thousands of times: change files, git add, git commit.

5. Write Commit Messages Future You Will Thank You For

A commit message is the note attached to a save point. Compare these:

Bad	Better
`update`	`Fix login button not responding on mobile`
`stuff`	`Add validation to signup form`
`final final v2`	`Refactor navbar into a reusable component`

A good rule: your message should complete the sentence "This commit will..." in a way that makes sense. Keep the first line short and specific. When you're hunting for the moment a bug appeared three weeks from now, you'll be very glad you wrote real messages.

6. Branches: Try Things Without Fear

Here's where Git gets genuinely powerful.

The main line of your project is usually called main. A branch is a copy of your work where you can experiment. If it goes well, you bring it back. If it goes badly, you throw the branch away and main is untouched.

git switch -c add-dark-mode

That creates a new branch called add-dark-mode and moves you onto it. Make your changes, add, and commit as usual. When you're happy:

git switch main
git merge add-dark-mode

Now main includes your dark mode work. Small habit that will save you a lot of pain: one branch per feature or fix. Keep them small and short-lived.

7. Connecting to GitHub: Push, Pull, Clone

So far everything lives on your laptop. Time to sync with GitHub.

git clone <url> copies an existing GitHub project to your machine
git push sends your new commits up to GitHub
git pull brings down commits that someone else (or another computer of yours) added

To connect a project you started locally, create an empty repository on GitHub, then link it:

git remote add origin https://github.com/your-username/my-project.git
git push -u origin main

After that first time, git push and git pull are all you need. A good habit: pull before you start working, so you begin from the latest version.

8. The Merge Conflict (It Looks Scary. It Isn't.)

Every beginner panics the first time they see this. Let me defuse it.

A conflict happens when two changes touch the same lines of the same file and Git can't decide which one wins. Instead of guessing, it stops and asks you. Open the file and you'll see something like this:

<<<<<<< HEAD
<h1>Welcome to my site</h1>
=======
<h1>Welcome to my portfolio</h1>
>>>>>>> add-new-heading

The top part is your current version. The bottom is the incoming one. Your job is simple: decide what the final text should be, delete the marker lines, and save. Then:

git add index.html
git commit

Done. Git just needed a human to pick a winner. Conflicts get easier the more often you commit small and pull often.

9. Undoing Mistakes (Without Panic)

Everyone makes mistakes. Here's a safe toolkit. First, run git status. It usually tells you the exact command you need.

Throw away edits to a file you haven't committed:

  git restore notes.txt

Careful: this really discards those changes.

Unstage a file you added by accident:

  git restore --staged notes.txt

Undo a commit you've already shared, safely:

  git revert <commit-id>

This adds a new commit that cancels the old one, so nobody's history gets rewritten.

Two commands to treat with respect: git reset --hard and git push --force. Both can destroy work, and force-pushing can wipe out teammates' commits. If you're not completely sure what they'll do, don't run them yet.

10. Don't Commit Your Secrets

This one can genuinely hurt you, so read it twice.

Never commit passwords, API keys, or .env files. Once something is pushed to a public repo, assume the whole internet has seen it, even if you delete it a minute later. Bots scan GitHub for exposed keys constantly.

Use a .gitignore file to tell Git which files to skip:

.env
node_modules/
*.log

If you do accidentally push a key, don't just delete the file. Revoke and replace the key immediately, then clean up. Deleting the commit isn't enough.

11. The Cheat Sheet

What you want	Command
Start tracking a folder	`git init`
See what's going on	`git status`
Stage a file	`git add <file>`
Save a snapshot	`git commit -m "message"`
See history	`git log --oneline`
Make and switch to a branch	`git switch -c <name>`
Switch branches	`git switch <name>`
Merge a branch into the current one	`git merge <name>`
Download a project	`git clone <url>`
Send commits to GitHub	`git push`
Get latest changes	`git pull`

You don't need to memorize all of these today. Print them, tape them next to your screen, and they'll stick on their own.

12. Habits That Make Git Painless

Commit small and often. Many small commits beat one giant one.
Write real messages. Future you is a stranger who needs context.
Pull before you start. Begin from the freshest code.
Branch for every feature. Keep main clean and working.
Run git status constantly. It costs nothing and prevents most surprises.

Now Go Break Something Safely

Make a throwaway folder, run git init, and go wild. Create a branch, mess up a file on purpose, create a conflict, and fix it. There's no better way to lose your fear of Git than breaking it in a place where nothing matters.

Ten minutes of that will teach you more than an hour of reading.

Let's Connect

Tell me in the comments what part of Git confuses you the most. I'll cover it in a follow-up.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What should I write next: how to read and understand error messages, or how to build your first portfolio website from scratch?

Stop Panicking at Red Text: How to Actually Read Error Messages

Prayush Adhikari — Mon, 05 Oct 2026 20:17:03 +0000

Your screen just turned red. There's a wall of text, half of it looks like a foreign language, and your first instinct is to close the terminal and pretend it never happened.

Been there. For an embarrassingly long time, my debugging strategy was to stare at the error for two seconds, decide it was unreadable, and start randomly changing things until it went away. Sometimes that worked. Mostly it made things worse.

Here's the surprising truth: that red wall of text is usually the most helpful thing your computer will ever say to you. It tells you what broke, where it broke, and often why. You just need to learn to read it. Let's fix that.

1. An Error Is a Note, Not an Insult

Most beginners hear error messages as criticism. "You did it wrong." So they look away.

Try a different frame. Think of an error message as a note left by a very literal coworker who can only say what they see: "I got to line 12, tried to use something called total, and I don't know what that is."

It isn't judging you. It's reporting a fact, and the fact narrows your search from "somewhere in my whole project" to "right around this line." That's a gift. A bug with no error message is much harder to find, and I'll get to that later.

2. Read the Whole Thing (Yes, Really)

The number one habit that separates people who debug fast from people who suffer: they read the entire message, slowly, before touching anything.

Most errors contain three useful pieces:

The type. What kind of problem is this? (TypeError, NameError, SyntaxError...)
The message. A short sentence explaining what went wrong.
The location. The file and line number where it happened.

Find those three and you've solved half the problem before opening Google.

3. Follow the Footprints

Here's a real-looking Python error:

Traceback (most recent call last):
  File "app.py", line 8, in <module>
    total = add_prices(cart)
  File "app.py", line 4, in add_prices
    return sum(prices) + tax
NameError: name 'tax' is not defined

Looks scary. Let's read it like a detective following footprints.

This block is called a stack trace (or traceback). It's a trail showing how the program got to the crash: line 8 called a function, and inside that function, line 4 is where things fell apart.

The trick in Python: read from the bottom up. The last line is the actual problem:

NameError: name 'tax' is not defined

Translation: "You used something called tax, but I've never heard of it." Now look one line above: line 4, inside add_prices. You'll spot that tax was never created, or is misspelled, or lives somewhere this function can't see.

Thirty seconds, and you know exactly where to look. No guessing.

JavaScript works a little differently, and the newest line is often at the top of the trace, so check where your browser or tool puts the important part. The reading skill is the same: find the type, the message, and the location.

4. A Field Guide to Common Errors

You'll see the same handful of errors over and over. Learn what they usually mean and you'll recognize most of them on sight.

Error	What it usually means
`SyntaxError`	You broke the grammar of the language: a missing bracket, quote, or colon
`NameError` / `ReferenceError`	You used a variable or function that doesn't exist (yet), often a typo
`TypeError`	You used the wrong kind of thing, like adding a number to text
`IndexError`	You asked for item 5 in a list that only has 3
`KeyError`	You asked a dictionary for a key that isn't there
`Cannot read properties of undefined`	You tried to use a value that doesn't exist, like `user.name` when `user` is empty
`ModuleNotFoundError` / `Cannot find module`	The library isn't installed, or the name or path is wrong
`404`	The page or endpoint you asked for doesn't exist at that address
`401` / `403`	You're not logged in, or you're not allowed to see that
`500`	The server itself crashed. Usually the problem is on their side, not yours

Don't memorize this table. Bookmark it, and let the patterns sink in over time.

5. The Error Might Be Lying (Slightly)

One thing that trips up every beginner: the line number points to where the program noticed the problem, not always where you made it.

The classic case is a missing closing bracket. You forget it on line 10, but the computer keeps reading until line 25 before realizing something is wrong. So the error shows up on line 25.

When the reported line looks perfectly fine, check the lines above it. Look for unclosed brackets, quotes, or parentheses. Nine times out of ten, that's where the real culprit is hiding.

6. Search the Right Way

Once you've read the error and still don't get it, Google is your next move. But there's a way to do this well.

Copy the error message itself, especially the last line. Not your whole file.
Remove parts that are specific to you, like your file paths and variable names.
Add the language or framework in front. "Python NameError name is not defined" beats "my code doesn't work."
Look at results from official docs, Stack Overflow, or GitHub issues first. Skim the answers and check the date, because old answers can be outdated.

Most errors you'll hit have been hit by thousands of people before you. You're rarely the first.

7. Using AI Without Turning Off Your Brain

AI tools are genuinely good at explaining errors. Paste in the message and the few lines of code around it, and you'll often get a clear explanation in seconds.

But use it as a teacher, not a fixer. Instead of "fix this," try:

"Explain what this error means in simple words"
"Where in my code is the likely cause, and why?"
"Give me a hint but don't write the solution"

If you paste the fix without understanding it, you'll hit the same error next week and be exactly as confused. I made the same argument in my earlier posts about learning in the AI era, and it applies double here.

8. When There's No Error (The Silent Bug)

The trickiest bugs are the ones where nothing crashes. The program runs happily and gives you the wrong answer.

No red text means no clue, so you have to create your own clues:

Print your way through it. Add print statements (or console.log in JavaScript) to see what your variables actually hold at each step. Most of the time you'll find that something isn't what you assumed.
Shrink the problem. Remove parts of the code until you have the smallest piece that still gives the wrong result.
Explain it out loud. Describe what each line is supposed to do, to a friend, a rubber duck, or the wall. Somewhere in that sentence, you'll say something that doesn't match the code.
Change one thing at a time. If you edit five things and it starts working, you won't know which one fixed it.

Bugs aren't magic. Every one has a cause, and the goal is to narrow down where it hides.

9. How to Ask for Help So People Actually Answer

Sometimes you're truly stuck, and asking for help is the right move. Vague questions get vague answers, or silence. A good question includes:

What you're trying to do. The goal in one sentence.
What you expected to happen.
What actually happened, with the exact error message pasted as text, not a photo.
The smallest bit of code that shows the problem.
What you've already tried.

Writing the question this carefully often solves the problem before you hit send. And when it doesn't, people answer fast, because you made their job easy.

10. Habits That Make You Faster

Read the error out loud, slowly. It sounds silly and it works.
Don't change random things. Every edit should test a specific idea.
Fix the first error first. Later errors are often just fallout from the earlier one.
Keep a "bugs I've fixed" note. The same mistakes come back. Your own notes are the fastest search engine.
Take a break if you've been stuck for over an hour. Fresh eyes spot the missing bracket in seconds.

Next Time Your Screen Turns Red

Don't close it. Don't panic-click. Take one deep breath and read it from the bottom up. Find the type, the message, and the location.

You'll be surprised how often the answer was sitting right there the whole time.

Let's Connect

Tell me in the comments about the most confusing error you've ever hit. I'd love to see if we can decode it together.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What should I write next: how to build your first portfolio website from scratch, or how to pick a programming language as a total beginner?

Which Programming Language Should You Learn First? (Stop Overthinking It)

Prayush Adhikari — Sun, 04 Oct 2026 04:30:14 +0000

You asked Reddit. You watched three "best language in 2026" videos. You messaged a friend who studies CS. Now you have six different answers, four browser tabs of comparison charts, and zero lines of code written.

I get it. I lost an embarrassing amount of time on this exact question before I wrote a single real program, and I see the same thing every time new members join our IT club. This post will end the debate for you. It won't declare a winner, because there isn't one. It'll give you a way to choose in about ten minutes.

1. The First Language Matters Less Than You Think

Here's what nobody tells beginners: the hard part of programming isn't the language. It's the ideas underneath it. Variables, conditions, loops, functions, and how to break a problem into small steps. Those ideas are the same everywhere.

Look at the same loop in two different languages.

Python:

for i in range(3):
    print("Hello", i)

JavaScript:

for (let i = 0; i < 3; i++) {
  console.log("Hello", i);
}

Same idea, same output, different spelling. Once you truly understand a loop in one language, you understand it in all of them. Your second language will take a fraction of the time your first one did.

So the question isn't "which language is the best?" It's "which language will keep me learning and building until the fundamentals click?"

2. Think of It Like Picking Your First Instrument

Say you want to learn music. Guitar, piano, and drums are all fine choices. What actually matters is what you want to play.

Want to accompany songs around a campfire? Guitar. Want to compose and understand theory? Piano. Want to drive a band? Drums.

Whichever you pick, you learn rhythm, timing, and how to practice. Switch to another instrument later and all of that carries over. Nobody who started on piano is stuck on piano forever.

Programming languages work the same way. Pick based on what you want to make, learn the universal skills, and move sideways whenever you need to.

3. Start From What You Want to Build

Skip the "top languages" lists for a minute and ask a simpler question: what do I want to make?

If you want to build...	Good first choice
Websites and web apps	JavaScript (with HTML and CSS)
Automation, scripts, data work, or AI projects	Python
Android apps	Kotlin (or Java)
iPhone apps	Swift
Games (beginner friendly)	C# with Unity, or GDScript with Godot
Big-name games or engines	C++
Hardware, embedded systems, or operating systems	C or C++
Backend services at scale	Java, C#, or Go

Notice that a few of these overlap. That's fine. You're picking a starting point, not signing a contract.

4. Still Have No Idea? Pick Python or JavaScript

If you genuinely don't know what you want to build yet, which is completely normal, choose between these two. Both are beginner-friendly, both have huge communities, and both have endless free learning material.

Python

Pros: Clean, readable syntax that looks close to plain English. Great for automation, data, and AI. Very forgiving for beginners.
Cons: You don't see visual results as quickly. Building a website or app with it takes extra tools.
Pick it if: You like logic, want to automate boring tasks, or are curious about data and AI.

JavaScript

Pros: Runs in every browser, so you can build something visual and share it with a link on day one. Powers a huge share of the web.
Cons: It has quirks that confuse beginners, and the ecosystem of tools can feel overwhelming.
Pick it if: You want to see your work on screen immediately and you're interested in websites or apps.

If you're still stuck, flip a coin. I'm not joking. The difference between the two for a beginner is small, and the time you spend agonizing is worth far more than any gap between them.

5. What About C, C++, or Java First?

Many colleges start students on C, C++, or Java. If that's your situation, just learn what your course teaches. You'll be tested on it anyway.

These languages are stricter and closer to how computers really work, which makes them harder at first but excellent for understanding memory, types, and performance. Plenty of great engineers started here. They're a fine first language if you have a teacher, a course, or a specific goal that needs them. If you're teaching yourself with no particular goal, a gentler language is usually easier to stick with.

6. Mistakes That Waste Your First Months

Language hopping. Two weeks of Python, then "actually JavaScript is better," then Rust because someone on Twitter said so. Every restart resets your progress. Pick one and commit for at least 90 days.
Choosing by hype or salary lists. Trends change. The person who keeps learning beats the person who chased the trend.
Waiting for the perfect choice. There isn't one. Time spent deciding is time not spent learning.
Learning three at once. One language, one path, one project. Depth first, breadth later.
Learning syntax only. Knowing what a for loop looks like is not the same as being able to solve a problem with it. Build things.

7. Does the Language Even Matter in the AI Era?

Fair question, since AI tools can write code in almost any language now.

Here's my answer: it matters less for typing, and more for understanding. AI can produce a working program in seconds, but you still need to read it, judge whether it's right, and fix it when it breaks. That requires knowing at least one language properly.

So choose one, go deep, and use AI as a tutor along the way. I covered this in more detail in my post about learning to code in the AI era, so check that out if you haven't yet.

8. How Will You Know You've Learned Enough?

You're past the beginner stage when you can:

Build a small project from a blank file without following a tutorial
Read someone else's simple code and roughly follow what it does
Fix most of your own errors by reading the message
Explain, in plain words, what your code does and why

That's the target. Not "finish every chapter." Notice that none of it requires knowing every feature of the language.

9. A Simple 90-Day Plan

Once you've picked, here's a plan that works.

Days 1 to 30: Fundamentals
Learn variables, conditions, loops, functions, and lists. Use one good free resource, and write small programs every day, even ten-line ones.

Days 31 to 60: Small projects
Build three or four tiny things: a calculator, a quiz, a simple tracker. Get stuck on purpose, and fight through it before searching.

Days 61 to 90: One real project
Pick something you'd actually use. Put it on GitHub, write a proper README, and get it online if you can. Show it to someone.

By day 90 you'll have a real project, real confidence, and an easy answer to "what have you built?"

10. When to Add a Second Language

Add another language when:

You've shipped at least one project in your first
A project or job genuinely needs something else
You're curious and the first one feels comfortable

A common and useful pairing is Python for automation and data alongside JavaScript for the web. But that's a decision for later. Right now, your only job is to start.

Decision Time

Answer these quickly and go with your gut:

Do you already know what you want to build? Use the table in section 3.
Does your college require a particular language? Learn that one.
Still no idea? Python if you like logic, JavaScript if you like seeing results.
Still can't decide? Flip a coin, and start today.

The best first language is the one you actually open tomorrow morning.

Let's Connect

Tell me in the comments which language you're starting with and what you want to build. I'll cheer you on.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What should I write next: how to build your first portfolio website from scratch, or how to stay consistent and avoid burnout while learning to code?

Your First Internship: How to Not Feel Completely Lost in Week One

Prayush Adhikari — Thu, 01 Oct 2026 04:02:29 +0000

You got the internship. Congratulations, genuinely. Now the panic sets in: everyone else seems to already know how things work here, the codebase is huge, and you have no idea what you're allowed to ask without looking clueless.

Every intern feels this in week one. What separates the ones who have a great internship from the ones who spend three months quietly terrified isn't skill. It's how they handle exactly this stretch.

1. You're an Exchange Student, Not a Transfer

Think about what it's like being an exchange student at a new school abroad. You don't already know the unwritten rules: how strict this teacher actually is, which shortcuts are fine, which ones aren't, what the local slang means. A smart exchange student spends the first weeks watching and asking quiet questions before assuming their old school's rules apply here.

An internship works the same way. Every team has its own unwritten culture: how they review code, how blunt or gentle their feedback is, what "done" actually means to them. You're not expected to know it on day one. You're expected to notice you don't know it yet, and to learn fast without pretending otherwise.

2. Nobody Expects You to Already Know Everything

This is worth repeating because it doesn't sink in easily: you were hired as an intern, not as a finished engineer. The company already knows you're learning. The pressure you feel to seem competent from day one is almost entirely self-imposed.

What they actually expect:

Curiosity and real effort
The ability to ask for help instead of silently spinning your wheels
Steady improvement over the weeks, not instant mastery
Being pleasant and reliable to work with

Nobody is quietly judging you for not knowing the codebase on day two. They'd be far more concerned by someone who pretends to understand something they don't.

3. The First Week Is for Watching, Not Proving

Resist the urge to immediately prove yourself with something big. The first few days are better spent learning the terrain:

Read the onboarding docs fully, even the boring parts
Set up your development environment and get the existing project running locally
Read through the codebase you'll be working in, even without changing anything yet
Notice communication patterns. Which channel do people use for what? How formal or casual is the tone?
Meet your team, even briefly. A short chat with each teammate is worth more than it seems

You're not being unproductive by doing this. You're building the map you'll need before you can move confidently.

4. Ask Questions the Smart Way

Asking questions is expected and encouraged. How you ask them is what actually gets noticed.

Weak: "This doesn't work, what do I do?"

Better: "I'm trying to do X. I expected Y to happen, but I got Z instead. Here's what I've tried so far. Do you know what I might be missing?"

The second version shows effort, gives your teammate enough to actually help quickly, and doesn't waste their time on back-and-forth just to understand the problem. A good rule: try for fifteen to thirty minutes on your own first, then ask, rather than either giving up instantly or silently struggling for hours.

5. Take Notes Like Your Future Self Depends on It

You'll be told a lot of things in your first weeks: where things live, how to run tests, who owns which part of the system, small quirks that aren't written down anywhere. Write it all down.

Keep a simple running document:

Setup steps you had to figure out
People and what they own or know well
Terms and acronyms specific to this company
Mistakes you made and how you fixed them

Two benefits: you stop asking the same question twice, and by week four you'll have an informal manual that would have saved you a lot of confusion in week one.

6. Understand Before You Touch

When you're finally given a task, resist jumping straight into code. Spend a few minutes making sure you actually understand what's being asked:

Restate the task in your own words to whoever assigned it
Ask about edge cases or ambiguous parts before you start
Check how your task fits into the bigger picture, if that's unclear

A short clarifying conversation up front is far cheaper than building the wrong thing and needing to redo it later.

7. Handling Feedback and Code Review

Your code will get reviewed, and comments will come back. This is one of the best parts of an internship, not a punishment.

Don't take it personally. A comment on your code isn't a comment on your worth
Ask "why" when a suggestion isn't clear, rather than silently changing it without understanding
Say thanks, even for blunt feedback. It signals you're coachable, which people notice and remember
Apply the same feedback proactively next time, which shows you're actually learning, not just fixing one instance

The interns who grow fastest are the ones who treat every review comment as a small, free lesson.

8. Manage Up a Little

You likely have a manager or a mentor assigned to you. Don't wait passively for them to check on you constantly. A little initiative goes a long way:

Give a short update on your progress every few days, even unprompted
Flag early if you're stuck or blocked, rather than waiting until a deadline is at risk
Ask what "good" looks like for your specific tasks, so you're not guessing at the bar

A quick, honest "here's where I am, here's what I'm stuck on" message is one of the simplest ways to look reliable, regardless of your actual skill level yet.

9. Build Relationships, Not Just Output

Your internship isn't only about the code you ship. It's also your first real chance to build a small professional network, which I've written about in more depth separately.

Say yes to coffee chats, casual lunches, or team social time when you can
Ask people about their own path into the field. Most people enjoy being asked
Be genuinely helpful to other interns too, not just senior engineers

These relationships often outlast the internship itself, sometimes becoming references, referrals, or simply people glad to hear from you again later.

10. Document Your Work as You Go

Don't wait until the final week to remember what you did. Keep a running log:

What you built or fixed, in plain language
What you learned that you didn't know before
Any measurable impact, if you can point to one honestly

This becomes the raw material for your resume, your final presentation if there is one, and interview stories for your next application. Trying to reconstruct three months of work from memory in the last week is much harder than logging it along the way.

11. Common Mistakes First-Time Interns Make

Pretending to understand something you don't. It always surfaces later, at a worse time.
Disappearing when stuck. Silence looks worse than admitting you're blocked.
Over-promising on timelines to seem capable, then scrambling to deliver.
Only talking to your immediate team. Meeting people elsewhere in the company opens doors later.
Comparing yourself to full-time engineers. They've had years of practice you haven't had yet.
Not asking for feedback proactively. Waiting for a scheduled review means missing months of smaller course corrections.

12. Using AI Tools During Your Internship

Many companies now allow AI coding tools, some don't, and some have specific rules about what data can go into them. Before using anything, ask what's allowed. Once you know the rules:

Use it to understand unfamiliar code faster, not to avoid understanding it
Never paste proprietary code, credentials, or customer data into a tool without explicit permission
Still be able to explain your own work in review, since "the AI wrote it" isn't an answer your reviewer wants to hear

Week One Checklist

[ ] Get your environment set up and the project running
[ ] Read the docs and skim the codebase before writing code
[ ] Meet your team, even with a short message or call
[ ] Start your running notes document
[ ] Ask at least one question you were nervous to ask
[ ] Send a short first-week update to your manager or mentor

You're Allowed to Not Know Things Yet

Every senior engineer on your team was once exactly where you are now, confused by a codebase, unsure what to ask, quietly worried they didn't belong. The only real difference between you and them is time and a lot of exactly these small, uncomfortable first weeks.

Show up, ask honestly, take notes, and give it real effort. That's genuinely all anyone is expecting from you right now.

Let's Connect

If you're starting an internship soon, tell me in the comments what's making you most nervous. I'll do my best to help.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What should I write next: how to survive group projects with a difficult teammate, or how to turn an internship into a full-time offer?

I Spent a Weekend Binge-Watching LLM Content So You Don't Have To (Okay, You Still Should, But Here's the Map)

Prayush Adhikari — Sun, 27 Sep 2026 13:58:09 +0000

Real talk: everyone and their uncle is "using AI" right now, but ask most people what a token actually is and you get a blank stare. I was in that camp too, not long ago. So this month I did something slightly unhinged — I sat down and went through three completely different explanations of how LLMs actually work, back to back, and it clicked in a way that no single YouTube video was ever going to give me.

Here's the thing: each of these sources attacks the problem from a totally different altitude. One gets its hands dirty with code and whiteboard sketches. One skips theory entirely and just shows you how to build something. And one is basically a full grad-school course crammed into a lecture series. Stack them together and you get something close to an actual curriculum, minus the tuition.

If you're on the same journey — curious about AI beyond "type prompt, get answer" — I'm breaking down what I learned from each one, and honestly, I'd watch them in the same order I did.

Big credit up front to the people who actually made this stuff:

Piyush Garg — "How LLMs Works? - Overview"
Dev Weekends — "Level 0 and Level 1 - Gen AI Sessions"
Stanford Online — "CME295: Transformers and Large Language Models I, Autumn 2025" (Afshine and Shervine Amidi)

Let's get into it.

Part 1: What's Actually Happening Inside the Box

If you've ever nodded along in a conversation about AI while quietly having zero clue what "embedding" means, start with Piyush Garg's video. It's not a theory lecture — it's a "let me rip the hood off this thing" video, and it works because it stays concrete the entire time.

The core message is refreshingly deflating in a good way: ChatGPT, Gemini, Claude — none of it is magic, none of it is sentient. It's math, code, and a lot of data. Even the name gives it away. GPT is basically a spec sheet:

Generative — it makes new stuff on the fly instead of retrieving and ranking existing pages like a search engine.
Pre-trained — it already chewed through a mountain of internet text, books, and conversations before you typed anything.
Transformer — the architecture underneath all of it, from Google's 2017 paper "Attention Is All You Need."

From there the video walks you through the actual pipeline your sentence goes through:

Tokenization. Before a computer can do anything with your text, it needs numbers. A tokenizer chops your sentence into chunks based on a vocabulary, and the size of that vocabulary decides whether you get clean whole-word tokens or things get sliced into subwords and stray characters. Garg demos this live with Hugging Face's transformers library and Google's Gemma tokenizer, and honestly that's the moment it stops being abstract and starts being "oh, that's literally what's happening."

Vector embeddings. Once you've got tokens, each one gets mapped to a dense vector — we're talking hundreds or thousands of dimensions — that's supposed to encode meaning. The analogy that actually landed for me: think direction and distance. The path from Cat to Milk looks a lot like the path from Dog to Pedigree. Dog to Animal mirrors Man to Human. The model isn't memorizing a dictionary — it's storing relationships between concepts, and you can literally go poke at this yourself through the OpenAI embeddings API.

Positional encoding. Here's a detail a lot of people skip over: Transformers don't read left to right the way you do. Without help, "the dog chased the cat" and "the cat chased the dog" would look identical to the attention mechanism, which — yeah, that's a problem. Positional encoding bolts sine and cosine functions onto the embeddings so word order (and the meaning that comes with it) actually survives.

Self-attention and multi-head attention. This is the star of the show, and it's the actual innovation from the 2017 paper everyone name-drops. Self-attention lets every token look at every other token and update itself based on context. That's how the model knows "bank" in "river bank" has nothing to do with "bank" in "ICICI bank" — something the older RNN and CNN architectures genuinely struggled with. Multi-head attention just runs a bunch of these attention processes in parallel, so the model can track multiple relationships at once — a dog, on a train, doing something, being a specific color — all simultaneously instead of one at a time.

Feed-forward layers, then output. These attention blocks stack on top of each other, refining the representation layer by layer, until a final linear layer spits out a probability distribution over the entire vocabulary for "what token comes next." Softmax turns those raw scores into actual probabilities, and temperature decides how safe or how spicy the model gets with its pick — low temperature plays it safe, high temperature gambles on something less likely (and usually more interesting, sometimes more unhinged).

The video also draws a clean line between training (the model sees known input-output pairs, calculates loss, updates weights via backpropagation) and inference (live deployment — the model just predicts one token at a time, autoregressively, until it hits an end-of-sequence tag, with zero learning happening). Sounds obvious once you say it out loud, but it clears up a lot of confusion about what's actually happening when you're chatting with one of these things.

What makes this video worth your time isn't that any of it is secret — it's that Garg keeps everything tied to code you can actually run: AutoTokenizer, the OpenAI embeddings endpoint, a from-scratch PyTorch generation loop with AutoModelForCausalLM. You walk away with a mental model you can go verify yourself instead of just trusting some guy on YouTube (me included).

Part 2: Cool, Now How Do I Actually Build Something?

Understanding attention mechanisms doesn't teach you how to ship a product. I learned that gap the hard way trying to wire an LLM into a side project with zero idea what I was doing. This is exactly where Dev Weekends' "Level 0 and Level 1" session comes in, and it's the most immediately useful of the three if your goal is writing software instead of passing an exam.

It starts with the unglamorous stuff that actually matters: you pay for tokens, full stop, and your bill is input tokens (your prompt) plus output tokens (the response). If you've ever gotten a surprise API bill, you already know why this matters more than the fancy theory.

From there it breaks down the three roles you'll use in basically every single LLM API call:

System message — sets the model's personality and ground rules, invisible to whoever's using your app.
User message — whatever the human actually typed.
Assistant message — the model's response, generated using both of the above as context.

A few engineering patterns get covered here that I think people skip more than they should:

Streaming (stream=True) — instead of waiting for the full response, you get it chunk by chunk, which is the entire reason ChatGPT feels like it's "typing" instead of freezing and dumping a wall of text on you.
Structured output / JSON schemas — if you're plugging an LLM into a real system, you cannot have it randomly deciding to wrap its JSON in a friendly little paragraph. Define a schema up front and you kill an entire category of parsing bugs before they happen.
Tool calling / function calling — this is the mechanism that lets a model say "I don't know today's weather, but here's a function signature for a weather API, go call it and hand me the result." The model itself never executes anything — it just recognizes when it needs help and passes the ball back to your app.

On the prompting side, it runs through the standard toolbox: zero-shot (just ask), few-shot (show it examples first), chain-of-thought (make it reason step-by-step before answering), and ReAct (interleaving reasoning with actual tool calls to chew through multi-step problems). I'd read about all of these separately before, but seeing them laid out as a progression — from "just ask" to "reason and act" — made a lot more sense than any individual blog post had.

The part I found genuinely most useful, though, was the fine-tuning vs. RAG breakdown. Fine-tuning means retraining chunks of the network on your own data — expensive, heavy on compute, and static, since any new information means retraining the whole thing over again. RAG (Retrieval-Augmented Generation) sidesteps all of that by keeping the model frozen and just hooking it up to an external, updatable vector database instead.

The RAG pipeline breaks down into five steps:

Parse your source documents — PDFs, databases, scraped pages via BeautifulSoup, whatever.
Chunk the text into fixed-size pieces (think 512 tokens) with some overlap (150 tokens) so you're not losing context at the seams.
Embed and store those chunks in a vector database (ChromaDB, PgVector) along with metadata like source and timestamp.
Search — turn the user's query into an embedding and run cosine similarity to pull the top-k most relevant chunks.
Inject those chunks into the prompt so the model actually grounds its answer in your data instead of just guessing confidently.

And it doesn't stop at "ship it and pray" — it flags RAGAS as a framework for actually evaluating whether your retrieved context is faithful, your answers are relevant, and you're not quietly hallucinating despite technically having a "grounded" system. That last part is easy to forget. RAG lowers your hallucination risk. It does not erase it. Learn that the easy way, not the hard way.

Part 3: The Academic Backbone — Stanford CME295

If the first two are "how it works" and "how you build with it," Stanford's CME295 (taught by Afshine and Shervine Amidi) is the "why it works, rigorously, and where this is all headed" course. It's a full nine-lecture sequence, and it's the one I'd point to if your goal is going from "informed enthusiast" to "person who can actually reason about model design decisions in a room full of people who'd know."

The syllabus tracks a clean arc:

Transformer — core attention mechanics and encoder-decoder structure, covered with academic precision instead of intuition-first analogies.
Transformer-Based Models & Tricks — how BERT, GPT, and T5 diverge architecturally, different positional embedding schemes, and the tricks that make large-scale training actually converge instead of blowing up.
Transformers & LLMs — the jump from small task-specific models to today's massive general-purpose ones, scaling laws, and emergent capabilities that only show up once you're big enough.
LLM Training — pre-training objectives, dataset prep at scale, and the distributed-cluster/memory-efficiency tricks required to train something this large in the first place.
LLM Tuning — Supervised Fine-Tuning, Parameter-Efficient Fine-Tuning (LoRA and friends), and alignment via RLHF and Direct Preference Optimization.
LLM Reasoning — how post-training unlocks reasoning, and the increasingly hot idea of scaling test-time compute instead of just throwing more compute at training.
Agentic LLMs — designing autonomous agents: task decomposition, memory architectures, tool use, multi-agent coordination.
LLM Evaluation — systematic benchmarking, the "LLM-as-a-judge" approach, and safety/robustness red-teaming.
Recap & Current Trends — tying it all together and pointing at where frontier research is actually headed.

What this course adds that the other two structurally can't is the why. Garg's video tells you self-attention solves the context problem. Stanford's course is where you'd actually get the math behind scaled dot-product attention, the reasoning behind specific positional embedding choices, and the real tradeoffs between RLHF and DPO for alignment. It's also the only one of the three treating agentic systems and formal evaluation as first-class topics instead of an afterthought bolted on at the end — which, not coincidentally, is exactly where the field's energy is right now.

Putting It All Together

Lined up side by side, these three cover roughly the same ground a CS curriculum would, just compressed into a weekend of watching instead of a semester of tuition:

	Piyush Garg	Dev Weekends	Stanford CME295
Best for	Building intuition for the internals	Shipping real LLM-powered software	Deep theoretical and research literacy
Format	Single video, whiteboard + code	Hands-on workshop, live API/RAG demos	9-lecture university course
Core focus	Tokens → embeddings → attention → sampling	API roles, streaming, JSON schemas, tool calling, RAG vs. fine-tuning	Math foundations, scaling, alignment, reasoning, agents, evaluation
Tools shown	Hugging Face `transformers`, PyTorch, OpenAI API	OpenAI API, ChromaDB, LangChain, BeautifulSoup, RAGAS	Academic frameworks, frontier benchmarks

Honest take: none of these alone gives you the full picture, and that's fine, because they're not trying to. Garg hands you the mechanical model of how a token turns into a prediction. Dev Weekends shows you what to actually do with that model once it's sitting behind an API and your credit card is on the line. Stanford gives you the rigor to understand why the field made the choices it did, and where it's probably going next — reasoning models, agentic systems, evaluation frameworks that can actually keep pace.

If you're early in this journey, that's the order I'd go: intuition, then application, then theory. Same path I took, minus the part where I procrastinated for two weeks before starting.

Now go tokenize something.

Let's Connect

I'm Prayush Adhikari, currently grinding through the 8th semester of computer engineering and running an IT club on the side while trying to actually understand the stuff I keep building with. If you've watched any of these three (or have a better resource I'm missing), drop it in the comments — I'm always collecting more.

Which one are you starting with: the internals video, the build-something workshop, or going straight for the Stanford deep end?

LinkedIn: https://linkedin.com/in/adhikareeprayush
GitHub: https://github.com/adhikareeprayush
Portfolio: https://prayushadhikari.com.np

Tutorial Hell Is Real: I Watched 40 Hours of Videos and Built Nothing (Here's How I Escaped)

Prayush Adhikari — Sat, 26 Sep 2026 01:43:16 +0000

Hey there! Let me guess how your week went.

You watched a full-stack course. Then another one. You nodded along, pausing at the right moments, typing out everything the instructor typed. Everything worked. You felt like a genius.

Then you opened a blank file to build something on your own, and your brain went completely white.

Welcome to tutorial hell. I've lived there. I paid rent there for way too long. This post is the map I wish I'd had on the way out.

1. How to Know You're Stuck in Tutorial Hell

Be honest with yourself. Tick these off:

You've finished more courses than you've built projects
You feel like you "get it" while watching, but can't start without a video
You keep switching to a new language or framework because the old one "wasn't clicking"
Your bookmarks folder is bigger than your GitHub profile
You've said the words "I'll start my own project after this course" more than twice

If you ticked two or more, you're in. No shame in it. Almost every self-taught developer visits at some point, and plenty of CS students too, because college can be tutorial hell with a syllabus.

2. Why It Feels So Good (and Why That's the Trap)

Here's the 5-year-old version.

Watching a tutorial is like watching someone cook on TV. You see the knife skills, the perfect sear, the plating. Everything looks easy, and you feel like you learned to cook.

Then you walk into your kitchen with raw ingredients and no instructions. Suddenly you don't know how hot the pan should be, how to tell if the chicken is done, or what to do when the onions start burning.

The show never showed you that part. It showed you the finished path, with every decision already made, every wrong turn already edited out.

That's the trap. Tutorials remove the exact thing that makes you learn: the struggle of not knowing what to do next. Your brain gets the warm feeling of progress without any of the actual muscle-building.

Same as the gym. Watching someone lift doesn't make you stronger.

3. The Real Skill Nobody Teaches

Here's the thing. Programming isn't really about knowing syntax. It's about taking a vague problem and breaking it down into small steps you can actually solve.

Tutorials never teach that, because the instructor already did the breaking down before hitting record. You only ever see the solved version.

So to escape, you need to practice the part they skipped: staring at a fuzzy idea, figuring out the first tiny step, doing it, then figuring out the next one. It feels slow and uncomfortable. That discomfort is the learning. Real talk: if it feels easy, you're probably still watching.

4. My Escape Method: Watch, Rebuild, Remix

This is the system that actually works for me and for the people in our IT club. Three steps for every tutorial:

Step 1: Watch (once)

Follow the tutorial once, start to finish. Type along if it helps. This is the only time you're allowed to follow along.

Step 2: Rebuild (from memory)

Close the tab. Delete the code. Open a blank file and build the same thing again without the video.

You will get stuck. You will forget things. Good. Every time you get stuck, spend 15 minutes trying to figure it out yourself before peeking. When you peek, look at only the one piece you need, then close it again.

This step alone is worth more than five extra tutorials.

Step 3: Remix (make it yours)

Now change something the tutorial never covered. Building a weather app? Add a feature for saving favorite cities. A to-do app? Add tags or a deadline reminder. A landing page? Rebuild it for a real local business.

The remix is where you stop being a follower and become a builder. It's also the part that makes your project different from the thousands of identical tutorial clones on GitHub. Recruiters can spot those from a mile away.

5. Project Ideas That Actually Work for Beginners

Stuck on what to build? Here's a starter list. Pick something small enough to finish in a week.

A tool that solves a tiny annoying problem in your daily life
A website for a local shop, a relative's business, or your college club
A tracker for something you already track in a messy spreadsheet (expenses, workouts, study hours)
A quiz app for a subject you're studying
A bot that sends you a daily reminder or summary
A simple dashboard showing data from a free public API
A personal site that's actually deployed and live
A cleaner, better-looking version of an app you use and find ugly

Notice the pattern? They all start from a real problem you have. Motivation is way easier when you're building something you'll actually use.

6. When You Get Stuck (You Will)

Getting stuck isn't a sign you're bad at this. It's the job. Here's how I handle it now:

Read the error message. Actually read it. Most beginners skip straight to panic. The error usually tells you the file, the line, and what it expected.
Explain the problem out loud to a friend, a rubber duck, or your wall. Half the time you solve it mid-sentence.
Shrink the problem. Delete everything unrelated until you have the smallest piece that still breaks.
Search with specifics, not "my code doesn't work". Paste the exact error.
Then ask AI to guide you, not to hand you the answer. Say "give me a hint, not the solution." I wrote about this in my last post, so check it out if you missed it.

Real talk: the developers who improve fastest aren't the ones who never get stuck. They're the ones who get comfortable being stuck.

7. The Comparison Trap

One more thing, because it quietly kills more beginners than bad tutorials do.

You'll see someone your age on social media shipping a startup, landing an internship, or posting a huge project. Ignore the urge to compare. You're seeing their highlight reel next to your behind-the-scenes.

I learned the hard way that the only comparison worth making is you today versus you a month ago. Can you build something now that you couldn't then? Then you're moving.

8. A 30-Day Plan to Break Out

If you want something concrete, here's the plan I'd give to a friend:

Week 1: Rebuild
Pick one tutorial project you already finished. Rebuild it from scratch without the video. Expect to struggle.

Week 2: Remix
Add two features to that project that were never in the tutorial. Deploy it somewhere public.

Week 3: Build your own
Choose a tiny original idea from the list above. Write down the smallest working version in one sentence, then build only that.

Week 4: Polish and share
Write a proper README explaining what it does and why you built it. Put it on GitHub. Post about it, or show it to your club or a friend.

That's one shipped, original project in a month. That alone puts you ahead of most people still on their fourth course.

9. Honest Takes

Tutorials aren't evil. They're great for starting. They're terrible as a destination.
A finished ugly project beats ten perfect plans.
Copying code isn't the sin. Not understanding it is.
Consistency beats intensity. One hour a day beats one heroic weekend.
Nobody feels ready. Start anyway.

That's It. Now Go Build Something.

Close this tab. Close the course you're halfway through. Open a blank file and start something small and slightly embarrassing.

It won't feel great at first. That means it's working.

Let's Connect

If you're stuck in tutorial hell right now, drop a comment and tell me what you're trying to build. I read every one.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What project are you building to escape tutorial hell? And what should the next post be: how to build a GitHub profile that gets you noticed, or how to survive your first coding interview?

Should You Still Learn to Code in 2026? An Honest Take From a Student Who's Still Grinding

Prayush Adhikari — Thu, 24 Sep 2026 16:32:29 +0000

So you've seen the videos. "Coding is dead." "AI writes everything now." "Don't bother learning to program."

Cool. Now you're three weeks into learning Python, staring at a SyntaxError, wondering if you're wasting your time.

I get it. I'm a computer engineering student in my final semester, I run an IT club, and I get this exact question all the time: "Bro, is it even worth learning to code anymore?"

Short answer: yes. Long answer: yes, but the way you learn has to change. Let me break it down with no hype and no doom.

1. The Panic Is Real (Let's Not Pretend Otherwise)

I'm not going to tell you everything is fine. It's not all fine.

Entry-level developer job postings have dropped hard. One 2026 breakdown puts the drop in junior postings at about 67% since 2022, with actual hiring falling even more. That hurts to read when you're the one about to apply.

But here's the thing most doom videos skip. Stanford's August 2026 revision found a real employment gap for young workers in AI-exposed jobs, yet the researchers themselves call it descriptive rather than proof of cause. And the U.S. Bureau of Labor Statistics still projects growth for software developer roles over the next decade.

So what's actually happening? The jobs aren't vanishing. They're being rewritten. The old "take a ticket, write boilerplate, submit a pull request" junior role is under pressure. The new junior role is closer to "understand the problem, direct the AI, check what it gave you, and explain why it's right."

Real talk: that's a skill you can learn. But only if you learn the basics first.

2. What AI Actually Replaced

Here's the 5-year-old version.

Think of AI as a really fast intern who never sleeps, never complains, and types 100x faster than you. Sounds amazing, right?

The catch: this intern is confidently wrong once in a while, and it will never tell you when. It'll hand you something that looks perfect, runs fine on the first try, and quietly breaks three days later.

If you don't understand the work, you can't tell the difference between "correct" and "almost correct." And that gap is exactly where beginners get burned.

It's the same story as calculators. Calculators didn't kill math. They killed the arithmetic grind. People who understood math got faster. People who never learned it just got confident wrong answers, faster.

3. The Vibe Coding Trap

You've probably heard of "vibe coding": describe what you want, let AI write it, don't read the output, go with the feeling. And honestly? It's fun. It went from a joke to something a huge share of developers now use daily, and you can ship a working prototype in an afternoon.

But look at what happens when the code breaks.

I learned this the hard way. I once had an AI generate a chunk of a project that I didn't fully understand. It worked. I moved on. Then something small changed, it broke, and I had zero idea where to even start looking. I spent more time debugging code I never wrote than it would've taken to write it myself.

The data backs this up. In Anthropic's own study of around 400,000 coding sessions, sessions rated as novice reached verified success about 15% of the time, versus roughly 28 to 33% for intermediate or expert sessions. That's vendor research, so take it as a signal, not gospel. But it lines up with what I see: AI makes experts faster. It doesn't turn beginners into experts.

And ask any working developer what annoys them most about AI code. In a Stack Overflow survey, the top frustration for about two-thirds of respondents was solutions that are "almost right". Almost right is the most dangerous kind of wrong. You only catch it if you understand what right looks like.

4. What You Should Actually Learn

If you're a beginner, stop trying to learn everything. Here's the short list that actually works.

1. One language, properly

Pick Python or JavaScript. Not both. Not five. Get to the point where you can write a small program from a blank file without copy-pasting. Fundamentals beat frameworks every time.

2. Debugging

This is the new superpower. When AI gives you broken code, the person who can read an error message and trace the problem wins. Learn to use print statements, read stack traces, and Google (or ask AI) specific questions.

3. Git and GitHub

Every job expects this. Learn to commit, branch, and push. It's boring. Do it anyway. It's also your public proof that you build things.

4. Basic SQL and how data is stored

Almost every app is a fancy wrapper around a database. If you understand tables, queries, and why things get slow, you're already ahead of most beginners.

5. Reading code

Sounds weird, but most of your career is reading code someone else wrote. Now that includes code an AI wrote. Practice reading before you write.

6. Explaining what you built

Being able to say "here's the problem, here's what I built, here's why I made this choice" is worth more than a fancy tech stack. Communication is the skill nobody puts on a roadmap.

5. How to Use AI While Learning (Without Rotting Your Brain)

I'm not telling you to avoid AI. That's silly, and employers expect you to use it. I'm telling you to use it like a tutor, not a vending machine.

Here are the rules I follow and tell everyone in my club:

Try first, ask second. Spend at least 15 minutes fighting the problem yourself. The struggle is where the learning actually happens.
Never paste code you can't explain. If you can't explain a line out loud, you don't own it yet. Ask the AI to explain it like you're new, then explain it back.
Ask it to quiz you. "Give me 5 questions on this topic and don't show the answers until I try." This alone changes everything.
Break it on purpose. Take working code, change one thing, and predict what will break. If you can predict it, you understand it.
Ask "why," not just "how." The best prompt for a beginner isn't "write me a login system." It's "why do we hash passwords instead of encrypting them?"

Use AI to go deeper, not to skip the work.

6. Build Proof, Not Tutorials

Here's the honest hiring reality right now. Companies are picky. A certificate of completion won't cut it.

What works instead is two or three real projects that are actually deployed and solve a real problem. Not a to-do app copied from a tutorial. Something specific: a tool for your college, a small site for a local business, a bot that fixes an annoying thing in your daily life.

Then do the part everyone skips: write a proper README explaining what it does, why you built it, and what you'd improve. If you used AI along the way, say how and where you checked its work. That's exactly the kind of maturity hiring managers want to see.

And join something. A club, an open-source project, a Discord community. Being around people who build things keeps you honest and gets you noticed. Running our IT club taught me that most opportunities come from people who know you build stuff, not from cold applications.

7. Things I'd Tell My Younger Self

Nobody is "too late." Every generation of developers thought the field was already crowded.
Tutorial hell is real. If you've watched 40 hours and built nothing, stop watching.
The goal isn't to write code faster than AI. It's to be the person who knows whether the code is good.
Consistency beats intensity. One hour a day for six months beats a 12-hour weekend binge.
Your first projects will be ugly. Ship them anyway.

That's It. That's the Honest Take.

Coding isn't dead. The lazy version of coding is. The version where you understand what you're building, can debug when things break, and use AI as a power tool instead of a crutch? That version is more valuable than ever.

Now go close that "coding is dead" video and open your editor. Write something small. Break it. Fix it. Repeat.

Let's Connect

If this hit home, drop a comment and tell me where you're stuck right now. I read every one.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What's your biggest fear as a beginner right now: AI taking your job, or never getting your first one? Tell me, and I'll write the next post about it.

Sources for the numbers above:

How to Get Your First Developer Job in 2026 (daily.dev)
Are Vibe Coders Replacing Junior Developers? (Wavect), which covers the Stanford revision, the BLS projection, the Anthropic study, and the Stack Overflow survey

Top 10 AI Coding Tools You Need in 2026 (Or You're Basically Coding With One Hand Tied Behind Your Back)

Prayush Adhikari — Sun, 20 Sep 2026 20:02:48 +0000

So here's the thing nobody warned us about: the "AI will help you code" era quietly turned into the "AI will just... code" era, and if you blinked you probably missed it. One day you're accepting autocomplete suggestions like a normal person, the next day your terminal is opening pull requests without you. Wild times. Anyway, here's ten tools that are actually worth your time right now, ranked by "how often do I personally open this."

1. Claude Code

This one lives in your terminal and just... does things. Refactors, writes tests, reads your whole repo before making a suggestion instead of guessing from three open tabs like some tools I won't name. It feels less like autocomplete and more like handing a task to a very fast, slightly overcaffeinated junior dev who actually read the codebase first.

Check It Out

2. Cursor

Cursor took "VS Code but the AI actually understands your project" and ran with it. Multi-file edits, chat that doesn't forget what file you're in, the whole deal. If you've been Copilot-only, this is the upgrade that makes you go "oh, we're doing THIS now."

Check It Out

3. GitHub Copilot Workspace

Copilot grew up. It's not just finishing your sentences anymore — you can hand it an issue and it drafts an actual plan before touching code. Feels less like a suggestion box and more like a very eager teammate who reads tickets before Slacking you questions.

Check It Out

4. Windsurf

The agentic-editor space got crowded fast, and Windsurf earned its spot by being genuinely good at holding context across a big session without you re-explaining your entire architecture every ten minutes. Underrated for long refactor sessions.

Check It Out

5. v0 by Vercel

Describe a UI, get actual working React components back. It's the closest thing to "type a sentence, get a webpage" that doesn't look like it was built in 2013. Frontend prototyping got stupidly fast.

Check It Out

6. Qodo (formerly CodiumAI)

Test coverage is the vegetables of software development — you know you should, you usually don't. Qodo writes actually-relevant tests based on what your code does instead of generic boilerplate. Slightly less guilt at code review time.

Check It Out

7. Tabnine

For the "I like AI help but I'd also like my proprietary codebase to not leave the building" crowd. Local/private deployment options make it the pick for teams with strict data policies. Boring in the best way.

Check It Out

8. Warp

A terminal that understands natural language and has an AI baked directly in for command lookup and debugging weird shell errors. If you've ever googled "how to undo a git rebase" at 1am, this is for you.

Check It Out

9. Graphite

Code review, but the AI actually summarizes the diff for your reviewers instead of them scrolling through 40 files going "sure, looks fine, ship it." Stacked PRs plus AI summaries make review way less of a chore.

Check It Out

10. Replit Agent

Full apps from a prompt, deployed and running, no local setup required. It's the tool that makes non-devs go "wait, I could build this?" — which is either exciting or terrifying depending on your job security anxiety that day.

Check It Out

The honest takeaway: nobody's job is "type code" anymore, it's "know what to ask for and whether the answer is actually good." Worth spending a weekend poking at two or three of these instead of doomscrolling about how AI is coming for your job. Pick one, break something small in a side project, learn from it.

Security Pitfalls in React Apps I Learned the Hard Way

Prayush Adhikari — Sat, 20 Jun 2026 15:05:53 +0000

A few months back I was doing a code review for a friend's project and noticed they were storing JWTs in localStorage. I almost said nothing because honestly, I had done the same thing in like three projects before someone pointed it out to me. That's kind of the problem with frontend security. Nobody really teaches it properly, so we all just copy patterns from tutorials that were written to be quick, not safe.

So here's what I've picked up, mostly from messing things up myself or catching bugs before they became actual incidents.

XSS is more common than you think

Cross-Site Scripting is when attacker-controlled JavaScript ends up running in your user's browser. Sounds dramatic. It's also surprisingly easy to introduce by accident.

The most common way I've seen it happen in React is through dangerouslySetInnerHTML. Someone needs to render rich text from a CMS or a user comment, they google how to do it, find this prop, use it, and move on.

function Comment({ userInput }) {
  return <div dangerouslySetInnerHTML={{ __html: userInput }} />;
}

If userInput is coming from anything a user typed or any external source, this is a problem. An attacker can craft input that includes script tags and now that runs in every other user's browser that loads the comment.

The fix is pretty straightforward. React escapes content by default when you render it normally, so just do that when you can:

function Comment({ userInput }) {
  return <div>{userInput}</div>;
}

And when you genuinely need to render HTML, run it through DOMPurify first. It strips out anything dangerous before it hits the DOM.

import DOMPurify from 'dompurify';

function Comment({ userInput }) {
  const clean = DOMPurify.sanitize(userInput);
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

Not perfect, but significantly better than nothing.

CSRF is the one people forget about entirely

I genuinely forgot CSRF was a thing for a while. It doesn't come up much in React tutorials because the React part isn't really where the vulnerability lives.

The short version: if your app uses cookies for auth, an attacker can get a logged-in user to make requests to your server from a completely different site. The browser sends the cookies automatically, your server sees a valid session, and whatever that request was supposed to do just... happens.

The standard defenses are CSRF tokens (a secret value the attacker can't read from their site) and setting SameSite=Strict or SameSite=Lax on your cookies. The SameSite attribute alone cuts off most of these attacks without much extra work.

Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly

If you're using a backend framework, there's usually middleware that handles CSRF token generation and validation. Worth checking if it's actually enabled rather than assuming.

localStorage is fine until it isn't

I know the feeling. Tutorial says put the JWT in localStorage, you put it in localStorage, app works, you ship it. And most of the time nothing bad happens.

The issue is that localStorage is readable by any JavaScript running on the page. So if you ever end up with an XSS vulnerability (a bad npm package, a forgotten dangerouslySetInnerHTML, whatever) the attacker's script can just read your token straight out of storage and send it somewhere.

localStorage.setItem('token', data.token);
// readable by literally any JS on this page

HttpOnly cookies solve this because JavaScript can't read them at all. The browser sends them with requests automatically, but no script can access the value. The tradeoff is that your backend needs to set the cookie for you, which adds a bit of coordination. But if you're already building an API, it's not that much extra work.

Security headers exist and you're probably not sending them

This took me embarrassingly long to actually implement. Security headers are HTTP response headers your server sends that tell the browser how to behave. Most apps don't send them because nobody ever runs into a direct error from not having them.

Content Security Policy is the big one. It tells the browser which sources are allowed to load scripts, styles, images, etc. A solid CSP adds a meaningful second layer against XSS because even if a script gets injected, the browser may refuse to run it.

Content-Security-Policy: default-src 'self'; script-src 'self'

There's also X-Content-Type-Options: nosniff which stops browsers from sniffing content types, and X-Frame-Options: DENY which prevents your app from being iframed on other sites (relevant for clickjacking).

If you're running an Express backend, the Helmet package sets most of these in a few lines. If you're on Vercel or Netlify, you can set them in a config file. Either way it's not a big lift once you actually sit down to do it.

Accidentally shipping secret keys

This one has bitten people I know. React apps bundle environment variables into the JavaScript that ships to the browser, which means anyone can open DevTools and read them.

In Create React App, only variables prefixed with REACT_APP_ get included in the bundle. In Vite, it's VITE_. The problem is people forget this rule and prefix something they shouldn't.

# now visible to anyone who opens the network tab
REACT_APP_STRIPE_SECRET_KEY=sk_live_abc123

Secret keys belong on the server. If your frontend needs to charge a card, it should call your own API endpoint, which then calls Stripe using the secret key from a server-side environment variable. The frontend never needs to touch the key directly.

Honestly

Most of this stuff isn't complicated once you know it exists. The gap is that nobody really lays it out together in one place during the "learn React" phase, so you end up shipping apps with several of these issues without realizing it.

I'm still finding old projects of mine where I got lazy about some of this. If you're in the same boat, pick one thing from this list and fix it this week. That's usually how I approach it rather than trying to audit everything at once.

If you've hit a security bug in production or caught one before it went out, I'd genuinely like to hear what it was in the comments.

Let's Connect!

LinkedIn: adhikareeprayush
Portfolio: prayushadhikari.com.np

I Built a Free Public Random Quotes API — No Key, No Auth, Just Use It

Prayush Adhikari — Wed, 06 May 2026 16:44:54 +0000

Hey there! So you've been Googling for a free quotes API that doesn't require signing up, doesn't throttle you after 100 requests, and actually has useful filters?

Yeah, I built that. It's live, it's public, and I want you to use it.

Base URL: https://quotesapi.prayushadhikari.com.np/api

No API key. No authentication. No credit card. Just copy the URL and start fetching quotes. Let me show you everything it can do.

Why Another Quotes API?

Most random quotes APIs I found while building projects were either:

Dead (domain expired, RIP)
Rate-limited to the point of uselessness
Behind a signup wall for basic features
Returning the same 20 quotes forever

I needed something with real filtering — by author, category, text search, quote length. So I built it. And since I built it anyway, I hosted it publicly so you don't have to.

Try It Right Now

Open your browser or terminal and hit this:

curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes/random"

You'll get back:

{
  "data": [
    {
      "quote": "I feel bare. I didn't realize I wore my secrets as armor until they were gone and now everyone sees me as I really am.",
      "author": "Veronica Roth, Insurgent",
      "category": ["armor", "secrets"]
    }
  ],
  "meta": {
    "total": 499708,
    "limit": 1,
    "offset": 0,
    "order": "random",
    "returned": 1
  }
}

Notice category is an array — a single quote can belong to multiple categories. And yeah, meta.total is 499,708. Nearly half a million quotes. That's not a typo.

That's it. No setup, no tokens, no nonsense. It just works.

All Available Endpoints

Hit the discovery endpoint first — it gives you the full route map:

curl -s "https://quotesapi.prayushadhikari.com.np/api"

Here's what's available:

Endpoint	What it does
`GET /api`	Route map — your starting point
`GET /api/quotes`	Paginated quotes with all filters
`GET /api/quotes/random`	Random quote(s), default `limit=1`
`GET /api/categories`	All available categories
`GET /api/authors`	Searchable author list
`GET /api/health`	Load status + diagnostics

The Random Quotes Endpoint

The most popular use case — get a random quote:

# Single random quote (default)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes/random"

# 5 random quotes at once
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes/random?limit=5"

This is what you want for daily quote widgets, Discord bots, browser extensions, email footers — anything that needs a surprise every time.

Filters That Actually Work

This is where this free quotes API beats most alternatives. You're not stuck with just "give me random." Let me show you what's possible.

Filter by Category

# Quotes about wisdom
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?category=wisdom&limit=5"

# Multiple categories (OR — matches either)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?categories=wisdom,motivation&limit=10"

# Multiple categories (AND — must match all)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?categories=wisdom,motivation&match_categories=all"

# Exclude a category
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?exclude_category=politics&limit=10"

Filter by Author

# Partial match, case-insensitive
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?author=oscar&limit=5"

# Exact match
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?author_exact=Oscar%20Wilde"

# Exclude specific author
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?exclude_author=Napoleon&limit=10"

Full-Text Search

# Search inside quote text
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?q=journey&order=text&limit=20"

Quote Length Filters

Perfect when you have a UI constraint — like a widget that only fits a tweet-length quote:

# Short quotes only (under 100 characters)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?max_len=100&limit=5"

# Medium length range
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?min_len=80&max_len=200&limit=5"

Discover What's in the Dataset

Before you build filters, explore what categories and authors exist:

# All categories
curl -s "https://quotesapi.prayushadhikari.com.np/api/categories"

# Categories with quote counts
curl -s "https://quotesapi.prayushadhikari.com.np/api/categories?counts=true"

# Search authors by name
curl -s "https://quotesapi.prayushadhikari.com.np/api/authors?q=einstein&limit=10"

# All authors (up to 100)
curl -s "https://quotesapi.prayushadhikari.com.np/api/authors"

The counts=true on categories returns { name, count }[] which is exactly what you need to build a category picker UI.

The Seed Param — My Favorite Feature

This is the most underrated param in this random quotes API.

curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?order=random&seed=42&limit=10"

Same seed = same "random" order, every single time. Use cases:

Daily quote of the day — use today's date as the seed (seed=20250506)
Shareable quote lists — send someone a seed and they see what you see
Reproducible testing — no flaky randomness in your test suite

Pagination for the Full Dataset

Random order doesn't support offset — that's intentional. But if you switch to deterministic ordering, pagination works perfectly:

# Page 1
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?order=text&limit=20&offset=0"

# Page 2
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?order=text&limit=20&offset=20"

The meta field in every response gives you total and returned so you can compute pages on your end.

Using the API in JavaScript

This quotes API supports CORS, so you can call it directly from the browser — no backend needed.

// Fetch a single random quote
const getRandomQuote = async () => {
  const res = await fetch('https://quotesapi.prayushadhikari.com.np/api/quotes/random');
  const { data } = await res.json();
  return data[0];
};

// Fetch quotes by category
const getQuotesByCategory = async (category, limit = 5) => {
  const params = new URLSearchParams({ category, limit });
  const res = await fetch(`https://quotesapi.prayushadhikari.com.np/api/quotes?${params}`);
  const { data, meta } = await res.json();
  return { quotes: data, total: meta.total };
};

// Daily quote using date as seed
const getDailyQuote = async () => {
  const today = new Date().toISOString().slice(0, 10).replace(/-/g, '');
  const params = new URLSearchParams({ order: 'random', seed: today, limit: 1 });
  const res = await fetch(`https://quotesapi.prayushadhikari.com.np/api/quotes?${params}`);
  const { data } = await res.json();
  return data[0];
};

// Example usage
const quote = await getRandomQuote();
console.log(`"${quote.quote}" — ${quote.author}`);

Using It in Python

import requests
from datetime import date

BASE_URL = "https://quotesapi.prayushadhikari.com.np/api"

def get_random_quote(category=None, limit=1):
    params = {"limit": limit}
    if category:
        params["category"] = category

    res = requests.get(f"{BASE_URL}/quotes/random", params=params)
    data = res.json()
    return data["data"]

def get_daily_quote():
    seed = date.today().strftime("%Y%m%d")
    res = requests.get(f"{BASE_URL}/quotes", params={"order": "random", "seed": seed, "limit": 1})
    return res.json()["data"][0]

# Get a random motivation quote
quotes = get_random_quote(category="motivation")
for q in quotes:
    print(f'"{q["quote"]}" — {q["author"]}')

# Get today's quote (same every time you call it today)
daily = get_daily_quote()
print(f'Daily: "{daily["quote"]}"')

All Query Parameters at a Glance

Here's the full reference for GET /api/quotes and GET /api/quotes/random:

Parameter	Description	Example
`author`	Substring match on author name	`author=einstein`
`author_exact`	Exact author name	`author_exact=Albert%20Einstein`
`exclude_author`	Exclude this author	`exclude_author=Napoleon`
`category`	Must include this category	`category=wisdom`
`categories`	Comma-separated, OR logic	`categories=wisdom,love`
`match_categories=all`	Require ALL listed categories	`match_categories=all`
`exclude_category`	Exclude this category	`exclude_category=politics`
`q`	Substring search in quote text	`q=courage`
`min_len` / `max_len`	Quote character length range	`min_len=50&max_len=200`
`limit`	Results per page (default 10, max 100)	`limit=25`
`offset`	Pagination offset (not for random)	`offset=40`
`order`	`random`, `author`, `text`, `none`	`order=author`
`seed`	Deterministic shuffle for random	`seed=42`
`legacy=true`	Returns bare JSON array	`legacy=true`
`meta=false`	Omit meta object from response	`meta=false`

What Can You Build With This?

Here's what I'd love to see people building:

Daily quote bots for Discord, Telegram, or Slack
New tab browser extensions with category-filtered quotes
Motivational widgets on personal portfolio sites
Quote-of-the-day email newsletters using the seed param
Mobile apps that match quote moods to user input
Screensaver or wallpaper generators with random quotes
Obsidian plugins that pull quotes into your daily notes
CLI tools that show a quote on every terminal open

The API handles CORS for all GET requests, so browser-direct calls work without a proxy backend.

Troubleshooting

Getting empty data: []?

Hit the health endpoint first:

curl -s "https://quotesapi.prayushadhikari.com.np/api/health"

It'll tell you if the full dataset loaded correctly or if there's a fallback in use.

Filters returning fewer results than expected?

You might be combining too many strict filters. Try loosening them one at a time. The q text search is a substring match, so q=inspiration won't match a quote containing "inspire."

Need ALL quotes, not just 10?

Use order=text (or order=author) with offset for pagination. meta.total tells you how many exist total. Don't use order=random with offset — it won't work.

Wrapping Up

I built this free random quotes API because I was tired of hitting dead endpoints and rate limits every time I wanted to add a quote feature to a side project. Now you don't have to be.

It's free. It's public. It's not going anywhere.

Start here: https://quotesapi.prayushadhikari.com.np/api

Drop a comment with what you're building — I read every single one and it helps me figure out what to add next. Want me to cover setting up your own instance, adding new quote datasets, or building a Discord bot with this? Let me know.

I'm Prayush Adhikari, grinding through computer engineering and shipping things in public.

LinkedIn: adhikareeprayush
GitHub: adhikareeprayush
Portfolio: prayushadhikari.com.np

Now go fetch some quotes.