From “Toy Projects” to the Industry

Disclaimer: This post is a collection of personal thoughts about the transition from working on student projects to work on a big company.

It’s been more than 4 months since I joined CD PROJEKT RED after finishing my Bachelor at DigiPen Bilbao. During these few months I’ve experienced one of the biggest changes I’ll have on my professional career, the jump from the university to work on real commercial projects! This post talks about my experience during such change and what I think helped me get through it. But before that…

Why write this post at all?

I wanted to think and understand what practices helped me adapt to my new position, so that I can keep on a good path and continue improving as a developer. Having this in mind, I decided to write the post with three main goals:

  1. Force me to think more, not only about the last few months but also about all this years, since I started studying programming at DigiPen Bilbao.
  2. Share my experience with the hope that someone can benefit from it, like a lot of blog posts, talks and people that helped me achieve my goals. All those that were part of the preparation for the transition I’m talking about in this post.
  3. Have a record, for the future me, because I’ll end up forgetting about how it felt like or how it is to start working on a company for the first time 😀

The big change/challenge

Everything was new! Not only the topics related to work, I was also experiencing changes in my personal life as I was moving to another country, far from my friends and family. But I was looking forward to something like that, meeting new people from different cultures, going out of my comfort zone and becoming independent. That said, now, I’ll stick to the professional side as much as possible 🙂

When I started working, almost everything was new:

  • The people I was working with.
  • New project, with a much bigger scale than what I worked on before.
  • The code base, both, in structure and scale.
  • The place where I was working on, my desk, the whole office and surroundings.

Although some of the points listed above may not sound something to worry about. I think that the combination of all of them is what makes this changes a bit “scary”. In most of the cases, the word “new” implies “different” and this is what makes it sound “scary”. You don’t know how everything will end up, in fact, you are always fearing that everything can end up bad…

But well, I wasn’t the only one that was experiencing something new, the people I was going to work with was going to have a new teammate, ME!

I think that this was the “worst” part of all the changes I was having, one thought:

I’m “The new one” :s

How was the experience during the first weeks?

Related to work, everything started being really difficult and frustrating, during the first days I was completely lost on the new tools and code base…

I was stuck for hours on the same place because I couldn’t get something to work :s
The most productive moment of the day was the last half an hour, it felt like I did some work and went back home thinking: “Tomorrow will be a more productive day”. But then the next morning everything went back to zero progress for hours…

Then, days passed, weeks, months… and here I am now, going everyday to work like I would have being working on it for more time than I have. I still have a lot to learn, (well, I’ll always have a lot to learn) but now, everything feels normal 🙂

You may be wondering…

What helped overcoming it?

I’ve taken everything I think helped me overcome all the changes and divided it in three categories:

  • First, the personal part, as a person starting to work on a new company/position.
  • Then, two for the intellectual topics (what helped me as a programmer)
    • what I learned and I was encouraged by DigiPen
    • and what I did by myself because I thought it was going to help me.

1. Personal – what helped from the people at CDP

What seemed the worse part, the “I’m the new one” thought, wasn’t that hard to overcome, actually it was pretty easy thanks to the help of the people around me 😀

I think that the fear when you are joining a new place is understandable, but in reality you are just joining a group of people as weird as you, that love to make games as much as you do. They don’t expect you to start producing right the way, they understand that you will need some time till you get used to the new environment, tools, workflow…

What helped me the most in this aspect was one of the first sentences they told me:

If you have some idea, or think that something can be done differently, just say it or change it.

This sentence makes a lot of sense. You are new, you may be less productive during the first months, but at the same time you are able to think out of the box, in a different way than someone that has being working around the same code for a long time. This sentence helped me realize I could actually help more than what I expected.

Summarizing, is normal to be a bit nervous/scared, but everything ends up fine. You just need to be yourself, earlier or latter the people you work with will end up being good colleagues. Having your own word is good, you are not paid to be a code monkey, your ideas are worth it even if they end up not being the best ones. In fact, during the first weeks most of the ideas I was trying to propose weren’t good, I lacked some context. But thanks to not keeping them for myself, I was getting the explanation of why it wasn’t a good idea and therefore learning something new.

Share your thoughts, there is nothing to loose.


2. From DigiPen – what helped me from my bachelor

DigiPen provided me all the knowledge I needed. What helped me assimilate and understand all the knowledge I was getting during the different courses, was that I had to directly work with almost everything mentioned in class. Either do homework in case of math or create small programs or projects for the Computer Science classes.


In my opinion, what makes DigiPen stand out is the “DO IT YOURSELF!” motto, the most powerful way to learn. If you don’t do something by your own, you probably won’t understand it well. May be in the moment you think you understood it, but by the time you have to do it again you will have forgotten it.

Small story: When I was in high-school I fell on the same mistake multiple times during my math classes:

Oh, the teacher is going to explain this problem I wasn’t able to do yesterday!

(Some time after) Oh! It was so easy! I already understood it, I don’t need to copy it.

(Same afternoon, at home) No idea how to start this problem…

Takeaway: If you want to learn something, DO IT YOURSELF! Otherwise, 95% of the times, you will forget it. By doing it yourself, you make sure you understand it and you have more chances to remember or come up with the solution by yourself latter on.

How did the “Do it yourself” idea fit within my RTIS bachelor at DigiPen?

During my bachelor I was able to explore a wide variety of areas and subjects such as math, physics, algorithms, graphics, data structures… All the topics expected in a Computer Science course plus all the mathematical knowledge required to make games.

Create all the technology from scratch. Frameworks for the different assignments and engines for game projects.

I had the possibility to put in practice what was covered in class thanks to all the projects I had, specially while working on game projects where I needed to apply all my skill set to create, together with my team, the best game we could. Writing own engines and frameworks from scratch helped me explore and understand better how game engines work internally, their architecture and be able to understand and adapt to new tools, engines and work with them.

All these converges to the same idea, do it yourself.

3. From myself – practices that helped me become a better programmer

At DigiPen, I had to code everything from scratch myself, but, I could have reused a lot of code through the different classes and projects once I had it done for the first time! I didn’t do that and it helped me A LOT!

As I was learning so fast about so many different topics, I decided to start from the ground up each subject, so that I could explore new ways of approaching problems and experiment with programming patterns and architectures. This made me analyze advantages and disadvantages between the old and new approach I was trying, leading to better results in both, maintainability and usability aspects. Without mentioning it was a good learning exercise. And again, all these can be summarized on:

Do it yourself and repeat until you master it.

I made my life harder…

Apart from repeating as much as possible everything I was learning, I also tried to not use shortcuts. Some people may say that I “made my life harder”. I always tried to use as few helpers as I could with programming related problems. Let me put some examples:

  • Use Notepad++ or Visual Studio Code instead of the fully featured Visual Studio.
  • Use printf or std::cout for debugging, instead of a debugger ( using Notepad++ ).
  • Use makefiles and/or some custom made scripts to create my workspace. Automate compiling in multiple configurations, running tests…
  • Rewrite and improve as much code as I could, trying new approaches and improving over the previous iterations.
  • Try to wait as much as possible before asking for help.

WARNING: Don’t take those points as must follow rules, all those practices can be harmful too.

Not learning how to use a so popular development tool like Visual Studio or be able to ask for help when you need it are also really valuable skills. I used Visual Studio and the debugger when working on big projects, or reused some graphics code because wasn’t the topic I most liked and I wanted to invest my time on rewriting or learning about some other system.

From my perspective, all the extreme practices are bad. There is usually a short and long path to achieve something, either of them can be a good way to achieve your goal. The problem comes when you take always the same one: the short way won’t provide you with the whole experience; on the other hand, using the long one too many times might prevent you from achieving the goal in time, will provide a lot of knowledge, but being able to manage your time is also an important skill to have.

These are some examples about what I learned when taking the long path:

  • Learn how to debug without a debugger to develop your mindset and understand better what’s happening, while at the same time you use breakpoints to debug more complex scenarios. But the first is needed in order to understand why data breakpoints exist, why are they useful and how you can use them to fix your issue.
  • Having written some bat files to automate your builds and tests helped me then develop some scripts that would cook assets and prepare a submission ready folder for my game projects. While learning about all the variables available to setup on a Visual Studio project also helped me understand more the build process, what improves compilation times, project dependencies, etc…

Be careful with the extremes, find the balance!

I found some new hobbies 😀

Watching talks! I watched a lot of talks, from the GDC, Extra Credits, CppCon, Jason Turner… Mainly about programming, but I also checked art, design, sound… see how making games looks like from their point of view and understand what could I do for them from my position. Latter I was surprised how often I went back to some of these talks and how I could use them as an inspiration, reference or as a lunch conversation starter.

Reading code! Go into GitHub and check out the crazy projects some people works on. Or start digging into some implementation code, like UE or STL source code. ( Yes, I agree, STL code seems a bit cryptic but you would be surprised how much you can learn if you put some attention 🙂 ).

Work on personal projects! This was a good practice in two aspects. First, I usually picked the projects in order to experiment with something I didn’t worked on before, so I was learning. Second, it was a way to clear my mind and focus on something different to what I had to do for the university, work on something for fun. In any case, don’t try to work on personal projects that don’t motivate you, is okay to start a project and throw it away in two days, don’t feel bad if it happens. Try to learn always out of everything, why did you stop working on it? What went right, what didn’t… Over all, enjoy the experience.

Summarizing… how did all these topics help?

To be honest, now that I’ve already broken through the barrier of starting in a new place and getting used to the new environment, tools and technology. Everything feels normal, the change was very similar to all the situations I had during my four years at DigiPen.

Everything I mentioned above prepared me intellectually to be ready to work on such a big project, to be a programmer. Each one taught me something different, something that was new.

At the same time, all of them taught me one same lesson once and over again…

Everything can be difficult at first, is just a matter of time what makes it become trivial.

That is what helped me overcome the frustration of the first few weeks, I knew it was just a matter of time to get used to the new code base, just like it happened during each assignment and project I worked on during the last years. With each mathematical formula that now I know and understand like the palm of my hand.

Frustration is something temporary, just don’t let it trick you.

Time and effort will pay off.

The reward is there, just around the corner.

2 thoughts on “From “Toy Projects” to the Industry

Add yours

Leave a Reply to Borja Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a website or blog at

Up ↑