# Le club des professionnels en informatique > La taverne du Club : Humour et divers > Humour Informatique >  Trolldi : comment survivre en entreprise tout en tant un dveloppeur mdiocre ?

## Stphane le calme

*Trolldi : comment survivre en entreprise tout en tant un dveloppeur mdiocre ?*
*Quelques conseils bien pratiques ... ou pas * 

Pete Shirley est un dveloppeur mdiocre et il le reconnait :  demandez  quiconque a dj travaill sur un projet de groupe avec moi et vous verrez . Il prcise que  la compensation principale est que je suis conscient que je suis un dveloppeur mdiocre. 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 dveloppeurs les heuristiques qui lui permettent de rester productif, notant au passage que  ces heuristiques sont bonnes pour tous les dveloppeurs, mais sont essentielles pour ceux dentre 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 systmes fonctionnent mieux sils restent simples et non compliqus ; par consquent, la simplicit doit tre un objectif cl de la conception et toute complexit inutile doit tre vite. Pour Shirley, il faut imprativement se poser une question prconise par le mouvement de la programmation extrme : quelle est la chose la plus simple qui puisse fonctionner ? Une fois que vous l'avez dfinie, 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 dveloppeur ne doit ajouter aucune fonctionnalit avant que cela soit jug ncessaire. Pour Shirley,  en ce qui concerne les fonctionnalits et en gnral, "*Y*ou *A*ren't *G*onna *N*eed *I*t" Puis ALAN. Avoid Learning Anything New (littralement, vitez d'apprendre quelque chose de nouveau). Shirley note que diffrents 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 donnes par dfaut. Demandez-vous toujours  comment un programmeur FORTRAN ferait-il cela ? . Au cours de votre vie, vous devriez utiliser occasionnellement des arbres, mais considrez-les comme une consommation excessive d'alcool ... une utilisation rgulire endommagera votre foie.Ne prtendez jamais que vous comprenez quelque chose quand vous ne la comprenez pas, et il est inutile de bluffer. Tout dabord, faites une recherche Google, puis demandez aux gens de vous recommander de la lecture et enfin demandez un tutoriel  un collgue. 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 vracit 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 dvelopper une zone de confort dans certaines zones. Celle de Shirley repose sur un code C ++ gomtrique qui appelle des nombres alatoires. N'essayez pas d'tre un expert dans tout ou mme la plupart des choses.
 Enfin, laissez lordinateur faire le travail ; Dave Kirk parle de l'lgance de la force brute (je ne sais pas si c'est original avec lui). C'est un cousin de KISS. Le matriel est rapide. Le logiciel est difficile. Profiter du miracle de la cration dans le logiciel ; vous crez quelque chose en vous appuyant sur le comportement des octets. Si vous tes mdiocre en dveloppement, mais que vous dveloppez toujours, rappelez-vous que c'est quelque chose que trs peu de gens peuvent faire .

Source : billet Pete Shirley

*Et vous ?*

 ::fleche::  tes-vous un dveloppeur mdiocre ?
 ::fleche::  Si oui, comment avez-vous fait pour survivre en entreprise ?
 ::fleche::  Sinon, avez-vous dj ctoy un dveloppeur mdiocre et comment l'avez-vous gr ?
 ::fleche::  Que pensez-vous des conseils de Pete Shirley ? Pratiques ou loufoques ?
 ::fleche::  Quels sont ceux qui vous ont le plus marqu ?

*Voir aussi :*

 ::fleche::  Trolldi : 30% des travailleurs remplaceraient leur patron par un robot, un pourcentage qui augmente dans la perspective d'un robot humanode amical
 ::fleche::  Trolldi : Mozilla nomin parmi les "Internet Villain" par l'ISPA britannique pour son support de DNS-over-HTTPS, aux cts de l'article 13 et de Trump
 ::fleche::  Trolldi : travailler juste une journe par semaine pourrait amliorer votre sant mentale, d'aprs une tude des chercheurs de l'universit Cambridge
 ::fleche::  Trolldi : un dveloppeur prsente le nouvel lment HTML <clippy>, une satire pour dnoncer l'attitude parfois  arrogante  de certaines entreprises

----------


## Invit

> Trolldi : comment survivre en entreprise tout en tant un dveloppeur mdiocre ?


Trop facile : passer chef de projet.

----------


## Markand

> Puis ALAN. Avoid Learning Anything New (littralement vitez d'apprendre quelque chose de nouveau). Shirley note que diffrents 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'espre que c'est une blague. C'est exactement le fait de rester sur des acquis prhistoriques qu'on volue plus. Je suis entour de collgues qui ne connaissent rien du C++ moderne et continuent d'crire des horreurs de l're C with classes. Au contraire, un bon dveloppeur doit se remettre en cause en permanence et renouveler ses connaissances. Tout comme un garagiste volue en fonction des nouvelles technologies sur les vhicules.

----------


## L33tige

Bizarrement y'en  2-3 qui sont pas de mauvais conseils je trouve, le KISS, remettre la parole en doute, ne pas prtendre savoir ce que l'on ne sais pas...

----------


## JCD_31

Je me suis toujours considr comme un dveloppeur mdiocre.

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

----------


## setni

A part " Puis ALAN. Avoid Learning Anything New (littralement vitez d'apprendre quelque chose de nouveau) "

En fait, si tous les devs appliquaient ces principes, la qualit du code, en gnrale, serait bien meilleure.

Notre profession est pollue 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 anantissant les candidats  un poste pour des motifs bidons et font exploser le cot 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 dveloppeur mdiocre ?


A en jug par les critres donns et le fait que j'ai tendance  avoir un QI proche de celui de la serpillire (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 dj ctoy un dveloppeur mdiocre et comment l'avez-vous gr ?


J'ai dj ctoy un dveloppeur plus mdiocre 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 plutt cohrent si on oubli l'aspect Fortran et renferm sur l'acquis.




> Quels sont ceux qui vous ont le plus marqu ?


"Ne prtendez jamais que vous comprenez quelque chose quand vous ne la comprenez pas, et il est inutile de bluffer. Tout dabord, faites une recherche Google, puis demandez aux gens de vous recommander de la lecture et enfin demandez un tutoriel  un collgue. Nous sommes tous ignorants sur presque toutes les choses."

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

----------


## defZero

M. Shirley est un gnie, il a tout compris.
On ressent lexprience du gars dans ses mots.

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

@Markand -1



> J'espre que c'est une blague.
> C'est exactement le fait de rester sur des acquis prhistoriques qu'on volue plus.
> Je suis entour de collgues qui ne connaissent rien du C++ moderne et continuent d'crire des horreurs de l're C with classes.
> Au contraire, un bon dveloppeur doit se remettre en cause en permanence et renouveler ses connaissances.
> Tout comme un garagiste volue en fonction des nouvelles technologies sur les vhicules.


Tes collgues 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 diffrent ou ABI/API incompatible avec un "Modern C++" (trs bon livre au passage).
Et puis c'est juste puril et hors propos de juger du niveau d'un dveloppeur 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 dveloppeurs mdiocres.

Pour reprendre l'exemple, ton garagiste, ne s'amusera pas  apprendre toutes les nouvelles techno sorti sur les dernier modles.
Il va se former au besoin et/ou sur le tas, pour quelques modles.
Sans compter que le socle (chassie, systme de freinage, moteur, transmission ...etc) de ta caisse, n'volue qu'as la marge depuis un paquet d'annes.
Ton garagiste  une caisse  outils, il sait (normalement  ::aie:: )  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 honnte du moins).

Dans tous les cas, la seule chose qui fait un bon ou un mauvais artisan/dveloppeur, c'est bien le rsultat.

De plus, comme la crit @setni (+1);



> En fait, si tous les devs appliquaient ces principes, la qualit du code, en gnrale, 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 faon beaucoup plus approfondi.
On peut d'ailleurs faire un parallle avec la fameuse maxime : Prfrez la qualit,  la quantit.
tant dveloppeur "Modern C++", vous devriez vous en tre rendu compte tout seul normalement.
Votre langage de choix tant tellement complexe  maitris, que peut ce prsentent comme maitrisant compltement C++ (moderne ou pas).

Finalement, il n'y a pas vraiment de bon ou mauvais dveloppeur, il n'y as que des Client content ou pas  :;): .
La finalit de notre mtier tant de fournir des logiciels conformes aux attentes des clients.
Partant de l, du moment que les attentes sont combles, peut importe le comment.

P.S. : Je croit bien que certains ont oublis que notre mtier ne ce rsumer pas qu'as coder et que le langage que l'on utilise n'est qu'un dtail d'implmentation (on peut faire un site web en c++ comme en php).

----------


## Pyramidev

> Envoy par Markand
> 
> 
> J'espre que c'est une blague. C'est exactement le fait de rester sur des acquis prhistoriques qu'on volue plus. Je suis entour de collgues qui ne connaissent rien du C++ moderne et continuent d'crire des horreurs de l're C with classes. Au contraire, un bon dveloppeur doit se remettre en cause en permanence et renouveler ses connaissances. Tout comme un garagiste volue en fonction des nouvelles technologies sur les vhicules.
> 
> 
> Tes collgues 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 diffrent ou ABI/API incompatible avec un "Modern C++" (trs bon livre au passage).


Tu ne sais visiblement pas de quoi tu parles. Le C with Classes remonte  l'poque o la premire norme du C++ n'tait pas encore finie. Cette premire norme date de 1998. Personne aujourd'hui n'utilise une bibliothque 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 dveloppeurs 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 dj obsoltes  l'poque du C++98.

 part a, cela fait longtemps que les pratiques qualifies de C++ Moderne ne sont plus nouvelles. Elles se sont popularises avec le C++11 et la plupart d'entre elles existaient dj avant. Le C++11 date de 2011, donc d'il y a 8 ans !

----------


## leresidue

> J'espre que c'est une blague. C'est exactement le fait de rester sur des acquis prhistoriques qu'on volue plus. Je suis entour de collgues qui ne connaissent rien du C++ moderne et continuent d'crire des horreurs de l're C with classes. Au contraire, un bon dveloppeur doit se remettre en cause en permanence et renouveler ses connaissances. Tout comme un garagiste volue en fonction des nouvelles technologies sur les vhicules.


Un garagiste volue en fonction des nouvelles technologies, car connaitre ces technologies permet au garagiste de faire son travail. C'est pas la mme 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 fort.

La plupart des langages sont le fruits de dveloppeurs qui soit voulaient rinventer le monde, mais sans grande originalit. Ou bien ce sont des langages conus pour des besoins spcifiques et qui sont ensuite apparus dans le public.

Les dveloppeurs en bas de l'chelle n'ont pas souvent suffisamment d'instinct pour jauger les technologies auxiliaires  celles qu'ils connaissent dj. La gymnastique mentale n'est pas encore installe.

----------


## Galet

Bonjour  tous,
Tout est une question de rfrence !
Nous avons tous un processeur et une capacit mmoire diffrente, il faut bien faire avec...ou sans.
On a tous crois des dveloppeurs qui font mieux en moins de temps...pour qui nous sommes surement des Mdiocres. Et d'autres, plus mdiocres encore... voir franchement mauvais. ::mouarf:: 

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

Il manque une rgle qui m'a dj sauve (et quelquefois desservie) : Le mieux est l'ennemi du bien !
La premire rgle d'un 'bon' programme est qu'il doit fonctionner.

belle journe...

----------


## defZero

@Galet : 


> La premire rgle 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  ::aie:: , mais je ne doit pas tre le seul  ::ptdr:: .
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 dveloppeurs 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 dj obsoltes  l'poque du C++98.


Ce n'est pas un contre exemple, juste on ne parle pas de la mme 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 premire norme du C++ n'tait pas encore finie.
> Cette premire norme date de 1998.


C'est faux (pas la date hein, la dessus tout le monde est d'accord  :;):  ) et tu mlange donc les 2 concepts.
Le terme "C with Classes" est bien antrieur au C++ et de plus lui a largement survcu.
Je te rappel que le C++ (mais aussi Objective-C)  ses dbuts n'tait qu'un simple jeu de macro C (bien avant normalisation).
Pour reprendre ton rappel historique, le terme "C with Classes", remonte  lapparition de la POO, quand les dveloppeurs voulaient utiliser les concepts de l'OO avec un code en C procdurale.
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 bass 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 bibliothque 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 (ct C et C++).
Un "compilateur" C with Classes a n'as jamais exist  ::ptdr:: , 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 dernires tant des lib "C with Classes" comme il y en a plthore, 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 comprhension 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 ncessaire de toute faon.

Rassure moi, quand tu exporte tes lib C++, pour les rendre utilisable par le reste du monde, mme en C++3K  ::aie::  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 joyeusets incompatibles et non spcifis) vers le monde extrieur ?
O bien, tu ne dveloppe/n'utilise pas de lib extrieur  tes projets et tu recompile tout  chaque Run ?

De toute faon, 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 mme coder en "C++ Functional"  ::ptdr:: .
Aprs tout, un compilateur C++ va compiler du C (sauf incompatibilits qui ont justement tait introduite avec le Modern C++) puisqu'il en est dpendant, l rciproque n'ayant jamais tait vrai.

@Pyramid : 


> part a, cela fait longtemps que les pratiques qualifies de C++ Moderne ne sont plus nouvelles.
> Elles se sont popularises avec le C++11 et la plupart d'entre elles existaient dj 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 ?  ::aie:: 
La rponse : 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 nenlve rien  l'ide 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 puril.
L'important c'est le rsultat final, comme certains l'ont rappels.

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 modle 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 smantique de mouvement => soit faire plus de copies, soit faire des passages par rfrence non constante et transfrer des ressources  la main, par exemple avec des fonctions membres swap.Absence de std::unique_ptr et d'autres wappers RAII => utiliser des bibliothques externes ou recoder ces wrappers RAII  la main.Absence des lambdas => coder  la main des classes qui surchargent l'oprateur fonction (operator()).Absence de auto => dclarer explicitement les types. C'est plus compliqu en programmation par templates o on peut avoir des types qui dpendent d'autres, mais j'ai dj gr 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 itrateurs.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 collgues qui l'entourent ont une toolchain sur laquelle ils ont accs au C++11 voire  une version ultrieure. Sinon, il n'aurait vraisemblablement pas crit son message. Aprs tout, il parlait de ses collgues, pas de dveloppeurs inconnus travaillant sur un projet lointain.

----------


## defZero

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

L tu fait clairement une gnralit 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 smantiques introduit  partir de C++11.

Pour tes exemples :
Absence de la smantique de mouvement => soit faire plus de copies, soit faire des passages par rfrence non constante et transfrer des ressource  la main, par exemple avec des fonctions membres swap.Absence de std::unique_ptr et d'autres wappers RAII => utiliser des bibliothques externes ou recoder ces wrappers RAII  la main.Absence des lambdas => coder  la main des classes qui surchargent l'oprateur fonction (operator()).Absence de auto => dclarer explicitement les types.
C'est plus compliqu en programmation par templates o on peut avoir des types qui dpendent d'autres, mais j'ai dj gr 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 rduit 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 ncessit 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 ?  ::aie:: 
En lien avec l'article, peut-tre est-ce la marque des meilleurs ?  ::ptdr:: 

@Pyramidev : 


> part a, il faudrait demander confirmation  Markand, mais je parie que ses collgues qui l'entourrent ont une toolchain sur laquelle ils ont accs au C++11 voire  une version ultrieure.
> Sinon, il n'aurait vraisemblablement pas crit son message.
> Aprs tout, il parlait de ses collgues, pas de dveloppeurs 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 diffrents ou non, mais avec diffrent prrequis.
Il m'est dj arriver de travailler avec des toolchain diffrentes, mais avec un code commun, ont prend bien le plus petit dnominateur commun, soit la version la moins volue du langage pris en compte par toutes les toolchain.

/!\  Sur ce qui suit, je suit juste ce que je prsume tre la pense de @Mankind pour dsigner le contre sens que je perois :

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




> C'est exactement le fait de rester sur des acquis prhistoriques qu'on volue plus.
> Je suis entour de collgues qui ne connaissent rien du C++ moderne et continuent d'crire des horreurs de l're C with classes.
> Au contraire, un bon dveloppeur doit se remettre en cause en permanence et renouveler ses connaissances.


Mais si on suit ta logique, choisir systmatiquement le Modern C++, c'est juste un choix facile et de faignant.
Tu reproche aux autres ce que tu fait toi mme, soit choisir ton outil de prdilection.
Prendre un outil que tu maitrise et tous vouloir faire avec, c'est humain, mais il faut garder  lesprit 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 "collgues" (qui ne seraient pas de "bon dveloppeur" d'aprs ta logique) qui t' "entoure", juste parce quils ne code pas comme tu le voudrais, a dmontre une sacre maturit et une sacre remise en cause de tes acquits.
a doit tre un vrai bonheur de travailler avec toi.  ::ptdr::

----------


## Jamatronic

Un dveloppeur a intrt  tre mdiocre. Les mdiocres 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 mdiocres.

----------


## Pyramidev

Par rapport au C++98, les intrts des versions plus rcentes du C++ sont d'crire plus facilement du code plus concis, plus lisible, plus standardis, plus performant et avec moins de risques d'erreurs. Bientt, 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 :


```

```


Concernant la distinction entre un bon dveloppeur C++ et un mauvais dveloppeur C++, je suis d'accord que la connaissance des dernires versions du langage n'est pas le critre 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 dveloppeur 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 dveloppeur a intrt  tre mdiocre. Les mdiocres 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 mdiocres.



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

----------


## jiboon

Ces rgles constituent une excellente recette pour rester mdiocre, je pense qu'il faut chercher  s'amliorer pas  survivre en tant mdiocre (tout en le sachant et en l'admettant)  ::weird::

----------


## 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 dveloppeur mdiocre.

----------


## JackIsJack

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/ Recrer la roue pour un quelconque motif d'optimisation (qui devra paratre vital pour vous). Refusez toute forme de template ou de librairies, ils ne sont pas adapts.

3/ Investissez vous  fond dans des sujets annexes qui ne requirent pas le jugement d'un client, par exemple Git, la configuration de l'edi. Crez des architectures techniques et des nomenclatures complexes sur ces domaines. Restez loigns des sources de jugement : trouvez la niche o vous serez seul.

4/ Critiquez le travail des prcdants dveloppeurs, c'est  cause de leur programme pourri si vous n'y arrivez pas. La seule bonne faon de rflchir est la votre. 

5/ Critiquez l'imprcision de la demande du client  :  c'est le client qui ne vous a pas dit que la scurit, les performances et la gestion de la concurence taient importantes, c'est de sa faute. Vous n'tes qu'un simple excutant.

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

7/ Critiquez le temps qu'on vous a allou. On vous a demand de dveloppez 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 rle d'expert de dire non ou de definir une cible cohrente avec ce chiffrage.

 ::aie::  (ils survivent comme ils peuvent les dveloppeurs mdiocres)

----------


## Cincinnatus

> Ok, un dveloppeur mdiocre.


+1

Ou plutt un dveloppeur humble.
je pense que derrire sa terminologie, il faut comprendre qu'un bon dveloppeur humble, prt  s'informer, se remettre en cause, sera en fait meilleur qu'un prsum cador. Il ne va pas rinventer la roue, ni bloquer les ides/initiatives des collgues. Il fera plutt un code plus simple  comprendre et un autre dveloppeur pourra plus facilement reprendre ses projets.

----------


## Markand

> @Markand -1
> 
> Tes collgues 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 diffrent ou ABI/API incompatible avec un "Modern C++" (trs bon livre au passage).
> Et puis c'est juste puril et hors propos de juger du niveau d'un dveloppeur 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 dveloppement sans mme connaitre ce qu'on fait.

Donc pour ton information,

Oui nous avons les outils pour faire du C++ moderneOui certains font l'effort ici de se remettre en cause et n'hsitent pas  venir me voir pour me demander des conseilsNon certains ne font pas l'effort et continuent de rester sur leur acquis post cole (certains collgues 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 dveloppeurs mdiocres.


Non, Linux est cod en C tout court.




> Il va se former au besoin et/ou sur le tas, pour quelques modles.


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.

----------


## Cincinnatus

> D'autres techniques de survie classiques


Mouais... Plutt de quoi se faire flinguer par son patron/ses collgues/son client  ::roll:: 




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




> 2/ Recrer la roue pour un quelconque motif d'optimisation (qui devra paratre vital pour vous). Refusez toute forme de template ou de librairies, ils ne sont pas adapts.


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 fonctionnalits  ::whistle:: 




> 3/ Investissez vous  fond dans des sujets annexes qui ne requirent pas le jugement d'un client, par exemple Git, la configuration de l'edi. Crez des architectures techniques et des nomenclatures complexes sur ces domaines. Restez loigns 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 compliqus qui ne servent  rien...




> 4/ Critiquez le travail des prcdants dveloppeurs, c'est  cause de leur programme pourri si vous n'y arrivez pas. La seule bonne faon de rflchir est la votre. 
> 
> 5/ Critiquez l'imprcision de la demande du client  :  c'est le client qui ne vous a pas dit que la scurit, les performances et la gestion de la concurence taient importantes, c'est de sa faute. Vous n'tes qu'un simple excutant.
> 
> 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 dveloppez 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 rle d'expert de dire non ou de definir une cible cohrente 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 collgues 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 (scurit, perfs, ...) sont plus  dfinir par les "techniciens" que par le client fonctionnel. 
6/ les utilisateurs ne lisent jamais la doc.  ::aie:: 
7/ on fait des versions et on livre d'abord le minimum, puis on ajoute des fonctionnalits au fur et  mesure des nouvelles livraisons. Cf la mthode MoSCoW pour prioriser les besoins : de ceux qui sont indispensables  ceux qui ne sont que des gadgets.
https://fr.wikipedia.org/wiki/Mthode_MoSCoW


Pour rsumer, un peu d'humilit et beaucoup de diplomatie, et a se passe mieux  :;):

----------


## L33tige

> +1
> 
> Ou plutt un dveloppeur humble.
> je pense que derrire sa terminologie, il faut comprendre qu'un bon dveloppeur humble, prt  s'informer, se remettre en cause, sera en fait meilleur qu'un prsum cador. Il ne va pas rinventer la roue, ni bloquer les ides/initiatives des collgues. Il fera plutt un code plus simple  comprendre et un autre dveloppeur pourra plus facilement reprendre ses projets.


C'est dommage parce-que pour moi a c'est un bon dveloppeur...  ::(: 

Plus srieusement, on  tous dj vu des gnies qu'on arrive mme pas  la cheville, mais franchement j'aimerais pas travailler en quipe avec la moiti d'entre eux.

----------


## JackIsJack

> Mouais... Plutt de quoi se faire flinguer par son patron/ses collgues/son client


Oui, si ton patron est intelligent !
Ma liste tait ironique  ::):  
C'est videmment une compilation de mauvaises pratiques... qui sont frquentes.

----------


## Cincinnatus

> Ma liste tait ironique


Heureusement, et je l'avais bien compris comme a.  ::chin::

----------


## el_slapper

> Trop facile : passer chef de projet.


Tu rigoles, mais j'ai vu une trs mauvaise dveloppeuse faire une trs bonne chef de projet. Bon, d'accord, un chantillon de taille 1 n'est pas statistiquement reprsentatif.

----------


## benjamalin

N'y a t il que moi qui ai vu l'ironie du propos... bien sur que ces pratiques dfinissent justement ce qui conduise  devenir un excellent dveloppeur. IE quelqu'un qui dveloppe des logiciels pas son go

----------


## GLDavid

> Tu rigoles, mais j'ai vu une trs mauvaise dveloppeuse faire une trs bonne chef de projet. Bon, d'accord, un chantillon de taille 1 n'est pas statistiquement reprsentatif.


Bonjour

J'ai vu un bon quivalent: se faire passer pour "l'architecte de l'cosystme logiciel de l'entreprise". Et oui, l'un de mes collgues a balanc cela pour se prsenter devant notre nime nouveau chef d'quipe. En ralit, il avait bien ralis quelques logiciels au dbut de la structure (2 stand alones en Delphi et un site dgueulasse en PHP). Puis, il n'avait plus rien sorti, prfrant se focaliser sur... quel nouveau langage je vais faire adopter  mon quipe et se faire passer pour le matre  penser.
Encore plus fort? J'ai! Vous tes Data Manager, et bien, prenez le monopole de la connaissance de la base de donnes utilise par l'entreprise. Ne partagez rien  vos collgues concernant vos connaissances et jouez la montre en cas de problme! 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-collgues qui a fini par tre mon suprieur hirarchique nous condamnant au reverse engineering.
Vous comprendrez pourquoi j'ai pas hsit une minute pour changer de job (en y gagnant au change)  ::P: 

@++

----------


## Guesset

Bonjour,

Il n'est pas sr qu'tre un bon programmeur soit un objectif professionnel sain.

Prenons un exemple.

Un trs bon dveloppeur crit un code efficient, lisible et bien document. Cela signifie qu'il est facile de le remercier (hlas dans tous les sens du terme) puisque la qualit du travail est telle qu'elle ne demande pas beaucoup de maintenance et que des amliorations 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 ncessitera la prsence de l'auteur initial, le seul  peu prs capable de le faire voluer.

Dans ce cas de figure, la persistance de bugs est un plus en terme d'incitations  conserver ce collaborateur prcieux (dans le sens o il cote cher  :8-):  ).  

Bien sr, cela ne s'improvise pas. Il faut viter les tests, les projections de montes en charges et travailler avec des outils en fin de vie.

J'exagre ? Peut tre.

Salutations

----------


## pierre.E

de toute facons avec les ia qui seront capables de compiler du code avec une efficacit redoutable suffit maintenant d'apprendre le python ::P:

----------


## Moez.B

Pour tre vraiment un dveloppeur mdiocre, 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 dtendu mme si les tches ne sont pas termines
- Respecter les deadlines mme si le dv est mal foutu et qu'il y a 5000 bricoles au passage : il vaut mieux avoir un dv foireux de fait  100% au jour j que de le faire  la perfection  70% au jour j+2

----------


## Guesset

Bonjour,




> Pour tre vraiment un dveloppeur mdiocre, il faut : 
> - Ne pas tre curieux


Si ne pas tre curieux est effectivement une caractristique du dveloppeur mdiocre, sa contrapose n'est gure mieux. Le dveloppeur qui utilise systmatiquement les nouveauts (souvent mal comprises et plus limites 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 adapte au problme.

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 prt  croire qu'une vielle application Cobol de 20 ans pouvait renatre en passanr dans une moulinette qui en sortirait un modle objet lui-mme retrait pour sortir du java.

Depuis le temps que mthodes et outils nous promettent des gains en vitesse et en fiabilit, les projets devraient se faire en un clin dil et la solution du "dans le doute reboot" ne pas exister.

C'est tout (pour l'instant  ::):  )

Salutations

----------


## Iloyd

tant tudiant, a motive.

----------


## pemmore

dbut des annes 70, elle passe un diplme d'lectronique et se retrouve dans une bote d'informatique je crois Delta Electronic,  l'poque les informaticiens courraient pas les rues, on formait sue le tas, seule fille de la bote, hyper gentille, ils l'ont protge, mais jamais elle a crit la moindre ligne de code des quelques annes heureuses  Paris, rendu quelques vagues services c'est tout.

----------


## DavidleVrai

Presque tout dans cet article est pour moi la description d'un bon dveloppeur. Mais certains suivent ces conseils les yeux ferms. 
Ce sont de bon conseils mais les appliquer strictement sans nuance fera de vous un dveloppeur aussi mdiocre que celui qui ne les applique pas. 

Mais dans la plupart des entreprises, un dveloppeur sera considr comme bon par le responsable du service, si il est en mesure d'expdier rapidement son travail. 
C'est a dire que ce dveloppeur 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 dveloppement soient en mesure de combler les manques, les approximations, les "ca je sais pas, tant pi, il se dbrouillera... ", 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 faon c'est pas lui qui est en charge de leurs corrections, ils n'interviendront que dans quelques mois). 

Le dveloppeur qui possde "ces qualits", apparatra dans les chiffres comme efficace parce que ceux-ci ne prennent en compte qu'une petite partie de la chane de production et  court terme. 
Alors qu'en ralit son travail cote cher, ajoute une charge de travail  ses collgues et dgrade le rsultat attendu. 

Mais, si tu es ce dveloppeur et que tu souhaites monter dans la hirarchie de l'entreprise, sache que suivre ces principes marchera  coup sr, que tu deviendras manager, que tu gagneras plus d'argent qu'un dveloppeur qui fait un travail cohrent. 
Oui, le responsable qui te choisira est ton digne prdcesseur. Il te reconnatra comme lui pour tre un bon : efficace et pragmatique (il en est persuad car il fait partit des lus et toutes "ces qualits" prouvent qu'il est clairement plus intelligent). 
Ce dveloppeur pourra donc prendre la suite en devenant a son tour le responsable, et continuer ainsi cette dlicieuse "boucle vertueuse". 

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

----------


## pemmore

> Bonjour  tous,
> Tout est une question de rfrence !
> Nous avons tous un processeur et une capacit mmoire diffrente, il faut bien faire avec...ou sans.
> On a tous crois des dveloppeurs qui font mieux en moins de temps...pour qui nous sommes surement des Mdiocres. Et d'autres, plus mdiocres encore... voir franchement mauvais.
> 
> L'important est d'essayer de mesurer ses limites et d'essayer de les dpasser...un peu !
> 
> Il manque une rgle qui m'a dj sauve (et quelquefois desservie) : Le mieux est l'ennemi du bien !
> La premire rgle d'un 'bon' programme est qu'il doit fonctionner.
> ...


Dans toute cration, invention, modification, etc, ce principe est le bon, tant pis pour les rleurs pris d'orthodoxie.

----------


## el_slapper

> (.../...)Le dveloppeur qui possde "ces qualits", apparatra dans les chiffres comme efficace parce que ceux-ci ne prennent en compte qu'une petite partie de la chane de production et  court terme. 
> Alors qu'en ralit son travail cote cher, ajoute une charge de travail  ses collgues et dgrade le rsultat attendu. (.../...)


Dans ma boite, c'est presque pareil. Le grand chef en Australie a demand des chiffres : combien chacun de nous quatre a dvelopp de tests automatiques? 

Madame A a pass beaucoup de temps  aider l'implmentation, et elle n'a pas beaucoup produit. Elle va se faire plomber, alors qu'elle a t trs utile  la boite.

Madame S a pass la moiti de l'anne  prparer son moteur de test pour les tests comptables. Depuis elle pisse de grande quantits de tests, tous sur la mme architecture. Elle va se faire fliciter, ce qui est normal. elle a bien prpar son coup, et en ramasse les dividendes en cette fin d'anne.

Moi, j'ai pass mon temps sur des tests trs compliqus...et finalement, tous nos clients ont laiss tomb cette option. Donc je craignais un nombre trs faible qui allait me plomber. Mais en fait, non. Parceque j'ai pass deux heures en dbut d'anne  transfrer des scripts de la version prcdente, et a multiplie par 10 mon nombre apparent de scripts raliss.

Monsieur M, lui, a gr des problmes techniques en tout genre. Il n'a pas fait un seul script de l'anne. Mais il en a transfr encore plus que moi de l'anne prcdente. a a du lui prendre 4 heures. Il va avoir une prime grce  ces 4 heures, pas pour son norme boulot de toute l'anne sur les problmatiques techniques qu'il a rsolu avec brio.


Cherchez l'erreur..... Personne n'a chm, tout le monde a mrit, on est deux  chapper  la guillotine grce  une astuce comptable, et une va se faire plomber parce-quelle n'a pas particip  la migration du dbut d'anne. Et mme la quatrime, au final, elle est juge seulement sur son second semestre. a suffit  son bonheur, mais c'est un peu injuste aussi, elle se fait fliciter pour la partie facile de son boulot.

----------


## malreVid

Un pro se pause pas de question un code c'est tous son ensembles  connatre, par la pratique cela vas de soi. C'est donc pour cela que je lui rpondrais un mdiocre n'existe pas en dveloppement . C'est toute la dfinition 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 mdiocre . Mais restons sr de nous dpasser le matre 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.  bientt. :8-):

----------


## TotoParis

Etre trop bon vous fait souvent rejeter de votre quipe : vous mettez trop facilement le doigt sur ce qui marche de travers et a se passe mal.
Et des trucs qui marchent de travers bien, j'en ai hlas trop vu. Si je vous disais ce que je rpare tous les jours dans des fichiers
ou des tables SQL, vous seriez trs tonns. Je ne fais mme plus que a. Sans oublier retrouver des critures comptables
perdues entre 2 applications, sans explication possible...
C'est pourquoi j'aime bien la rgle KISS, a permet aux clients de ne pas trop dysfonctionner. Et ce n'est mme pas du vieux COBOL,
mais un language que je ne pensais pas retrouver depuis les annes 1990...La double peine quoi.

----------

