Introduction

I'm currently building my first fullstack web application — a digital agency website with a complete blog management system. On Day 13 of the build, I ran into one of those errors that stops everything and sends you deep into Stack Overflow. This is the story of that error, why it happened, and how I fixed it.

What I Was Building

I needed a rich text editor for an admin blog dashboard. The requirements were simple:

• Bold, italic, headings

• Bullet lists and numbered lists

• Code blocks

• Image support

React-Quill seemed like the obvious choice. It's popular, well-documented, and has thousands of GitHub stars. So I installed it:

npm install react-quill@2.0.0 quill@1.3.7 --legacy-peer-deps

Everything looked fine. Then I opened the page.

The Error

Uncaught TypeError: react_dom_1.default.findDOMNode is not a function
    at ReactQuill2.getEditingArea (react-quill.js:13139:45)
    at ReactQuill2.instantiateEditor (react-quill.js:13028:50)
    at ReactQuill2.componentDidMount (react-quill.js:12998:16)

The editor crashed immediately on mount. The page was blank. Nothing worked.

Why This Happens

The key is in the error: findDOMNode is not a function.

findDOMNode was a React DOM method that allowed class components to access their underlying DOM node. React deprecated it years ago and finally removed it completely in React 19.

React-Quill 2.0.0 internally uses class components and calls findDOMNode to locate its editor container. Since React 19 no longer has this method, the editor crashes the moment it tries to mount.

You can verify your React version by checking package.json:

"react": "^19.2.0"

If you are on React 19, React-Quill will not work. There is no workaround — the issue is inside React-Quill's source code itself.

What I Tried First That Didn't Work

I tried wrapping the editor in an error boundary. The editor still crashed before rendering.

I tried lazy loading it with dynamic imports. Same result — the crash happens inside componentDidMount, not during import.

I tried downgrading React-Quill versions. None of the published versions support React 19.

The conclusion was clear: React-Quill needed to be replaced entirely.

The Solution: TipTap

TipTap is a modern headless rich text editor built specifically for React. It uses hooks instead of class components, which means it has zero compatibility issues with React 19.

Install it like this:

npm install @tiptap/react @tiptap/pm @tiptap/starter-kit @tiptap/extension-image @tiptap/extension-link @tiptap/extension-placeholder --legacy-peer-deps

Setting Up TipTap in React 19

Here is a minimal working example:

import { useEditor, EditorContent } from '@tiptap/react';
import StarterKit from '@tiptap/starter-kit';

const Editor = () => {
  const editor = useEditor({
    extensions: [StarterKit],
    content: '<p>Start writing here...</p>',
    editorProps: {
      attributes: {
        class: 'focus:outline-none min-h-64 px-4 py-3',
      },
    },
  });

  // Get HTML content for saving
  const handleSave = () => {
    const html = editor.getHTML();
    console.log(html); // Send this to your API
  };

  return (
    <div>
      <EditorContent editor={editor} />
      <button onClick={handleSave}>Save</button>
    </div>
  );
};

export default Editor;

Two things to note:

• useEditor() initializes the editor instance

• EditorContent renders it into the DOM

• editor.getHTML() gives you the content as an HTML string ready to save to your database

Building a Custom Toolbar

TipTap is headless — it has no built-in toolbar UI. You build your own, which actually gives you full control. Here is how I built mine:

const ToolbarButton = ({ onClick, active, children }) => (
  <button
    type="button"
    onClick={onClick}
    className={`px-2 py-1 rounded text-sm font-medium ${
      active ? 'bg-blue-100 text-blue-700' : 'text-gray-600 hover:bg-gray-100'
    }`}>
    {children}
  </button>
);

// Inside your component:
<div className="flex gap-1 p-2 border-b">
  <ToolbarButton
    onClick={() => editor.chain().focus().toggleBold().run()}
    active={editor.isActive('bold')}>
    <strong>B</strong>
  </ToolbarButton>

  <ToolbarButton
    onClick={() => editor.chain().focus().toggleItalic().run()}
    active={editor.isActive('italic')}>
    <em>I</em>
  </ToolbarButton>

  <ToolbarButton
    onClick={() => editor.chain().focus().toggleBulletList().run()}
    active={editor.isActive('bulletList')}>
    • List
  </ToolbarButton>

  <ToolbarButton
    onClick={() => editor.chain().focus().toggleHeading({ level: 2 }).run()}
    active={editor.isActive('heading', { level: 2 })}>
    H2
  </ToolbarButton>
</div>

The chain().focus().toggleBold().run() pattern is TipTap's command API. It chains actions together and executes them on the editor.

One Gotcha: Loading Existing Content

If you are building an edit form where you need to load existing content into the editor, there is a timing issue to be aware of. The editor initializes asynchronously, and your API data also loads asynchronously. If you call editor.commands.setContent() before the editor is ready, nothing happens.

The fix is to use a separate state variable and a useEffect that watches both:

const [postContent, setPostContent] = useState('');

const editor = useEditor({
  extensions: [StarterKit],
  content: '',
});

// Sync content to editor only when BOTH are ready
useEffect(() => {
  if (editor && postContent) {
    editor.commands.setContent(postContent);
  }
}, [editor, postContent]);

// When your API data loads:
const fetchPost = async () => {
  const response = await axios.get(`/api/blog/post/${id}`);
  setPostContent(response.data.content); // This triggers the useEffect
};

This pattern ensures content is set safely regardless of which loads first.

Add List Styles to CSS

TipTap renders lists correctly in the DOM but you need to add CSS to make them visible. Add this to your global stylesheet:

.tiptap ul {
  list-style-type: disc;
  padding-left: 1.5rem;
  margin: 0.5rem 0;
}

.tiptap ol {
  list-style-type: decimal;
  padding-left: 1.5rem;
  margin: 0.5rem 0;
}

.tiptap h2 {
  font-size: 1.5rem;
  font-weight: bold;
  margin: 0.75rem 0;
}

.tiptap blockquote {
  border-left: 4px solid #009ad9;
  padding-left: 1rem;
  color: #6b7280;
}

Without this, bullet points and headings will render invisibly.

Key Takeaway

Before installing any npm package, check whether it supports your React version. React 19 is still new and many popular packages have not updated yet.

If you see findDOMNode is not a function in your console, the package you are using relies on a removed React API. The fix is to find a modern alternative — not to downgrade React.

TipTap is that alternative for rich text editing. It is actively maintained, React 19 ready, and honestly more flexible than React-Quill anyway.

What I'm Building

This editor is part of a 30-day fullstack project I am documenting publicly. I am building a complete digital agency website with React, Node.js, PostgreSQL and Cloudinary. Follow along if you want to see the full build!

How We Fixed a react-helmet-async Crash That Gave Us Zero Clues

If you have been building React apps for a while, you know the feeling. You write your code, save the file, check the browser, and instead of seeing your beautiful page — you get a white screen and a red error in the console that makes absolutely no sense.

That is exactly what happened to us on Day 12 of building the Sticobytes website. We had just finished the Blog listing page. Everything looked good. The code was clean. And then this showed up in the browser console:

Uncaught TypeError: Cannot read properties of undefined (reading 'add')
    at HelmetDispatcher.init (react-helmet-async.js:812:21)
    at HelmetDispatcher.render (react-helmet-async.js:816:10)

White screen. Blog page gone. No helpful hints.

If you have never seen this error before, welcome to the club. Let us break it down together — what caused it, why the error message is so misleading, and most importantly, what the fix is and why it works.

First, What Is react-helmet-async?

Before we talk about the error, let us quickly understand what react-helmet-async is and why we were using it.

When you visit a website, each page usually has a unique title in the browser tab — something like "Blog | Sticobytes Digital Agency". Each page also has hidden tags in the HTML <head> section called meta tags. These tags tell Google, Facebook, Twitter, and other platforms what the page is about. They look like this in your HTML:

<head>
  <title>Blog | Sticobytes Digital Agency</title>
  <meta name="description" content="Explore our latest tutorials and insights." />
  <meta property="og:title" content="Blog | Sticobytes Digital Agency" />
</head>

In a normal HTML website, you just type those tags directly into your HTML file. But React apps work differently. React controls the entire page through JavaScript — there is only one HTML file (index.html) and React swaps the content dynamically as you navigate between pages.

So how do you change the page title and meta tags when the user moves from the Home page to the Blog page to a single Blog Post? That is exactly what react-helmet-async solves. It lets you set those <head> tags from inside your React components like this:

import { Helmet } from 'react-helmet-async';

const Blog = () => {
  return (
    <>
      <Helmet>
        <title>Blog | Sticobytes Digital Agency</title>
        <meta name="description" content="Explore our latest tutorials." />
      </Helmet>

      {/* rest of your page */}
    </>
  );
};

Clean, simple, and it works on every page. This is important for SEO — search engines like Google read those meta tags to understand and rank your pages.

We added <Helmet> to our Blog page. Saved the file. And that is when the white screen appeared.

The Error — And Why It Is So Misleading

Let us look at the error again:

Uncaught TypeError: Cannot read properties of undefined (reading 'add')
    at HelmetDispatcher.init

Read that error message carefully. What does it tell you?

• Something is undefined

• It tried to read a property called 'add' from that undefined thing

• It happened inside HelmetDispatcher.init

What does it NOT tell you?

• What is undefined

• Why it is undefined

• What you need to do to fix it

This is the kind of error that sends new developers to Google for an hour. Because nothing in the message says "hey, you forgot to add HelmetProvider". It just says something is undefined somewhere deep inside the library code.

Here is what is actually happening under the hood.

What React Context Is (In Plain English)

To understand the real cause of this error, you need to understand a concept called React Context.

Imagine you are in a large office building. The building has a central electricity supply room in the basement. Every floor, every room, every socket in that building gets its power from that central room. You do not need to run individual wires from the power station outside directly to every single desk. The building's infrastructure handles it.

React Context works the same way. Some libraries need a central "supply room" set up at the top of your app. Once that central room exists, every component anywhere in your app can tap into it — no matter how deeply nested it is.

For react-helmet-async, that central supply room is called HelmetProvider.

When you use <Helmet> inside your Blog component, it does not work on its own. It tries to communicate with HelmetProvider — to say "hey, update the page title and meta tags to these values". If HelmetProvider does not exist, there is nothing to communicate with. The connection is undefined. And that is exactly what the error is telling us, just in a very unhelpful way.

The Fix

The fix is simple once you know what is missing. Open your main.jsx file — this is the entry point of your React app, the very top of your component tree.

Before (broken):

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import App from './App.jsx'

createRoot(document.getElementById('root')).render(
  <StrictMode>
    <App />
  </StrictMode>,
)

After (fixed):

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import { HelmetProvider } from 'react-helmet-async'
import './index.css'
import App from './App.jsx'

createRoot(document.getElementById('root')).render(
  <StrictMode>
    <HelmetProvider>
      <App />
    </HelmetProvider>
  </StrictMode>,
)

Two changes:

1. Import HelmetProvider from react-helmet-async

2. Wrap <App /> with <HelmetProvider>

Save the file. Refresh the browser. White screen gone. Blog page working perfectly.

Why This Fix Works Everywhere, Forever

Here is the beautiful part about this fix. You do it once and it works for every single page in your app — now and in the future.

Because HelmetProvider wraps <App />, which contains your entire application, every component anywhere in your app can now use <Helmet> without any issues. Your Home page, Blog page, Services page, individual Blog Post pages, Contact page — all of them can set their own unique titles and meta tags, and they all tap into that one HelmetProvider you set up in main.jsx.

The Bigger Lesson — The Provider Pattern

This is not just a react-helmet-async thing. This is a pattern you will see over and over again in React development. It is called the Provider Pattern.

Many popular React libraries work this way:

The rule is simple: if a library exports both a Provider and a component that uses it, the Provider must be an ancestor of all components that use it — and usually that means putting it in main.jsx at the very top.

When you see a cryptic error from a library you just installed, one of the first questions to ask yourself is: "Does this library need a Provider that I forgot to add?"

How to Spot This Pattern in Future

When you install a new React library, do this one thing before writing any code — read the "Getting Started" or "Installation" section of the documentation and look for any mention of a Provider or a wrapper component.

If you see something like:

// Wrap your app with this
<SomeProvider>
  <App />
</SomeProvider>

Go straight to main.jsx and add it there. Do not add it to individual pages. Add it once at the root. That is the correct way.

Quick Summary

Here is everything we covered, in one place:

• What happened: We added <Helmet> to our Blog page for SEO meta tags but got a white screen with a confusing error

• Why it happened: react-helmet-async requires a HelmetProvider at the root of the app. Without it, <Helmet> has nothing to connect to and crashes

• Why the error is confusing: The error message talks about undefined and 'add' — nothing about a missing Provider

• The fix: Import HelmetProvider and wrap <App /> with it in main.jsx

• The bigger lesson: This is the Provider Pattern — many React libraries need a root-level Provider. Always check the docs for this when installing something new

Final Thought

The most valuable bugs are the ones that teach you something that applies far beyond the original problem. This one taught us about React Context, the Provider Pattern, and how to read cryptic library errors.

Next time you see an error that seems to come from deep inside a library with no clear explanation — take a breath, check if a Provider is missing, and remember this post.

Happy building. 🚀

Written by Chinedu Obia, Co-Founder of Sticobytes — sharing real bugs from real projects so you learn faster than we did.

Follow the Sticobytes 30-day build journey at blog.sticobytes.com

I've seen a pattern emerge: a student receives a coding challenge, opens ChatGPT, pastes in the requirements, and within seconds has a complete, working solution. Project submitted. Green checkmark earned. Next module unlocked.

But here's what happens next: that same person struggles to explain their own code during code reviews. They can't debug when something breaks. The project that took five minutes to "complete" taught them absolutely nothing.

This is the uncomfortable reality of learning web development in 2025, and we need to talk about it.

The Elephant in the Room

Let me be clear: I love AI. I use it. It's an incredible tool that's transforming how we work. But there's something deeply concerning happening in the developer learning space right now. New developers are using AI not as a learning aid, but as a replacement for learning itself.

I've observed this pattern across various learning communities:

• Students copying entire code blocks from ChatGPT without reading them

• Learners using AI to complete assessments and challenges

• People celebrating projects they built but can't explain

• Developers with impressive portfolios who struggle to code basic functionality from scratch

The code runs. The project deploys. The portfolio looks great. But when it's time to debug, modify, or build something new without AI, the foundation crumbles.

Yes, AI Is Powerful (And That's Exactly the Problem)

Here's what makes this tricky: the people defending AI-heavy learning aren't entirely wrong. They'll tell you:

"AI is the future of development. Why wouldn't you use the best tools available?"

"Senior developers use Stack Overflow and copy-paste code all the time. What's the difference?"

"You don't need to memorize syntax anymore. Just understand concepts."

These arguments sound reasonable on the surface. AI is transforming software development. Professionals do use AI tools in production. But there's a crucial difference between a senior developer using AI to accelerate their workflow and a beginner using it to avoid developing fundamental skills.

A senior developer using GitHub Copilot understands why the suggested code works. They can evaluate it, modify it, and debug it when it breaks. A beginner copying from ChatGPT is building on quicksand.

The Real Cost of the AI Shortcut

When you use AI to solve problems you haven't yet learned to solve yourself, you're not just missing out on syntax knowledge. You're losing something far more valuable:

Problem-solving skills. The mental muscle you build when you're stuck, frustrated, and forced to think through a problem is irreplaceable. That struggle is where real learning happens.

Pattern recognition. When you write code yourself (even badly), you start recognizing patterns. You see how HTML structures relate to CSS selectors. You understand why JavaScript functions are organized a certain way. AI-generated code robs you of this intuition.

Debugging ability. If you didn't write the code and don't understand how it works, how will you fix it when it breaks? And trust me, it will break.

Confidence. There's a unique confidence that comes from solving a hard problem yourself. When you rely on AI for everything, you develop a dependency that makes you doubt your own abilities.

I've experienced this firsthand. There have been moments when I was tempted to ask ChatGPT to "just fix this CSS issue" or "write this JavaScript function for me." And sometimes I did. Every time I took that shortcut, I regretted it later when I encountered the same problem again and still didn't know how to solve it.

My Framework: When to Use AI (and When to Struggle)

After three years of coding and observing different approaches to learning, I've developed some personal rules for using AI as a developer still building their foundation. These aren't universal laws, just guidelines that have worked well for me and others I've mentored:

Use AI When:

1. You're stuck after genuine effort. My rule: try to solve the problem myself for at least 30-45 minutes before turning to AI. This ensures I've actually wrestled with the problem.

2. You need concept explanations. AI is brilliant at breaking down complex concepts into simple terms. Asking "Can you explain what closures are in JavaScript?" is productive learning. Asking "Write me a function that uses closures" is not.

3. You want to understand existing code. Pasting code and asking "What does this do line by line?" can be enlightening, especially when reading documentation or open-source projects.

4. You're learning best practices. Questions like "What's the most accessible way to structure this form?" or "How can I make this code more performant?" help you level up.

5. You need a starting point for research. Using AI to generate a list of topics to study or resources to explore is smart learning strategy.

Don't Use AI When:

1. It's an assignment, test, or exercise designed to teach you something. If the point is to learn, and you skip the learning, you've defeated the entire purpose.

2. You haven't tried the problem at all. The first attempt should always be yours, no matter how messy or broken.

3. You're building your portfolio projects. These projects should showcase your abilities. If you can't rebuild them from scratch without AI, they're not really your abilities.

4. You don't understand the code it generates. If AI gives you code you can't explain, don't use it. Take time to understand it first, or ask AI to explain it and then rewrite it yourself.

5. You're trying to "get through" material quickly. Speed means nothing if you haven't learned anything.

The Balance: AI as a Mentor, Not a Crutch

The key is treating AI like you would a senior developer mentor. A good mentor doesn't do your work for you. They guide you, explain concepts, point you in the right direction, and help when you're genuinely stuck. They don't hand you solutions without teaching you the principles behind them.

Here's how I use AI productively:

Instead of: "Write me a responsive navigation bar"
I ask: "What are the key CSS properties I need to understand to make a navigation bar responsive?"

Instead of: "Fix this code [paste entire project]"
I ask: "I'm getting this error message. What does it mean and what should I investigate?"

Instead of: "Create a to-do list app in JavaScript"
I ask: "What are the main concepts I need to understand to build a to-do list app? What should I learn first?"

This approach means I'm learning with AI rather than learning from AI. There's a massive difference.

A Challenge for Fellow Developers Still Learning

If you're reading this and recognize yourself in the "ChatGPT copy-paste" description, I'm not judging you. I've been tempted too. The pressure to keep up, to have impressive projects, to feel like you're progressing quickly can be overwhelming.

But I want to challenge you: try building something from scratch this week without AI. It can be small—a simple landing page, a basic calculator, whatever. Just you, your code editor, and documentation.

Yes, it will be frustrating. Yes, it will take longer. Yes, your code might be messier than what ChatGPT would generate.

But you'll learn more from that one project than from ten AI-generated ones. And when you finally get it working, you'll have earned something real: the knowledge that you can actually do this.

The Bottom Line

Is web development worth learning in 2025 with AI everywhere? Absolutely. But only if you're actually learning it.

AI isn't going away. It's going to become even more powerful and integrated into development workflows. But the developers who thrive won't be the ones who learned to prompt AI well. They'll be the ones who learned to code well and then learned to use AI to amplify their skills.

Build your foundation first. Let AI be the tool that makes you faster and more productive, not the crutch that prevents you from learning to walk.

Your future self, sitting in that technical interview or debugging that production bug at 2 AM, will thank you.

What's your take on using AI as a beginner developer? Have you found a balance that works for you? Drop your thoughts in the comments. I'm genuinely curious how other learners are navigating this.

If you're reading this, chances are you've just been introduced to CSS, and your brain might feel like it's about to explode. Flexbox? Grid? Position absolute? Z-index? Box model? Media queries?

I get it. I've been there.

When I first started learning CSS as a self-taught developer, I made the classic beginner mistake: I tried to memorize everything. Every property, every value, every syntax rule. I'd spend hours trying to cram flexbox properties, thinking "if I just memorize justify-content and align-items, I'll be fine."

Spoiler alert: I wasn't fine.

The truth hit me hard when I sat down to build my first real project. I stared at my blank HTML file, knowing all these CSS "concepts" but having absolutely no idea where to start. That's when I realized something crucial about coding.

Now I'm in a bootcamp, and I see beginners making the same mistake I did—trying to memorize everything instead of understanding how to actually solve problems.

Coding Isn't About Memorization

Here's what nobody tells you when you start learning web development:

Coding is not about cramming syntax. It never was, and it never will be.

Even senior developers with 10+ years of experience Google basic CSS syntax. I've watched my instructor pull up MDN documentation for the hundredth time to check a flexbox property. And you know what? That's completely normal.

Think about it this way:

Would you rather be someone who:

• Can recite 50 CSS properties from memory but doesn't know when to use them?

Or someone who:

• Understands how CSS works, knows where to find information when stuck, and can actually build things?

The answer is obvious.

The Real Skills You Need to Develop

After months of self-learning and now being in a bootcamp, here's what I've learned about what actually matters:

1. Problem-Solving Over Syntax

Good programmers don't memorize code. They understand problems and figure out solutions. When you face a layout challenge, the question isn't "What's the exact syntax for flexbox?" It's "What problem am I trying to solve, and which CSS tool can help me?"

2. Reading Documentation is a Superpower

One of the most valuable skills you can develop is learning how to read documentation. MDN, CSS-Tricks, W3Schools—these aren't "cheat sheets" for beginners. They're professional tools that EVERYONE uses, from juniors to seniors.

Being able to:

• Search for what you need

• Understand technical documentation

• Apply examples to your own code

...is literally 50% of the job.

I learned this the hard way during my self-taught journey. Now in my bootcamp, I see other beginners struggling with the same thing—thinking they need to memorize everything before they can build anything.

3. The Internet is Your Co-Pilot

"But isn't Googling things cheating?"

Absolutely not.

Professional developers Google things constantly. The difference between a beginner and an experienced developer isn't that one Googles less—it's that the experienced developer knows:

• What to search for

• How to evaluate answers

• How to adapt solutions to their specific problem

4. Understanding Beats Memorizing Every Single Time

Instead of memorizing that display: flex makes a container a flexbox, understand WHY you'd use flexbox. Instead of cramming grid properties, understand WHEN grid is better than flexbox.

When you understand the "why" and "how," the syntax becomes easy to look up.

My Journey: From Self-Taught to Building Real Projects

Let me share something real with you. I started learning web development on my own, and recently, during my bootcamp, I built my first complete multi-page portfolio website using HTML and CSS.

🔗 View Live Portfolio | GitHub Repository

Three pages: Home, About, and Contact. Fully responsive. Professional design. Smooth animations. The whole package.

Here's the kicker: I didn't know half of what I needed before I started.

How I Actually Built It

I didn't memorize CSS before building. Instead, I:

1. Broke down the problem: "I need a navigation bar that stays at the top when scrolling."

2. Researched the solution: Googled "CSS sticky navigation" and found position: sticky

3. Understood the concept: Read about how sticky positioning works, when it applies, and its limitations

4. Applied it to my code: Implemented it, tested it, broke it, fixed it

5. Moved to the next problem: "How do I make these cards display in a grid?"

I repeated this process dozens of times. Each time, I wasn't memorizing—I was understanding.

The Problems I Solved

Throughout this project, I faced real challenges:

• Making the hero section look good on mobile - Researched media queries and flexbox wrapping

• Creating a responsive grid that adapts to screen size - Learned about repeat(auto-fit, minmax())

• Styling form inputs to look professional - Discovered :focus pseudo-class and input styling techniques

• Making navigation highlight the current page - Used the .active class strategically

For EVERY single one of these challenges, I:

• Identified the problem

• Searched for solutions

• Read documentation

• Experimented with code

• Broke things

• Fixed things

• Learned

That's real coding.

What Beginners Should Actually Focus On

If you're just starting with CSS and feeling overwhelmed, here's my advice:

1. Build Projects, Not Just Study

Stop reading about CSS and start using CSS. Build things—even if they're ugly at first. Every problem you solve is worth more than hours of reading tutorials.

2. Get Comfortable Being Uncomfortable

Not knowing something doesn't mean you're bad at this. It means you're learning. Every developer you admire was once exactly where you are, staring at their screen thinking "What does z-index even do?"

3. Develop Your Research Skills

Practice searching for solutions. Learn to:

• Ask better questions ("How to center a div in CSS" vs "CSS not working")

• Read documentation without panicking

• Test code examples

• Adapt solutions to your needs

4. Understand Concepts, Not Just Syntax

When learning something new in CSS, ask yourself:

• What problem does this solve?

• When would I use this?

• What are the alternatives?

• How does it actually work?

Understanding these answers means you can always look up the syntax later.

5. Embrace the Struggle

Spending 30 minutes figuring out why your flexbox isn't working isn't wasted time. That's learning. That frustration you feel when things don't work? That's your brain rewiring itself to think like a developer.

The Truth About Learning to Code

Here's what I wish someone had told me when I started:

You're not supposed to know everything.

You're not supposed to memorize everything.

You ARE supposed to get stuck.

You ARE supposed to Google things.

You ARE supposed to check documentation.

The goal isn't to become a walking CSS reference manual. The goal is to become someone who can:

• Identify problems

• Find solutions

• Implement them effectively

• Learn from the process

My Portfolio: Proof That This Works

My portfolio website isn't perfect. But it's real, it works, and I built it by doing exactly what I'm telling you:

• Understanding concepts over memorizing syntax

• Researching when stuck

• Breaking problems into smaller pieces

• Learning by doing

🔗 Check it out here: Live Demo | GitHub Repository

The code is all there. You'll see:

• HTML structure using semantic tags

• CSS with flexbox and grid

• Responsive design with media queries

• Animations and transitions

• Form styling

• And a lot of problem-solving

To Everyone Feeling Lost

If you're learning on your own or in a bootcamp right now, staring at CSS and wondering if you'll ever "get it"—you will.

If you're trying to memorize every CSS property—stop. You're wasting your energy. (Trust me, I wasted months doing this)

If you feel like you should know more than you do—you're exactly where you should be.

The developers you look up to? They Google things daily. They check documentation constantly. They get stuck and have to figure things out. The difference is they're comfortable with that process.

Start Today

Don't wait until you've "learned enough CSS." Pick a project—any project—and start building. Get stuck. Google things. Read documentation. Try things. Break things. Fix things.

That's how you actually learn to code.

My portfolio took me several days of doing exactly this. Yours will too. And that's not just okay—that's perfect.

Summary: The Real Path to Learning CSS

Let me leave you with this:

Coding is not about cramming. It's about:

• Understanding how things work

• Knowing where to find information

• Problem-solving step by step

• Building real projects

• Learning from mistakes

• Researching when stuck

The internet is always here. Documentation isn't going anywhere. What matters is that you understand the concepts and know how to find what you need when you need it.

Stop trying to memorize everything. Start trying to understand anything.

Build something today. Get stuck. Figure it out. Repeat.

That's how real developers are made.

Resources That Actually Help

Here are the resources I used while building my portfolio:

• MDN Web Docs - The CSS documentation bible

• CSS-Tricks - Practical examples and explanations

• Stack Overflow - Real problems, real solutions

• Google - Your best friend, seriously

Connect With Me

I'm on the same journey as you—learning, building, and sharing. Let's connect and learn together!

Portfolio: https://chinaydu01.github.io/my-portfolio/
GitHub: https://github.com/chinaydu01

Drop a comment below if you're also learning CSS. What's the biggest concept you're struggling with right now? Let's figure it out together!

Happy coding, and remember: Google is not cheating. It's how professionals work. 🚀

P.S. - If this helped you, share it with someone else who's feeling overwhelmed by CSS. We all need this reminder sometimes.

Following up on my Week 1 bootcamp post, I mentioned we'd be spending more time with HTML before diving into CSS. Well, I took that to heart and built not one, but two complete projects to really solidify what I've been learning.

Why I Built Two Projects Instead of One

Here's the truth—understanding syntax and being able to build something functional are two very different things. You might watch a tutorial on HTML forms and think "I got this," but until you actually build a form from scratch, troubleshoot validation issues, and structure it properly, you don't really know it.

So instead of just completing the bootcamp assignment and moving on, I challenged myself to build two different projects that would force me to:

• Practice the same concepts in different contexts

• Solve problems independently

• Build muscle memory for HTML structure

• Learn by doing, not just by reading

Project 1: Comprehensive Registration Form

🔗 View Live Project | GitHub Repository

This project is a deep dive into HTML forms—and I mean comprehensive. It features:

• All major HTML5 input types (text, email, password, date, radio, checkbox, file, range, color, and more)

• 8 organized sections with logical grouping

• Built-in HTML5 validation techniques

• Accessibility best practices (proper labels, fieldsets, ARIA attributes)

• Real-world form structure you'd actually use

What I learned:

• How different input types behave and when to use each one

• The importance of client-side validation for user experience

• Proper form accessibility isn't optional—it's essential

• How to structure complex forms so they're easy to navigate

Project 2: Multi-Page Recipe Website

🔗 View Live Project | GitHub Repository

This one was all about understanding how multi-page websites work and how to maintain consistency across pages. The site includes:

• Home page - Landing page with recipe highlights

• Recipe detail page - Step-by-step instructions with ingredients

• Nutrition table - Structured data using HTML tables

• Recipe submission form - User interaction and data collection

• About page - Information about the site

What I learned:

• How to structure navigation across multiple pages

• Maintaining consistent headers and footers

• Organizing a larger project with multiple HTML files

• Using semantic HTML to create meaningful page structure

• Working with tables for actual tabular data (nutrition facts)

• Creating intuitive user flows between pages

The Real Lesson: Practice Over Perfection

Both projects are built with just HTML—no CSS, no JavaScript. And honestly? They look pretty basic. But that's not the point.

The point is that I can now:

• Structure a complex form without looking up syntax every 5 minutes

• Navigate between pages confidently

• Write semantic HTML without overthinking it

• Understand accessibility from the ground up

• Organize multi-file projects logically

This is what "building coding muscles" means. It's not about making something pretty right away—it's about repetition, making mistakes, fixing them, and doing it all over again until the patterns stick.

My Advice to Fellow Beginners

If you're just starting out or going through a bootcamp, here's what I'd tell you:

1. Don't just take notes and move on Notes are helpful for reference, but they won't make you a developer. You need to write code—lots of it.

2. Build the same thing multiple times Your first attempt will be messy. Your second will be better. By the third, you'll start seeing patterns and best practices naturally.

3. Practice concepts in different contexts Building a form once? That's learning. Building forms for a registration page, contact page, and survey? That's mastery.

4. Embrace the ugliness Your HTML-only projects won't look impressive, and that's okay. You're learning structure first. The styling comes later.

5. Push to GitHub Even if you think your code is "not good enough," push it anyway. Your GitHub is a journal of your progress, not a portfolio of perfection.

What's Actually Next

Now that I've really solidified my HTML fundamentals through these projects, I'm genuinely ready for CSS. Not because the bootcamp says it's time, but because I've built enough HTML structure to appreciate what CSS will do for it.

Next up: We're diving into CSS to bring these bare-bones HTML projects to life. I'll be styling the recipe website first and documenting the process.

The bio page from Week 1? The registration form? The recipe site? They're all about to get a complete visual makeover. Stay tuned.

Are you in a bootcamp or learning to code? What's your approach—build everything or move fast through tutorials? Drop a comment and let's discuss!

Projects:

• Registration Form - Live Demo | GitHub

• Recipe Website - Live Demo | GitHub

  This is part of my ongoing bootcamp journey series. Read Week 1: Revisiting HTML Fundamentals

In my last post, I shared why I decided to join this bootcamp despite teaching myself to code. Now, let me walk you through what we've been building and the fresh perspectives I've gained in our first week.

What We Covered

Our first week focused on HTML5 fundamentals, including:

• HTML document structure and boilerplate

• Semantic HTML elements (header, main, section, footer)

• Working with forms and input types

• Creating accessible tables

• Image optimization with alt text

• Best practices for accessibility

Even though I'd worked with HTML before, revisiting these topics in a structured way helped me identify gaps in my knowledge and solidify best practices I'd been fuzzy on.

The Project: Personal Bio Page

Our hands-on project was building a personal bio page using pure HTML5—no CSS, no JavaScript, just semantic markup.

🔗 View Live Project | GitHub Repository

The page includes:

• Personal profile section with image

• About me biography

• Hobbies and interests lists

• Skills showcase (ordered list)

• Weekly schedule table

• Contact form with various input types

Check out the live demo and feel free to explore the code on GitHub to see how everything comes together!

Key Concepts I Reinforced

Semantic HTML Structure

One thing the bootcamp emphasized is using semantic HTML for better accessibility and SEO. Instead of divs everywhere, we structured the page meaningfully using elements like <header>, <main>, <section>, and <footer>. This structure tells browsers and screen readers exactly what each part of the page represents—making it more accessible for everyone.

Building Accessible Forms

Forms were a big focus this week. The key learning here: every input needs a properly associated label for accessibility. Using the for attribute on labels that connects to the input's id helps screen readers and improves usability for all users. We also learned about fieldsets and legends to group related form elements logically.

Tables for Structured Data

We used tables to display a weekly schedule, and I learned the importance of using tables only for tabular data, not layout. Using proper table elements like <thead>, <tbody>, <th>, and <td> adds semantic meaning and significantly improves accessibility.

Images and Alt Text

Every image needs descriptive alt text—not just for accessibility but also for SEO and scenarios where images fail to load. This was something I knew but didn't always practice consistently.

Self-Taught vs. Bootcamp: My Observations

Learning HTML in a bootcamp versus on my own has revealed some interesting differences:

Structure matters: Having a curriculum removes the "what should I learn next?" paralysis I often faced when self-teaching.

Filling knowledge gaps: I realized I'd been skipping over important concepts like proper form accessibility and semantic HTML. Self-teaching sometimes means you learn what you need in the moment, not necessarily what you should know.

Community learning: Seeing how my peers approach problems differently has been invaluable. There's always more than one way to solve something, and bootcamp discussions expose you to different thinking patterns.

Accountability: Having deadlines and projects due keeps me consistent. When self-teaching, it's easy to say "I'll do it tomorrow."

What's Next

Before we dive into CSS, we'll be spending more time with HTML. Next week, we're building a complete multi-page website using just HTML—no styling yet. This will help solidify our understanding of HTML structure, navigation between pages, and how to organize a larger project.

I'm excited to work on something more complex and see how all the pieces fit together. Once we've mastered HTML structure with a multi-page site, then we'll move into CSS to bring everything to life with styling and responsive design.

Stay tuned for the next update!

Following along on my bootcamp journey? Drop a comment below with your own experiences—whether you're self-taught, in a bootcamp, or considering one. Let's learn together!

Project Repository: GitHub
Live Demo: View Project

But here's the thing: I didn't start here. For months now, I've been teaching myself web development. I've built projects, watched countless tutorials, read documentation until my eyes glazed over, and coded through frustration and breakthroughs alike. I did it all on my own terms, at my own pace.

So why would someone who's already learned so much on their own choose to enter a structured bootcamp? And more importantly—if you're trying to decide between self-teaching and joining a bootcamp, what should you actually consider?

I've spent time on both sides of this debate (well, one side fully, and about to dive into the other). Here's what I wish someone had told me before I started this journey.

The Self-Taught Journey: What Actually Worked

Let me be clear: self-teaching isn't just viable—it's powerful. Some of the best developers I know never set foot in a classroom or bootcamp. They learned by doing, by breaking things, by Googling error messages at 2 AM.

Here's what made my self-taught journey valuable:

Freedom to Explore

When you're teaching yourself, you get to follow your curiosity. If something interests you—whether it's CSS animations, responsive design, or a new JavaScript framework—you can dive right in. No syllabus holding you back, no waiting for week 6 to learn the cool stuff. You set the pace, you choose the projects, you decide what matters.

I spent weeks just playing with Bootstrap, building page after page until responsive design became second nature. Nobody told me to do that—I just wanted to master it. That kind of self-directed learning builds genuine passion.

Building Real Discipline

Here's something people don't talk about enough: when you're self-taught, showing up is entirely on you. No teacher taking attendance. No classmates to keep you accountable. Just you, your laptop, and your commitment.

Every single line of code I wrote as a self-taught developer came from internal motivation. That's a superpower. It means I *chose* this path—it wasn't assigned to me. When the bootcamp gets tough (and I know it will), I'll have that foundation of self-discipline to fall back on.

Learning to Learn

Self-teaching forced me to develop one of the most critical skills in tech: learning how to learn. I became comfortable with being uncomfortable. I learned to read documentation, interpret error messages, and ask the right questions on Stack Overflow.

When you don't have a teacher to explain things, you get resourceful fast. You learn that "I don't know" isn't a dead end—it's the beginning of figuring it out.

Cost-Effective

Let's be real: not everyone has thousands of dollars to spend on education. Self-teaching gave me access to world-class resources for free—freeCodeCamp, YouTube, MDN documentation, countless blogs and tutorials. I built real skills without going into debt.

For where I was at the time, free resources were exactly what I needed to get started.

The Struggles: What Self-Teaching Couldn't Give Me

But if self-teaching was so great, why am I here? Why am I about to spend two months in an intensive bootcamp?

Because as powerful as self-teaching is, it has real limitations—and I hit most of them.

Lack of Structure (aka Tutorial Hell)

You know that feeling when you finish a tutorial and think, "Okay, cool… now what?" That was my life for months. I'd learn one thing, jump to another topic that seemed interesting, then circle back to something I'd have-learned before.

There was no clear path. No "here's what you need to master before moving to the next level." Just an overwhelming sea of content and no map to navigate it. I learned a lot of things *partially*, but never went deep enough to feel truly confident.

I was stuck in what people call "tutorial hell"—endlessly consuming content without building real mastery.

Imposter Syndrome Hit Different

When you're self-taught, there's no external validation. No grades, no certificates (well, not meaningful ones), no teacher saying, "Yes, you've got this." Just you and your nagging doubt: *Am I actually good enough? Am I learning the right things? Would a real developer laugh at my code?

I'd look at job descriptions asking for "proficiency in backend development" and think, "I've used Node.js a few times… does that count?" Spoiler: it didn't. I had surface-level knowledge, and I knew it.

Knowledge Gaps I Didn't Know I Had

Here's the dangerous part about self-teaching: you don't know what you don't know. I could build a decent frontend, sure. But did I understand how databases actually work? Could I set up a proper API? Did I know best practices for security, or deployment, or version control workflows?

Not really. I knew *how* to do some things, but I didn't understand the why behind them. I was copying patterns without understanding the principles.

And because I didn't know these gaps existed, I didn't know to fill them.

Isolation Was Real

Coding alone is… lonely. There's no one to celebrate with when something finally works. No one to commiserate with when you've been debugging the same issue for three hours. No one to review your code and say, "Hey, here's a better way to do this."

You miss out on the kind of learning that happens when two developers look at the same problem and approach it differently. You miss the "aha!" moments that come from explaining your code to someone else.

I didn't realize how much I needed a community until I didn't have one.

Decision Fatigue Is Exhausting

Should I learn React or Vue? Should I focus on frontend or dive into backend? Which course is actually good? Which tutorial isn't outdated? Do I need to learn TypeScript right now, or can I wait?

When every decision is yours alone, decision-making becomes exhausting. I spent more time *deciding what to learn* than actually learning. Analysis paralysis is real, and it stole weeks of progress from me.

Why I'm Choosing a Bootcamp Now

So here I am, two days away from starting Techrise Cohort 2. And I'm not doing it because self-teaching failed—I'm doing it because I've outgrown what it can offer me right now.

Here's what I'm hoping the bootcamp will give me:

A Clear, Structured Path

No more guessing. No more "what should I learn next?" The bootcamp has a curriculum designed to take me from where I am to where I need to be—systematically. I'll go deep instead of wide, mastering one concept before moving to the next.

Structure isn't limiting—it's liberating. It frees me from decision fatigue so I can focus all my energy on actually learning.

Accountability and Deadlines

Let's be honest: when you're learning alone, it's easy to skip the hard stuff. It's easy to say, "I'll tackle that tomorrow" and never get around to it.

A bootcamp keeps you accountable. There are deadlines, projects, milestones. You can't just coast through the easy parts—you have to do the work. And honestly? I need that. I need someone (or something) pushing me to show up even when it's tough.

Peer Learning and Collaboration

One of the things I'm most excited about is finally being around people who think like me—people who wake up thinking about code and go to sleep debugging in their dreams.

Learning alongside others means:

- Seeing how different people solve the same problem

- Getting real-time feedback on my code

- Collaborating on projects (the way real development teams work)

- Building a network of peers who'll still be around after the bootcamp ends

Development isn't a solo sport, and I'm ready to learn how to work with a team.

Filling the Gaps (Especially Backend)

I'm comfortable with HTML, CSS, and frontend frameworks. But backend? Databases? Prisma? Deployment pipelines? I've dabbled, but I've never gone deep.

The bootcamp is specifically designed to take me full-stack—to turn my half-knowledge of Node.js and databases into real, production-ready skills. I'll learn not just *how* to build backends, but *why* we make certain architectural decisions.

I'm also diving into Vue.js on the frontend, which will expand my toolkit and make me more versatile as a developer.

Real-World Practices

Here's something self-teaching rarely covers: how do professional developers actually work? What does a proper Git workflow look like? How do you write maintainable code? How do you handle code reviews, testing, deployment?

Bootcamps teach you the practices that make you employable, not just capable. And that's huge.

What I'm Bringing From Self-Learning

Here's the thing, though: my self-taught journey wasn't wasted time. In fact, I think it's given me a massive advantage going into this bootcamp.

I'm Not Starting From Zero

I already know HTML, CSS, JavaScript, and responsive design. I understand how the web works at a foundational level. That means I can focus my energy on the new stuff—backend, databases, advanced JavaScript—instead of struggling with syntax and basic concepts.

Self-learning gave me the foundation. The bootcamp will help me build the skyscraper.

I Know How to Be Self-Reliant

When I get stuck (and I will), I know how to unstick myself. I know how to read documentation, debug effectively, and Google my way to solutions. Bootcamp instructors won't always be available—but my self-taught resourcefulness will.

I Actually Want This

Because I chose this path myself—because I spent months learning on my own before committing to a bootcamp—I know this isn't just a phase. This is what I want to do. That internal motivation will carry me through the hard days.

The Verdict: It's Not Either/Or

So, self-taught or bootcamp—which one is better?

Honestly? That's the wrong question.

The right question is: What do you need right now, at this stage of your journey?*

When I was starting out, self-teaching was perfect. It let me explore, build a foundation, and figure out if I actually enjoyed coding. It cost me nothing but time, and it taught me how to learn independently.

But now? Now I need structure. I need depth. I need to fill the gaps and level up fast. A bootcamp is the right tool for the job.

The best developers I know didn't choose one path and stick to it forever—they used different learning methods at different stages. They self-taught when they needed flexibility. They took courses when they needed structure. They joined bootcamps when they needed intensity. They learned from mentors when they needed guidance.

Learning to code isn't a one-size-fits-all journey. It's a choose-your-own-adventure, and the smartest thing you can do is pick the right tool for the stage you're in.

What I'm Expecting (and Nervous About)

I'm excited, no doubt. But am I nervous? A little.

I'm excited about finally mastering backend development. I'm excited about working on real projects with a team. I'm excited about having a clear roadmap for the next two months.

But I'm also nervous about keeping up. What if everyone else is further ahead? What if I struggle with concepts that seem easy to others? What if I hit a wall and can't push through?

Honestly, though? That nervousness is a good sign. It means I care. It means this matters to me. And I'd rather be nervous and growing than comfortable and stagnant.

Two days from now, I'll walk into that bootcamp as a self-taught frontend developer. Two months from now, I'll walk out as a full-stack engineer ready to build real solutions.

And I'll be documenting every step of the journey right here on CodeWithNaydu.

Over to You

So what about you?

Are you self-taught? Bootcamp grad? Somewhere in between? What's worked for you? What hasn't?

If you're trying to decide between self-teaching and joining a bootcamp, I hope this helps. There's no wrong answer—just the right choice for where *you* are right now.

Drop a comment and let me know your story. Let's learn from each other.

And if you want to follow along as I navigate this bootcamp, hit that subscribe button. I'll be sharing weekly lessons, honest reflections, and everything I'm learning along the way.

Let's grow together—one line of code at a time.

Next up: Day 1 of bootcamp. The real work begins.

---

Follow my journey from self-taught frontend developer to full-stack engineer. Subscribe to get new posts delivered straight to your inbox.

Who Am I?

My name is Naydu, and I'm a self-taught frontend developer based in Umuahia, Abia State. I currently work at Sticobytes, a digital service agency where I build web solutions using HTML, CSS, and frameworks like Bootstrap. I'm comfortable creating beautiful, responsive interfaces, but I've always known there's more to the story.

You see, frontend development is powerful, but it's only half the equation. I've dabbled in backend technologies—Node.js, jQuery, Express, SQL—enough to know what's possible, but not enough to feel truly confident. I want to solve real-life problems with code, not just make things look good. And to do that, I need to go deeper.

Why I'm Joining a Bootcamp

Next week, I'll officially begin Techrise Cohort 2, a 2-month intensive bootcamp facilitated by the Abia State Government in collaboration with the 17 Local Government Councils and Learn Factory. Right now, I'm already in camp, settling in and soaking up the prep talks, but the real work is about to begin.

You might wonder: "Why a bootcamp if you're already a developer?" Here's why:

Structure and Focus: Self-learning is powerful, but it can also be chaotic. A bootcamp provides a clear path, taking me from where I am to where I want to be—systematically.

Team Learning: Development isn't a solo sport. Working with others who share the same goals sharpens your skills, exposes you to different perspectives, and prepares you for real-world collaboration.

New Skills: I'll be diving deep into backend development with Node.js and Prisma, and exploring Vue.js on the frontend. These aren't just buzzwords—they're tools that will help me build complete, production-ready applications.

Accountability: When you're learning alone, it's easy to skip the hard stuff. A bootcamp keeps you accountable, pushing you to show up even when it's tough.

What Excites Me Most

I'll be honest—I'm excited. No doubts, no second-guessing. I'm excited about the possibility of connecting with people who share the same mindset, who wake up thinking about code and go to sleep debugging in their dreams. I'm excited about finally becoming comfortable with the backend, turning my half-knowledge into real expertise.

But beyond the technical skills, I'm excited about what comes after. I want to build projects that solve real-life problems—whether for my community here in Abia State, my region, or beyond. I want to contribute to something meaningful, something that makes a difference.

The Road Ahead: My Vision

This bootcamp is just the beginning. My goals are long-term:

In the next 2 months: Master full-stack JavaScript development, get comfortable with Prisma for database management, and build projects that showcase my skills.

In 1-2 years: Work with a team building impactful solutions. Create projects that address real problems—maybe improving local services, simplifying processes, or creating opportunities for others.

Beyond that: Dive into Web3 and blockchain technology. Our financial systems are going digital, and blockchain is the foundation. It's a new frontier, and I want to be part of building it.

Why I'm Blogging

Here's the thing: learning in public is one of the most effective ways to actually learn. When you commit to teaching others, you're forced to understand concepts deeply. You can't fake it when you're explaining something in writing.

But this blog isn't just for me—it's for you.

If you're a beginner, you'll find tutorials, explanations, and real talk about the struggles and wins of learning to code. I'll break down concepts in simple terms because I remember what it's like to be confused by jargon.

If you're an experienced developer, maybe you'll find value in my journey—or better yet, share your own insights in the comments. I believe we all learn from each other.

What to Expect from CodeWithNaydu

Starting next week, I'll be sharing:

Weekly lessons: As I progress through the bootcamp, I'll document what I'm learning—HTML, CSS, JavaScript deep dives, Node.js, Prisma, Vue.js, and more.

Beginner-friendly tutorials: Step-by-step guides that assume no prior knowledge. If I use a technical term, I'll explain it.

Real projects: Not just toy examples, but projects designed to solve actual problems.

Honest reflections: The wins, the bugs, the moments of frustration, and the breakthroughs.

My path to Web3: As I build my foundation, I'll be documenting my journey toward blockchain development.

I'm committing to posting at least twice a week. Consistency matters, and I want this blog to be a reliable resource for anyone on a similar path.

Let's Connect

This journey is better together. I'd love to hear from you:

Are you learning web development right now? Where are you in your journey?

What topics do you struggle with most?

What would you like me to write about?

Drop a comment below, connect with me on social media, or just follow along. Let's build something great—one line of code at a time.

And when I'm not coding? You'll probably find me reading, playing sports, or cheering on Manchester United (yes, even during the tough seasons).

Welcome to CodeWithNaydu. Let's learn, build, and grow together.

Next up: Week 1 of the bootcamp kicks off, and I'll be sharing everything I learn. Stay tuned!

Follow my journey as I go from frontend developer to full-stack engineer and beyond. Subscribe to get new posts delivered straight to your inbox…