Scio Spotlight: Talking about passion, projects and videogame development with Pedro Ramírez
Written by: Scio Team
Introduction: Why Side Projects Still Matter in Modern Engineering
Across the software industry, leaders often talk about frameworks, delivery velocity, and architecture. Yet one of the most powerful indicators of engineering maturity is something far simpler, something that rarely appears in dashboards or performance reviews, and something that still separates great engineers from average ones. It is the ability to build things outside work, driven only by curiosity, experimentation, and genuine interest. For many developers, software is both a profession and a playground. The workday revolves around sprint planning, backlog refinement, and delivering features under pressure. But outside of those constraints, there is an entirely different space where creativity unfolds. Side projects give engineers room to explore new technologies, test ideas without bureaucracy, sharpen their skills, and learn in a way that cannot be replicated inside a production environment. Some people contribute to open-source projects. Others tinker with automation scripts or dive into new languages. And some take on challenges that stretch far beyond their comfort zone. This is where today’s story comes in. In this Scio Spotlight, we talk with Pedro Ramírez, Chief Architect at Scio, about a side project that required equal parts discipline, curiosity, and pure passion. Years ago, Pedro set out to build something he had never built before. Not an API. Not a web interface. Not a business application. A full videogame, designed, coded, optimized, published, and shipped to real users. The project became FlyFlyFly, an endless runner released on mobile and still available on the Microsoft Store today. The result was more than a finished product. It became a source of learning, a bridge between craft and creativity, and even an unexpected advantage later in his career. This is the story of what he built, what it taught him, and why leaders should care about what their engineers build when no one is telling them to.
Section 1: When Curiosity Turns Into Craft, and Craft Turns Into Growth
One of the most common misconceptions in engineering leadership is the idea that side projects are distractions. In reality, the opposite is often true. Engineers who experiment outside their paid responsibilities bring sharper instincts, broader perspectives, and more resilient problem-solving skills into their daily work. For Pedro, this happened almost by accident. “Like many people, I assumed building a small mobile game would be straightforward,” he recalls. “You have game engines, libraries, and enough tutorials online to fill a lifetime. It sounded simple in theory.” It didn’t take long for reality to adjust those expectations. FlyFlyFly seemed small enough to build quickly. But the moment Pedro began prototyping, he realized how different game development is from the typical enterprise or product work most software engineers do. Optimization matters in ways that corporate systems never demand. Memory usage becomes critical. Framerate consistency becomes non-negotiable. Visual assets, performance tuning, collision detection, user input handling, and device compatibility all become part of the same equation. “You suddenly discover how little room you have,” Pedro says. “You try to run something on a slightly older device, and it forces you to rethink the entire way you’re handling resources. You end up debugging physics behavior one minute and reworking asset compression the next.” This level of constraint is rarely present in everyday engineering roles, which is precisely what makes the experience invaluable. It forces engineers to think beyond abstractions, beyond frameworks, and beyond library convenience. It demands an understanding of how systems behave when everything needs to run smoothly and consistently under real, user-facing pressure. Side projects like this sharpen instincts. Pedro didn’t simply build a game, he built an operating environment for himself where learning was unavoidable. And in the process, he developed a deeper sense of how software behaves in the wild.
Section 2: The Unexpected Complexity Behind Building a Game From Scratch
Game development is a surprisingly multidimensional craft. Even small games require a blend of systems thinking, creative design, and user experience intuition. For an engineer accustomed to building business software, it can feel like stepping into an entirely different discipline. “You’re not just writing code,” Pedro explains. “You’re designing the interface, creating graphics, deciding how the character moves, balancing speed, difficulty, and even color choices. You become a full team of specialists inside one person.” Along the way, he discovered aspects of development that traditional roles rarely expose. Resource management, for example, became one of the biggest challenges. With limited memory and varying device capabilities, every asset had to be optimized and every decision measured. Another challenge was balancing gameplay. This required experimentation, iteration, and a willingness to rebuild entire components when a mechanic felt too slow, too difficult, or simply not fun. Pedro also had to learn how to market the game, prepare it for digital storefronts, and handle support once it launched. This led to one of the most surprising lessons of the entire journey. While working at Amazon at the time, he realized that his employment contract raised concerns about intellectual property ownership. “It technically made the game their property,” he says. “It created a conflict that made it difficult to maintain or grow the game later.” It was an unexpected but meaningful education in the importance of understanding IP agreements, licensing, and ownership terms, something many engineers overlook until it becomes a problem. All of this made FlyFlyFly more than a hobby. It was a masterclass in end-to-end product development. Pedro walked through every stage, from ideation to launch, while learning skills that would later prove useful in real client engagements and leadership roles. For engineering leaders, this is an important reminder. The most valuable learning often comes from unstructured, voluntary work. Engineers who push themselves through unfamiliar territory develop adaptability, versatility, and decision-making skills that are hard to teach in a classroom or through corporate training.
Section 3: When Passion Projects Influence Real Work and Real Opportunities
Years after launching FlyFlyFly, an interesting opportunity appeared at Scio. A client was exploring the development of an RPG-style game similar to classic turn-based titles like Final Fantasy. They needed a technical lead who understood game mechanics, constraints, and the demands of building an experience rather than a business workflow. Pedro fit that profile immediately. “I was put in charge of the project because of my experience with FlyFlyFly,” he says. “Even though our client paused development later for budget reasons, the work we did and the trust they placed in us was a direct outcome of that personal project.” It’s a perfect example of how passion-driven work can influence professional opportunities in unexpected ways. Side projects demonstrate initiative. They reveal a person’s curiosity, drive, and willingness to explore. They also show how an engineer behaves when there is no roadmap, no product manager, and no established process guiding the way. This is why many leaders value them. They expose intrinsic motivation. Side projects also shape long-term leadership potential. Pedro’s experience gave him a first-hand look at navigating ambiguity, solving unstructured problems, and making decisions without a safety net. These are the same qualities that help teams move through complex transitions and high-stakes architectural decisions. For companies evaluating nearshore partners or expanding engineering teams, this is a meaningful reminder: experience is not just measured in years. It is measured in how people use their time, how they push themselves, and how they build when no one is assigning the work. Passion projects reveal patterns that traditional résumés rarely show. At Scio, these patterns often turn into leadership opportunities because they indicate the kind of engineer who learns continuously, adapts quickly, and sees beyond immediate deliverables.Comparison Module: What Side Projects Build That Day Jobs Rarely Do
Capability |
Built in the Day Job |
Strengthened Through Side Projects |
|---|---|---|
| Ownership mindset | Sometimes | Always |
| Multidisciplinary learning | Limited | Required |
| Experimentation freedom | Often constrained | Unlimited |
| Resource optimization | Only when needed | Constant |
| User experience intuition | Varies by role | Essential |
| Ability to self-direct | Depends on structure | Core skill |
Section 4: The Human Side of Building Something for Yourself
Beyond the professional value, there is a deeply human side to building something outside work. When engineers create something purely for fun, they reconnect with the part of themselves that first led them into the industry. The sense of discovery. The desire to understand how things work. The excitement of solving a problem on your own terms. For Pedro, this aspect became even more meaningful because he shared the experience with his son. “We figured out the mechanics together,” he says. “It was fun not only as a developer, but as a dad.” This matters more than most leaders realize. Software development has always been a mix of logic and imagination. Passion fuels both. Engineers who maintain that spark stay curious longer, resist burnout more effectively, and handle ambiguity with greater patience. Passion does not replace hard work, but it lifts it. As Pedro explains, “When you enjoy the work, the hard parts feel different. You still deal with challenges, but they don’t drain you the same way.” This distinction is crucial, especially in technical leadership. Passion generates endurance. Endurance supports mastery. Mastery accelerates growth and increases the quality of decisions engineers make under pressure. Projects like FlyFlyFly become long-term confidence builders. They remind engineers that they can create, solve, and learn even in unfamiliar territory. That mindset strengthens entire teams, especially in organizations where innovation, experimentation, and continuous learning define success.Conclusion: A Story About a Game, or a Story About Growth?
FlyFlyFly is still available in the Microsoft Store. But the real story lives in the journey of building it, not just the outcome. Pedro learned how to navigate new disciplines. He improved his technical instincts. He gained exposure to product thinking. He discovered unexpected IP challenges. He opened doors to new opportunities at Scio. And he reconnected with the creative spark that drives so many engineers into the field. Every engineering leader knows that great teams are built from people who care about their craft. Side projects help nurture that care. They create environments where engineers push themselves, experiment without fear, and grow in ways formal training rarely achieves. At Scio, we see these qualities often. Our teams combine strong fundamentals with curiosity, creativity, and a constant drive to learn. It is part of what makes nearshore collaboration so effective when the partner is aligned with your culture, expectations, and technical depth. If you’re looking for engineering teams that bring this mindset into your organization, Scio is here to help.FAQ
-
Yes. Side projects push engineers into unfamiliar territory where they must self-direct, experiment, and troubleshoot new kinds of problems. This sharpens instincts and often accelerates professional growth.
-
Not necessarily. But leaders can create psychological space for engineers to explore ideas. This often leads to innovation, better retention, and more engaged teams.
-
Absolutely. Teams with curiosity-driven engineers tend to adapt faster, communicate more effectively, and bring stronger problem-solving skills to client work.
-
This is where clarity matters. Engineers should understand their employment contracts and IP clauses before publishing or commercializing personal work.
But that is the rub. We’re examining a scenario where they need to extend themselves into new technologies and possibly change their operations significantly. And because we’re assuming their teams are informal, separate silos – we’re also assuming they know about the higher efficiencies they could achieve if they began to shift to a DevOps methodology but – again, like our second scenario, they have existing customers and products/services in the field to maintain and support. Like most companies in this situation, their backlog of feature requests for their existing software is just what they can handle at the moment. Adding another layer of work would just mean something would have to give. An outsourced development team, in this case, makes sense and this organization is likely to have customer-facing product development well-in-hand. But, what they don’t have is a scalable organization to match the importance of the project and a broad understanding of new technologies and architectures they need to consider to streamline their organization.