Quand quelqu'un serait-il considéré comme un mauvais programmeur?
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 évaluations 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'est pas du tout intéressé à le découvrir.
Un grand signe d'avertissement est s'ils sont un programmeur "culte de la cargaison" - ce qui signifie qu'ils font des choses mais ne savent pas pourquoi ils font ces choses (c'est juste "la magie"). Excellent article d'Eric Lippert ici .
De l'article:
des programmeurs qui comprennent ce que fait le code, mais pas comment il le fait.
Un gros conseil pour moi est lorsqu'ils vous posent, à vous ou aux autres programmeurs, des questions de développement qui montrent clairement qu'ils n'ont fait aucun effort pour le découvrir par eux-mêmes.
Un corollaire est lorsqu'ils posent plusieurs fois la même question de programmation, indiquant qu'ils n'internalisent pas les informations.
Quand cela leur prend beaucoup de temps pour résoudre le problème 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 a dit ci-dessous dans les commentaires)
Une extension de ceci est les personnes qui connaissent un sous-ensemble des fonctionnalités de certaines technologies mais ne montrent aucune envie d'en savoir plus. 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 se déroulent sur The Daily WTF sur une base régulière.
Quand ils savent qu'il existe de meilleures façons de faire les choses, mais refusent toujours de les faire même lorsque le temps le permet.
Personnellement, je pense que tout programmeur qui peut regarder son propre code qu'il a écrit il y a quelque temps et ne pas trouver quelque chose de mal avec lui 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.
Quand j'étais chef d'équipe dans un petit magasin, il y avait plusieurs personnes que je devais réaffecter (ni moi ni mon supérieur direct n'avions de capacité de résiliation sans une tonne de Ruban rouge et une pile de documentation.) ou de ne pas avoir de renouvellement de contrat à la fin de la mission 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 avis. Choses qui ont amené les gens dans la catégorie "Bad Programmer" de mon livre:
- Insensible ou Ossifié dans le passé
Lorsque le "programmeur" ne semble pas être en mesure d'absorber le nouveau système, le nouvel outil ou tout ce qui est déployé, quelle que soit la façon dont la formation/l'éducation est effectuée. Doit répéter cette formation fréquemment.
Lorsque le "programmeur" ne connaît que la technologie ou le paradigme de codage qu'il utilisait il y a 10 ou 15 ans. C'était assez bon alors, alors pourquoi devraient-ils changer? - Codeur Cowboy
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 "parce que nous devons le faire réparer maintenant" et est ensuite surpris lorsque le "correctif" échoue.
Le Cowboy n'est certainement pas non plus un joueur d'équipe. N'a pas besoin d'équipe puante. - La girouette
Ce "programmeur" est amoureux de la "technologie du jour " et voit chaque nouveau cadre, langage, méthodologie ou tout ce qui est nouveau et chaud comme - 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 pour le projet. p. ex. Réécriture d'une bibliothèque standard "parce qu'elle est inefficace pour notre système" ou introduction d'outils et de techniques non adaptés au problème en question. ex. Présentation de LISP ou Forth dans un environnement mainframe. - LOC une. Sandbagger
Ce "programmeur" utilise l'obscurcissement et la mauvaise direction pour augmenter la une. LOC: Lignes de code payées. J'ai vu du code dans cette situation qui était page après page, écran après écran de structure et de logique en double, avec seulement les noms de paragraphe ou de variable de contrôle modifiés pour augmenter le nombre de lignes. - Expert indispensable
Le "programmeur" qui a les connaissances du domaine pour résoudre les problèmes en question, mais puisqu'il "sait" tout à ce sujet. En fait, s'ils devaient être heurtés par un bus, alors toute l'organisation s'écroulerait. { Observation: Ceux qui pensent qu’ils sont indispensables le sont généralement. (Quelqu'un a-t-il eu la source de cet aphorisme?)} - Le chef des pâtes
Ce "programmeur" est spécialisé dans le code spaghetti, épicé avec des identifiants qui sont tout simplement trop difficiles à suivre sans un IDE implémenté syntaxiquement. par exemple IndexI1O0, Index1I0O, etc. - Stagiaire d'été - Sous-type spécifique Walking Disaster
Mon ancien magasin avait l'habitude d'embaucher un certain nombre de stagiaires en fin d'études secondaires ou universitaires. Une fois, un département avait besoin d'une petite base de données pour suivre l'utilisation de certains équipements (maintenant, c'était de retour et il utilisait dBase III). Le gars a codé tout l'été, mais il n'avait pas fini quand l'université a commencé à l'automne. Il a obtenu une prolongation d'une semaine puis une deuxième semaine. À la fin de la deuxième semaine, j'ai été envoyé pour reprendre son projet et le ramener au développement des systèmes pour être terminé. Il m'a montré ce qu'il avait fait, puis la partie inachevée. Ce qui a fonctionné avait un bonbon pour les yeux, mais l'application était incomplet. 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 de pouvoir dire quoi que ce soit, il avait supprimé un tas de fichiers.
. trouver une logique supplémentaire, même si elle est incomplète.
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 a mis un nom, une adresse, un DOB, quelques codes de lettres et un certain type de numéro d'identification. Le format et la mise en page me dérangeaient. Toutes les dates de naissance de plusieurs personnes étaient à peine un âge légal pour boire. La plupart des adresses n'étaient pas là, quand je les ai consultées dans notre annuaire entrecroisé. Quand j'ai montré les imprimés à son superviseur, il m'a regardé et m'a dit "Permis de conduire, vous ne pensez pas?" Je l'ai dit. Il a dit que c'était pourquoi il avait trouvé le stock de transparence coupé à la poubelle à côté du 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. Il était 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
Mis à part le manque évident de connaissances/capacités, un programmeur est mauvais, si son code est plus difficile à lire et/ou à maintenir qu'il ne devrait l'être.
Incapable de s'adapter aux technologies à venir
Quand personne d'autre ne peut lire son code. Peu importe à quel point vous êtes brillant; aucun programmeur n'est une île.
Il y a deux catégories de programmeurs pour moi - solo et équipe.
Les mauvais programmeurs solo sont
- Ceux qui ont mis trop de temps à accomplir la tâche simple.
- Ceux qui ne peuvent pas rechercher par eux-mêmes ce qu'ils font.
- Ceux qui oublieront ce qui a été codé aujourd'hui en quelques jours et ne peuvent pas très bien maintenir 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 se coordonner avec les autres membres de l'équipe.
- Ceux qui n'acceptent pas les critiques.
- Ceux qui ne savent pas comment être utiles aux autres et comment bénéficier des autres membres de l'équipe.
- Ceux qui ne peuvent pas écrire de code lisible.
- Ceux qui ne commentent pas par souci de lisibilité pour les autres.
Quelqu'un qui ne fait pas attention aux détails et qui est toujours en mode "ça marche, donc je le laisse tranquille. Toutes ces exceptions dans les journaux n'ont pas d'importance".
Un grand signe d'avertissement dans mon expérience, c'est quand ils ne commentent pas leurs hacks ....
Vous savez ce que je veux dire: quand vous êtes forcé de faire quelque chose de très hacky parce qu'il n'y a tout simplement pas de meilleure façon de le faire.
Les bons programmeurs détesteront devoir le faire et mettront des commentaires en ligne indiquant combien ils détestent mettre ce genre de piratage, mais il n'y a pas le choix. Les mauvais programmeurs vont juste mettre le hack et ne pas le commenter.
Ne voulant pas admettre qu'ils ne connaissent pas la réponse et/ou refusant de rechercher les choses.
Si vous ne le savez pas, n'abandonnez pas - comprenez-le et faites-le.
En étant reproduit, on a montré la manière à droite de le faire, et à plusieurs reprises de le faire simplement.
Calme évidemment quand un programmeur écrit BEAUCOUP de code. Très grandes fonctions, peut-être copier/coller des lignes ou des blocs de code, en utilisant beaucoup plus si nécessaire, etc. Cela pourrait être dû au fait que le programmeur ne connaît pas une fonction standard pour faire ce qu'il veut mais la plupart du temps ce n'est pas le cas.
Je déplace ma réponse ici à partir d'un sujet en double fermé qui demandait Pouvez-vous reconnaître si vous êtes un mauvais programmeur? L'autre sujet était fermé pendant que je composais ma réponse. Ma réponse répond plus directement à la question telle qu'elle a été formulée par l'autre demandeur et se lira mieux si vous comprenez cela.
Soupir! Une partie de moi ne voulait pas ajouter à ce sujet déjà chargé, mais l'autre partie a gagné! Pourquoi at-il gagné? Pourquoi est-ce que je me donne la peine d'ajouter encore plus de mots à ce Multilogue particulier? Eh bien, parce que, dans une certaine mesure, j'ai peut-être une vision légèrement différente de celle des nombreux commentateurs précédents.
Le binaire fonctionne très bien dans les ordinateurs: c'est "1" ou "0", "on" ou "off". Nous pouvons résumer et encoder beaucoup d'informations en utilisant ces deux fameux états. Mais, cela n'a pas tendance à fonctionner aussi bien pour les questions humaines: "bon" ou "mauvais", "sain" ou "fou", "bon" ou "mal", "intelligent" ou "stupide", "gras" ou "maigre", "vivant" ou "mort?" Ce genre d'évaluations polarisées a toujours laissé l'être humain attentionné terriblement insatisfait. Quels que soient les schémas de mesure que je choisis d'appliquer, je trouve généralement que les réponses à de tels contrastes frappants se situent en fait quelque part le long d'un continuum entre l'un de ces pôles et l'autre, pas à l'une ou l'autre extrémité.
Je lutte contre cette tendance à la polarisation depuis un certain temps maintenant et ma solution personnelle est que je trouve 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 demander ceci: "Dans quelle mesure suis-je un mauvais programmeur?" Ou, mieux encore, de le demander dans l'autre sens: "Dans quelle mesure suis-je un bon programmeur?" Si vous poursuivez la vérité, vous vous situerez probablement quelque part le long d'un continuum entre être un "mauvais" programmeur et un "bon". Ensuite, une fois que vous avez réussi à localiser approximativement où vous vous trouvez le long de ce chemin, vous pouvez probablement identifier un point un peu plus proche de la "bonne" extrémité - un point où vous aimeriez vous retrouver dans un avenir proche.
Si vous ne placez pas ce point trop loin, vous pouvez probablement mettre votre arrière-train en prise 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 bientôt trop occupé à programmer pour avoir à vous poser à nouveau cette question! Oh, et vous progresserez probablement plus rapidement si vous commencez à taper du code sur un clavier aussi rapidement et souvent que possible; et, si vous faites une petite pause de temps en temps, lisez du code de haute qualité écrit par vos pairs! En ces jours de développement dynamique Open Source, vous ne manquez pas de code gratuit et exquis à apprendre!
Donc, je vous recommande fortement d'essayer mes trois petits mots, "dans quelle mesure", et de voir jusqu'où ils peuvent vous mener!
Ceux qui ne connaissent pas des principes tels que SOLID, DRY, OOP et ainsi de suite. Il est important d'avoir une bonne compréhension des principes de programmation et des fondations plutôt que de connaître des technologies spécifiques. Ceux qui ont des fondations solides seront capable d'apprendre de nouveaux sujets facilement et produira un meilleur code.
Une chose qui distingue un mauvais programmeur d'un programmeur débutant est l'insistance obstinée à implémenter son système préféré dans la langue et l'API dans lesquelles il travaille.
J'ai hérité une fois d'un système où le développeur précédent a réimplémenté (en Java) un grand ensemble de l'API Ashton Tate DBase III + en couches au-dessus de la bibliothèque d'accès dbf personnalisée. Aucun cadre de collections Java Java n'a été utilisé.
C'était pour qu'il puisse écrire une application Java/swing qui ressemblait et agissait comme une application DBase III + (ou éventuellement clipper).
Les applications qu'il a écrites dans ce système avaient des menus lite-bar et ouvraient un formulaire de fenêtre complète avec une rangée de boutons en bas lorsque vous naviguiez dans la lite-bar jusqu'à l'option. C'était comme une petite machine à remonter le temps dans les années 80.
L'homme était clairement un développeur qualifié. Il savait suffisamment qu'il était capable d'écrire tout ce système lui-même dans le délai de ce projet. Il a également pu le réutiliser sur quelques autres systèmes internes.
Mais il était un horrible programmeur dans la mesure où son code a mal utilisé les fonctionnalités des systèmes sur lesquels il a travaillé. Il était plus disposé à passer 3 mois sur une bibliothèque personnalisée d'avantages douteux que d'apprendre Java/Swing/SQL.
Quelqu'un qui dit "Ça ne peut pas être fait".
À mon avis, il s'agit de résoudre des problèmes, l'outil devrait être beaucoup moins pertinent que de faire le travail. 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 "ça ne peut pas être fait"
Un signe d'avertissement est trop centré sur la manière académique et "correcte" de faire les choses, et pas assez sur la réalisation du travail.
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 pontification mais produisent très peu.
Un programmeur intégré qui ne comprend pas très bien les interruptions ou le multitâche. Également des programmeurs qui ont besoin de travailler avec des champs de bits mais qui ne saisissent pas les opérations logiques et les décalages.
Un signal de reconnaissance immédiat est que quelqu'un dit: "Je ne comprends pas pourquoi cela ne fonctionne pas. J'ai tout fait correctement."
! (intelligent et fait avancer les choses)
Aujourd'hui, de nombreux programmeurs pensent que cette complexité est mieux gérée en utilisant uniquement un petit ensemble de techniques bien comprises dans leurs programmes. Ils ont composé des règles strictes sur la forme que les programmes devraient avoir, et les plus zélés d'entre eux dénonceront ceux qui enfreignent ces règles comme de mauvais programmeurs
Un programmeur qui ne fait que copier et coller du code depuis d'autres endroits, et ne comprend pas comment le code fonctionne réellement, est connu comme un mauvais programmeur! Je vois généralement cela avec javascript.
Je pense que la seule façon dont un programmeur peut être mauvais en programmation est de cesser d'écouter ce que les autres ont à dire.
La programmation concerne l'information. Il faut garder les oreilles et les yeux grands ouverts.
Un programmeur ne peut s'améliorer qu'en frappant les livres et en travaillant dur. Mais, vous devez également vous concentrer sur l'apprentissage de nouvelles choses, et non sur l'apprentissage constant (recherchez de nouvelles expériences dans votre domaine/industrie spécifique).
Bonne chance.