For the curiosity of our technical readers, I would like to share a story on challenges in software development and how the firstly invisible (but necessary) contributions eventually become part of an improved customer experience. The challenges include tackling open-source upstream dependencies, finding balance between reusability and customization and, importantly, impacting colleagues for the better. Here is my conversation with Greta Krylovaitė, Front-End Software Engineer in the Cloud2 Squad, Development Productivity Tribe, who started her journey at Danske Bank in Future Pros program a year and a half ago.

Greta, tell the readers about yourself, what do you work on and how does your day look?

I work as a front-end developer for the Cloud2 Self-Service Portal. Currently I am focusing on our codebase partial revamp, making sure we get rid of security bugs, legacy code, and various clutter as much as possible, while also implementing and improving new UI features. For a regular day, I have discovered a daily routine that works best for me: first thing in the morning I try to do code reviews, if I have time before daily stand-up, I continue working on my task or release my reviewed PRs if I have any. After stand-up and lunch, I work on tasks I have planned for my sprint, do some reading, and attend meetings.

Can you tell us a bit more about the Cloud2 product and how is the user interface is built and architected?

The Cloud2 portal is built with Angular (which implies TypeScript), NRWL NX, RxJS, NgRx, Node.js, Express. Our frontend also consumes Python based API from our back-end team and our own UI kit on which we collaborate with AGE team’s front-end engineers.

Cloud2 UI architecture consists of separate libraries for each component (courtesy of NRWL NX), NgRx store data access layers for components’ state management, legacy Node back-end (transitioning to Cloud2 API) and practical details in-between. We have separated UI components like buttons, dialogs, badges and so on to UI kit for convenience and use it as a library.

Recently you have completed a major Angular framework upgrade, how do you feel about it?

I feel simply great because it was my first independent major version upgrade which immediately consisted of 3 migrations (Angular 9 -> Angular 10 -> Angular 11 -> Angular 12) and I love a good challenge. It took me some time, but I am glad to say it was released without any bugs (or at least, nobody complained).

In your opinion, what are the benefits of doing such upgrades where not so much is visible for the end user?

The most benefit from major framework version upgrades translate to user benefit in later stages of development. What I mean is, with new framework we get a lot of bug and security fixes, also new inexpensive features, optimizations, which help us develop a better product for our users. One of the notable example features is the nullish coalescing operator, which will reduce the number of checks for undefined and null values in the code.

What was the top reason for having this huge upgrade now specifically in Cloud2?

Biggest visible need for upgrade came from our modern design. The Cloud2 portal step by step introduces a contemporary design and we continue to revamp our look to keep the portal tidy, fast and light. Another example is that the Angular Material 10 introduced stepper component which we plan to use, so that we do not build our own from scratch. Later we started collaborating with AGE team and for that to work we agreed to keep one major Angular version behind. And every Angular framework major version has just 12 months of long-term community support.

How does your team look and how they were impacted by this? 

Cloud2 front-end team consists of 4 developers: me and Alanas joined around a year and a half ago as a part of Future Pros programme and because it worked so well for us, our team decided to take 2 more Future Pros last year – Benas and Mikas. Angular version upgrade impacted the whole team, firstly: in code linting, tslint was deprecated so we all had to move to eslint. Angular Material theming uses slightly new syntax, new Material components, faster builds, View Engine deprecation in favour of Ivy, improved builder phase reporting, logging and so on. Practically speaking, the build process is now faster both when it works well and when it does not.

Major upgrades normally go one major version at once. This one was a 3-in-1 upgrade. Wasn’t that risky?

The 3-in-1 upgrade was not as risky, but it was time consuming. Angular does not support migrating across multiple major versions at once so it is less prone to bugs and surprises, however, as I mentioned, this approach takes some time.

It is more like when you must change tires for a running car and participate in a race at the same time – while the work on upgrade goes on, the team also works on other features, which must be eventually merged with the upgrade.

What lessons did you learn? How will your code maintenance practices change?

The most obvious takeaway is to not put off major version upgrades for later. From now on, our team agreed to stay one major version behind since we have some resources and expertise to spare for our code maintenance.

Any advice for fellow software engineers on code housekeeping? Tech debt?

Be up to date with new versions (the irony, I know), invest time in writing clean code (less spaghetti to maintain) and push your teammates to clean-up as well. At the end of the day there is no such thing as perfect code, but we can always try to improve and learn from our mistakes.

That was an amazing journey. Thank you, Greta!

Feeling inspired to start your own Tech career journey? 👩‍💻
Visit our Future Pros page and APPLY for participating in the program!