Victor and I have been playing board games for the better part of the last decade; we’ve also spent that decade moving and living in different cities, so we’ve both seen gaming groups come and go. I’ve started to notice patterns (more specifically, anti-patterns) that commonly emerge as a result of player miscommunication, game misunderstandings, and general bad game design.

We picked five such anti-patterns and I will summarize them (with links) below. I hope you find them interesting!

The entire discussion series as a playlist can be found here.

1. Poor game categorization leading to mismatched expectations

Have you ever played a game, loved it, wanted to find other games similar to it, and struggled? Even after doing your research and reading reviews, I’d often buy a new game, go through a couple plays, and find that something feels “off”: it didn’t really capture the elements of the old game that I was looking for. Board games are so interactive and complex that its hard to categorize them without overgeneralizing. Unfortunately, this is a problem that harms board game discovery and understanding, without a clear solution.

Key Points

• We don’t have a good vocabulary for describing and categorizing board games.
• The board game community suffers from overly broad descriptors such as “Euro” and “Ameritrash”, which have completely lost their meaning.
• This makes recommending new games to friends and deciding what to play difficult.
• People relate differently to games based on their interaction style, their mechanics, their weight, their theme, etc.

Episode 1 - Board games are poorly classified and this hurts outreach

2. Cooperative board games

Cooperative board games sound nice: everybody plays together, everybody succeeds together, yay! In practice, this can be much more painful as shared control and responsibility of the game cause friction. This is especially troublesome when a skill/experience disparity exists, causing what is known as the alpha gamer or the quarterbacking problem.

Key Points

• The alpha gamer (aka quarterbacking) problem exists when one player dominates the cooperative game, essentially robbing their teammates of the experience.
• A difficult tradeoff emerges for the alpha gamer: purposely play sub-optimally or be labelled as the jerk?
• To prevent this, the best cooperative board games include asymmetric communication or information.

Episode 2 - Cooperative board game experiences are hard to do well

3. Analysis paralysis and blame

For more complex board games, players may often take (what seems to be) excessively long turns, causing frustration for the other players. Players often want to play optimally enough that the challenge of the game is genuine, but if a slow player starts playing very poorly due to social pressure, the game is already compromised. While it’s easy to blame the player, I’ve found that long turns are often the result of other factors, mostly involving game mechanics.

Key Points

• The typical solution to AP is often either “think faster” or “learn the strategy faster”. I think this is unhelpful and gatekeeps the hobby.
• Game mechanics play a large role in AP. Some examples include: too much information on the board, volatile game states, and a high degree of importance per move.
• It is in every game group’s interest to mitigate AP; reducing the social pressure around AP is the best strategy.

Episode 3 - Analysis paralysis is not the player’s fault

4. Negative reactions to “kingmaking” and collusion

If you’ve ever played the Settlers of Catan, you’ve probably seen this happen. A player jumps out to an early lead, comes close to winning, but the rest of the table colludes, refuses to make trades with the leader player, and they ultimately lose. This is often met with anger from the player who was leading, but I don’t think this is a negative outcome.

Key Points

• For many, many board games, kingmaking is an expected part of the design. When games have an innate amount of conflict built into them, social capital plays a part, which naturally lends to kingmaking.
• Even in low conflict games, I think opportunities for lead changes are important to keep the game interesting.
• Ultimately, the question comes down to the player’s values when in a losing position. What is the value of a win when faced with other, more meta objectives?

Episode 4 - Kingmaking isn’t really a problem

5. Failing to lean into the tabletop medium

Tabletop board games are constrained by a very obvious requirement: the game needs to fit on and successfully operate on a table. I feel that many board games focus too much on game mechanics and strategic design, and not enough on the tabletop experience itself.

Key Points

• Some games involve a high degree of overhead: shuffling cards, moving components around, etc. This is generally mentally uninteresting and doesn’t add value to the experience.
• Rule enforcement is a major difference. In the physical medium it is up to the players to enforce rules themselves, yet some game mechanics make rule enforcement more difficult.
• Conveying information to and amongst players is more difficult in person. Board games don’t benefit from interactive UIs or gamelogs, and game design should optimize for information signalling.

Episode 5 - Good game design is not necessarily good board game design

I’ve seen Philip Guo summarize his view on the differences between pursuing a CS PhD and going into industry in a (now deleted) talk recording, and it stuck with me so much that I think I can still now paraphrase its concept. Working on any major innovative project incorporates three major areas: (1) design, (2) engineering and (3) marketing. In industry, you’re assigned to a team that focuses primarily on one of these areas. In a PhD, you’re forced to constantly shift your time and thinking between all three.

Like any generalizing thought, this won’t be entirely accurate. But it’s a useful enough way to think about the role of a PhD student, so let’s go one level deeper and discuss the ways in which PhD students wear many hats.

Design involves collecting information from the world, finding the overlap between observed opportunities and capabilities, and creating a compelling solution in that space. In practice, this involves reading research papers, attending talks, discussing ideas with your advisor/other researchers, and writing many, many pages of notes. I’ve noticed that this is the part of research that many early stage PhD students struggle the most with. I can think of several reasons why:

• Novel design is not a skill that most CS/Engineering undergraduate programs train. In most course projects or even summer research internships, a well-scoped, safe problem is presented to you, with clear constraints and requirements.
• Because this can be very difficult, many PhD advisors protect their students by handholding their students through this process and handing them well-developed research ideas. A common starter project in a PhD program involves an eager first year PhD student hopping onto an established senior PhD’s project. At this point, the project is likely quite mature, and the first year student gets the undergraduate intern experience.
• Working actively on design doesn’t produce measurable progress. While ultimately useful in the long run, your advisor might be displeased if you told them you spent several weeks “thinking really hard about a problem”. The compulsion to write code or run experiments wins out here.

I am by no means an expert at this, but maybe I’ll write more about the research design process in the future, since it seems to be in demand. I’ll just say this: if you’re an early stage PhD student and you don’t have a place where you regularly note your thoughts and ideas, start now.

Engineering is fairly straightforward and is quite similar to what most of your peers in industry are doing now. This usually involves building a proof-of-concept that is relevant to your research idea or writing code to execute convincing experiments on that proof-of-concept. Unlike industry, the overall goals are slightly different here; research code needs to work well enough to sell your research idea. It doesn’t matter much if your code fails on certain edge cases, or wouldn’t scale to a production-level environment. Unless releasing research code is a planned contribution of your work, tests and documentation are also often overlooked. Because of this, there is a bit of a stigma surrounding PhD graduates who ultimately decide to enter industry; they are thought of to write low quality code, especially when compared to software engineers who spent the same amount of time in industry.

Marketing is the step of convincing external stakeholders that your solution is relevant, novel and of high quality. Research involves tying supporting evidence to research claims; marketing is when you convince stakeholders that you’ve properly done so. In practice, this involves writing research papers, preparing and giving research talks and more informally, pitching your ideas to colleagues. Since claims are so tightly tied to a project’s pitch, I’d also be inclined to say that experiment design falls here too. This is an often overlooked part of the CS PhD, but like it or not, spending 5+ years in research will build your writing and speaking skills tremendously.

For a successful, end-to-end research project, a CS PhD student will likely invest several months on each areas. It’s also rare that work in each area is performed sequentially, especially when considering the likelihood of paper rejections. A paper can be rejected for inadequacies in any of the above areas, forcing you to loop back and reconsider its design, engineering or marketing.

Note: My MSc advisor Ivan Beschastnikh gave a talk for EuroSys2020 that touches on the research process and how it relates to rejection. See the first 15 slides of this talk.

Closing. So, let’s revisit. What does an average day look like for me? The cliche, cop-out answer is that there is no “average” day for me. It mostly depends on what state my projects are in. I personally find it easier and more refreshing to work on multiple projects at once, so sometimes I’ll be editing the paper for one project, while writing code and reading papers for another. Because of this, most of my days are fairly dynamic and open; I will personally spend two hour blocks shifting between any of the above tasks at a time. Of course, this doesn’t even include the typical coursework or TA requirements that many PhD programs also have, which also add a lot of context switching.

Parting thoughts and advice

(1) It’s important not to overlook any of the three major research areas by simply classifying them as “necessary evils”. I’ve personally either been involved with or closely observed research projects that have completely sunk due to failures in each of these areas:

• A well executed idea is made obsolete because another piece of unnoticed work has or is clearly able to solve the problem in a strictly better way. There is almost no path forward in this state.
• The code for a project is in such a bad state that additional experiments can’t be executed and desired features can’t be implemented. Costly engineering decisions were made early in the project and, instead of fixing them, the team is better off starting from scratch.
• A novel idea with solid implementation is ultimately presented in the wrong way, and the corresponding research community is unconvinced. For whatever reason, the project gets tunnel vision and attached to this pitch, and the work is perpetually rejected.

(2) If you are an early-stage PhD student I think there is value in asking yourself some of the following questions:

• What parts of the research process am I currently more/less comfortable with?
• What parts of the research process do I expect my advisor to help me the most with? Are they currently doing that?
• What parts of the research process is my advisor helping me too much with? Could I stand to learn and grow more if things were done differently?

(3) I’ve recently had a friend remark that “PhD graduates make great entrepreneurs”. There are a lot of factors at play here so I’m still not sure if we actually have a noticeable advantage over our peers in industry. But, like PhD students, entrepreneurs wear many hats, also often at once. After one spends several years working in this way, it’s easy to see why this would be an easy transition to make.

Thanks to Alejandro Cuevas for some helpful feedback on this post.

I’m still not entirely sure what message I want to get across — but I suspect that this post might provide value for three different groups of readers:

• Friends and family who want to know more about my life (I really appreciate you!!)
• Any prospective student curious about the Computer Science MSc at UBC, the Systopia lab, or life with my MSc advisor Ivan Beschastnikh.
• Anyone at all who is considering the MSc vs PhD vs industry question, and wants one example of what this path could look like. Surprisingly, I have had multiple people recently ask me for advice in this specific topic.

I hope that catering to these three audiences simultaneously doesn’t dilute the meaning in this post too much. We shall see.

This post was heavily inspired by Jean Yang’s What My PhD Was Like and Philip Guo’s The PhD Grind. Once I finish my PhD, I hope to write something equally as informative and substantial.

A short preamble

Just in case you aren’t aware, not all master’s degrees in CS are made the same. This is especially true in CS, where many schools in the USA offer course-based master’s degrees in computer science. These programs have a relatively small focus on research progress and emphasize course and project work a great deal. At UBC (and at many other Canadian universities), the vast majority of students do a research-based master’s. The UBC model differs from the typical US model in the following ways:

• Like PhD students, all MSc students are funded. This is usually through a research advisor’s grant, and sometimes through a TA fellowship.
• At UBC, the program required six graduate level courses and a research thesis. The thesis is expected to be a year’s worth of work, and is roughly equivalent to a first-author conference paper submission.
• It is quite rare for undergraduates to enter directly at the PhD level, and instead they will do a master’s first before potentially transitioning into a PhD.
• Some master’s students start the program without a committed research advisor and are expected to find one after their first year. I was one of these cases.

Alright, that’s enough context for now. Here is the story of my master’s degree, told over 7 school semesters.

Fall 2016

Fresh off of my undergraduate degree and two months of backpacking across Europe and Asia, I came to Vancouver energized, optimistic and completely clueless. In hopes of finding a research advisor, I told every student/professor that I met that I was “broadly interested in machine learning”, without realizing that >50% of my incoming cohort had the same idea. On the first day of my orientation, one of the PhD students in the ML lab tells me that the chance of an unknown, unfunded student joining their lab is virtually zero.

Nevertheless, I pushed forward; I found any ML-adjacent professor I could and sent them cold emails asking for meetings. Every single one of these emails was ignored or forgotten. The rest of my mental energy and time this semester was spent completely on three graduate courses. In one of these courses, Ivan’s distributed systems course, the entire course consisted of reading, reviewing, and discussing papers everyday in class; I had never taken a course like this before and was both intimidated and excited by it.

Once I land back in Toronto to visit my family over the winter holidays, Ivan sends me an email, asking if I would consider working with him as his student. The prospect sounds exciting but I know very little about distributed systems which scares me.

Winter 2017

After spending the winter holidays considering my one-and-only option, I meet with Ivan in the first week of January and agree to be his student. I don’t believe I’m exaggerating when I say that, as of the writing of this post (early 2021), this has turned out to be the single best decision I have made in my career. Despite formally agreeing to be Ivan’s student, I didn’t “actively” do much research in my first term with Ivan. I wasn’t writing any code or focusing on any single research project.

Looking back, I really grew in two ways throughout this term. The first is that I was really encouraged by Ivan to build my research taste: every week I read a few papers, took notes on them, and discussed my thoughts with Ivan. Our lab also hosted a weekly reading group that featured lively discussion about recent papers published in top conferences. To anyone in CS grad school who intends to be a creator: don’t underestimate the value of building your taste (this has been best said by Ira Glass).

Secondly, this was the term in which I really started to get more comfortable at UBC socially. In addition to forming a community with my research labmates, I really began to connect with the wider CS department as a whole. The culture within CS at UBC is phenomenal; every week the graduate students in the CS department would host tea, bar nights, board game nights, and a student-run casual lecture series. As grad school continued, these events and friend groups kept me sane as things got tougher in the coming months.

Summer 2017

In April of 2017, Google published a blog post introducing federated learning: the topic that would end up being the basis of my research for the next 2 years. On paper, this was a perfect topic: federated learning was a novel method for distributed machine learning (lots of new and unsolved problems), and was backed by one of the biggest tech companies in the world (wasn’t going away). It also helped incredibly that federated learning was a perfect fit at the intersection of my and Ivan’s interests.

This was the first term in which I did research full-time, with no other course or TA obligations. Initially, my project was to support a peer-to-peer version of federated learning, complete with data privacy and security. As the summer progresses, we add Tor onion routing and differential privacy to the system, and we name the project TorMentor. The summer is a lovely time, and work is not very stressful. I find an ultimate frisbee team, go on several classic Vancouver-area hikes, and end up having a pretty great few months.

Fall 2017

After working on TorMentor all summer, Ivan and I are ready to write up results and submit it to EuroSys 2018; the deadline is in October. I’ve never written a serious, non-course-project paper before, so the thought of making new research claims to completely anonymous reviewers is absolutely terrifying. For about four weeks straight, I work frantic and disorganized late nights leading up to the submission deadline, which is more intense and stressful than anything I have ever done. At the end of a 36-hour non-stop work session, we submit with 30 seconds remaining. I immediately curl into a ball and plant my face into the floor. After a few minutes, Ivan and our group head to the campus bar for a drink.

I move in with some of my UBC cohort friends to a basement apartment in Kitsilano. My rent costs over a third of my stipends, and the apartment is barely livable. We frequently have to deal with mice and in some parts one has to duck to avoid bumping their head. However, Kitsilano is a lively neighborhood that I completely fall in love with. We live 10 minutes from the beach and everything we need is within walking distance. As a carefree 24 year old living across the country away from home, it’s perfect.

Winter 2018

The TorMentor paper is sent back with a rejection. Looking back, it was easy to see why, and it would be the first of many paper rejections I’d receive in my career. Nevertheless, I was demoralized. My labmates, especially the senior PhD students in my group, all provide kind and encouraging words. Especially now that I know paper rejections are completely normal and this was nothing new to them, I really hope to be as supportive to my peers as I become a more senior PhD in my own lab.

Ivan and I develop a plan for addressing reviewer feedback and prepare TorMentor for a resubmission in February. As I’ve now learned, resubmissions are much less stressful than paper submissions, and the rest of the journey for TorMentor was relatively smooth (after a couple more rejections, it would eventually be accepted to a workshop in 2019). TorMentor was far from groundbreaking, and I’ll be the first to admit it had many fundamental flaws. But, you never forget your first.

Summer 2018

There is no need to get repetitive about my research here so I’ll keep it short. I have a very productive summer working on research, and Ivan even lets my supervise an undergrad for the summer. I expand my work in federated learning and produce two additional projects and papers from it: FoolsGold, a defense against sybil-based poisoning attacks on federated learning, and Biscotti, a blockchain-based peer-to-peer federated learning system. Much like TorMentor, both of these papers were written up, frantically submitted, went through multiple rejection cycles, and were eventually accepted at good conferences or journals. In my opinion, both FoolsGold and Biscotti turned out to be far stronger papers than TorMentor; I suppose this came with experience as my skills and taste developed.

Otherwise, I’ll say this once more and for the last time: summer in Vancouver is absolutely perfect. Every weekend, my friends and I go hiking or camping outdoors. Friday evenings were spent out drinking at a bar or on the beach, talking late into the hours of the night. My friends Stewart and Nico convince me to take up climbing and we start going regularly. I really feel at home and have some of the best times of my life.

Fall 2018

The final month of my master’s involved writing and presenting my thesis. I’ll be completely honest here: my Master’s thesis was just my latest TorMentor submission with formatting adjustments. To anybody stressing over their master’s thesis right now: my master’s thesis was easily approved with minor formatting fixes, and I highly doubt that anybody has read it in full since. I certainly haven’t.

By the end of 2018, I was finally forced to really start thinking about my future. By this point, I knew that a software engineering job was not of interest to me and I was committed to a career in CS research, so a PhD was the natural next choice. Despite being very productive working with Ivan for two years, I was looking to move away from distributed systems research and wanted to branch more into machine learning security and privacy research. Ivan offered that I could stay on as his PhD student at UBC, but strongly encouraged me to at least apply elsewhere.

Most PhD programs accept applications in December, so there was plenty of time for Ivan and I to collaborate on a shortlist of potential advisors and my application. I applied to 8 PhD programs and was accepted to 6 of them. Ultimately I would decide to join Carnegie Mellon University in the upcoming fall.

One issue with my plan is that all my program start dates were not until the Fall of 2019. By a complete stroke of luck, one of Ivan’s former PhD-mates had just founded a privacy-preserving blockchain startup in Berkeley, called Oasis Labs. One referral and a couple interviews later, my plans for 2019 were fully laid out. In December, I meet all my friends in Vancouver for the last few times and board a plane to Berkeley on new year’s eve of 2018. And so ends my time at UBC.

Closing Thoughts

People frequently ask if doing a PhD in CS is worth it: you’re severely underpaid and overworked for 5+ years, in an industry that can otherwise pay you very, very well. The common response (for optimists, at least) is that, even if you don’t ultimately decide on a career in research, the skills you learn and the experiences you have during the journey make it all worth it. I think the same thoughts can apply at a lesser scale to an MSc in CS.

I grew tremendously during time at UBC: as a researcher, as a thinker and as a person. I made many lifelong friendships and was privileged enough to intimately experience an amazing city. Of course, I owe a huge amount to UBC, to Ivan, and to the friends I made in Vancouver. I can’t thank them enough and will always look back to this period with fondness as a special time in my life.