What working on a big team taught me
Full Stack Developer Co-op · London Computer Systems · Cincinnati, OH · Aug 2025 to Dec 2025
This was my first time working inside a large codebase I did not write, alongside a team of more than 50 engineers. Over the co-op I resolved 30 plus production tickets spanning bug fixes, feature work, and database updates, and the biggest thing I took away was not a framework. It was how a real engineering team operates.
The problem
Coming in, I had built plenty of my own projects, but I had never opened a codebase this large or worked on a team this size. The challenge was less about any single ticket and more about becoming productive in a system I did not design, on a team with its own rhythm and standards.
I needed to learn how to find my way around unfamiliar code, write changes other engineers would approve, and contribute steadily inside an Agile process without slowing anyone down.
What I built
- 1
Get productive in a large codebase
I learned to navigate a big Angular, C#/.NET, and SQL system I did not write, tracing features end to end and figuring out where a change belonged before touching anything. Reading code became as important as writing it.
- 2
Work to the team's standards
Through code reviews I learned to write changes that fit the team's conventions and to take feedback well. Reviewing and being reviewed taught me more about clean, maintainable code than any tutorial had.
- 3
Find the Agile rhythm
Sprint planning, standups, and steady delivery inside a 50 plus engineer team showed me how large efforts stay coordinated. I learned when to ask a good question instead of spinning my wheels, and how to own a ticket from investigation through review to production.
- 4
Debug real production issues
Investigating live production problems, often by pairing and peer debugging across the team, taught me to reason about systems I only partly understood and to communicate clearly while doing it.