Astuces pour digérer une sale journée de travail ?

Je n’ai jamais dit que ça n’était pas pareil dans toutes les boîtes d’info. J’ai dit que c’était surtout courant dans les ESN.

Je pense qu’il faut définir « les technos de son temps ». J’avais lu un article il y a quelques temps (je n’arrive plus à mettre la main dessus) où son auteur expliquait qu’il valait parfois mieux partir sur une technologie legacy qui avait fait ses preuves sur plusieurs années (une décennie) plutôt que de prendre le dernier joujou à la mode. Et encore, qu’on se le répète, ça dépend vraiment du besoin (pour reprendre tes propos, attention à la Silver Bullet).

L’idée n’est pas, à titre d’exemple, d’utiliser Python 2 ou je ne sais quoi. L’idée c’est d’utiliser des outils qui certes ne sont pas sexy, mais qui ont été éprouvés au fil du temps et sont encore valable aujourd’hui dans la plupart des cas. Car des outils qui survivent, c’est des outils utilisés par des gens, il y a donc de la documentation, une communauté et peut-être davantage d’environnements professionnels où nous sommes susceptibles d’apporter quelque chose (subséquemment ça résout le problème de « j’arrive sur un environnement technique que personne ne connaît parce que c’est tout nouveau et pas encore utilisé ailleurs »).

Tu n’as peut-être pas les mêmes exigences qualité qu’un développeur logiciel ?

Vu le domaine dans lequel il bosse, je pense que Arius a pas mal d’exigences en qualité Mais c’était pour le coup juste une pique, vu qu’il bosse dans le juridique, ça reste très différent des secteurs techniques et scientifiques.

Mais perso, dans le bâtiment on n’aime pas non plus dépasser les deadlines, surtout quand on voit le niveau des indemnités de retard. Ce qui était assez rigolo avec le premier confinement puisque des maîtres d’ouvrage ont bien balancé que c’était pas leur problème, et que les entreprises de construction allaient donc tout prendre à leur charge.

Je n’ai jamais dit que ça n’était pas pareil dans toutes les boîtes d’info. J’ai dit que c’était surtout courant dans les ESN.

Et c’est ce qui me dérange dans ton propos, parce que pour moi cela revient gratuitement à mettre le spotlight les ESN alors que ce n’est pas plus courant là-bas qu’ailleurs. Tu as cité tout sauf la phrase importante de mon post : c’est un processus normal et sain.

En bref, le seul moyen pour une boîte de continuer à vivre et de rester concurrentiel, c’est d’évoluer avec les technos de son temps

Je pense qu’il faut définir « les technos de son temps ». J’avais lu un article il y a quelques temps (je n’arrive plus à mettre la main dessus) où son auteur expliquait qu’il valait parfois mieux partir sur une technologie legacy qui avait fait ses preuves sur plusieurs années (une décennie) plutôt que de prendre le dernier joujou à la mode. Et encore, qu’on se le répète, ça dépend vraiment du besoin (pour reprendre tes propos, attention à la Silver Bullet).

Il ne s’agit absolument pas de chercher des silver bullets. Il s’agit de faire de la veille et d’expérimenter pour évoluer. Ce que je lis dans ce paragraphe sembler reposer sur plusieurs hypothèses tacites que j’ai appris à ne plus faire avec le temps :

• Tout projet doit être fait avec une collection de technologies à la fois homogène et figée dans le temps : ce qui n’est presque jamais le cas depuis 10 ans, et n’est juste plus du tout vrai dans les architectures micro-services. C’est tout leur intérêt, chaque service étant abstrait derrière son API, tu peux bien l’implémenter en Python ou Node ou PHP au début pour le livrer rapidement, le passer en Go pour améliorer ses perfs quelques mois plus tard, puis le passer en Rust encore quelques mois plus tard quand tu t’aperçois que le GC est son point de contention… Tu peux donc choisir, pour chaque élément de ton système, la techno qui fait le mieux le job, et donc tu as le loisir d’expérimenter : le risque que tu prends ce faisant est parfaitement maîtrisé, parce que son scope est réduit et délimité par son API. C’est exactement l’opposé de la recherche d’une silver bullet.
• Adopter une nouvelle techno, c’est adopter un joujou ou quelque chose de sexy : je peux te citer plusieurs technos modernes qui font extrêmement bien leur job, et qui sont tout sauf sexy. Le premier exemple qui me vient en tête est fluentd : jamais je ne me suis senti plus sale qu’en configurant des règles pour cet outil qui est à la fois récent (cloud native) et anti-sexy, et pourtant il s’agit du standard de facto pour router et pré-traiter des logs dans un environnement comme Kubernetes, c’est le plus documenté et le plus efficace, et passer par une stack EFK est beaucoup moins coûteux dans ce genre d’environnement que d’essayer d’y mapper une gestion des logs "à l’ancienne" avec syslog ou journald et/ou Logstash.
• Le seul besoin qui compte est celui du client : en tant qu’entreprise d’informatique, tu as un besoin de faire de la veille, d’essayer des nouvelles choses, de minimiser ton effort (et donc tes coûts), de faire mieux demain ce que tu as fait jusqu’à aujourd’hui. Ce besoin, en tant que développeur, est tout aussi important que celui auquel tu réponds. Dans une boîte d’info, un projet n’est que rarement quelque chose d’isolé ou à prendre en isolation de tous tes autres projets : il vient dans un contexte. C’est de l’évolution de ce contexte qu’il est question.

Dans tous les cas, tu vas avoir des projets sur lesquels tu peux te permettre d’expérimenter des nouvelles choses, et d’autres non. Et dans le cas de ces premiers, ne jamais sauter sur l’occasion pour te faire une réelle opinion sur des nouvelle technologies et décider de généraliser ou non leur utilisation, est une erreur.

Si tu veux résumer ça par une punchline : tes choix technologiques doivent suivre un juste équilibre entre exploration et exploitation. Ne jamais faire le premier est aussi malsain que ne jamais faire le second.

Si l’on parle de mettre un informaticien sur un environnement technique qu’il ne connaît absolument pas parce qu’il faut combler des trous (c’est du moins ce que j’ai compris à la fois de Tchaïkovski et de plusieurs personnes qui me faisaient des retours d’expérience type « j’ai été vendu expert Scala alors que j’avais jamais touché à une seule ligne de Scala avant »), c’est peut-être un processus normal d’un point de vue économique (trouver un développeur Scala, c’est peut-être très cher), mais sain, je m’interroge.

Et permets-moi sérieusement de douter du fait que c’est « pas plus courant là-bas » qu’ailleurs.

Je connais très, très peu de sociétés qui ont l’intelligence de te dire « t’as fait jamais de Go ? C’est pas grave, t’as déjà fait du Python et du C, tu vas te sentir comme chez toi ».

Les sociétés demandent bêtement X années d’expérience sur tel langage, notamment lorsqu’il s’agit de clients finaux. On se souviendra de ce mauvais buzz.

Alors, oui, je mets le spotlight gratuitement sur les ESN qui, pour la plupart, cherchent davantage à vendre des consultants en costume vide qu’à vendre de la qualité.

J’ai même certains de nos échanges privés où Cap Gemini s’était pris de vives critiques à ce propos (parce qu’elle a développé une appli qui a fait un gros flop et qui a coûté horriblement cher à l’État).

Alors certes ça aurait pu être une autre boîte d’informatique bien rodée, mais mon hypothèse (et je dis bien hypothèse, cette fois) est la suivante : ce n’est pas en envoyant des développeurs faussement expérimentés en mode chair à canon sur des projets parfois compliqués que tu peux espérer aboutir à des résultats satisfaisants.

Et s’il y a bien une pratique où ce genre de stratégie est répandue, c’est en ESN.

Bon, j’arrête ici. Comme souvent, tu changes le sujet de base uniquement pour parler des ESN, et ce faisant tu réponds à autre chose que le problème dont il est question ici en réduisant (volontairement ou non) le scope à ce dont tu veux parler. Et inévitablement, tu viens de répondre à autre chose que ce que j’ai dit.

Pour dire que quelque chose est "surtout" répandu dans les ESN, il convient de regarder non seulement ce qui se passe dans les ESN, mais aussi partout ailleurs, sans quoi tu ne peux pas comparer, et donc pas dire que ça se passe "surtout" à un endroit.

Je crois que dans la remarque de Ge0, il est surtout question des ESN qui abandonnent des techno non mourantes au profit des technos plus jeunes et fraîches pour des raison non pas techniques mais marketing auprès des clients qui veulent du shiny.

En bref, le seul moyen pour une boîte de continuer à vivre et de rester concurrentiel, c’est d’évoluer avec les technos de son temps, et le seul moyen pour les ingénieurs de maîtriser ces technos c’est de travailler sur de vrais projets avec. C’est un processus normal et sain.

Ça dépend de ce que tu entends par là. S’il suffit de rester sur les dernières version de Python et de faire évoluer le code incrémentalement pour tirer profit des apports des versions successives, alors je n’ai aucun problème.
Par contre, si tu me demandes de mettre à la poubelle ma base de code Python en v3.8, qui marche depuis la v3.0, qui a toujours marché, je ne comprends pas l’intérêt, ni même comment mon entreprise resterait plus concurrentielle. D’expérience (édition de logiciels B2B), les clients ont besoin de travailler avec des outils stables et n’apprécient pas d’être les cobayes de la R&D victimes des nouvelles lubies des ingénieurs. Ils sont donc en général ravis d’apprendre que l’entreprise avec qui elle collabore a une politique technique de stabilité. Ce qui ne disqualifie pas l’évolution technique pour autant, mais qui disqualifie bien la révolution technique, source d’incertitude et de stress pour tout le monde, y compris nos très chers clients.

J’ai l’impression que ton sentiment s’explique surtout en R&D d’une entreprise : c’est surtout la R&D qui reste concurrentielle ce faisant, mais pas nécessairement ce que vend l’entreprise.

Certaines entreprises sont sur des marchés qui ne demandent pas un tel investissement R&D. Je pense notamment aux logiciels qualifiés de skin over a database qui sont faits pour améliorer le travail quotidien d’un métier très spécifique. Souvent c’est une app Web classique qui n’a rien de très sophistiqué, mais qui s’avère d’une efficacité redoutable pour les clients qui l’achètent à prix d’or (et à raison). On reste donc très compétitif et concurrentiel commercialement (non pas techniquement).

Une boîte d’info qui n’acquiert pas des nouvelles compétences est une boîte en mauvaise santé. Certaines le gèrent en allouant un gros budget à la formation des ingénieurs, mais une regle tacite que l’on peut dériver de l’expérience, c’est que ces formations ne servent qu’à bootstrapper l’apprentissage.

J’aurais tendance à être d’accord, mais pour des raisons culturelles plutôt que directement utilitaristes. Une entreprise avec des collaborateurs prompts à progresser, c’est très positif car c’est gage d’une certaine diligence et du goût pour bon travail. Même si les ingénieurs se forment à une techno qui n’est pas utilisée (et ne le sera jamais) dans la boîte, l’ouverture d’esprit que ça apporte ne peut qu’être bénéfique à long terme.

Mais attention, tout le monde n’aime pas ça, moi le premier. Je suis celui qui est toujours allé à reculons aux Dev training de la boîte (obligatoire car sur heures de bureau) en radotant : « encore un nouveau gadget à apprendre sans que ce soit justifié, ça m’emmerde et j’ai l’impression de perdre mon temps ».

Alors du coup :

• J’avais oublié de rajouter le suffixe "Bundle" après le nom de ma classe de bundle Symfony 4

• J’avais oublié de rajouter l’import de mon fichier de routing dans le répertoire routes de la racine

• Pb de configuration du container Docker pour un autre bug qui m’empêchait de vérifier la résolution du vrai bug

Tous ces points ont été résolus par un collègue, la honte. Cela dit ça faisait 1 an que je n’avais pas touché à Symfony. Pour le deuxième point je ne me souviens même pas d’avoir appris ça dans la doc.

Hier, pareil, ce même collègue m’avait appris un truc (enfin plutôt rappelé) sur Symfony 4. M’enfin je lui ai dit que ça faisait longtemps que je n’avais pas pratiqué donc ça doit minimiser un peu la perte de réput' auprès de lui.

Finalement mon bouton s’affiche et la route (après avoir vidé le cache) fonctionne.

Sincèrement, ne n’inquiètes ni pour ce qui t’es arrivé, ni pour ta réputation auprès des collègues. Perdre du temps sur des problème du type que tu décris, c’est normal, encore plus si tu n’as pas touché au framework depuis un an !

Et le corollaire, c’est que c’est normal d’aider ses collègues et de les débloquer sur des détails qu’ils ne savent pas, qu’ils ont oublié ou tout simplement qu’ils n’ont pas vu parce qu’ils ont la tête dans le guidon (pour ce dernier point, une peluche peut aider).

Un collègue qui vient me poser des questions parce qu’il ne comprends pas ou parce qu’il reste bloqué après avoir cherché, c’est bien.

Ce qui est mal, c’est le collègue qui ne pose jamais aucune question et qui monte des « solutions » alambiquées et à l’inverse des bonnes pratiques pour pallier sa mauvaise connaissance du framework et/ou du langage. Parce que dans ce cas, le code produit est fragile, incompréhensible et impossible à maintenir. Et sur la durée, on perds infiniment plus de temps qu’à répondre a collègue qui pose des questions.

ça marche bein merci bien !

Oui, j’aime bien taquiner mon lama.