Forem: Sahil Sahu

I Read My Code From 1 Year Ago. I'm Both Impressed and Horrified.

Sahil Sahu — Fri, 12 Dec 2025 12:38:23 +0000

Found my first "real" project while cleaning up GitHub. Decided to read through it.

Big mistake.

The Setup

One year ago, I built a full-stack blog app. My biggest project at the time. I was so proud.

Authentication system
CRUD operations
Comment section
File uploads
Deployed to production

Felt like a senior developer. Showed it to everyone.

Fast forward to today. I opened the codebase.

What I Found

The Good (Surprisingly)

I actually finished something.

Not a half-done tutorial project. Not abandoned after day 3. A complete, working application.

17-year-old me deserves credit for that.

The architecture wasn't terrible.

Separated routes, controllers, models. Not perfect, but organized. I could actually follow my own logic.

It works. Still.

Checked the live site. Still running. No major bugs. Users still posting blogs.

For a beginner project? That's impressive.

The Bad (Oh No)

Then I looked at the actual code.

// My actual code from 1 year ago
const data = await fetch(url).then(res => res.json()).then(data => data).catch(err => console.log(err))

if (data != null && data != undefined && data != '') {
  if (data.user != null) {
    if (data.user.posts != null) {
      if (data.user.posts.length > 0) {
        // actual logic finally starts here
      }
    }
  }
}

Six levels of if statements. Just to check if posts exist.

Current me would write:

const data = await fetch(url).then(res => res.json());
if (data?.user?.posts?.length > 0) {
  // logic here
}

One line. Optional chaining. Done.

The Ugly (I'm Sorry)

Variable names from hell:

const x = userData;
const xx = userData.posts;
const xxx = userData.posts[0];
const data1 = xxx;
const data2 = data1.comments;
const finalData = data2;

What was I thinking? Was I allergic to meaningful names?

Comments that lie:

// fetches all users
const posts = await getAllPosts();

No. It fetches posts. The comment is wrong. The function name is right. Why did I write that comment?

The infamous TODO:

// TODO: fix this later
// FIXME: this is temporary
// NOTE: refactor this entire file

Spoiler: I never fixed it. It's still there. Still "temporary."

Password in the code:

const DB_PASSWORD = "mypassword123";

Yes. Hardcoded. In the repo. Public repo.

I'm lucky I wasn't hacked.

What I Learned About My Growth

1. I Understand Async Now

Then:

fetch(url)
  .then(res => res.json())
  .then(data => {
    processData(data)
      .then(result => {
        saveResult(result)
          .then(() => {
            console.log('done');
          })
      })
  })

Callback hell. I didn't understand promises.

Now:

const res = await fetch(url);
const data = await res.json();
const result = await processData(data);
await saveResult(result);

Clean. Readable. Async/await saved my life.

2. I Know When NOT to Comment

Then: Comments everywhere explaining obvious things

// increment i by 1
i++;

// check if user exists
if (user) {

Now: Comments only when code isn't self-explanatory

// Retry with exponential backoff for rate limiting
await retryWithBackoff(apiCall);

3. I Understand Error Handling

Then:

try {
  // 50 lines of code
} catch (err) {
  console.log(err);
}

Catch everything. Log nothing useful. Pray it works.

Now:

try {
  await riskyOperation();
} catch (err) {
  logger.error('Failed to process user data', {
    userId,
    error: err.message,
    stack: err.stack
  });
  throw new AppError('Failed to process data', 500);
}

Specific errors. Useful context. Actual error handling.

4. I Value Readability Over Cleverness

Then: Tried to be clever

const result = users.filter(u => u.age > 18).map(u => ({...u, adult: true})).reduce((acc, u) => ({...acc, [u.id]: u}), {});

One line! So smart! Impossible to debug.

Now: Readable over clever

const adults = users.filter(user => user.age > 18);
const adultsWithFlag = adults.map(user => ({
  ...user,
  adult: true
}));
const userMap = Object.fromEntries(
  adultsWithFlag.map(user => [user.id, user])
);

More lines. Way clearer. Future me will understand this.

The Cringe Moments

My auth "security":

if (password === user.password) {
  // login success
}

Plain text passwords. In 2024. I'm embarrassed.

My "validation":

if (email.includes('@')) {
  // valid email
}

That's not validation. That's hope.

My error messages:

res.status(500).json({ error: 'Something went wrong' });

Every. Single. Error. Same message. Debugging was a nightmare.

What Stayed Good

Not everything was terrible:

✅ File structure made sense - Even now, I can navigate it easily

✅ Function names were descriptive - getUserPosts() does what it says

✅ Separated concerns - Routes, controllers, models in different files

✅ It works - Despite the mess, users can still use it

The Humbling Realization

One year ago, I thought this was amazing code.

Today, I see all the flaws. The inefficiencies. The bad practices.

One year from now, I'll probably look at my current code and cringe too.

That's not depressing. That's growth.

If you're not embarrassed by your old code, you're not learning.

What I'm Doing About It

Option 1: Rewrite Everything

"Let me fix all these issues!"

Reality: I'd spend weeks rewriting working code. Not worth it.

Option 2: Leave It Alone

"It works, don't touch it"

Reality: But it's public. It's on my portfolio. It represents me.

Option 3: Strategic Improvements (What I'm Actually Doing)

✅ Fixed the security issues (hashed passwords, env variables)

✅ Added proper error handling

✅ Improved the most painful parts

✅ Added a README explaining it's an old project

✅ Left the rest alone

It's a time capsule of my learning journey. That's okay.

The Lesson

Your old code will always look bad. That means you're growing.

Signs you're improving:

You cringe at code from 6 months ago
You spot bugs immediately in old projects
You can't believe you didn't use X pattern
You want to refactor everything (but don't)

If your year-old code still looks perfect, you haven't learned anything.

My Advice

Go Read Your Old Code

Pick a project from 6-12 months ago. Read it honestly.

You'll feel:

Proud (you built something!)
Embarrassed (what was I thinking?)
Motivated (look how much I've grown)

All three are valid.

Don't Delete It

I almost deleted this project out of embarrassment. Glad I didn't.

It shows:

Where I started
How far I've come
That I actually finish things
My learning progression

Recruiters appreciate the growth story more than perfect code.

Learn From Past You

Every cringe moment is a lesson:

Nested ifs everywhere? → Learn optional chaining
Callback hell? → Master async/await
Bad variable names? → Practice clean code
No error handling? → Learn proper patterns

Your past mistakes are your future study guide.

One Year From Now

I'll probably read THIS post and cringe at something I said.

I'll look at my current projects and see obvious flaws.

And that will be a good sign.

It means I'm still learning. Still growing. Still improving.

Your Turn

When's the last time you looked at your old code?

Go find a project from 6+ months ago. Read through it. Come back and tell me:

What made you proud?
What made you cringe?
What did you learn?

Drop it in the comments. Let's celebrate our growth (and our cringe) together.

My commitment:
Not deleting old projects. They're proof of progress, not embarrassment.

Hit ❤️ if you've ever cringed at your own code.

Stop Learning Frameworks. Seriously

Sahil Sahu — Mon, 24 Nov 2025 08:18:35 +0000

I wasted 2 years chasing the "hot new framework." Then I realized the uncomfortable truth.

The Framework Trap

My journey looked like this:

Year 1:

January: "React is the future, I need to learn it!"
March: "Wait, Vue is easier, switching to Vue"
June: "Everyone's talking about Svelte, time to learn Svelte"
September: "Angular has better structure, maybe I should..."
December: Still can't build anything complex in any of them

Year 2:

Learning Next.js, then Remix, then Astro
Rewriting the same portfolio in 6 different frameworks
Watching "X vs Y" comparison videos for hours
Arguing in Twitter comments about which framework is "best"
Still not building anything meaningful

Notice the pattern? I learned ABOUT frameworks. I didn't learn TO BUILD.

The Wake-Up Moment

A friend who learned coding in 2010 showed me his project. Built with jQuery and vanilla JS. It was:

Fast
Clean
Actually used by 10,000+ people
Making him $2k/month

My reaction: "But... that's old tech?"

His response: "Yeah, but it works and I actually finished it."

That stung.

What Nobody Tells You

Frameworks don't make you a better developer. Problem-solving does.

Here's what matters:

Can you break down complex problems?
Do you understand how data flows?
Can you debug efficiently?
Do you know when to optimize and when not to?
Can you actually ship something?

These skills transcend frameworks.

I know developers who master React but can't explain:

When to use state vs props
How async actually works
Why their app is slow
How the internet works
What happens when you type a URL

They can install packages. They can't solve problems.

The Experiment

I challenged myself: Build something complex WITHOUT any framework.

Just vanilla JavaScript. HTML. CSS.

The result?

It was HARD. Really hard.

But I learned more in 2 weeks than I did in 6 months of framework hopping:

How DOM manipulation actually works (not just setState)
Why frameworks exist (they solve real problems I was now facing)
What "reactivity" actually means (I had to build it myself)
How routing works under the hood
Real performance optimization (no framework to hide behind)

After this, going back to React felt like superpowers. I finally UNDERSTOOD what it was doing for me.

The New Approach

Now I tell beginners:

Phase 1: Build Without Frameworks (2-3 months)

Build these with vanilla JS:

Interactive quiz app
Image carousel
Form with validation
Data table with sorting/filtering
Simple SPA with routing

Yes, it's harder. That's the point.

Phase 2: Feel The Pain

You'll naturally encounter problems:

"Managing all this DOM manipulation is messy"
"Keeping UI in sync with data is annoying"
"This routing logic is getting complex"

Good. Now you understand what frameworks solve.

Phase 3: Learn ONE Framework (3-4 months)

Pick based on job market:

Most jobs? React
Want easiest? Vue
Love TypeScript? Angular

Learn it deeply. Not just the tutorial level.

Phase 4: Stop Learning Frameworks

Seriously. One is enough.

Spend your time on:

Building actual projects
Learning backend
Understanding databases
Getting good at debugging
Shipping products

The Uncomfortable Truth

The framework doesn't matter as much as you think.

React vs Vue vs Svelte? They all:

Manipulate the DOM
Manage state
Handle events
Compose components

Once you deeply understand ONE, you can learn another in 2 weeks if needed.

But here's what takes years to learn:

How to structure large applications
How to write maintainable code
How to debug production issues
How to work with APIs
How to optimize performance
How to collaborate with a team

These skills work in ANY framework.

What Changed For Me

I picked React (because job market) and went DEEP:

Read the actual docs (not just tutorials)
Built 5 complex projects (not todo apps)
Read open source React code
Understood how it works internally
Learned patterns, not just syntax

Meanwhile, I ignored:

New framework announcements
"X is dead, use Y" posts
Comparison videos
Twitter framework wars

Result? I'm actually employable now.

The Framework Paradox

Beginners think: "I need to learn all frameworks to get hired"

Reality: "Companies want someone who can solve problems, regardless of framework"

I've seen job postings say "React experience required" hire Vue developers.

Why? Because the Vue dev showed they could:

Build complex features
Write clean code
Debug effectively
Learn quickly

The specific framework was irrelevant.

My Advice If You're Starting Now

Month 1-3: Learn JavaScript deeply. Build things without frameworks.

Month 4-7: Pick ONE framework (React is safest bet). Build real projects.

Month 8+: Stop learning frameworks. Start building your career.

Focus on:

Solving real problems
Building complete projects
Understanding fundamentals
Shipping actual products

The Test

Ask yourself:

❌ "What framework should I learn next?"

✅ "What problem am I trying to solve?"

❌ "Is React better than Vue?"

✅ "Can I build this feature?"

❌ "Should I rewrite this in [new framework]?"

✅ "Does my current solution work?"

If you're still asking the first questions, you're stuck in the framework trap.

Stop Optimizing For Learning. Start Optimizing For Building.

The goal isn't to know every framework.

The goal is to build things people use.

You can do that with React. Or Vue. Or even jQuery.

Pick one. Go deep. Build stuff. Ship it.

Then, and only then, if you NEED another framework for a specific job or project, learn it in 2 weeks.

Your Turn

What framework are you "learning" right now? Be honest - are you learning to build, or learning to say you know it?

Drop a comment. Let's be real with each other.

Hit ❤️ if you needed this reality check. Hit 💀 if you're currently stuck in framework tutorial hell.

I Learned React Wrong for 3 Months. Here's What I Wish I Knew on Day 1

Sahil Sahu — Tue, 18 Nov 2025 06:23:24 +0000

I spent 3 months learning React.

Built 4 projects. Felt confident. Then got destroyed in my first code review.

"Why are you doing it like this?"

"This isn't how React works."

"Did you learn this from a 2018 tutorial?"

Turns out, I learned React completely wrong.

Here's what I wish someone told me on Day 1.

Mistake #1: I Learned Class Components First

What I did:

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  render() {
    return <div>{this.state.count}</div>;
  }
}

Why it's wrong: Class components are legacy. The industry moved to functional components in 2019.

What I should've learned:

function MyComponent() {
  const [count, setCount] = useState(0);
  return <div>{count}</div>;
}

The lesson: Don't learn outdated patterns. Check when the tutorial was made.

Mistake #2: I Used useEffect for Everything

What I did:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, [userId]);

  return <div>{user?.name}</div>;
}

Why it's problematic:

Race conditions
No loading state
No error handling
Runs on every render if dependencies are wrong

What I should've learned:

function UserProfile({ userId }) {
  const { data: user, isLoading, error } = useQuery(
    ['user', userId],
    () => fetchUser(userId)
  );

  if (isLoading) return <Spinner />;
  if (error) return <Error message={error.message} />;

  return <div>{user.name}</div>;
}

The lesson: Use proper data fetching libraries (React Query, SWR). Don't reinvent the wheel.

Mistake #3: I Put Everything in useState

What I did:

function Form() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [age, setAge] = useState('');
  const [address, setAddress] = useState('');
  // ... 10 more useState calls
}

Why it's messy: Too many state variables. Hard to manage. Causes unnecessary re-renders.

What I should've learned:

function Form() {
  const [formData, setFormData] = useReducer(
    (state, action) => ({ ...state, ...action }),
    { name: '', email: '', age: '', address: '' }
  );

  const handleChange = (e) => {
    setFormData({ [e.target.name]: e.target.value });
  };
}

The lesson: Related state should be grouped. Use useReducer for complex state.

Mistake #4: I Prop-Drilled Like Crazy

What I did:

<App>
  <Header user={user} theme={theme} />
    <Sidebar user={user} theme={theme} />
      <Content user={user} theme={theme} />
        <Footer user={user} theme={theme} />

Why it sucks: Passing props through 5 levels. Nightmare to maintain.

What I should've learned:

// Context for global state
const UserContext = createContext();

function App() {
  return (
    <UserContext.Provider value={user}>
      <Header />
      <Sidebar />
      <Content />
    </UserContext.Provider>
  );
}

function Header() {
  const user = useContext(UserContext);
  return <div>{user.name}</div>;
}

The lesson: Context API exists for a reason. Use it for global state.

Mistake #5: I Didn't Think About Performance

What I did:

function TodoList({ todos }) {
  return (
    <div>
      {todos.map(todo => (
        <TodoItem 
          key={todo.id} 
          todo={todo}
          onDelete={() => deleteTodo(todo.id)}
          onEdit={() => editTodo(todo.id)}
        />
      ))}
    </div>
  );
}

Why it's slow: Creates new functions on every render. Every todo re-renders when ANY todo changes.

What I should've learned:

const TodoItem = memo(({ todo, onDelete, onEdit }) => {
  return <div>{todo.text}</div>;
});

function TodoList({ todos }) {
  const handleDelete = useCallback((id) => {
    deleteTodo(id);
  }, []);

  return (
    <div>
      {todos.map(todo => (
        <TodoItem 
          key={todo.id} 
          todo={todo}
          onDelete={handleDelete}
        />
      ))}
    </div>
  );
}

The lesson: Use memo, useMemo, useCallback for expensive operations.

What I Wish I Learned First

If I could restart learning React today, I'd learn in this order:

Functional components + Hooks (skip class components entirely)
Proper state management (useState → useReducer → Context)
Data fetching (React Query or SWR, not raw useEffect)
Performance optimization (memo, useMemo, useCallback)
Component patterns (compound components, render props)

Resources That Actually Helped

Don't learn from:

Tutorials older than 2020
Courses teaching class components first
Random YouTube videos without dates

Learn from:

Official React docs (beta.reactjs.org)
Kent C. Dodds blog
React Query documentation
Josh Comeau's blog

The Real Lesson

You'll learn React wrong at first. Everyone does.

The key is unlearning bad patterns quickly.

Signs you learned React wrong:

Still using class components
useEffect for data fetching
Props drilling 5 levels deep
Creating functions inside render
Not using any state management library

Fix it now. Refactor one project using modern patterns.

Your future self (and code reviewers) will thank you.

What React mistake did you make? Drop it below. Let's learn together. 👇

Stop Building Todo Apps. Build These 3 Projects Instead

Sahil Sahu — Mon, 10 Nov 2025 12:56:31 +0000

I built 5 projects before getting my first interview.

The first 2 got me ghosted.

Project 3 got me noticed.

Projects 4-5 got me hired.

The difference? I stopped building what tutorials told me to build and started building what recruiters actually care about.

If you're self-taught and wondering why your portfolio isn't getting responses, here's what to build instead.

❌ Stop Building: Todo Apps, Weather Apps, Calculators

Why they don't work:

Every beginner builds them
Too simple to showcase real skills
Recruiters have seen 10,000 of them

The harsh truth: These projects say "I can follow a tutorial" not "I can solve problems."

✅ Build This Instead: Project #1 - "Clone Something Real"

What: Pick a feature from a real app and rebuild it.

Examples:

Twitter's infinite scroll feed
Spotify's search with filters
Instagram's image upload with preview
Uber's live location tracking

Why it works:

// Todo App teaches you this:
const addTodo = () => {
    todos.push(newTodo);
}

// Cloning Twitter teaches you THIS:
const fetchFeed = async (page) => {
    // Pagination
    // Infinite scroll
    // Loading states
    // Error handling
    // Rate limiting
    // Image optimization
}

What recruiters see: "This person can build features we actually need."

My example: I cloned Instagram's image upload. Learned file handling, image compression, progress bars, and preview generation. Got asked about it in 6/10 interviews.

✅ Build This Instead: Project #2 - "Solve YOUR Problem"

What: Build a tool that solves a problem YOU actually have.

Why it works: Real problems = real solutions = interesting to talk about.

Examples from my journey:

Built a browser extension that blocks YouTube recommendations (saved 2 hours/day)
Created a script that auto-applies to jobs (applied to 100 companies in 1 hour)
Made a dashboard tracking my LeetCode progress with charts

The magic question in interviews:
"Why did you build this?"

Bad answer: "I followed a tutorial"

Good answer: "I was wasting 2 hours daily on YouTube, so I built this to block distractions. Saved me 60 hours/month."

Recruiters love this because it shows initiative and problem-solving.

✅ Build This Instead: Project #3 - "Real-Time Anything"

What: Build something with live updates. Chat app, collaborative editor, live notifications, multiplayer game.

Why it works: 90% of developers avoid this because it's "hard." That's your advantage.

The tech that impresses:

// WebSockets (Socket.io)
socket.on('message', (data) => {
    // Real-time updates
});

// Or Server-Sent Events
const eventSource = new EventSource('/api/stream');

// Or WebRTC for peer-to-peer
const peerConnection = new RTCPeerConnection();

My example: Built a collaborative whiteboard. Multiple users draw simultaneously.

In interviews, I said: "I handle 50+ concurrent users with optimized socket events, batching updates to reduce server load by 95%."

Their response: "When can you start?"

The Framework: What Makes a Project "Hire-Worthy"

Every good portfolio project has these 3 things:

1. Complexity You Can Explain

Not complicated for the sake of it. But complex enough that you learned something hard.

Example: "I implemented JWT authentication with refresh tokens and role-based access control."

2. A Problem It Solves

Not "I built this to learn React."

But "I built this because finding parking near campus was impossible."

3. Live Demo + Clean Code

Deploy it (Vercel, Netlify, Railway)
Write a README explaining WHAT and WHY
Add screenshots/GIFs
Keep code clean with comments

My Actual Portfolio That Got Me Interviews

Project 1: Twitter clone (infinite scroll, image uploads)

Why: Showed I could handle complex state management

Project 2: Job application automation tool

Why: Solved my own problem, showed initiative

Project 3: Cloud Based File Management System

Why: Demonstrated advanced technical skills

Total time: 12 weeks

Interview callbacks: 12 companies

Success rate: 5x higher than my first portfolio

Your Action Plan (Start Today)

Week 1-3: Clone one feature from Twitter/Instagram/Spotify

Week 4-6: Build a tool that solves YOUR problem

Week 7-10: Build something real-time (chat, notifications, collab tool)

Then:

Deploy all 3
Write clear READMEs
Add to LinkedIn/GitHub
Start applying

The Truth Nobody Tells You

You don't need 10 projects.

You need 3 projects that show:

You can build real features ✅
You can solve problems ✅
You can handle complexity ✅

Todo apps show none of this.

Stop building what every tutorial teaches.

Start building what every company needs.

What's the most interesting problem you've faced recently? Drop it below—that's your next project. 👇

Links:

Follow me on X - click here
My Portfolio - click there

How I Went From "Hello World" at 15 to Full-Stack Developer at 18

Sahil Sahu — Thu, 06 Nov 2025 05:16:57 +0000

Three years ago, I didn't know what HTML stood for. Today, I have a portfolio with 5+ full stack projects and just landed my first freelance client.

My Portfolio - click here
Follow me on X - click here

This is everything I wish someone told me when I started.

The Beginning (Age 15)

It started with Minecraft mods. Seriously.

I wanted to create custom items for my server, found a YouTube tutorial, and copied some code I didn't understand. It didn't work. I spent 6 hours figuring out why.

When it finally worked, I felt like a wizard.

That's when I realized: I could BUILD things. Not just use apps - actually create them.

I was hooked.

Year 1: The Messy Start (Age 15-16)

What I learned: HTML, CSS, JavaScript basics

What actually happened:

I jumped around. A LOT.

Week 1: "I'll learn Python!"
Week 2: "Actually, web dev seems cool"
Week 3: "Wait, should I learn C++ for games?"
Week 4: Back to web dev

My first website was... terrible. Like, Comic Sans terrible. Centered everything terrible. But I made it myself and put it on the internet. That felt incredible.

<!-- My actual first website, no joke -->
<html>
  <body bgcolor="black">
    <center>
      <font color="lime" face="Comic Sans MS">
        <h1>Welcome to my EPIC Website!!!</h1>
        <marquee>This is so cool!!!</marquee>
      </font>
    </center>
  </body>
</html>

I thought I was a genius. Looking back... yikes.

The Turning Point

Around month 4, I built a simple to-do app following a tutorial. Then I tried to add my own feature - a dark mode toggle.

I spent 2 days on it. Stack Overflow became my second home. But when that toggle finally worked?

That's when I learned the most important lesson: You learn by breaking things and fixing them.

Following tutorials is fine for learning syntax. But real learning happens when you go off-script.

Year 2: Getting Serious (Age 16-17)

What I learned: React, Node.js, MongoDB, Git

This was the "grind" year. I was that kid coding during lunch break. My friends thought I was weird. My parents worried I was on my computer too much.

But I was building real stuff:

Project 1: Study Timer App

Built with vanilla JS (before I knew React)
Pomodoro technique timer
Saved data to localStorage
Looked ugly but WORKED

What I learned: DOM manipulation, local storage, JavaScript events

Project 2: Weather App

My first API integration
Used OpenWeather API
Learned about async/await the hard way (callback hell nightmares)
Actually looked decent with CSS Grid

What I learned: APIs, async JavaScript, responsive design

Project 3: Movie Database

First React project
TMDB API integration
Search, filter, favorites
Deployed on Netlify

What I learned: React basics, state management, component lifecycle

Project 4: Chat App

First full-stack project
Node.js + Express backend
Socket.io for real-time chat
MongoDB for storing messages
Completely broke in production multiple times

What I learned: Backend, databases, deployment, that production is DIFFERENT from localhost

The Struggles Nobody Talks About

Imposter Syndrome Hit HARD

Every YouTube tutorial made it look easy. Every dev on Twitter seemed to know everything. I felt stupid constantly.

I'd see 12-year-olds building AI apps and think "I'm already behind."

Reality check: Those kids probably followed a tutorial too. Everyone's faking it a bit.

Tutorial Hell Was Real

For 3 months, I just followed tutorials. Built the same to-do app 15 different ways. Never built anything original.

Breaking free was hard. I had to force myself: "Build something without a tutorial."

It was messy. It took forever. But that's when I actually learned.

Burnout at 16

Around month 14, I hit a wall. Coded for 8 hours, made zero progress, felt like I'd never be good enough.

I took a week off. Just played games, hung out with friends. Came back refreshed.

Lesson: Breaks aren't weakness. They're necessary.

Year 3: Portfolio & Real Projects (Age 17-18)

What I learned: Next.js, TypeScript, PostgreSQL, Tailwind, Docker

This year was about leveling up. Making things that actually looked professional.

The Portfolio

I rebuilt my portfolio 4 times. Each time I learned something new and thought "I need to redo everything."

Version 4 finally felt right:

Next.js for performance
Tailwind for styling (game changer)
Framer Motion for animations
Dark mode (obviously)
Actually mobile responsive (shocking, I know)

Real Projects I'm Proud Of

*1. FileFlow *

User Authentication with Email Verification
Secure File Uploading and Storage
Preview and Download Files
Delete and Manage Uploaded Files
Responsive and User-Friendly Interface
JWT-based Authentication & Authorization
Drag-and-Drop File Upload
Cloud Storage Integration with File Validation

2. JobTube

User & Employer Authentication (JWT)
Role-based Dashboards (Job Seeker & Employer)
Job Listings with Search & Filter Functionality
Application Submission & Tracking
Admin Panel to Manage Users, Jobs & Applications
Responsive & Accessible UI (Tailwind CSS)
Backend API with Secure CRUD Operations

*3. Framely *

User Authentication with JWT and secure cookies
Full Profile Customization (profile picture, bio, website)
Follow/Unfollow user system
Post Creation with image uploads to Cloudinary
Interactive Posts with likes, comments, and post deletion
Ephemeral Stories that automatically expire after 24 hours
Real-Time Notifications for likes, comments, and follows using Socket.IO
Real-Time Direct Messaging (Chat) between users
Dynamic Explore Page to discover popular content
Saved Posts feature for bookmarking content
User Search functionality to find and connect with others
Responsive and Intuitive UI with skeleton loaders for a smooth experience

4. Growth AI

AI-Powered Conversational Interface
Real-time Response Rendering
Multiple Chat Sessions
Clean and Modern UI
Responsive Design for All Devices
Secure API Integration
Persistent Chat History (Local Storage or DB)

What Actually Helped Me Learn

1. Build Projects, Not Just Follow Tutorials

After basics, I learned by building. Every new concept = new project.

Want to learn React? Build something in React. Not another todo app. Something YOU want to use.

2. Document Everything

I kept a dev journal. Every time I solved a hard problem, I wrote it down.

Now when I hit the same problem, I have my own notes. Way better than googling the same thing 50 times.

3. Read Other People's Code

GitHub is free education. Find projects similar to what you're building, read the code.

I learned more from reading Next.js source code than any tutorial taught me.

4. Don't Learn Everything At Once

I wasted months trying to learn:

Frontend frameworks
Backend
DevOps
Databases
All at the same time

Learn ONE thing deeply, then add layers.

My path: HTML/CSS → JavaScript → React → Backend → Databases

5. Deploy Your Projects

Code on localhost isn't real. Deploy it.

Netlify, Vercel, Railway - they're free. Deploy everything.

You'll learn about environment variables, CORS, HTTPS, and all the stuff tutorials skip.

6. Join Communities

Discord servers, Reddit, dev.to - other developers are helpful.

I was scared to ask "dumb questions" for so long. Turns out, everyone has the same questions.

The Tech Stack I Use Now

Frontend:

React / Next.js (for everything)
Tailwind CSS (never going back to vanilla CSS)
TypeScript (game changer for big projects)

Backend:

Node.js + Express (simple, works)
MongoDB (when I need a database)
Firebase (for quick projects)

Tools:

VS Code + extensions
Git + GitHub
Figma (for designs)
Postman (for API testing)

Deployment:

Vercel (frontend)
Railway / Render (backend)
Cloudinary (images)

What I Wish I Knew at 15

You don't need a $3000 course

I learned everything from:

YouTube (Traversy Media, Web Dev Simplified, Fireship)
freeCodeCamp
docs
Building stuff and googling errors

You don't need a perfect portfolio

My first portfolio had 3 projects. That's enough. Just make sure they WORK and the code is on GitHub.

Age doesn't matter

I'm 18. Some people start at 30. Some at 50. Doesn't matter. Just start.

Consistency beats intensity

1 hour every day > 10 hours once a week

I coded daily, even if just for 30 minutes. That adds up.

Your first projects will suck

That's normal. Make them anyway. You can't get better without making bad stuff first.

Where I Am Now

12 projects in my portfolio
First freelance client ($200)
Starting to apply for junior dev positions
Still learning every day
Still googling "how to center a div" sometimes

I'm not a senior developer. I'm not a genius. I'm just someone who started at 15 and didn't quit.

If You're Just Starting

Start today. Not tomorrow. Today.

Pick ONE thing to learn (I'd say HTML/CSS). Follow ONE tutorial. Build ONE thing.

Then build another. Then another.

In 3 years, you'll look back and be amazed at how far you've come.

You don't need:

Perfect conditions
Expensive courses
A CS degree
To be a "natural"

You just need:

A laptop
Internet
Consistency
Patience with yourself

What's Next For Me

Keep building projects
Learn more about system design
Contribute to open source
Maybe start a YouTube channel?
Get my first dev job

I'm 18. I have so much to learn. But I'm not waiting until I "know enough."

I'm building, shipping, and learning as I go.

Your Turn

If you're learning to code right now - what's holding you back from building something?

If you already learned - what do you wish you knew when you started?

Drop it in the comments. Let's help each other out.

My learning resources (all free):

freeCodeCamp
JavaScript.info
React docs
YouTube (Traversy, WebDevSimplified, Fireship)
MDN Web Docs
Stack Overflow (obviously)

Follow my journey:
My PortFolio - click here
Follow me on X - click here

If this helped you, hit that ❤️. If you're learning too, drop your GitHub - I'll check out your projects!

webdev #beginners #javascript #react #coding #100daysofcode

I Stopped Writing Tests and My Code Got Better

Sahil Sahu — Tue, 04 Nov 2025 07:42:05 +0000

Yeah, I said it. Come at me.

Before you start typing that angry comment, hear me out. I'm not saying "don't test." I'm saying I stopped writing tests the way everyone tells you to.

The Problem Nobody Talks About

For years, I followed the gospel: Write tests first. Test everything. 100% coverage. TDD or bust.

My codebase had 3,247 tests. Coverage was 94%. CI took 23 minutes to run. I felt like a responsible adult developer.

Then I shipped a bug that wiped out $12k worth of data.

The tests? All green. ✅

What Actually Happened

The bug was simple: An edge case in our payment processing where users could submit the same transaction twice within 50ms. Race condition. Classic.

Why didn't the tests catch it? Because I tested what I thought about, not what actually breaks.

Our test suite was massive, but it was testing:

Happy paths (90% of tests)
Edge cases I imagined (9% of tests)
Whatever got me to 94% coverage (1% of tests)

Zero tests for the actual user behavior that broke things.

The Uncomfortable Truth

Most tests are just checking if functions return what you told them to return. That's not testing, that's just... writing the same logic twice.

// My old tests looked like this
describe('calculateTotal', () => {
  it('should add tax to subtotal', () => {
    expect(calculateTotal(100, 0.1)).toBe(110);
  });
});

// Cool story. But did I test:
// - What if subtotal is negative?
// - What if tax is a string "10%"?
// - What if this runs 1000 times per second?
// - What if the user's locale formats numbers differently?

What I Do Now Instead

1. I Write Fewer, Better Tests

Instead of 3,247 tests, I have about 400. But these 400 tests are mean.

// New style: Test like users actually break things
describe('Payment processing under stress', () => {
  it('handles rapid duplicate submissions', async () => {
    const userId = 'test-user';
    const paymentData = { amount: 100, card: '4242...' };

    // Fire 10 identical requests simultaneously
    const promises = Array(10).fill(null).map(() => 
      processPayment(userId, paymentData)
    );

    const results = await Promise.all(promises);
    const successful = results.filter(r => r.success);

    // Only ONE should succeed
    expect(successful.length).toBe(1);
  });
});

2. I Test Integration, Not Units

Unit tests are overrated. There, I said it again.

Your calculateTax() function works fine in isolation. But does it work when:

The database returns null
The API times out
The user's session expires mid-request
Redis goes down

That's what breaks in production. Not your pure functions.

3. I Use Property-Based Testing

This changed everything.

import fc from 'fast-check';

// Instead of testing specific cases, test properties
test('user input never causes crashes', () => {
  fc.assert(
    fc.property(
      fc.string(), // any string
      fc.integer(), // any integer
      fc.object(), // any object
      (name, age, metadata) => {
        // This should NEVER throw, no matter what garbage we pass
        expect(() => {
          createUser(name, age, metadata);
        }).not.toThrow();
      }
    )
  );
});

This generates thousands of random test cases. It found 7 bugs in my code that I would NEVER have thought to test.

4. I Test in Production

Controversial? Maybe. Effective? Absolutely.

// Feature flags + monitoring = production tests
if (featureFlags.newPaymentFlow) {
  try {
    result = await newPaymentProcessor.process(payment);
    metrics.increment('new_payment_flow.success');
  } catch (error) {
    metrics.increment('new_payment_flow.error');
    logger.error('New payment flow failed', { error, payment });

    // Fallback to old flow
    result = await oldPaymentProcessor.process(payment);
  }
}

I know in real-time if something's broken. My test environment never caught the issues that production monitoring does.

The Results

6 months after this switch:

Tests run in 4 minutes instead of 23
Found 3x more bugs before users did
Deployments went from scary to boring (in a good way)
Onboarding new devs is faster - they understand 400 good tests way easier than 3k mediocre ones

What I'm NOT Saying

I'm not saying "don't test." I'm saying:

❌ Stop writing tests just to hit coverage numbers

❌ Stop testing only happy paths

❌ Stop writing tests that just repeat your implementation

✅ Start testing like users actually use (and break) your app

✅ Start testing the integration points where things actually fail

✅ Start monitoring production like it's part of your test suite

The Backlash I'm Ready For

"But TDD!"

TDD is great for well-defined problems. But most of our work isn't well-defined. Requirements change. You'll rewrite those tests 5 times.

"But code coverage!"

Coverage tells you what you executed, not what you tested. 100% coverage with bad tests is worse than 60% coverage with good tests.

"But best practices!"

Best practices from 2010 don't apply to 2025 codebases. We have better tools now. Use them.

Try This Instead

For your next feature:

Write ONE integration test that exercises the whole flow
Add property-based tests for any user input
Test the failure modes (timeouts, null responses, etc.)
Add monitoring to catch what you missed
Ship it

You'll find more bugs, write less code, and ship faster.

Your Turn

Am I completely wrong? Probably partially. Tell me why in the comments.

Already doing something like this? Share your approach. Let's learn from each other.

Still writing unit tests for getters and setters? I'm sorry for your loss.

Tools I Actually Use:

fast-check - Property-based testing for JS/TS
Playwright - Integration testing that doesn't suck
Datadog/New Relic/etc - Production monitoring
Feature flags (LaunchDarkly, Unleash, or roll your own)

Hit that ❤️ if this made you question your test suite. Drop a 💀 if you think I'm about to get fired.

testing #controversial #webdev #javascript #devops

I Broke My Code 17 Times in One Day — Here’s What I Learned

Sahil Sahu — Fri, 31 Oct 2025 08:28:05 +0000

Let’s be honest — we’ve all been there.

You install a new tool, follow every tutorial step by step… and still get an error that makes zero sense.

For me, it was Docker.

I was excited to containerize my first app. I wrote my Dockerfile, typed docker build ., and BAM —

ERROR: error during connect: Head "http://%2F%2F.%2Fpipe%2FdockerDesktopLinuxEngine/_ping": The system cannot find the file specified.

I stared at it for 10 minutes straight.

But that one frustrating day taught me lessons every developer should know — especially if you’re just getting started with modern tools like Docker, Git, or any CLI-based tech.

1. Don’t just copy-paste commands — understand them

Tutorials are great, but they often skip why you’re running each command.

When I typed docker build, I didn’t even know that it connects to a background process called the Docker daemon.
Once I realized that, the error message finally made sense — my Docker daemon wasn’t running.

Lesson: Every command has a purpose. Before running it, ask yourself — what does this actually do?

2. 90% of bugs aren’t code — they’re setup issues

You can write perfect code and still get errors because of missing installations, environment variables, or wrong versions.

Instead of blaming yourself, blame your environment first.

Now, whenever something breaks, I run through a checklist:

Is my service running?
Is the path or environment variable correct?
Did I open the correct terminal (Windows CMD vs WSL vs Linux shell)?

This mindset alone saves hours.

3. Read error messages like clues

Errors are not enemies — they’re breadcrumbs.

That terrifying long red text in your terminal? It’s actually your best friend.
It’s trying to tell you exactly where things went wrong.

When I learned to slow down and read every line of an error, I started solving issues faster — even ones I’d never seen before.

4. Document your pain — someone else needs it

Every time I fix a weird bug, I write it down.
Not only does it help me later, but it also turns into a blog post like this.

If you share your learnings, you help others skip the same pain — and that’s how you grow your dev audience.

5. The “Error → Curiosity → Understanding” loop

That day I broke my code 17 times was exhausting. But each fix gave me a deeper understanding of how Docker works.
And that’s the secret to becoming a better developer — not avoiding errors, but learning through them.

💬 Final Thought

Every developer has a “nothing works” day.
But those days shape you far more than the ones where everything runs smoothly.

So next time you hit a scary error, don’t quit — debug it, document it, and share it.
You never know whose life (or terminal) you might make easier.

If you enjoyed this post, give it a ❤️ and follow me — I’ll be sharing more real-world dev lessons and debugging stories every week.

Let’s grow together, one error at a time.