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

  1. #1
    Chroniqueur Actualités

    Trolldi : comment survivre en entreprise tout en étant un développeur médiocre ?
    Trolldi : comment survivre en entreprise tout en étant un développeur médiocre ?
    Quelques conseils bien pratiques ... ou pas

    Pete Shirley est un développeur médiocre et il le reconnait : « demandez à quiconque a déjà travaillé sur un projet de groupe avec moi et vous verrez ». Il précise que « la compensation principale est que je suis conscient que je suis un développeur médiocre. Je n'essaie pas de faire quelque chose d'extraordinaire ». Gardant à l'esprit qu'il est loin d'être le seul dans son cas, il a tenu à partager à la communauté des développeurs les heuristiques qui lui permettent de rester productif, notant au passage que « ces heuristiques sont bonnes pour tous les développeurs, mais sont essentielles pour ceux d’entre nous qui appartiennent au bas de la pyramide » :
    • Tout d'abord, il propose de suivre le principe KISS ("keep it simple, stupid" ou "keep it stupid simple") qui stipule que la plupart des systèmes fonctionnent mieux s’ils restent simples et non compliqués ; par conséquent, la simplicité doit être un objectif clé de la conception et toute complexité inutile doit être évitée. Pour Shirley, il faut impérativement se poser une question préconisée par le mouvement de la programmation extrême : quelle est la chose la plus simple qui puisse fonctionner ? Une fois que vous l'avez définie, vous devez l'essayer. Si elle ne fonctionne pas, il faut alors passer à la seconde chose la plus simple ;
    • Ensuite vient le principe YAGNI ("You aren't gonna need it" - vous n'en aurez pas besoin) qui stipule qu'un développeur ne doit ajouter aucune fonctionnalité avant que cela soit jugé nécessaire. Pour Shirley, « en ce qui concerne les fonctionnalités et en général, "You Aren't Gonna Need It" »
    • Puis ALAN. Avoid Learning Anything New (littéralement, évitez d'apprendre quelque chose de nouveau). Shirley note que différents langages, environnements et outils vont et viennent, et chacun d'entre eux requiert l'apprentissage d'un nouvel ensemble de faits, de pratiques et d'une mentalité. Et ils vont probablement s'en aller. Aussi, il recommande de n'apprendre quelque chose de nouveau que quand vous y êtes contraint : « en 1990, j'ai appris le C ++. En 2015, j'ai appris le Python. C'est suffisant ».

    • Faites des tableaux votre structure de données par défaut. Demandez-vous toujours « comment un programmeur FORTRAN ferait-il cela ? ». Au cours de votre vie, vous devriez utiliser occasionnellement des arbres, mais considérez-les comme une consommation excessive d'alcool ... une utilisation régulière endommagera votre foie.
    • Ne prétendez jamais que vous comprenez quelque chose quand vous ne la comprenez pas, et il est inutile de bluffer. Tout d’abord, faites une recherche Google, puis demandez aux gens de vous recommander de la lecture et enfin demandez un tutoriel à un collègue. Nous sommes tous ignorants sur presque toutes les choses.
    • Sachez que la plupart des conseils en programmation sont mauvais. Demandez-vous s'il existe des preuves empiriques de la véracité d'un conseil donné.
    • Évitez de vous lier à un autre logiciel que celui auquel vous êtes habitué sauf si vous y êtes forcé. Cela se passe rarement bien empiriquement.
    • Essayez de développer une zone de confort dans certaines zones. Celle de Shirley repose sur un code C ++ géométrique qui appelle des nombres aléatoires. N'essayez pas d'être un expert dans tout ou même la plupart des choses.

    « Enfin, laissez l’ordinateur faire le travail ; Dave Kirk parle de l'élégance de la force brute (je ne sais pas si c'est original avec lui). C'est un cousin de KISS. Le matériel est rapide. Le logiciel est difficile. Profiter du miracle de la création dans le logiciel ; vous créez quelque chose en vous appuyant sur le comportement des octets. Si vous êtes médiocre en développement, mais que vous développez toujours, rappelez-vous que c'est quelque chose que très peu de gens peuvent faire ».

    Source : billet Pete Shirley

    Et vous ?

    Êtes-vous un développeur médiocre ?
    Si oui, comment avez-vous fait pour survivre en entreprise ?
    Sinon, avez-vous déjà côtoyé un développeur médiocre et comment l'avez-vous géré ?
    Que pensez-vous des conseils de Pete Shirley ? Pratiques ou loufoques ?
    Quels sont ceux qui vous ont le plus marqué ?

    Voir aussi :

    Trolldi : 30% des travailleurs remplaceraient leur patron par un robot, un pourcentage qui augmente dans la perspective d'un robot humanoïde amical
    Trolldi : Mozilla nominé parmi les "Internet Villain" par l'ISPA britannique pour son support de DNS-over-HTTPS, aux côtés de l'article 13 et de Trump
    Trolldi : travailler juste une journée par semaine pourrait améliorer votre santé mentale, d'après une étude des chercheurs de l'université Cambridge
    Trolldi : un développeur présente le nouvel élément HTML <clippy>, une satire pour dénoncer l'attitude parfois « arrogante » de certaines entreprises
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert confirmé
    Citation Envoyé par Stéphane le calme Voir le message
    Trolldi : comment survivre en entreprise tout en étant un développeur médiocre ?
    Trop facile : passer chef de projet.

  3. #3
    Membre confirmé
    Puis ALAN. Avoid Learning Anything New (littéralement évitez d'apprendre quelque chose de nouveau). Shirley note que différents langages, environnements et outils vont et viennent, et chacun d'entre eux requiert l'apprentissage d'un nouvel ensemble de faits, de pratiques et d'une mentalité. Et ils vont probablement s'en aller. Aussi, il recommande de n'apprendre quelque chose de nouveau que quand vous y êtes contraint : « en 1990, j'ai appris le C ++. En 2015, j'ai appris le Python. C'est suffisant ».
    J'espère que c'est une blague. C'est exactement le fait de rester sur des acquis préhistoriques qu'on évolue plus. Je suis entouré de collègues qui ne connaissent rien du C++ moderne et continuent d'écrire des horreurs de l'ère C with classes. Au contraire, un bon développeur doit se remettre en cause en permanence et renouveler ses connaissances. Tout comme un garagiste évolue en fonction des nouvelles technologies sur les véhicules.

  4. #4
    Membre éclairé
    Bizarrement y'en à 2-3 qui sont pas de mauvais conseils je trouve, le KISS, remettre la parole en doute, ne pas prétendre savoir ce que l'on ne sais pas...

  5. #5
    Membre averti
    Je me suis toujours considéré comme un développeur médiocre.

    Ma 3eme règle de vie au travail est "Evite de faire des choses que tu n'as pas l'habitude de faire" et boudu que cette règle m'a été sacrément utile au cours de ma carrière.
    On peut ajouter son corollaire : "Si tu sais pas, refile le boulot fais toi aider."

  6. #6
    Membre actif
    A part " Puis ALAN. Avoid Learning Anything New (littéralement évitez d'apprendre quelque chose de nouveau) "

    En fait, si tous les devs appliquaient ces principes, la qualité du code, en générale, serait bien meilleure.

    Notre profession est polluée par des bullshiters ultra rigides qui passent plus de temps à vouloir la perfection que l'application pratique.
    Ces personnes sont des cancers qui pourrissent les vocations en anéantissant les candidats à un poste pour des motifs bidons et font exploser le coût des projets en mettant en danger la solvabilité de leur boite.
    Cocréateur d'un réseau social musical
    Suivez-nous sur https://www.facebook.com/Spolsik/?ref=aymt_homepage_panel

  7. #7
    Membre éclairé
    Trop facile : passer chef de projet.
    ou alors scrum master, c'est dans l'air du temps ;-)

  8. #8
    Membre confirmé
    Êtes-vous un développeur médiocre ?
    A en jugé par les critères donnés et le fait que j'ai tendance à avoir un QI proche de celui de la serpillière (ce qui me permet de lui tenir conversation !), on va dire oui...

    Si oui, comment avez-vous fait pour survivre en entreprise ?
    Suffis d'arriver dans un projet au bon moment et d'être par la suite l'un des seul capable de maintenir ce gros monolith qu'est devenu le projet o/

    avez-vous déjà côtoyé un développeur médiocre et comment l'avez-vous géré ?
    J'ai déjà côtoyé un développeur plus médiocre que moi surtout, et j'ai appris ce jour là qu'un clavier est un excellent outil pour arracher des dents.

    Que pensez-vous des conseils de Pete Shirley ? Pratiques ou loufoques ?
    En dehors de l'aspect trolldi ils sont plutôt cohérent si on oubli l'aspect Fortran et renfermé sur l'acquis.

    Quels sont ceux qui vous ont le plus marqué ?
    "Ne prétendez jamais que vous comprenez quelque chose quand vous ne la comprenez pas, et il est inutile de bluffer. Tout d’abord, faites une recherche Google, puis demandez aux gens de vous recommander de la lecture et enfin demandez un tutoriel à un collègue. Nous sommes tous ignorants sur presque toutes les choses."

    Et ça s'applique pas qu'au code ...

  9. #9
    Membre extrêmement actif
    M. Shirley est un génie, il a tout compris.
    On ressent l’expérience du gars dans ses mots.

    @SimonDecoline & @pboulanger +1, vous m'avez fait rire, mais c'est tellement vrai.

    @Markand -1
    J'espère que c'est une blague.
    C'est exactement le fait de rester sur des acquis préhistoriques qu'on évolue plus.
    Je suis entouré de collègues qui ne connaissent rien du C++ moderne et continuent d'écrire des horreurs de l'ère C with classes.
    Au contraire, un bon développeur doit se remettre en cause en permanence et renouveler ses connaissances.
    Tout comme un garagiste évolue en fonction des nouvelles technologies sur les véhicules.
    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.
    Linux est coder en "C with Class", maintenant je n'irais jamais dire que M. Torvalds ou M. Kroah-Hartman sont des développeurs médiocres.

    Pour reprendre l'exemple, ton garagiste, ne s'amusera pas à apprendre toutes les nouvelles techno sorti sur les dernier modèles.
    Il va se former au besoin et/ou sur le tas, pour quelques modèles.
    Sans compter que le socle (chassie, système de freinage, moteur, transmission ...etc) de ta caisse, n'évolue qu'as la marge depuis un paquet d'années.
    Ton garagiste à une caisse à outils, il sait (normalement ) à quoi chaqu'uns sert, mais s'il n'as/ne connait pas celui dont il à besoin, soit il te renvoie vers un autre garage, soit il te donne rendez-vous pour plus tard le temps de ce renseigner (s'il est honnête du moins).

    Dans tous les cas, la seule chose qui fait un bon ou un mauvais artisan/développeur, c'est bien le résultat.

    De plus, comme la écrit @setni (+1);
    En fait, si tous les devs appliquaient ces principes, la qualité du code, en générale, serait bien meilleure.
    Bien, d'accord avec ça.
    Ne pas apprendre tout et n'importe quoi, permet de ce forgé un socle solide de connaissances sur quelques technos, certes moins étendue, mais de façon beaucoup plus approfondi.
    On peut d'ailleurs faire un parallèle avec la fameuse maxime : Préférez la qualité, à la quantité.
    Étant développeur "Modern C++", vous devriez vous en être rendu compte tout seul normalement.
    Votre langage de choix étant tellement complexe à maitrisé, que peut ce présentent comme maitrisant complétement C++ (moderne ou pas).

    Finalement, il n'y a pas vraiment de bon ou mauvais développeur, il n'y as que des Client content ou pas .
    La finalité de notre métier étant de fournir des logiciels conformes aux attentes des clients.
    Partant de là, du moment que les attentes sont comblées, peut importe le comment.

    P.S. : Je croit bien que certains ont oubliés que notre métier ne ce résumer pas qu'as coder et que le langage que l'on utilise n'est qu'un détail d'implémentation (on peut faire un site web en c++ comme en php).

  10. #10
    Expert confirmé
    Citation Envoyé par defZero Voir le message
    Citation Envoyé par Markand Voir le message
    J'espère que c'est une blague. C'est exactement le fait de rester sur des acquis préhistoriques qu'on évolue plus. Je suis entouré de collègues qui ne connaissent rien du C++ moderne et continuent d'écrire des horreurs de l'ère C with classes. Au contraire, un bon développeur doit se remettre en cause en permanence et renouveler ses connaissances. Tout comme un garagiste évolue en fonction des nouvelles technologies sur les véhicules.
    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).
    Tu ne sais visiblement pas de quoi tu parles. Le C with Classes remonte à l'époque où la première norme du C++ n'était pas encore finie. Cette première norme date de 1998. Personne aujourd'hui n'utilise une bibliothèque ou un compilateur qui n'est compatible qu'avec le C with Classes : soit on code en C, soit on code en C++.
    En C++, quand on dit que des développeurs codent dans un style C with Classes, c'est pour dire qu'ils codent en C++ en gardant des habitudes qui viennent du langage C et qui étaient déjà obsolètes à l'époque du C++98.

    À part ça, cela fait longtemps que les pratiques qualifiées de C++ Moderne ne sont plus nouvelles. Elles se sont popularisées avec le C++11 et la plupart d'entre elles existaient déjà avant. Le C++11 date de 2011, donc d'il y a 8 ans !

  11. #11
    Futur Membre du Club
    Citation Envoyé par Markand Voir le message
    J'espère que c'est une blague. C'est exactement le fait de rester sur des acquis préhistoriques qu'on évolue plus. Je suis entouré de collègues qui ne connaissent rien du C++ moderne et continuent d'écrire des horreurs de l'ère C with classes. Au contraire, un bon développeur doit se remettre en cause en permanence et renouveler ses connaissances. Tout comme un garagiste évolue en fonction des nouvelles technologies sur les véhicules.
    Un garagiste évolue en fonction des nouvelles technologies, car connaitre ces technologies permet au garagiste de faire son travail. C'est pas la même chose avec les ordinateurs. Se limiter à sa zone de confiance pendant un certain temps, ça permet de faire germer la graine avant que vienne la forêt.

    La plupart des langages sont le fruits de développeurs qui soit voulaient réinventer le monde, mais sans grande originalité. Ou bien ce sont des langages conçus pour des besoins spécifiques et qui sont ensuite apparus dans le public.

    Les développeurs en bas de l'échelle n'ont pas souvent suffisamment d'instinct pour jauger les technologies auxiliaires à celles qu'ils connaissent déjà. La gymnastique mentale n'est pas encore installée.

  12. #12
    Membre actif
    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...
    Windows 7 / Delphi Tokyo
    "Les choses ne changent pas. Change ta façon de les voir, cela suffit" Lao Tseu

  13. #13
    Membre extrêmement actif
    @Galet :
    La première règle d'un 'bon' programme est qu'il doit fonctionner.
    +1, Tout à fait d'accord avec toi.

    @Pyramidev :
    Tu ne sais visiblement pas de quoi tu parles.
    Oui, je ne sais pas de quoi je parle , mais je ne doit pas être le seul .
    Je te rappel que @Mankind parlait d' "ère" et pas de "style" C with Classes, on parle bien de 2 choses distinctes.

    Donc quand tu écrit :
    En C++, quand on dit que des développeurs codent dans un style C with Classes, c'est pour dire qu'ils codent en C++ en gardant des habitudes qui viennent du langage C et qui étaient déjà obsolètes à l'époque du C++98.
    Ce n'est pas un contre exemple, juste on ne parle pas de la même chose.
    Comme tu peut le voir qu'en j'évoque le code de Linux, le terme "C with Classes" à 2 significations.

    @Pyramidev :
    Le C with Classes remonte à l'époque où la première norme du C++ n'était pas encore finie.
    Cette première norme date de 1998.
    C'est faux (pas la date hein, la dessus tout le monde est d'accord ) et tu mélange donc les 2 concepts.
    Le terme "C with Classes" est bien antérieur au C++ et de plus lui a largement survécu.
    Je te rappel que le C++ (mais aussi Objective-C) à ses débuts n'était qu'un simple jeu de macro C (bien avant normalisation).
    Pour reprendre ton rappel historique, le terme "C with Classes", remonte à l’apparition de la POO, quand les développeurs voulaient utiliser les concepts de l'OO avec un code en C procédurale.
    En passant, C++ n'est de fait qu'une émanation du C ce qui, l'as contraint à une contorsion syntaxique incroyable avec les Quircky que l'on connait et cela comme tous les autres langages étant basés sur le C pour faire de l'objet.
    Mais il existe toujours, puisqu'il regroupe toutes les techniques permettant d'avoir un code OO en C.
    En fait, il doit en exister autant que de toolkit/framework Objet en C.

    @Pyramid :
    Personne aujourd'hui n'utilise une bibliothèque ou un compilateur qui n'est compatible qu'avec le C with Classes : soit on code en C, soit on code en C++.
    Et pour cause ça n'existe pas, le "C with Class" n'est pas un langage, mais 2 concepts distincts (côté C et C++).
    Un "compilateur" C with Classes ça n'as jamais existé , donc oui on est d'accord, soit on code en C soit en C++.
    Par contre, concernant des lib "C with Classes", juste regarde GLib/GObject, EFL/EO, ...etc.
    Ces dernières étant des lib "C with Classes" comme il y en a pléthore, mais ça reste des lib C ...with Classes, pas C++ on est d'accord.

    Donc, je regrette, mais le "C with Classes" ne ce limite pas à là compréhension que tu en as d'un style de code C++ avant standardisation, ou au fait que des gens utilise le C++ comme si c'était du C, ce qui est parfois nécessaire de toute façon.

    Rassure moi, quand tu exporte tes lib C++, pour les rendre utilisable par le reste du monde, même en C++3K tu exporte bien une interface C (extern "C", ...etc) ?
    Sinon, je serait heureux de savoir comment tu interface du code C++ (avec ses mangling(s), runtime(s) et autres joyeusetés incompatibles et non spécifiés) vers le monde extérieur ?
    Où bien, tu ne développe/n'utilise pas de lib extérieur à tes projets et tu recompile tout à chaque Run ?

    De toute façon, de par ça nature/conception, le C++ est destiné à être utilisé avec un "style" C with Class.
    Donc je ne voit juste pas ce qu'il y a de mal là dedans, si le code est correct on peut même coder en "C++ Functional" .
    Après tout, un compilateur C++ va compiler du C (sauf incompatibilités qui ont justement était introduite avec le Modern C++) puisqu'il en est dépendant, là réciproque n'ayant jamais était vrai.

    @Pyramid :
    À part ça, cela fait longtemps que les pratiques qualifiées de C++ Moderne ne sont plus nouvelles.
    Elles se sont popularisées avec le C++11 et la plupart d'entre elles existaient déjà avant.
    Le C++11 date de 2011, donc d'il y a 8 ans !
    Oui, et.
    Si la toolchain fournit pour un projet n'est pas C++11 capable, tu fait quoi avec ton Modern ISO/C++11 & plus, pas si moderne que ça d'il y a 8 ans ?
    La réponse : Tu vas être bien emmerder de ne pas savoir coder en C++ style C with Classes, parce que tu ne te saura former qu'à partir du Modern C++ et puis 8 ans quand on parle de norme C++, je regrette mais c'est peanuts.

    Enfin, bref, merci pour ce petit rappel d'histoire, mais ça n’enlève rien à l'idée de mon commentaire qui est que juger de la qualité d'un programmeur en se basant sur l'outil (le langage) qu'il utilise est puéril.
    L'important c'est le résultat final, comme certains l'ont rappelés.

    P.S. : Le "style" C with Classes utilisé dans une toolchain C++, dont tu parle est utilisé :
    - Soit par les codeurs C pour avoir un typage plus stricte avec un compilateur C++.
    - Soit par les codeurs C++ pour s'interfacer avec le reste du monde, sans changer de toolchain pour leur projet.
    - Soit par les codeurs C++ pour remplir un objectif de performance, car oui le modèle Objet du C++ à un coup, contrairement à ce que l'on peut lire ici ou là.

  14. #14
    Expert confirmé
    Citation Envoyé par defZero Voir le message
    Si la toolchain fournit pour un projet n'est pas C++11 capable, tu fait quoi avec ton Modern ISO/C++11 & plus, pas si moderne que ça d'il y a 8 ans ?
    Qui peut le plus peut le moins.
    • Absence de la sémantique de mouvement => soit faire plus de copies, soit faire des passages par référence non constante et transférer des ressources à la main, par exemple avec des fonctions membres swap.
    • Absence de std::unique_ptr et d'autres wappers RAII => utiliser des bibliothèques externes ou recoder ces wrappers RAII à la main.
    • Absence des lambdas => coder à la main des classes qui surchargent l'opérateur fonction (operator()).
    • Absence de auto => déclarer explicitement les types. C'est plus compliqué en programmation par templates où on peut avoir des types qui dépendent d'autres, mais j'ai déjà géré ça.
    • Absence de la range-based for loop => utiliser BOOST_FOREACH ou, si on ne peut pas utiliser Boost, écrire une boucle for verbeuse à la main avec des itérateurs.
    • Absence de std::array => utiliser boost::array ou, si on ne peut pas utiliser Boost, utiliser un type tableau du C++.
    • etc.


    À part ça, il faudrait demander confirmation à Markand, mais je parie que ses collègues qui l'entourent ont une toolchain sur laquelle ils ont accès au C++11 voire à une version ultérieure. Sinon, il n'aurait vraisemblablement pas écrit son message. Après tout, il parlait de ses collègues, pas de développeurs inconnus travaillant sur un projet lointain.

  15. #15
    Membre extrêmement actif
    Ce message n'a pas pu être affiché car il comporte des erreurs.

  16. #16
    Membre éclairé
    Un développeur a intérêt à être médiocre. Les médiocres savent mieux travailler en équipe que les bons. Or, savoir travailler en équipe est le plus important, donc, finalement, les meilleurs, du moins ceux qui occupent la grande majorité des emplois (dans des équipes) sont les médiocres.
    Sur Youtube je suis "Le prof des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

  17. #17
    Expert confirmé
    Par rapport au C++98, les intérêts des versions plus récentes du C++ sont d'écrire plus facilement du code plus concis, plus lisible, plus standardisé, plus performant et avec moins de risques d'erreurs. Bientôt, avec les modules du C++20, il y aura aussi la facilité d'écrire du code qui compile plus vite.

    Pour illustrer la concision et la lisibilité, voici un bout de code en C++17, suivi de son équivalent en C++98 :
    Code cpp :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
     
    #include <iostream>
    #include <map>
    #include <string>
     
    void codeInCpp17() {
    	const std::map<std::string, std::string> country_capital_map = {
    		{"France", "Paris"},
    		{"Spain", "Madrid"},
    		{"USA", "Washington"}
    	};
    	for(const auto& [country, capital] : country_capital_map)
    		std::cout << "The capital of " << country << " is " << capital << ".\n";
    }
     
    void codeInCpp98() {
    	std::map<std::string, std::string> country_capital_map;
    	country_capital_map["France"] = "Paris";
    	country_capital_map["Spain"] = "Madrid";
    	country_capital_map["USA"] = "Washington";
    	std::map<std::string, std::string>::const_iterator it, start, stop;
    	start = country_capital_map.begin();
    	stop = country_capital_map.end();
    	for(it = start; it != stop; ++it) {
    		const std::string& country = it->first;
    		const std::string& capital = it->second;
    		std::cout << "The capital of " << country << " is " << capital << ".\n";
    	}
    }
     
    int main() {
    	codeInCpp17();
    	codeInCpp98();
    	return 0;
    }


    Concernant la distinction entre un bon développeur C++ et un mauvais développeur C++, je suis d'accord que la connaissance des dernières versions du langage n'est pas le critère le plus important. Par exemple, c'est beaucoup moins important que de savoir architecturer du code testable (par des tests unitaires) et bien appliquer le SRP (Single Responsibility Principle).

    Mais un développeur qui veut être bon doit chercher à progresser continuellement. Et, dans cette progression, il y a aussi le fait de s'informer sur l'évolution technologique, ce qui inclut l'évolution des langages de programmation que l'on utilise.

  18. #18
    Futur Membre du Club
    Citation Envoyé par Jamatronic Voir le message
    Un développeur a intérêt à être médiocre. Les médiocres savent mieux travailler en équipe que les bons. Or, savoir travailler en équipe est le plus important, donc, finalement, les meilleurs, du moins ceux qui occupent la grande majorité des emplois (dans des équipes) sont les médiocres.

    Oui mais moi j'aimerais m'employer moi-même. Si je veux travailler en équipe optimal dans mon entreprise, je vais devoir être médiocre. Mais si je suis médiocre, y a pas d'entreprise. Je n'aurais pas fait ce que j'aimais. Gros dilemme!

  19. #19
    Nouveau Candidat au Club
    Ces règles constituent une excellente recette pour rester médiocre, je pense qu'il faut chercher à s'améliorer pas à survivre en étant médiocre (tout en le sachant et en l'admettant)

  20. #20
    Membre confirmé
    Peter Shirley is American computer scientist and computer graphics researcher. He is a Distinguished Scientist at NVIDIA and adjunct professor at the University of Utah in computer science. He has made extensive contributions to interactive photorealistic rendering.
    Ok, un développeur médiocre.