Staying Productive When Dependencies Blocked QA and Programming Work


Challenges of the Past Week

During this phase of production, my primary challenge was less about a broken system and more about timing. As quality assurance and an assistant programmer, much of my work depends on systems being available to test or modify. This week, several core files were actively checked out in Perforce while features were still being implemented. That meant I could not immediately step in to test changes or assist directly in code without risking conflicts or redundant work.

This kind of bottleneck matters because delays in testing can allow issues to pile up later, when fixes are more expensive and disruptive. From a player’s perspective, problems that go unnoticed early often surface as instability, inconsistent behavior, or last-minute cuts. Waiting without a plan would have slowed feedback and limited how useful I could be to the team during a critical setup period.

A snippet of the changelog that I largely formatted

How I Worked Through It

Rather than treating those blocks as downtime, I shifted my focus toward work that would strengthen production while the code caught up. I spent that time contributing to project documentation and planning conversations that would shape development going forward. Reviewing the design document, drafting changelogs, and helping clarify our prioritized feature list gave me a deeper understanding of the game’s intended scope and helped ensure that future testing would align with those goals.

That planning work also connected directly to another issue I had noticed earlier in the week, which was how quickly assets had been added to the project without much structure. By being involved in discussions about upcoming asset request sheets for art and audio, I helped reinforce a more deliberate approach that supports source control and keeps the project organized. This made it easier for me, in my QA role, to understand what content was expected and what was still placeholder. The team also worked to remove all the extra files that bloated the game size, potentially causing issues for the end user to allocate space to install the game.

The result was that I stayed productive without stepping on anyone else’s work, while also positioning myself to provide better testing and support once files became available again. When systems were ready, I was already familiar with the intended design and could jump in with context instead of catching up, or it would be easier and less confusing to review any added code. That continuity improves team efficiency and leads to a more polished experience for the end user.

A look into the Design Document

Get Ascending: Peaks Beyond