Sinners just won the Oscars. No one's surprised — it's a great film. But what caught my attention wasn't the win itself. It was a clip circulating about Ryan Coogler, the director, and where he says his first real introduction to Irish culture came from.
Not a documentary. Not a trip abroad. A Disney Channel movie called Luck of the Irish.
He talks about the river dancing scene — this big, loud, joyful moment in a movie most people barely remember. And yet, there it was, quietly sitting in his mind for years. Quietly shaping the sensibilities of the man who would eventually make one of the most celebrated films of the year.
Luck of the Irish is not an Oscar-winning movie. Not by any measure. But it inspired one.
I've never wanted my work out there. My code, my writing, whatever I'm making — it never felt good enough to share. The gap between what I imagined and what I actually produced always felt too wide, too embarrassing. So I kept things to myself. I told myself I'd put it out when it was good. When it was ready. When I could stand behind it.
But what if that's not the point?
Even imperfect work does something in the world. Maybe someone looks at your app, your documentation, your half-finished side project and thinks I can do something 10 times better than this in my sleep. And then they go and do it. That's still inspiration. You moved them. You gave them a reference point — even if that reference point was something to push against.
And if you never put it out, you never gave them that.
There's also something else that happens. You participate. You put yourself in the room. Like everyone at the gym who's sweating and struggling — you showed up. You did something. The person sitting at home trying to decide whether or not to get up and go in didn't do anything. I spent a long time being that person. Waiting until I was ready to be impressive before I'd let myself count.
I've been picking up watercolor painting lately. I'm not skilled. I'm not even sure what I want to paint most of the time.
There was a day I got into a fight with my boyfriend as couples sometimes do. I needed somewhere to put it, so I picked up a brush, found a quick reference on Pinterest, and tried to copy it. It wasn't good. But if you squint hard enough, you can kind of see where the inspiration came from.
I put it on my mirror.
Now it catches the corner of my eye throughout the day, and I smile — because I made that. It's a small, crooked, imperfect little thing. And it gives me a piece of joy I didn't know I could feel. I didn't know I was allowed to feel that about something I made before it was perfect.
That painting is inferior by almost any standard. It's also mine. And it matters to me in a way that the imaginary perfect version never could, because the imaginary version doesn't exist. This one does.
People idolize greatness but not the mediocre work that got us there.
I used to live in a loop: I'll start when I'm ready. I'll put it out when it's good. I'll count it when it matters.
The problem is nothing ever felt ready, good enough, or worth counting. So I never started, never put anything out, and never let anything count.
When I turned 30, I decided that everything I do from this point forward counts. The code, the writing, the bad watercolors. All of it. Not because it's perfect — it won't be — but because doing the work is the point. The work I put out might inspire someone. It might inspire them to do better. It might catch someone on a bad day and give them a small, quiet reason to smile.
I never thought my work mattered because it was inferior. So I held it back, and I never gave myself the chance to grow past that inferiority. But Ryan Coogler watched a Disney Channel movie about a kid who discovers he's Irish, saw people dancing, and carried that with him into Sinners.
That's enough proof for me.
The inferior work matters. Put it out.
]]>I really did not anticipate how long it would take.
I spent most of my time testing and continuously changing the code. Sometimes it was just too unstable for regular use. I did eventually complete my application. And I have a working app and the same skill level I started with.
That's the paradox. I built a tool to get better at DSA, and building it consumed all the time I could have spent getting better at DSA.
I thought shipping would be the finish line. "Once I can see over the hill, I'll be done" was what I thought, and what kept me working ferociously.
Reality: shipping was the starting line. Maintenance, users, bugs, features - all of it was waiting on the other side. A product isn't a task you complete. It's a commitment you maintain.
Now that I'm using it constantly I see so many more opportunities for improvement. What was a bug-infested rent-controlled complex is now less infested and could probably get top dollar on the free market. Too bad it's open source. I keep two versions of the application now - one that's stable for my actual use, and another for continuous integration and improvements. Because I learned the hard way that you can't study on a platform you're actively breaking.
I wanted my application to be perfect before releasing. The drive toward perfection was misguided. I wanted CodeMaster to be successful, and I hoped creating a perfect application would get me there. I wanted it to be all-encompassing, a full learning engine, so I incorporated a lot of moving parts.
I bet you aren't surprised when I tell you I never reached perfection.
I spent so much time on it that it got to the point where I just had to make it public because I actually wanted to get back to learning DSA and applying to jobs. I wanted this application on my portfolio. It just got to the point where I couldn't justify spending more time on it.
Each new feature must integrate with everything existing. I wanted CodeMaster to be adaptive to a user's performance. To do that means a lot of integration points. The app barely asks users for input - there's really only one form where we're regularly collecting anything, the problem submission page, and even there two of the inputs are automatically filled from LeetCode.
My session system has 3 layers:
Seems simple. But there's a 4th layer that integrates between everything else. To control stagnation and session composition I added escape hatches for when a user is stuck on one difficulty of problem. Just recently I fixed a bug where we were creating sessions that were all hard problems. Seeing that annoyed me. I didn't want to even attempt the session, so I waited for it to go stale and trigger the regeneration script to create a new one.
Can you believe I went to check my numbers on the Chrome extension store and it dropped from 5 whole users to 3? All that integration work. For 3 people.
I spent so long building CodeMaster that I forgot why I was building it. The app was supposed to get me better at DSA. Instead it became the thing I poured all my time into while my actual skills stayed the same.
But now it exists. It works. And I'm finally using it for what it was meant for.
The paradox didn't resolve because I figured out the perfect balance between building and studying. It resolved because I eventually just stopped. Stopped adding features. Stopped chasing perfection for 3 users. Stopped treating the tool like it was the goal. I closed the IDE and opened a problem.
Sometimes the best feature you can ship is the decision to stop shipping features.
]]>With tools like Google Antigravity, the cost to create an application has dropped dramatically. You can delegate entire tasks to AI agents. You can ship without fully understanding what you shipped.
But understanding isn't required to build anymore. It is required to maintain.
Building an app is no longer impressive on its own. The new question is: how long did you maintain it? Because that takes real understanding.
I've been reading Clean Code while refactoring CodeMaster. Each chapter sends me back through the codebase looking for places to improve. Here's what I've learned: when you're working with a mature codebase, most of the decisions have already been made.
That's a double-edged sword. Early on, large sweeping changes were easy because my patterns weren't established yet. The code was flexible. But as the project grew, those early decisions hardened into constraints I had to live with or fight against.
Some of those early decisions were mistakes I didn't recognize until maintenance forced me to.
When I started CodeMaster, I asked AI what stack would make the most sense for a Chrome extension. I didn't look too deeply into the npm packages it recommended. I searched them to make sure they existed and that the documentation said they could do what I needed. That was enough to move forward.
Mantine was one of those choices. A React component library. Clean, well-documented, easy to use. AI suggested it, the docs looked good, so I went with it.
Towards the end of the project, right before releasing to the Chrome Store, I noticed something: I had a lot of Mantine style overrides in my CSS. When I was implementing the onboarding flow, I was constantly fighting with Mantine's styles. Every component needed tweaks. Every layout required workarounds.
Then I stopped and asked: why am I doing all this work to fix a problem that shouldn't exist?
Mantine is designed for standalone applications. I was using it in a content script that overlays LeetCode pages. The styles were conflicting because the library wasn't meant for my use case. I had to pull Mantine out of the content script entirely. I still use it for the dashboard pages where it works fine, but that refactor cost me time I wouldn't have spent if I'd understood the constraint from the start.
AI recommended the library. AI couldn't tell me it was wrong for my architecture. That required understanding the system I was building.
The Mantine problem wasn't just a maintenance issue. It was an architecture issue. I didn't understand how the pieces of my application fit together.
AI can write components. It can't decide where they belong.
It used to be that you had to build applications backwards. You had the big picture of what you wanted, then you broke it into confetti and had to piece it back together. You built your UI component by component, like assembling a puzzle one corner at a time. Then you moved to your backend. Then you figured out your services.
Now you can bring your full idea to AI. We don't have to carry the little pieces of the picture anymore. AI handles the confetti.
So what's left for the developer? Seeing how the pieces fit. Knowing which pieces to use in the first place. Knowing that a standalone component library doesn't belong in a content script. That's architecture—understanding your system well enough to make decisions AI can't make for you.
I don't think AI will ever create an application end-to-end with just one prompt. It works in controlled environments. "Build a Facebook clone" gets close because there's plenty of documentation. But for something truly new, AI can only remix the old. It can tell you what's likely to work and what won't. It can't envision what doesn't exist yet.
And it can't see your whole system at once. It doesn't know that your Chrome extension has three different contexts: background script, content script, dashboard. Each with different constraints. It doesn't know that a choice that works in one context creates problems in another. Only you can hold that picture in your head.
With this level of abstraction, you need a new type of developer. One who can zoom in and out.
Zoom in: debug the CSS conflict, trace the state bug, understand why this specific component breaks in this specific context. Zoom out: see how the content script relates to the background script, understand why a library that works in one place fails in another, hold the whole architecture in your head.
AI is excellent at the zoomed-in work. It can write the function, fix the syntax, suggest the solution. But it can't zoom out. It doesn't have the context. It doesn't know your system.
Creation is cheap now. The value is in understanding: how the system is designed, how long you can keep it running, how deeply you know what you built.
The most important question when building is why. Why this architecture? Why this tool? Why does this piece belong here and not there? Features don't matter unless they're connected to a reason. The applications that succeed have a clear why behind every decision.
AI doesn't know your why. That's still yours.
]]>For the last two months, I've been in maintenance mode. Refactoring. Rewriting. Breaking things, then fixing them, then breaking them again. The features all work. The app is live. But the codebase underneath? It was a mess I had to clean up.
This is the part no one talks about when they say "just ship it."
Most of my branches have one to three commits. Small, focused changes. But there's one branch in my git history with 150 commits. I call it my shame branch.
Here's what happened: I added a linting rule that enforces file size limits. Overnight, I had 180+ warnings. Files that had grown too big while I was focused on features. So I thought, "I'll just fix all of these at once."
That was a mistake.
I started extracting helper functions, splitting files, reorganizing folders. Every change broke something else. I'd fix one regression and create two more. I was refactoring code I'd written when I didn't fully understand what I was building. The 150 commits were me stumbling through the mess I'd made.
I used AI to build faster. ChatGPT and Claude were my constant companions. But building fast with AI created its own kind of debt.
I didn't write tests as I built. So later, I asked AI to write tests for bugs I kept hitting. But generating tests isn't the same as understanding what to test. I ended up with tests that were too tightly coupled to implementation details. When I refactored, the tests broke, and I couldn't tell if it was a real bug or just a test that needed updating. I had to throw a lot of them out.
Same with linting. At first my rules were too strict. AI is good at delegation, but if you're not reviewing the output carefully, the quality slips. While the foreman is out, the workers go out to play.
Every shortcut I took came back to haunt me.
I set up linting rules and testing infrastructure on the same day back in July. But I didn't enforce them consistently. The rules existed, but they weren't blocking bad code from getting merged.
Now I start every new project differently:
I also learned that tests should verify behavior, not implementation. The question isn't "did it call this internal function?" It's "did it return the right data?" If I'd understood that earlier, my tests would have survived the refactoring.
Building something and keeping it running are different skills.
When you're building, you're focused on making it work. Ship the feature. Fix the obvious bugs. Move fast. But maintenance requires a different mindset. You have to think about what happens six months from now when you've forgotten how this code works. You have to care about the code you're leaving behind, not just the feature you're adding.
I'm considering converting the project to TypeScript. Not because JavaScript doesn't work, but because TypeScript catches the exact bugs that kept biting me. Wrong data shapes. Missing properties. Functions returning different types than their callers expect. The compiler would have caught half my regressions before they happened.
Everyone celebrates shipping. But the project isn't done when it ships. It's done when you abandon it.
I spent two years building CodeMaster. I've now spent two months just cleaning it up. That ratio probably isn't unusual. The maintenance phase is long, unglamorous, and necessary.
If you're building your first real project, know this: the code you write today is code you'll have to maintain tomorrow. The shortcuts you take will come back. The tests you skip will haunt you.
Ship it. But then stick around for the hard part.
]]>I shipped CodeMaster. It's real. It's live. Here's what I learned.
Starting projects was never the problem. I'm full of ideas. But finishing? That's where I always fell short.
The difference between a half-finished project and a shipped project isn't skill. It's showing up consistently, even when it stops being exciting.
Some days I was excited to work on CodeMaster. Other days it felt like a slog. But I showed up anyway. You don't have to feel motivated. You just have to show up.
I'm not gonna lie ChatGPT was my constant companion. I'd ask it why things weren't working, help me decode errors, think through problems out loud.
But AI didn't save me from my own simple mistakes. I had bugs that came from not understanding how Chrome extensions work things I should have known if I'd read the documentation. That equals wasted time I could not cut. AI could fix symptoms, but it couldn't give me foundational understanding. I had to earn that.
This app was supposed to be an MVP.
Then I showed someone an early version and they were wildly unimpressed. So my insecure self just started adding features. Whatever made sense, I put in. That's why this is no longer an MVP—it's a full-fledged app.
I spent two years working on this by myself, not showing anyone. That was insane. I shouldn't have done that.
I can't say I regret it I'm proud of what this became. But I would iterate faster next time. Show it sooner. If you're building something for other people, it should be shown to other people. By hiding it, I wasn't creating the best possible application. I didn't have to do it alone.
Building in public builds up contacts. People get you in their heads an idea of who you are, what you're trying to build. I could have built up a user base. I could have gotten feedback earlier. That's one of my biggest lessons: iterate faster and show people what you're building.
When you're building alone, you can't rely on motivation. You need systems.
For me, that meant:
The systems kept me moving forward even when I didn't feel like it.
I had this vision of what CodeMaster would be elegant, polished, every feature I dreamed of.
The reality was messier. Some features didn't work the way I imagined. The UI wasn't as smooth as I wanted. Bugs. Edge cases I hadn't considered.
But the gap between vision and reality is normal. It doesn't mean you're failing it means you're in reality, not a fairytale.
Shipped products are never perfect. They're just good enough to be useful.
Before CodeMaster, I felt like a fraud. I had certifications. I had done bootcamps. But I didn't have proof that I could execute.
Shipping one thing changes everything.
Now I have proof. I can point to CodeMaster and say: "I built that. End to end. It works."
That confidence is real. It's not based on hope or potential it's based on evidence.
More projects. More shipping. More proof.
Because at the end of it all, the only way I know if life was worth it is through what I was able to create.
]]>Here's what I built and why each feature matters.
The core of CodeMaster is the Leitner system—a proven method for spaced repetition that helps you retain information long-term.
Here's how it works:
Problems move through different "boxes" based on how well you know them.
If you solve a problem correctly, it moves to the next box. If you struggle, it moves back down. This means you spend more time on what you don't know and less time on what you've already mastered.
Why this matters:
The Leitner system ensures I'm actually learning, not just checking boxes. It also has cooldown logic—problems don't come back immediately. They space out over time based on which box they're in. This prevents burnout and mimics how our brains actually retain information.
One of the biggest challenges with LeetCode is knowing what to practice next. There are thousands of problems, and it's easy to feel lost.
That's why I built pattern ladders.
Pattern ladders guide your progression through algorithm types with tag-aware difficulty scaling.
Instead of jumping randomly between topics, CodeMaster helps you:
This gives structure to your learning. You're not just solving random problems—you're building mastery step by step.
Why this matters:
When I was practicing without structure, I would avoid the hard topics. Pattern ladders force me to confront what I'm weak at, but in a way that feels manageable.
CodeMaster doesn't just give you random problems. It adapts based on your performance.
Adaptive sessions adjust based on:
This means every study session is tailored to what you need most right now.
Why this matters:
Adaptive sessions make sure I'm using my time efficiently—working on what will actually move the needle.
CodeMaster includes a dashboard with visual analytics powered by Recharts.
You can see:
Why this matters:
Progress can feel invisible when you're learning algorithms. The dashboard makes it tangible. I can look at it and see: "I've moved 15 problems to Box 3. I'm getting better at arrays. I need to work on graphs."
That visibility keeps me motivated.
The extension architecture was one of the trickiest parts to build. Chrome extensions have three main components that need to communicate:
Getting them to sync state without conflicts required building a custom message-passing system and careful IndexedDB management.
The technical challenges:
The biggest hurdle was state management. When you mark a problem as complete in the popup, that needs to update IndexedDB, refresh the dashboard, and notify the content script—all while handling race conditions and keeping data consistent.
I built a custom React hook (useChromeMessage) that handles all the message passing between components. It ensures that state updates flow smoothly and data doesn't get out of sync.
Why this matters:
Building the extension forced me to learn browser APIs deeply—something I wouldn't have gotten from a web app. Managing asynchronous state across multiple contexts taught me more about JavaScript than any tutorial could.
CodeMaster tracks tag mastery behind the scenes using a scoring algorithm that weighs three factors:
Tags with low scores get prioritized in your next session. It's like having a coach who knows exactly where your weak spots are.
How it works in practice:
Let's say you've mastered Arrays (high accuracy, recent practice, good coverage) but you've been avoiding Dynamic Programming (low accuracy, not practiced in weeks, few problems solved). The tag mastery engine will surface more DP problems in your adaptive sessions until your scores balance out.
The algorithm constantly adjusts based on your performance. If you ace a DP problem, its priority drops. If you struggle with an Array problem, Arrays get bumped back up.
Why this matters:
This automatic prioritization means you don't have to think about what to practice next. The system handles it for you based on your actual performance data, not your feelings about what you should work on.
That's the thing about building something real. You have an idea of what it should be, and then you have to actually make it work.
Building CodeMaster taught me:
The features work. They help me learn. And that's what matters.
CodeMaster is a personalized learning and productivity Chrome Extension that helps developers master data structures and algorithms through a smart, pattern-based spaced repetition system.
It's not perfect. But it's real. And it's helping me get better at algorithms every day.
In the next post, I'll share what I learned shipping CodeMaster—the challenges, the surprises, and what I'd do differently.
]]>I didn't do that. I only wanted to spend my time building something I would be proud of. Something I was struggling with—so that even if I failed to make it a commercial success, it would still be a tool I could use to solve my own problems.
The problem I chose to solve was my own. I was preparing for technical interviews and drowning in LeetCode problems with no way to know if I was actually retaining what I learned. Every tool I tried felt like it was built for someone else's brain, not mine.
People might ask why make your first real project so complicated. It didn't start out that way. But I realized that building something I genuinely needed meant I'd actually finish it. If it failed commercially, I'd still have a tool that solved my problem. That made it worth the complexity.
When I started practicing LeetCode seriously, I quickly realized I had a problem. Not with solving problems—but with knowing if I was actually improving.
At first I just went over random easy problems—that was just me spinning my wheels for a couple weeks. Then I found the LeetCode Patterns curated list made by seanprashad. It was helpful because it let me study related topics together. I had a route I could follow.
But I still felt like I was behind. I had no system. No way to track what I was getting better at. No way to know if I was actually improving or just staying busy. I couldn't tell you which patterns I had mastered and which ones I was still struggling with.
That was the problem.
There are a lot of tools out there for LeetCode practice. Problem trackers. Progress dashboards. Study plans.
But none of them worked the way my brain did.
I needed something that would:
Every day I practiced, I wished it existed. So I built it.
A Chrome extension made sense because:
I didn't want to build another todo app because I don't need another todo app. I needed something that would help me get better at the one thing standing between me and the career I wanted.
The goal wasn't just to track problems. It was to build a system that would help me actually get better, not just feel busy.
Before CodeMaster, I would solve a problem, feel good about it, and then completely forget the solution two weeks later. I needed a system that would force me to revisit problems at the right intervals—not so soon that I was just memorizing, but not so late that I'd forgotten everything.
That's what spaced repetition does. It's not just tracking—it's actively reinforcing what you've learned at the exact moment your brain is about to forget it.
What do you do for work? Most people answer with their profession or a job they're currently working, like it's the all-encompassing answer. The question is answered as if it's the only work that matters.
The economic pressure of life decides what work we take on based on how much money we can make and how painful the work is to complete.
But I decided in 2022 to take the other work I do in my life seriously. What that means is acknowledging and taking seriously my own aspirations and goals.
I can't force my success in the world. And while I have monetary goals, if I am able to prioritize my own work, my own creations, money will follow.
CodeMaster isn't just a portfolio project. It's proof that I can identify a problem, build a solution, and ship something real.
And that's why I didn't build another todo app.
Next post: The Features That Make CodeMaster Work
]]>Amazon Web Services (AWS) has roughly 40 percent of the cloud infrastructure market, so when a major outage happens, it naturally cascades across hundreds of companies and millions of users. But it made me wonder: whose fault is it when something like this happens — AWS or the developers who build on top of it?
The outage itself was isolated to AWS's US-EAST-1 region (Northern Virginia), yet so many applications across the country went offline. Shouldn't there be failovers or backup systems to handle that? What actually failed was AWS's internal DNS system, which connects core services like DynamoDB, EC2, and CloudWatch. When those DNS lookups broke, any application trying to reach those services simply couldn't — causing a ripple effect that spread far beyond one data center.
The reality is that while multi-region redundancy and backups are possible, they're also expensive. Running mirrored infrastructure in multiple data centers can easily increase monthly cloud costs by 50–200%, depending on the service and amount of data replication. For a smaller SaaS company spending $10,000 a month on AWS, that could mean $15,000–$25,000 or more — often not worth it for protection against a once-a-year outage.
For most businesses, the cost of full redundancy isn't worth the potential risk of a few hours of downtime once or twice a year. Instead, outages like these become a built-in part of the risk model — an accepted trade-off between uptime and operating cost.
My own VDI likely runs on a high-compute, multi-region setup, possibly through a provider like Citrix, which distributes workloads across multiple clouds or geographic zones. When routing failed for those 20 minutes, it probably just switched over to another data center automatically.
That's the difference between my VDI and many consumer apps: Citrix and similar enterprise systems are designed with multi-region active-active deployments, meaning they can keep running even if one region fails. But smaller companies can still hedge with cheaper strategies like multi-AZ deployments, caching, queued writes, or static fallback pages — ways to stay partially functional without doubling their infrastructure bill.
AWS outages like this aren't new. The 2017 S3 outage, the 2021 Kinesis failure, and the 2023 EC2 disruption all originated in the same US-EAST-1 region. Each time, it shows how much of the internet depends on a single point of failure.
Sometimes, it's not that companies don't know how to prevent downtime — it's that they simply can't justify the cost of being invincible.
]]>CodeMaster took me embarrassingly long to finish—years, in fact. The only reason it didn't take me longer is? AI.
AI has empowered people to chase their dreams. I'm one of them. I suddenly had access to all the answers I used to get stuck on. I already had two years of coding experience. People less skilled than me were using AI to ship applications. Why shouldn't I?
What was stopping me before was my lack of knowledge—I'd never built an app from scratch. But AI platformd like ChatGPT and Claude had all the knowledge of how to make applications successful. I used all the tools at my disposal because I decided: if I don't make this, if I don't finish it, no one will.
But to understand why CodeMaster mattered, you need to know where I was coming from.
I started coding in 2018 after an economics degree. I didn't know what path to take. This was during the coding bootcamp boom, and I got into a program for career changers—a chance to participate in a bootcamp and potentially get hired by their corporate sponsor.
At the end of the bootcamp, we had to present a full Angular application with a REST API. The bootcamp was Java-focused. We learned the basics and then had to demonstrate our skills. I struggled and didn't finish the project, but had to present what I had. They were not impressed, and I didn't get the position.
I still decided to apply to software development positions. I got a position but shorty after COVID broke our, and the project I got hired for was canceled. I worked the next two years in a software development role where I wasn't doing much development. I would get some tasks like fixing a React form or hooking up a new endpoint to our UI. But 75% of the work was data scraping and validation—not real coding. I kind of checked out. I wasn't an active participant in my own career.
Eventually, I ended up in a help desk position. That's when I realized I had to build something of my own.
I started applying for jobs but wouldn't hear back. Sometimes on applications you'll have an option to put your GitHub profile or portfolio. My GitHub wasn't consistent, and I had nothing in my portfolio. I wanted a well-paying job in my chosen field, and I wasn't doing everything to make that possible.
I thought about contributing to open-source projects. I completed 2 pull requests before realizing I didn't care about the projects I was working on. I was already selling 40 hours of my time working for money. I didn't want to exploit more of my time on work that didn't matter to me. I had a folder full of half-completed projects. I already had basic skills. I didn't need to follow another tutorial. I needed to build an application I cared about.
In my mind, having one app with real users on the Chrome Store would be worth more than all my half-finished projects. I could improve my GitHub profile through commits, and I would get proof for job applications and also for myself.
I needed a job, but more than that, I needed proof.
That's when I decided to build CodeMaster—a Chrome extension that helps developers master data structures and algorithms through spaced repetition and pattern-based learning. It integrates directly with LeetCode, adapting to your progress and reinforcing what you've learned.
But more than the product, what changed was me. For the first time, I wasn't giving up halfway.
That daily effort—showing up and working toward something that mattered to me—started to change things. I've always had high aspirations, just like a lot of people out there. I think the main difference between people who accomplish their dreams and the people who don't is that they don't run from the work.
CodeMaster is 95% done. I'm fixing the final bugs before launching on October 30th. For the first time, I'm not abandoning a project halfway. That alone has changed how I see myself—as a developer again.
And it helped me feel like a developer again.
In the next few posts, I'll share what I learned from shipping CodeMaster—from how I used AI to accelerate development to the lessons that finally helped me finish.
]]>