Petite digression sur cet article :

• I won't let you pay me for my open source

Je commente juste ce passage, lié à la licence MIT car je suis totalement d’accord avec :

The MIT license to a large extent is the anti-license. The utopia of socialized programs, one that embraces the lack of marginal cost for software goods.

It’s an explicit rejection of the strong-property rights approach taken by both Gates and Stallman at their respective ends of the libertarian spectrum.

It’s the language of giving without expecting anything in return. It’s the language of sincere charity. A charity without strings attached, neither commercial nor reciprocal. With the risk of sounding sanctimonious, I read it as a pure projection of altruism.

[…]
That to me is freedom.

Car non, même si je considère que GPL et consorts sont nécessaires, ce n’est pas pour moi une licence libre.

La liberté, c’est quand je fais ce que j’ai envie de faire, et comment j’ai envie de le faire.

Est-ce que la licence GNU me permet de faire ce que je veux ? Non. Je ne peux pas, par exemple, faire un logiciel propriétaire avec un code d’origine libre.

La liberté va de paire avec des devoirs, je suis absolument d’accord avec ça. Mais précisément : il faut bien distinguer les deux.

Ainsi, je vois les licences comme suit :

• MIT est la liberté : je fais ce que je veux.
• Une licence propriétaire, n’a que des devoirs (ou des interdits, qui ne sont que des devoirs négatifs ; en tout cas le contraire d’une liberté). Je ne fais rien comme je veux.
• GNU/GPL essaye de concilier les deux : en donnant une liberté associée à des devoirs. Je fais ce que je veux, mais sous certaines conditions.

Parfois, souvent même, c’est utile et nécessaire de poser quelques limites. Mais dans autant de cas, une permissivité totale est également nécessaire.

Prenons l’exemple de la loi, car c’est ça qui détermine nos vies en société.

La loi, la constitution, posent des libertés et des devoirs pour chaque personne. Ainsi, par exemple, pour utiliser l’espace public, on ne doit pas être ivre. Il en va de la tranquillité de la société, sachant que l’alcool est une drogue, qu’elle rend violent et incapacitant : une personne ivre est un danger pour elle-même et les autres et il est mieux d’éviter ça.

Pourtant, il est tout à fait autorisé d’être ivre.
Il est tout à fait autorisé de boire quand on est mineur.
Et il est aussi tout à fait autorisé d’être ivre quand on est mineur.

Juste, chez soi.

Chez soi y a pas de problème.
Chez soi, la permissivité est très très large.

Encore heureux.

Stallman avec GPL, n’a pas fait une permissivité totale pour chez soi. Ce qu’il a fait, c’est un espace public : à la fois empli de libertés et délimité par des devoirs. La licence MIT, elle, c’est chez soi. Une licence propriétaire, en revanche, c’est chez les autres : on fait ce qu’on nous autorise de faire, car on n’est pas chez soi.

Quand je suis chez moi, je n’ai pas envie qu’on vienne me dire ce que j’ai le droit de faire ou non. Ni Bill Gates, qui vient me harceler parce que j’ai modifié Windows pour l’installer comme je veux ; ni Richard Stallman qui exige que je lui donne une copie de mes travaux pour qu’il distribue ça à tout le monde. Je n’ai juste pas forcément envie : j’ai fait ça pour moi, point.

Gates et Stallman ont beau être chacun à l’opposé d’une échelle assimilable à la droite et à la gauche en politique, cette échelle je la vois plutôt comme un polygone à trois sommets : Gates (tout interdit) à un bout, Stallman (des libertés ET des devoirs) à un autre, et les licences totalement libres telles que MIT, Apache, WTFPL au troisième (que des libertés).

En fait, en rédigeant ce post, je viens de me mettre une image mentale sur pourquoi je n’ai jamais considéré la licence GNU comme libre, tout en étant fondamentalement convaincu de son utilité. L’un n’empêche pas l’autre en fait.

Et le seul problème, c’est qu’on assimile GPL ou GNU à la liberté, alors qu’en réalité on devrait l’associer à une chose publique. (je n’emploie volontaire pas l’expression « domaine public », car ce vocabulaire signifie déjà quelque chose, même si le terme approprié serait bien « domaine public »). La GPL s’appelle d’ailleurs « General Public Licence », pas « General Free Licence ». C’est peut-être pas sans raison.

Car ce qui est public, est accessible à tous, sans appartenir à qui que ce soit. Le bus est un transport public : pourtant je ne peux pas virer le conducteur et voler le bus pour rentrer directement jusque chez moi. Ni sortir dans un parc et couper les fleurs. Ni ramasser un banc pour mettre dans mon jardin.

Alors que ce qui est libre, je peux le prendre et en faire ce que je veux. Si y a un panier de pommes dehors où c’est écrit « Gratuit, servez-vous », je peux prendre une pomme et elle devient la mienne. Je peux la manger, la rapporter à la maison, en faire de la compote ou la jeter aux poules : j’ai le droit. C’est libre.

Quand j’ai commencé à utiliser un ordinateur, j’adorais bidouiller. J’étais encore petit, mais je m’amusais à modifier tous les paramètres possibles et voir ce qui se passait. C’était sous un système Windows. J’essayais aussi de supprimer ou déplacer des fichiers, toujours pour voir. Là, forcément ça plantait et il fallait réparer.

Avec le temps et au fil des bidouilles, on comprend quel programme fait quoi et ce qu’il ne faut pas faire ou alors seulement en connaissances de cause.

C’est un bon moyen d’apprendre.

Au fil du temps, je me suis lassé et j’ai voulu découvrir d’autres trucs. J’ai essayé GNU/Linux (Ubuntu). J’ai pu découvrir un autre système, d’autres manières de fonctionner, d’autres paramètres à bidouiller, à casser et à réparer, d’autres fichiers dans lesquels gratter, etc.
J’utilise toujours du Linux aujourd’hui, sur mon système personnel de façon courante.

Mais j’ai l’impression que tout ça c’était avant. Aujourd’hui je ne bidouille plus comme ça.

Aujourd’hui, si je bidouille mon système, c’est pour qu’après ça marche. J’édite d’obscurs fichiers de config, j’installe des outils étranges et je fais des scripts bizarres, mais tout ça est devenu purement fonctionnel.

J’ai plus le temps ni l’envie de bidouiller pour m’amuser : la fin n’est plus l’excitation de découvrir, casser puis réparer un ordinateur. Pas que je ne suis plus curieux, mais parce qu’une fois qu’on a découvert, on ne peut plus redécouvrir. Mon intérêt s’est porté sur autre chose.

La fin est devenue d’avoir un ordinateur qui fonctionne comme je le veux. Et c’est bien ce que j’ai : j’ai passé plusieurs années étudier le fonctionnement, afin de voir ce qu’on pouvait modifier et comment, pour pouvoir avoir enfin un système qui fonctionne comme je veux.

Ça ne me dérange pas de lancer des lignes de commandes trouvées sur la dernière page de l’internet, mais ça doit avoir un but et ça doit fonctionner. C’est d’ailleurs la raison de mes checklists Linux/Windows : avoir mes commandes à porté de main et pouvoir les appliquer rapidement en cas d’installation d’un nouveau système (mise à niveau complet, changement de PC…).

Pourquoi avoir un PC qui marche ?

Avant je bidouillais pour bidouiller. Maintenant je bidouille pour que ça marche. Car si ça marche, je peux produire et créer : faire des choses constructives.

L’informatique a pris une grande place dans mon quotidien et j’aime avoir les outils pour l’exploiter correctement. Et si un outil n’existe pas (ou n’est pas à mon goût), je sais le créer.

Tout le temps passer à regarder le fonctionnement d’un ordinateur m’a permis de découvrir l’univers des possibles en informatique (car oui, un ordinateur peut faire autre chose que ses courses en ligne ou regarder Netflix).

Du coup, maintenant, je crée des outils qui me servent au quotidien dans ce que je fais. Ma page des outils en ligne est dans cette veine-là.

Je pense que c’est un peu comme quand on évolue de lecteur à écrivain : on regarde, on apprend, puis on construit des choses différentes de ce qu’on a vu grâce à ce qu’on a appris.

Peu de monde va aussi loin dans cette démarche. La plupart des gens, face à un ordinateur, n’y voient qu’un écran interactif, bien loin de se douter qu’avec les bons outils et les bonnes connaissances on peut utiliser son PC pour faire à peu près n’importe quoi.

Et aujourd’hui, c’est là que je me dirige, plus que vers le simple bidouillage.

Ça en est à un point où, parfois, les systèmes trop configurables me font chier. KDE, un environnement Linux axé sur la personnalisation, est très joli mais ne m’attire pas. Je préfère Mate (Gnome) qui a autant d’options (juste elles sont cachées) mais qui à l’utilisation n’est pas encombrante.

C’est un peu ce que je reproche à Android de plus en plus. Il y a des tas d’options partout, à tel point que celle que l’on cherche est introuvable 90 % du temps. Sur ce plan, et bien que ça ne soit pas la seule raison, je songe de plus en plus à passer sur iOS/iPhone. Un système qui tourne et qui ne traîne pas dans mes pattes, quitte à avoir moins d’options : c’est ça que je veux.

Voici une magnifique subtilité du CSS, mais parfaitement logique quand-même :

• The surprising behavior of !important in CSS custom property values

Que se passe-t-il si on met !important dans une variable ?

Voyons ça :

div {
  --color: red !important;
  color: var(--color);
  color: yellow;
}

À votre avis ça donne quoi ça en CSS ? Le point litigieux, c’est bien-sûr la présence du !important
Sauf qu’il est à savoir que le !important n’est pas sur une déclaration de propriété, mais sur une déclaration de variable CSS.

Or, une variable ne peut contenir qu’une valeur. La valeur contenue dans --color est donc red. Il faut savoir que le !important ne fait pas partie de la valeur : il s’agit d’un élément de langage qui permet de jouer sur la spécificité, comme un drapeau (un flag).

Résultat : la couleur finale du texte sera décidée par le vainqueur des deux déclarations de color juste en dessous. Comme celle-ci ont la même spécificité, c’est la dernière qui gagne.

Conclusion : le texte est en jaune.

!important n’est pas sans effet !

Maintenant, utiliser un !important dans les variables CSS n’est pas sans effet pour autant.
Regardons :

div {
  --color: red !important;
  --color: blue;
  color: var(--color);
}

Ici, aucune ambiguïté sur la déclaration de la couleur, puisqu’il n’y en a qu’une seule : color prendra la valeur contenue dans la variable --color. Oui mais laquelle ?

Réponse : celle dont la déclaration a la spécificité la plus grande ! Autrement dit, la première.
Conclusion : ça donnera du rouge.

Il convient donc de distinguer deux cas de figure :

div {
  --color: red !important;
  color: var(--color);
  color: blue;
}

div {
  --color: red;
  color: var(--color) !important;
  color: blue;
}

Dans le premier cas, les deux déclarations de couleur ont la même spécificité. C’est donc la dernière qui gagne : le texte sera bleu.
Dans le second cas, c’est la première déclaration qui a la plus grande spécificité (à cause du !important).

Peu importe qu’elle ait une variable ou non, c’est elle qui gagne : cela donnera du rouge.

Le conflit ? Quel conflit ?

Dans sa conclusion, l’article dit qu’il y a deux niveaux de « scope » (traduction ?) sur lesquelles sont appliqués le !important. Une sur les variables, et une sur les propriétés. Je ne suis pas d’accord avec ça : pour moi il n’y a en a qu’une seule. En revanche, il a deux déclarations différentes à considérer : une sur une variable, et une sur une propriété.
Maintenant, dans les deux cas, on peut ajouter un !important si l’on veut. Et comme ce sont deux choses différentes, elles n’entreront pas en conflit.

Appliquer deux !important à deux propriétés différentes n’est pas un problème :

div {
  font-weight: bold !important;
  color: red !important;
}

Ces deux choses n’entrent pas en conflit.
Par conséquent, les deux choses suivantes non plus :

div {
  --color: bleu !important;
  color: red !important;
}

Notez que ci-dessus, la variable --color est déclarée, mais jamais utilisée, donc aucun conflit à l’horizon.

Dans ce qui suit, toujours aucun conflit :

div {
--color: bleu !important;
color: var(--color) !important;
}

Tout est clair : la variable reçoit du bleu. La couleur reçoit la variable. Donc la couleur finale est bleue.

Et même s’il y avait plusieurs déclarations de la variable, celle qui gagne est celle de la plus grande spécificité. Ensuite, c’est la déclaration de la couleur avec la plus grande spécificité qui gagne. Ainsi l’exemple suivant donnera du rouge :

div {
  --color: red !important;
  --color: blue;
  color: var(--color) !important;
  color: green;
}

Parmi les variables, c’est le rouge qui gagne sur le bleu.
Parmi les propriétés, c’est celui avec le var() qui gagne sur celui avec le vert. Or la variable contient du rouge. Donc le texte sera rouge.

Applications à un contexte plus large

Tout ceci est évidemment à mettre dans un contexte plus global avec des déclarations sur des sélecteurs de spécificité différente.

div {
  --color: blue !important;
  color: var(--color);
}

div#foo {
  --color: orange;
  color: var(--color);
}

Ici ça sera… Bleu !

Regardons la couleur pour commencer. La couleur reçoit ce que contient la variable. Aucune ambiguïté. Et la règle qui s’applique est celle dans le second bloc. Pourquoi ? Parce que le sélecteur y est plus spécifique.

Maintenant que contient cette variable ? Cette variable est celle qui est la plus spécifique. Donc celle avec le !important. Donc le bleu.

En effet, même s’il y a un #id sur le sélecteur du second bloc, la variable --color ne contient pas de l’orange, mais du rouge : le !important sur une propriété est plus spécifique que la même propriété placée sur un ID (Spécificité de 1-0-0-0-1 au lieu de 0-1-0-0-1).

Par contre, il en est différent si le !important sous le deuxième bloc avait été sur la variable au lieu de la propriété :

div {
  --color: blue;
  color: var(--color)!important;
}

div#foo {
  --color: orange;
  color: var(--color);
}

Dans ce cas, la variable qui s’applique est l’orange dans le second bloc (car cette variable est plus spécifique à cause de l’ID dans le sélecteur).
Par contre la propriété qui s’applique, c’est bien celle du premier bloc (car cette propriété a le !important). Le texte est donc orange.

Le vocabulaire est important : la propriété et la variable sont des déclarations différentes. Elles ont chacune leur spécificité (au sens de « priorité CSS »).

Si je ne conserve que les éléments qui s’appliquent, ça donne ceci :

div {
  color: var(--color) !important;
}

div#foo {
  --color: orange !important;
}

La couleur reçoit une variable, comme indiqué dans le premier bloc. Mais cette variable a une valeur assignée dans le second bloc seulement. Par contre cette valeur ne s’applique sur les div#foo. Si vous avez un div#bar, la variable ne contiendra rien et la propriété sera annulée.

Ça vous semble casse gueule ? Attendez la suite.

Cas des sélecteurs enfants

Jusqu’à maintenant, même si on utilise deux sélecteurs différents, ils ciblent le même élément HTML.
Terminons donc par quelques exemples pour montrer ce qui se passe avec avec des sélecteurs enfants.

Voyons :

div {
  --color: red !important;
  color: var(--color) !important;
}

div a {
  --color: orange;
  color: black;
}

La question : quelle est la couleur du lien ?
Réponse : noire.

Noire ? Oui, noire. La déclaration tout à la fin.

En effet, le premier bloc a beau avoir des !important sur toutes les propriétés, ils s’appliquent au div, tout comme leur spécificité. Or, seule, la spécificité n’est pas héréditaire. La spécificité n’est héritée que si la valeur sur laquelle elle s’applique est héritée. En réalité, seule la propriété la plus spécifique est alors héritée.

Ainsi, pour savoir ce qui s’applique à notre a, on regarde le code destiné au a. C’est alors lui qui s’appliquera, s’il y en a.

Et le a a une déclaration de couleur : color: black;. L’hérédité ne s’applique donc plus : on applique le color: black;, point barre. L’hérédité ne s’applique qu’en l’absence de déclaration.

Ainsi, si on avait mis :

div {
  --color: red !important;
  color: var(--color) !important;
}
div a {
  --color: orange;
}

Alors, le texte serait rouge. La couleur du a serait héritée du div, et contiendra var(--color), qui, dans le contexte du div, est rouge.

Pas orange ?
Non : l’orange est du contexte de a. Or la propriété de couleur color est héritée du contexte de div, et là, dans son contexte, c’est bien du rouge que contient la variable.

On aurait même pu mettre un !important dans le second bloc, cela restera rouge, pour la même raison : la couleur est héritée, et l’héritage contient une variable contenant du rouge :

div {
  --color: red !important;
  color: var(--color) !important;
}
div a {
  --color: orange!important;
}

Si l’on voulait du orange, on doit ajouter un color: var(--color) dans le second bloc. Comme ça, la couleur du a est déclarée et non-héritée. Mais il faut bien conserver la déclaration de la variable dans le a, sinon la variable n’est plus déclarée et elle hérite.

Il faut retenir que la variable s’applique sur les propriétés du même contexte. Le parent transmet une propriété ? D’accord, mais sa valeur est également transmise, même si c’est une variable.

Et là on arrive donc à quelque chose de très drôle : quid des variables appliquées à plusieurs propriétés, l’une déclarée et l’autre héritée ?

div {
  --color: white;
  color: var(--color);
}
div a {
  --color: black;
  background-color: var(--color);
}

Ici le texte sera bien en blanc sur fond noir !
Décomposons :

• La couleur : la couleur n’est pas déclarée sur le a. Elle est donc héritée. Et l’héritage contient du blanc : c’est donc du blanc.
• Le fond : le fond est déclaré sur le a. Le fond contient var(--color). Et --color, dans ce contexte, contient du noir. Le fond est donc noir.

Si l’on n’avait pas déclaré le --color: black;, alors la variable aurait été héritée, et on aurait eu du blanc sur fond blanc.

Notez que dans ce dernier exemple on n’a mis aucun !important : normal, car la spécificité n’est pas héritée si la propriété sur laquelle elle est appliquée n’est pas elle-même héritée.

On aurait pu en mettre partout dans le premier bloc, on aurait tout de même eu du blanc sur du noir.

Ah et : ici on ne parle que de la propriété color. Je vous laisse imaginer ce que ça donne si l’on utilise des variables dans display, flex ou position, le tout assaisonnée de sélecteurs comme a ~ a et de pseudo-classes :not() ou :placeholder-shown. Ça promet, non ?

Log4Shell est une nouvelle de ces failles informatique qui touchent des milliards d’appareils, et qui permettent potentiellement à n’importe qui d’en prendre le contrôle. Elle est décrite comme « la plus grosse et la plus critique des failles unique de la décennie » (« the single biggest, most critical vulnerability of the last decade »). La CISA et la BSI (respectivement les ANSSI américaines et allemandes) l’ont qualifié de « extrêmement critique ».

Elle peut affecter non seulement un ordinateur ou un SI d’entreprise, mais aussi votre téléphone, imprimante connectée, ou de plus en plus votre frigo, télé, voiture, porte de garage ou four à micro-ondes connecté.

Pour comprendre la faille, je vous renvoie à ce thread sur Twitter.

Si je devais résumer : cela concerne un module utilisé par les outils de gestion des journaux système d’une installation informatique (les « logs »).
Beaucoup de programmes utilisent les logs (tous en fait, plus ou moins). Certains peuvent alors y mettre des variables, comme ${date}, qui seront alors remplacés par l’outil qui gère le journal (en l’occurrence, ${date} sera remplacé par la date courante au moment de l’accès au journal).

Or il se trouve que certaines variables sont renvoyées en cascade vers d’autres modules qui peuvent y placer d’autres informations. En particulier, ici un module (JNDI) qui vient remplacer une des variables par des données arbitraires… Par exemple une URL au bout de laquelle n’importe qui peut placer du code malicieux.

Ce problème est signalé depuis 2016.

Le module, utilisé par toutes les big-tech (Microsoft, Apple, Google, Tesla…) est maintenu par… Trois gus qui font ça sur leur temps libre :

Ces trois personnes n’y sont pour rien : les erreurs arrivent et ils vont sûrement corriger ça très vite. Le problème que je vois surtout, c’est que des sociétés dont la valorisation cumulée doit bien dépasser 5 trillions de dollars, n’ont pas gratifié ces dév ne serait-ce que de 1 000 $ durant du tout ce temps.

Si votre architecture fonctionne comme ça : soutenez ceux qui vous permettent de bosser ! C’est la moindre des choses, en fait.

Il ne fait pas beaucoup de doutes que quelqu’un qu’on paye pour s’occuper de quelque chose à temps plein sera plus efficace pour corriger les bugs que quelqu’un qu’on laisse bosser sur son seul temps libre de temps en temps.

Je vois deux choses à retenir ici :

• en profitant du boulot des autres, on hérite aussi de leurs erreurs. Ce n’est pas grave, mais faut en être conscient : on est dépendant d’eux ;
• en abusant des lib et outils sans prodiguer ne serait-ce qu’un simplement soutien ponctuel, faut pas s’étonner que le module reste du boulot fait irrégulièrement et sur du temps libre.

Qu’on soit clair : le boulot d’un amateur sur son temps libre peut être très bon. Ce que je veux dire en vrai, c’est que si l’on construit son empire sur ce boulot, il faut peut-être s’assurer que ce code « amateur » soit solide. Et en l’occurrence, ça passe par un soutien suffisant à celui qui s’occupe de ce code ou de son audit.

Les dév mangent aussi (je vous jure !), et le temps qu’ils passent à bosser ailleurs pour pouvoir manger, ils ne le passeront pas à corriger l’outil qui maintient votre empire en place. Tout simplement parce que votre empire, il s’en fout autant que vous vous foutez de lui en ne donnant pas ne serait-ce qu’un micro-pourcent de ce que vous distribuez aux actionnaires chaque année. Et c’est bien normal.

Or, n’importe quel appareil numérique aujourd’hui fonctionne grâce à des dizaines, des centaines de ces modules développées par des passionnés et des bénévoles. Ouvrez n’importe programme ou n’importe quelle application et allez dans les « crédits » ou les « à propos ». Vous y verrez le nom des personnes qui vous rendent la vie plus simple, chaque jour, y compris, si c’est fait correctement, les outils qui permettent à ces applications de fonctionner, et leurs auteurs.

Et les exemples où l’industrie se fiche de remercier ces gens et s’en retrouve à genoux également : on se souviendra de Heartbleed, la faille de 2014 qui avait fait un grand bruit parce qu’il touchait tous les sites sécurisés (SSL) et tous les outils, y compris ceux des Gafam, et avait mis en lumière le manque de moyens de la fondation OpenSSL qui s’occupe de ça. Quelques années après, OpenSSL ne tourne toujours qu’avec environ 50 000 $ par an…

ÉDIT : ah oui… Ceci est aussi à mettre en perspective avec cet article de ce journaleux qui demande aux dév d’arrêter de vouloir être payés un salaire à la hauteur de leur compétences.

(Ça rime :D)

• Lire : Que veulent les développeurs ? La grande enquête ! - Korben

J'avais commencé de répondre jusqu'aux question bullshito-corporate qui ne veulent strictement rien dire, j’ai donc abandonné en cours de route.

Je vais donc mettre ici ce que je considère comme un poste de développeur idéal. C'est ma vision des choses ; si y'en a qui sont pas d'accord c'est leur droit et pas vraiment mon problème.

Je précise quand-même : je code aujourd'hui professionnellement comme personnellement, même si ce n'est pas mon activité principale.

Bref, voici mes critères (en dehors de la paye).

Pour commencer : un bureau FERMÉ.
Coder quoi que ce soit, c'est une activité intellectuelle et j'ai besoin d'être concentré.
Je peux rester assis à réfléchir 12 h de suite, ça me gêne pas. Par contre le moindre bruit, sonnerie de téléphone pour des broutilles, ou tocage à la porte peuvent faire perdre 5 h de réflexion, et à vous 5 h d'avancement sur la deadline. C'est vous qui voyez.

Un bon bureau, chaise, écran.
C'est notre matériel de travail, bon sang ! Pour la même raison qu'un mécano ne travaille pas avec des outils premier-prix de chez Lidl, si vous nous donnez une chaise en bois et une table bancale pour bosser sur un Médion de 2005 et son clavier en Qwertz, ça va pas le faire.
Je veux utiliser mon ordi. Ou en tout cas mon clavier et ma souris. Ainsi que si possible mon environnement de développement.

La plupart des développeurs font du dev également à titre perso et ont appris ça chez eux avec leur logiciels et ont leurs repères (raccourcis claviers, etc.). C'est comme ça qu'on est le plus efficace, et ces demandes ne sont pas pour vous faire chier, bien au contraire.

Des spec précises
Dîtes nous précisément ce que vous voulez qu'on code et pour quand et on le fait et vous aurez ce que vous voulez au moment fallu. Et passez le mot au client aussi.
Si les spec ne sont pas précises, je considère que le choix non précisés sont laissés à notre discrétion. On dit pas à un architecte « je veux une maison », mais « je veux cette maison », accompagnée d'une liste complète de critères à respecter ab-so-lu-ment.

Le dèv c'est pareil.

Trucs non-importants
Perso je me fiche et contre-fiche :

• d'un babyfoot
• de la salle de sport
• des sorties ou soirées organisées par la boîte
• d'un distributeur de bouffe ou de café
• d'un psychologue ou d'un masseur au travail
• …

Certains aiment se sentir au jardin d’enfant pour bosser. Tant mieux pour eux, mais moi c'est pas mon cas. Je préfère l’ambiance « bibliothèque » en plein désert (et moins y a de monde, mieux j’y suis).

Et je distingue l’entreprise du reste de ma vie et j'ai envie de garder ça comme ça. Les soirées entreprise, si c’est plus d’une fois dans l’année, ça devient lourd, et si c’est pour en profiter pour parler boulot, sans moi merci. Revenez aux bons horaires.

D'ailleurs parlant de ça : les horaires et les congés flexibles c'est un gros point positif. Leur absence, un gros point négatif, sans être discriminant.

En résumé
Je suis dév : je travail en silence avec ma tête et mon ordi.
Il est donc normal d’être bien mentalement (au calme loin du bruit) et avec un bon ordi / chaise / souris.

Tout le reste, je m’en fiche : babyfoot & co, ce n’est pas un avantage pour moi (sauf s’il est loin loin loin au sous-sol).

---

PS : non, je ne recherche pas de poste de dév en ce moment.
J’ai juste tiqué sur un article d’un confrère blogueur.