Testing is a main stress right now. We've been trying to get a multiplayer testing session set up with our small army of external testers, but during our first session of the semester, we discovered some integral issues. First off, our testing manager cannot host a dedicated server, so he would have to have someone else host. Second, I've noticed that many people on the team don't really test their own work before attempting to submit a code review, and even before/after a merge to develop. While we can fix the first issue fairly easily just by communicating well, and possibly working alongside Champlain to host a central, more permanent server, the second issue, however, is much more concerning.
Everyone needs to test their own work: that's how it needs to work if we want to be efficient. So far, not many have been doing that. We've even seen a few people on the front-end team finding themselves completely unable to test because they couldn't spawn in... they didn't have a spawn point in their levels. 2 people didn't even have the repository set up, even though there is an instructional document, and they were supposed to do this during the first week. As the person who tends to manage the state of the repository this is severely concerning, because that means we have people pushing directly to develop, mainly pushing bugs and overwrites. This is why we had so many bugs on our first day of testing. Why aren't they asking questions? How did we as leads fail to find these things?
I think I, personally, would have been able to notice the miscommunication more if the level designers had been using the repository as they were supposed to be. We would have noticed continuous commits on develop that weren't merged from a feature branch, and thus we would have caught it early. To resolve the issue, we as leads need to initiate communications with them more often, rather than expecting them to come to us, since that didn't work. We'll likely need to check on their usage of the repository, and have frequent check-ins to review work, and dig out questions they may have, but are holding back.
On a positive note, a few other people on the back-end who were not testing their work have responded super, super well to feedback addressing it, and they're now doing fantastic work! Additionally, more people have been stepping up and volunteering to help me out with the multitude of networking bugs, and even implementing their own networked features using my work as a base! I didn't really expect people to do that, because network programming is quite difficult, and has a steep learning curve. It's most certainly welcome and appreciated.
Time for a quick personal review. I feel like I'm doing a pretty good job as a lead for the back-end team. I'm really trying to teach Unreal (and networking/programming practices) as best as I can, using code review sessions to do so. Sometimes I'll hop into workspace voice chats with people to do some debugging, and use that time to help with Unreal knowledge transfer. I'm also still able to do my work as a network programmer, because Ben is able to take on some of the lead responsibilities as well. I think I need to improve my levels of communication with Colton though. He spends most of his time with the front-end leads, since he needs to match Alex's art style, and ensure they know how to use his shaders and materials; however, he's having quite a bit of trouble just getting it all set up and working on the back-end code. I really can't take on more programming work, but I can rubber-duck for him, and help out debugging since my secondary specialization is Graphics. I also just want to up my communication with the front-end team in general, regarding our recent issues. Another thing I really need to work on is the classic engineer issue: as a lead, I cannot fix everything, but also as an engineer, I want to fix everything. I need to stop going after so many bugs, and rely on my team to handle more of them so that I can focus on getting our networking into a playable, reliable state.
Comments