A day in the life of a TUI Musement Software Engineer
In this article, I will present a snapshot of daily life as a Software Engineer at TUI Musement and give some insights into the way we work.
9 AM
Time to start! Let’s grab a coffee and, when I’m in the office, have a quick chat with colleagues: perhaps there’s even some delicious cake if I’m lucky!
In TUI Musement, the Engineering Teams work with the Agile methodology using the Scrum or Kanban framework, so for the first hour (give or take) it’s preparation time: we prepare for the stand-up, update tasks in the Jira platform, check emails, and organize our daily work.
During the week we’ll also attend the usual Agile Ceremonies like Planning, Refinement, and Sprint Retrospective.
10 AM
Most of the time we work remotely and as many colleagues are located in different countries, all of the meetings are video calls. However, when we’re in the office I love to sit in the same room as my teammates and attend the meeting together.
It’s time to update everyone about the work I completed yesterday and what I’m going to do today. We usually report blockers and issues we run into and re-align on technical decisions. All developers attend, together with the Product Manager, the Product Designer, and the Scrum Master.
In TUI Musement we’re organized into Agile Domain Teams: each team is responsible for a specific area of the business, like payments, orders, products, content, integrations, and many others.
We work on different platforms: B2C websites (like www.musement.com and www.gotui.com), B2B solutions for suppliers, partners, and affiliates, and internal tools for data management. The teams share the ownership of these applications, implementing solutions related to their specific domain.
Historically our data source and API provider is a PHP monolith reading and writing from a MySQL Database but recently we’ve started to extract functionalities into separate microservices written in Golang, Java, and .NET as it is more tailored to the needs and separations required by the domains.
In addition to that, NodeJS, Golang, or PHP API Proxies serve specific web applications following the Backend For Frontend architecture. We use them to merge and select data from different APIs so the frontends will receive only those strictly needed.
Most of our frontends are written in VueJS and more specifically, with the NuxtJs framework. Since the codebases are shared between teams, we required a fast and consistent way to build them. NuxtJS is serving this purpose very well since its structure is simple and strict so we know we’ll find the same patterns across all our platforms!
Also, on the Frontend, we use the so-called Shared Components: VueJS components, developed in a separate repository, which can be configured and imported as NPM packages inside the NuxtJS applications. Thanks to this, we can plug and play shared functionalities (search, product pages, checkout, and payment flow) across all platforms without rewriting them all the time.
10:15 AM
Stop talking, let us get some work done!
During the Daily Scrum, our Product Manager pointed out a bug that urgently needs to be addressed. It’s not clear if the issue relies on the backend or in the web application.
I think it’s a good idea to reach out to one of my frontend colleagues on Slack and see if she has some time to do a pair programming session with me for the analysis. Luckily, she has already started to investigate the issue and can provide me with the cURL that is replicating the issue.
It seems that the controller of the endpoint, inside our new microservice, is not handling an edge case. Before implementing the fix, I’m going to write the unit test for that case and, as expected it fails. Now I can work on the controller and finally the test is passing: looking at the green ✅ is always a big satisfaction!
The next step will be to restart the service inside the docker container and locally check if the cURL is now returning the expected response. It’s working! 🎉. Now I can commit the fix and open a Merge Request in the Gitlab repo, adding all my backend colleagues within the team as reviewers. For the Merge Request, we have a template that helps us to explain the changes in detail, highlighting the WHAT, the WHY, and HOW to TEST them.
In the description, I will assume that the reader has a low context about the project and the code base, so I add a lot of extra information.
After my commits, a pipeline will start, running the unit tests and deploying a feature branch to an ephemeral environment. I’ll add the cURL in the Jira ticket so the fix can also be validated by the testers before releasing it to production.
12:00 AM
On Slack, we have a channel in which we report the new MR we opened. I add mine but I also see that I need to review some others opened by my colleagues.
I spotted one on an API Proxy I was working on during the previous Sprint; I have a lot of knowledge on that code-base: maybe I can give some good suggestions and finish the review before lunch.
1 PM
It’s lunchtime! Yesterday I went to the office and we decided to go to our favorite seafood restaurant. They prepare delicious dishes of Sardinian cuisine and it’s always a big pleasure for us all to go there.
Today it’s different, I’m at home and luckily, it’s a sunny day: the perfect weather for a short jog around the park nearby my home and an easy-fresh meal before reopening the laptop. This will also help to re-establish the balance after the generous meal we had yesterday: they always treat us very well 😋.
2 PM
Today I have a 1:1 with my manager. In this weekly appointment, I can share updates, learning, and achievements and she will give (and ask for) feedback. Above all, it’s a space to discuss skill development and career growth.
I usually prepare the topics I want to discuss in advance, to be sure we cover all the points that are important to me.
2:45 PM
If I don’t have other meetings in the afternoon, I can focus on a new feature I started to develop a few days ago. I want to introduce an external library in my application, but I’m not sure it’s a good idea so I reach out to a colleague in the Performance Team. The Performance Team is a cross-domain team, focused on performance, shared standards, and best practices. She proposes a simpler alternative already used by another team, that is perfect for my use case. I’m able to complete the implementation and open another Merge Request.
5 PM
It’s time to write down an idea I had and want to explore. I’ve often heard about GraphQL, but I don’t know it well and I’ve never had the time to research it or use it in a real-world project. My team is using RESTful APIs, and we never really considered it as an alternative. I would like to study it, to understand if we could benefit from it. This topic seems like a perfect candidate for Tech Friday!
Tech Friday is one of the things I love the most about working in TUI Musement. We can dedicate a day every week (Friday, as you can imagine) to develop our skills, both hard and soft. I can’t imagine a better way to conclude the week. Software engineers have the chance to decide how to spend their time and the projects they will work on. We can choose to study new technologies, experiment, read a book or improve the existing software, focusing on aspects like performance or monitoring. We can do it both individually or in collaboration with one or more teammates. At the end of the project, we’ll share the result with the colleagues, so that they can benefit from it too.
The outcome can be a proof of concept, in which we demonstrate the feasibility of an idea; an internal tech meet-up; an architectural decision record to document a software design choice; a Confluence page to be shared with the company.
Sometimes we write articles describing a project which started during Tech Friday. You can find them on our tech blog. Besides the already mentioned shared components approach, a good example is how to measure the performance of a web application with Lighthouse CI in a GitLab CI pipeline. Or the article describing how to create a UI library with Web Components.
Today I want to formalize my proposal about GraphQL. I will spend some Fridays trying to analyze the pros and cons, and together with a colleague, I will implement a PoC, to make sure that it fits all our requirements. I send the plan to my engineering manager, who promptly approves it. Tomorrow will be an interesting day.
6 PM
It’s time to turn off the pc. If I’m working from home, I can spend some quality time with my family and my friends. If I’m at the office, it’s time to think about the aperitivo with my colleagues.
Kudos
A big thank you to Marco Ziliani who helped me write this article.
