Letting Go of the Solo Coder
19 Dec 2025Software Engineering 2 Reflection
Introduction
“The lone wolf dies, but the pack survives”, a quote from Ned Stark in the Game Of Thrones, became a quote that stood out to me after going through my Software Engineering 2 class. Throughout most of my life in school projects, I enjoyed working alone. I have always believed this was the best way because my consequences are only reflected upon my own actions. I felt self-centered because I didn’t want other people’s actions to affect my hard work and have unwanted outcomes. In my software engineering 2 class however, it made me change my perspective. In a team of 9 members, it made me realize that in my future career, I will be working in a large or even a larger group. Given the task of creating a web application to keep track of a pantry in a team of 9, I felt that there are way too many people in my team. Initially I wanted to let others lead instead and I just wanted to do whatever tasks that they gave me. I wanted to work alone and stay focused on my tasks instead of being bothered by others. This changed due to seeing how some of my members were lost and confused. I had to step out of my comfort zone and decided to help with ideas of features to add. I took the initiative to make a document and have people write down the outline on a google doc because at first we were just communicating our ideas without having a clear documentation on it.
The First Hurdle: Getting Started
Our first milestone was simply getting the project set up. We chose a tech stack including NEXT.JS, TypeScript, Bootstrap, PostgreSQL, Prisma and Playwright with the deployment on Heroku. Even this basic step was a challenge with nine people. Some of us struggled with having the right node versions and others struggled setting up our VScode. I helped some of my teammates with setting up their postgres and also being able to see the live database tables. We also set up continuous integration (CI) with ESLint and prettier to enforce code quality. Just getting the application to run on everyone’s machine felt like a small accomplishment. My initial thought was that this process was slowing us down, but I soon realized it was one of the most crucial steps. Without everyone being on the same page technically, we wouldn’t have been able to move forward as a team.
Facing Early Challenges
As we approached our first milestone deadline, the real pressure began. We needed to have something presentable. Merge conflicts started popping up frequently with our home page and sign in page due to styling and layout differences. Additionally our playwright tests would fail in CI, blocking our pull requests. ESLint errors were always there, but reviewing pull requests helped others fix test failures and troubleshooting CI pipelines. I learned that in a team, your progress is only as fast as the slowest blocker. If someone’s tests were failing, it delayed everyone. I couldn’t just focus on my own features, I had to make sure the team’s pipeline was healthy. This was my first lesson in collective responsibility.
The Middle Struggle: Communication and Clarity
After the initial setup, we hit a few progress roadblocks. We didn’t have a clear, shared understanding of what features we were building. We initially had stories setup in github but we lost track of our issue tickets and overtime, we stopped using user stories. Ideas contradicted each other in meetings but we were still able to find middle ground. Some ideas that contradicted each other included features like having different pages for a catalog of items or not. Additionally, our database architecture was ambiguous, which led to confusion and became prone to bugs when writing queries and APIs. CI rules also felt too strict, often failing builds for minor formatting issues which in turn slowed us down. Deployment errors and database connection issues also became common as multiple people would be touching the same database schema. Motivation dipped, weekly meetings felt unproductive, and communication between some members faded. During this period, I shifted my focus. I started spending more time on design discussions and database planning. I would discuss with some of my members that had time about the database planning. I tried sketching out database relationships and also some rough features and pages. I saw that coding was only part of the job, the bigger task was aligning nine different minds.
The Final Push: Adaptation and Simplification
Towards the end of the project, time was running out. We faced last-minute CI errors and deployment failures that the CI was unable to cover. It became clear that we had over-scoped. We made the tough decision to remove some complex features, like the Google Image search feature. I pivoted to a simpler and direct feature where I can find products from an open source grocery catalog item and parse them into the catalog which included the product image, name, and also categories.. This made it so that the user doesn’t have to create every single grocery item in the catalog and instead, a simple query through a grocery API would find the item. Additionally, I made it simpler to add products to a shopping list by having a modal of the catalog open in the shopping list modal instead of having a whole different catalog page. There were many features that I wanted to add such as having a user upload a photo of a pantry and use AI/computer vision to automatically parse into the pantry or make a list of what’s in the pantry.In software engineering, this was a crucial lesson to learn that sometimes you must abandon the “perfect feature for the “good enough” one that actually ships. Letting go of my personal investment in certain code was difficult, but it was the right call for the team.
Reflection as a Software Engineer
Looking back, my coding experience was a mix of pride and frustration. I was able to get features out, but sometimes at the cost of clean code. Near deadlines, I would “vibe code” my way through causing a lot of spaghetti code just to push something out. I learned the importance of maintaining code quality even under pressure. My attempt to implement a complex feature of the Google Image Search engine taught me about time management and scoping. I also learned the value of a good API design and routing through trial and error. Most importantly, I saw that writing code is only one piece. Ensuring it integrates, passes tests, and deploys successfully is where the real engineering happens.
Reflection as a Team Member
As a team member, I grew in my ability to communicate. I learned to explain my technical thoughts clearly and listen to others. I saw that helping a teammate debug an issue wasn’t a distraction, it was an investment in the team’s success and prevention of future greater problems. I believe that if I ever had to do this project alone, I would have failed. I wouldn’t have been able to figure out the CI and ESLint errors on my own and also be able to successfully deploy the site. The database schema would have been messy, and the test coverage would have been poor. The project succeeded because we pooled our knowledge.
Conclusion: The Pack Survives
This class changed my understanding of what it means to be a software engineer. It’s not just about being the best solo coder. It’s about being a reliable, communicative, and supportive member of a pack. The lone wolf, the version of me that wanted to work in isolation, could not have been able to build this web app. The pack, with all its chaos and compromise is what’s able to build our project. I learned to value documentation, clear communication, and collective problem-solving over individual brilliance. Moving forward, I carry this lesson with me: in software, as in life, we survive and thrive not alone, but together.