Ce que personne ne te dira sur le métier de développeur

Ce que personne ne te dira sur le métier de développeur

Le métier de développeur a beaucoup d’avantages. Mais crois-moi quand je te dis qu’on est loin de la promenade à Walt Disney. Avec le besoin exponentiel de développeur et du coup l’explosion des formations j’entends beaucoup de gens vendre le métier comme un séjour au Club Med. Alors, pourquoi pas mettre une crotte de nez au milieu du visage de cette réputation parfaite ? Aujourd’hui je vais te dire ce qu’on oublie de te préciser sur le métier de développeur.



Pas de repos pour les braves

Dans la plupart des métiers, tu apprends énormément au début et après tu affines ton savoir via ton expérience. Je te le dis tout de suite tu fais ça en tant que développeur autant allumer le gaz et fermer les fenêtres c’est pareil. Ce métier change en permanence, c’est pénible et la cadence est infernale. Car il y a un gros problème avec le métier de développeur. Personne ne t’a dit qu’il n’y a pas de règle absolue en termes de ce que tu dois apprendre. Il n’y a pas un langage à connaître ou un framework à maîtriser. Tout est tendance. Une tendance par définition est passagère. Ça fait de toi quelqu’un de cool et recherché par les recruteurs à un moment T. Et un énorme plouc le lendemain.

Tu nages dans un océan de savoir et si tu nages pas assez vite tu te fais bouffer par des requins. Alors oui effectivement tu peux ne rien apprendre et faire exactement la même chose au même endroit pendant 10 ans. Mais dans ces conditions, je peux te dire que tu n’es pas prêt pour le jour de l’entretien.



Un entretien avec Quentin

Salut! Je viens de voir ton CV et je vois que tu connais Javascript. C’est cool hein mais ici on fait du Go. Le projet a un besoin extrême de gestion concurrentielle. Bon bien évidemment tout est Dockerisé ça va sans dire. D’ailleurs en local on bosse avec Minikube dans une VM Vagrant, provisionnée avec Ansible évidemment. Après ça part sur une dizaine d’étapes CI-CD en continuous delivery sur GitLab, la base. En prod y’a un Terraform qui spawn l’infra et Helm coté applicatif qui spawn le HaProxy qui va gérer le Load Balancing sur un cluster Kubernetes via GCP, classique. Tu vas voir c’est cool on a un gros Istio qui gère les permissions via des Sidecard Proxy et une stack EFK pour monitorer tout ça. Hein ? Ha oui tout le monde est DevOps ici c’est obligatoire, y’a pas mal de SecOps aussi. Ça me fait penser qu’on a aussi du Legacy sur AWS. Donc si en plus tu connais le fonctionnement des VPC et de CloudFormation ça va vraiment peser dans la balance pour ton embauche.





Bon, je me moque comme un gros sale mais en vrai j’aime beaucoup l’annonce de Quentin. Quand j’ai vu cette vidéo, j’étais à fond, leur stack en jette et ça a l’air super intéressant ce qu’ils font dans leur boite. Mais si tu n’es pas prêt à te remettre en question tous les matins et apprendre quelque chose fréquemment, n’appelle pas Quentin. D’ailleurs, n’appelle personne, car être développeur la plupart du temps c’est travailler pour Quentin. Ça s’arrête jamais.



Demandes improbables

Beaucoup de gens qui gèrent les projets informatiques n’ont aucune connaissance en informatique. Ça arrive très souvent quand t’es dans une petite boite. La petite boite elle veut impressionner son client et ça à petit prix. Ils vont promettre un truc impossible au client et venir te voir après avec un grand smile. Personne ne t’a dit que tu allais devoir révolutionner internet pour hier à cause de Jean-Michel chef de projet. Pourtant ça arrive tout le temps. Et à part serrer les fesses et essayer de trouver un compromis difficile de se sortir de cette situation. Du coup tu quittes ta petite boite pour une grosse boîte. Et là une nouvelle surprise t’attend.

Cette surprise s’appelle l’over-engineering. Je te prends un exemple simple : tu dois rajouter un champ dans un formulaire. Ça a l’air simple, mais ça ne l’est pas. Car le formulaire il est dans un énorme portail en prod. Déjà il faut mettre à jour la base de données en mettant à jour le script de migration lancé au moment du build sur la CI au moment du docker build. Si tu ne maîtrises pas bash, docker et la CI-CD déjà t’es pas bien et tu transpires. Et t’as rien fait là encore ! Il reste à mettre à jour le model de données backend, la validation coté UI, ajouter des tests unitaires, des tests d’intégration, des tests fonctionnels, passer la code review, passer la QA, déployer sur tous les environnements pour enfin prier de pas te péter la gueule en prod. Ça t’a pris trois jours et t’as fait deux crises d’épilepsie.



décision


Et quand t’es extérieur au métier ou que t’as jamais travaillé sur des projets de grande taille, c’est incompréhensible. De l’extérieur t’es juste un débile qui sait pas rajouter un champ dans un formulaire. Alors qu’en fait tu viens de passer sur 60 couches de tech pour faire ça. Personne ne t’a dit que tu allais gérer de la complexité extrême tout en passant pour un con. Imagine avec un problème plus compliqué que ça ? Tu crois que c’est pour faire joli qu’il y’a autant de spécialisations chez les dév ?



L’enfer c’est les autres

Beaucoup de développeurs se construisent un égo aussi gros que la tour Eiffel. Très rapidement, ça devient toxique avec tout le monde et ça rend ton boulot pénible. Allant jusqu’à réveiller chez certains le trop connu syndrome de l’imposteur. Ces gens sont une réalité et on ne t’a pas dit que t’allais travailler avec eux tous les jours. Ils sont là à cause du côté concurrentiel lié au métier et de tout ce qu’il faut en savoir pour être efficace. Mais ces gens, même si tu vas avoir envie de les découper lentement, ils ne seront pas ton principal problème.

Si tu n’es pas un énorme touriste, tu vas vouloir mener à bien tes projets. Et surtout tu vas vouloir les finir à temps. Tu te doutes bien que les deadlines ne sont pas toujours bien alignées avec la réalité du travail que tu dois effectuer pas vrai ? Hé bien ce qu’on ne t’a pas dit c’est que en fait les deadlines ne sont jamais alignées avec la montagne de boulot qui t’attend. C’est un running gag les deadlines dans ce métier. Mais ça fait plus rire personne.



métier de développeur


Ça te fait plus rire parce que tu retrouves à faire des 50 – 60 h par semaine parce que « le client ne peut pas attendre ». Et c’est pas la première fois. Ni la dernière d’ailleurs. Certains parlent de fatalité dans le métier de développeur d’autres font carrément des tutos pour éviter le burnout. Bordel des tutos anti-burnout on est où ? En tout cas moi je sais que c’est dans cette situation que tu commences à arrêter d’utiliser tes mains pour coder.



Attente et réalité

Il y a déjà pas mal d’années, je suis arrivé frais comme un gardon à mon premier stage. J’étais au top. Dans ma tête je pensais que j’allais développer le nouveau Facebook. Sky is the limit je suis un hacker comme dans les films. Et là je me suis pris une énorme tarte dans la gueule.

– Ouais salut, donc toi tu vas faire que des jeux Facebook pour aspirer un maximum de données personnelles.
– Ha! OK. Mais du coup je fais des jeux c’est cool!
– Mais non ferme l
à, c’est une boite externe qui fait les jeux, t’es con ou quoi? Toi tu fais juste l’aspirateur de données personnelles. Et vas-y franchement on veut du gros, du sale, du poilu, les mails, les photos, les amis, les téléphones tu mets tout open-bar. Personne ne lit, ça clique OK, on y va franchement.

Autant te dire que je me suis barré assez vite de cet enfer et que cette boite n’apparaît pas sur mon CV. Et là je te vois avec ton regard hostile tu vas me dire que c’est normal au début de faire des boulots de merde. Certes, mais le problème c’est qu’après ça va durer un peu. Tu as le choix entre les applications de retraite les plus chiantes du monde que personne veut faire ou les sites vitrine pour des sirops copiés/collés à la chaîne. Et je te parle même pas du code legacy ! Beaucoup de monde ne fait que nettoyer la merde des autres pendant un moment. Tu vas pas travailler pour la NASA, tu vas nettoyer du caca. On ne t’a pas dit que les boulots intéressants sont quasiment toujours réservés aux développeurs expérimentés.

Enfin dans la tête de beaucoup de monde le métier de développeur ça ressemble à un espèce de hacker avec une capuche qui fait des trucs de fous. Un magicien des temps modernes qui fait de la magie noire à chaque fois qu’il touche le clavier. La réalité est tout autre.





Y’a pas de magie. Y’a énormément de réflexion en amont. Organiser sa pensée pour transformer un problème du monde réel en une solution informatique via un processus d’abstraction qui fait du sens. On ne t’a pas dit que tu passes plus de temps à réfléchir à une solution qu’à l’implémenter. Il te faut un niveau absurde de concentration. Il te faut maintenir cette concentration pendant des heures seul face à l’écran. Ensuite, c’est des heures passées à rechercher des codes d’erreurs sur Google et à lire des documentations interminables. On ne t’a pas dit que ce métier c’est fouiller sur Google toute la journée ? Avec le temps passé sur Stack Overflow et sur d’autres forums tu t’en rends rapidement compte.



Épilogue

Ça doit faire en moins cinq minutes que tu m’écoutes chialer. Alors le métier de développeur est le pire métier de la terre ? Je suis un malheureux hein ? Bien sûr que non. C’est super le métier développeur et y’a plein d’avantages. Et si tu penses devenir dev, je t’invite fortement à tenter l’aventure. Mais c’est loin d’être le paradis qu’on t’a survendu partout. Arrêtons de présenter ce métier comme la neuvième merveille du monde. Acceptons la réalité que parfois c’est tout moisi. Comme tous les boulots de la terre.

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment, je suis développeur backend senior / DevOps à Montréal pour un géant du jeux vidéo. Le dev est l'une de mes passions et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cet e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

Pour me soutenir, la boutique officielle est disponible ! Sinon désactiver le bloqueur de pub et/ou utiliser les liens affiliés dans les articles, ça m'aide aussi.

39 commentaires sur “Ce que personne ne te dira sur le métier de développeur”

  1. C’est tellement ma vie !
    J’ai juste eut la chance de quasi pas faire de merde au début, j’ai vite été sur un gros projet intéressant 🙂
    Sinon, il manque aussi les outils qui feraient gagner des heures et des heures que le client / le patron ne veut pas mettre en place « parceque ça marche comme ça », pas de ci / cd par exemple a l’opposé de l’over engeneering 😅

  2. Oui, tout cela plus les situations merdiques à la noix où tu es sous-marin d’une agence en sous-marin. Résultat, dernier maillon de la chaine, tu ramasses aussi pour tous les autres. Par contre, ça sera toujours le dev qui met du temps – on lui a transmis y a 2mn, mais bon 🙂

    Ou le cas où le matin tu es support sous-marin N-1 et l’après-midi support sous-marin N-2. Le matin tu dis oui, et l’après-midi, tu dis non. A la même personne et/ou à la même demande, parce que « politique ». Ou les discussions à 3 par groupe de 2, ou ça se contredit entre client, agence et sous-marin.

    Un autre point pas facile à gérer : quand on te demande d’implémenter un truc, et que tu pointes les trous dans la spec (et encore, des fois, c’est dans le modèle même). Et là, le fantastique CdP fraichement arrivé et avec les dents longues voit ses idées géniales balayées par un pauvre dev qui montre par A+B que son modèle révolutionnaire de gestion de mon Q tombe complètement à plat face à la réalité de l’existant (dont il n’a pas connaissance).

    Pire, quand tu es sous-traitant, tu as le CdP et ton boss tout contents qui se félicitent de leur brillantituderie… et tu vas lever la main et dire « et dans ce cas ? ». Au choix, tu vas être soit l’emmerdeur soit le pénible. Le problème va être enterré… jusqu’à ce qu’il se déterre tout seul. En général, au pire moment.

  3. Bonjour,
    Ce qui m’a le plus étonné et qui m’étonne encore c’est la perte de bon sens.
    Je sais bien que les gens n’ont pas idée de ce que le développement peut faire mais :
    – J’ai donné un GO, vous avez mis en prod, l’utilisatrice principale va commencer ses 1ers tests –> Quoi ?
    – On avait dit un mois d’historique indexé, ça va si on passe à 12 ?
    – …
    Je suis souvent de faire des métaphores à base de ville, de docteur, de garagistes pour que connaissance technique ou pas on marche sur la tête

  4. Ah! ça me rassure tellement de lire ça, enfin pas la partie on pompe les infos des utilisateurs d’appli FB mais la partie : développer c’est 90% faire des recherches et de la réflexion. Je débute un BTS pour être dev et souvent j’ai la sensation que ce que j’apprend ne représente qu’une goutte d’eau dans un océan de connaissance sans fin ! Je passe mon temps à faire des recherches sur les technos qu’on utilise et au final j’ai pas l’impression de coder des masses.
    Enfin bref, sympas ton article 🙂

  5. Après plus de 12 ans de dev divers et variés (c++, Java, php et JS) j’ai appris quelques trucs qui évitent bien des problèmes :

    – Les boîtes qui te présente leur stack de ouf au détriment de la simplicité juste parce que « Google et Amazon l’utilisent » sont a fuir comme la peste.

    – Il faut se méfier des tendances , particulièrement dans le web. Perso je me penche sur une techno que si elle a quelques années derrière elle (hors demande client spécifique)

    – Les délais intenables c’est pas mon problème. T’as chiffrer sans me consulter avant ? T’assumes ta connerie c’est pas a moi de réparer.

    1. – Les délais intenables c’est pas mon problème. T’as chiffrer sans me consulter avant ? T’assumes ta connerie c’est pas a moi de réparer.

      C’est exactement ca ! Par contre, c’est plus facile a dire qu’a faire quand tu est un junior et que tu viens d’arriver.

      1. En plus de demander des couilles pour tenir tete aux gens dans cette situation… ce qui la encore n’est pas donné a tout le monde. Et le risque ici c’est de passé pour un emmerdeur.

    2. Je suis d’accord sur les deux premiers points : c’est ce qu’on appelle la Hype Driven Development

      Sur le troisième je suis d’accord en théorie mais dans la vraie vie ça se passe pas comme ça (à part si on a vraiment besoin de toi). Si t’es junior et facilement remplaçable, tu te fais juste dégager comme un mal propre si tu réponds souvent comme ça

    3. Rassurant point de vue, que je partage. Qui m’a meme été ‘enseigné’ en alternance par un senior… Voilà pourquoi de FrameworksJS je vais sur PHP youpi!

  6. Ahahah j’adore cet article. Jolie crotte de nez dressée au milieu du tableau. Après je tiens à dire que l’annonce de Quentin m’a fait flipper ! Toutes les sociétés ne sont pas aussi avant-gardiste que ça. Y’a moyen de trouver des sociétés ou il n’y pas besoin d’en connaître autant même si c’est vrai, un dev doit se tenir à la page

  7. >>Organiser sa pensée
    Je m’étais demandé à moment pourquoi on trouvait bcp de trucs innommables dans du code source, une des raisons est qu’on ne peut pas réfléchir dans la vitesse, à moins d’avoir un QI élevé.
    Aborder le toyotisme, pardon l’Agile, ce serait bien aussi. Quant on me parle de cadence et de vélocité, je commence à m’inquiéter.
    A ce jour l’organisation du travail tend à rendre le métier de développeur à l’identique des ouvriers spécialisés sur une chaîne de fabrication.
    Un début de réflexion : http://www.seuil.com/ouvrage/la-chaine-invisible-jean-pierre-durand/9782021092165

    >>On ne t’a pas dit que ce métier c’est fouiller sur Google toute la journée ?
    Bien évidement tu le fais en dehors de ton temps de travail, car quand t’es cadencé faut bien produire quelque chose à la fin de la journée.

  8. Oh mince c’est presque tellement moi ! Sauf que je ne développe pas pour le web mais pour le print. A mon poste mes collègues me voit comme le magicien (je suis seul) qui résout toutes leurs merdes du quotidien et quand je rale qu’ils me polluent mon propre temps de production, ils sont surpris de ma réaction, me disent qu’ils me comprennent et… recommencent moins de 30s plus tard :3 funny story ?!

  9. Bonjour,
    Sinon en terme de la rigueur demandée dans toutes les annonces ? Comment formulez un projet professionnel avec ce que je viens de lire….?

    1. Article difficile à lire quand on vit cette situation, je suis une victime de ces formations qui te vendent ce métier comme quelque chose de passionnant.
      Pour ma part j’ai un an en entreprise et je suis déjà au bord du gouffre, j’ai envie de tout arrêter et de faire autre chose mais n’ayant que cette formation en poche je n’ai aucune autre possibilité… Du coup je reste et subis ce boulot.
      Bref si j’ai un conseil à ceux qui veulent se lancer là dedans c’est de bien vous attendre à ce que dit cet article.

  10. Franchement, je n’ai RIEN compris à l’annonce de Quentin… Je ne sais même pas ce que sa boite fait, c’est trop compliqué tout ça, pas vraiment KISS.

  11. J’ai d’abord cru que l’annonce de Quentin était une blague… C’est quand j’ai vu que les commentaires étaient désactivés que j’ai commencé à douter.

  12. Hey full stack Bébé .
    Faut savoir s’imposer 😏
    C’est dur et amusant aussi fait savoir s’entourer de ceux qu’il nous faut comme équipe c’est l’essentiel .
    Et du CSS en masse 🧠🤪

  13. Un bonheur à lire cet article!! En formation développeur web…. Je commence à mettre en relation la cadence de la formation et celle du métier!!!! Mais on y prend un tel plaisir (enfin pour l’instant)!!! Au moins on sait à quoi s’attendre!!

  14. 1. En SSII tu es présenté comme expert rien que par ce tu connait le nom d’un produit.
    2. La MEP est pour hier alors que personne ne sait faire la différence entre ce qui est demandé et ce qui est utile ou nécessaire.
    3. Si tu part en vacance 2 semaines tu est obsolète depuis 20 ans en revenant
    4. En 40 ans de dev en télécom puis en gestion , j’ai du apprendre une quinzaine de langages. A l’aube de la retraite, je n’en maîtrise que 3 ou 4 et encore.
    😀
    Beaucoup de stress souvent
    La reconnaissance rarement.
    Nous sommes outilleurs .
    Nous utilisons des outils conçus par d’autres pour fabriquer des outils destinés à d’autres.
    Mélange de frustrations et de satisfactions.

  15. le monde du travail dans toute sa splendeur, je ne suis pas Dev mais electro-mecanicien.
    les deadlines on connais l’obsolescence de nos connaissances aussi, l’esclavage et la merde quand tu es junior, ramasser la merde des commerciaux et autres charlatans…
    Le soir tu as mal à la tête moi j’ai mal au dos, et la fin du mois mal au cul au moment de la paye… (je suis parti dans l’agriculteur Bio maintenant)
    j’ai toujours mal au dos mais je sais pourquoi pour qui et pour quel salaire.

  16. Alors, … si tu remplaces « développeur » par « développeur backend/fullstack/devops/autre connerie du genre » je suis d’accord. Sinon, ton article est totalement faux pour:
    * Les développeurs embarqués (C sur du ARM, la tendance on s’en torche).
    * Les développeurs Java (On peut pas dire que le java aie beaucoup évolué ces dernières années)
    * Etc….

    En gros, seuls les développeurs sur les technos web ou assimilées sont sujets à cette pression des « tendances » que tu décris et même si aujourd’hui ils sont nombreux, ils ne sont pas représentatifs de l’intégralité des développeurs.

    Pour finir, le côté « syndrome de l’imposteur » est très très très loin d’être spécifique au métier de développeur. En fait, c’est ce qui gangrène de façon générale le monde actuellement. Regarde les politiques.
    Dès l’instant ou tu sors d’une structure type startup, que tu sois secrétaire, développeur, chaudronnier ou sur une chaine d’assemblage de gode-michet, tu devras composer avec ce genre de profil « sous-merdique ». C’est pas un problème de développeur, c’est un problème sociétal.

    Tu veux vivre mieux ? Reconvertis toi sur des technos qui soient moins soumise à l’effet de mode: dev embarqué, dev C++, Java ou Cobol. Si tu sais pas gérer le côté très très mouvant de l’univers « web-centric », alors tu te feras bouffer à y rester.

    1. Je suis d’accord que le développeur embarqué ne soit pas soumis à cette pression d’effet de mode, l’embarqué utilise majoritairement le langage C(un vieux langage sure pour l’embarqué)., Le C++ n’est que minoritairement utilisé dans l’embarqué, je ne considère pas le développement système comme de l’embarqué.

      Mais je conteste complètement le cas du java dont la majorité d’application actuelle se concentre soit sur les appli mobile avec Java ME pour Android, soit sur les appli web avec Java EE ainsi qu’avec spring. C’est soit du web, soit du mobile, donc très soumis à la pression d’effet de mode(crossover massif sur les librairies, devops, methodologie agile et consort).

    2. A cela, j’ajoute une chose très importante, je l’ai remarqué mais je ne sais pas pour vous.
      C’est que derrière toutes ces complications, il y a une question d’argent.
      Premièrement, les ESN/SSII, startups sont obligés de suivre les tendances et de multiplier la stack technique pour se différencier des autres afin de mieux se vendre auprès du client finaux (Donc on juge par l’argent mais non pas pour la réussite réelle du projet).
      Deuxièmement, les ESN/SSII, startups multiplient la stack technique et par la même occasion la taille de l’équipe (devops, secops, développeur backend, développeur frontend, UX/UI designer, Srum master, Product owner) ou le nombre de services incluses dans la réalisation (devops, secops, développement backend, développement front end, UX/UI design, Srum, planning poker), dans le but de gonfler le budget à faire payer aux clients finaux.
      C’est décevant, mais le but réel est là, gonfler le budget. Mais je ne leur en veux pas, c’est difficile de trouver un client. En augmentant le nombre de services inclus dans le projet, on augmente la durée de réalisation et par la même occasion, on oblige le client à rester plus longtemps.

    1. Et allez il nous manquait un sjw. 1- Il n’y a pas beaucoup de femmes dans le dév. 2- Si la jalousie du genre masculin comme genre neutre a même gagné le cerveau des mecs, alors autant en inventer un nouveau qui regroupe tout le monde plutôt que de compliquer la langue et de la rendre dégueulasse à lire. Merci.

  17. Cet article force pas mal sur les côtés négatifs et c’est le but.
    La partie sur la course folle aux nouvelles technos est vrai. Ca devient insupportable toute cette hype.
    Par contre, il faut être honnête, ça reste un métier quand même beaucoup plus confortable et dans lequel on est beaucoup plus indépendant que dans 99% des autres métiers actuel.

  18. une question non traitée :
    est ce que le ratio heures de travail / salaire vaut le coup ?
    Je suis en reconversion pro et je viens d’un monde où je n’allume pas mon ordi en dehors des heures de travail en entreprise. Je suis mal payé mais mon cerveau n’est pas mis en danger à court terme. Se lancer dans l’aventure dev web c’est aussi pour se dire que le travail paye. Mais jusqu’à quel niveau ?

    1. Tu fais mini 40h par semaine, soit 160h par mois. Il te faut sans cesse te reformer, donc ajoute encore des heures, c’est cette constante reformation qui ajoute les heures.

      Disons que si t’es chanceux, t’es payé 2200e net à Paris en junior/medior. 2200E/160h=14e net par heure.

      C’est des approximations, a vérifier avec d’autres témoignages, mais en gros, tu serais payé entre 11 et 20e net par heure dans la plupart des cas à Paris.

      Y’a pire, mais y’a peut être mieux, c’est chronophage. A voir donc. Faites une vrai grosse enquête avant de vous lancer.

      1. Alexis, tu as des droits en termes de formation. Ton entreprise doit te permettre de te former, et ce sur ton temps de travail. Et je parle bien de formations financées par l’entreprise. A moins que tu ne sois freelance ou je ne sais quel profil particulier 🙂

    2. Bonjour,

      En réalité, ça dépend beaucoup de ta personnalité et de ton manager/chef de projet. Si tu communiques pas et si ton CP est mauvais, ça se passera mal et tu seras toujours en train de faire des heures sup’ gratuites pour rattraper des prétendus « retards ». En revanche, si tu communiques régulièrement sur les obstacles que tu rencontres, si tu préviens assez tôt que tu vas dépasser le temps alloué à ta tâche et si ton CP sait exercer son rôle (planifier, expliquer les retards au client, lui dire non quand c’est justifié), des solutions seront trouvées.

      On te dira peut être que « machin bosse plus vite que toi », mais la vitesse n’est qu’un paramètre : combien de retours (bugs, anomalies, insatisfactions…) ? le code produit est-il facile à maintenir ? etc. Coder vite n’est pas avantageux si on passe plus de temps à corriger des bugs et à galérer en maintenance. Mais coder « bien » ça prend nécessairement du temps. Il faut en parler et le dire : soit je code plus vite au détriment de la qualité, soit on me donne du temps pour coder correctement, mais je ne peux pas faire les deux. Au moins les choses sont claires dès le départ.

      Perso, je travaille en ESN (SSII) depuis plusieurs années. En tant que junior, je ne savais pas ça, et effectivement je faisais pas mal d’heures sup NON PAYEES. Pour qu’elles soient payées, il fallait que ce soit prévu en avance par le projet, ce qui n’était jamais le cas (les fameux « retards »). Aujourd’hui, ça ne m’arrive plus et je fais sereinement les 37,5h prévues par mon contrat, pas une de plus. Car si tu es malin, tu arriveras à te dégager les heures de veille techno sur ton temps de travail, et non sur ton temps perso (ce qui est pour moi aberrant). Il y a certes des périodes plus animées que d’autres, il faut en tenir compte et trouver un équilibre. Si tu dépasses tes horaires un jour/une semaine, fais moins le jour suivant/la semaine suivante.

      Choses à retenir pour être serein au boulot :
      1) pas besoin d’avoir « des couilles » pour communiquer sur les retards/les chiffrages des tâches, au contraire. Quelqu’un qui communique bien est apprécié en tant que tel car il facilite le boulot du CP, et évite les mauvaises surprises qui dégradent fortement les conditions de travail de toute l’équipe.
      2) si malgré tout tes efforts ça se passe mal, change de collègues (en changeant de projet ou carrément de boite selon les cas)

  19. Salut à tous. Sincèrement merci. Merci d’avoir donné la réalité de ce métier que je m’apprêtait a faire. J’ai 40 piges avec 20 années de commercial à la con dans les assurances , où on me demandait de vendre n’importe quoi à n’importe qui. A me demander « combien ça va ? »et non « comment ça va? ». A ne plus pouvoir me regarder dans une glace tellement j’avais honte de moi d’arnaquer des gens. A avoir la pression des objectifs faire des comptes rendus mensuel, hebdo et journalier WTF !!! Après un burn out, je commence une période de chômage, pendant laquelle je me suis dis il faut vraiment faire autre chose. J’aime l’informatique , les nouvelles technologies, c’est donc tout naturellement que je me suis tournée vers ce domaine. Je commençais à m’autoformer avant d’intégrer une formation de 6 mois en distanciel.
    Mais là j’ai bien compris que je rêvais tout debout, je pensais faire du total remote pépère peut importe les heures mais j’avoue que cet article a au moins le mérite de planter le décor et au vus des commentaires c’est vraiment le cas. Donc merci de m’avoir ouvert les yeux, il ne me reste plus qu’a m’arracher les cheveux à trouver le quoi faire, ou quand comment dans quelle étagère? bref trouver ma voix. Biz à tous les dev que je ne connaîtrait pas du coup.

  20. Etant Dev Front-end Drupal je confirme !! Je pense retourner à mes bases … Java … Monde de requins sans compter que la moindre faiblesse on te jette, on presse le citron jusqu’au bout puis on te dégage du jour au lendemain pour des travailleurs nearshores indoux polonais ukrainiens … Bref le tiers de ton salaire ….
    Tu bosses sur une chouette techno mais on te dit après deux ans de code il faut tout changer t’adapter et apprendre aussi vite que qqun qui a 10 ans d’expérience … Bref ce monde m’a dégoûté et je me demande si je ne vais pas changer de voie …. Après coder pour soi-même c’est top et plaisant. Pour ma part je ne suis pas un grand developpeur full stack mais j’adore cela quand même.

  21. Bonjour,

    J’effectuais une recherche pour essayer de comprendre pourquoi autant de devs ne savent pas organiser et construire leurs codes convenablement, ou si cela venait de mon côté un peu trop psycho rigide ou vieux con.

    Maintenant, mon intuition est confirmer. En faite, dans beaucoup d’entreprises, ils en ont rien à foutre du code ou plutôt de l’algorithme. Seul le résultat compte !!! Dans les temps, et peu importe les moyens et les technologies utilisés.

    Du coup, beaucoup de personnes sont formées à l’exécution en développement plus qu’à la conception. A la final si pas de conceptions cohérente, alors grosse difficulté pour la maintenabilité, l’évolution, la sécurisation des applications ainsi que la standardisation des processus interne.

    Quand tu vois des personnes qui sont à la conception logiciel qui confondent un brouillon (draft) applicatif avec une épreuve de conception (Proof Of Concept). Je crois que cela se passe de commentaires.
    Quand tu as un nouveau venu en développement qui se retrouve à torcher la merde des aux autres en permanences et à qui personne n’attribut de projet. Alors que dans se vie privé, il construit de superbe projet et s’investit de manière associatif. Là ça se passe commentaire.

    C’est comme ça que nous retrouvons avec des différences majeurs entre (par exemple) un SOAP* qui a un WSDL/XSD** qui est différent du XML*** a envoyer. Avec des constructions différentes bien marquées au niveau des schémas. Ce qui permet aux devs un grosse perte de temps et de passer pour un con.

    Une autre chose qui me fait beaucoup rire, c’est le lâchage de mots techniques. Même si en tant que vieux loup de mer, je connais et comprends leurs significations, c’est pas pour autant que les personnes en face de moi qui les utilises les comprennent. ( Je dis ça pour certain RH. 😉 )

    Donc, je suis peut-être de la vielle école, mais lorsque je discute technique, j’évite d’utiliser les désignations de marques ou nom logiciel, mais plus le processus technique qu’il représente. Effectivement, par exemple, plutôt que de parler de VirtualBox, MiniKube, VMWare, je préfère nettement les termes superviseurs, machine hôte [etc]. Un exemple, les personnes qui parlent de Docker mais en faite qui désigne une partie de l’architecture Docker qui est le containeur, et qui connaissent que ça … 😅

    Enfin, petite réflexion du jour : C’est pas le code qui doit organiser l’algorithme, mais l’algorithme qui doit organiser le code.

    * Technologie d’interfaçage machines machines
    ** Fichiers de description schématique pour savoir comment échanger des données avec un serveur distant
    ** Fichier résultant du schéma de description qui sera envoyé au serveur distant

  22. Moi je vous donne mon avis après de nombreuses années de DEV (6502 à l’origine, RPZ pour ceux qui connaissent 😉 :

    On bosse pour des brèles en informatique qui savent même pas ce que c’est un OS ou un HDD ou je ne sais pas un bit !! C’est eux les bites. Franchement ce métier c’est vraiment de la merde, tu as un très haut niveau dans le domaine et on crois toujours que tu ne fous rien parce que visuellement ça ne se remarque pas. Beaucoup de DEV sont malheureux, les projets sont pourtant magnifiques, mais l’environnement des non-tech est horrible ! Attention à ceux qui ne sont pas des guerriers, ça pique !

    « Bande de p’tits cons » (amicalement bien entendu).

T'en penses quoi ?

Your email address will not be published. Required fields are marked *