I wanted to write down some of the notes I picked up in the past and share them with anyone looking at starting out in the Technical Director role, it’s by no means exhaustive.
Focus on growing the team’s knowledge
As you become more senior as an engineer you end up taking on more complex problems, finding solutions for things that usually haven’t been done before (or integrating lots of individual systems into a unique system). When you do these things, it’s important to show others how you did it as well as the why. You may not be directly managing people but you are still essential to growing the team’s knowledge and experience.
Documentation, doing talks (GDC talks are great for hiring too), and 1-to-1 training, it’s important to help grow juniors into seniors. If you don’t, the company ends up becoming top-heavy and that leads to other types of problems.
Don’t be that person who produces arcane code with obscured variable names to keep their job security.
Early in the project, it’s important to define code standards to make sure everything looks like it was written by one person. That way when Person X picks up a bug and finds it in Person Y’s code, they are able to understand the what / why and structure of the code and fix it.
Now, once those standards are defined it’s important to not just have them sit in some internal documentation, you need to ensure those standards are adhered to by the next step.
Knowledge sharing isn’t just for seniors, it’s for everyone! Usually, before you submit your code you want to have someone on the team review it with you. How to do a good code review is a whole talk in itself, but in short, you want to do three things.
Does the solution “make sense”
The code needs to solve the problem defined but in a sensible way.
If the task was to have object X move towards object Y, and you open the review to find that instead of moving object X the code instead moves everything else around object X until it’s near object Y.
You can let the reviewer know that there is a better solution that doesn’t involve moving the entire world. They learn from it and the code base doesn’t get some obscure code submitted into it.
Does the code have any pitfalls?
When you are reviewing the code, keep an eye out for things that can cause nasty bugs. My personal pet peeve was memory leaks/memory stomping bugs. They can be difficult to spot in a review but they can cause even harder-to-diagnose problems in the future.
Helping train others to spot them by pointing them out in reviews leads to fewer of them showing up in the future.
As was told to me: “It’s cheaper to catch a bug in review than by expecting QA to find it”
Does it fit the standards?
This is usually down to style, but keep it consistent otherwise it becomes difficult to read everyone’s unique style.
I prefer private variables to be prefixed by m_SomePrivateVariable but I’ve also seen:
m_SomePrivateVariable pSomePrivateVariable somePrivateVariable _somePrivateVariable
Is it the end of the world? No, but it should be addressed to keep everything looking clean and consistent. Speaking of which if you need a coding standard for Unreal, I got you.
Find a great review to learn from?
Share it with others in your team. I remember one code review in an entire dynamic content stripping system which ended up having ~150 issues flagged in it, from the back and forth I had with my reviewer I was able to find a simpler solution that also was more performant (Simon if you read this, you rock dude).
Code reviews are great at sharing knowledge, but you need to also document the intent of the code. This can be in giant comment blocks (In the aforementioned content stripping system I had a huge comment explaining the what/why), and it can also be in something like Confluence.
You will want to ensure the team is keeping their documentation up-to-date so that things can be maintained in the future. Try and do this as part of a deliverable, this isn’t always easy to do but it means that in a year’s time when you need to re-address part of the system, you aren’t starting from scratch on the knowledge.
Bugs come in, every, single, day. If that isn’t happening then you aren’t testing hard enough. If you let them pile up you’ll drown in them. So it’s very important to promptly triage bugs as they come in and then make sure the most urgent, game-breaking bugs get eyes on them.
Every day I would sit on a call with our QA leads and the other tech directors to go through the day’s new bugs. The goal was to allocate them to the correct team, define a priority rating and let the right people know of the serious bugs.
As a group, make sure standards are defined. What is a P0? What is a P1, etc?
That way, you can have anyone on the team handle the prioritization and streamline the process. Sometimes you’ll have a complicated bug that doesn’t present anything helpful in a call stack and it’ll require some investigation to really uncover the right team. In that case, use your judgment to assign a team and then check in to see the status of the issue.
As a complete side-note here, if you start seeing lots of one-off call stacks which seem to make no sense causing a crash, you might be looking at a memory stomping issue, which breaks the call stacks and makes QA very sad because suddenly the 5-10 bugs a day turn into 100+ unique bugs.
Lead the charge on difficult problems!
Draw from your previous experience and help your team break down complex problems into smaller, more solvable problems. There is nothing worse than going to a planning meeting, seeing a huge problem presented (IE: “We would like to make a car”), and then asking the team for an estimate only to see everyone bury their faces.
Instead, work with your leadership and producers to break down those chunks of work into smaller pieces that are easier to give estimates on (“Design the wheels”, “build the chassis”, etc)