Tes arguments sont plutôt valable, mais attention à ce qu'on ne les retourne pas contre toi :
— Il peut y avoir des erreurs ou des oublis dûs à un bug dans le script, qui si ils sont rares (cas particulier pas prévu) passeront inaperçus aussi (alors que si c'est fait par un cerveau humain, il y a des chances que l'anomalie soit prise en compte quand elle est rencontrée) ;
— pressé par le temps sous la pression de ta hiérarchie (il faut aller aussi vite que si c'était fait à la main), tu cours plus de risque que ce type de problème arrive ;
— rien ne dit que tu ne devras pas tout refaire si tu fais un script jetable et que les données de départ changent ;
— au lieu de mouler, tu ferais mieux de prendre de l'avance sur telle ou telle tâche qui traîne depuis X temps (il y a toujours une tâche en retard, en cherchant bien).
Du coup la question qu'il faut se poser est différente. Si il s'agit d'une tâche critique, dans laquelle une erreur ou un oubli poserait un réel problème qu'il ne suffirait pas de régler une fois qu'on s'en est aperçu (ex : on risque de perdre un prospect / de l'argent / la confiance d'un client), alors c'est qu'il faut procéder différemment.
Dans ce cas, Il faut prendre le temps d'analyser la tâche en amont pour éliminer le plus possible les risques de bugs, prendre le temps de l'implémenter correctement, et de tester le résultat de manière approfondie.
Du coup le vrai problème devient d'identifier une telle tâche, et de prévoir alors l'investissement (au moins en temps) nécessaire. Autrement dit de gestion du risque. Ah tiens, justement, c'est le boulot de ton chef (ou éventuellement le tien, mais dans ces cas là tu as rarement à te justifier de la manière de procéder)... Et prendre en compte l'avis d'un technicien au préalable si besoin est au lancement de la tâche, tout en revoyant le budget temps toujours si il le faut, c'est son boulot aussi. Donc en fait ce qu'il faut c'est pas se justifier, c'est savoir quand on a une chance de convaincre son chef pour avoir le temps de le faire proprement...
C'est marrant j'ai l'impression qu'on s'éloigne de la problématique de geek, là. Ou alors on la déplace au niveau au dessus, tétracapillosection, tout ça... ;-)
[^] # Re: ta definition
Posté par nodens . En réponse au journal Telling a geek. Évalué à 2.
— Il peut y avoir des erreurs ou des oublis dûs à un bug dans le script, qui si ils sont rares (cas particulier pas prévu) passeront inaperçus aussi (alors que si c'est fait par un cerveau humain, il y a des chances que l'anomalie soit prise en compte quand elle est rencontrée) ;
— pressé par le temps sous la pression de ta hiérarchie (il faut aller aussi vite que si c'était fait à la main), tu cours plus de risque que ce type de problème arrive ;
— rien ne dit que tu ne devras pas tout refaire si tu fais un script jetable et que les données de départ changent ;
— au lieu de mouler, tu ferais mieux de prendre de l'avance sur telle ou telle tâche qui traîne depuis X temps (il y a toujours une tâche en retard, en cherchant bien).
Du coup la question qu'il faut se poser est différente. Si il s'agit d'une tâche critique, dans laquelle une erreur ou un oubli poserait un réel problème qu'il ne suffirait pas de régler une fois qu'on s'en est aperçu (ex : on risque de perdre un prospect / de l'argent / la confiance d'un client), alors c'est qu'il faut procéder différemment.
Dans ce cas, Il faut prendre le temps d'analyser la tâche en amont pour éliminer le plus possible les risques de bugs, prendre le temps de l'implémenter correctement, et de tester le résultat de manière approfondie.
Du coup le vrai problème devient d'identifier une telle tâche, et de prévoir alors l'investissement (au moins en temps) nécessaire. Autrement dit de gestion du risque. Ah tiens, justement, c'est le boulot de ton chef (ou éventuellement le tien, mais dans ces cas là tu as rarement à te justifier de la manière de procéder)... Et prendre en compte l'avis d'un technicien au préalable si besoin est au lancement de la tâche, tout en revoyant le budget temps toujours si il le faut, c'est son boulot aussi. Donc en fait ce qu'il faut c'est pas se justifier, c'est savoir quand on a une chance de convaincre son chef pour avoir le temps de le faire proprement...
C'est marrant j'ai l'impression qu'on s'éloigne de la problématique de geek, là. Ou alors on la déplace au niveau au dessus, tétracapillosection, tout ça... ;-)