Forem: Trevor Browning

The Bug Was One Character Long: Lessons From My First Full Stack App

Trevor Browning — Fri, 27 Jun 2025 20:47:26 +0000

The Initial Climb

Recently, as part of the upcoming freeCodeCamp Hackathon, my assigned team decided on the stack it would use:

Vue Express Typescript

At that point, I had only ever worked with basic HTML/CSS/JS. I had just recently learned how to set up Firebase, using it for a Discord group project for a kanban-style board. Dev Dashboard

At first, when looking up documentation and tutorials, I felt overwhelmed with how to properly handle Express, what went into securing an API, and how to properly run it. It took me a few hours of just going over everything from installation to usage.

After a bit though, it started to click. Once I found out what goes into setting up a backend, it started to make a lot of sense.

I worked on it for a few hours over the next few days, learning as I wrote new code — from hashing passwords to using .env to store environment variables.

Everything was going smoothly up to that point. I had the basic structure completed. I then had the new task of learning Vue.

Like I previously mentioned, I had only had experience with HTML, so switching to a component-based language like Vue was a new challenge, but like with the backend, it started to click. I had a working login flow, a secure API, and a frontend that could talk to it. I had built a full-stack application, albeit very basic, from scratch. Flushed with success, I decided to add one last "simple" feature before calling it a night. It should have been just a quick change. Instead, it made me want to start over.

The Descent Into Config Hell

At that moment, I was working on setting up the project routes and getting everything connected.

It should have worked perfectly fine, but something was wrong.

Error.

Only a simple error, the import was a bit off. No big deal, I fixed it.

I tried testing the server and frontend. Errors everywhere.

It made no sense. Everything was working great. It had been live 10 minutes prior with no issues whatsoever. The error messages were no help. I was getting a wall of red text about things like Cannot find module or No overload matches this call..., pointing to lines of code that hadn't been touched since the last successful run. It felt like I was going insane.

I tried using Google, no luck. I tried using ChatGPT to help me understand the error messages. All that did was run me in circles and suggest breaking 90% of my project by uninstalling dependencies and rebuilding the project with new imports.

After about 3 hours, nothing worked.

I was at a standstill with this project I just wanted to complete — the project I had a soft deadline for before the Hackathon started at the beginning of next week.

I decided to try one more fix.

I recreated the entire project from the bottom.

Unfortunately, after another handful of hours, I received the exact same error message.

I scanned every file, every folder. Everything looked correct (to me).

On my last bit of patience before giving up, I decided to look at my previous Git commits, just to prove to myself that it had been working.

I was scrolling through the file list, comparing it to my current project, not expecting to find anything. And then I saw it. A detail so small, so insignificant, that I had scanned past it a hundred (if not more) times.

A single character that had brought my entire project to a grinding halt.

In my project folder, the file was named ts.config.json.

I was exhausted, irritated, but making that one fix to correct it to tsconfig.json changed all of that. I felt the stress leave immediately. I was more annoyed that I had missed it so many times.

npm start | npm run dev — the server and frontend go live. No errors in sight. It was such a relieving moment.

The Payoff

I’m not an experienced developer. I’m still very much at the beginning stages, but it was such a satisfying moment once I fixed that simple mistake. I was so close to completely scrapping the project and working on something more my level. Thankfully, I kept persisting. I kept trying to find the root cause of why it was happening.

It only took another 6 hours or so to completely finish the first version of the project. I’ve never felt so proud to complete a project of this scale to date. I felt… accomplished. It’s only a simple full-stack that isn’t going to change the world, but I created it, I fixed it — it’s mine. I have this newfound confidence which will only help me grow as a developer.

Always stay persistent. Keep looking for that typo.

It will be worth it.

GitHub Repo

Live Demo

DevLog #2: When APIs Finally Clicked

Trevor Browning — Sun, 30 Mar 2025 15:02:23 +0000

A week ago, just hearing the word “API” made me nervous.

I’d seen them everywhere—every tutorial, every tool—but I never fully understood how they worked. I tried learning about them a couple of years ago, and again at the start of this current 14-day Python challenge. Both times, I hit a wall. JSON? Endpoints? Headers? I’d get overwhelmed and move on.

But then, halfway through this challenge, something finally clicked.

They’re Just Dictionaries.

Seriously. That was the moment.

Once I realized that most API responses are basically just dictionaries, it all made sense. Suddenly, I was able to break down the structure of a JSON response and start pulling data like I knew what I was doing. It wasn’t perfect—but it was progress.

My first working API call was a simple "Quote of the Day" app. It returned this quote:

"Success is about creating value." – Candice Carpenter

That quote hit harder than I expected—both in life and in code.

From Confusion to Clarity

Learning APIs wasn’t about brute-forcing documentation or memorizing syntax. It was about learning how to experiment. To try. To break things and fix them slowly.

Before this journey, I’d quit projects as soon as they stopped working. A typo here, a misplaced line there, and I’d be off chasing a new idea. Now, I’ve learned to breathe, read the error, and debug one step at a time.

The key change? Committing to finish. Every single day. One project at a time.

Patterns, Not Snippets

The repetition is starting to pay off.

In Tkinter, I now understand how to structure a UI with frames, and how to mentally map layout changes to specific blocks of code. In Flask, I finally get what @app.route("/") actually does—and it no longer scares me.

I still reuse a few bits of setup code here and there, but I’m trying not to rely on snippets. The more I type it out myself, the more it sticks.

What’s Really Changed

I don’t just write code now—I see it.

I can scroll through my own files and understand what’s happening without getting lost. I can visualize how the app looks based on what part of the file I’m reading. That used to feel impossible.

Most of all, I’ve stopped waiting to feel “ready.” I just build, break, fix, and repeat. I think about what I built yesterday, what I’m building today, and how I’ll tweak it tomorrow.

And slowly, I’m starting to think like a builder.

What Comes Next

There’s still a week left in this challenge, and I’ve got plenty more to learn. But already, this feels like a turning point—not just in skill, but in mindset.

My goal isn’t to “finish the 14 days.”

My goal is to walk away with lasting skills and the confidence to build what I imagine.

Thanks for reading. If you’re learning APIs, Python, or just trying to push through your own roadblocks—stick with it. You might be one small project away from your own breakthrough. If you’ve been down this path before and have any advice, I’d love to hear it. I’m always open to learning from others.

DevLog #1: Why I’m Building 14 Projects (and What Comes After)

Trevor Browning — Fri, 28 Mar 2025 15:07:52 +0000

Earlier this week, I gave myself a challenge: build 14 small Python projects in 14 days. The original plan was simple - stick to basic CLI apps, focus on core Python concepts, and keep the momentum going.

But a few projects in, I decided to raise the bar.

I’ve tried learning to code on and off for the past few years, using all kinds of resources — tutorials, videos, docs. But I kept getting stuck.

Eventually, I realized the problem wasn’t knowledge...it was practice. So I decided to stop looping through the syntax and actually put it to use.

I created a spreadsheet and mapped out 14 days. Each day would be a new project. No filler. Just build something real in 3–4 hours and ship it. Simple tools. Simple structure. Complete focus.

Why GUI?

The original plan was all CLI. But once I got started, I realized that adding even simple GUIs made these projects feel more complete. More usable. More mine.

So I leaned in.

Even simple interface work forced me to learn things I hadn't touched before - layout systems, file handling, keyboard bindings, packaging apps as .exe files, and how to keep code organized when projects grow.

And I’ve learned way more in a few days than I have in two years of just “learning to learn.”

What I’ve Built So Far

Here are a few of the apps I’ve completed:

A file renamer with batch handling and live previews
A simple calculator with full keyboard support
A journaling app with autosave and focus mode
A time tracker for logging hours spent on this challenge
A password generator with strength options and CSV export
A to-do list app - my first ever GUI (TrevList)

Each project taught me something new. They all started as small ideas, and now they're open-source, usable tools that I built from scratch.

Why I’m Doing This (Learning and DevLog)

I've realized that posting your own work for the first time is kind of... anxiety-inducing. It’s easy to wonder if what you’re building is “good enough” or if anyone will take it seriously - especially when you're still figuring things out.

But I’ve decided to share anyway. Because waiting until everything is polished usually means never sharing at all. And honestly, the rough edges are where the real learning happens.

I'm not trying to build the next big thing. I’m not chasing perfection.

I’m doing this to learn by finishing - to take an idea, turn it into real code, and release it. Even when it’s messy. Especially when it’s messy.

Before all this, I worked in film production for years. Now I'm starting to spend most of my time building tools and trying to learn to the best of my ability. This challenge has helped me think more like a developer - not just in syntax, but in structure, decision-making, and shipping work.

What Comes Next

I’ll be writing Dev Logs here every few days (or at least weekly), sharing what I’m building, what I’m learning, and where I’m stuck.

No fluff. No polish. Just real notes from someone learning in public.

If you’re learning Python too, or just trying to build more consistently...feel free to follow along or drop a comment. I’d love to connect.

Thanks for reading. More soon.