Tech in Football: the innovation kills the tradition?

André Luis de Oliveira — Mon, 17 Feb 2025 01:22:34 +0000

In early 2025 and this topic still open: the technologies used in modern football kills the tradition and the emotion of the 'old football'?. Our answer isn't so simple as it appears to be. In the past years, we are using even more features than ever, features like VAR, data analysis in apps like SofaScore, Footstats and we also can talk about the mordern arenas replacing the old and traditional stadiums. This points make us think about and agree with a point: the football as we know are changing and evolving with the techs.

About VAR, in the middle 2022 it was such a polemic because of the human failures and bad use of this feature. Nobody was a hundred percent against it. But the main topic that I came here to talk is about data collect and analysis. It was a feature that the clubs use for a lot of reasons: scout, hiring new players and even to bet's market.

For the data and tech enthusiasts, apps like SofaScore are the main tools to review a player performance, looking to ball-pass rating, shots on goal, expected goals and a lot more.

It's undeniable that we have a lot of freak players like Erling Haaland that scored 23 times in 17 first appears in 2022/2023 season. Obviously the numbers are by your side, being considered the best striker of this generation. But in some cases, some players will be wronged in this analysis and it happens because the way that this data collect happens.

The following text came from https://www.sofascore.com/news/pontuacoes-estatisticas-sofascore/:

"The football is a game that valorizes the goals, if you are part of a goal, your contribuition will be valorized even more in sofascore pontuation. Even further, football is more than just score goals, and we try to consider this complexity when we are creating a algorithm looking to give a equal oportunity to all players get a big pontuation. Looking this way if a player got a lot of disarms, fundamental passes, dribble and interceptions, theoretically, he can receive a higher pontuation than a player that scored twice but isn't involved in the match. It's about sports science that doesn't allow pre-concepts because it all goes to a machine that break tens of statistics to produce this pontuation."

Despite this concern about the automation of football, algorithms doesn't look at a lot of facts. A lack for example: for the algorithm never will be a nice thing, but in 'real-life', a good lack can stop a counter attack that allows the adversary to score a goal.

Pre-assists also are a topic to be discussed, regardless of the good numbers in analysis plataform, Bruno Guimarães from Newcastle United have a very peculiar characteristic: the dept pass between the defender and the side player, that allows a cross to the area. In this case, this pre-assist is contabilized just as a normal pass, when in reality it represents a trigger to a ofensive construction.

This cases that I talked about are just some of the many problems that this data collect as we have nowadays can interfer in reality. This is something embryonary but I believe that this metrics have a lot to get better and help the clubs and the managers to deal with the players and competitivity of the championships, looking for better performances and funnier games to watch.

The fact is: this is happening and we have to look about it. We cannot let the bad reasons like BET's analysis and this 'newbie' way to collect data affect the evolution of this sport that we all love so much.

In the end: everything evolved with techology, why not football?

Unpacking Tao of React #1

André Luis de Oliveira — Mon, 01 Apr 2024 21:50:29 +0000

Imagine you're a front-end dev and you don't know anything about software architecture. Now, imagine you have an interview tomorrow at exactly 7:32 AM and you need to absorb some core concepts—fast.

While browsing the internet, you stumble across a specific book—but unfortunately, you don't have enough time to read it (after all, the interview is literally tomorrow at 7:32 AM 😵‍💫).

If that sounds like you, this article (and the next ones) are for you.

The book I'm talking about is Tao Of React by Alex Kondov.

I decided to re-read it and share a few thoughts on how using some of its concepts worked for me in production. I'll go through specific topics—from folder structure to external libraries and state management decisions.

Let's dive in!

1 - Architecture

initially just folder organization lol

1.1 - The common module

The idea is simple: if you'll reuse it in more than one place, toss it in a common folder.

Not just components—hooks, helpers, utils, anything reusable. Abstract it and centralize.

Why?

To avoid duplication and make maintenance easier.

1.2 - Absolute paths

This might sound like nitpicking, but once your project scales, you'll be grateful for following this.

Avoid this:

import { foo } from "../../../../common/helpers/foo";

Use this instead:

import { foo } from "@common/helpers/foo";

Why?

Clarity and flexibility. If you ever refactor folder structures, your imports stay clean and understandable.

1.3 - Wrap components inside folders

Think about how you organize your clothes—you don't mix shirts and pants randomly.

Now think about your components the same way.

What's easier to understand and maintain?

❌ Bad:

✅ Good:

1.4 - Route/Module structure

Simple rule: Separation of Concerns.

Each page (or module) should only contain stuff related to itself.

If you're in the home page folder, there shouldn't be any code about the dashboard there.

Easy.

1.5 - Modular dependencies

Here's where I respectfully disagree with Alex Kondov.

He mentions the Rule of Three: it's okay to repeat something up to three times—on the third time, refactor and abstract.

But I say:

If you're using something from module X in module Y—it's already reusable. Move it to common. Why wait?

1.6 - External components

Imagine using a UI library's Button like this:

<Button>Click Me</Button>

Suddenly, the library maintainers change it to:

<Button placeholder="Click Me" />

Now you have to refactor every instance.

Solution?

Create a wrapper around external components. So if the API changes, you only need to update it in one place.

Yes, the example is exaggerated—but the lesson stands.

What's next?

In the next article: How to create a module efficiently?

Basically, a step-by-step to not mess things up when modularizing your app.

That's it for now!

Hope you enjoyed the read—I'm writing this the way I wish someone had explained it to me. Feedback is welcome ✌️

Forem: André Luis de Oliveira