Having a Team of Novices

Now imagine that every driver learned by just getting thrown onto the road without any instructors (Okay, maybe this method doesn't work for everything)

A part of this project where our team thought we could provide the most value to demystifying engine development was by being inexperienced. This seems counterintuitive at first glance, but it does make sense. As the people who are both developing and writing about the development, we wouldn't have any preconceived notion or assumptions while developing the engine, so we could then document the things that we assumed for others to know about. Other novices would likely have the same questions and same assumptions, and thanks to our team existing of solely novices, nobody was there to feed us the answers.

A significant part of the engine development process is just making decisions about the engine, whether they're architectural or implementational. For the Isetta project, this took place in team discussions where we would gather around a computer or the whiteboard. In these discussions, someone would present the problem, then usually they would present their original solution and also why that solution wouldn't work. From there, the team would throw around ideas and prod for more details about the problem we were trying to solve. At a minimum, these meetings provided everyone context on a feature that was being developed in our engine and it forced us to confront design conflicts that may have been brewing. If someone on the team already had engine development experience, the meetings may have ended immediately after hearing this person's solution (this likely wouldn't have happened all the time, but it would surely be a tempting path to take, especially when we were pressured or in crunch). This highlights a challenge of working with more experienced people: while that experience helps the product ship, it can also be harmful for learning.

In the beginning of the project, we had a pseudo-expert in the room in the shape of a book, Game Engine Architecture by Jason Gregory. Everyone on the team had read the book in some capacity, which gave us this vocabulary to use in our discussions. However, a pitfall we almost fell into, especially in the beginning, was following our "expert" too closely. Some of our discussions and decisions started to boil down to "what does the book do?", and while this was helpful to push development forward, it wasn't really good for our growth. It was problematic to rely on or imitate the expert experience too closely, particularly when just starting.

With professional engine development, the goal is the product, while the learning along the way is a side effect. But for our project, the goal wasn't to have a perfect, bug-free engine but instead to learn engine development, and having a functioning engine at the end was our side effect. This is something that we found made our project unique compared to most full-time engine development efforts! And with our learning and the learning of those who read our development blog being the main goal, it was in our best interest to avoid having some guiding hand in the team. We made mistakes which impacted the engine (sometimes in pretty bad ways), but we learned more from those mistakes than we would have if someone had told us how to do it outright.