Legend Of Imposters: How a Beginner Project Helped Me Battle Shame

Source: Dev.to

Introduction

There are two wolves that live in me – one with an endless desire to improve, learn, get really good at what I do, and put myself out there. The other – shame.

• Why don’t I know this stuff better?
• This project is lame.
• People will think “how the heck does she have a job?”

The truth is, I really enjoyed my latest project. I learned a ton, and yeah, I’m a little embarrassed that this didn’t click earlier for me. I’m here regardless because I’m excited that I learned something. Months from now I’ll look back and see how far I’ve come. Even if you’ve been at this for years, put yourself out there and ask the questions. Do the “lame beginner project.” The only time you lose is when you don’t try.

I’ve often heard people talk about imposter syndrome, and I’ve thought, “Okay, but with me, if they really knew… It’s not imposter syndrome if I’m really an imposter!” That fear kept me from posting about my journey, asking questions, and celebrating my wins. I’m taking a step forward now. Reflection and feedback are part of how I learn, so here we are.

Why I Went Back to the Basics

I LOVE The Legend of Zelda: Breath of the Wild. It’s easily in my top 5 games I’ve ever played. When I wanted a small, low‑stakes project to understand API and frontend interactions better, I stumbled on a free API for the game… I was stoked.

The purpose of the project was twofold:

1. Get more at ease with APIs – learn how to read them, access properties, and transform data into something users can actually interact with. I do this all the time at work, but I often feel like I understand too little. I know what works, but not why.
2. Practice some CSS – because why not have fun with it?

I learned a lot! Most of it wasn’t even what I was aiming to learn. I thought I’d deepen my basics and turn APIs from “dev magic” into “a puzzle I can solve.” Instead, I discovered how much architecture, naming, and structure affect my ability to reason about a project. And apparently, DOM manipulation can absolutely humble you after years of living inside frameworks.

This year I’ve emphasized learning architecture and design principles, so imagine my surprise when I discovered that even a small free‑API project requires architectural thinking.

Mapping the World: Mental Models & APIs

The API was fun and easy to read. Hats off to the maintainer – they did a great job. I’d recommend it to anyone who wants to explore projects with BOTW data.

As I started poking around the data, something I’d only heard about in recent months finally made sense: mental models. I first heard the term on a podcast and Googled it, but it didn’t click. Only after working with the API and reflecting later did I realize I’d been building those internal maps all along – picturing how the data flows, how pieces connect, and how the UI should act. When I used Postman to explore the endpoints, I was actively building mental models.

I originally imagined something much more complex, but after actually interacting with the data, I pivoted. A straightforward compendium – where I could easily look up items and their locations in the game – ended up being perfect. No need for back buttons or multiple views.

The Combat: Async Tracks and DOM Manipulation

I was honestly shocked at how quickly I lost track of data and responses. I intentionally used .fetch().then().then().catch() chains instead of modern syntax to force myself to understand the Promises that power the async/await world we live in.

At one point I spent half an evening wondering why my data looked perfect in a console.log inside the fetch… but never made it to the UI. Turns out I never returned the Promise in one of my .then() chains. The console showed the right thing, but my UI literally had nothing to work with.

Tracking where data was lost became a theme in my project. I learned very quickly that when classes are grouped properly, debugging becomes so much easier. Clean structure helped me follow the data from start to finish. Most of the bugs I hit boiled down to losing track of data flow. This project showed me clearly where I need to improve: tracking data from fetch to frontend.

DOM manipulation also kicked my butt. Adding elements dynamically felt foreign after working in Angular all day. I walked away with a dozen new Anki cards and a better grasp of built‑in method quirks. My go‑to pattern was:

1. Find a working solution (hello, StackOverflow).
2. Understand why it works.
3. Compare it to my broken version.
4. Use AI as a rubber duck – I always told it not to give me answers, just to ask questions, so I had to think more deeply.

New Game Plus: Lessons in Architecture

Now that I actually know what mental models are and have a little more experience with designing and architecting, I’d do a few things differently:

• Write out 1–3 interactive user flows – what the user is trying to do and what alternatives they might take. That alone would shape UI choices and data expectations.
• Stop throwing everything into a class – classes should represent behavior plus state. This helped untangle a lot of the mess I created early on and showed me how much cleaner my code can be when helpers live separately from the things that actually manage data.

The Loot: What I Actually Learned

This project unlocked understanding in places I didn’t expect – architecture, async flow, DOM manipulation, and, honestly, confidence. I walked away feeling like I finally “get” Promises in a way that’s not just theoretical.

More than that, it reminded me that tiny, low‑stakes projects can level up a whole range of skills at once. I’m already building my next little experiment, and I’m excited to share that one too.

And the next time those two wolves start arguing about whether my project is lame or whether I should post it anyway… well, I’ve got a little more evidence that feeding the curious one pays off.