4 Years and 4 Months at Zenerate and After (1)
2025. 02. 01.
After a long journey of 4 years and 4 months at Zenerate, I'm going back to school to finish my undergraduate degree. My extended leave of absence has finally run its course, and now I must truly attend classes. These days, I've been reflecting on my experience as a software engineer at a startup.
1. About working as a software engineer at a startup¶
If we trace back to the time when Zenerate didn't even have its name yet, when we were a small team conducting research on dividing dormitory buildings into multiple rooms, my connection with Zenerate spans just over 6 years. In January 2019, the CTO contacted me, saying my skill set would be a great fit for the project they were working on. This marked the beginning of my work, where I pondered how to structure the thousands of ways to divide a building and store it in a database and how to visualize this information in Grasshopper.
About a year later, as the research project's idea developed, the team became a startup, and in September 2020, after leaving a game company, I joined Zenerate. Knowing nothing about startups, I spent over 4 years growing and experiencing numerous things. My primary role was developing and maintaining backend services, including architectural design engine development. To elaborate, my work involved selecting the necessary technology stack for service development in ever-changing situations, sometimes finding and learning new technologies, determining how far we should improve the perfection of technology, deciding when the service should be operational, distributing tasks to team members, and ultimately implementing the service.
While working, I realized that solving problems isn't just about addressing what's in front of you, but about being able to define the problems themselves. And, perhaps inevitably, problem definition must occur within the context of the market before us - what we want to or need to do. No matter how brilliantly I could develop features, if the development period is too long and we miss the timing to capture users' attention, it's worthless from the company's perspective. Conversely, if we rashly tackle tasks without careful consideration, technical debt accumulates too quickly. When system expansion becomes inevitable, critical bugs emerge, making it difficult to meet new user needs. If users want a faster, higher-performance service, adopting a slightly niche but performance-guaranteed technology can make it hard to find collaborators and research materials. This could potentially impose an overly burdensome workload on the development team. Such workload reduces team flexibility, making new service development challenging and potentially slowing the company's growth. I'm unsure how many problems I've defined, solved, and redefined according to changing circumstances. Looking back, while this work wasn't easy, it was quite interesting.
I believe my 4 years at Zenerate were about exploring paths with no definitive right answers but certainly some wrong turns, navigating step by step through direct experience. I feel honored to have traversed these interesting, challenging, and surprising times alongside the various connections I made at Zenerate.