Quand quelqu'un serait-il considéré comme un mauvais programmeur? [fermé]

Comment considéreriez-vous qu'un programmeur est mauvais dans ce qu'il fait?

Si possible ... Comment devrait-il s'améliorer?

Quand ils ne parviennent pas à apprendre de leurs erreurs et des examens par les pairs.

Nous sommes tous verts à un moment donné; Cependant, si vous ne vous améliorez pas ou n'essayez pas de vous améliorer, vous êtes un mauvais programmeur.

Un programmeur qui ne sait pas ce qu'il ne sait pas et qui n'a aucun intérêt à le savoir.

Un gros signe d'avertissement est s'il s'agit d'un programmeur "culte de la cargaison" - ce qui signifie qu'il fait des choses mais ne sait pas pourquoi il fait ces choses (c'est juste "magique"). Excellent article d'Eric Lippert ici .

De l'article:

les programmeurs qui comprennent ce que le code fait, mais pas comment il le fait.

Un gros problème pour moi, c’est quand ils vous posent, à vous ou aux autres programmeurs, des questions de développement qui montrent clairement qu’ils n’ont fait aucun effort pour s’en sortir par eux-mêmes.

Un corollaire est quand ils posent la même question de programmation plusieurs fois en indiquant qu'ils ne sont pas en train d'intérioriser les informations.

Quand cela leur prend beaucoup de temps pour résoudre le problème de FizzBuzz.

Les programmeurs qui refusent d'apprendre de nouvelles technologies / langages et insistent pour s'en tenir à ce qu'ils savent déjà.

Addendum: (en ajoutant ce que le tiret dit ci-dessous dans les commentaires)

Une extension de cela concerne les personnes qui connaissent un sous-ensemble des fonctionnalités de certaines technologies mais ne souhaitent pas en apprendre davantage. Langage de programmation, éditeur, autres outils ...

Lorsqu'un membre de l'équipe est le développeur producteur négatif .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Cela signifie que le reste de votre équipe doit faire plus de travail à cause du mauvais développeur. NNPP

Quand ils produisent des choses qui font partie du Daily WTF de façon régulière.

Quand ils savent qu'il y a de meilleures façons de faire les choses mais refusent quand même de les faire même quand le temps le permet.

Personnellement, je pense que tout programmeur qui peut consulter son propre code qu’il a écrit il ya un moment et ne pas trouver quelque chose qui ne va pas avec, n’est pas bon. "Un certain temps" peut évoluer avec l'expérience ... Je dirais entre quelques semaines et un an environ.

Ceux qui ignorent les avertissements sur leurs codes et ne se soucient que des erreurs.

Lorsque j'étais chef d'équipe dans un petit magasin, il fallait que plusieurs personnes me réassignent (ni moi ni mon supérieur hiérarchique direct ne disposions d'une capacité de résiliation sans une tonne de paperasserie et une pile de documents.) Ou de ne pas renouveler mon contrat. à la fin de l'engagement en cours. Certains des types énumérés ont également fonctionné pour d'autres chefs d'équipe, et ils ont à peu près le même point de vue. Ce qui a amené des gens dans la catégorie "Mauvais programmeur" de mon livre:

1. Incalculable ou inexplicable dans le passé
   Lorsque le «programmeur» ne semble pas être en mesure d'absorber le nouveau système, le nouvel outil ou ce qui est en train d'être déployé, quelle que soit la manière dont la formation / l'éducation est effectuée. Doit répéter cette formation fréquemment.
   Quand le «programmeur» ne connaît que la technologie ou le paradigme de codage qu’il utilisait il ya 10 ou 15 ans. C'était assez bon alors, alors pourquoi devraient-ils changer?
2. Cowboy coder
   La personne qui code en premier, sans plan. Le "programmeur" qui apporte des modifications non testées au code de production et / ou aux données "car nous devons le réparer maintenant" et est ensuite surpris lorsque le "correctif" échoue.
   Le cow-boy n’est pas non plus un joueur d’équipe. N'a pas besoin d'aucune équipe puante.
3. La girouette-
   Ce « programmeur » est tombé amoureux de la « technologie du jour » et voit tout nouveau cadre, la langue, la méthodologie ou tout ce qui est nouveau et chaud comme
4. Le "gros cerveau"
   Ce "programmeur" est tellement sûr de son talent et de ses capacités que des choses sont faites qui n'ont pas beaucoup de sens de projet. Par exemple, réécrire une bibliothèque standard "car elle est inefficace pour notre système" ou introduire des outils et des techniques ne convenant pas au problème à résoudre. Par exemple, introduire Lisp ou Forth dans un environnement mainframe.
5. LOC ^a. Sandbagger
   Ce "programmeur" utilise l'obscurcissement et la mauvaise direction pour augmenter le ^a. LOC: Lignes de code payées. J'ai vu du code dans cette situation, page par page, écran après écran de la structure et de la logique en double, avec uniquement le nom des variables de paragraphe ou de contrôle modifiées pour augmenter le nombre de lignes.
6. Indispensable Expert
   Le «programmeur» qui possède la connaissance du domaine pour résoudre les problèmes actuels, mais qui «sait» tout sur le sujet. En fait, s’ils devaient être renversés par un bus, l’ensemble de l’organisation s'effondrerait. { Observation: Ceux qui pensent qu’ils sont indispensables le sont généralement. (Quelqu'un a la source de cet aphorisme?)}
7. The Pasta Chef
   Ce 'programmeur' est spécialisé dans le code spaghetti, agrémenté d'identifiants trop difficiles à suivre sans IDE implémenté dans la syntaxe. par exemple, IndexI1O0, Index1I0O, etc.
8. Stagiaire d'été - Sous-type spécifique Walking Disaster
   Mon ancien magasin embauchait un certain nombre de stagiaires en fin de lycée ou d'université. Une fois, un ministère avait besoin d’une petite base de données pour suivre l’utilisation de certains équipements (elle utilisait maintenant dBase III). Le gars a codé tout l'été, mais cela n'a pas été fait quand l'université a commencé à l'automne. Il a eu une prolongation d'une semaine puis une deuxième semaine. À la fin de la deuxième semaine, je fus envoyé pour reprendre son projet et le ramener au développement de systèmes pour qu'il soit terminé. Il m'a montré ce qu'il avait fait, puis la partie inachevée. Ce qui a fonctionné avait bon goût des yeux, mais l'application étaitincomplet. Lorsque j'ai ouvert la nouvelle boîte de disquettes formatées pour obtenir des copies, il a dit "juste une seconde, laissez-moi supprimer mes fichiers de test ..." et avant que je puisse dire quoi que ce soit, il avait supprimé un tas de fichiers.
   En tant que type suspect, et trouvant que sa demande n'était presque rien d'autre que des bonbons à l'œil quand je suis rentré dans mon magasin, je suis retourné au département et ai sorti Norton et ai effacé les fichiers qu'il avait supprimés, en essayant de trouver une logique supplémentaire, même si incomplet.
   J'ai trouvé, pas une mauvaise logique, mais un mauvais comportement. L’imprimante connectée au PC qu’il utilisait était une imprimante à marguerite. Le jeu de caractères normalement monté était une variante suisse. La sortie des programmes supprimés donne un nom, une adresse, une date de naissance, des codes de lettre et un type de numéro d'identification. Le format et la mise en page m'ont dérangé. Toutes les dates de naissance de plusieurs personnes étaient à peine en âge de boire. La plupart des adresses n'étaient pas là, quand je les ai trouvées dans notre annuaire croisé. Quand j'ai montré les impressions à son superviseur, il m'a regardé et m'a dit: "Permis de conduire, tu ne trouves pas?" J'ai dit que je l'avais fait. Il a expliqué que c’était la raison pour laquelle il avait trouvé la pellicule transparente coupée à la poubelle près de la Xerox. Notre mauvais garçon avait fait des superpositions pour ajuster son âge et celui de ses amis sur leurs permis de conduire. Nous l'avons signalé aux autorités.pas payé pour ses deux dernières semaines.

Ce ne sont que quelques-uns des mauvais personnages avec lesquels j'ai dû travailler ....

/ s / BezantSoft

Incapable de s'adapter aux technologies à venir

Mis à part le manque évident de connaissances / capacités, un programmeur est un mauvais programmeur si son code est plus difficile à lire et / ou à maintenir qu'il ne devrait l'être.

Quand personne d'autre ne peut lire son code. Peu importe à quel point vous êtes brillant. aucun programmeur n'est une île.

Quelqu'un qui ne fait pas attention aux détails et qui est toujours dans le mode "ça marche, alors je le laisse tranquille. Toutes les exceptions dans les journaux n'importent pas" en mode.

Pour moi, il y a deux catégories de programmeurs: solo et équipe.

Les mauvais programmeurs solo sont

• Ceux qui ont pris trop de temps pour faire la tâche simple.
• Ceux qui ne peuvent pas rechercher par eux-mêmes ce qu'ils font.
• Ceux qui vont oublier ce qui a été codé aujourd'hui dans quelques jours et ne peuvent pas très bien conserver leur propre base de code.
• Ceux qui ne peuvent pas s'adapter aux exigences changent.

Les mauvais programmeurs d’équipe sont ceux qui tombent dans la catégorie des mauvais programmeurs solo, y compris

• Ceux qui ne peuvent pas coordonner avec d'autres membres de l'équipe.
• Ceux qui n'apprécient pas les critiques.
• Ceux qui ne savent pas être utiles aux autres et comment tirer profit des autres membres de l'équipe.
• Ceux qui ne peuvent pas écrire du code lisible.
• Ceux qui ne commentent pas par souci de lisibilité pour les autres.

Pas disposés à admettre qu'ils ne connaissent pas la réponse et / ou pas disposés à faire des recherches.

Si vous ne le savez pas, n'abandonnez pas - réfléchissez-y et faites-le.

D'après mon expérience, un gros signe d'avertissement est quand ils ne commentent pas leurs hacks ...

Vous savez ce que je veux dire: quand vous êtes obligé de faire quelque chose de très difficile parce qu'il n'y a tout simplement pas de meilleure façon de le faire.

Les bons programmeurs détesteront le devoir de le faire et ajouteront des commentaires en ligne expliquant à quel point ils détestent utiliser ce genre de bidouille, mais ils n’ont pas le choix. Les mauvais programmeurs vont juste mettre le bidouillage et ne pas commenter.

Calme évidemment lorsqu'un programmeur écrit BEAUCOUP de code. De très grandes fonctions, peut-être copier / coller des lignes ou des blocs de code, en utilisant beaucoup plus si nécessaire, etc. Cela peut être dû au fait que le programmeur ne connait pas une fonction standard pour faire ce qu'il veut, mais ce n'est pas le cas la plupart du temps.

Être réprouvé montre la bonne façon de le faire et le fais toujours de manière facile.

Je déplace ma réponse ici à partir d'un sujet en double fermé qui a demandé Pouvez-vous reconnaître si vous êtes un mauvais programmeur? L’autre sujet était en cours de fermeture alors que je composais ma réponse. Ma réponse aborde plus directement la question telle qu'elle a été formulée par l'autre demandeur et lira mieux si vous comprenez cela.

Soupir! Une partie de moi n'a pas voulu ajouter quelque chose à ce sujet déjà très chargé, mais l'autre a gagné! Pourquoi a-t-il gagné? pourquoi suis-je dérangé d'ajouter encore des mots à ce multilingue? Eh bien, parce que, dans une certaine mesure, mon opinion est peut-être légèrement différente de celle de nombreux commentateurs précédents.

Le binaire fonctionne très bien dans les ordinateurs: c'est '1' ou '0', "on" ou "off". Nous pouvons extraire et encoder beaucoup d'informations en utilisant ces deux états célèbres. Mais, cela ne marche pas aussi bien pour les affaires humaines: "bon" ou "mauvais", "sain" ou "fou", "bon" ou "mal", "intelligent" ou "stupide", "gras" ou "mince", "vivant" ou "mort?" Ce genre d’évaluations polarisées a toujours laissé l’être humain soucieux de ma part terriblement insatisfait. Quels que soient les schémas de mesure que je choisis d’appliquer, je trouve généralement que les réponses à ces contrastes aussi extrêmes se situent quelque part dans un continuum entre un tel pôle et l’autre, et non à l’une ou l’autre des extrémités.

Je lutte depuis un certain temps déjà avec cette tendance à la polarisation, et ma solution personnelle est qu’il me semble beaucoup plus utile d’appliquer trois mots à une telle évaluation: " dans quelle mesure!"

Donc, ma réponse à votre question est de vous suggérer de la reformuler et de vous poser la question suivante: "Dans quelle mesure suis-je un mauvais programmeur?" Ou encore mieux, demandez-le dans l'autre sens: "Dans quelle mesure suis-je un bon programmeur?" Si vous recherchez la vérité, vous vous situerez probablement quelque part dans un continuum entre être un "mauvais" programmeur et un "bon" programmeur. Ensuite, une fois que vous parvenez à vous situer approximativement sur ce chemin, vous pouvez probablement identifier un point un peu plus proche de la "bonne" fin - un point où vous souhaiteriez vous retrouver dans un proche avenir.

Si vous ne définissez pas ce point trop loin, vous pouvez probablement passer à l’arrière-train et commencer à le déplacer dans cette direction. Si vous parvenez à répéter plusieurs fois cet algorithme heuristique assez simple, vous risquez de vous retrouver trop occupé à programmer pour avoir à poser à nouveau cette question! Oh, et vous ferez probablement des progrès plus rapides si vous commencez à marteler du code sur un clavier aussi rapidement et aussi souvent que vous le pouvez; et, si vous faites une petite pause de temps en temps, lisez un code de haute qualité écrit par vos pairs! En ces jours de développement Open Source dynamique, vous ne manquerez pas de code gratuit et exquis pour apprendre!

Donc, je vous recommande fortement d'essayer mes trois petits mots, "dans quelle mesure", et de voir jusqu'où ils peuvent vous mener!

Quelqu'un qui dit "ça ne peut pas être fait".

À mon avis, tout est une question de résolution de problème, l'outil devrait être beaucoup moins pertinent que de travailler réellement. Si je dois le résoudre en utilisant MS-Access ou un langage d'assemblage, c'est une question de temps et d'argent, pas une question de "Cela ne peut pas être fait"

Un signal d’avertissement est une focalisation excessive sur la manière académique et "correcte" de faire les choses, et pas assez sur le travail effectué.

S'il ne connaît que la syntaxe d'un langage mais ne connaît pas les concepts de base des algorithmes.

Quand ils font beaucoup de pontificats mais produisent très peu.

! (intelligent et fait avancer les choses)

Ceux qui ne connaissent pas les principes tels que SOLID, DRY, OOP, etc. Il est important de bien comprendre les principes de la programmation et les fondements plutôt que de connaître des technologies spécifiques. Ceux qui ont une base solide pourront apprendre de nouveaux sujets facilement et produiront un meilleur code.

Un programmeur intégré qui ne comprend pas très bien les interruptions ou le multitâche. Aussi les programmeurs qui doivent travailler avec des champs de bits mais ne saisissent pas les opérations logiques sur eux et le décalage.

Un signal de reconnaissance immédiat est que quelqu'un dit: "Je ne comprends pas pourquoi cela ne fonctionne pas. J'ai tout bien fait."

Une chose qui distingue un mauvais programmeur d’un programmeur débutant est son insistance obstinée à mettre en œuvre son système favori dans le langage et l’API dans lesquels ils travaillent.

Une fois, j’ai hérité d’un système dans lequel le développeur précédent avait ré-implémenté (en Java) un grand ensemble de l’API Ashton Tate DBase III + superposée à la bibliothèque d’accès dbf personnalisée. Aucune des infrastructures de collections Java n'a été utilisée.

C'était pour qu'il puisse écrire une application Java / swing qui ressemblait à une application DBase III + (ou éventuellement une clipper).

Les applications qu’il a écrites dans ce système comportaient des menus à barres lites et ouvraient un formulaire pleine fenêtre avec une rangée de boutons en bas lorsque vous sélectionniez l’option à barres lite. C'était comme une petite machine à remonter le temps dans les années 1980.

L’homme était clairement un développeur habile. Il en savait assez qu'il était capable d'écrire tout ce système lui-même dans les délais impartis pour ce projet. Il a également pu le réutiliser sur quelques autres systèmes internes.

Mais il était un programmeur horrible en ce sens que son code utilisait mal les fonctionnalités des systèmes sur lesquels il travaillait. Il était plus disposé à passer 3 mois sur une bibliothèque personnalisée d'avantages douteux que d'apprendre Java / Swing / SQL.