Confessions of an Unreal Engine 4 Engineering Firefighter

Stop Burnout, Start Growth

• Incredibly often, I have seen teams hire one or multiple entry/mid-level engineers, and then immediately try to extract senior/higher-level work out of them, without offering them room to grow or fail.
• I believe that this is causing rapid turnover and extreme burnout: it is a negative feedback loop that crushes the potential for high-level local talent, thus creating even more ridiculous demand.

Not Having an Engineer Is a Problem

Learn from Your Mistakes

• if your company is to deliver a product that requires an engineering effort, you should also try to distinguish between an underperforming engineer, and a handicapped engineer, who is overburdened with responsibility in relation to their skill level.

High-Level Engineering Is More Than Just Code

By the Way, All Your Subordinates Are Lying to You (Because You Don’t Listen)

• One very interesting thing I had found, when I came into an office as an outside objective evaluator and you had left me to do my job, was that approximately 2 nanoseconds later your employees were already telling me everything that was wrong about you, your company, and your development methodologies. It was not a matter of having a trusting face, or even promising them to make things better, it was about your employees who cared about the growth of the company, and more importantly about their own growth within a company despite feeling unheard and ignored. I just happened to be a new face that wouldn’t judge them for what they would say, and even if I did, often they are so tired of the problem being present that they would even just stop caring about any potential consequences of speaking out against their employer.
• Usually an outstanding problem or issue is already known by your staff, and often they have tried to make you aware of this problem, but usually it gets prioritized into nothingness, or filtered into white noise by your chain of command where no action gets done. Worst case is when someone brings this up directly to the most senior decision-maker, and it gets either immediately rejected or the intent to ignore is made clear.
• Allowing reported issues to result in zero action is the quickest way to convert your employees, especially your engineers, from enthusiastic company-first workers into “clock in, clock out, it’s not my problem” workers.
• As a manager, you can tel if an engineer is happy with their work if they are comfortable giving higher-ups constructive feedback about issues at hand directly. As an engineer, you can tell if a manager is actively working fo ryou if you see at least some action performed as a response to your feedback. When both things happen, management might see an increase in reported problems during development, but they’ll also see an increase in resolutions, instead of seeing fewer but critical issues that go unresolved. Burndown charts are a great tool for identifying which camp you are in. Assuming you are using issue-tracking software correctly, if you are seeing erratic spikes and inconsistent numbers week-to-week regarding your number of open problems to number of problems solved, your team is not working at their full capacity.
• just because you have an outspoken engineer who shouts about development issues every day does not mean your team is healthy. If only one engineer on a team is causing problems, and you have no lead present, usually one of two situations is occurring. That person may actually deserve to be your lead and his/her fellow engineers are trusting them to make the changes needed, or that engineer is just an asshole. Sitting down with your engineering team, and treating them with respect, will quickly let you know which situation you are in.
• If I get the call to come in and fix engineering issues, I immediately try to seek out the peoople who are clearly disgruntled […]. If I’m able to identify that they are correctly disgruntled, and simply not causing havoc, I’m going to feed you your employees' own knowledge. And I’m likely going to charge more than it would have cost for you to simply listen to your employees.
• WHen you do not listen to this relaying of information, and you are stil set on hiring outside forces to solve your problem, I will do whatever engineering is required and absolutely shock you in terms of how productive one engineer could be. In reality, this is not because I’m a super genius high-level engineer, it is because I am leveraging your team’s engineering against you because you are too fucking thick to see otherwise.

Don’t Become a GDC War Story

Don’t Be A Victim Of Corporate Kool-aid or Cult Culture

• It is known that to work at some companies, you must succumb to their corporate kool-aid to survive.
• If you’re potentially hiring from one of these large kool-aid companies, it’s important to vet the candidates for their ability to self-think.
• As an employee, it is important to know what is good for the company and to know what is artificial flavoring. You should be actively agreeing with the way a company is moving forward, instead of passively letting things deteriorate. You might wake up one day with a hatred no one can soothe.

Moving Up As An Engineer / Growing Your Engineers

• As an engineer, you will always have a ‘weakest area’. What separates entry, mid, and senior level engineers are usually the types of weaknesses an engineer has, as opposed to their strengths.
• If you need the support of people above you more than the people to your side to organize meetings and convey information, you’re mid-level.
• If […] you need help from those sitting aside you as opposed to above you, and you’re able to communicate this need and get the job done without the need of about a hundred cross-department meetings, there is a good chance you’re qualified to be a senior level engineer.
• If you find yourself being able to work out problems as [a] team incredibly well but feel like you don’t have the skill to be the one who frequently comes up with the “last piece of the puzzle” or the “critical problem-solving solution”, you might not be heading toward being a senior-level engineer but instead you might be better off as a lead engineer.
• If you’re the guy asking for help from people below, to your side, and above you, you’re probably an entry-level engineer. If you frequently need suport from those above you (excluding C-level and executive suport, that my friends is a whole new level of hell), there’s a good chance you are mid-level engineer. If you find yourself supporting and being supported by those at your side, you are likely a senior or lead level engineer.
• It is my belief that lead engineers should not be mistaken for senior engineers and vice versa. Lead engineers should be skiled, and they shoudl be above seniors in structural authority, but that does not mean that they should be automatically paid more, valued more, or trusted more. The role of a lead engineer is to lead. The role of a senior engineer is to solve the tough problems. Ideally your lead engineer is also a senior engineer, but this is not always the case.
• If you find yourself in a situation where your top level engineers are being strapped for time because [they’re] too busy helping the people below them, you need more senior level engineers. If you find that productivity is good and that you are underutilizing your senior level engineers, the answer is to bring on mid-level engineers. The seniors will allow the mid levels to grow, which in turn allow the seniors to grow as well either sideways into lead roles or upwards into executive/principle/board member roles.

Dumb Things That Bad Engineers Or Companies Without Engineers Do In Production That Hurt Themselves

• When it comes to the pure engineering aspect of being an engineer, sometimes being an effective engineer is simply the enforcement of seemingly obvious things. If I am called to figure out a pure engineering problem, 95% of my time is usually spent identifying the problem, 4% involves fixing it, and 1% is about telling everyone that the problem has been fixed.
• Smaller Commits, Better Commit Logging
• Make Builds and Test Them
• Test Your Builds on The Target Hardware
• Try to Follow Some Form of Style Guide
• Don’t Ignore Your Lead Engineer if You Have One
• It Works on My Machine