Remix In Production at Tesco - An Interview With Hugo Jobling - Part I/II
Remix has been out for a while proving its worth in the trenches. Now's a good time to gather some evidence whether it lives up to its promises or not.
Hey Full Context Developer
(I’m writing in a personal quality, opinions are mine and are not reflective of Tesco’s)
Today, we are doing something different. As the title says, I will write about Remix but the format is going to be new for this publication. The framework has been out for a couple of years so enough time has passed for the frontend community to learn about how and when to use it best. I thought now is the right time to re-evaluate its benefits based on real-life experience.
And to do that, a special opportunity presented itself. As you might know I recently joined Tesco and it turned out that the principal software engineer on our project, Hugo Jobling was a very early adopter of Remix. I recently managed to grab a few hours of his time to talk about it. Some of you might remember, the framework was first published as a pay-only product. Hugo bought it in the earliest days and used it ever since in multiple projects. One of them is running in close to two thousand Tesco stores across the UK.
Below you can read the edited version of the interview. I arranged it in sections focusing on specific topics. As the whole thing turned out to be quite long I will be releasing it in parts! Here’s the overview. The first part will cover the first 3 topics and the second will focus on Remix and the RAP.
📖 Career
Hugo’s professional history, following the evolution of the web from the very beginning of the 2000’s as a kid to adopting React in 2013 to becoming one of the earliest users of Remix
How he made ethical choices about certain industries
Where can an engineer be the most effective
🛒 Tesco
Why Hugo joined this company. (I chime in too)
An insider’s look of working at Tesco as a software engineer
Some of the unique benefits Tesco offers for professional development
⚛️ React
What he learned from using React for a decade
How he made successful early adoption decisions multiple times
What were the unique benefits of early adoption for his career
🎛️ Remix
How to cultivate a great taste for technology choices.
What types of applications are best suited to built with Remix
How Remix offers more than Next.js
🙋♀️ RAP
What’s a RAP and why is there one in almost 2,000 Tesco stores
How to handle real-time data with the Remix architecture
How well does it do in production
Recording this interview was super fun and insightful. I’m sure you will enjoy it too. Huge thanks to Hugo for the conversation. You can find out more about him at: thisishugo.com (which is a tiny Remix site btw…) For a teaser here are some quotes:
“Having been built and working with large scale React applications for years, you realize, as everybody realizes, that it's called Create React App, it's not called Maintain React App. And there's a reason for that.“
“When I work on a Remix application, I'm really productive because when I'm following the happy path, the pit of success, it pushes you along like a tailwind.“
- Hugo Jobling
👋 Intro
Joe: Let me start with a quick rundown of my plans for this conversation. I would like to cover two main topics. First, to get to know you a little bit better as a software engineer and as a person. And then, to learn about your experience with Remix and what are some of your takeaways from using it on multiple live projects.
✍️ Author’s Note: If you are already familiar with what Full Context Development is and the history of this newsletter feel free to skip to the next paragraph.
Let me tell you a bit about what this Full Context Development stuff is and how I came up with it. It’s obviously strongly connected to this newsletter too, which grew out of my work on my own project. I developed an “online book” - you can check it out at: fullcontextdevelopment.com - where I tried to distill my experience about making good technical decisions based on targeted business outcomes and to extend it with deep research from the knowledge of the wider software development industry. It sucked quite a bit I guess, only attracted 12 customers. What actually got some real interest from people over the internet was the tech reviews I wrote as a marketing effort. I’ve reviewed Remix and Next.js using the system I established in the book. And they got published in React themed newsletters like This Week in React, React Newsletter and Awesome React Weekly from LibHunt. From then on people started to sign up to my own newsletter through the book’s website. That’s how all of this started. The main goal of what I'm doing here is to give people insight into the most recent front-end technologies by answering questions like: How much value will they provide for your projects? How will they impact business results? How could they influence your career? The core of this approach is simple, all we have to do is focus on five impact factors: CPU-DB. Customer Experience, Productivity, Utilization, Direct Costs and Business Opportunities. I’ve spent around two months distilling those 5 factors while I was looking for the smallest subset of “things“ that can connect the full range of business outcomes with the complete set of technical attributes of software and programming. And people are signing up to the newsletter. Not in droves, not like crazy, but steadily and the pace is accelerating. That's something I’m super proud of and grateful for.
📖 Career
- From building websites at 10 to Principal Software Engineer at Tesco
Joe: I’ve been planning to write about Remix recently, and as I heard about your experience with it, I thought it would be the perfect opportunity to get someone’s perspective who actually used it in production for years about the strengths and weaknesses of the framework . Later, when we had the chance to talk more in-person, during your visit to the Tesco office in Budapest, I realized that you are a really interesting guy to talk to.
Hugo: Well, give the appearance of one.
Joe: No kidding, and I'm super excited to do this interview. I would love if you could introduce yourself for the readers, maybe by walking us through your career. I know you started out in tech journalism. How did that happen? And then how did you transition into software development?
Hugo: After finishing my A-levels I wasn't going to go to university. I had a six-month fixed-term contract job working for the Department of Work and Pensions, just to have some disposable income. I knew that wasn't going to be a career so I was looking for other opportunities. I used to read this website called Trusted Reviews. (Spoiler: this is a link to all of Hugo’s contributions there.) During this time, they posted a job advert, and I was like, how high can it be? I could write. I like writing. I like tech. Also I was active on the forums. So they knew who I was. I sent in an application, did an interview, and they're like, try again in six months. So I did try again in six months, and then I got a job there.
Joe: Oh nice, that’s not how the story usually goes! How did it continue?
Hugo: I was there for just about four years. And then that company got bought by a bigger organization. The founder left. He was a really great mentor to me. And him leaving just killed the culture of the company and I wasn't really keen on working there anymore. So I became a freelance writer doing individual paid articles, which at the time was a shrinking field and very competitive.
Joe: I guess this was the perfect time to consider a career change. But why software engineering?
Hugo: By that time I'd been playing with development for ages. I did a programming course at school and we did web development as part of our IT GCSEs. But I've been building websites basically since websites are possible to build. I got like 25 megabytes of hosting space for my 10th or 11th birthday and I was building my own, little personal website. It was horrific. I'm glad Archive.org hasn't got it anymore, because it was truly terrible.
Joe: Now you really made me want to have a look at it! But I know how some things are better left in the past so let’s get back to your story of moving into development.
Hugo: I simply thought, OK, how hard can it be? Let's start doing some web dev work. I just started out doing like, oh, you want a single website for your little thing that you're going to do. So I did some of that and then pivoted into a full-time web dev job at a local business developing a point of sale application so clearly I've developed a pattern.
✍️ Author’s Note: Our teams are working on the UIs of the newest Tesco tills so it definitely looks like a pattern.
Joe: How did your career continue from there?
Hugo: So I did that for a few years then took a role at a local-ish e-commerce company. Then I decided that the money was better in London, so I better go work in London. My first job there was at a consultancy, just doing typical consultancy stuff, building prototype apps and the like.
I think that's a useful type of work to have done at some point, especially at small consultancies because it does force you into having to communicate with stakeholders, to learn to cut the chaff and move fast to deliver by the deadline.
It teaches you the mindset of building MVPs, while actually focusing on the minimal and the viable, and solving problems as opposed to playing with cool tech. Because if you spend one out of your two weeks playing with fancy toys, then you will have very dissatisfied customers.
✍️ Author’s Note: This makes absolute sense from the Full Context perspective. It’s no wonder I defined 2 out of the 3 real goals of our work as solving the problems of the users and the problems of the business.
Joe: It was a really valuable experience to have for me too, that’s for sure. I worked in a similar environment for roughly a year, a few months more, and it gave me a really good understanding of how my choices connect to the life of the businesses (clients) I work for. It’s one of the main influences why I started to write my book. But back to you journey.
Hugo: So there's the e-commerce, then the consultancy place, then I worked at a venture capital firm for a short period of time building an in-house software tool. From there I went to a sports betting place called Ladbrokes Coral, which is quite a big UK gambling company.
Interestingly, again, working on a point of sale till system written in React and Redux. That was in 2018 or so. Then you come back in 2021, three years later, and it's like, oh great, I get to see the same problem again. (That’s when Hugo joined Tesco as principal software engineer.) Weirdly with the same tech, because it was started about the same time. I can see all the things we did differently, some of them are better in this place.
When my time at that betting company came to an end I knew that I wanted to do something a little more ethical. Then I saw this role available at Tesco.
And I was thinking about where am I actually effective as an engineer? Typically, I think that I do a better job working on products that I'm actually a user for.
✍️ Author’s Note: This is also encoded in the Full Context mentality. I’ve dedicated two chapters of the book to help people understand the customer’s perspective of the software products we create because we can only do our best work when we have that kind of understanding under our belt.
And I actually was a customer of Tesco. I do use the Till software. And I have opinions about what is and is not good Till software, as opposed to working on some internal tooling for some bank, right? Or like building an insurance product or anything where you're out of touch with the domain. Also, the fact that I had previous experience working on point of sale, React, e-commerce systems, I was like, I can bring a lot of value to this specific role because I've worked on this problem twice before. I know what an approach to it looks like. And so I can actually apply that to this problem space. And then Tesco was daft enough to hire me. So here we are.
🛒 Tesco
- Helping millions of people as a software engineer
Joe: It’s really interesting how your story naturally progressed from a birthday gift of a couple megabytes of hosting space to working at the scale of Tesco in a very high impact position. And I can relate to your motivation for joining this company. I also considered the ethical aspect when I was planning my next move. For me it’s tremendously motivating to know that you help people get something that they really need and that we are working on something *real* instead of *virtual*.
Hugo: Well, that's the selfish side of it, right? The reason I took the role at a gambling company was because the problems were really interesting. You're talking about real-time processing of millions of events. Take for example the Grand National in the UK, it’s a massive event where the same amount of activity happens in the system on that one day as on the rest of the year. You get these really interesting big problems of scale and throughput, that's a fun problem to solve.
But at the end of the day, you're like, yeah, but it is gambling. I go back and forth. Am I making the world a worse place? For some people? Yes. For most people? Broadly, I feel neutral, verging towards unethical. It's not as bad as working for a company that does arms manufacturing. Or tobacco companies. Well, there's no societal benefit to smoking. People enjoy it, but it's not good for you.
On the other hand, I had other opportunities where I could have gone to work for a healthcare startup that was doing healthcare in Africa or something like that. That would be more morally good than what I’m doing. But I feel like Tesco is towards the better end of the spectrum, all things considered.
And there's not a lot of companies where you can have the level of scale and impact and also feel good about it while having the chance to make major individual contributions.
If you're going to work at Google or Meta, you're going to be one of 5,000, 10,000 engineers, there's a very small number of people that have outsized impact. Engineers working on the React team at Meta have more impact than your typical Meta developer. But most people at Meta don't work on React. And I don't know what they've been doing for the last year because it hasn't been releasing updates to React. So maybe nobody works on React at Meta anymore. Who can say?
Joe: Yeah, I don't know either, but I would be surprised if there was no work going on behind the scenes. What I know with 100% certainty is that many interesting things are going on at Tesco Technology. What do you like about them the most?
Hugo: The good side of it is you can affect positively, literally, millions of people. And then also, if you're not careful, millions of people can have a bad day because of your mistakes. But you want to have stakes, right? It makes it meaningful. At Tesco, you feel like what you're doing is actually having a positive impact on society, broadly speaking.
Joe: Yeah, I agree. What I found fascinating in addition to that is the scale of the organization itself and the opportunities that come along with it.
Hugo: This is another thing that attracted me to Tesco. I'm at a point in my career now where I don't want another 18 months and then pivot, 18 months and then pivot cycle. I want to work on something that I get to see the consequences of my decisions in five years' time. And I think that Tesco is the kind of place where you can have that long a career.
✍️ Author’s Note: Most definitely, we have a couple of colleagues who are here for 10 or even 20+ years. Make of that what you will, but for me their depth of familiarity with the domain and the organization is super impressive. They can leverage these assets to easily create seemingly 100x impact.
I have done some smaller greenfield projects from scratch, in some cases, they were 100% my code and nobody else’s. I've been proud of those things, and I thought they were good software. But I've written it and then, I don't see the report from someone three years later that has to maintain that thing as to whether or not they were able to pick up what I did. I want that person's opinion as to my software, right?
Joe: That’s the kind of input you can only get while sticking around for a long time in a stable environment, at a place like Tesco for example. You will plateau in certain aspects of your professional development if you are always jumping around every 18 months as you said.
Hugo: Some of the stuff I'm proud of, like the decisions we've made recently, are things like not only saying it's not time to do a rewrite, but actually having a migration path from what we have today to a better version of it in two years' time, that’s the roadmap I was putting out for this project. It's just an interesting evolution in thinking, being more cognizant of the fact that not everything needs to be disposable.
Joe: I'm in a similar phase myself. I choose Tesco among other reasons to have the chance to learn from the long-term consequences of my decisions.
Hugo: You have a bit more flexibility. You don't have just six months of runway where everything is boom or bust. At Tesco people are rightfully upset when you lose the business money. It's not inconsequential. The situation with our cloud logging is a perfect example. At a time you realize, oh, we're spending X amount of money, and we've been doing that for six months, and we're going to be doing that for the next six months if we're not careful.
Joe: Well this sounds interesting. Why is that?
Hugo: It's externalities, where, as a developer, I just think console.log, right? Of course I'm going to write my logs. But it doesn't occur to me that this log line will get written 1,000 times a minute on 1,000 servers every single day. And that's costing us 10 gigabytes of data a day, which every month is costing us £1,000. One log line is £1,000 of cost a month. An engineer can easily write that line without realizing those consequences. (The numbers are of course made up, just close enough to give you a sense of the actual scale.)
That's money that could be better spent elsewhere. That could be some extra engineers joining the team. Or savings are passed on to our customers in a lot of cases. So this stuff does matter. But like, nobody's getting fired because you were two weeks late or put in some extra logging. And the project will most likely live on for the next five years, and who knows how much longer.
The business problem (the need to collect payment from customers) will be there, even if the specific implementation of what you're doing isn't there anymore. And that's the interesting part, it’s you get to work on the same problem for a long period of time.
⚛️ React
- The experience of working with React for a decade
Joe: That’s what provides the chance to learn from long term consequences and also to become an expert of a business domain. Moving on to the more front-endy topics I planned, one of the things you mentioned is that you have worked with React since at least 2018? When was the first time you used it? What were your first impressions?
Hugo: I've been following it along since its inception. I was there in 2013, straight off the back of the F8 Facebook conference. I was like, let's use this thing. I was, apparently, one of the few people who thought that JSX seemed fine. Some years down the road the bulk of the community got over that initial hump too.
At that time people were excited about React. The pitch that it was "just the view layer" helped, I think. When you're working on existing projects and want one page of our application to be this fancy interactive page, but keep the rest of the app server rendered, React felt like a quite natural fit there. That was what everybody was building. That's how I picked it up.
Then it just turned out that the tooling only seems to get better and better. Fast forward to today and the level of tooling we have is just extremely good. The types of problems that you can solve, even with relatively little ability, is much wider. Newcomers can get a multiplicative advantage, a level up over what you could do 10 years ago.
Joe: How does it feel to work with React after a decade of using it?
Hugo: What's interesting about working in React over a longer period of time, is that one of React's greatest strengths is also one of its biggest weaknesses, which is historically how not opinionated it has been about how you build a React application. And what that has resulted in, at least in the apps that I've worked on, is that unless they were started by the same person and worked on by the same teams, typically every React app you work on is its own thing. I see very little commonality between different React apps. And I think that's also more true for React and the JavaScript ecosystem in general, than it has been for other ecosystems, because there's just more churn in the space.
React today is, in many ways, quite different to the React I learned a long time ago. Hooks are very different to the component lifecycle. And the ecosystem of what you do in React is very different today. But fundamentally, the mental model is the same. Your application as a function of state is kind of still there.
I think they latched onto a really good idea. There's that Guillermo Rauch tweet that says, React is such a good idea, we're going to be thinking about the implications for the next decade. I remember thinking, it's a little bit high, but broadly, he’s probably right. And lo and behold, here we are almost 10 years later from when he wrote that. And we are still seeing the implications of the React programming model all this time later.
Joe: Adopting a library very early comes with a huge risk but has unique benefits as well. What were the positive effects of adopting React early on?
Hugo: There was no guarantee that React was going to be like the big thing it is. But by getting in very early, I had the advantage of, when React becomes big and companies start looking for React expertise, that I've been doing it as long as anybody outside of Facebook can be doing React. Five years ago I had five years experience, which was quite rare. I have now 10 years experience, which is still quite rare.
And so the advantage that has afforded is exposure to more of the types of problems that teams working with React have faced, such that now, when we have our internal issues on the team, and someone's like, oh, I've got this problem with React, odds are I've probably seen it before.
Not because I'm some kind of React expert that knows everything about React. It's as you expose yourself to something for long enough, the same problems tend to resurface.
✍️ Author’s Note: This is where we will stop for this post. Let me know how you liked it in the comments and stay tuned because: