What’s in a name?
Hi, I’m Owen, an Engineering Lead looking after front-end engineering across the Partnership. Today I’d like to talk about changing the name we use for Front-end engineers in the John Lewis Partnership.
When I joined John Lewis & Partners nearly three years ago, we had a group of people called UI Engineers, who built the front-end of our johnlewis.com and waitrose.com websites.
I’ve felt for a while that the name UI Engineer didn’t speak to the complexity, breadth and scope of the work that we as engineers who work on the front-end deal with, so I’ve recently been re-branding UI Engineers to be called Front-end Engineers. I thought I’d write a blog post to help explain why.
A simple UI
When I think of a User Interface (UI), I tend to think about what a user would see and interact with in a web page.
For this example, we’re going to use a simple sign-in form.
This sign-in form has 4 main components:
- A heading (Sign in)
- An email field with a label
- A password field with a label
- A sign-in button
Things to consider when building this UI
Here are just some of the things I would consider when building this UI:
- When the user enters an email, how do we check that it’s a valid email address?
- Does the password meet any requirements with letter/number combinations?
- How do you let the user know if something is wrong?
- What happens when the user clicks on the button? Does it send something to a login API?
- What happens if something goes wrong when connecting to the API?
- How do we protect against people trying to hack into our database through our form?
- What if the user doesn’t have JavaScript enabled? Or what if it doesn’t download before they fill in the form?
- How do we make the page as fast as possible?
- How do we make our page accessible to all users?
Wow, that’s quite a lot to think about already, and that’s “just” a simple sign-in form with 4 components. Imagine how much there is to consider when you’ve got a much more complex app!
So, as a “UI Engineer”, I’m concerned with all these things in just building my User Interface. You’d think that would be complicated enough, right?
Let’s rewind a bit…
So how do we even begin to build this UI?
It’s decision time!
Most websites/web apps are built using HTML, CSS and JavaScript but these days there are many, many ways to work with these technologies. We need to make some decisions:
- Which devices and browsers do we need to support?
- If we need to support older browsers, how do we translate modern JavaScript into something these browsers understand?
- Are we going to use a framework/library e.g. React?
- Do we need to use a package manager e.g. npm?
- How are we going to break up our app in to re-useable components?
- What flavour of CSS do we want e.g. CSS modules, CSS-in-JS, SCSS?
- How are we going to communicate with the API?
- How are we going to test our app? How do we write unit, integration, visual regression and end-to-end tests?
- What does our app architecture look like e.g. serverless, server rendered or client side?
- If we have a server we have more control, but we have to manage it. How do we do that? How do we scale up in times of heavy traffic?
- Do we need to consider routing and state management?
- How are we going to do A/B tests?
- How do we make sure our app is secure?
How do we get it in front of customers?
So we’ve decided to build a nice shiny, fully tested server-side rendered React app, how do we get it into production?
We’ll need a to put our app into a container so it can be deployed to a cluster, so we’ll need to know about Docker and Kubernetes and Google Cloud.
We’ll need some kind of automated pipeline to run our tests and get it into our Cloud environment, so we’ll need to know about CI/CD pipelines within Gitlab.
We’ll need to monitor performance of our app and our environment and respond to issues.
So what’s the point?
The complexities and responsibilities of working on the Front-end have increased exponentially in recent years, far beyond just building User Interfaces.
Traditional responsibilities include:
- Working with UI and UX designers to make sure we match the design perfectly
- Making sure what we build is accessible for all users
- Making sure our app performant, measuring and correcting performance issues
- Testing things across browsers, devices and screen sizes
Modern responsibilities also include:
- Component-driven design, designing our own abstractions
- Site-level and application architecture
- Routing
- Writing unit, integration and end-to-end tests
- Fetching our own data
- Caching
- Talking to APIs
- Mutating data
- State management
- Operability
- Security
The rise of JavaScript as a ubiquitous multi-purpose language, huge advances in tooling and libraries, along with the adoption of software engineering principles, have made Front-end engineering more involved and complex than ever. I don’t think the name UI engineering speaks to this complexity.
So, from this day forth, we shall hereby be known as:
🥳 Front-end Engineers 🥳
In the John Lewis Partnership we value the creativity of our engineers to discover innovative solutions. We craft the future of two of Britain’s best loved brands (John Lewis & Waitrose).
We are currently recruiting across a range of software engineering specialisms. If you like what you have read and want to join us, take the first steps to a rewarding career in technology.
