DEV Community: Prayush Adhikari

Building a Career Network When You Don't Know a Single Person in Tech

Prayush Adhikari — Tue, 03 Nov 2026 22:09:16 +0000

You've heard it a hundred times: "it's all about who you know." Cool. You know your classmates, your professors, and nobody who works at a tech company.

That advice is only useful if you already have the network. What nobody explains is how to build one starting from exactly zero, without feeling like a fraud sliding into strangers' inboxes.

Here's the plan I'd give a younger version of myself, back before our IT club existed and I didn't know a single working developer either.

1. Networking Is a Savings Account, Not an ATM

Most people only think about networking the week before they need a job, which is exactly why it feels awkward. That's like walking into a bank you've never opened an account with and asking for a loan.

Real networking works like a savings account. Every genuine interaction, every helpful comment, every time you show up and contribute, is a small deposit. You're not trying to withdraw anything in that moment. Months or years later, when you actually need advice, an introduction, or a referral, there's something in the account to draw from.

The people who seem to have "good luck" landing opportunities usually spent a long time quietly making deposits nobody noticed.

2. Networking Isn't What You Think It Is

Forget the image of a stiff conference room, a stack of business cards, and forced small talk. That's not what actually works for a student, and it's not what most working developers enjoy either.

Real networking looks more like:

Commenting thoughtfully on someone's post
Asking a genuine question in a community chat
Helping someone with a problem you happen to know the answer to
Sharing something you built and having a short exchange about it
Attending a meetup and talking to two people, not fifty

It's just being a real, useful, curious person in front of other people, repeatedly, over time.

3. Start With the People You Already Have

Before reaching out to strangers, look at your immediate circle. It's bigger than you think.

Classmates and club members. Some of them will land jobs before you, get internships, or start companies. Today's classmate is tomorrow's referral.
Professors and teaching assistants. They know people in industry, write recommendation letters, and remember students who actually engaged in class.
Alumni from your college. Alumni networks exist specifically because people like helping someone who studied where they did.
Anyone already in your family or neighborhood who works in tech, even loosely. A distant connection is still a connection.

Running our IT club taught me that most opportunities I've seen come from people who already knew I built things, not from a cold application into a void.

4. Find Rooms Where the Right People Already Are

You don't need to force conversations with strangers on the street. Go to spaces where the people you want to know are already hanging out.

Local meetups and tech events, in person if you can. Search for developer or startup meetups in your city.
Discord and Slack communities built around a language, framework, or local tech scene.
Open-source projects, where contributing naturally puts you in conversation with maintainers and other contributors. I wrote a whole post on making your first contribution if that's new to you.
Twitter and LinkedIn threads in your field, where replying with a genuine thought gets you noticed by people you'd never otherwise meet.
Hackathons, which pack a room full of exactly the kind of people worth knowing, compressed into a weekend.

Pick two or three of these and show up regularly. Consistency in one place beats scattering yourself thin across ten.

5. How to Actually Talk to People (Without the Cringe)

The fear here is usually "what do I even say?" Here's a shape that works almost anywhere:

Notice something specific. A project they posted, a talk they gave, a comment they made.
Say what you noticed and why it stood out.
Ask a real question, not a generic one.

Compare:

Generic: "Hey, I'd love to connect and learn from you!"

Specific: "I saw your post about migrating your app to a new framework. I'm about to do something similar for a small project. What surprised you most during that migration?"

The second one shows you actually paid attention, and it gives them something easy and specific to answer. People respond to specific far more than to generic.

6. Give Before You Ask

The fastest way to build goodwill is to be useful first, with no immediate ask attached.

Answer a question in a community you're part of
Share someone else's project or post, genuinely, not for show
Offer a small piece of help, like testing someone's app or pointing out a bug
Introduce two people you know who should know each other

None of this needs to be a grand gesture. Small, repeated helpfulness is what makes people remember you kindly, long before you ever need to ask them for anything.

7. Online Presence Is Part of Your Network Too

You don't need to meet someone in person for them to become part of your network. A consistent online presence lets people find and recognize you before you ever say a word to them.

Keep your GitHub and LinkedIn active and current
Post about what you're building, even small things
Reply thoughtfully in comment sections instead of just scrolling past

By the time you do message someone, they might already recognize your name. That completely changes how a cold message lands.

8. Asking for Help the Right Way

Eventually you will need to ask someone for something: advice, a referral, feedback on your resume. Do it well:

Be specific. "Could you review my resume?" is easier to say yes to than "Can you help me with my career?"
Make it easy to decline. "No pressure at all if you're busy" genuinely reduces the guilt of saying yes or no.
Respect their time. A 15-minute call, not an hour. A short message, not an essay.
Follow up with results. If their advice helped, tell them. It's the best thank-you there is, and it makes the next ask easier.

9. Keep Track of Your People

You'll meet more people than you can remember details about. A simple note works wonders:

Name, where you met them, what they do
What you talked about
Anything you promised to send or follow up on

Checking in occasionally, not just when you need something, is what turns a one-time interaction into an actual relationship.

10. Introverts Can Do This Too

If the idea of talking to strangers drains you, you don't need to become a different person. Networking has quieter forms that work just as well:

Writing thoughtful posts and comments instead of speaking up in every room
One-on-one coffee chats instead of big group events
Contributing to open source, where the interaction happens through code and comments
Being deeply useful to a smaller number of people instead of broadly known to many

Depth works as well as breadth. You don't need five hundred connections. You need a few dozen who actually know what you're capable of.

11. Mistakes That Undo Your Efforts

Only reaching out when you need something. People notice the pattern.
Being vague. Nobody can act on "let's connect sometime."
Ghosting after getting help. Follow up, say thanks, and close the loop.
Comparing your network to someone else's. Some people start with family connections. You're not behind, you're building from a different starting point.
Treating every interaction as transactional. Genuine curiosity about other people reads very differently from networking as a chore.

Your First Deposit

Pick one person today: a classmate doing something interesting, a maintainer of a tool you use, someone whose post caught your eye. Say something specific and genuine. No ask attached.

That's one deposit. Do it once a week, and in a year you won't be starting from zero anymore.

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 about the first person who helped your career move forward. I'd love to hear the story.

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

What should I write next: how to survive your first hackathon, or how to write a resume that gets past the filters before a human ever sees it?

How to Answer "Tell Me About Yourself" Without Freezing Up

Prayush Adhikari — Fri, 30 Oct 2026 19:15:40 +0000

Every interview opens the same way. "So, tell me about yourself." Simple words, and somehow your brain goes completely blank.

You know your own life. You've lived it. And yet the second someone asks you to summarize it out loud, on the spot, with a stranger judging your job prospects, it feels impossible to know where to even start.

Here's the good news: this question isn't testing your life story. It's testing whether you can explain yourself clearly in under a minute. That's a skill, not a personality trait, and it's one you can build in an afternoon.

1. Think in Loglines, Not Life Stories

Movie posters don't summarize the whole film. They give you a single line, called a logline, that captures the idea and makes you want to know more. "A shark terrorizes a beach town" is Jaws. Nobody expects the poster to cover the third act.

Your answer to "tell me about yourself" needs the same restraint. You're not delivering your whole biography. You're giving the interviewer a clean, compelling logline for who you are professionally, one they'll want to ask follow-up questions about.

2. What This Question Is Actually Asking

Strip away the friendly phrasing and the real question is: "Can you tell me, in a minute, who you are, what you can do, and why you're here?" Interviewers use it to:

See if you can communicate clearly under a bit of pressure
Understand your background before diving into specifics
Judge whether your interests actually line up with the role
Get a natural opening into the rest of the conversation

They're not looking for your hobbies since childhood or a full timeline of your degree. They want the shape of your professional story, in your own words.

3. The Three-Part Shape

Use this simple structure. It works for almost anyone, at almost any stage.

Present. Who you are right now, in one line. Your year, your field, your current focus.

Past. One or two things that got you here. A project, a turning point, a skill you built.

Future. Why you're excited about this specific role or company.

That's it. Present, past, future. It sounds almost too simple, which is exactly why it works: it gives your answer a beginning, a middle, and a clear direction, instead of a list of facts in random order.

4. An Example, Built Piece by Piece

Let's build one together.

Present: "I'm a final-year computer engineering student, and I lead my college's IT club."

Past: "I got interested in web development after building a small booking site for a local event, and since then I've built a few projects, including one that a small business actually uses."

Future: "I'm looking for a role where I can keep building real, used software, and this position's focus on frontend work is exactly the direction I want to grow in."

Read out loud, that's about thirty seconds. Confident, specific, and it naturally invites a follow-up question about the booking site or the club. That's exactly what you want: an answer that opens doors instead of closing the topic.

5. Keep It Under a Minute

This is the single most common mistake: rambling for three or four minutes, wandering through unrelated details, and losing the interviewer's attention halfway through.

A tight, thirty-to-sixty-second answer signals confidence. A long, unfocused one signals nerves, even if the content is fine. If you're not sure whether you're going too long, time yourself once. Most first attempts run twice as long as they should.

6. Adjust It to the Room

Your three-part answer isn't fixed in stone. Tune it to who's asking.

A recruiter or HR screen: Keep it broad. Focus on your background and general direction.
A technical interviewer: Lean slightly more into your projects and technical interests.
A founder or small team: Mention what draws you to their specific mission or product, if you genuinely know it.

Same three-part skeleton, different emphasis depending on who's in the room and what they likely care about.

7. Write It Down, Then Say It Out Loud

Reading this post won't fix the freeze-up moment. Practice will.

Write your three parts as short bullet points, not full sentences yet.
Say it out loud to yourself, then to a friend, then record yourself if you can stand it.
Time it. Trim anything that isn't pulling its weight.
Practice it in different moods, tired, rushed, a bit nervous, so it holds up when your actual interview nerves show up.

You're not memorizing a script word for word. You're building familiarity with the shape of the answer, so your brain has somewhere to go instead of freezing.

8. What to Leave Out

A few things that quietly weaken this answer:

Your entire life story from childhood onward
Personal details unrelated to the role, unless they're genuinely part of why you're here
Self-deprecating jokes about being nervous or unqualified. Confidence, not comedy, is the goal
A list of every single skill you have. Save the details for follow-up questions
Reciting your resume line by line. They already have it in front of them

9. If You Genuinely Freeze Mid-Answer

It happens, even with practice. If your mind goes blank halfway through:

Pause and breathe. A short silence feels longer to you than it does to them.
Restate where you are. "Sorry, let me pick that back up. So after that project..."
Fall back to your bullet points if you wrote them down and have them nearby, especially in a virtual interview.
Keep going. A slightly imperfect but complete answer is far better than stopping entirely.

Nobody expects a flawless delivery. They're watching whether you can recover calmly, which itself is a good signal.

10. Turning It Into a Real Conversation

A good answer doesn't just get evaluated, it moves the conversation forward. Notice what your example answer set up: mentioning the booking site invites "tell me more about that," and mentioning the IT club invites a question about leadership.

You can use this on purpose. Include one or two details you'd genuinely enjoy talking more about. You're steering the interview toward ground where you're strongest, without it feeling forced.

11. A Version for Every Situation

Since you'll answer this question many times, prepare a couple of versions:

A 30-second version for a fast screen or a casual chat
A 60-second version with a bit more detail, for a full interview
A written version for LinkedIn or a portfolio "about" section, in a slightly more casual tone

Once you've built the three-part structure, adjusting length is just a matter of trimming or expanding the middle section.

Say It Out Loud Once, Right Now

Before you close this tab, say your present, past, and future out loud, even roughly. It'll feel a little clumsy the first time. That's fine, that's what practice is for.

By the fifth time you say it, it won't feel like a script anymore. It'll just feel like you, explaining yourself clearly, which is all this question was ever asking for.

Let's Connect

Drop your thirty-second answer in the comments if you're brave enough. I'll give you honest feedback.

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

What should I write next: how to build a personal brand as a developer without feeling cringe, or how to survive group projects with a difficult teammate?

Side Project Ideas That Actually Impress Recruiters (Not Another To-Do App)

Prayush Adhikari — Tue, 27 Oct 2026 17:28:57 +0000

Be honest. How many to-do apps have you built?

I'm not judging. I've built one, and so has nearly everyone reading this. The problem is that a recruiter looking through a stack of student portfolios sees the same to-do app, weather app, and calculator dozens of times. They blur together, and none of them tell the reader anything about you.

The good news: you don't need a genius idea to stand out. You need a real problem, a finished result, and a clear story. This post covers what makes a side project impressive, a bunch of ideas you can start this week, and how to present them so people actually remember you.

1. Why Tutorial Clones Don't Land

Clones aren't bad for learning. I wrote a whole post about using them properly. But as portfolio pieces they have three weaknesses:

Everyone has them, so they don't differentiate you
You didn't make the important decisions, since the tutorial did
They don't solve a real problem, so there's nothing to talk about in an interview

A recruiter's real question isn't "can this person follow a video?" It's "can this person figure out something new and finish it?" Your projects need to answer that.

2. Think of It Like a Science Fair

Picture a school science fair. Some kids bring the classic baking-soda volcano. It erupts, everyone claps, and nobody remembers it.

Then one kid presents a project on why the water in their own neighborhood tastes different from the next street over. They asked a real question, tested it, found something, and explained what they'd do next. That's the one the judges talk about afterward.

Notice what made the second project win. It wasn't fancy equipment. It was a real question, a clear method, and honest results. Your side projects should work the same way.

3. What Makes a Project Impressive

Aim for as many of these as you can:

It solves a real problem. Ideally one you or people around you actually have.
It has real users. Even five classmates using it beats zero. It proves someone wanted it.
It's finished and live. A deployed link beats a screenshot every time.
It shows decisions. Why this database? Why this approach? What trade-offs did you make?
It's well documented. A clear README, screenshots, and a short "what I'd improve" section.
It has something of your own. A twist, a feature, or an angle that isn't in a tutorial.

You don't need all six. But a project with real users, a live link, and a solid README will beat a technically fancier one with none of that.

4. Project Ideas That Work

Here's a list grouped by what each one shows. Adapt them to your own life so they're not copies.

Solve a problem near you

Problems you can see up close are the best source of ideas, and you can find real users easily.

A college timetable and attendance tracker that reminds you of classes and calculates how many you can still miss
A club event registration and attendance system with a simple dashboard for organizers
A shared notes or past-papers site for your department
A hostel or canteen menu app that shows what's for dinner
A certificate generator that takes a list of names and produces personalized PDFs for an event (any club organizer would love this)

Work with data

An expense tracker with charts that shows where your money goes each month
A dashboard built on a free public API, like air quality, weather, or transport data for your city
A small data analysis project about something local, with your findings written up as a short blog post

Automate something boring

A script that renames, sorts, or backs up files the way you actually want
A Telegram or Discord bot for your club or study group, like a reminder bot or a quiz bot
A tool that pulls information you check every day into one place, such as deadlines, results, and announcements. If you scrape anything, respect the site's rules and terms.

Build a useful developer tool

A command-line tool that scaffolds your favorite project setup
A browser extension that fixes a small annoyance, like blocking distractions while you study
A small library or package that other people can install and use

Use AI as a real feature

AI projects are trendy, so they can help you stand out, but only if they're more than a chat box glued to an API. A few sturdier ideas:

A study helper that turns your lecture notes into quiz questions and flashcards
A job application tracker that summarizes postings and highlights skills to mention

If you do this, show your work. Explain how you handle wrong answers, cost limits, and user privacy. That's what separates a thoughtful project from a demo.

Go full stack

A booking or appointment system for a local salon, clinic, or coaching center
A simple inventory or order manager for a small shop
An app with login, a database, and deployment, even a small one, since it proves you can connect the whole chain

Contribute to open source

Fix a bug, improve the docs, or add a small feature to a real project. A merged pull request tells a recruiter you can read someone else's code and work with a team.

Do real work for a real person

A project you built for an actual client or organization, even a small one, is worth more than most personal experiments. My post on landing your first freelance client covers how to find one.

5. How to Choose Which One to Build

Run your ideas through these four questions:

Do I or someone I know have this problem? If yes, motivation and feedback come free.
Can I get a working version live in 4 to 6 weeks? If not, shrink it.
Can I find five real people to try it? Classmates, club members, or family all count.
Does it show a skill I want to be hired for? Databases, APIs, auth, deployment, testing, whatever your target roles ask for.

Pick the one that gets the most yeses. Don't wait for a perfect idea, since a good idea you finish beats a great one you never start.

6. Ship a Small Version First

The biggest project killer is scope. You imagine the full app with twenty features, build for three weeks, and abandon it.

Instead, define the smallest useful version: the single feature that makes it worth using. Build only that, put it online, and show it to real people. Then improve it based on what they actually say. Use GitHub issues to keep a short list of next steps, which also shows recruiters you plan and prioritize.

7. Present It Like a Pro

A brilliant project with a weak presentation gets ignored. Give every project:

A clear README with what it is, the problem, screenshots, how to run it, and what you'd improve. My GitHub profile post goes deeper on this.
A live demo link. Recruiters rarely clone and run your code.
A short demo GIF or video that shows it working in thirty seconds
A simple architecture diagram made in a tool like Excalidraw, showing how the pieces connect
A "decisions and trade-offs" section explaining why you chose what you chose
Real numbers if you have them, like "used by 30 students in my department." Only claim what's true, and never inflate the numbers.

Then write about it. A short blog post on how you built it, what went wrong, and what you learned doubles as content and as proof that you can communicate.

8. Using AI While You Build

Using AI tools to build is normal, and employers expect it. Just make sure you can explain every part of your project. If someone asks why a function works the way it does and you can't answer, the project hurts you more than it helps.

Be upfront in your README about where AI helped and what you reviewed or rewrote yourself. That reads as mature, not lazy.

9. Turn It Into an Interview Story

A project is only half the value. The other half is how you talk about it. Prepare a short version:

The problem: what were you trying to solve, and for whom?
The choices: what options did you consider, and why did you pick these?
The challenge: what went wrong, and how did you fix it?
The result: who used it, and what happened?
The next step: what would you improve with more time?

That five-part story answers most interview questions about your projects before they're asked. My post on your first coding interview shows how to weave it in.

10. Common Mistakes

Copying a tutorial and calling it yours. Add something original or don't list it.
Never deploying. "Works on my machine" doesn't count.
Going too big. Ambition is great, but unfinished projects tell a story too.
Hoarding tech. Using seven frameworks doesn't impress anyone. Using two well does.
Skipping the README. It's the first thing people read and often the only thing.
Leaking secrets. Never commit API keys or passwords, as I covered in my Git post.
Exaggerating. Fake numbers and inflated claims fall apart in the first interview question.

Your 30-Day Plan

Week 1: Pick one idea using the four questions. Write the smallest useful version in one sentence, and sketch the screens.
Week 2: Build the core feature. Ugly is fine.
Week 3: Deploy it, invite five real users, and collect their feedback.
Week 4: Improve based on feedback, write the README, record a short demo, and post about it.

One finished, used, documented project in a month puts you ahead of most of your batch.

Let's Connect

Tell me in the comments which idea you're picking, or share a problem you'd like to solve. I'll happily help you shape it.

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

What should I write next: how to build a career network when you don't know anyone in tech, or how to make your first open-source contribution?

Job Offer vs Starting Your Own Thing: How to Actually Decide

Prayush Adhikari — Sat, 24 Oct 2026 17:31:48 +0000

You've got an offer, or you're about to. And somewhere in the back of your mind is a nagging, quieter option: what if you just built your own thing instead?

Social media makes this decision look obvious, in whichever direction the algorithm currently favors. One month everyone's romanticizing quitting to build a startup. The next, everyone's posting about the stability of a good job. Neither extreme is actually giving you advice about your specific situation.

Let's walk through this properly, without the hustle-culture noise on either side.

1. A Job Is Renting, Your Own Thing Is Building

Here's a way to frame it that cuts through a lot of the noise.

Taking a job is like renting a house someone else built. It's move-in ready, the plumbing already works, and if something breaks, it's not entirely on you to fix. You get steady shelter without the years of construction. You don't own the walls, but you're protected from a lot of the risk that comes with building.

Starting your own thing is building your own house from the ground up. You choose every wall, every room, every decision, and eventually you own the whole structure. But you're also the one dealing with a leaky roof at 2 AM, and there's a real chance the house takes years longer than planned, or never gets finished at all.

Neither is the objectively better housing situation. It depends on how much uncertainty you can carry right now, and what you actually want to own at the end.

2. Both Choices Can Be the Smart One

Let's kill a myth on each side.

Taking the job isn't "selling out." A stable role teaches you things a beginner startup often can't: how experienced people structure real systems, how a functioning team actually communicates, and what "good" looks like at scale. Plenty of successful founders spent years as employees first, quietly learning how things actually work before building their own version.

Starting your own thing isn't automatically reckless. If you've already got early traction, some savings, or family support to fall back on, and you're clear-eyed about the odds, betting on yourself early can be exactly the right call. Some of the best-known founders started very young, precisely because they had less to lose and more time to recover if it didn't work.

The honest answer is that it depends on your specific situation, not on which path sounds more impressive to post about.

3. Questions That Actually Matter

Skip the vague "what does my gut say" question for a moment and answer these instead.

Financially: Can you cover your basic costs for six to twelve months if your own thing earns nothing in that time? Do you have savings, family support, or another income source? Being honest here isn't pessimism, it's just math you need before making the call.

On the idea: Do you have actual evidence people want this, like real users, a validated problem, or a version already gaining traction? Or is it still mostly a feeling that it could work?

On timing: Is there something specific pulling you toward the job (learning something you genuinely need, or a role that's a real opportunity) or toward your own thing (a narrowing window, a competitor moving fast, momentum you'd lose by waiting)?

On what you'd learn either way: What could a few years at this job teach you that would make your own thing stronger later? What would building your own thing right now teach you that a job never could?

On reversibility: If you take the job, can you still build your own thing on the side or return to it in a year or two? If you go all in on your own thing and it doesn't work, how easily could you get back into a job market later?

That last question matters more than people admit. A job you leave to start something is often easier to come back to than people assume. A missed early window on a genuinely time-sensitive idea might not come back at all.

4. The Middle Path Nobody Mentions Enough

This isn't always a binary choice made once, forever. A few real middle paths:

Take the job, build on the side. Slower, but with a financial floor under you the whole time. Plenty of real companies started exactly this way.
Negotiate a delayed start if you have an idea you want to test properly before committing to either path fully.
Set yourself a deadline. Give your own thing a defined window, say six months, with honest goals. If it's not working by then, take the job path without treating it as failure.
Take a shorter-term or contract role that pays the bills while leaving you real time and energy for your own project.

The all-or-nothing framing makes this decision feel scarier than it usually needs to be.

5. What "Your Own Thing" Actually Demands

Be honest about what building really requires, beyond just having an idea:

Long stretches with no clear feedback on whether it's working
Handling tasks completely outside your skill set: sales, admin, legal basics, customer support
Financial uncertainty for longer than most people expect
The discipline to keep showing up with no boss checking in on you

None of that is a reason not to do it. It's a reason to go in with open eyes instead of only the highlight reel you've seen online.

6. What a Job Actually Demands Too

The job path has its own less-discussed costs:

Less control over what you work on and how
A ceiling on how fast you can grow within someone else's structure
The comfort itself can be its own trap, since it's easy to stay somewhere just because it's stable, long after it's stopped teaching you anything

Comfort isn't automatically safety. Sometimes it's just a slower kind of drifting.

7. Talk to People Who've Actually Done Both

Before deciding, if you can, talk to a few real people:

Someone who took a job first and started their own thing later
Someone who started early and it worked
Someone who started early and it didn't, and what they did next

Notice that the third conversation is often the most useful. People who tried and it didn't work are usually far more honest about the real experience than the highlight-reel success stories you see online.

8. If You Genuinely Can't Decide

Sometimes both options look equally reasonable and you're stuck circling. A few practical tie-breakers:

Take the option that's harder to reverse later, only if you're confident about it. If one path closes doors the other doesn't, weight that carefully.
Ask what you'd genuinely regret not trying, assuming either path could realistically work out fine.
Set a real deadline for the decision itself. Endless deliberation is its own kind of cost, since both options often have their own timing pressure.

9. A Note I'm Not Qualified to Give

Money, contracts, equity, and legal terms around a job offer or a business are genuinely important, and getting them wrong can be costly. I'm not a lawyer or a financial advisor, and this post isn't a substitute for one. If real numbers or contracts are on the table, it's worth getting a second, informed opinion from someone qualified before you sign anything.

10. There's No Universally Right Answer

If you came here hoping for a formula that spits out "job" or "own thing," I don't have one, and anyone who claims they do is oversimplifying your actual situation. What I do believe: the decision matters less than most people think, and how you show up afterward matters more. Plenty of people have built great careers starting either way, and plenty have regretted rushing either choice without thinking it through.

Answer the Real Questions First

Before you decide anything, sit down and honestly answer the financial, evidence, timing, and reversibility questions from section 3. Write the actual answers down, not vague impressions.

The decision gets a lot clearer once the vague feeling turns into specific facts about your specific situation.

Let's Connect

Tell me in the comments which way you're leaning, and what's pulling you there. I won't tell you which one is right, but I'm happy to think through it with you.

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

What should I write next: how to make the most of your first internship, or how to survive group projects with a difficult teammate?

PHP2Shell: Two Critical PHP Bugs You Need to Patch Today (CVE-2026-109618 & CVE-2026-109619)

Prayush Adhikari — Thu, 22 Oct 2026 14:35:18 +0000

Hey there! If you run anything on PHP, stop scrolling and open a terminal. Seriously.

On October 21, 2026, the PHP team shipped an emergency security release for two critical bugs. Not a WordPress plugin. Not some abandoned Composer package. The PHP engine itself. And yes, that means a perfectly written app can still be exposed.

I'll break down what these bugs are, how they work (the 5-year-old version first, then the senior-dev one), how to check your servers, and how to patch without breaking things. No panic, no hype. Just the stuff that actually works.

1. The 30-second version

The bugs are tracked as CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 (CVSS v4.0), and both can lead to remote code execution by an unauthenticated attacker.

Thing	Detail
Affected	PHP 5.4 through 8.5.11
Fixed in	8.5.12, 8.4.27, 8.3.36, 8.2.35
Upstream fix for 8.1 and older	No official release (source backports exist, more on that below)
Real fix	Update PHP, then restart everything
Workarounds	Partial at best. PHP itself says updating is the only safe choice

Real talk: if you are reading this and your PHP version is below one of those numbers, you are in the "patch tonight" group.

2. The 5-year-old version

Imagine a restaurant. Every customer (request) gets a table, and a waiter sets it with plates and cutlery before the customer sits down.

Bug one (out-of-memory handling). The waiter is halfway through setting a table when the kitchen runs out of plates. Instead of finishing, he bolts out of the room. Later, the cleaner comes in, sees a half-set table, and assumes it was set properly. So he starts clearing things that were never placed. Chaos.

Bug two (stale state). When a customer leaves, the restaurant throws away their reservation slip. But the host still has a sticky note pointing at where that slip used to be. The next customer arrives, the host trusts the sticky note before checking anything, and reads whatever is sitting in that spot now.

That is basically it. One bug trusts half-built data, the other trusts a pointer to data that no longer exists.

3. The senior-dev version

Now the real names for those things.

CVE-2026-109618: RCE via out-of-memory corruption. PHP handles out-of-memory errors by exiting the current context with longjmp(). If that happens while request data is only partly initialized, PHP's request cleanup can treat the invalid data as valid. That's memory corruption an attacker can steer.

CVE-2026-109619: RCE via stale global state. PHP keeps some global state that points at memory owned by a request. After the request ends, that memory is freed, but the state survives. A later request handled by the same worker can touch that stale state before normal initialization resets it. This is a use-after-free (the advisory lists CWE-416).

Two more details that matter:

Besides code execution, an attacker may be able to read memory from the PHP worker process. That memory can hold passwords, tokens, API keys, and certificates from other requests. Reading it does not even require code execution first.
The bugs are in the runtime, so even a plain "Hello World" page on a vulnerable version can be attacked.

Here's the thing most people miss: updating WordPress or Laravel does not update PHP. PHP comes from your server package, your host, or your container image. Different layer, different update.

4. Why mod_php is the scary one

Not every setup is equally exposed. Every PHP that serves web requests is in scope (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed), but the advisory singles out Apache mod_php as the highest risk. A demonstrated exploit there needs a single unauthenticated request, and it fires before any of your application code runs.

PHP-FPM behaves differently because it shuts the worker down when a request fails early during setup. One of the two bugs was shown to reach code execution on both mod_php and FPM, though the FPM route depends on an operation inside the running app. For the other, PHP says FPM is susceptible but no complete FPM exploit has been shown.

Translation: FPM is not "safe", it's just harder. Patch both.

5. How this blew up (the messy timeline)

This one had drama, and it's a nice case study in why embargoes are fragile.

Oct 20: Details leaked ahead of a planned Oct 22 disclosure. PHP posted an advance notice and pulled the release forward a day.
Oct 21, around 03:00 UTC: Cloudflare switched on default WAF rules as a stopgap.
Oct 21, 13:34 UTC: PHP published the GitHub security advisories.
Oct 21, 14:00 UTC: Fixed versions released.
Later that day: watchTowr reported active exploitation attempts, and Cloudflare said attackers were changing payloads to dodge its rules.

As of the reporting I read, nobody had confirmed a successful break-in of a specific server. But some organizations took systems offline as a precaution, including government sites in the Netherlands and the HR platform BambooHR. That tells you how seriously people are taking it.

The bugs were found by researchers at Wiz Research, Calif, and OpenAI's Codex Security team, working with the PHP security team. They say AI models helped turn old, obscure flaws into working exploits much faster than a human team could. The affected code has been in PHP for more than a decade.

The PHP Foundation also published an honest post-mortem: signs of the out-of-memory problem were spotted during a 2024 audit, but no concrete route to code execution was found, competing fixes stalled, and they called the delay a structural failure of their process. Respect for saying that out loud.

6. Am I vulnerable? Check in two minutes

First, figure out which PHP actually serves your web traffic. The php on your command line can be a different install from the one behind your site.

# CLI version (may NOT be what your site uses)
php -v

# FPM binary (adjust the version number)
php-fpm8.3 -v

# Is Apache loading mod_php?
apachectl -M | grep -i php

# What PHP processes are actually running?
ps aux | grep -E "php-fpm|apache2|httpd" | head

Compare the version against the table in section 1. One catch: Linux distros and hosting vendors often backport fixes without changing the version number. So Debian or Ubuntu can show an "old-looking" version that is actually patched. Check the package changelog for the CVE instead of trusting the version string:

apt changelog php8.3-fpm | grep -E "CVE-2026-10961[89]"

If you're on shared hosting or cPanel, you can't run any of this. Ask your host which build you're on and whether it carries the fix. Some vendors have published backports for older branches, but you need to confirm for your plan.

7. Patch it (and actually restart)

On Debian or Ubuntu with a package-managed PHP:

sudo apt update
sudo apt upgrade
# then restart whatever serves PHP
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # or nginx, if it fronts FPM

The restart is not optional. Long-running workers keep the old code in memory until they're restarted. I know that sounds obvious, but "I patched it" and "I patched it and restarted it" are two very different sentences.

If you ship with Docker, rebuild your image from a patched base. Don't just redeploy the old one:

# Make sure the tag resolves to a patched release (8.4.27+ for 8.4)
FROM php:8.4-fpm

docker build --pull --no-cache -t myapp:patched .
docker run --rm myapp:patched php -v

Check the output says 8.4.27 or higher (or the patched equivalent for your branch). Then redeploy and confirm in production, not just on your laptop.

8. What if I really can't update yet?

Be honest with yourself here: these are band-aids. The advisory says only updating gives complete protection. But if you're waiting on a vendor, these reduce exposure to specific attack paths.

For CVE-2026-109618 (out-of-memory):

; php.ini
; Per the advisory: stop apps from overriding the limit at runtime
memory_limit = -1
post_max_size = 8M

# And cap request sizes at the web server / proxy too
client_max_body_size 8m;

Do not reach for RLIMIT_AS or RLIMIT_DATA as a substitute. PHP warns those can trigger the same vulnerable path.

For CVE-2026-109619 (stale state):

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

Then restart every worker. Turning off session upload progress blocks the confirmed session paths, not every possible variant. It was circulated as a workaround before the patch and it turned out to be incomplete. Don't let it lull you into thinking you're done.

9. After you patch

Two follow-ups most people skip.

Re-check your memory settings. The fix adds a new hard memory limit. When it's reached, the process ends and shutdown handlers don't run. So review memory_limit and post_max_size against what your app really needs, or you may trade a security bug for a surprise outage.

Look for signs you were hit before patching. The researchers suggest watching for:

unusual multipart requests followed by memory-limit errors or repeated HTTP 500s
oddly large PHPSESSID cookies in responses
PHP workers restarting for no clear reason

A rough starting point on a typical Linux box (log paths vary by setup):

# Memory-limit errors in recent logs
sudo grep -R "Allowed memory size" /var/log/ 2>/dev/null | tail -n 20

# Spike of 500s in an nginx access log
awk '$9 == 500' /var/log/nginx/access.log | wc -l

If anything looks off and you handle user data, rotate secrets (API keys, DB passwords, session secrets) after patching. Memory disclosure means those could have been exposed without any visible "hack".

10. PHP 8.1 and older: the uncomfortable part

PHP 8.1 and below have reached end of life, so there is no official patched release for them. The vulnerable range goes all the way back to 5.4, so a lot of legacy sites are sitting in it.

Your options, best to worst:

Upgrade to a supported branch (8.2 or newer). Note that 8.2 reaches end of life on December 31, 2026, so 8.3 or 8.4 is the smarter target if you can manage it.
Use a vendor backport. The PHP security team published source backports for 7.4, 8.0, and 8.1, and some distros and hosts ship their own patched builds.
Do nothing. Don't.

This is the "learn from it" moment for everyone with a client site running some PHP version nobody dares to touch. An old runtime is a debt that eventually gets called in.

11. It's not the only PHP bug this year

PHP2Shell is the loud one, but the patch notes this year have been busy. A few from the earlier releases, for context:

May 2026: a use-after-free in the SOAP extension (CVE-2026-6722) that could lead to remote code execution if you expose a vulnerable SoapServer endpoint to untrusted users, fixed in 8.2.31, 8.3.31, 8.4.21 and 8.5.6.
July 30, 2026: a PostgreSQL extension fix for SQL injection through a backslash breakout in E'...' strings (CVE-2026-17543), plus BCMath and Phar fixes.
September 2026: another high-severity SOAP issue (CVE-2026-91765), along with fixes in OpenSSL certificate verification, the HTTP stream wrapper and PHP-FPM, shipped in 8.2.34, 8.3.35, 8.4.26 and 8.5.11.

If you've been running "I'll update PHP next quarter", those are your receipts for why that plan is shaky.

12. What I'm taking away from this

Patch the runtime, not just the app. Frameworks and CMS updates don't touch the PHP underneath.
Restart after patching. Always. Verify the running version, not the installed one.
Know what's under your containers. Pin your base image tags, and rebuild on a schedule, not only when the news scares you.
Run supported versions. The upgrade you keep postponing is cheaper than the incident.
Workarounds are not fixes. Treat them as a bridge to the patch window.

That's it. That's the checklist.

Now go run php -v on every server you own. Then go restart something.

Let's Connect

I'm Prayush Adhikari, currently grinding through computer engineering and building software on the side. I write about things I run into while building, breaking, and (sometimes) fixing stuff.

If this saved you a late night, drop a comment and tell me what you're running (mod_php, FPM, Docker, shared hosting?) and whether you've patched yet. And if you've got questions, ask. I'll answer what I can.

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

Which would you rather read next: a hands-on guide to hardening PHP-FPM, or a breakdown of how use-after-free bugs actually work?

References

PHP 8.5.12 and 8.4.27 release notes: https://github.com/php/php-src/releases
GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
The Hacker News coverage: https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
Google Cloud guidance: https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619

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

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