Conversation

Notices

1. Eliot: unleashed (eliotberriot@mastodon.eliotberriot.com)'s status on Friday, 02-Aug-2019 04:01:50 EDT Eliot: unleashed

   Tiens je parle souvent des trucs que je fais en dev, mais rarement des trucs que je fais pas ou connais pas.

   Je me dis que ça pourra peut-être faire relativiser d'autres personnes qui doutent de leurs compétences/connaissances.

   Alors, du coup.

   J'ai jamais appris la différence entre les bits, les bytes, les octets et tout.

   J'ai jamais fait language plus bas niveau que PHP ou Python.

   J'ai amais touché vraiment au hardware (j'ai changé un disque une fois je crois)

   J'ai jamais appris les notations CIDR. D'une manière générale, la couche réseau est très obscure pour moi. Les interfaces, les routes, les couches, les routeurs, les switchs, les masques de sous-réseau, les gateway ? Je sais que ça existe :D

   La crytographie ? Ahaha. Ah. Ahah.

   J'ai jamais vraiment réussi à utiliser IRC.

   Jusqu'à y'a deux semaines, j'étais incapable d'écrire une condition en bash sans regarder une doc.

   Je fais pas de maths plus poussées que des moyennes ou des produits en croix. Quand je vois des gens parler de matrices, de vecteurs, de fonctions, ou autre, mon cerveau est en PLS.

   1. Eliot: unleashed (eliotberriot@mastodon.eliotberriot.com)'s status on Friday, 02-Aug-2019 11:01:54 EDT Eliot: unleashed

      in reply to

      Du coup avec les retours de certaines personnes, je réalise qu'il manque peut-être une seconde partie à ce post.

      Une partie sur tout ce qui a fait de moi un meilleur dev' mais dont personne ne parle jamais ?

      J'ai déjà évoqué plusieurs fois du fait que je suis autodidacte.J'ai commencé le dev' vers 18-20 ans. En plein cursus pro pour devenir libraire. J'ai un bac L, un DUT de librairie/bibliothèque et une license pro en documentation.

      Je n'ai quasiment pas bossé dans ce domaine là (hormis quelques stages / boulots d'été).

      A priori, y'avait AUCUNE raison que je bosse dans l'info avec un parcours comme ça.

      Et pourtant…

      Funkwhale, c'est un logiciel qui gère une *bibliothèque* musicale. Je vous raconte pas le nombre de pièges que j'ai pu éviter dans le design et l'implémentation de certaines fonctionnalités grâce à mon cursus initial.

      Et pourtant…

      Le métier de dev, c'est avant tout un métier ou on lit, on écrit et on communique. Je ne parle pas de l'écriture du code, qui est généralement minoritaire dans ce que j'ai pu observer par rapport à tout le reste.

      L'apprentissage, la recherche, les spécifications, le support, les demandes d'aide, la documentation (la lire ou l'écrire ;), les échanges, les rapports de bug… Tout ça, ça constitue 80% du boulot de dev', et ça demande avant tout de savoir s'exprimer, de communiquer avec les autres et de comprendre ce qu'on lit.

      Autant de choses qui sont généralement plus mis en avant dans les cursus littéraires que scientifiques.

      Et pourtant…

      Si on mets de côté la partie produit et développement pure, Funkwhale c'est aussi une communauté, une entité juridique au dessus, des valeurs, des choix politiques.

      Pour construire tout ça, il a fallu discuter, se réunir, écrire, parler finances, administratif, droit, community management, modération, communication, prise de décision…

      Je vous laisse deviner si ma capacité à écrire des tests unitaires en Python ou à utiliser les métaclasses a été d'une quelconque utilité dans ce processus, par rapport à, disons, mes courts de droit, d'éco, de gestion, de communication, de marketing…

      Certes, on pourrait considérer que je pinaille et que ce n'est pas du travail de dev à properement parler.

      Pour moi, ça fait partie de mon boulot de dev', de faire en sorte que mon environnement de travail soit adapté à mes besoins, à à ceux des autres, et à ceux du projet.

      Un peux comme le fait de choisir ses fournisseurs, ses outils, ses tarifs, ses CGU quand on bosse, mettons, dans la construction fait partie du boulot.

      Formulé autrement, si tu as envie de développer un logiciel, tu ne peux pas juste ignorer ces questions. Donc ça fait partie du boulot (même si c'est une autre personne qui s'en occupe).

      Le corollaire, c'est que si vous avez ces compétences là, vous pouvez acquérir celles qui vous manquent (genre la programmation) *après*.

      Ça fera pas de vous un·e moins bon·ne dev !

   2. ❤ Bram ❤ (bram@social.wxcafe.net)'s status on Friday, 02-Aug-2019 09:50:02 EDT ❤ Bram ❤

      in reply to

      @eliotberriot un truc qui me fascine vraiment dans notre milieux c'est toute cette série de biais :

      - ma valeur dépend de ce que je sais faire [de technique]
      - y a "que" le savoir technique qui compte vraiment/est valorisé
      - c'est + valorisé d'avoir du savoir absolu alors qu'on est dans une dimension de la surabondance et que pouvoir gérer (apprendre par soit même etc...) est méga plus important
      - on parlait jamais des "softs skills" (gestion de projet, d'équipe, émotions...)

   3. Elisa, clueless kitty (electron@social.art-software.fr)'s status on Friday, 02-Aug-2019 05:02:15 EDT Elisa, clueless kitty

      in reply to

      @eliotberriot
      Si tu veux la différence entre les bits, les bytes et les octets c'est une histoire de paquets.

      Un bit c'est une unité d'information. En l'occurence soit zéro, soit un. C'est un peu l'équivalent du pixel pour l'image: tu peux pas faire plus petit.

      Un *byte*, c'est ce qu'on appelle en français un "mot": c'est un ensemble de bits. pas forcément huit, tu noteras. Sur les anciens ordinateurs d'ailleurs c'était assez peu souvent huit. Cinq, Six, sept, douze, seize etc.

      Un octet, c'est juste un byte dont la taille est fixée à huit bits.

      Donc un octet peut prendre 2⁸ valeurs différentes (vu que chacun de ses bits peut prendre deux valeurs), ça fait 256.