Les dév qui essayent de merger du code avec des TODO dans main, comment je vous regarde bizarre. Qui va le faire ? Quand ? Pour quelle raison ?
- Hey, t'as créé le ticket pour le bug dont tu me parlais hier ?
- Non pas la peine, j'ai allumé un cierge et j'ai mis un TODO dans le code.
- Nickel, merci.
@orange_lux c'est moi le linter. Comme ça je les shame en passant.
@orange_lux nan mais sinon en soi les TODO pourquoi pas, mais avec un numéro de ticket quoi.
Et le "qui" devant s’en occuper c’est moi aussi bien sûr. Le "pourquoi" étant tout simplement que je ne veux pas garder des TODO dans mon beau code que j’aime très fort.
Je passe régulièrement grepper les TODO/FIXME dans ma base de code, pour les corriger le plus tôt possible. Je fais partie de cette espèce de développeur très étrange pour qui le code temporaire est vraiment temporaire.
Dans les exceptions notables, il y a un truc dont j'ai vu que ce sera possible en GTK4 mais a priori pas encore en GTK3, donc je me suis mis un mot pour y penser quand je migrerai.
- replies
- 0
- announces
- 0
- likes
- 0
@vv221
tu es en train de nous expliquer que tu n'as pas de chef de projet, ou alors que ton chef de projet n'a pas de client qui réclame ses nouvelles fonctionnalités pour hier ? Quelle chance tu as !
Quand je me fais employer/exploiter, je considère que les délais de livraison ça ne me concerne pas. C’est le boulot du chef de projet de se débrouiller pour que le client soit content avec la date à laquelle ce qu’il a demandé sera effectivement terminé, contrairement à moi il est payé pour ça.
Les histoires de "deadline", je ne les écoute même pas. Elles ont été décidées entre un client qui n’a aucune idée de ce que ça implique, et un chef de projet qui ne comprend pas ce que ça veut dire.
CC: @TofuTheSquirrel@piaille.fr
@vv221 il faut quand même avoir la capacité mentale pour résister aux demandes incessantes du chef de projet. Pendant longtemps j'ai pas eu ça 🙁
J'ai fini par refuser de donner des estimations pour les tâches, mais pas mes collègues, et donc on a continué à avoir des estimations qui des fois étaient correctes et des fois pas.
il faut quand même avoir la capacité mentale pour résister aux demandes incessantes du chef de projet. Pendant longtemps j'ai pas eu ça 🙁C’est un talent auquel on n’est jamais formé, mais c’est essentiel à acquérir pour la survie sur le long terme ;)
CC: @TofuTheSquirrel@piaille.fr
@matthieu @vv221 justement les deadlines, parlons-en parce qu'il y a un rapport. Les types qui font la moitié du taff, laissent des TODO partout et disent au product manager que c'est fini, ils nous aident pas exactement à assainir le fonctionnement des projets de dév.
Après chacun fait ce qu'il veut sur son projet perso, ou sur sa branche, mais par pitié un peu de sérieux sur les trucs qui partent en prod.
Les types qui font la moitié du taff, laissent des TODO partout et disent au product manager que c'est fini, ils nous aident pas exactement à assainir le fonctionnement des projets de dév.C’est pour ça que je ne suis pas comme eux, et que je dis simplement au chef de projet que c’est pas fini. Et que s’il veut que ce soit fini, il va falloir qu’il choisisse quelle(s) fonctionnalité(s) ne sera finalement pas livrée.
CC: @matthieu@weber.fi.eu.org
CC: @matthieu@weber.fi.eu.org @TofuTheSquirrel@piaille.fr
@TofuTheSquirrel
le truc qui m'est arrivé à répétition, c'est de fournir une rustine pour corriger rapidement un bug en prod (parce que le client veut—avec raison—que ça remarche le plus vite possible), de se mettre d'accord avec le(s) chef(s) de projet de prendre plus tard le temps de corriger la cause du bug, et de ne jamais se voir allouer le temps de corriger ladite cause parce qu'il y a toujours qqch de plus urgent à faire 🙁
Si ça ne leur convient pas, qu’ils embauchent quelqu’un d’autre. Je suis là pour écrire du code de qualité dont on peut tous être fiers.
CC: @TofuTheSquirrel@piaille.fr
@TofuTheSquirrel
j'ai l'impression qui ce qui cause une confusion c'est la nuance entre « ça marche » et « c'est fini ». Le client veut que ça marche, il s'en fout que ce soit fini. Sauf que si c'est pas fini, ça marche seulement à 99% mais ça fait illusion jusqu'à ce qu'un bug soit déclenché.
En fait, il faudrait forcer les chefs de projet pressés de corriger eux-mêmes les bugs de prod. Ça leur apprendra l'importance du « c'est fini » par rapport à « ça marche ».
En fait, il faudrait forcer les chefs de projet pressés de corriger eux-mêmes les bugs de prod.On a fait ça dans une de mes boîtes, avec un chef de projet de bonne volonté qui souhaitait réellement apprendre ce genre de chose pour nous décharger de certaines tâches. Zéro regret.
Probablement le meilleur chef de projet que j’ai eu de ma carrière (Jérémy Sollier, si tu te reconnais, c’était un plaisir de bosser avec toi).
CC: @TofuTheSquirrel@piaille.fr
Genre tu peut te retrouver remplacé par le chef quand tu fais de la merde.
Ils n’ont jamais travaillé de leur vie mais se permettent de juger le nôtre, de travail. Avec comme résultat que les équipes fonctionneraient en fait beaucoup mieux sans eux.
CC: @matthieu@weber.fi.eu.org @TofuTheSquirrel@piaille.fr
CC: @lanodan@queer.hacktivis.me @matthieu@weber.fi.eu.org @TofuTheSquirrel@piaille.fr
@lanodan
les chefs de projet gèrent le projet et sont censés faire l'interface (et le bouclier) entre client et développeurs, pas donner des ordres. C'est pas les mêmes compétences (et je suis bien content de ne pas avoir besoin de causer au client).
Forcer le chef de proj à coder, c'est seulement pour le punir de m'avoir forcé à laisser trainer un bug 🙂
Je crois qu'aucun de mes chefs de projet ne savait coder (et moi je ne sais pas gérer les projets non plus).
Et si ça peut te rassurer sur tes compétences, eux non plus ne savent pas gérer de projets, on peut le constater au quotidien ;)
CC: @lanodan@queer.hacktivis.me