Perfected Imperfection: My 2025 Journey from Junior to Competent~ish Mid-Level Developer

We are currently 15% of the way through 2026 and I took a breaf from writing and posting content. The new year restarted the challenge to grow and share what I am learning. So here is my 2025 year-in-review.

Why I Do This: My 2025 Year-in-Review

So the trail version of 2026 has expired and we all back to it all over again. I should have done this in the later part of December last year like all the other developer EOY posts, well I am human and I just wanted to get away from it all. So here is my 2025 year-in-review, expect it to be a bit different from the rest. At DevOps Days 2025, a giant in the React and AI space asked me a simple question: “Why do you do this?” The honest answer? Because I needed to prove to myself that I could, and because no one was having this part of the tech conversation.

2025 was supposed to be the year I “became” a mid-level developer. Spoiler: that’s not how it works and I got some of the skills but not I don’t feel the competency. Surprise, surprise … there was no magical level-up moment. Instead, it was a year of building things that actually work, learning from things that broke, speaking/learning at conferences when I felt underqualified, and slowly proving—to myself—that is where I belong (yes, I still have imposter syndrome). So here’s my 2025 recap: the projects that taught me, the talks that pushed me, the community that supported me, and the mental shifts that stuck.

From General Attendee to Stronger Learner/Speaker

Caption: Snapshot from my presentation at Carolina Codes 2025.

If 2024 was about attending conferences and speaking at a few, 2025 was about stepping up to share what I was learning.

Carolina Codes 2025

Speaking at Carolina Codes in September was terrifying. Not “butterflies” nervous—legitimately “what am I doing here” terrified. My talk, “And It Was Written,” came from a personal place: I was struggling to document my own projects. The response to this talk surprised me. People thanked me for practical advice. One person said my framework “finally made documentation creation make sense.” That proved you don’t have to be an expert to help people—you just have to be a few steps ahead and willing to share what worked for you. I continued to network among other events after Carolina Codes. Each engagement taught me: preparation and showing is the antidote to imposter syndrome. When I knew my material cold—not because I was an expert but because I’d lived it—I could answer questions confidently.

Other Speaking Events

The momentum built through spring and fall. DevOpsDays Atlanta and Orlando Code Camp let me refine talks on civic hacking and demonstrated competency. March’s 200OK brought my first technical deep-dive: “Back to Basics” on JavaScript fundamentals, emphasizing mastery before framework adoption. Humbling, but it taught me to gauge audience needs better and it required me to do more research and preparation.

Fall found me hitting stride. Magnolia Conf evolved my side projects framework into “Negotiation is the Key…” The year closed with me teaching lightning talk creation at AJUG. Each venue delivered lessons: civic tech resonates across DevOps communities, regional conferences crave career-focused content, and honest personal frameworks connect when you share the struggles behind them.

Code That Counted

Caption: My github contributions for 2025

Shipped: The Projects I Can Show

I’ve shipped a couple projects and earned a certification that taught me different lessons about ownership and scale. I rebuilt my portfolio site with Astro 5 and Tailwind CSS, this was the first time I had to think beyond features—implementing view tracking with Supabase, configuring Microsoft Clarity analytics, and optimizing for both SEO and GEO. Every architectural decision, from content collection schemas to email service integration, was mine to make and live with. The digital garden, a Jekyll-based knowledge repository, challenged me differently (yes, I know it’s not the best right now ). Publishing interconnected notes as a static site meant wrestling with content structure, bidirectional linking, and remembering how to make Ke. The digital garden is less polished than the portfolio, but it’s real and it’s mine.

Discover Jackson, my hackathon project, taught me about working with third-party component libraries at scale. Integrating Kendo UI components, managing local storage for user favorites, and building responsive layouts under time pressure—these weren’t tutorial scenarios. I made calls about component composition and state management that I couldn’t take back. The FreeCodeCamp Data Visualization certification pushed me into unfamiliar territory with D3.js, data-driven interfaces and the importance of tooltips. Building interactive visualizations meant thinking about data transformation pipelines, SVG manipulation, and responsive chart rendering—skills that don’t come from reading documentation alone and swearing a few times.

Each project has code I wish I’d written differently. But they’re all live, they all work, and people actually use them. That progression from “following tutorials” to “making architectural decisions” feels like crossing into mid-level territory. I made mistakes. I refactored things I wish I’d gotten right the first time. But I shipped it, it works, and people are using it. That feels like a mid-level milestone.

Vue Mastering : Learning by Teaching

Caption: Learning in public—turning Vue topics courses into blog content and teaching what have learnt

My favorite project was working through Vue Mastery courses and turning what I learned into blog articles. I wasn’t an expert teaching beginners — I was a junior developer learning out loud. Here’s what I discovered: writing about something you just learned forces you to actually understand it. Creating “11 JavaScript Fundamentals for Vue Developers” meant really internalizing the fundamentals, not just copy-pasting code. The feedback loop is powerful. People read my posts, ask questions, and their questions reveal gaps in my understanding. I learn more, update my mental models, write better explanations. This series became popular not because I’m an expert, but because I’m learning alongside my readers. I also converted it into a talk an presented it at 200OK in Tulsa.

The Unsexy Stuff That Matters

I also shipped infrastructure work on my Astro blog: view counters (currently broken), Generative Engine Optimization (GEO), and portfolio refactoring. Not flashy, but they taught me that caring about the boring stuff separates developers who make things work from developers who make things work well.

How My Thinking Changed

Caption: The real growth—shifting from “thinking about it” to “make it work well”

The technical work was visible progress, but the real growth happened in how I think about software development, product architecture, product delivery and business value delivery. I’m also paying more attention to my health and well-being (somewhat), hobbies and longevity as a software professional. I’ve started diving into the policies and politics of the tech ecosystem (well, this needs sooo much work). Enough rambling, let’s break this down.

From “Make It Work” to “Make It Maintainable… or Decent-ish”

I started thinking beyond just shipping working code to understanding architectural patterns and their trade-offs. I’m not just reaching for Pinia or Nuxt because the tutorial said to—I’m evaluating whether my app’s complexity actually justifies the abstraction overhead. When does global state beat component composition with props? When does prop drilling become unmaintainable versus acceptable simplicity? Is the cognitive load of Nuxt’s conventions worth it for this project size? What am I learning, what else I need to learn and what level of competence am I at? That’s the developer mindset I’m cultivating: optimizing for maintainability, scalability, and developer experience, not just functionality … one piece at a time.

From Perfect to Production

I had side projects stuck at 60-80% done because I kept refactoring for perfection or waiting for the “ideal” architecture. 2025 taught me that shipped beats perfect, and production beats localhost. I learned to decompose projects into smaller, shippable increments—each one targeting specific skills I’m developing. I got good at understanding and writing tickets. This crystallized in my Kill List Framework, detailed in this article, which validates MVPs through defined success metrics. Bear in mind, my projects aim for demonstrated competence and portfolio depth. So as I ship, I’m gathering user feedback and tracking analytics. I can iterate based on real usage patterns instead of imagined edge cases.

From Stack Overflow to Collaborative Problem-Solving

Early on in my career, asking for help felt like exposing incompetence—yeah, transposing academic mindset to tech wasn’t a good idea. This year taught me that collaboration accelerates technical growth exponentially. Code reviews, pair programming, and architectural discussions—these are force multipliers and should be highly encouraged. It’s one of the best ways to level up, as teaching concepts reinforces understanding while exposing knowledge gaps. The best engineers aren’t the ones who memorize documentation—they’re the ones who leverage collective intelligence and contribute back to it. Still refining this, but the growth is somewhat tangible.

From Features to Systems Architecture… Thinking and Building

So I’ve been engineering software for the last 8+ years, spanning side projects and production systems. I’ve evolved from asking “does it work?” to “does it scale?” and “what are the trade-offs?” This is kinda jarring and occasionally leads to analysis paralysis when evaluating architectural decisions. I’m learning to balance implementation details with system design—thinking in terms of data flow, service boundaries/ separation of concerns, and error handling.

For me now, building projects means building out stuff that supports my frontend skills even thinking about the full stack implications. I am currently learning and working on a full-stack application, thus now I couldn’t just implement a booking form—I had to design for race conditions, implement optimistic locking, consider cache invalidation strategies, and plan for horizontal scaling. What happens with concurrent bookings? How do we handle distributed transactions? This systems thinking is still developing, but the architectural awareness fundamentally changes how I approach problems.

The Meats and Potatoes ~ Yes I like food

These shifts all point to the same evolution: moving from writing code that works to designing systems that scale. Junior developers focus on getting features shipped (been there). Mid-level developers—where I’m heading—focus on building resilient, composable systems with clear boundaries and thoughtful abstractions. That evolution, from syntax to systems, that’s what defined most of my 2025.

The technical work was visible progress, but the real growth happened in how I think about software development. Beyond just writing code, I evolved my approach to product development, business considerations, and the broader ecosystem. I’m also investing more intentionally in health, well-being, and longevity as a software professional. While I’ve started engaging with tech policy and politics (still a work in progress), the shifts below represent my biggest mindset transformations.

From “Make It Work” to “Make It Work Well”

I evolved from just building working code to understanding how the code works and why I make certain architectural choices. I’m no longer reaching for a state management library just because a tutorial suggested it—I’m evaluating whether my app’s complexity actually justifies the added abstraction. This is the mid-level developer mindset I’m cultivating: prioritizing quality, structure, and maintainability alongside functionality.

From Perfect to Shipped

My GitHub graveyard was full of side projects stuck at 60-80% completion, victims of perfectionism and procrastination. 2025 taught me that shipped beats perfect, and done beats shipped-someday. I codified this philosophy in my Kill List Framework, which helps validate ideas through demonstrated competence rather than imagined perfection. Now I ship early, gather feedback, and iterate based on real usage instead of hypothetical edge cases.

From Solo Struggle to Collaborative Growth

Early in my career, asking for help felt like admitting incompetence—a toxic carryover from traditional educational mindsets. 2025 heavily dismantled that belief. Collaboration isn’t just important; it’s fundamental to growth. Teaching what I learn reinforces my knowledge, while learning from others accelerates my progress. The best developers aren’t those who know everything—they’re the ones who know when to ask questions and how to synthesize insights from their community. Still a work in progress, but the shift is profound.

From Features to Systems Thinking

After 8+ years in software (including side projects and full-time work), I’ve shifted from asking “Does it work?” to “Does it scale?” This transition brings its own challenges—occasionally paralysis by analysis—but it’s essential for mature development.

Now when I build, I can’t just implement a booking form in isolation. I’m thinking: How does this integrate with our data model? What happens when two users book simultaneously? How will this perform under load? What are the failure modes? This systems thinking is still developing, but the awareness fundamentally changes how I approach every problem.

Each project now serves dual purposes: reinforcing technical skills while contributing to a larger architectural vision. It’s no longer about building features—it’s about building sustainable, interconnected systems.

The Meta-Lesson

These shifts share a common thread: moving from tactical execution to strategic thinking. Junior developers focus on making things work, as a. Mid-level developers (where I’m heading) focus on making things work well, together, and sustainably. That evolution—from code to craft—defined my 2025.

Real Talk: What’s Still Hard

Caption: The honest part—half-finished projects, imposter syndrome, and the learning overwhelm

Finishing What I Start

I gave a talk about completing projects, which is hilarious considering I have a sufficient number of half-finished projects on GitHub right now. The Kill List Framework helps, but frameworks don’t solve the fundamental problem: limited energy competing with full-time work. I’ve gotten better—breaking work into smaller pieces, being realistic about scope. But finishing side projects as a junior dev with a full-time job is still somewhat genuinely difficult if the projects aren’t properly scoped. It takes a bit of planning, a lot of willpower, some crying and a decent coffe habit.

The “What Should I Learn Next?” Overwhelm

The frontend ecosystem moves fast, well tech moves extremely fast. I constantly feel like I’m falling behind. Everyone says “go deep, not wide,” but when you’re job hunting, you feel pressure to know everything. So after a talk or three with a few mentors, I have been working on the following: go deep in the Vue ecosystem, get competent with TypeScript and fundamental JavaScript and taking the time to understand the fundamentals of software engineering. But I still have FOMO when I see exciting new tools, with experience however, I know not either get overwhelmed or chase the new shiny. I am also love by the “rule of three” ( it shpuld be atleast three years old, being used by three medium sized companies that I respect and mentioned by 3 other developers that I respect) when it comes to learning new things.

The “Am I Actually Any Good?” Question

Even after shipping the hackathon project and speaking at conferences, I still sometimes wonder if I’m actually good at this or just lucky. The difference this year is recognizing imposter syndrome for what it is instead of letting it paralyze me. Still feels weird some days though.

What I’m Focused On for 2026

Caption: Looking forward to the road ahead

- Actually Finish Projects ~ Based on Documentation : three projects to finish in Q1: a simpler boilerplate for isNerandoDoneYet that can be bootstrapped by other developers, a shipped version of a Vue based- greeting card generator and done ~ version portfolio. Done beats perfect.

- Keep Learning in Public : one blog post every two weeks … more , no matter how small it is. I have the problem of where I think my explanations may be not clear . But here is the plan: Document wins and failures. The failures teach more.

- Get Really Good at Vue + Tailwind CSS + JavaScript + TypeScript : Going really deep with this skillset as its my main toolset at work. While I may skim other stuff to keep up with the ecosystem, I’m going to focus on getting really good at these skills. The aim is to be able to apply these skills to any project I am working on, thus demonstrating competence. So the aim to complete books and courses that cover these skills, build a complex Vue 3 project and contribute to open source.

- Think Beyond Individual Features || Master My Current Role : Take the time to develop the habit of thinking one level above my current feature. So before any building is done, sketch connections, write user stories, testing strategies, etc. Ask all the questions like : “what breaks if this fails?” “what are the edge cases?” “what are the performance implications?” “what are the security implications?” “what are the accessibility implications?” “what are the legal implications?” “what are the business implications?” “what are the user experience implications?” The aim deepen my understanding, demonstrated competence and technical ability of my current role.

- Keep Helping Others Teaching forces better understanding. Keep being active in Vue/developer/frontend communities. Get the place of doing informal code review. Keep speaking at conferences and meetups. Find a open source project or three to contribute towards.

- Tinkering with AI based tools Whether we like it, AI based software tooling is here to stay. I want to keep tinkering with it and see where it takes me. I will be learning, building and documentating the experience.

The Truth About Leveling Up

Caption: No magical moment—just slowly becoming the developer I want to be

2025 taught me that leveling up isn’t about suddenly feeling confident one day. It’s about doing slightly harder things than you’re comfortable with, failing sometimes, learning from it, and gradually expanding what you’re capable of. The journey from junior to senior developer via mid-level isn’t a straight line. There’s no moment where someone says “congratulations, you’ve levelled now up now.” You just wake up one day and realize you can do things you couldn’t do a year ago or even a month ago.

I’m not “there” yet—wherever “there” is. But I’m further along than I was. And that’s what 2025 was about: making progress, even when it felt messy and uncertain. So here’s to 2025—a year of building, breaking, learning, and slowly becoming the software professional I want to be. And here’s to 2026 — where I keep going, keep learning, and keep shipping … more. Now if you’ll excuse me, I have some side projects to actually finish make work this time, this is my working mental model working towards.

---