Remote Teamwork.

Introduction

With all that’s going on in the world (US has now claimed the #1 position - go States go!), remote work posts are clawing for notice on all my feeds. Productivity tips, horror stories, and tutorials for a successful call.

Recently, I had a bit of a remote work scenario myself - with a game project. No, I didn’t take part in a game jam; it was a school project. For my business class, we were supposed to create a board game, but being the techy kid I am, my team decided to create a text-based real estate game instead. (It’s a private GH project - I’ll ask permission from my teammates before we release it and perhaps I shall update this post with a link.)

As we were working with a programming project, it was a lot easier for us to collaborate and produce something, and it’s been about two weeks since we started working on the project. We’re getting close to the release (and due) date, and it’s nearly bug-free!

Overall, I learned quite a bit from working with my peers, and I thought I’d share some of the introspections I gathered in this post.

(In other news - it’s my birthday, if you read this on the day it’s published. Give updoots now. I’m now slightly less smol - yay! :tada:)

Stay on the same page

Right off the bat, one of the issues we had was staying on the same page with implementation methods. We have a turn structure, and within that several methods like turn_next_turn, turn_choose, etc. These all need different parts of each available property, like price for some, a boolean if the property is rented, the value of the house on the property - the list goes on.

Something I think we didn’t do quite effectively enough was creating the property structure, and the turn structure together. Instead of assigning the subtasks and tackling each method separately while adding information to properties willy-nilly, we should have sat down together, and created a list structure. Element one would be the price, two would be the rent rate, three the lease length, and so on. We did end up refactoring, and rewriting some methods, but this time could have been spent bugfixing instead.

This is especially crucial for methods and sections of code where multiple people were interpreting the same values - making sure everyone was on the same page and understood what we were implementing was a key design point.

Have a central document

With games, usually there’ll be a GDD, but I don’t see (or personally implement, I’m guilty as well) a similar document often in the open source projects I navigate. Outlining user navigation structures, and how parts of code interact was a strength of our team.

Writing our ideas down on paper let us ask crucial questions and investigate the feasibility of each option, and make an educated decision on how to move forward. Even when not creating a new feature, it helped explain where key elements were, and let everyone know that these variables existed, ensuring that we didn’t have redundant objects.

A central document is also a great place to log bugs and issues, prioritize and brainstorm fixes, and create new features. It’s also a resource people can turn to for deciding what they’ll work on, and for assigning tasks to people. Instead of spreading across multiple platforms, I liked that we had one Google Doc for all our game information, and kept to Hangouts for communication.

If you back up the document with Git (or just add on in a log format), you can also look at what you’ve done.
Personally, I found that we didn’t need to designate one person as the secretary, but with larger teams, that might be useful. As a smaller group, we tracked issues we found, and discussion was always straightforward.

Communicate effectively

Working with a team is always different than working alone. You have to ensure that people understand what you’re doing, and that a task’s been claimed by one person. Lots of logistical admin work.

My ‘advice’, if you can call it that, would be to choose a chat app of some sort, and include that in your communication stack. We used Hangouts - it’s simple, is accessible right from Gmail, and is relatively distraction free. Also, calls!

Regarding messaging: I recently stumbled across some crosspost of this article by Cal Newport, explaining their method of email-writing. While novel-length messages are honestly a waste of time, I felt that some aspects of his essay could be adopted into my personal workflow.
Instead of firing off a quick message, I tried to provide links to the resources I used, and explain (if not in the message, in the comments) how I worked on the feature, which brings me to my next point.

Comment. Please.

I was the only native Pythonista in the project, with a mixture of C# and Java natives - along with one novice. As such, I ended up using some interesting features, like dictionaries, enumeration, and various libraries that might not have made intuitive sense to the others.

Sure, they could have found out by themselves what literal_eval() does, but adding a simple comment would have been enough.

While comments are ~unnecessary in personal projects~ indeed best practice and we all write them haha myself included, they’re really a core communication method, besides chat and call, that developers (myself included) should utilize to their fullest.

One thing our team did was even use features to ‘message’ each other, leaving notes like ‘what does this do?’ or ‘rename variables please’, or noting issues and things like that. It’s an effective built-in platform, and can be referenced in the document.

Take initiative and do your work

Our team worked as well as it did because we all did our work. While speedrunning your work and letting others take on difficult bits is tempting, please do your work.
Your teammates are relying on you to share your knowledge, and besides, figuring out difficult implementations is super rewarding. (Also, virtual human points!)

Meeting etiquette

Meetings are honestly one of the most important ‘syncing’ moments (at least for our team). We put together docs, went over important design points, and practised some of that effective communication.

Some tips for a good call: - Join on time (preferably even a couple minutes early to check technical problems out. Then again, don’t show up thirty minutes early while people aren’t doing anything, or the host is still debugging a last minute issue.) - Make sure your equipment works. Not everyone has the latest Audiotechnica or Sony setup, but even the standard laptop mic will do.

• Remove distractions. Yes, a Discord notification is super distracting - so close Discord. Your other team members are fully dedicating themselves to the meeting, so you should too. Try to limit browsing only to essential resources, your document, your group chat, and whatever code / issue you’re discussing.
• Mute while not talking. (Reduces the frequency of embarrassing conversations you’re having with family - try to avoid these altogether, but sometimes it happens.) Also reduces frequency of background noise interruptions, like ambulances, fire, etc.

One additional point I’d like to make is utilizing submeetings. While we had entire group meetings maybe once every two days, some of us who were collaborating on one feature would have shorter calls between them. That way, precious all-together time wouldn’t be wasted (especially as building and debugging a new feature with time pressure on call is very difficult). As well, it enables team members to get to know features more intimately, and collaborate better!

Currently

As a responsible, productive individual (top ten lies I like to tell myself every day), I did actually make good use of my time. I’ve decided to focus on Kenna - the site generator for teachers to generate online presences to update their students. As well, I’ve been dabbling with Javascript more, and Vue, so I’ve been trying to incorporate the Vue / JS stuff to automate the file generation. Justin’s has been a lesson in usability (check the issues if you dare), so I’ve learned to be more conscious of non-developers using my systems. I also have plans for (after KennaGen is finished) to recreate my SJAP in some sort of interactive website platform. It’s been a pretty good week!