Affichage des résultats du sondage: Votre avis

Votants
40. Vous ne pouvez pas participer à ce sondage.
  • En voulant coder vite, on perd toujours plus de temps à corriger ses erreurs

    26 65,00%
  • Il faut d'abord convaincre le management

    9 22,50%
  • La norme c'est de livrer rapidement, des patchs suivront pour corriger les bogues

    12 30,00%
  • Les développeurs ne sont jamais assez rapides pour le management

    15 37,50%
  • Aller lentement sera interprété comme de la paresse ou de la sous-performance

    21 52,50%
  • Un développeur rapide est vu comme un développeur motivé

    15 37,50%
  • Autre (à préciser)

    1 2,50%
  • Pas d'avis

    0 0%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 369
    Points : 37 918
    Points
    37 918
    Billets dans le blog
    2

    Par défaut Trolldi : pourquoi coder lentement c'est coder plus vite, mais aucun développeur ne veut le faire

    Trolldi : pourquoi coder lentement c'est coder plus vite
    mais aucun développeur ne peut le faire dans la réalité

    En tant que développeur, vous avez certainement déjà senti la nécessité de coder rapidement. Le plus souvent, cela se produit lorsque les délais sont très serrés et que vous sentez que vous ne serez pas en mesure de fournir un livrable attendu à temps. Mais parfois, ce comportement peut s’avérer très coûteux.

    C’est le cas par exemple si la pression d’aller vite vous amène à sous-estimer le travail à faire ou à mal l’évaluer, ne pas respecter la conception, les règles de codage, etc. Une complexité cachée découverte plus tard vous conduit alors à revenir en arrière. Ainsi, la volonté d'aller plus vite vous aura tout simplement fait prendre du retard.

    À l'inverse, vous arrivez à terminer le projet dans les délais, mais avec une forte dette technique. Il faut en effet rappeler que dans un projet, la qualité augmente la charge de travail, ce qui peut avoir un impact sur le délai immédiat. Ainsi, lors de la survenue imminente d'une nouvelle version d'un logiciel par exemple, respecter la conception idéale peut mettre en péril la livraison d'une nouvelle version du logiciel. À ce moment précis, ne pas respecter la conception idéale peut permettre d'atteindre l'objectif prioritaire à court terme (sortir une nouvelle version), mais vous contractez une dette technique que vous allez rembourser tout au long de la vie du produit sous forme de temps de développement de plus en plus long et de bogues de plus en plus fréquents.

    La solution serait donc d’aller lentement mais sûrement ? Une chose est sure, cela va permettre d’éviter les pièges ou limiter les erreurs. Dans un billet de blog sur Programmerfu.com, Garrett Lancaster, créateur d'une application SaaS, essaie d'ailleurs d'expliquer qu'en programmation, « aller lentement, c'est aller plus vite », ce que beaucoup d'entre nous ne mettront peut-être pas en doute. Il faut donc « ralentir pour être un programmeur meilleur et plus heureux », a-t-il suggéré dans une discussion sur Reddit.

    Il explique que cela ne sera pas seulement bénéfique pour le développeur lui-même, mais aussi pour les autres développeurs qui auront à travailler sur son code, que ça soit pour ajouter de nouvelles fonctionnalités ou pour le maintenir. Il n’est en effet pas nécessaire de rappeler comment cela peut être pénible de travailler sur un code de mauvaise qualité, et en plus écrit par une autre personne. Mais dans la réalité, vu les contraintes extérieures, la suggestion de Garrett Lancaster est-elle applicable ? Cela s'aligne-t-il avec la vision de l’entreprise et du management ? C'est sur ce point que la suggestion de Garrett Lancaster a été débattue.

    Le fait est que le plus souvent, c’est l’entreprise et le management qui créent un environnement sous pression avec des délais très serrés obligeant les équipes de développeurs à essayer d’aller le plus vite possible. Il faut donc avant tout les persuader que cette manière de travailler peut affecter la qualité du code et pourrait nécessiter plus de travail plus tard. Pour un développeur qui essaie d’aller lentement pour éviter de commettre des erreurs graves, comment sera-t-il perçu par son manager ou son entreprise ? Comme quelqu’un de paresseux, sous-performant, non motivé ?

    Et vous ?

    Qu'en pensez-vous ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre du Club
    Inscrit en
    novembre 2003
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : novembre 2003
    Messages : 27
    Points : 53
    Points
    53

    Par défaut

    Informatique: On a le temps de faire mal 3 fois mais on a pas le temps de faire bien 1 fois.

  3. #3
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 100
    Points : 0
    Points
    0

    Par défaut

    Moi qui ai toujours cru que je codais lentement vis-à-vis des perfs des autres...
    Un bon RAD (plein d'affinités et intuitifs) et voilà que les choses changes.

    Durée de vie du RAD estimé a combien d'année sur le marché du travail ?

    (Windev, RAD Studio, ...) C'est bien sa le problème de la demande... Le second n'y est vraiment pas souvent, alors ses ancêtres...

  4. #4
    Membre confirmé Avatar de Cincinnatus
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2007
    Messages
    189
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 189
    Points : 538
    Points
    538

    Par défaut

    Il ne s'agit pas de coder lentement, même si Garrett Lancaster parle de "taper lentement". Il s'agit d'abord de ne pas se précipiter, et comme il l'écrit également, de rassembler un maximum d'informations avant de planifier et se concentrer (sans interruptions extérieures).
    En fait, réfléchir avant d'agir.
    Effectivement, c'est parfois possible, mais pas dans tous les environnements de travail, malheureusement.

    C'est cependant du bon sens, que je rapprocherais de DDD : Domain-Driven Design : on étudie le problème en large et en travers avant de concevoir et avant de programmer. ça semble un peu contradictoire avec TDD par contre
    .

  5. #5
    Membre régulier
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2017
    Messages : 15
    Points : 101
    Points
    101

    Par défaut

    Je suis globalement d'accord avec le billet, mais je pense qu'il manque une variable essentielle : quel est le surcoût de la qualité ?

    S'il est exagéré (procédures délirantes), alors oui, les développeurs seront tentés de s'en passer pour gagner du temps.
    Si on trouve un juste milieu, alors cela devient dérisoire. Sauf projet microscopique, quand on développe on passe plus de temps à réfléchir à comment coder les choses, comment les agencer, comment les afficher, comprendre le besoin utilisateur précis, qu'à écrire du code (propre ou non). C'est pour cela que la surcouche "qualité" peut devenir négligeable en temps : les normes de codage, l'organisation "intelligente" du code, les tests unitaires, les interfaces, les commentaires, la doc, ... tout cela n'est que du déroulage, lorsqu'on est un minimum rodé, et peut donc se faire rapidement.

  6. #6
    Membre à l'essai
    Profil pro
    Inscrit en
    janvier 2012
    Messages
    5
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2012
    Messages : 5
    Points : 17
    Points
    17

    Par défaut

    D'accord avec Cincinnatus, il ne s'agit pas de coder "lentement" mais de ne pas se precipiter vers la 1e intuition venue et se retrouver dans une voie sans issue.

    Après, il est difficile de trouver un compromis évident entre "se précipiter" et "prévoir tous les risques auxquels on pourrait être confronté", surtout que dans le 2e cas, on peut passer longtemps a ne rien faire et finir par se décourager.

    Personnellement, j'essaie avant tout de modulariser l'application de manière a limiter la complexité unitaire de chaque module. Avec un bon découpage de modules et des contrats clairs entre modules, on peut se permettre de coder "vite fait, bien fait" à l'intérieur des modules car la dette technique restera circonscrite et facilement addressable par la suite

  7. #7
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 100
    Points : 0
    Points
    0

    Par défaut

    C'est un peu la notion de culture générale en matière d'algorithmique, selon les précédents commentaires.
    Pas faux aussi... Utilisation de framework et librairies tierces ou pas étant là encore ce qui peut faire la différence...

  8. #8
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2013
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2013
    Messages : 35
    Points : 105
    Points
    105

    Par défaut

    Les problématique sont différentes selon les outils utilisés. Par exemple, si on fait une faute de frappe et que le projet met 10 minutes à build, alors oui il vaut mieux bien se relire et pas taper sur le clavier comme un décérébré. Perso, en Delphi a peu près n'importe quoi compile en un claquement de doigt. A tel point que je compile parfois juste pour mettre le curseur la ou je m'étais arrêté au milieu d'une ligne

    Pour ce qui est de l'organisation de son temps, j’essaie une "nouvelle" technique.
    Pour ne pas partir à droite à gauche j'ai une feuille de route de mon dev. C'est simplement une liste des choses que je sais à l'avance que je vais devoir faire. Chaque élément de la liste occupe entre 5 minutes et 4 heures.
    Après le but c'est de s'y tenir, dans l'ordre, et sans déborder.

    Ça m'aide à rester concentrer, et à ne rien oublier.

  9. #9
    Rédacteur/Modérateur

    Avatar de Songbird_
    Homme Profil pro
    Bidouilleur
    Inscrit en
    juin 2015
    Messages
    305
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Bidouilleur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2015
    Messages : 305
    Points : 2 436
    Points
    2 436
    Billets dans le blog
    3

    Par défaut



    Pour ne pas partir à droite à gauche j'ai une feuille de route de mon dev. C'est simplement une liste des choses que je sais à l'avance que je vais devoir faire. Chaque élément de la liste occupe entre 5 minutes et 4 heures.
    Après le but c'est de s'y tenir, dans l'ordre, et sans déborder.

    Ça m'aide à rester concentrer, et à ne rien oublier.
    Je fais à peu près la même chose. Soit je laisse ça sur une feuille, quand ce sont des petits projets personnels, soit j'intègre ma feuille de route directement dans mon bug tracker et je lis chaque issue à un ou plusieurs commits lorsque je commence à coder, pour les retrouver facilement par la suite.

    Sinon pour noter les spécificités de son programme, il y a Cucumber qui a l'air d'être vraiment pratique. Je ne l'ai pas encore utilisé donc je ne connais pas ses limites, mais ça me tente bien.
    Avant de poster: FAQ Rust(WIP); FAQ Dart; FAQ Java; FAQ JavaFX.
    Vous souhaiteriez vous introduire au langage Rust ? C'est par ici ou ici !
    Une question à propos du langage ? N'hésitez pas à vous rendre sur le forum !

    N'hésitez pas à contribuer ou nous faire part de vos retours !
    Release Rust FAQ #7


    Ninja Gaiden meets Metal.

  10. #10
    Membre habitué
    Inscrit en
    mai 2006
    Messages
    80
    Détails du profil
    Informations forums :
    Inscription : mai 2006
    Messages : 80
    Points : 198
    Points
    198

    Par défaut

    Massacrer le clavier, copier-coller. Massacrer le clavier, copier-coller. Copier-coller, copier-coller, copier-coller, massacrer le clavier...

    Compiler.

    Merde ça marche pas... 🤣

    Patcher. Compiler. Patcher. Compiler. Publier.


    "Alors, maintenant on va faire une petite modif. Rien, hein! Ça prendra 5 minutes. Il faut juste changer ça, et rajouter ça. Ho, et puis ça, finalement, ce n'est plus utile. C'est bon ? Je reviens dans 5 minutes...." 🤣

  11. #11
    Membre chevronné
    Avatar de CodeurPlusPlus
    Profil pro
    Inscrit en
    septembre 2013
    Messages
    569
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 569
    Points : 1 935
    Points
    1 935

    Par défaut

    Il ne faut coder ni trop vite ni trop lentement, réfléchir suffisamment sans devenir contre-productif, et se rappeler que, quoi que l'on fasse, il y a toujours quelqu'un qui code à la fois plus vite et mieux que soi.

    Voilà, j'ai fait plaisir à tout le monde en énumérant des banalités ?

  12. #12
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 803
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 803
    Points : 5 672
    Points
    5 672
    Billets dans le blog
    2

    Par défaut

    Je suis croyant pratiquant du "rien ne sert de courir, il faut partir à point".

    Je considère que du code doit, in fine, toujours être bien fait. Si urgence il y a, il faut le faire vite en prévoyant d'y revenir nécessairement plus tard, même si on pense l'avoir bien fait du premier coup. Il faut donc chiffrer le travail en partant du principe qu'on prendra le temps de le faire, puis y ajouter les frais supplémentaires pour fournir une version vite fait d'abord. Voilà comment je le conçois : soit c'est bien fait, soit c'est d'abord vite fait puis bien fait.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  13. #13
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 023
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 023
    Points : 4 423
    Points
    4 423

    Par défaut

    Citation Envoyé par clorr Voir le message
    "se précipiter" et "prévoir tous les risques auxquels on pourrait être confronté"
    Moi, je donne un autre son de cloche , ... mais dans un contexte de programmation tout seul (ou peut-être une toute petite équipe) - sans cahier de charges (ou presque rien)

    Si je code lentement, c'est parce que je développe en "eXtrem Programming"

    Je commence par intégrer des fonctionnalités en [ultra] simplifié. Ceci permet 0) de les coder rapidemment 1) d'intégrer d'autres fonctionnalités qui en dépendent 2) de tester cette fonctionnalité
    Et ensuite ces fonctionnalités sont de plus en plus améliorés/ augmentées et refactorisées (*) et donc de plus en plus testées (et aussi de tester les dépendances).
    C'est cela qui prend du temps: de coder en incrémental.

    Et si ton code est bien modularisé, tu modifies à chaque fois que la partie nécessaire.
    Et si tu dois supprimer du code, le temps passé sur les fonctionnalités supprimées dépend de leurs avancements.
    Parce qu'on ne peut pas prévoir tout à l'avance. Donc on code minimaliste et si cela ne plait pas, ne sert à rien: placard ou poubelle.

    Et ceci permet aussi de prendre de petites pauses (1 ou 2 jours par exemple), pour s'arrêter et réfléchir. Et éventuellement coder/ corriger 2-3 petits trucs. (<- tu avances toujours)
    Il y a aussi l'ordre qui est important. On code les fonctionnalités ou on modifie les choses évidentes/ certaines/ prioritaires (<- les petites pauses permettent aussi d'évaluer l'avancement et de réajuster le pseudo-planning)

    * le refactoring 1) prend le plus de temps 2) est nécessaire parce qu'on a toujours des fonctionnalités qui collent au mieux les besoins déjà codés, mais pas plus.
    Son problème, c'est que souvent ton code ne fonctionne plus tant qu'il n'est pas fini (et donc tu n'as plus rien à montrer)

  14. #14
    Candidat au Club
    Homme Profil pro
    Etudiant en informatique
    Inscrit en
    mars 2015
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 20
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Etudiant en informatique

    Informations forums :
    Inscription : mars 2015
    Messages : 2
    Points : 3
    Points
    3

    Par défaut

    Je ne suis pas vraiment d'accord, en faisant des erreurs, on apprend, et en apprenant les fois prochaines on sera beaucoup plus efficace, coder lentement c'est perdre son temps, à moins que ce qu'on est en train de faire / utiliser on ne le refera jamais ..

  15. #15
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 803
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 803
    Points : 5 672
    Points
    5 672
    Billets dans le blog
    2

    Par défaut

    Coder lentement ne veut pas dire ne pas faire d'erreur. D'ailleurs, il ne s'agit pas simplement de coder lentement ou rapidement, qui ne veut rien dire en soit, mais de choisir entre prendre le temps de concevoir complètement avant de coder ou de se lancer dans le code tout de suite en concevant la solution à la volée. Les erreurs sont toujours possibles, dans les deux cas, mais la seconde pratique tant à faire du code qui sera jeté plus tard. Si le projet dure longtemps, les dépendances à ce code jetable s'agrémentant, il finira par devenir à la fois nécessaire à jeter mais impossible à jeter, mettant l'équipe dans l'embarras car il faudra non seulement refaire ce bout là mais aussi tous ceux qui en dépendent, et ainsi de suite.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  16. #16
    Membre expérimenté
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 365
    Points : 1 590
    Points
    1 590

    Par défaut

    Citation Envoyé par foetus Voir le message
    Si je code lentement, c'est parce que je développe en "eXtrem Programming"
    L'eXtreme Programming se base sur les principes suivants :
    • Le développement itératif. C'est ce que tu viens de décrire dans ton message.
    • Le développement piloté par les tests (Test Driven Development) : on écrit les tests unitaires d'abord et on code la fonctionnalité ensuite. A court terme, c'est plus long que ne pas écrire de tests unitaires. A long terme, on détecte vite les régressions.
    • Le binômage (pair programming) : deux développeurs par PC ! Il y en a un qui code et l'autre qui surveille les erreurs et propose des alternatives.
    • Les binômes changent régulièrement de façon à ce que tout le monde connaisse un peu tout le programme. Ainsi, lors d'une itération, si la plupart des demandes se concentrent sur la même portion du programme, au lieu que seul le spécialiste de cette portion travaille dessus, une plus grosse partie de l'équipe peut intervenir.


    C'est étrange que ton message focalise la lenteur à court terme sur le développement itératif alors que c'est surtout le binômage qui ralentit le plus à court terme. Développes-tu vraiment en eXtrem Programming ?

    Citation Envoyé par Damoy Voir le message
    en faisant des erreurs, on apprend, et en apprenant les fois prochaines on sera beaucoup plus efficace, coder lentement c'est perdre son temps
    Dans le contexte de l'article, l'expression coder lentement est trompeuse car, sémantiquement, elle suggère qu'il s'agit de réaliser les même tâches que coder rapidement, de manière moins rapide et plus soigneuse, alors qu'il s'agit en fait de réaliser plus de tâches.

    Pour ajouter des fonctionnalités à un programme, un développeur qui travaille correctement ne fait pas que coder ce qui sera visible le jour de la livraison, et il ne fait pas que coder tout court. En effet, il faut penser aux tâches suivantes (la liste n'est pas exhaustive) :
    • L'analyse du besoin. Quand le supérieur demande d'ajouter une fonctionnalité qui semble étrange, il faut demander quel est le besoin derrière au lieu de répondre "OK." et de foncer tête baissée dans le code. Parce que peut-être qu'il faudrait coder autre chose voire même qu'il n'y a pas besoin de changer le code.
    • La factorisation du code entre plusieurs applications. Au lieu que chaque équipe de développement réinvente la roue carrée dans son coin pour son projet à elle, il faut discuter entre équipes pour mettre du code en commun. Ainsi, quand on corrige un bogue ou quand on ajoute une fonctionnalité dans le code commun, c'est effectif chez tout le monde.
    • La documentation. Cela permet d'éviter que, quand un développeur quitte la boîte, les connaissances indispensables au bon déroulement du projet disparaissent avec lui.
    • Le traitement des erreurs. Par exemple, au lieu de supposer que tous les fichiers en entrée sont au bon format et laisser le programme crasher lamentablement quand le format est incorrect, il faut construire un message d'erreur avec l'adresse du fichier et en quoi son contenu est incorrect. De même, quand une sauvegarde échoue, il faut afficher un message d'erreur pour avertir qu'elle a échouée au lieu de laisser l'utilisateur croire que tout va bien puis appeler le help desk quelques jours plus tard.
    • Le programme doit aussi écrire un fichier de log qui décrit les actions des utilisateurs et les erreurs détectées. C'est parfois indispensable pour analyser des problèmes quand un utilisateur appelle le help desk.
    • Les tests unitaires. C'est pour détecter plus facilement les régressions.

    Quand un développeur fait tout ce travail, la hiérarchie peut avoir l'impression qu'il "code lentement" dans le sens où le code est "fini" plus tard. Mais, en réalité, il code plus de choses (par exemple, il traite les erreurs) et il fait aussi du travail qui ne consiste pas à écrire du code (par exemple, il documente).
    Dans certaines boîtes, pour la hiérarchie, un développeur qui "code vite" est en fait un développeur qui ne fait que la moitié du travail et laisse une grosse dette technique. Mais la hiérarchie a l'impression qu'il a fait tout le travail car elle ne voit pas tout le suite les conséquences de cette dette technique.

  17. #17
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 100
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Matthieu Vergne Voir le message
    Je suis croyant pratiquant du "rien ne sert de courir, il faut partir à point".
    Ohhhhhh!!!!

    Et moi, je suis croyant pratiquant du "rien ne sert de courir, tout vient à point qui sait attendre".

    Je te raconte pas les embuches rencontrées...

    Cela étant, les PMI-PME et plus grandes sociétés sont souvent celles qui n'en rencontre pas avant d'avoir vendu les produits aux clients...

  18. #18
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 803
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 803
    Points : 5 672
    Points
    5 672
    Billets dans le blog
    2

    Par défaut

    Je suis aussi un croyant pratiquant du "tout vient à point à qui sait attendre". Le truc, c'est que ça ne dit pas "à qui attend" mais "à qui sait attendre". Il s'agit d'une patience raisonnée, pas d'attendre que les autres fassent le boulot à ta place. Il faut du temps pour que certaines choses bougent, ou que des opportunités se manifestent. Le tout étant de se focaliser sur ce qui augmente tes chances d'obtenir ces opportunités plutôt que d'essayer de forcer la main. Il y a une inertie dans tout, et ça aussi il faut en être conscient et l'exploiter.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  19. #19
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 100
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Matthieu Vergne Voir le message
    Il s'agit d'une patience raisonnée, pas d'attendre que les autres fassent le boulot à ta place.
    Chef de projet et maitre du planning à respecter...
    Le peu que je connais au sujet du génie logiciel (C.N.A.M., cours du cycle probatoire, diplôme d'ingénieur) permet même d'introduire une mesure comme TOEIC pour les niveaux de maitrise d'une langue...

    Bien sûr, encore faut-il pouvoir garder le niveau suffisamment longtemps...

  20. #20
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 100
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Michael Guilloux Voir le message
    Qu'en pensez-vous ?
    Se qui n'est pas un trolldi, c'est justifier le fait de toujours avoir besoin de coder pour un développeur dans une entreprise.
    De justifier d'une place permanente et non remplaçable.

    Après les outils métier de la comptabilité, je vois bien les écoles et universités payer un abonnement mensuel pour leurs structures informatique...
    Sans oublier tous les bulletins d'information (MAJ, UPGRADE, DOWNGRADE) qui vont avec.

Discussions similaires

  1. Pourquoi les développeurs travaillent-ils la nuit ?
    Par Gordon Fowler dans le forum Humour Informatique
    Réponses: 122
    Dernier message: 06/10/2013, 01h30
  2. Réponses: 22
    Dernier message: 29/12/2010, 09h44
  3. Les pirates ont-ils compris avant les autres l'avantage du Cloud?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 9
    Dernier message: 24/11/2010, 14h34
  4. les jeux ont-ils un voir plusieurs points communs ?
    Par Invité dans le forum Modélisation
    Réponses: 2
    Dernier message: 04/11/2010, 15h20
  5. Les sessions ont-ils une taille limite?
    Par wormseric dans le forum Sessions
    Réponses: 1
    Dernier message: 26/03/2008, 10h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo