A day selling lechugas (as a backend engineer)

Here at Mercadona Tech, we have a mantra:

“At the very end, all we do is sell lechugas” (lechuga in Spanish means lettuce).

This is an informal way of saying that any component in the team, from a warehouse picker to our CEO, has to base its decisions thinking on whether the option makes us sell more (or better) lechugas or not. I, as a backend engineer, am not exempt from this mantra. In this article, I will try to explain what a day of a backend engineer focused on selling lechugas looks like.

It’s 09:00 AM, and I’m arriving at our offices in Plaza América in València (today, I’ve decided to go to the office to have some human interaction). In my team, Organization, we have our daily standup set at 09:40, so I still have some spare time before it starts. After commenting on the film they watched yesterday while drinking a coffee with a couple of colleagues, it’s time to check Slack and take a look at some pending messages.

I usually spend the first minutes of my day checking our systems’ health: check application’s metrics, response times remaining between acceptable times, no errors raised nor issues reported by our stakeholders, etc. Here, at Mercadona Tech, we work on self-organized teams, so we have the freedom of taking any decision we consider appropriate to reach our team’s goals, but we assume the responsibility of our decisions, though. Ensuring the health of our systems is part of that responsibility as a backend engineer of my team.

But going back to my day: it’s 09:40 AM, and it’s time for the standup daily: the moment in the day in which every team member puts in common its progress with the rest of the team.

Today we start a new sprint. The top priority User Story in the sprint is related to a new integration with Mercadona’s intranet (our mother company) that will let us sync the warehouses’ workforce data of our systems with its official source of truth without requiring manual intervention. The way to tackle this integration is entirely open. There are many valid approaches with their corresponding pros and cons, so we’ve planned a mob programming session to reach a fast and valuable solution while ensuring consensus between the team members.

The session starts, and the first question is: how can we cheaply reach a minimum product that we can quickly put in production and let us learn about the validity of the solution? This question triggers the debate and enables the communication to start flowing between the participants: are there similar problems already solved by other teams? Are we ok with the value-effort of the approach? Any clear edge cases we should cover? Let’s draw this idea on the whiteboard.

The outcome of this discussion is a consensus on the path to follow to face the integration, and the next step comes right after the agreement: immediately start coding it! We know which should be the behavior of our system, so that’s exactly what we start coding: the first red test that our system has to pass to ensure it does what it’s supposed to do. Doing TDD helps us a lot by focusing on what adds value to the system (what makes the test turn green) and avoiding wasting time on unimportant details (any other thing not making the test turn green). If you’re not familiar with this, my colleague Juanjo details it well using an outside-in approach in his recent article.

After the first participant ends up adding the first red test, it’s time to switch to the next developer that writes the minimum code that makes the test pass. Refactor the code together, and start the loop again by adding the next red test.

All this process ends up having a Pull Request ready to review with the basic functionality of the integration. Something pretty small but with enough entity to be put in production and let us validate our approach without too much effort (and all this with just investing a few hours!).

There’s something still pending to be able to put this code in production: define how it’s going to be deployed in our infrastructure. Yes! Here at Mercadona Tech, all the engineers, not only backends, are somehow DevOps in this sense: we implement it, deploy it (and take care of it!). To achieve this, our beloved SRE mates help us with many tools that make this task easier for us (and even you can ask them more specific questions by just paying a chivito!). So thanks to this help, this part is pretty straightforward and doesn’t require too much effort from the developer’s side, but let us precisely define what we want to deploy, and even more interesting: how.

So, after a funny and productive coding morning, it’s time for a break! It’s a perfect moment to disconnect a bit: some mates go to the gym or take a walk in the old Turia riverbed Park, near our office. Others like me prefer to take a coffee after lunch and invest some spare time with my team colleagues.

When I’m back at the office, it’s time to check Slack again and review a couple of pending PRs. And meanwhile, our PR for the integration has been approved, so it’s time to merge it!

In order to check how this new feature works once integrated with the rest of the systems, we firstly deploy everything into our staging environment: an entire stack of applications and services running in a pre-production environment where we can perform end-to-end tests and see how the change behaves. Almost everything is normally detected on this step with any potential dependency incompatibility, misconfiguration, broken contracts on exchanged messages between systems, etc. almost everything is usually noticed on this step. And if everything follows the expected path, the next step is to deploy it to a single warehouse, the one that we call laboratory.

Why do we first deploy to laboratory warehouse and not to all of them together (laboratory + stable warehouses)? To ensure learning can happen fast without assuming a high risk.

It’s in our nature to deploy many small things many times a day with the primary purpose of understanding whether the changes were correct or not. And be able to decide further iterations with the learnings we obtain (data, performance -metrics-, plus real impact in our laboratory warehouse).

Suppose any unexpected behavior arises or that the system performance is degraded. In that case, we can be sure that it has a relatively small impact (just one warehouse Vs. N warehouses) and quickly roll back the release, identify errors and iterate the solution before moving it to stable. Another extra ball of this approach is that the environment makes it friendly for the developer to deploy several times a day. We do very few releases with pretty small changes. When an issue is raised, the detection time tends to be relatively small since only a small set of changes might be causing the disruption. Fortunately, this time everything worked as expected, and we can move it to production and let it run as planned (during the night).

So my teammates and I leave the office having finished the first. Small iteration of a vast integration, knowing that tomorrow we’ll be able to check whether our approach is valid or not to solve this enormous challenge and decide further steps based on the learnings we obtain from it. So the first feedback loop will be completed with just investing one day of work. Not bad, huh?

So, before finishing my day, I want to answer a question you may be asking yourself: “you spoke about development approaches, how you deploy, self-organized teams, but… what about the mantra of selling lechugas?”.

It was all about selling lechugas, my friend!

As our CTO says, it doesn’t add any value to having a tech monument if it cannot sell more lechugas. By applying techniques like TDD, frequently going to production, and doing it with really small things, we focus on providing the right solutions for the right problems. Without assuming the risk of investing time in solutions without actually determining if they help us solve our problems or not. The backend engineers we are looking for are those aligned with this culture and methods, with the required technological knowledge to deliver value fast and simplify problems, helping the team focus on what adds value to reach our objectives.

Are you aligned with our culture and values? Does this look like a challenge for you? Then check our open roles!