Introduction

It's been about two to three weeks since my first project — one where I was involved in every phase from planning to verification — wrapped up after joining the company.

Maybe because it was my first real project, I faced a lot of challenges and felt many of my own shortcomings acutely. At the same time, it was a period where I learned an enormous amount.

Countless bugs, endless issues, a delayed schedule… I got thoroughly beaten up (figuratively), and I want to make sure I don't forget the lessons I learned from it all — even if writing this down feels a little embarrassing. 🫠

This post is, in a way, me publicly sharing the very first report card I received as a frontend developer. Think of it as both a confession and a letter of reflection.

Project Overview

To give a brief introduction: the project involved adding a major new feature to an existing product, and I was the sole frontend developer on the team. (This was less than three months after I had started as a junior frontend developer. 🫢)

Being a three-month junior handling frontend development solo was already a lot, but what made it even harder was the extremely tight timeline. We were given roughly four weeks total — covering planning, design, and development.

Our company holds a retrospective at the end of every project. My teammates filled in Keep, Problem, and Try sticky notes for me, and I'll be building on their feedback with my own thoughts below.

Keep

Positive attitude

My teammates highlighted my positive and proactive attitude as a Keep point. With the bold mindset of "I can do this!" that only a new hire can have, I pushed through the heavy workload without complaining.

Midway through the project, developers started questioning the actual value of the feature and wondering why we were building it at all — that kind of doubt could easily have tanked morale.

But I shifted my perspective: if I have to do it, I might as well enjoy it. I told myself to think of it as a high-quality side project I was getting paid for, and that mindset let me keep developing with genuine enthusiasm despite all the doubts about the spec. (I like the saying that those who smile through hard times are the true pros. ^^)

Actively reviewing planning and design

Not being afraid to voice new ideas

During the planning and design phases, I proposed improvements and flagged things that had been overlooked. Rather than passively accepting whatever was handed to me, I studied the details carefully and kept asking whether there was a better way.

For example, while reviewing the wireframes, I noticed that the main feature was buried several levels deep in the navigation. I suggested making it directly accessible from the feature's main page so users could get to the key functionality right away.

Problem

Insufficient developer testing

I think this one sentence sums up the entire Problem section — and it captures the biggest gap I felt between non-professional projects and real-world work.

I'll be honest, even if it's embarrassing: I had never even heard the term "developer testing" until near the end of this project, and I genuinely did not know that I was supposed to handle this many edge cases in my development. (If I had known, I truly would not have done it this way!)

Because of that, when QA started I was hit with a staggering volume of bug reports, and I remember being in a state of shock. Despite that shock, I'm honestly proud of myself for calmly working through every single ticket. 😂 (Keep it together!)

To use an analogy: imagine studying hard all night, then getting your exam back and seeing red ink absolutely everywhere. I think this might be the lowest grade I've ever received in my life. 😵

Try

More thorough self-testing

This experience made the area I need to improve crystal clear: test more, more, MORE thoroughly as I develop!

In this project I got things wrong because I simply didn't know better (using the exam analogy — these were questions I got wrong because I didn't know the material). I've now written more than enough "wrong answer notes" to fill a notebook, so my goal for the next project is to minimize bugs.

Now I feel like I actually know how deep and how carefully I need to look when developing! 😎

Self-directed and realistic schedule estimation

Did I overestimate myself? I thought I could get everything done within the initial timeline, but in the end the schedule simply wasn't physically feasible and development had to be extended.

I think the biggest reason was inexperience. No matter how many team projects I did during SSAFY, those experiences weren't nearly enough to accurately gauge my real-world capacity.

When it comes to schedules, I've learned that I need to be pessimistic rather than optimistic — and be objective about my own abilities. Fortunately this was a new feature with no existing customers, so there was no contractual delivery deadline. If there had been, it would have been a serious problem. 🤯

I do wish there had been a senior developer on this project who could have helped me set a realistic schedule from the start.

Closing

That's a wrap on my retrospective for my first real-world project. I felt even more of my own limitations than I expected… but I think if you're going to take your lumps, it's better to take them early. The reason I believe that: it means there's that much more room to grow going forward.

This was the first project where I could actually measure my own abilities after achieving my goal of becoming a frontend developer, so I had high hopes — and accordingly, I was pretty disappointed in myself.

Sharing this embarrassing report card despite the cringe is my way of putting my ambitions for future growth on the record. Because I want to prove in my next project that I've become a better developer than I am today.

I'll carry today's KPT with me and keep pushing to grow more and more as a developer.

Let's go!