Trolldi : comment survivre en entreprise tout en étant un développeur médiocre ? Quelques conseils bien pratiques... ou pas 675PARTAGES 40 0 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 ;

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, " Y ou A ren't G onna N eed I t" »

ou ren't onna eed t" » 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 :



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 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 » :« 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 Ê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é ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 35 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Expert confirmé https://www.developpez.com Envoyé par Stéphane le calme Envoyé par Trolldi : comment survivre en entreprise tout en étant un développeur médiocre ?

67 0 Trop facile : passer chef de projet. Membre éclairé https://www.developpez.com 19 0 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... Membre confirmé https://www.developpez.com



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



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



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



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



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



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



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



(ils survivent comme ils peuvent les développeurs médiocres) 15 0 D'autres techniques de survie classiques1/ Noyez les gens dans une apparente complexité. Utilisez un vocabulaire technique et des concepts abstraits face aux clients, chefs de projets.2/ Recréer la roue pour un quelconque motif d'optimisation (qui devra paraître vital pour vous). Refusez toute forme de template ou de librairies, ils ne sont pas adaptés.3/ Investissez vous à fond dans des sujets annexes qui ne requièrent pas le jugement d'un client, par exemple Git, la configuration de l'edi. Créez des architectures techniques et des nomenclatures complexes sur ces domaines. Restez éloignés des sources de jugement : trouvez la niche où vous serez seul.4/ Critiquez le travail des précédants développeurs, c'est à cause de leur programme pourri si vous n'y arrivez pas. La seule bonne façon de réfléchir est la votre.5/ Critiquez l'imprécision de la demande du client : c'est le client qui ne vous a pas dit que la sécurité, les performances et la gestion de la concurence étaient importantes, c'est de sa faute. Vous n'êtes qu'un simple exécutant.6/ Critiquez le mauvais usage des utilisateurs : ils font n'importe quoi, c'est normal que votre programme soit planté. Les gens auraient dû suivre l'indication de la page 42 du manuel ou ce que vous aviez pensé lors du développement.7/ Critiquez le temps qu'on vous a alloué. On vous a demandé de développez facebook en 3 jours, c'est normal que vous ayez pondu une daube inmaintenable, sans doc et qui fonctionne à moitié ; ce n'était pas votre rôle d'expert de dire non ou de definir une cible cohérente avec ce chiffrage.(ils survivent comme ils peuvent les développeurs médiocres) Membre éclairé https://www.developpez.com Trop facile : passer chef de projet. Trop facile : passer chef de projet. 13 0 ou alors scrum master, c'est dans l'air du temps ;-) Membre confirmé https://www.developpez.com 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. 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. 11 0 Ok, un développeur médiocre. Membre averti https://www.developpez.com



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." 13 3 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,fais toi aider." Membre expérimenté https://www.developpez.com Envoyé par anykeyh Envoyé par Ok, un développeur médiocre.



Ou plutôt un développeur humble.

je pense que derrière sa terminologie, il faut comprendre qu'un bon développeur humble, prêt à s'informer, se remettre en cause, sera en fait meilleur qu'un présumé cador. Il ne va pas réinventer la roue, ni bloquer les idées/initiatives des collègues. Il fera plutôt un code plus simple à comprendre et un autre développeur pourra plus facilement reprendre ses projets. 9 0 +1Ou plutôt un développeur humble.je pense que derrière sa terminologie, il faut comprendre qu'un bon développeur humble, prêt à s'informer, se remettre en cause, sera en fait meilleur qu'un présumé cador. Il ne va pas réinventer la roue, ni bloquer les idées/initiatives des collègues. Il fera plutôt un code plus simple à comprendre et un autre développeur pourra plus facilement reprendre ses projets. Expert confirmé https://www.developpez.com Envoyé par defZero Envoyé par Envoyé par Markand Envoyé par 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.

Au hasard version de lib, compilateur, name mangling différent ou ABI/API incompatible avec un "Modern C++" (très bon livre au passage). 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).

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 ! 6 0 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 ! Membre éprouvé https://www.developpez.com 7 2 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. Membre confirmé https://www.developpez.com Êtes-vous un développeur médiocre ? Êtes-vous un développeur médiocre ?



Si oui, comment avez-vous fait pour survivre en entreprise ? Si oui, comment avez-vous fait pour survivre en entreprise ?



avez-vous déjà côtoyé un développeur médiocre et comment l'avez-vous géré ? 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 ? Que pensez-vous des conseils de Pete Shirley ? Pratiques ou loufoques ?



Quels sont ceux qui vous ont le plus marqué ? Quels sont ceux qui vous ont le plus marqué ?



Et ça s'applique pas qu'au code ... 4 0 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...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/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.En dehors de l'aspect trolldi ils sont plutôt cohérent si on oubli l'aspect Fortran et renfermé sur l'acquis."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 ... Poster une réponse Signaler un problème

