NoBullshit Tech-Lead EntityMap

NoBullshit Tech-Lead (Organization)

Marque éditoriale de FGRibreau SARL. Elle publie le livre NoBullshit Tech-Lead et, sur getnobullshit.com, ses 60 principes, des guides et un glossaire destinés aux développeurs, Tech-Leads, architectes et CTO.

60 principes fondamentaux pour gérer sa dette technique, livrer sans stress, tenir la production et bâtir une organisation efficace — du développeur au CTO. NoBullshit Tech-Lead : 60 principes pour Tech-Lead et CTO - published by NoBullshit Tech-Lead

60 core principles to handle technical debt, ship without stress, keep production healthy and build an effective organization — from developer to CTO. NoBullshit Tech-Lead: 60 principles for tech leads and CTOs - published by NoBullshit Tech-Lead

François-Guillaume Ribreau (Person)

Full Stack CPTO et auteur du livre NoBullshit Tech-Lead. Il a passé quinze ans à architecturer, construire et réparer des systèmes d’information, de la startup au grand compte, et a fondé ou cofondé Cloud-IAM, Netir, Image-Charts et Redsmin.

AFFILIATED_WITH → NoBullshit Tech-Lead

Je transforme l’informatique en centre de profit. Quinze ans à architecturer, construire et réparer des systèmes d’information — de la startup au grand compte. Partout, les mêmes problèmes qui reviennent, et les mêmes principes pour les régler. NoBullshit Tech-Lead , c’est ce condensé. À propos — François-Guillaume Ribreau | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

I turn IT into a profit center. Fifteen years architecting, building and fixing information systems — from the startup to the large enterprise. Everywhere, the same problems coming back, and the same principles to fix them. NoBullshit Tech-Lead is that distillation. About — François-Guillaume Ribreau | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Je prends le rôle de CPTO pour des équipes tech — architecture, management, produit, prod —, je mène des audits techniques 360° et j’aide les dirigeants à trancher quand ça compte. Et je construis mes propres SaaS, de l’idée au premier euro de MRR : une douzaine de fois. À propos — François-Guillaume Ribreau | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

I step in as CPTO for tech teams — architecture, management, product, production —, I run 360° technical audits, and I help leaders make the right call when it matters. And I build my own SaaS, from idea to first euro of MRR: a dozen times over. About — François-Guillaume Ribreau | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

NoBullshit Tech-Lead (nbtl:Book)

Livre de 240 pages en français qui réunit 60 principes pour gérer la dette technique, livrer sans stress, tenir la production et bâtir une organisation efficace, du développeur au CTO. Chaque chapitre porte une idée, en trois pages au plus.

AUTHORED_BY → François-Guillaume Ribreau
PRODUCED_BY → NoBullshit Tech-Lead
INCLUDES → Les 60 principes Tech-Lead & CTO
SUITED_FOR → Tech-Lead

60 principes fondamentaux, du développeur au CTO. Une idée par chapitre, 3 pages maximum, des illustrations qui restent. Le livre — 240 pages, 60 principes | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

60 core principles, from developer to CTO. One idea per chapter, three pages max, illustrations that stick. The book — 240 pages, 60 principles | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Ce livre recense les 60 principes essentiels applicables de la petite à la grande entreprise, du développeur au CTO en passant par le Tech-Lead et l’architecte pour répondre aux problèmes du quotidien. NoBullshit Tech-Lead : 60 principes pour Tech-Lead et CTO - published by NoBullshit Tech-Lead

This book gathers the 60 essential principles that apply from the smallest startup to the largest enterprise, from developer to CTO — including tech leads and architects — to solve everyday problems. NoBullshit Tech-Lead: 60 principles for tech leads and CTOs - published by NoBullshit Tech-Lead

Les 60 principes Tech-Lead & CTO (Taxonomy)

Les 60 principes du livre NoBullshit Tech-Lead, répartis en 9 catégories (Développement, Recrutement, Produit, Infrastructure, Organisation, Culture, Vision, Management, Vie personnelle). Chaque principe a sa page sur getnobullshit.com, avec les retours d’expérience de la communauté.

INCLUDES → Assurer la transformation numérique en défragmentant
INCLUDES → C'est le code qui fait foi
INCLUDES → Choix technologique : X ou Y ?
INCLUDES → Considérer le SI comme un océan
INCLUDES → Contraindre d’abord, relâcher plus tard
INCLUDES → Documenter le rationnel
INCLUDES → Faire d'une pierre trois coups
INCLUDES → Le nommage doit être ennuyeux
INCLUDES → Le ratio production/consommation
INCLUDES → Mettre le plus de contraintes en amont
INCLUDES → Ne mets pas tes noix dans l'étau
INCLUDES → Préférer le déclaratif sur l'impératif
INCLUDES → Préférer l'explicite à l'implicite

Tout le livre, gratuit, en entier. Pas de teasing, pas de mur. Classés par catégorie — du dev à la vie perso. Ressources — les 60 principes | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

The whole book, free, in full. No teasing, no paywall. Grouped by category — from dev to personal life. Resources — the 60 principles | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Tech-Lead (Concept)

Rôle de l’ingénieur qui répond de la direction technique d’une équipe, c’est-à-dire de l’architecture, de la qualité, des choix techniques et de la livraison. On le devient quand on répond de ce que l’équipe livre, et plus seulement de son propre code.

On devient Tech-Lead le jour où l’on répond de ce que l’équipe livre, et plus seulement de son propre code. Le titre suit souvent après. Il faut déjà être crédible techniquement, puis apprendre trois métiers nouveaux : décider et écrire pourquoi, faire progresser les autres, parler produit et business. Devenir Tech-Lead : guide de la transition | NoBullshit - published by NoBullshit Tech-Lead

You become a Tech Lead the day you are accountable for what the team ships, and no longer only for your own code. The title often comes later. You need to be technically credible first, then learn three new jobs: making decisions and writing down why, helping others grow, and speaking product and business. How to become a Tech Lead: the transition guide - published by NoBullshit Tech-Lead

Un Tech-Lead répond de cinq choses : la direction technique de l’équipe, la qualité de ce qui est livré, la capacité à livrer souvent sans stress, la fiabilité en production et la montée en compétence de l’équipe. Il ne fait pas tout lui-même. Il s’assure que c’est fait, rend les décisions explicites et retire ce qui bloque. Responsabilités d’un Tech-Lead : le guide concret - published by NoBullshit Tech-Lead

A Tech Lead is accountable for five things: the team’s technical direction, the quality of what ships, the ability to ship often without stress, reliability in production, and the team’s growth. They do not do everything themselves. They make sure it gets done, make decisions explicit and remove what blocks the team. Tech Lead responsibilities: a practical guide - published by NoBullshit Tech-Lead

Engineering Manager (Concept)

Rôle qui répond des personnes d’une équipe technique, du recrutement aux entretiens individuels, à l’évolution de carrière et à l’organisation. Dans une petite structure, la même personne le cumule souvent avec celui de Tech-Lead.

Le Tech-Lead répond de la direction technique d’une équipe : architecture, qualité, choix techniques, livraison. L’Engineering Manager répond des personnes : recrutement, entretiens individuels, évolution de carrière, organisation. Dans une petite structure, une seule personne porte souvent les deux casquettes ; quand l’équipe grandit, les séparer évite que l’une des deux soit négligée. Tech-Lead vs Engineering Manager : quelles différences ? - published by NoBullshit Tech-Lead

The Tech Lead is accountable for a team’s technical direction: architecture, quality, technical choices, delivery. The Engineering Manager is accountable for the people: hiring, one-on-ones, career growth, organisation. In a small company one person often wears both hats; as the team grows, splitting them keeps either one from being neglected. Tech Lead vs Engineering Manager: what’s the difference? - published by NoBullshit Tech-Lead

Assurer la transformation numérique en défragmentant (Methodology)

Avec le temps, le SI d'une entreprise se fragmente et la même information se duplique partout. Cette fragmentation ralentit tout et allonge le time-to-market.

PART_OF → NoBullshit Tech-Lead

Aujourd’hui, la valeur d’une entreprise ne se mesure plus à ses logiciels ou ses algorithmes mais à ses données. Au fil du temps, une entreprise avec un historique important aura un Système d'Informations (SI) fragmenté. Concrètement, si l’on réalise une photographie d'un SI d’une entreprise de plus de 10 ans d'existence, on constate qu’un même type d'information se retrouvera à plusieurs endroits. C’est ce que j'appelle la fragmentation. Qui dit fragmentation, dit perte de performance du SI, évolutions complexes, rallongement du time-to-market. Assurer la transformation numérique en défragmentant - published by NoBullshit Tech-Lead

Today the value of a company is measured by its data more than by its software or its algorithms. Over time, a company with a long history ends up with a fragmented information system, where the same type of information lives in several places. I call that fragmentation, and it brings a slower IS, harder changes and a longer time-to-market. Drive digital transformation by defragmenting | NoBullshit - published by NoBullshit Tech-Lead

C'est le code qui fait foi (Methodology)

En production, c'est le code qui fonctionne et qui fait foi. Specs, User Stories et maquettes restent des intermédiaires ; seul le code est tangible et utile.

PART_OF → NoBullshit Tech-Lead

Ce qui fonctionne en production c'est le code, ce ne sont pas les spécifications, les User Stories, les issues ou encore les maquettes, c’est donc bien le code qui fait foi. Le code est la seule matière tangible et utile, il est la finalité. C'est le code qui fait foi | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

What runs in production is the code itself, well ahead of the specifications, the user stories, the issues or the mockups. So the code is what holds the truth. It is the only tangible, useful material, and it is the end goal. The code is the source of truth | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Choix technologique : X ou Y ? (Methodology)

PostgreSQL ou MongoDB ? Java, JavaScript ou Rust ? Kubernetes ou PaaS ? Comment arbitrer un choix technologique qui engage l'avenir de l'entreprise.

PART_OF → NoBullshit Tech-Lead

Au fil des années, j'ai vu pas mal de personnes dans des positions CTO ou de Lead venir me demander quelle technologie, langage de programmation ou framework utiliser. Est-ce qu'il vaut mieux partir sur PostgreSQL, MongoDB ou MariaDB ? Coder en Java, JavaScript ou Rust ? Est-ce que je mets mes applications sur du Kubernetes bare-metal ou alors sur une Platform as a Service (PaaS) ? Tant de choix qui vont avoir un impact sur le futur de l’entreprise. Choix technologique : X ou Y ? | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Over the years, plenty of people in CTO or Lead roles have come to ask me which technology, language or framework to use. PostgreSQL, MongoDB or MariaDB? Java, JavaScript or Rust? Should I run my apps on bare-metal Kubernetes or on a Platform as a Service? So many choices that will shape the future of the company. Technology choice: X or Y? | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Considérer le SI comme un océan (Methodology)

Les données ont une gravité et les applications gravitent autour. En surface, l'utilisateur final ; au fond, la donnée. Voyez votre SI comme un océan.

PART_OF → NoBullshit Tech-Lead

Les données subissent la gravité1, la majorité des applications du SI gravitent autour. Ces applications se trouvent à mi-chemin entre la surface et le fond de l'océan. Tout ce qui touche l'utilisateur final est à la surface. Nos utilisateurs surfent sur notre SI grâce à des applications mobiles, des applications web, des sites webs et des clients lourds. Ils génèrent du mouvement et de l'information. Considérer le SI comme un océan | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Data has gravity, and most of the applications in the information system orbit around it. These applications sit halfway between the surface and the bottom of the ocean. Everything that touches the end user is at the surface. Our users surf our IS through mobile apps, web apps, websites and desktop clients, generating movement and information. Think of the information system as an ocean | NoBullshit - published by NoBullshit Tech-Lead

Contraindre d’abord, relâcher plus tard (Methodology)

Plus les contraintes arrivent tôt dans un projet, mieux on garde le cap fixé. Contraindre d'abord puis relâcher plus tard découle directement de là.

PART_OF → NoBullshit Tech-Lead

Nous avons vu précédemment que plus des contraintes étaient instaurées tôt dans un projet, plus nous étions en capacité de garder le cap prédéfini. Le principe de contraindre d'abord et relâcher plus tard est une conséquence de ce premier principe. Contraindre d’abord, relâcher plus tard | NoBullshit - published by NoBullshit Tech-Lead

We saw earlier that the sooner constraints are set in a project, the better we can hold the course we defined. Constraining first and relaxing later follows directly from that first principle. Constrain first, relax later | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Documenter le rationnel (Methodology)

Prises à l'oral, les décisions se déforment ou s'oublient avec le temps. Documenter le rationnel garde vivant le pourquoi des choix structurants.

PART_OF → NoBullshit Tech-Lead

Les décisions sont prises de manière orale ? Au sein de l'équipe ? Tout au long du projet ? Il s'avère que nos souvenirs sur cette décision changent dans le temps voire, pire, disparaissent. Documenter le rationnel | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Are decisions made out loud? Within the team? All the way through the project? It turns out our memory of a decision shifts over time, or worse, disappears. Document the rationale | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Faire d'une pierre trois coups (Methodology)

Comment accomplir autant sans se tuer à la tâche ? En visant trois effets utiles pour une même action. Voilà ce que j'appelle faire d'une pierre, trois coups.

PART_OF → NoBullshit Tech-Lead

On me demande parfois comment je fais pour accomplir autant. Bien que je ne me considère pas comme quelqu’un d'extrêmement productif, j’ai tout de même observé que j’appliquais très souvent un principe que j'aime appeler “faire d'une pierre, trois coups”. Faire d'une pierre trois coups | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

People sometimes ask how I get so much done. I don't think of myself as especially productive, yet I've noticed I very often apply a principle I like to call “kill three birds with one stone”. Kill three birds with one stone | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Le nommage doit être ennuyeux (Methodology)

Bien nommer est difficile, presque un art. Des règles existent pourtant : un nom descriptif, sans ambiguïté, qui se comprend seul. Un nouvel arrivant le saisit-il ?

PART_OF → NoBullshit Tech-Lead

L'exercice de nommage est souvent difficile, il est même parfois perçu comme un art. Néanmoins, il existe quelques règles. Le nom idéal doit être le plus descriptif et transparent possible, être dénué d’ambiguïté, et se suffire à lui-même. Je me mets souvent dans la peau d'un nouvel arrivant. Comprendra-t-il ce terme ? Le nommage doit être ennuyeux | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Naming is often hard, and it's sometimes seen as an art. Still, a few rules exist. The ideal name is as descriptive and transparent as possible, carries no ambiguity, and stands on its own. I often put myself in a newcomer's shoes and ask: will they understand this term? Naming should be boring | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Le ratio production/consommation (Methodology)

Le ratio production/consommation compare ce que l'on produit et ce que l'on consomme, au travail comme dans la vie. Un principe qui invite à l'introspection.

PART_OF → NoBullshit Tech-Lead

On s’est tous au moins une fois posé la question “Qu’est-ce que je fais ici, sur Terre ?”. Le ratio production/consommation | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

We've all asked ourselves at least once, “what am I doing here, on Earth?” The production/consumption ratio | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Mettre le plus de contraintes en amont (Methodology)

Ajouter des tests, du multi-tenant ou de l'analyse statique sur un projet déjà avancé fait mal. D'où ce principe : mettre le plus de contraintes en amont.

PART_OF → NoBullshit Tech-Lead

Avez-vous déjà mis en place des tests sur un projet qui n'en avait aucun ? Du multi-tenant sur un produit mono-tenant ? Un outil d'analyse statique de code sur un projet bien avancé ? C'est (très) douloureux, n'est-ce pas ? Mettre le plus de contraintes en amont | NoBullshit - published by NoBullshit Tech-Lead

Have you ever added tests to a project that had none? Multi-tenancy to a single-tenant product? A static analysis tool to a project well under way? It's (very) painful, isn't it? Put the most constraints upfront | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Ne mets pas tes noix dans l'étau (Methodology)

Entre gens qui visent le même but, les conflits viennent d'un écart de contexte, qui installe friction et défiance. Comment enrayer ce cercle vicieux ?

PART_OF → NoBullshit Tech-Lead

Au sein d’une entreprise ou dans la vie personnelle, les conflits entre personnes partageant les mêmes objectifs viennent d’une différence de contexte entre elles. Cette différence de contexte d'information peut entraîner une friction et un manque de confiance au sein de l’équipe, qui peut s’aggraver au fil du temps. Mais comment s’installe ce cercle vicieux ? Ne mets pas tes noix dans l'étau | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Within a company or in your personal life, conflicts between people who share the same goals come from a difference in context between them. That gap in information can create friction and erode trust within the team, and it tends to get worse over time. So how does this vicious circle take hold? Don’t put your nuts in the vise | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Préférer le déclaratif sur l'impératif (Methodology)

Au lieu de dicter chaque étape à la machine (impératif), déclarez le problème à résoudre. Le développeur énonce le quoi et la machine trouve le comment.

PART_OF → NoBullshit Tech-Lead

Plutôt que d'indiquer à la machine avec une approche impérative les étapes successives à exécuter, il est préférable de déclarer, de formuler le problème à résoudre. Le développeur n'exprime donc plus le comment, il exprime le quoi. La responsabilité de la machine est d'interpréter l'énoncé du problème, puis de le résoudre de manière efficace. Préférer le déclaratif sur l'impératif | NoBullshit - published by NoBullshit Tech-Lead

Rather than telling the machine, in an imperative style, the successive steps to run, it's better to declare, to state the problem you want solved. The developer states the what and leaves the how to the machine. It falls to the machine to interpret the problem and then solve it efficiently. Prefer declarative over imperative | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Préférer l'explicite à l'implicite (Methodology)

Transmis à l'oral, les choix d'architecture restent implicites, cachés dans le système. Rendez-les explicites pour passer de la réaction à l'anticipation.

PART_OF → NoBullshit Tech-Lead

Une culture de transmission orale des choix structurants de processus, d'architectures ou de configuration, sont autant de choix implicites, dissimulés sous diverses formes dans le système. Ce chapitre permet de passer de l'ère de la réaction à celle de l’anticipation ! Préférer l'explicite à l'implicite | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Passing on structural choices of process, architecture or configuration by word of mouth turns them into implicit choices, hidden in various forms across the system. This chapter is about moving from an age of reaction to an age of anticipation. Prefer explicit over implicit | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

SSoT (source de vérité unique) (Concept)

Une seule donnée fait foi. On évite de dupliquer l’information dans plusieurs systèmes qui finissent par diverger.

DESCRIBED_BY → Source de vérité unique

Une seule donnée fait foi. On évite de dupliquer l’information dans plusieurs systèmes qui finissent par diverger. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

One piece of data is authoritative. We avoid duplicating information across systems that eventually diverge. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

SoC (Separation of Concerns) (Concept)

Séparer les responsabilités : chaque module fait une chose et la fait bien, sans empiéter sur les autres.

DESCRIBED_BY → Séparer les intérêts

Séparer les responsabilités : chaque module fait une chose et la fait bien, sans empiéter sur les autres. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Separating responsibilities: each module does one thing well, without stepping on the others. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Dette technique (Concept)

Le coût futur des raccourcis pris aujourd’hui. À distinguer entre dette subie (qu’on encaisse) et dette choisie (qu’on pilote).

DESCRIBED_BY → Prendre conscience de la dette subie et dompter la dette choisie

Le coût futur des raccourcis pris aujourd’hui. À distinguer entre dette subie (qu’on encaisse) et dette choisie (qu’on pilote). Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

The future cost of shortcuts taken today. Distinguish suffered debt (you absorb it) from chosen debt (you steer it). Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Library-first (Concept)

Concevoir d’abord une bibliothèque réutilisable, puis l’application autour. On favorise la réutilisation et les interfaces propres.

DESCRIBED_BY → Favoriser l'approche library-first

Concevoir d’abord une bibliothèque réutilisable, puis l’application autour. On favorise la réutilisation et les interfaces propres. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Design a reusable library first, then the application around it. Favors reuse and clean interfaces. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Map/reduce humain (Concept)

Distribuer un travail entre plusieurs personnes (map) puis consolider (reduce). Puissant, mais coûteux en coordination : à utiliser avec parcimonie.

DESCRIBED_BY → Utiliser le map/reduce humain avec parcimonie

Distribuer un travail entre plusieurs personnes (map) puis consolider (reduce). Puissant, mais coûteux en coordination : à utiliser avec parcimonie. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Distribute work across people (map) then consolidate (reduce). Powerful but costly in coordination: use sparingly. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Go for the edge (Concept)

Traiter les cas limites tôt. Ce sont eux qui révèlent les vrais problèmes de conception.

Traiter les cas limites tôt. Ce sont eux qui révèlent les vrais problèmes de conception. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Tackle edge cases early. They reveal the real design problems. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Loi de Conway (inversée) (Concept)

L’architecture d’un système reflète l’organisation qui le produit. En l’inversant, on structure les équipes pour obtenir l’architecture voulue.

DESCRIBED_BY → Assurer la mise à l'échelle des équipes en suivant la loi de Conway inversée

L’architecture d’un système reflète l’organisation qui le produit. En l’inversant, on structure les équipes pour obtenir l’architecture voulue. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

A system’s architecture mirrors the organization that builds it. Inverting it means structuring teams to get the architecture you want. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

UAT (User Acceptance Testing) (Concept)

Environnement de recette utilisateur. Dans le livre : s’il t’en faut un, c’est souvent le signe d’un produit mal pensé.

DESCRIBED_BY → Si tu as un environnement UAT, t'as raté ton produit

Environnement de recette utilisateur. Dans le livre : s’il t’en faut un, c’est souvent le signe d’un produit mal pensé. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

User acceptance environment. In the book: if you need one, it’s often a sign of a poorly designed product. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Monitoring & alerting (Concept)

Mesurer l’état du système (monitoring) et être prévenu quand ça dérape (alerting). L’un sans l’autre ne sert à rien.

DESCRIBED_BY → Pas de monitoring sans l'alerting

Mesurer l’état du système (monitoring) et être prévenu quand ça dérape (alerting). L’un sans l’autre ne sert à rien. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Measure the system’s state (monitoring) and get notified when it goes wrong (alerting). One without the other is useless. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Déclaratif vs impératif (Concept)

Décrire le résultat voulu (déclaratif) plutôt que la suite d’étapes (impératif). Plus lisible, plus robuste.

DESCRIBED_BY → Préférer le déclaratif sur l'impératif

Décrire le résultat voulu (déclaratif) plutôt que la suite d’étapes (impératif). Plus lisible, plus robuste. Glossaire | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead

Describe the desired result (declarative) rather than the sequence of steps (imperative). More readable, more robust. Glossary | NoBullshit Tech-Lead - published by NoBullshit Tech-Lead