DEV Community: Ellie O'Connor

Building the Tool I Wished I Had

Ellie O'Connor — Fri, 16 Oct 2026 02:42:19 +0000

Lately I've felt an irresistible pull to finally act on an idea I've carried around for years.

In a former life, I was a special education teacher. That job is actually how I got into tech: I wanted to build tools that would make my own work easier. I'm starting what is fondly known in the #100Devs community as my "100-hours project".

The problem

In many ways, special ed teachers are on their own. You find your own tools. You create your own systems. And the resources you need for everyday tasks are scattered across too many places. When it came time for me to update students' progress weekly or prep for a student's IEP, I would lose hours just collecting data from multiple sources.

A core part of the job is tracking students' IEP goals. One student can have one to five goals. In a state like mine, with no cap on caseloads, a teacher can have 25 or more students. Twenty-five students times even two goals each...you do the math.

So I'm building SpEd Hub, a tool that pulls those resources into one place, starting with writing, saving, and tracking IEP goals.

The tools

Database: PostgreSQL. Student goal data has a predictable shape, which fits a relational database with a fixed schema, where the database itself enforces the rules. I also chose it because I want to strengthen my skills in SQL and database design, so I'm writing every query myself.

Backend: Python with FastAPI. Python was the first language I learned, and its type hints feel familiar coming from TypeScript. I also love that FastAPI builds a solid docs page for my API automatically. But the biggest reason is AI. Python's data and AI ecosystem is hard to beat, and I have real AI plans for SpEd Hub, from progress analytics to helping teachers find resources.

Frontend: React and TypeScript. I have a soft spot for Angular, but React is a skill I want to stretch. That's really all that went into this one.

AI: Claude. In the past I've used tools like BMAD, and I still like it, but Claude has evolved so much over the last year and a half that BMAD's skills no longer feel unique. For this project I'm using Claude's Projects feature on the web: asking targeted questions, iterating on ideas, walking away, and then reading the source material myself. Claude is great at the overview, but it can't always predict what will spark understanding for me, so I love that it points me to sources. The biggest lesson has been learning to push back, so my own ideas shine through and I actually understand what I'm building instead of letting Claude do it all or just saying "looks good to me."

Right now the schema is in a good place, and I'm writing the endpoints.

Why it matters to me

This is a passion project. Making teachers' lives easier excites me, and so does building better connections between teachers and students and keeping parents in the know about their child's goals. I also have ideas for improving communication between special ed and gen ed teachers.

I'm not building something huge or worrying about scale. But I do want something that's actually useful and fast. Teachers have it hard enough.

Your turn

I'd love to hear from you:

How do you make decisions about your database structure?
What tools do you use for planning?
What does your scoping and planning process look like?

'Introducing Myself: From Classroom Teacher to Full-Stack Developer'

Ellie O'Connor — Tue, 17 Mar 2026 23:03:16 +0000

Introducing Myself: From Classroom Teacher to Full-Stack Developer

Hi! My name is Ellie, and I'm a full-stack software developer.\
This is my first blog, and I'll admit, I'm feeling a little self-conscious about it. There are so many blogs out there–why add to the noise? Well, this blog isn't just for you; it's for me. It's a space for me to reflect, learn and grow as a developer. If you stick around, you may just find something valuable here too.

My Journey So Far

My journey into software development started in an unlikely place: a special education classroom.\
Back in 2014, I learned just enough code to mock up some screens for my dissertation on assistive technology. At the time, I never imagined I could become a developer. I had all these preconceived notions about working tech that I used to gate-keep the field from myself.

In 2016, I landed my first job in special education. I loved the role, but I couldn't shake the feeling that students and teachers deserved better tools. In my department, we used three different programs just to write and track students' progress towards their IEP goals, and another seven websites and software programs to create instructional materials. It was overwhelming and inefficient.

That's when I started coding with a dream: to create a one-stop-shop for special education teacher–a tool that could handle IEP goal building, tracking, and resource creation all in one place. Step one? Learning web development basics, HTML and CSS (thank you FreeCodeCamp!).

My journey accelerated in 2022 when I left teaching. It was terrifying–teaching was all I'd known for nearly a decade–but I know it was the right move for me. I had been working my way through FreeCodeCamp and a Python book, but felt overwhelmed. Everywhere I looked on social media, someone had an opinion on the "best way to learn to code". And even more people wanted to sell their mentorship or knowledge for thousands of dollars.

On a coding Discord server, I discovered #100Devs, a free, live coding bootcamp hosted on Twitch. I had missed the first class but joined for the second one. That changed everything for me.\
The #100Devs classes and community helped me build a foundation I could stand on and continues to be a source of community and learning. I truly attribute my career change to that moment when I joined.

Today, I'm part of a lean team at the number one ERP system for the metal casting industry, putting my skills to work every day.

Why I Build This Blog

So, why a blog?

For me, writing is a way to solidify what I'm learning. When I put my thoughts into words, I understand them better. This blog is a space for me to explore the lessons I'm learning and talk about the projects I'm working on.

But, it's also about connection. I'm hoping to meet others who are on similar journeys–whether you're a seasoned developer, a career changer like me, or just someone who's curious about tech.

Let's Connect

If you've made it this far, you're a legend and I appreciate your time and energy. If you'd like to see more of my work, stay tuned to this website. I'll be adding my projects over the next few weeks and posting more about my learning progress. You can find ways to connect with me on my "Contact" page.

I'm a big fan of virtual coffee chats and would love the chance to meet others.

I'm excited to share my journey with you, and I can't wait to see where it takes us.

Until next time,

Ellie

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

Ellie O'Connor — Sat, 06 Dec 2025 01:29:05 +0000

There are two wolves that live in Ellie – 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 have often heard people talk about imposter syndrome, and I've often 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. So when I wanted a small, low-stakes project to understand API and frontend interactions better and stumbled on a free API for the game...I was stoked.

The purpose of the project was twofold. First: get more at ease with APIs – how to read them, accessing properties, and transforming 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.\
What happens if I try doing a, b, c like x, y, z instead? This project gave me the safety and creative space to explore that.

Second: 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 had a huge emphasis on learning architecture and design principles. So imagine my surprise when I discovered that even in a small free-API project requires architectural thinking.

Mapping the World: Mental Models & APIs

This was a fun, easy-to-read API. Hats off to the maintainer because they did a great job. It's an API I would recommend for 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. 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. But I walked away with a dozen new Anki cards and a better grasp of built-in method quirks. My go-to pattern was: find a working solution (hello, StackOverflow), understand why it works, compare it to my broken version, and then 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.
I’d start by writing out 1–3 interactive user flows—what the user is trying to do and what alternatives they might take. That alone would have shaped my UI choices and my expectations for the data.

I’d also stop throwing everything into a class. Learning that classes should represent behavior plus state helped me untangle a lot of the mess I created early on. It also 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 so many 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.