IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Humour Informatique Discussion :

Trolldi : comment survivre en entreprise tout en étant un développeur médiocre ?

  1. #21
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2003
    Messages
    310
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 310
    Points : 745
    Points
    745
    Billets dans le blog
    1
    Par défaut
    D'autres techniques de survie classiques

    1/ Noyez les gens dans une apparente complexité. Utilisez un vocabulaire technique et des concepts abstraits face aux clients, chefs de projets.

    2/ Recréer la roue pour un quelconque motif d'optimisation (qui devra paraître vital pour vous). Refusez toute forme de template ou de librairies, ils ne sont pas adaptés.

    3/ Investissez vous à fond dans des sujets annexes qui ne requièrent pas le jugement d'un client, par exemple Git, la configuration de l'edi. Créez des architectures techniques et des nomenclatures complexes sur ces domaines. Restez éloignés des sources de jugement : trouvez la niche où vous serez seul.

    4/ Critiquez le travail des précédants développeurs, c'est à cause de leur programme pourri si vous n'y arrivez pas. La seule bonne façon de réfléchir est la votre.

    5/ Critiquez l'imprécision de la demande du client : c'est le client qui ne vous a pas dit que la sécurité, les performances et la gestion de la concurence étaient importantes, c'est de sa faute. Vous n'êtes qu'un simple exécutant.

    6/ Critiquez le mauvais usage des utilisateurs : ils font n'importe quoi, c'est normal que votre programme soit planté. Les gens auraient dû suivre l'indication de la page 42 du manuel ou ce que vous aviez pensé lors du développement.

    7/ Critiquez le temps qu'on vous a alloué. On vous a demandé de développez facebook en 3 jours, c'est normal que vous ayez pondu une daube inmaintenable, sans doc et qui fonctionne à moitié ; ce n'était pas votre rôle d'expert de dire non ou de definir une cible cohérente avec ce chiffrage.

    (ils survivent comme ils peuvent les développeurs médiocres)

  2. #22
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    Mars 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : Mars 2007
    Messages : 592
    Points : 1 679
    Points
    1 679
    Par défaut Humilité
    Citation Envoyé par anykeyh Voir le message
    Ok, un développeur médiocre.
    +1

    Ou plutôt un développeur humble.
    je pense que derrière sa terminologie, il faut comprendre qu'un bon développeur humble, prêt à s'informer, se remettre en cause, sera en fait meilleur qu'un présumé cador. Il ne va pas réinventer la roue, ni bloquer les idées/initiatives des collègues. Il fera plutôt un code plus simple à comprendre et un autre développeur pourra plus facilement reprendre ses projets.

  3. #23
    Membre éclairé
    Homme Profil pro
    Développeur C++
    Inscrit en
    Octobre 2008
    Messages
    242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur C++

    Informations forums :
    Inscription : Octobre 2008
    Messages : 242
    Points : 705
    Points
    705
    Par défaut
    Citation Envoyé par defZero Voir le message
    @Markand -1

    Tes collègues dont tu te plein qu'il code en "C with Class", ont peut être une bonne raison de le faire.
    Au hasard version de lib, compilateur, name mangling différent ou ABI/API incompatible avec un "Modern C++" (très bon livre au passage).
    Et puis c'est juste puéril et hors propos de juger du niveau d'un développeur sur le langage ou la version de celui-ci qu'il utilise.
    @defZero -1 (vu qu'on peut pas discuter sans attribuer des points en 2019).

    J'adore le type qui juge une équipe de développement sans même connaitre ce qu'on fait.

    Donc pour ton information,

    • Oui nous avons les outils pour faire du C++ moderne
    • Oui certains font l'effort ici de se remettre en cause et n'hésitent pas à venir me voir pour me demander des conseils
    • Non certains ne font pas l'effort et continuent de rester sur leur acquis post école (certains collègues sont ici depuis leur sortie d'école il y a plus de 25 ans).


    Linux est codé en "C with Class", maintenant je n'irais jamais dire que M. Torvalds ou M. Kroah-Hartman sont des développeurs médiocres.
    Non, Linux est codé en C tout court.

    Il va se former au besoin et/ou sur le tas, pour quelques modèles.
    Effectivement, comme l'a dit mon VDD, tu ne sais pas de quoi tu parles. Je connais un garagiste qui se forme obligatoirement tous les 6 mois via une mise à niveau au sein de Renault.

  4. #24
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    Mars 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : Mars 2007
    Messages : 592
    Points : 1 679
    Points
    1 679
    Par défaut
    Citation Envoyé par JackIsJack Voir le message
    D'autres techniques de survie classiques
    Mouais... Plutôt de quoi se faire flinguer par son patron/ses collègues/son client

    Citation Envoyé par JackIsJack Voir le message
    1/ Noyez les gens dans une apparente complexité. Utilisez un vocabulaire technique et des concepts abstraits face aux clients, chefs de projets.
    Autrement dit, l'informatique est un problème...

    Citation Envoyé par JackIsJack Voir le message
    2/ Recréer la roue pour un quelconque motif d'optimisation (qui devra paraître vital pour vous). Refusez toute forme de template ou de librairies, ils ne sont pas adaptés.
    Des fois ça marche. Mais là encore, ne pas l'exprimer devant le client ou le patron. Faire passer ça sous une couche ou deux de fonctionnalités

    Citation Envoyé par JackIsJack Voir le message
    3/ Investissez vous à fond dans des sujets annexes qui ne requièrent pas le jugement d'un client, par exemple Git, la configuration de l'edi. Créez des architectures techniques et des nomenclatures complexes sur ces domaines. Restez éloignés des sources de jugement : trouvez la niche où vous serez seul.
    Point de vue du client : l'informaticien se fait plaisir et aime les machins compliqués qui ne servent à rien...

    Citation Envoyé par JackIsJack Voir le message
    4/ Critiquez le travail des précédants développeurs, c'est à cause de leur programme pourri si vous n'y arrivez pas. La seule bonne façon de réfléchir est la votre.

    5/ Critiquez l'imprécision de la demande du client : c'est le client qui ne vous a pas dit que la sécurité, les performances et la gestion de la concurence étaient importantes, c'est de sa faute. Vous n'êtes qu'un simple exécutant.

    6/ Critiquez le mauvais usage des utilisateurs : ils font n'importe quoi, c'est normal que votre programme soit planté. Les gens auraient dû suivre l'indication de la page 42 du manuel.

    7/ Critiquez le temps qu'on vous a alloué. On vous a demandé de développez facebook en 3 jours, c'est normal que vous ayez pondu une daube inmaintenable, sans doc et qui fonctionne à moitié ; ce n'était pas votre rôle d'expert de dire non ou de definir une cible cohérente avec ce chiffrage.

    Bon, là, si on cumule les points 4 à 7, c'est du Trump : je n'y suis pour rien, tous les autres sont des nuls, y compris les collègues et le patron.
    Si c'est vrai, il est temps d'aller voir ailleurs.

    Sinon, il vaudrait mieux être positif :
    4/ le code devait être adapté aux nouvelles technologies/plate-formes/demandes des clients... Oui, bon il a fallu tout refaire, mais au moins il y a du boulot à la clé.
    5/ les besoins non fonctionnels (sécurité, perfs, ...) sont plus à définir par les "techniciens" que par le client fonctionnel.
    6/ les utilisateurs ne lisent jamais la doc.
    7/ on fait des versions et on livre d'abord le minimum, puis on ajoute des fonctionnalités au fur et à mesure des nouvelles livraisons. Cf la méthode MoSCoW pour prioriser les besoins : de ceux qui sont indispensables à ceux qui ne sont que des gadgets.
    https://fr.wikipedia.org/wiki/Méthode_MoSCoW


    Pour résumer, un peu d'humilité et beaucoup de diplomatie, et ça se passe mieux

  5. #25
    Membre expérimenté
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mai 2019
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mai 2019
    Messages : 474
    Points : 1 359
    Points
    1 359
    Par défaut
    Citation Envoyé par Cincinnatus Voir le message
    +1

    Ou plutôt un développeur humble.
    je pense que derrière sa terminologie, il faut comprendre qu'un bon développeur humble, prêt à s'informer, se remettre en cause, sera en fait meilleur qu'un présumé cador. Il ne va pas réinventer la roue, ni bloquer les idées/initiatives des collègues. Il fera plutôt un code plus simple à comprendre et un autre développeur pourra plus facilement reprendre ses projets.
    C'est dommage parce-que pour moi ça c'est un bon développeur...

    Plus sérieusement, on à tous déjà vu des génies qu'on arrive même pas à la cheville, mais franchement j'aimerais pas travailler en équipe avec la moitié d'entre eux.

  6. #26
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2003
    Messages
    310
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 310
    Points : 745
    Points
    745
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Cincinnatus Voir le message
    Mouais... Plutôt de quoi se faire flinguer par son patron/ses collègues/son client
    Oui, si ton patron est intelligent !
    Ma liste était ironique
    C'est évidemment une compilation de mauvaises pratiques... qui sont fréquentes.

  7. #27
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    Mars 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : Mars 2007
    Messages : 592
    Points : 1 679
    Points
    1 679
    Par défaut
    Citation Envoyé par JackIsJack Voir le message
    Ma liste était ironique
    Heureusement, et je l'avais bien compris comme ça.

  8. #28
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Trop facile : passer chef de projet.
    Tu rigoles, mais j'ai vu une très mauvaise développeuse faire une très bonne chef de projet. Bon, d'accord, un échantillon de taille 1 n'est pas statistiquement représentatif.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #29
    Membre à l'essai
    Profil pro
    Inscrit en
    Novembre 2007
    Messages
    15
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2007
    Messages : 15
    Points : 22
    Points
    22
    Par défaut
    N'y a t il que moi qui ai vu l'ironie du propos... bien sur que ces pratiques définissent justement ce qui conduise à devenir un excellent développeur. IE quelqu'un qui développe des logiciels pas son égo

  10. #30
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Service Delivery Manager
    Inscrit en
    Janvier 2003
    Messages
    2 851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Service Delivery Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 2 851
    Points : 4 743
    Points
    4 743
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Tu rigoles, mais j'ai vu une très mauvaise développeuse faire une très bonne chef de projet. Bon, d'accord, un échantillon de taille 1 n'est pas statistiquement représentatif.
    Bonjour

    J'ai vu un bon équivalent: se faire passer pour "l'architecte de l'écosystème logiciel de l'entreprise". Et oui, l'un de mes collègues a balancé cela pour se présenter devant notre nième nouveau chef d'équipe. En réalité, il avait bien réalisé quelques logiciels au début de la structure (2 stand alones en Delphi et un site dégueulasse en PHP). Puis, il n'avait plus rien sorti, préférant se focaliser sur... quel nouveau langage je vais faire adopter à mon équipe et se faire passer pour le maître à penser.
    Encore plus fort? J'ai! Vous êtes Data Manager, et bien, prenez le monopole de la connaissance de la base de données utilisée par l'entreprise. Ne partagez rien à vos collègues concernant vos connaissances et jouez la montre en cas de problème! Et point d'orgue, exigez des autres la documentation et la qualité de programmation que vous n'avez jamais fourni!
    C'est ce que j'ai vu de la part d'un autre de mes ex-collègues qui a fini par être mon supérieur hiérarchique nous condamnant au reverse engineering.
    Vous comprendrez pourquoi j'ai pas hésité une minute pour changer de job (en y gagnant au change)

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  11. #31
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Programmeur médiocre, programmeur d'avenir ?
    Bonjour,

    Il n'est pas sûr qu'être un bon programmeur soit un objectif professionnel sain.

    Prenons un exemple.

    Un très bon développeur écrit un code efficient, lisible et bien documenté. Cela signifie qu'il est facile de le remercier (hélas dans tous les sens du terme) puisque la qualité du travail est telle qu'elle ne demande pas beaucoup de maintenance et que des améliorations pourront être faites par un nouveau venu qui s'appuiera sur la lisibilité du code et sa bonne documentation.

    En revanche, un code illisible et mal documenté nécessitera la présence de l'auteur initial, le seul à peu près capable de le faire évoluer.

    Dans ce cas de figure, la persistance de bugs est un plus en terme d'incitations à conserver ce collaborateur précieux (dans le sens où il coûte cher ).

    Bien sûr, cela ne s'improvise pas. Il faut éviter les tests, les projections de montées en charges et travailler avec des outils en fin de vie.

    J'exagère ? Peut être.

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  12. #32
    Membre confirmé Avatar de pierre.E
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Janvier 2016
    Messages
    241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2016
    Messages : 241
    Points : 570
    Points
    570
    Par défaut
    de toute facons avec les ia qui seront capables de compiler du code avec une efficacité redoutable suffit maintenant d'apprendre le python

  13. #33
    Membre averti Avatar de Moez.B
    Homme Profil pro
    Développeur Delphi
    Inscrit en
    Mars 2006
    Messages
    219
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2006
    Messages : 219
    Points : 370
    Points
    370
    Par défaut
    Pour être vraiment un développeur médiocre, il faut :
    - Venir à 9h, partir à 17h
    - Ne pas être curieux
    - L'innovation et les nouvelles technologies, langages, Frameworks et EDI doivent être un sujet tabou.
    - Suivre toujours les directives et les demandes du chef sans contester ni contredire
    - être toujours souriant, ambiance détendu même si les tâches ne sont pas terminées
    - Respecter les deadlines même si le dév est mal foutu et qu'il y a 5000 bricoles au passage : il vaut mieux avoir un dév foireux de fait à 100% au jour j que de le faire à la perfection à 70% au jour j+2
    "L'homme supérieur est celui qui a une bienveillance égale pour tous, et qui est sans égoïsme et sans partialité." [Confucius]
    "Celui qui n'évolue pas disparaît." [Charles Darwin]
    “Without requirements or design, programming is the art of adding bugs to an empty text file.” [Louis Srygley]

  14. #34
    Expert confirmé

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 317
    Points : 4 124
    Points
    4 124
    Par défaut Tout nouveau tout beau
    Bonjour,

    Citation Envoyé par Moez.B Voir le message
    Pour être vraiment un développeur médiocre, il faut :
    - Ne pas être curieux
    Si ne pas être curieux est effectivement une caractéristique du développeur médiocre, sa contraposée n'est guère mieux. Le développeur qui utilise systématiquement les nouveautés (souvent mal comprises et plus limitées que le marketing le laisse penser) parce que c'est moderne et de facto mieux, n'est pas meilleurs car il ne cherche nullement la solution adaptée au problème.

    C'est surprenant mais nous sommes dans un domaine technique qui n'échappe en rien à la mode. Pire, cela ressemble parfois à une croyance en la magie. Par exemple, j'ai vu quelqu'un prêt à croire qu'une vielle application Cobol de 20 ans pouvait renaître en passanr dans une moulinette qui en sortirait un modèle objet lui-même retraité pour sortir du java.

    Depuis le temps que méthodes et outils nous promettent des gains en vitesse et en fiabilité, les projets devraient se faire en un clin d’œil et la solution du "dans le doute reboot" ne pas exister.

    C'est tout (pour l'instant )

    Salutations
    Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. (Samuel Beckett)

  15. #35
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    Octobre 2017
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Octobre 2017
    Messages : 95
    Points : 80
    Points
    80
    Par défaut
    Étant étudiant, ça motive.

  16. #36
    Membre actif
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2019
    Messages
    144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : Novembre 2019
    Messages : 144
    Points : 285
    Points
    285
    Par défaut Ma soeur aînée s"est retrouvée dans ce cas,
    début des années 70, elle passe un diplôme d'électronique et se retrouve dans une boîte d'informatique je crois Delta Electronic, à l'époque les informaticiens courraient pas les rues, on formait sue le tas, seule fille de la boîte, hyper gentille, ils l'ont protégée, mais jamais elle a écrit la moindre ligne de code des quelques années heureuses à Paris, rendu quelques vagues services c'est tout.

  17. #37
    Membre régulier
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 124
    Points : 86
    Points
    86
    Par défaut
    Presque tout dans cet article est pour moi la description d'un bon développeur. Mais certains suivent ces conseils les yeux fermés.
    Ce sont de bon conseils mais les appliquer strictement sans nuance fera de vous un développeur aussi médiocre que celui qui ne les applique pas.

    Mais dans la plupart des entreprises, un développeur sera considéré comme bon par le responsable du service, si il est en mesure d'expédier rapidement son travail.
    C'est a dire que ce développeur saura :
    - produire rapidement un code qui impactera largement le temps de tous ceux qui suivront,
    - faire le minimum acceptable pour que ceux qui utilisent son développement soient en mesure de combler les manques, les approximations, les "ca je sais pas, tant pi, il se débrouillera... ", la mauvaise ergonomie, les bugs, ...
    - refiler son travail à son voisin,
    - produire des bugs qui ne seront pas assez visibles pour qu'on le pointe du doigt (de toute façon c'est pas lui qui est en charge de leurs corrections, ils n'interviendront que dans quelques mois).

    Le développeur qui possède "ces qualités", apparaîtra dans les chiffres comme efficace parce que ceux-ci ne prennent en compte qu'une petite partie de la chaîne de production et à court terme.
    Alors qu'en réalité son travail coûte cher, ajoute une charge de travail à ses collègues et dégrade le résultat attendu.

    Mais, si tu es ce développeur et que tu souhaites monter dans la hiérarchie de l'entreprise, sache que suivre ces principes marchera à coup sûr, que tu deviendras manager, que tu gagneras plus d'argent qu'un développeur qui fait un travail cohérent.
    Oui, le responsable qui te choisira est ton digne prédécesseur. Il te reconnaîtra comme lui pour être un bon : efficace et pragmatique (il en est persuadé car il fait partit des élus et toutes "ces qualités" prouvent qu'il est clairement plus intelligent).
    Ce développeur pourra donc prendre la suite en devenant a son tour le responsable, et continuer ainsi cette délicieuse "boucle vertueuse".

    L'autre possibilité et que ce développeur sait tout ca mais comme c'est un enf...é, il s'en fou, il ch.. sur son prochain.

  18. #38
    Membre actif
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2019
    Messages
    144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : Novembre 2019
    Messages : 144
    Points : 285
    Points
    285
    Par défaut La première règle d'un 'bon' programme est qu'il doit fonctionner.
    Citation Envoyé par Galet Voir le message
    Bonjour à tous,
    Tout est une question de référence !
    Nous avons tous un processeur et une capacité mémoire différente, il faut bien faire avec...ou sans.
    On a tous croisé des développeurs qui font mieux en moins de temps...pour qui nous sommes surement des Médiocres. Et d'autres, plus médiocres encore... voir franchement mauvais.

    L'important est d'essayer de mesurer ses limites et d'essayer de les dépasser...un peu !

    Il manque une règle qui m'a déjà sauvée (et quelquefois desservie) : Le mieux est l'ennemi du bien !
    La première règle d'un 'bon' programme est qu'il doit fonctionner.

    belle journée...
    Dans toute création, invention, modification, etc, ce principe est le bon, tant pis pour les râleurs épris d'orthodoxie.

  19. #39
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par DavidleVrai Voir le message
    (.../...)Le développeur qui possède "ces qualités", apparaîtra dans les chiffres comme efficace parce que ceux-ci ne prennent en compte qu'une petite partie de la chaîne de production et à court terme.
    Alors qu'en réalité son travail coûte cher, ajoute une charge de travail à ses collègues et dégrade le résultat attendu. (.../...)
    Dans ma boite, c'est presque pareil. Le grand chef en Australie a demandé des chiffres : combien chacun de nous quatre a développé de tests automatiques?

    Madame A a passé beaucoup de temps à aider l'implémentation, et elle n'a pas beaucoup produit. Elle va se faire plomber, alors qu'elle a été très utile à la boite.

    Madame S a passé la moitié de l'année à préparer son moteur de test pour les tests comptables. Depuis elle pisse de grande quantités de tests, tous sur la même architecture. Elle va se faire féliciter, ce qui est normal. elle a bien préparé son coup, et en ramasse les dividendes en cette fin d'année.

    Moi, j'ai passé mon temps sur des tests très compliqués...et finalement, tous nos clients ont laissé tombé cette option. Donc je craignais un nombre très faible qui allait me plomber. Mais en fait, non. Parceque j'ai passé deux heures en début d'année à transférer des scripts de la version précédente, et ça multiplie par 10 mon nombre apparent de scripts réalisés.

    Monsieur M, lui, a géré des problèmes techniques en tout genre. Il n'a pas fait un seul script de l'année. Mais il en a transféré encore plus que moi de l'année précédente. Ça a du lui prendre 4 heures. Il va avoir une prime grâce à ces 4 heures, pas pour son énorme boulot de toute l'année sur les problématiques techniques qu'il a résolu avec brio.


    Cherchez l'erreur..... Personne n'a chômé, tout le monde a mérité, on est deux à échapper à la guillotine grâce à une astuce comptable, et une va se faire plomber parce-qu’elle n'a pas participé à la migration du début d'année. Et même la quatrième, au final, elle est jugée seulement sur son second semestre. Ça suffit à son bonheur, mais c'est un peu injuste aussi, elle se fait féliciter pour la partie facile de son boulot.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  20. #40
    Membre à l'essai
    Homme Profil pro
    Logistitien
    Inscrit en
    Octobre 2013
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Logistitien
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Octobre 2013
    Messages : 30
    Points : 24
    Points
    24
    Par défaut Projeter Vous
    Un pro se pause pas de question un code c'est tous son ensembles à connaître, par la pratique cela vas de soi. C'est donc pour cela que je lui répondrais un médiocre n'existe pas en développement . C'est toute la définition de ce termes, et ces bien ce qui force beaucoup d'entre nous a prendre beaucoup de recul, notamment du fait de ces update bien trop frequent alors oui médiocre . Mais restons sûr de nous dépasser le maître n'est plus d'usage. Trop lol sont aujourd'hui les patefolle pour pas dire plateforme de source, et de source sur aucun language est aussi mediocre. Prenons courage et combattons ensemble ce besoin detoujours en faire car en trop encore aujourd'huiet toujours incompris de toute individualisme. À bientôt.

Discussions similaires

  1. Trolldi : comment avoir du succès en tant que développeur Web ?
    Par Michael Guilloux dans le forum Humour Informatique
    Réponses: 9
    Dernier message: 25/05/2018, 04h29
  2. Comment faire un tableau tout simple dans un état
    Par robertetgorgette dans le forum Access
    Réponses: 1
    Dernier message: 25/07/2006, 16h20
  3. comment utilisé des classes toute prêtes
    Par Burinho dans le forum Langage
    Réponses: 3
    Dernier message: 23/01/2006, 23h18
  4. Réponses: 11
    Dernier message: 14/12/2005, 14h45
  5. Réponses: 2
    Dernier message: 09/07/2003, 15h10

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