Continued from [A Gamer’s Primer to the Career Meta, Part 4: Compensation]

A lot of career advancement comes from expanding one’s skillset into a senior role. Many newcomers to the industry lack the necessary context to understand just what [kind of responsibilities are granted] to a [junior, mid-level, or senior] developer. The difficulty is figuring out how to get more senior. The descriptions of the roles don’t easily lend themselves to teaching oneself and, most of the time, work assignments typically err on the side being within one’s capabilities rather than challenging them to expand - that is, your boss will more often give you a task she knows you can do rather than one you will need to grow into. The result of this tends to be career stagnation - those stuck below glass ceilings at junior or mid-level with no clear path to more responsibility or promotion.

The big issue here is the “unknown unknowns” - the many potential issues with the work that exist that you don’t know exist because you’ve never heard of them before. As an example, consider certification - it’s a tremendously important part of the game development process with huge amounts of resources dedicated to it, but the entry level junior designer would likely have no knowledge that it exists. This can be extrapolated to all sorts of other non-obvious institutional knowledge and “best practices” - things that you don’t know you don’t know. 

The good news is that it is possible to accelerate one’s learning. Even though you might not know what you don’t know, there are still people on your team who you can look to for direction and training that do know these things. If you want to learn what exists out there, you need to look to those who know it already. Then, once you’ve discovered those areas for growth, you can formulate a plan to learn them yourself. There are two major approaches to this that I suggest: 

[Find a Mentor]

Budding young developers need mentors to help direct their growth in areas that they need. Find a senior developer on the team (not necessarily your lead) who works near your space and try to make friends. In engineering, there’s a concept called “pairwise programming” where two engineers sit down and hash out a reasonable code design together while looking at the same screen. Design often does similar things - we sit down and iterate together quickly in order to come up with a design that passes muster with (at least) two sets of eyes on it. If you get a chance to participate in such work, you should absolutely ask for and take them whenever possible. The importance with these sessions is not (just) to get the work done, but to learn what kind of questions a (more) senior developer will ask, because those are the same kind of questions you need to ask yourself as you do your work on your own. Similarly, you can reach out to senior devs to check your work on a conceptual level before you start doing it. I often call these a “sanity check” - just making sure the idea is sound. Optimally, your solution should be easy to explain. If they have questions, answer them if you can or return to the design if you can’t, but remember the kind of questions they ask. This mentorship will steadily expose you to more elements you probably didn’t know existed and help you push the boundaries of what you’re familiar with.

Participate in Submission Reviews

Mentorship isn’t the only way to find out what you don’t know. One of the best practices in development is regular review passes on new submissions - code reviews, design reviews, art reviews, schedule reviews, etc. This is so that the submitter has a second (and possibly third or fourth) set of eyes on the work that is about to go into the depot, a final check for obvious bugs or other issues. If you’re a more junior dev, you can help the process by providing another set of eyes on the work and pick out any bugs you see, but you should also take the review process as a learning opportunity - what is the more senior developer doing with their code/content/art that you don’t recognize? Why might they have chosen to do so? Is it a better choice? The review process isn’t just there to catch bugs, but also to help pass along tribal knowledge to the reviewers on the submission. The submitter will usually answer your questions if you ask. These review processes are a great way to get exposure to the kind of thinking that more senior developers apply and the questions and problems their work needs to address.

Most of the time, becoming more senior is more about figuring out where to grow rather than the actual growing. Knowing where to improve and then improving in those areas is natural progression. The hard part is not knowing how or where to improve. It can be very easy to get stuck in one place and stagnate during your career if you try to blaze your own trail without looking to mentorship and other best practices. The work you do in that situation will probably be (more or less) functional, but you’ll likely be stuck at that glass ceiling and unable to break through it to get that title promotion. Getting more senior and taking on more responsibility at work tends to be a case of learning from those who know more than you. You can learn this yourself through natural exposure, but putting yourself into situations where you are more commonly exposed to these situations are how you can fast track your own growth.

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

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ