What’s it like working as a front-end engineer at Nutmeg?

Shaun Stone


3 min read

When looking for a new role, wouldn’t it be great to get a true understanding of what you’d be doing daily, the architecture and technologies used and the process of development from beginning to end? The only time you get to ask questions is during the recruitment process and time is limited. In this article, I’ll outline what it’s like to work on the front-end team.

Design system – Nutkit

These days we’ve stopped worrying about pixels being off, wrong font sizes, colours being the wrong hex code and many other user interface (UI) irregularities. Instead, we spend more of our time focusing on writing clean code for product features – using components like Lego building blocks, where we can construct full pages in minutes.

Our components are built with React and are all semantic versioned, so we have full control. We write unit tests with 100% code coverage, visual regression to identify any malformation to our web pages and create storybook links for anyone to preview.

There are times where some UI visuals will be missing in our design system, and this means we can create a new component. A UI designer will provide the blueprint on how it should be built so it’s consistent with our Nutmeg branding. This blueprint is the result of various collaborative discussions between our design and engineering teams, as opposed to being thrown over the fence. This takes place in a design system meeting every Friday where everyone is welcome to join.

Web libraries

So, we’ve covered the UI development side of things, but now let’s discuss the domain-driven development. Each team has their own library that is a collection of npm packages1. These packages tackle a specific area of a domain.

For example, we have a payments team that deals with anything related to payments (surprise surprise), and they have a package called ‘Pay in now’. This package is portable, versioned like our UI components and can be dropped into any application. Here is an example of transaction history from the Valuations & Performance domain.

Development process

Each team works in fortnightly sprints, working on a prioritised collection of tickets (either features, tasks or bugs). You have support of a tech lead and a product owner, so if you have any questions about how the product works or operates, you can get the answers you need to finish your ticket.

There are some very challenging areas technically, so it’s important to bounce ideas off other engineers, and this is what the Front-end Guild is for. Every two weeks, anyone can raise a technical problem – or propose a new technology. I’ve been working at Nutmeg for two and a half years, and I’m still learning new things. This is very important as things move fast in this industry.

Once you have completed your work, you raise a pull request in GitHub, where we require two approvals from other engineers. This is to keep quality control intact, and everyone is aware of what’s happening overall. We encourage strong communication between teams at all times when releasing our changes – it’s so important.

Testing process

To increase our confidence in our code behaving exactly as we intend, we have various forms of automated testing.

Unit testing

We use the tools Jest and Enzyme to write our unit tests. 100% code coverage is enforced using git hooks. Git hooks also allow us to automate code linting with ESLint for JavaScript, and Stylelint for Sass.

Integration testing

The next form of automated testing is our integration tests – where Cypress is our tool of choice. We test domain-specific libraries in isolation and see how they interact with our back-end microservices.

End-to-end testing

The next layer of testing is our end-to-end testing. These tests run through the critical flows of our applications and are very lightweight in nature. We delegate granular testing to integration. For this layer of testing we want to check things like: Can I create a stocks and shares ISA? Can I make a payment? Can I log in?

Visual regression

Lastly, for our design system, we use a tool called Loki to test for visual regressions in components. We check in a snapshot image of the component as a reference image. Once a new change is committed, Loki takes a new snapshot of the components and compares them against the reference image. If the images are not the same (i.e. one pixel is different), the Loki tests will fail, and the pipeline will halt.

All the automated testing is integrated into our Jenkins pipelines and determine whether a build passes or fails.

These measures are part of our front-end testing process.

Summary

Nutmeg is a brilliant and interesting place to work as an engineer. The front-end architecture is sophisticated and evolving. Learning is at the core of the company, and we value code quality as much as speed of delivery. With all the new products and features we’re building, as well as our future plans to scale, it’s truly an exciting time to work here.

Sources

  1. npm is a package manager for the programming language JavaScript.

Risk warning

As with all investing, your capital is at risk. The value of your portfolio with Nutmeg can go down as well as up and you may get back less than you invest.

Was this post helpful?
Let us know if you liked this post
Yes
No
Powered by Devhats
Shaun Stone

Shaun is frontend platform lead at Nutmeg. He works on the technical side of things for our portfolios and drives the development of our user interfaces.


Other posts by