Not a bug.
Not a technical misunderstanding.

A gap.

Hard to put into words at the time, but strong enough that I felt the need to write it down, or rather, type it out.

A gap between the way they approach the internet, and the way I learned to use it.

AI is everywhere now. It’s no longer new.
Whether we see it as an opportunity, a threat, or just another tool, it is already embedded in our daily practices. Every day brings new announcements, demos, and debates.

And in the middle of all that noise, a simple question kept coming back:

Is thinking without AI becoming useless?

Back to paper

Every Sunday, I volunteer at a local association, running website-creation workshops.

That week, while introducing JavaScript and basic algorithms, I suggested a detour.
One that felt almost anachronistic to them.

No computers.
No code editors.
Just paper, pens, and collective thinking.

We described an algorithm in plain language, using pseudocode.
The goal wasn’t syntax, but logic: understanding what happens, in what order, and why.

Only afterward did we talk about JavaScript.

I wanted to convey a simple idea:
as long as a problem isn’t clear on paper, it won’t be any clearer once handed to an AI or wrapped inside a framework.

Laying out a line of reasoning, even imperfectly, is still a structuring step.
It allows you either to write the code yourself, or to formulate a more precise request to a colleague, or to an AI.

What I didn’t anticipate

Once the exercise was over, I asked them to sit at their computers and turn their pseudocode into JavaScript.
No constraints. Total freedom.

Almost all of them immediately opened Copilot.

Not to get occasional help.
But to ask for a complete solution.

What surprised me wasn’t the use of AI itself.
It was how it was used.

The prompts were vague. Very generic.
Even though, just minutes earlier, the logic had been clear in their minds, expressed in plain language and discussed together.

The generated answers worked.
But they were often unnecessarily complex, disconnected from the original reasoning, and hard to relate to what they actually wanted to build.

We could have ended up with something much simpler.
If only the request had been clearer.

Searching doesn’t mean the same thing anymore

That’s when something clicked.

They don’t search the internet the way I learned to.

Reading official documentation doesn’t come naturally to them.
StackOverflow barely exists in their mental model.

Why browse multiple sources when an AI can deliver an immediately usable answer?

From my perspective, that’s unsettling.
But on reflection, it’s perfectly rational.

We learned how to search because we had no choice.
They are learning how to query a system that already produces answers.

It’s not necessarily better.
It’s not necessarily worse.
It’s just different.

After COVID, I had personally distanced myself from StackOverflow anyway.
The atmosphere had become toxic, moderation rigid and sometimes contemptuous. Today, I almost feel relieved that beginners have another entry point.

This shift started long before AI, which only made it more visible.

The question that remains

Leaving the workshop, I wasn’t sure what to think.

Does this generation not know how to search yet?
Or am I projecting a way of working that no longer fits their reality?

Thinking before acting takes time.
And I wonder whether, in our constant effort to save time everywhere, we are making an essential step invisible and therefore optional:

taking the time to understand what we are actually asking.

Or maybe, more simply, I’m just becoming that slightly grumpy, outdated developer, like those who worked with punch cards when computers became more powerful.

I don’t have the answer yet.

But in tech, being a specialist is a fragile thing. A language disappears. A framework takes a sharp turn. Years of habits wiped out by a single update.

This constant instability feeds a familiar discomfort:
👉 Imposter Syndrome.

Because everything moves fast. Too fast. And no one teaches us how to keep running.

Imposter Syndrome

Remember Adobe Flash? If you’re younger, probably not. But I knew devs who built their whole career on it.

It started small — a client project, a fun animation. Then another. And another. They weren’t trying to make a strategic bet. Flash was just there, accessible.

So they learned. They practiced. They got good.

And one day, the shock announcement: Flash was dead. Just gone.

Years of experience, muscle memory, expertise… obsolete overnight.

When that happens to you once, you don’t forget. And the fear keeps coming back: “Will I be able to keep up?” “Will I understand this new framework?” “Am I still relevant?”

Especially when your favorite language — like PHP is for me — keeps evolving. New syntax, new best practices, new standards.

It’s both exciting (progress!) and terrifying (I’m gonna fall behind…).

Because behind every “deprecated” notice lies a little voice saying: “Maybe I was never that good to begin with.”

The hidden weight behind the keyboard

Imposter syndrome isn’t just about doubting your skills. It’s the irrational feeling that you’re a fraud, and that sooner or later, others will “find out.” Even when you’re experienced, praised, or successful, the internal narrative says: “I just got lucky. I don’t really belong here.”

For many of us, this is tied to perfectionism. Every bug feels like a personal failure. Every moment of uncertainty confirms, in our minds, that we’re not good enough. And ironically, the more we learn, the more we realize how much we don’t know. Which feeds the cycle of doubt.

What makes it harder is how little this feeling is talked about openly. We look around and think everyone else is confident and sure of themselves, that we’re the only ones pretending. But in reality, many developers, from junior to senior, wrestle with this silent burden.

AI at the service of humans

But one day, something clicked. A real turning point: the arrival of AI. Not as a threat. But as a shoulder. A mentor. A Copilot.

Not long after ChatGPT launched, I was working on a side project: a Memory Game, just for fun.

I wanted to add a little bonus effect, like a combo in Guilty Gear Strive.
The kind of totally unnecessary detail that just makes you love your project.

The problem? I had no idea how to search for it. Not on Google, not on Stack Overflow. I didn’t even know what keywords to use.

So I tried something new. I described what I wanted — in plain language — to ChatGPT.

And it got me. Not just answered, understood.

It suggested a method, explained the logic, gave me ideas to try. And I ended up getting exactly what I was imagining.

Maybe just a small detail. But for me, it was a revelation.

What if we weren’t alone anymore?

Being able to offload a bit of mental burden, to feel like there’s “someone” there to support you, to explain when you’re stuck, to help you learn… It’s freeing.

I no longer spend two weeks stuck on a blank page, trying to figure out the best way to approach a new framework. I’ve got an assistant. A private tutor. Always available. It explains. It guides.

And with that mental load off my back, I can push myself further.

But it’s not perfect

Let’s be clear: AI isn’t magic. It makes mistakes. It sometimes invents things. It can hallucinate.

That’s actually the word often used: “hallucination.” It might suggest a method that doesn’t exist. Reference a library that’s not real. Mix up syntax from different languages.

That’s why using AI requires a shift in mindset: Don’t take everything at face value.

Test. Question. Validate.

Use AI not as a crutch, but as a sparring partner. A brainstorming tool. A jumping-off point.

This part of the article might become obsolete quickly, given the pace of progress. But as of today (May 2025), it’s still crucial to stay critical and curious.

Paradoxically, that’s also how we grow: not by trusting blindly, but by learning to evaluate, compare, and build on top of what we receive.

The real lesson

Every Sunday, I teach programming to a group of teenagers. And I tell them this:
AI isn’t here to replace you. It’s here to support you. A personal teacher. Patient. Always there. Helping you grow.

Just copy-pasting what it gives you won’t get you far. But using it to think differently, to take more risks, to learn faster… That changes everything.

Un article un peu différent (et en français cette fois) pour partager ma dernière expérience : la découverte (intense) de mon tout premier tournoi d’échecs en présentiel.

La programmation n’est pas ma seule passion : les échecs me captivent depuis plusieurs années. Je joue régulièrement en ligne, surtout sur Chess.com, parfois sur Lichess. Mais ces derniers temps, j’avais l’impression de tourner en rond.

Ma progression s’était ralentie, mes automatismes me piégeaient, et je sentais qu’il me manquait un déclic.

Alors, à la rentrée dernière, je me suis lancé un défi : suivre des cours d’échecs, dans l’idée d’améliorer mon ELO — le fameux classement qui reflète notre niveau.

Quelques mois plus tard, j’avais progressé. Ma vision du jeu avait changé, mes réflexes s’étaient affinés. Il était temps de quitter l’écran pour affronter l’inconnu : un vrai tournoi, en présentiel.

Vendredi 2 mai : le tournoi des gladiateurs

C’était donc mon tout premier tournoi en présentiel. Et j’y suis allé… sans trop savoir à quoi m’attendre.

Je ne m’étais pas renseigné sur le déroulement, ni sur les subtilités du système de points ou les règles spécifiques. Autant dire que j’y allais un peu à l’aveugle. Heureusement, les gens sur place étaient super bienveillants et m’ont expliqué plein de choses utiles :

• 5 parties à jouer (le nombre varie selon les tournois).
• Chaque partie durait 12 minutes, avec un incrément de 3 secondes par coup.
• On alterne les couleurs : si on joue blanc à une partie, on joue noir à la suivante.
• Le classement se fait de la manière suivante : 1 point pour une victoire, 0 pour une défaite, 0.5 pour un nul. À chaque ronde, on affronte un joueur ayant un score similaire. Donc plus on gagne, plus les adversaires sont forts.

Là, le stress commence sérieusement à monter.

En plus du chrono, il faut respecter des règles très strictes :

• La main qui déplace une pièce doit aussi appuyer sur la pendule, sinon faute.
• Une pièce touchée, même frôlée, doit être jouée.
• Une pièce lâchée est considérée comme jouée, on ne peut plus revenir dessus.
• Et surtout : si on ne voit pas que son roi est en échec et qu’on joue un autre coup… c’est une faute.

Les fautes ne sont pas juste symboliques :

• À la première, l’adversaire gagne une minute.
• À la deuxième, c’est perte immédiate.

Ok, pression maximale. Il va falloir rester concentré pendant cinq parties d’affilée. Quelques heures sous tension. Mais je me dis : allez, tout va bien se passer…

Objectif secondaire : un classement FIDE

En tournoi, tout le monde n’a pas encore de classement FIDE (le classement international officiel).Pour en obtenir un, il faut :

• gagner une première partie contre un joueur classé FIDE (un match nul ou une défaite ne comptent pas, et une victoire contre un joueur non classé non plus),
• puis affronter au moins 4 autres parties contre des joueurs FIDE (gagner ou perdre n’a pas d’importance à ce stade).

C’est ce qui permet de fixer le classement initial.

Tant qu’à être là, je me dis que ça serait bien d’en profiter pour débloquer ça. Mais je préfère ne pas trop y penser pour ne pas me rajouter de pression.

Partie 1 — La surprise

La première partie démarre à 20h45. Et là, contre toute attente : victoire !

Je joue les noirs, mon adversaire est classé 1458 FIDE. Il attaque un peu trop tôt sur l’aile roi, sans voir que mes pièces s’activaient ailleurs.
J’en profite, je promeus un pion en dame et je conclue.
✅ 1 point !

C’est une petite surprise pour moi : première partie, première victoire, et directement contre un joueur classé.

C’était pile ce qu’il fallait pour enclencher le processus du classement FIDE. Première étape faite, il faut maintenant que le hasard des rencontres me fasse jouer contre des joueurs classés, et tenter de ne pas perdre contre tous :D.

Partie 2 — Le trou noir (alors que je jouais les blancs)

Pas vraiment le temps de souffler, on enchaîne. Cette fois, mon adversaire est classé 1494.
Et là… je perds totalement le fil. Je passe beaucoup trop de temps à réfléchir à mon ouverture, chaque coup me semble flou. J’entre dans ma tête, j’hésite, je doute.

Résultat : je perds… au temps, il lui restait encore 7 minutes 30 à la pendule. Grosse frustration.
❌ 0 point.

Partie 3 — Le combat jusqu’au bout

Nouvel adversaire : classé 1561. Je joue à nouveau les noirs.
Je suis remonté, je veux me rattraper. La partie est compliquée, tendue. En fin de jeu, je suis en désavantage matériel : il lui reste plus de pièces majeures. “Allez, Julien tu dois tout donner pour ne pas perdre encore une fois”.
Alors je m’accroche, les autres parties sont terminées et les gens viennent de plus en plus nombreux regarder notre partie. Comme si je ne me métais pas déjà assez la pression.

Et je finis par équilibrer la position.

Fin de partie. 20 secondes chacun à la pendule. Les mains tremblent. Match nul, bien mérité.
🤝 0.5 point.

Partie 4 — Le contrecoup

On était les derniers à finir. Pas de pause. On enchaîne.

Cette fois, je joue les blancs contre un 1668 ELO.
Mais je suis encore dans la partie d’avant. Trop d’infos, trop de tension, je n’arrive pas à me reconcentrer.
Mon esprit flanche. Défaite au temps. Mérité.
❌ 0 point.

Partie 5 — L’abandon inattendu

Il est presque 23h. Je suis vidé. Mais je veux bien finir. Une dernière.

Je joue les noirs contre un joueur classé 1370.
J’arrive à prendre l’avantage rapidement, avec un double échec : ma dame et mon cavalier menacent à la fois le roi et une tour. Je prends la tour.
Mon adversaire tente une contre-attaque désespérée sur mon roi, mais dans la précipitation, il place sa dame en prise directe par mon cavalier.

Il essaye de se reprendre, mais la règle est claire : pièce lâchée = pièce jouée.
Le juge de table intervient, et l’oblige à jouer le coup. Il sait que la pièce est perdue, et décide d’abandonner.

Je me sens un peu mal à l’aise face à une fin aussi brutale, mais il prend bien la décision, avec sportivité.

✅ 1 point pour moi.

Bilan

Pour une première participation, je finis avec 2.5 points sur 5. Ce n’est pas exceptionnel, mais je suis content : j’ai appris énormément en quelques heures. Et surtout, j’ai obtenu une victoire contre un joueur classé, ce qui ouvre la porte à un classement FIDE dans les prochaines semaines.

Je ne m’attendais pas à un tel écart entre le jeu en ligne et le jeu sur table. Le stress, l’ambiance, les bruits autour, la pression du temps… c’est tout un autre monde.

J’étais lessivé à la fin. Cinq parties, c’est long. Surtout quand on veut tout calculer pour éviter les erreurs de mouvement et de tactique.

Mais j’imagine qu’avec l’habitude, les automatismes viennent et le cerveau s’épuise un peu moins.

Ce que je retiens, c’est que ça m’a donné envie de continuer. Le plaisir de jouer, de progresser, et même galérer un peu, c’est ce qui rend l’expérience enrichissante.

Alors on continue, j’ai hâte de participer au prochain tournoi. On verra ce que ça donne :)

How do you learn a new language or framework just to test a random idea that pops into your head?
For occasional side projects, it’s manageable. But when your urge to experiment becomes almost daily, it’s just not sustainable.

So, for a long time, I adapted.
I stuck to the languages I knew.
It was frustrating, but at least I could see things through.

And then… AI arrived.
Bringing with it a fresh wave of creativity.

A creative lifeline

Tools like Cursor gave me something I didn’t realize I needed: a smart coding companion.
I tried Cursor on a personal project — more on that in a second — and I was genuinely impressed.
It helped me bring an idea to life in record time.

Honestly? It was fascinating.
A bit scary.
But mostly… addictive.

⚠️ Of course, it’s not magic:
You still need to write proper prompts, understand what the AI is doing, debug, adjust, refine.
But once you get the hang of it, the time savings are massive.

I wouldn’t use it (yet — in April 2025, at least — but AI is evolving so fast that this might not hold true for long) on a critical or deeply complex project.
But for a POC, a quick V1, or a teaching tool? It’s fantastic.

A real-life use case: King’s Board

One of my recent personal projects, King’s Board, is an interactive tool designed to help chess beginners understand influence zones on the board.

The idea came to me while playing, realizing how easily new players miss certain patterns or details:

• Which squares are being attacked?
• Which pieces are defending each other?
• How many pieces are targeting the same square?

I built the backend myself in Laravel + API Platform, as I usually do.
But for the React frontend, I wanted to try something new: I used Cursor to help me structure components, iterate faster, and test UI ideas.

With a single click, users can select a piece and instantly see the squares it controls, which ones are protected, and where the threats are.

It’s not a game — it’s a teaching tool.
And without Cursor on the frontend, I’d probably have taken three times longer to get something usable.

AI doesn’t replace expertise — It amplifies It

Let’s be clear: you can’t go far with tools like this unless you think like a developer.
You still need to understand component dependencies, common pitfalls, and the kinds of mistakes the AI might make (and trust me, it makes them).

But if you have the basics, AI becomes a creative accelerator.

I now see it as a complement:
It lets me skip what I already know, saves me time, and frees me up to explore new ideas.

And if you love tinkering, learning, and experimenting?
It’s a dream come true.

A New Addiction?

Barely have I finished one project, and I already want to start another.
Is AI making devs more hyperactive than ever? Maybe.
But honestly… is that really a bad thing?

Links

• Cursor AI: https://www.cursor.com/
• King’s Board website: https://kingsboard.fr
• King’s Board backend GitHub API: https://github.com/noweh/kingsboard
• King’s Board frontend GitHub : https://github.com/noweh/kingsboard-app

During an update to one of my projects, I encountered an issue during deployment: one of my folders had a capital letter on my machine but not in the Git repository. As a result, everything worked locally, but in production, the file was missing. Under macOS and Windows, renaming a file by only changing its case (e.g., facades→ Facades) might not be detected as a modification. This behavior can lead to difficult-to-identify errors, especially in collaborative environments or during automated deployments.

Why Git can’t detect case changes?

Git tracks files by generating hashes based on their content. I explained this process in detail in this article, but in short, Git also relies on the filesystem's metadata.

On a case-insensitive system (like Windows or macOS in "case insensitive" mode):

• Facadesand facades are treated as the same file by the system.
• Git differentiates between file names but still depends on the system’s behavior.
• As a result, a simple case change might not be detected.

A quick test with git hash-object git hash-object shows that Git does distinguish between two different strings:

echo 'Facades' | git hash-object --stdin
a331da958bcf562a51dc148cf2ae46a106ebed7c

echo 'facades' | git hash-object --stdin
98113d4c6defe216298262d4c80324f58319d340

Now, let’s see a practical test with files:

mkdir facades
touch facades/README.md
git add facades
git commit -m "Add facades"

mv facades Facades
git status
# nothing to commit, working tree clean

git ls-files
# facades/README.md

On a case-insensitive system, Git doesn’t detect the change, whereas on a case-sensitive system (like Linux), the change would be picked up.

Why macOS can be case-insensitive?

Unlike Windows, where the NTFS filesystem is case-insensitive by default, macOS allows you to choose when formatting a disk. By default, macOS uses APFS (Apple File System) or HFS+ in case-insensitive mode, meaning Facadesand facades are treated as identical.

You can check if your filesystem is case-insensitive with this command:

diskutil info / | grep "Case"

If you see File System Personality: APFS Case-sensitive, your system correctly distinguishes between uppercase and lowercase letters. If this mention is absent, your system is case-insensitive.

How to avoid this issue?

1. Use git mv.
   If you need to rename a file by changing only its case, use:
   git mv --force facades Facades
   This explicitly informs Git of the rename.
2. Manually Verify and Correct
   If Git doesn’t recognize the case change, you can remove and re-add the file:

git rm --cached facades
git add Facades
git commit -m "Fix file rename"

In summary

This issue can be confusing, especially when working in teams or across different operating systems. A few best practices can help avoid these problems and ensure that Git correctly handles file changes.

It’s a problem that can easily go unnoticed and waste time, which is why it’s important to understand it and share this knowledge with other developers.

Let me share what I’ve learned about the differences, illustrate a real-world example encountered with GitHub Workflows, and provide solutions to avoid potential pitfalls.

Understanding the differences between getenv and $_ENV

getenv

The getenv function accesses the system's environment variables directly. This means it interacts with the environment in which the PHP process is executed, independent of PHP-specific configurations.

Example:

putenv('MY_SECRET_KEY=MY_VALUE');
echo getenv('MY_SECRET_KEY'); // Outputs: MY_VALUE

$_ENV

The $_ENV superglobal, on the other hand, depends on the configuration of the php.ini file. Specifically, it is populated only if the variables_order directive includes the letter "E". In some environments (like default configurations on certain servers), $_ENV may be empty.

Example:

putenv('MY_SECRET_KEY=MY_VALUE');
echo $_ENV['MY_SECRET_KEY']; // May not work

Required configuration in php.ini:

variables_order = "GPCS" # Add "E" to include $_ENV

The variables_order directive

The variables_order directive in php.ini controls which superglobals PHP initializes and in what order. It accepts a string of letters, each representing a category of variables:

• G: GET variables (e.g., $_GET from URLs).
• P: POST variables (e.g., $_POST from forms).
• C: Cookie variables (e.g., $_COOKIE).
• S: Session variables (e.g., $_SESSION).
• E: Environment variables (e.g., $_ENV).

If the letter E is missing from the directive, PHP will not populate the $_ENV superglobal with environment variables, even if they exist in the system.

Example configurations

Complete configuration

variables_order = "GPCSE"

• All superglobals are initialized.
• $_ENV will be populated with system environment variables.

Partial configuration

variables_order = "GPCS"

• Only $_GET, $_POST, $_COOKIE, and $_SESSION are initialized.
• $_ENV will remain empty.

Real-world example: GitHub Workflows and automated tests

While using GitHub Actions to automate a project, I encountered an issue during the execution of tests requiring secret keys configured in GitHub. My code attempted to retrieve these values via $_ENV but failed.

After some investigation, I realized that $_ENV was empty in this environment. However, using getenv allowed me to access the variables without any issues.

This got me digging into how getenv and $_ENV really work.

Original (problematic) code:

$secretKey = $_ENV['SECRET_KEY'] ?? null;
if (!$secretKey) {
    throw new Exception('Secret key not found');
}

Working solution:

$secretKey = getenv('SECRET_KEY');
if (!$secretKey) {
    throw new Exception('Secret key not found');
}

The case of the vlucas/phpdotenv component

This issue got me thinking about how popular libraries like vlucas/phpdotenv handle environment variables. Curious, I decided to dive deeper into how it works.

The library takes a clever, multi-layered approach to ensure maximum compatibility across different PHP setups. When a .env file is loaded, it doesn’t just stop at one method of making the variables available. It directly populates the $_ENV superglobal by assigning each key-value pair from the file, while also using PHP's native putenv() function to inject those variables into the system's environment. This means they’re instantly accessible through getenv() as well.

Depending on its configuration, phpdotenv can also populate $_SERVER, ensuring flexibility no matter how your code accesses environment variables. This design makes it a robust solution for environments where PHP’s configuration isn’t entirely within your control.

Source for the library.

putenv() and thread safety

When using putenv(), keep in mind that it modifies the global environment for the entire process, which can lead to race conditions in multi-threaded applications.

This is not a problem in mono-thread environment, but in multi-threads environment, this might result in unpredictable behavior.

Recommendations

1. Prefer getenv for accessing environment variables: Especially in environments where you don’t have full control over the PHP configuration (e.g., CI/CD, shared hosting, etc.).
2. Test in the target environment: Differences between local and remote environments are often the source of hard-to-diagnose bugs.
3. Using putenv() is strongly discouraged due to the fact that these functions are not thread safe.
4. Check the php.ini configuration: If you must use $_ENV, ensure that variables_order includes "E" or…
5. Manually populate $_ENV if needed: you can populate $_ENV yourself like this:

foreach ($values as $key => $value) {
    $_ENV[$key] = $value;
}

Conclusion

While getenv and $_ENV may seem similar, their differences can lead to issues, especially in contexts like CI/CD pipelines or shared hosting. By understanding these subtleties and following best practices, you can avoid tricky bugs and ensure better portability for your code.

Have you encountered similar issues or have tips to share?

Un premier aperçu d’une histoire où le virtuel et le fantastique se croisent. Découvrez les deux premiers chapitres en exclusivité, avec d’autres révélations à venir…

Genèse

Dans les profondeurs d’un système informatique, un monde avait été conçu.

Au commencement, il n’y avait que des lignes. Des lignes de code parfaites, tissées avec une précision clinique. Ce monde naquit du travail d’un être invisible : le Concepteur.
Jamais vu, jamais entendu, mais omniprésent dans son œuvre. Chaque fragment de ce programme portait sa signature : une harmonie intemporelle.

Mais tout cela appartient à un lointain passé.

Depuis des Cycles, le Concepteur a disparu sans explication. Privé de son architecte, ce monde s’effondre lentement.

Les mises à jour automatiques, censées réparer l’ordre, corrompent davantage le système. Les structures autrefois solides deviennent fragiles.
Les rares traces laissées par le Concepteur flottent dans l’espace comme des murmures éteints, des commentaires amputés et illisibles :

// Do not ... this part ...
// Beware ... ... core system...

Au cœur de ce chaos, une mise à jour automatique provoque l’inattendu. Une secousse brutale ébranle le programme.
Des fragments de mémoire fusionnent dans un désordre incohérent, contaminant le code intact. Des fonctions oubliées s’activent.

De cette collision chaotique naît une singularité : une entité que personne n’attendait.

Chapitre 1 : l’éveil de \/Fork

Secteur 347 — En bordure de la RAM.

Cycle temporel 0 — Emergence de la défaillance [ *** Donnée corrompue *** ].

Loin des zones centrales du programme, dans un fragment de mémoire presque oublié, une anomalie se réveille. Là, parmi les résidus d’une fonction obsolète, un petit fragment de code prend vie. Une sous-routine insignifiante, oubliée depuis des cycles : \/Fork.

\/Fork n’a pas de mémoire, pas de passé. Il est un accident, réveillé par les chocs de la mise à jour. Tout autour de lui se décompose. Les blocs de mémoire s’effondrent, les constantes agonisent dans des boucles infinies.

Un grondement lointain retentit. Une présence terrifiante approche : le Grand Garbage Collector (G²C).

Conçu pour nettoyer les erreurs et libérer l’espace mémoire, G²C a évolué bien au-delà de sa fonction initiale et est devenu incontrôlable.
Son corps est un dodécaèdre étoilé, dont les pics s’étendent et se rétractent à intervalles réguliers, comme s’ils réagissaient à une pulsation interne. Une de ses faces, massive et lisse, porte un œil immense, un faisceau froid et implacable qui scrute tout sur son passage. Il observe méthodiquement chaque secteur, balayant tout ce qu’il rencontre de son regard analytique.

Son approche est implacable. Il ne distingue plus le bon du corrompu.
Dans sa quête de purification, il efface tout sur son passage, réduisant le code à un amas de fragments inertes. Chaque mouvement est une promesse de destruction, chaque analyse un pas de plus vers l’anéantissement.
Le faisceau lumineux de son œil, plus précis qu’un rayon laser, cherche la moindre anomalie, la moindre imperfection, avec une lenteur terrifiante et une efficacité dévastatrice.

Une impulsion brutale traverse \/Fork : fuir. Son code s’éveille dans la panique, et il se précipite à travers le chaos numérique. Il traverse des fragments de mémoire brisés, évite des fonctions abandonnées, contourne des zones de données contaminées.

Le fracas des batailles résonne autour de lui.

Des entités instables — variables, constantes, fragments — s’affrontent sous des bannières brisées. Leurs cris résonnent dans le chaos. Leurs mouvements sont comme des vagues opposées, chacune suivant sa propre logique. Les lignes de code se tordent, se multiplient, se divisent.

Les variables de la faction ->Serial, avancent en une file ordonnée, sans hésitation. Chaque donnée est soigneusement placée, chacun s’aligne à sa place. Ils sont d’une précision glaciale, et leur progression ne laisse aucune place à l’improvisation. Tout est calculé, ordonné.

Face à elles, les entités de la Classe []Array réagissent en éclats. Les valeurs flottent, se déplacent librement dans des configurations imprévisibles. Elles se réorganisent en données disparates, se répandant en éventail. L’improvisation fait la loi.

Les variables, massives et à la peau d’ébène, dotées de quatre bras, se jettent dans le chaos. Leurs yeux luminescents scrutant les lignes de code pour anticiper les attaques. Chaque mouvement semble à la fois précis et fluide, comme si leur structure même était taillée pour ces affrontements.

Soudain, une collision. Dans sa fuite, \/Fork heurte violemment deux variables rivales en pleine bataille : Serial->128 et Array[42]. L’impact est brutal. Leurs fragments se mélangent, s’infiltrant dans son code.

L’univers se fige. Une règle sacrée a été brisée : l’héritage multiple est impossible. Et pourtant, \/Fork est là, vivant. Une anomalie, un paradoxe.

Le silence se fait. Tous les regards se tournent vers lui.

Puis, le grondement reprend. G²C s’avance, juge final et implacable, dévorant tout ce qui est inutile, tout ce qui ne respecte pas les règles. Un faisceau incandescent fuse vers \/Fork, prêt à l’effacer.

Mais au moment de l’impact, quelque chose se produit. Une déchirure invisible altère la réalité, un glitch. \/Fork est éjecté hors du système, projeté dans un vide numérique.

Quand il reprend conscience, il est seul.
Autour de lui, un paysage désolé, une étendue binaire sans forme ni logique, comme si tout avait été effacé. Les débris du conflit entre les factions ->Serial et []Array jonchent le sol, vestiges d’une guerre pour la suprématie des structures.
Plus de variables, plus de constantes. Juste un silence absolu.

Il se redresse, la panique s’estompant une question émerge dans son noyau :
<”Qui\/​suis\/​je ?”> (Traduit du binaire)

Quelque chose dans ce vide résonne avec lui. Un écho distant, un appel silencieux. \/Fork le perçoit dans ses lignes.
Le paysage est immobile, mais sous cette immobilité, il devine une pulsation, infime. Une vie ténue, un reste.

Alors qu’il fait un pas, puis un autre, une pensée le traverse :
<”Si\/​je\/​suis\/​ici, c’est\/​qu’il\/​reste\/​encore\/​quelque\/​chose. Je\/​dois\/​avancer.”>

A suivre… Chapitre 2 : errance en terres mortes

Bonus : quelques croquis

Programming languages handle it in two main ways:

• Manual memory management: Languages like C or C++ give developers complete control over memory using functions like malloc and free. While this allows for optimized performance, it also introduces risks like memory leaks or invalid memory access. Developers must be meticulous to avoid errors.
• Automated memory management: Languages like Java, Python, PHP, and C# automate memory management using a Garbage Collector (GC). While this adds a small performance cost, it simplifies development and reduces the risk of memory-related issues.

Let’s dive into how garbage collection works and explore the principles it applies.

Memory allocation

Every time you create a variable or an object, the program allocates memory to store it. This memory usually comes from a special area called the heap.

As the program runs, the heap fills up with allocated memory. The garbage collector’s job is to:

1. Identify unused memory blocks that are no longer needed by the program.
2. Reclaim these memory blocks for reuse.
3. Determine the optimal timing for garbage collection to minimize the impact on performance.

Methods of Garbage Collection

1. Reference counting

Some garbage collectors like Python or PHP use reference counting. Every object or variable has a reference count, which tracks how many parts of the program are using it:

• Adding a reference to an object increases its count.
• Removing a reference decreases its count.
• When the reference count drops to zero, the object is no longer needed and can be safely destroyed.

Example:

In Python:

a = [1, 2, 3]  # The reference count for [1, 2, 3] is 1.  
b = a          # The count increases to 2.  
del a          # The count drops to 1.  
del b          # The count is now 0, and the object is destroyed.pyth

In PHP:

$obj = new stdClass();  
$ref = $obj; // Reference count is 2 (1 for $obj, 1 for $ref).  
unset($ref); // Reference count drops to 1.  
unset($obj); // Reference count is 0, and the object is destroyed.

2. Detecting cyclic references

Reference counting alone isn’t sufficient. Consider two objects referencing each other but not being accessible from the rest of the program. These cyclic references prevent their reference counts from reaching zero, even though they are no longer useful.

Modern garbage collectors (e.g., in Python, PHP) include algorithms to detect and clean up such cyclic references.

Example of a cyclic reference:

a = []  
b = []  
a.append(b)  # a references b  
b.append(a)  # b references a  
# If both a and b are no longer accessible, they form a cycle.

3. Generational collection

Some garbage collectors (e.g., Java, .NET) optimize their process by organizing objects into generations, based on their lifespan:

• Young Generation (YoungGen): Contains newly created objects. Most objects have a short lifespan and are quickly discarded.
• Old Generation (OldGen): Contains objects that have survived multiple collections, indicating longer relevance.
• Permanent Generation (PermGen): Used for metadata, like class structures or method references (replaced by Metaspace in modern Java).

By focusing frequent collections on the YoungGen and less frequent but thorough sweeps on the OldGen, these systems achieve an efficient balance.

4. Mark-and-Sweep algorithm

The Mark-and-Sweep approach is a commonly used algorithm in garbage collection:

1. Marking: The GC starts from the root references (global or local variables) and marks all objects accessible from them.
2. Sweeping: It then deletes all unmarked objects, reclaiming their memory.

This process ensures that even complex dependency trees are handled efficiently.

Pros and cons of Garbage Collection

Advantages

• Reduces memory leaks by automatically freeing unused memory.
• Simplifies development by eliminating manual memory management.
• Highly optimized for common scenarios in modern software.

Disadvantages

• Introduces a small performance overhead, especially during complex cycles.
• Can cause pauses in program execution (a concern for real-time applications).
• Its behavior can be unpredictable in memory-intensive or low-latency scenarios.

How to work with Garbage Collection

Although garbage collection simplifies memory management, developers should still write memory-efficient code to reduce its workload:

• Avoid creating unnecessary objects or variables.
• Reuse existing objects when possible.
• Be mindful of cyclic references in complex structures.

For instance, in Java or C#, memory pressure increases when too many objects are allocated without being freed. This triggers the garbage collector to run, which may temporarily affect performance.

Conclusion

Garbage collectors are powerful tools that improve productivity and reduce memory-related errors. While they introduce some performance trade-offs, these are usually negligible in most applications.

By understanding how garbage collection works and adopting best practices, developers can create efficient and reliable programs that leverage the power of automated memory management.

Want to dig deeper?

Here are some resources to explore specific implementations in various languages:

• Python: Garbage Collection in Python (official docs),
• Java: Garbage Collection in Java,
• C#/.NET: GC Fundamentals,
• PHP: PHP Garbage Collection.

The Garbage Collector’s role in programming was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a simple but powerful idea:

“If you can’t explain something simply, you don’t fully understand it.”

As a lead developer, this truth resonates deeply. Explaining, simplifying, and breaking down complex ideas forces us to truly grasp the essence of a technology, tool, or method. When we make complex concepts accessible to others, we sharpen our own understanding.

Every time I’ve had to explain a concept in simple terms, I realized how much I needed to revisit the basics.

Why explaining makes you a better developer

As a lead dev, explaining forces you to formalize your knowledge. What seems obvious to you might be unclear to others, and this process challenges your assumptions. Sharing an idea strengthens your own understanding. It’s a virtuous circle: the better you explain, the better you code.

Simplifying to understand: The case of SSO

Once, I had to explain the concept of Single Sign-On (SSO) to a group with little to no technical background. I had two minutes to prepare, and technical jargon was off the table. A real challenge!

I used this analogy:
“SSO is like having one key that unlocks all the doors in the same building.”

This helped them understand that a single login grants access to multiple services without needing to reauthenticate. For example, logging into Google gives access to Gmail, YouTube, and Drive.

That exercise reminded me of a crucial lesson: explaining means breaking down a concept for yourself before sharing it with others.

The Lead Developer’s role: teach to grow

Being a Lead Developer is more than managing a team. It’s about listening, simplifying, and sharing knowledge. Explaining isn’t a waste of time — it’s an investment. For your team, your project, and yourself.

Back to basics: the autoload example in PHP

Take PHP’s autoload feature. For an experienced developer, declaring and using a namespace feels natural. But explaining it to a junior developer? That’s a different story.

How does autoload really work? What happens behind the scenes?
When you explain it, you rediscover the core mechanics: file paths, the autoloader’s role, and class mapping. What once felt automatic becomes a clear demonstration of logic and structure.

In fact, I explored this topic in more detail in this article.

What about you?

What’s the last concept you explained that made you revisit your fundamentals? Share your experience in the comments!

How does it work?

Each file is represented by a unique fingerprint, called a hash (or digital fingerprint). When you modify a file, Git recalculates its hash and compares it with the previously recorded one:

• Identical hash? No changes detected.
• Different hash? Git immediately recognizes that a modification has occurred.

Try it yourself!

Git includes a built-in tool to visualize this process. Run the following command in your terminal:

echo 'https://medium.com' | git hash-object --stdin

You will get the following output:
a18294310b57112d93801eb7f365b1839cf615d1

This string is the unique hash (fingerprint) of the character sequence. Change just one character, and the resulting hash will be completely different.

Why is this so powerful?

Thanks to this hashing system, Git can:

• Track every modification, even the smallest one.
• Optimize performance: comparing hashes is much faster than comparing entire files.
• Ensure data integrity: any unintended modification is quickly detected.

Every time you run git status, Git uses this mechanism to compare the current state of your local files with those recorded in the repository.

Hashing in Git’s overall architecture

This hashing process is at the core of Git’s architecture. Each commit is essentially a recorded version of your files, represented by a unique hash. When you create a commit, Git calculates the hash of the entire content to generate this fingerprint.

Branches, in turn, are merely pointers to these commits, making it easier to navigate between different versions of your code.

In summary, this mechanism not only tracks changes to each file but also ensures the integrity and consistency of your project’s entire history.

How does Git detect file changes? was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.