My CD Projekt RED story, part 3

We are now 2 years into my CD Projekt RED adventure and so far, it’s been mostly smooth sailing. I got promoted to a QA Analyst position, an equivalent of a specialist position for developers. I was earning around 2600zł or $650 per month, which would sometimes go as high as 3500zł with additional crunch pay. At this point I felt fairly rewarded for my efforts and could even start planning my wedding. I also received the first bonus for my participation in the creation of both Witcher 3 expansions. This amounted to roughly 13.000zł or $4250, which was an amount of money I had a hard time wrapping my head around. I still lived in a single room in an apartment I shared with other people, but at this point it was mostly my own choice. I’ve had my own wedding on the horizon so I needed every coin I could save for the occasion.

Getting out of QA

It was during that time that I decided I want to transition away from doing QA work. I approached the audio team’s producer to start the discussion about my future. I saw myself in a role of an audio technical designer, which would mean I would be responsible for technical implementation and scripting of audio assets and events. This was turned down, because sound designers already did this kind of work. The producer didn’t see the need for creating such a specialized position, arguing that for the same money, he could hire another sound designer who would both do the work I wanted to start doing and take care of audio assets creation. So this turned out to be a dead end. However, the lead of the audio code team noticed my interest in all things technical, and since the only audio programmer left besides him was about to leave the company, he offered to train me in the ways of C++ with the hope of transferring me to his team in the future. I’ve always enjoyed working with this guy, so I was very excited and grateful for being given such an opportunity. I couldn’t wait for my first coding lessons to begin.

Programming like a noob

Soon, I’ve had Visual Studio set up on my PC by IT and was given my first coding assignment. I was to write a simple standalone application in WinForms that would be used by the audio team to manage some audio-specific data. I’ve had no idea what WinForms is, no C# knowledge and no understanding of code architecture whatsoever, but I ploughed through with stackoverflow filling one screen, and Visual Studio the other. What I wrote was a nightmarish abomination that could hardly be called a program, but since my lead’s knowledge of C# was not that better from mine, I kinda passed the test and started receiving real-life C++ tasks involving the RED Engine 4 development. I struggled a lot at first, but I was determined to get up to speed as fast as possible. My lead would help me every now and then, but I was mostly left to my own devices. Apart from the C++ tasks, there also popped up a need for the audio code team to develop an application that sound designers could use to manage the sound engine’s behavior configuration data. The last remaining audio programmer had left the company at that point, so the task would land on me. At this point I was officially transferred to the audio code team as a Junior Audio Programmer, earning a little over 3000zł or $750 a month. In the most crunchy period I got paid a little over 5000zł, doing between 10 to 12 hours a day, including some Saturdays. Most importantly, though, after years of documenting things broken by others, I finally had the chance to break some stuff myself.

Getting it

Since I will be referring to my lead a lot throughout the rest of this post, let’s call him Dave to make the story easier to follow. Dave’s break into games programming was not that different from my own. Like me, he was not a computer science graduate and have learned how to code at work. I always scent he saw a younger version of himself in me. I must have been a kind of a personal project of his, and apparently that’s what he went around telling people. It was a kind gesture of him to had given me the opportunity to transition to a more satisfying career path. I had genuinely liked him ever since I had joined the audio team ranks almost 2 years prior. Unfortunately, all of this had started to change as I learned more about programming. It’s funny how people inexperienced in programming take certain functionalities for granted. A good example of that is how most people assume an undo-redo functionality is so commonplace it has to be a child’s play to implement such a feature. It might be a shock to some people, but it really is not that simple. In fact, there are many simple-looking features that take experienced developers months to implement. It certainly took me by surprise how much work is needed to implement some functionalities commonly found in various applications. What’s really shocking, though, is that Dave was as surprised by this as I was. Right after I started working on that tool I mentioned, a new programmer have joined the audio programming ranks. This one was a professional. Since the scope of the tool was constantly growing, it was quite possible he would have to take over its development at some point. It was for this reason that I decided to follow my pro colleague's advice and write the tool in WPF. Since Dave had neither knowledge nor experience with WPF, he wouldn’t be able to understand how the tool is written, let alone take over the work in case both me and my new pro colleague would call in sick. And so it went for some time. I was fighting with WPF and learning it step by step, with small victories here and there. Alongside that I was getting up to speed with the C++ engine/gameplay/audio programming workflow the coders followed at RED. The pro colleague would prone me in the right direction whenever I found myself completely at lost with WPF.

Getting my hands seriously dirty

The complexity of the tasks I was being assigned grew every week. I was getting less insecure about my programming skills, but would often get stuck with bugs that originated from very obscure, difficult to read code. Since a lot of this code was written by Dave, I would ask him for help in many of these cases. I would be given instructions on how to fix or expand the code, but even then, I couldn’t stop thinking there was something wrong about the way the code was written. It was only later when I learned on my own the principles of code readability and maintainability, when I grew to understand just how horrible that codebase was. It didn’t take long before the first issues between me and Dave had started brewing. It started off with the way he would sometimes express himself when reviewing my code. On several occasions he told me the code I’d written made no sense. Now, what I wrote might have very well made little sense at times, considering all the catching up I had to do. However, that’s not the code he criticized. I soon discovered that it was not bad code he was getting so upset about. It was simply code he would have written differently. It wasn’t that the code made no sense. After all, it compiled and gave expected results. It made no sense to him and that’s a big difference. Initially, I was trying to be as open to this criticism as I could. After all the productive and positive interactions I had had with Dave before, I believed in his good intentions and determined to simply improve my skills more and more. I would crunch-code at work, go home exhausted, only to continue watching coding courses on Pluralsight for the rest of the evening. I was doing all I could and made good progress. Dave knew I was learning with Pluralsight and he would sometimes ask me what I was looking into those days. I remember one such interaction particularly well. One day I told him I was following a course on design patterns, to which he reacted with “oh, these things. I might learn them one day myself”. And he really meant it. It’s not encouraging when you hear your lead saying things like that.

Realizing the uncomfortable truth

At that point I’d had a couple of months of regular code reviews with Dave behind me and was starting to work with people from other departments. This meant I had to include them in the reviews of the code I was writing. It was those people, mostly junior and specialist level programmers from the gameplay code team, who had made me correct some horrible mistakes I was making. An example of that was iterating over copies of objects instead of const references to those objects. Dave had never pointed to me that it’s something I should avoid. If I were to mentor an aspiring programmer, that’d probably be one of the very first things I would mention. As my programming skills developed, I felt more and more uncomfortable with my lead reviewing my code, seeing it as pointless. Many of the tasks I had to work on involved expanding what Dave had written before. In many cases, instead of adding or adjusting requested functionalities, I had to rewrite the code from scratch because of how messy and impossible to expand it was. I’d worked with Dave for almost two years at this point and I had really enjoyed working with him before I had joined his team. It was always nice to talk to him, he could always make me feel like he’s in control. I really want to get this point across here: I started working with Dave with as much goodwill and trust towards him as possible. It was only after I joined his team that I really got to understand that his professional and positive outlook was only an act, just like it was for the studio as a whole. I’ve discovered for myself what other developers had mentioned to me on multiple occasions. Apparently, some higherups at RED were very similar to Dave: easy to talk to, emanating an aura of professionalism and control, fighting for influence over the game director, but when it came to doing any actual, solid work... Yeaaaaaaaaah.... Pass on that.…

Doing research

Because what I was learning on Pluralsight and from colleagues from other departments conflicted so much with what I learned from my lead, I’ve decided to meet with the audio programmer who had left before I have joined the team to talk about his own experiences with Dave. I’ve heard stories about the two of them not getting along very well, so I was interested the hear what that was about. It turned out he knew very well what I was talking about. He also told his story, which I hope he will one day publish somewhere. I couldn’t quite believe what he told me could really have happened at RED. I knew one thing for sure, though - I didn’t want to take any chances. So I talked to my lead one on one. I asked him to stop insinuating I’m stupid and perhaps open to ideas other than his own. He seemed receptive to my feedback, but this marked a final turning point of my RED adventure, which directly lead to me leaving the company several months later. Things went downhill pretty fast after that little chat of ours. In the last part I will be focusing more on the HR processes at RED, the incredible plotting of my lead and my final months at the company. Here is the last part of the story.