Discussion :

[Stéphane le calme]

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

[Invité]

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

Trop facile : passer chef de projet.

[Markand]

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.

[L33tige]

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...

[JCD_31]

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."

[setni]

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.

[pboulanger]

Trop facile : passer chef de projet.

ou alors scrum master, c'est dans l'air du temps ;-)

[strato35]

Ê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 ...

[defZero]

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).

[Pyramidev]

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 !

[leresidue]

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.

[Galet]

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...

[defZero]

@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à.

[Pyramidev]

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.

[defZero]

@Pyramidev : [QUOTE]Qui peut le plus peut le moins.[/CODE]

Là tu fait clairement une généralité de ton cas parce que des Dev Modern C++ qui ne savaient pas utilisé une toolchain ante-diluviene, j'en est vue un paquet.
Et pour revenir au sujet de l'article, tous les Dev Modern C++ ne seraient pas capable (en temps et/ou en capacité) de se passer des abstractions, sucres syntaxiques et ajouts sémantiques introduit à partir de C++11.

Pour tes exemples :

• 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 ressource à 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.
• Absence de std::array => utiliser boost::array ou, si on ne peut pas utiliser Boost, utiliser un type tableau du C++.
• etc.

Oui et si tu supprime la "move semantic", que tu réduit les "value category" à ce qui existait avant C++11 et que tu supprime les constexpr, tous ce qui reste est du sucre syntaxique.
...Dans tous les cas ça revient à abandonner les avantages du Modern C++, ce qui est normale puisque nécessité fait loi.
Par contre pourquoi vouloir à tout pris faire du Modern C++, si du C++ style "C with Classes" suffit ?
Autrement dit, pourquoi faire simple, quand on peut faire compliqué ?
En lien avec l'article, peut-être est-ce la marque des meilleurs ?

@Pyramidev :

À part ça, il faudrait demander confirmation à Markand, mais je parie que ses collègues qui l'entourrent 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.

Oui, tu a raison, il faudrait demander à @Markand, s'il re-passe par là un petit éclaircissement serait le bienvenue .

Par contre, il n'est pas rare dans une équipe de travailler sur des projets différents ou non, mais avec différent prérequis.
Il m'est déjà arriver de travailler avec des toolchain différentes, mais avec un code commun, ont prend bien le plus petit dénominateur commun, soit la version la moins évoluée du langage pris en compte par toutes les toolchain.

/!\ Sur ce qui suit, je suit juste ce que je présume être la pensée de @Mankind pour désigner le contre sens que je perçois :

Le C++ est le langage four tout par excellence, c'est donc en contre exemple même de ce qu'écrit @Mankind.

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.

Mais si on suit ta logique, choisir systématiquement le Modern C++, c'est juste un choix facile et de faignant.
Tu reproche aux autres ce que tu fait toi même, soit choisir ton outil de prédilection.
Prendre un outil que tu maitrise et tous vouloir faire avec, c'est humain, mais il faut garder à l’esprit que ce n'est pas un choix rationnel.
En reprenant tes mots, tu te repose donc sur tes laurier en ne te remettant pas en cause et en ne renouvelant pas tes connaissances.

P.S. : Tu peut coder des horreur en Modern C++ comme en C++ style "C with Classes", ça n'as rien à voir. Là on en revient au sujet de l'article.
P.S. (bis) : Et puis cracher sur les "collègues" (qui ne seraient pas de "bon développeur" d'après ta logique) qui t' "entoure", juste parce qu’ils ne code pas comme tu le voudrais, ça démontre une sacrée maturité et une sacrée remise en cause de tes acquits.
Ça doit être un vrai bonheur de travailler avec toi.

[Jamatronic]

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.

[Pyramidev]

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.

[leresidue]

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!

[jiboon]

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)

[anykeyh]

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.