I realised a previous question i made might’ve been written poorly so let me rephrase it. How do you introduce new developers to a long developing games where there are a lot of different elements from previous years running in it. I imagine even for experienced dev it would be hard to get into a long running mmo and know how the code works in it, especially if it’s code based being maintained fora lot of years.

The journey of a thousand miles begins with a single step. When I ramp a new hire up, I like to take a three-pronged approach to help them learn stuff through a variety of exposures. Depending on the new hire’s experience level and their performance on the initial tasks, this approach allows the new hire to engage as much as they feel comfortable, as well as provide some pretty good context to me for what to do next with them.

Yeah, I can do that.ALT

The first prong is assigning the new hire fairly easy tasks in the area they’ve been assigned to work on. This typically starts with fixing existing (and fairly simple) bugs. Small bugs are a good way to familiarize a new hire with the code, assets, tools, and work flow. In addition, it also provides good acceptance criteria for completing the task. There are also almost always small bugs available for fixing on large projects, especially long-running large projects.

Detective Pikachu looks through a magnifying glassALT

Second, I put new hires into circulation for reviewing other peoples’ work (e.g. code review, design review, art review, etc.), especially those working in the same area as the new hire. They help look over work done by others and get an opportunity to ask questions about the work being done. This helps show the new hire how others on the team are doing their work and gives them an avenue to ask questions about how things work.

"Join me, and together we can rule the galaxy" -- Darth VaderALT

Third, I like pairing the new hire up with a mentor so they can feel more comfortable asking general questions without feeling nervous or fearing judgement. More experienced new hires probably won’t need a mentor as long, but it is good to have someone who can answer questions and suggest helpful information to the new hire. One big problem that many new hires have is the unknown unknowns - things that they don’t know that they don’t know. The mentor should help point those things out.

Rocky training with one-handed push upsALT

As the new hire gains experience with the project and levels up, we can repeat this process for each new area of responsibility that we want them to work on. I might start a new hire with class design first, before expanding their responsibilities to enemy or encounter design. With luck, they’ll be able to pick things up more quickly as they become more familiar with the project and the way things work. The first few weeks of being a new hire on a big project is often like drinking from the firehose - it’s information overload on all sides. I’ve found that assigning small actionable tasks, peer review participation, and providing a mentor are all very useful means of structuring the onboarding process and make it a little less daunting.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *