Technical problems, learnings and day-to-day work at my Unity Internship
Hello! My name is Fillip Serov and I am currently on an 11 month Software Engineering internship at Unity. My position is full stack so I get to work with both the front and backend of the Unity Analytics product my team owns. I mainly work with Javascript (React) on the frontend and Kotlin on the backend.
Before joining Unity, I was studying for my BSc in Software Engineering at Swansea University. Whilst there’s a huge difference between university work and real work, in reality there are definitely transferable skills between both: modules involving group work make you run into common issues when several programmers work together, and at a company you’re able to see how they avoid or reduce those issues. For example, automated testing decreases the chance of someone merging work that will cause errors for other people, or quick daily standups to give people a chance to point out things blocking their work.
At University sometimes large writing assignments seem like they won’t be relevant to the real world, however, you’ll be thankful for the practice when you have to write any sort of technical document outlining the requirements/tasks for a large feature, or even something as small as articulating a problem well when writing a bug report.
My first piece of work was to pair with a teammate and fix a small bug on our frontend. In hindsight, I really appreciated that I was able to get hands-on experience and time pairing with an experienced engineer because I could get first hand experience with how my team approaches issues. I saw how they navigated the large codebase to quickly get to the problematic file, and then the problematic line. In my opinion it’s best to drill down as far as possible, and then work backwards to try and understand what is going on, since you prevent yourself from starting at an unnecessarily large and abstract point of view.
The steps after are important too of course: creating a pull request, verifying the change in a staging environment, getting a review from someone, and of course actually deploying to production.
Microservice Architecture
The backend my team works with consists of just a little over a dozen microservices. Joining the team, it was interesting to see the advantages and disadvantages that microservices brought, having only ever worked on “monoliths” before.
It became obvious quickly that it is extremely useful if not required to have some sort of base library on top of which all of your microservices are built. There will be countless times where a change needs to be applied to all your services, and it’s much easier to bump up the version number of a shared library, rather than copy-pasting a change a dozen times.
Since these services don’t live in isolation, they need some way to communicate with each other. In our setup, each service is able to generate a client library for itself: this means turning each API endpoint into a function, usable inside another service. This simplifies immensely the process of writing code for a service that needs to work with another service. Personally I’ve never dealt with anything like this, so it was quite fun to delve into it (with the help of my teammates of course!). I ended up customizing the client generator we use to attach a unique “correlation ID” to each outgoing request, the importance of which I’ll explain in the next paragraph.
Logging becomes more difficult when dealing with microservices, since by default you have no way of knowing which logs come from which service. Service A may report that it received an error from service B, and the only way you can find out what happened is by searching service B’s logs at around the same time as service A reported an error. However attaching a “correlation ID” to each log creates a chain between all relevant requests that can easily be followed. Since implementing these correlation IDs it has become much easier to debug service error.
Day-to-day Development
What does a usual feature task look like on my team? The Analytics Event Browser is a feature I worked on recently. Below you can see screenshots of the feature before and after my changes. We had to update the page to have two more filter options for a better user experience, and since that isn’t really compatible with the existing page layout, a small update to the layout was needed as well.
To start I needed to update our backend to accept these two new filters. This is a fairly straightforward change since these filters (and pages with other filters) hit the same backend service, so most of the work there was already done. Of course I took this opportunity to add a set of tests for the new filters (not like it would have been approved otherwise!).
The next step was to update the SQL that fetches the data to display on the event browser page. I had to do this because one of the new filters was targeting a column that was not previously fetched when getting the data. The need to do this is quite rare as most work is related to changing how data is shown, as opposed to adding additional fields.
Finally, we reach the frontend, where I needed to rework the page to account for the new filter options. The design for the page had already been prepared (in Figma) by a designer using the same components and styles as the ones available to me in our codebase. Design definitely isn’t a one-way process, and if I find there are unexpected complications I can easily speak to our designer to find a better solution. Most of the work at this point was to write JavaScript logic and to get the React components to communicate as required. There’s (thankfully) very little CSS to write as most of that is handled by our UI framework.
And there you go, your feature is complete!
I would heavily encourage any students looking for a placement to apply to Unity. I’ve really enjoyed my time here and I’m looking forward to using the skills I’ve learned here in both my upcoming third year, and my future career!
Find out more on our Students and Early Careers Recruitment page, and read about kick-starting your career with the Unity Student Program in this Unity blog post.
