Quelles sont les erreurs les plus communément commises par de nouveaux programmeurs ? Et comment les éviter ?

[Katleen Erna]

Quelles sont les erreurs les plus communément commises par de nouveaux programmeurs ? Et comment les éviter ?

La situation est assez fréquente. Une entreprise, un service informatique...et un petit nouveau qui arrive. Le jeune développeur a évidemment beaucoup moins d'expérience que ses aînés, ce qui peut l'amener à commettre certaines erreurs. Parfois, les "anciens" remarquent que les "nouveaux" font toujours le même type d'erreurs. Aussi, il serait bon de connaître les manquements les plus fréquents, afin de pouvoir les éviter.

Alors, selon vous et votre expérience, quelle est l'erreur la plus communément commise par une toute fraîche recrue ?

Voici déjà une liste de suggestions. Libre à vous d'en rajouter d'autres :

- Ne pas demander d'aide. Souvent, par manque de courage ou au contraire par excès de confiance en soit.

- Passivité en cas de problème récurrent.

- Incapacité d'estimer le temps nécessaire à l'accomplissement d'une tâche. Variante : promettre de terminer un travail en deux semaines, lorsque l'on sait pertinemment qu'il en demandera trois.

- Ne pas suivre les standards de l'équipe.

- Écrire du code trop compliqué pour crâner

- Dévier de l'architecture prévue sans prévenir

Avez-vous souvent été confrontés à ce type de comportements ? En avez-vous relevé d'autres ?

Comment éviter ces erreurs ?

[Le_Phasme]

Celle qui m'a sauté aux yeux alors qu'elle n'est pas dans les réponses tout de suite en lisant la question :
> Rester bloqué pendant 1/2 journée devant un problème et ne pas savoir comment faire pour aborder le sujet avec un collègue

[deadalnix]

Je suis étonné de voir ce qui moi me saute aux yeux : la conception et les bonnes pratiques.

Design pattern ? MVC ? Abstraction ? metaprogrammation (a non, ça c'est tellement ouf que les langages modernes tronquent) ?

[metagoto]

Je trouve que les nouveaux programmeurs manquent d'expérience

[mon_nom_est_personne]

pour ma part j'ai surtout remarque le cote faire du compliquer pour ce faire remarquer. Du genre développer dans un langage obscure en version alpha qui est aussi stable qu'un flanc. Et aussi l'oublie systematique de commentaires et de nom de variables explicitent.

Code :

1
2
3
4
5
6
7
a = 0;
b = c;
//test
if(a == 2 && c == a){
print "ok";
}

j'ai toujours envie de mettre des claques !

[iberserk]

Clairement rester bloquer 1/2 jours sur un problème sans rien demander à personne de peur de se faire mal voir... bien dommageable (au bout de 2 jours, l'équipe n'a cependant pas fait son boulot, un minimum de suivi est nécessaire...

Ce qui me choque surtout est le niveau vraiment ridicule en SQL des BAC+5...

[naholyr]

Mes réponses vont fortement varier en fonction de l'individu, en tous cas surtout en fonction de son emplacement sur la ligne "timide ... extraverti" Les mots "timide" et "extraverti" ne sont peut-être pas totalement représentatifs, mais je vais préciser ma pensée.

L'"extraverti" aura la plupart du temps tous les défauts cités, puisqu'il est trop fort pour avoir besoin d'aide, trop fort pour suivre des standards pourris (les siens sont mieux), trop fort pour avoir besoin de mettre des commentaires, etc...
Comment le détecter ? C'est celui qui va remettre souvent les choix en question, et avoir tendance à déclarer que tout est pourri (en gros, à part ce qu'il a développé lui-même à 14 ans, tout est de la merde). Avec le temps ça deviendra un excellent élément, un dév d'élite, mais il faut qu'il se prenne quelques claques avant Il est impératif de bien le surveiller car il va développer vite, mais sera incapable de tenir sur le long terme (ignorer tel ou tel bug car "pas intéressant" par exemple, ce qui forcément complique la maintenance), et l'existence d'un "responsable qualité" du projet est indispensable pour cadrer ce type de débutant trop sûr de lui.
L'égo surdimensionné est un problème classique pour le programmeur, nous devons toujours lutter contre...

Le "timide" lui en revanche n'a pas ce problème d'égo, mais parce qu'il n'ose pas déranger ne va jamais communiquer. Ça c'est un problème commun à tous les débutants à mon avis, l'absence de communication pour une raison ou pour une autre (soit parce qu'il sait mieux que les autres, soit parce qu'il ne veut pas déranger, soit parce qu'il a peur de poser des questions con, dans tous les cas c'est une composante commune je crois).
Pour éviter ce travers il est indispensable de prendre les devants en :
* Rédigeant des documents de conseil, conception technique, standards de qualité, etc...
* Allant régulièrement le voir pour vérifier son avancement et vérifier qu'il ne reste pas bloqué sur un problème à la con.
* Le rassurer, lui répéter qu'il ne doit pas avoir peur de poser des questions vraiment stupides, et ne pas l'enfoncer quand on lui parle d'un point technique et qu'il ne semble pas comprendre : "ah oui désolé, c'est normal que tu ne saches pas si je ne t'en ai pas parlé avant, tiens vas voir par là tu auras de la doc sur ce point...".


Un problème sous-jacent qui n'est pas posé ici : les programmeurs non débutants ont aussi souvent les mêmes défauts (ne pas poser de question, dériver sans prévenir, rester bloqué sur un problème), donc je ne suis pas sûr que ces défauts soient un problème d'expérience. La seule différence *devrait être* (parce qu'hélas ça n'est pas toujours le cas, je suis bien placé pour savoir qu'on a beau savoir qu'il ne faut pas rester 1/2 journée sur le même problème sans avancer, on le fait parfois quand-même quand on est pris dans le feu de l'action) que le programmeur expérimenté saura prendre du recul et s'arrêter pour s'auto-juger et détecter ses erreurs de comportement afin de les corriger.

L'auto-repair c'est un truc long à acquérir


Bref, ce n'est que mon très humble avis, que je pense très caricatural, mais j'espère qu'il permettra de poser les bases d'un débat intéressant avant que la discussion ne dérive en défouloir anti-noobs

[smehdi21]

Bonjour.
etant un programmeur débutant, je dirai que le probléme majeur, c'est de vouloir faire vite pour ne pas etre à la traine de ses collegues et impressioner ses superieurs par sa rapidité, et finalement je me retrouver avec du code pourri que j'arrive pas à maintenir.
aussi un autre point c'est de ne pas savoir prevoir le tps necessaire à telle ou telle tache ...

[nasty]

Je rejoins smehdi21
C'est vrai qu'en tant que jeune développeur, on cherche a faire bien et si on le fait tout seul c'est mieux, mais je me rappelle avoir passé quelques heures sur des problèmes bidons.
Et je pense que connaitre les erreurs des anciens jeunes développeurs peut aider les nouveaux jeunes développeurs, en les évitant!
Cordialement
Nasty

[galel]

Envoyé par metagoto

Je trouve que les nouveaux programmeurs manquent d'expérience

hihi

[Louis Griffont]

Pour moi, la plupart des soucis viennent de l'intégration du "nouveau" dans l'équipe. Et n'est pas forcément du au "nouveau" justement !

Je pense que beaucoup d'entreprise minimise l'impact de l'arrivée d'un "nouveau" sur l'équipe en place (certains vont se sentir en danger, d'autres se sentir minimiser, ...) et cela peut créer une hostilité, un ressenti vis à vis du "nouveau" qui aura déjà pas mal de stress en arrivant.

J'ai mis "nouveau" entre guillemets car je pense que l'on retrouve les mêmes problèmes que le "nouveau" soit sans expérience ou que ce soit un "confirmé". Je pense que la préparation de l'équipe est primordiale pour que tout se passe bien. Plus le "nouveau" se sentira bien accueilli, plus rapide sera son adaptation. Maintenant, il est important de vite cerné la personnalité du nouvel arrivant "grande gueule", "timide", "je sais tout et mieux que tout le monde", "pourvu que je ne fasse pas de conneries", ... Bref, quelle que soit la personnalité du "nouveau" il me semble impératif de bien l'encadrer et de le mettre en confiance.

[dams78]

Envoyé par metagoto

Je trouve que les nouveaux programmeurs manquent d'expérience

Tu crois?

Un des problème peut aussi venir du manager, c'est la moindre des choses quand on prend un débutant (pour le payer pas cher) de l'encadrer un minimum. Et ça coûte rien de passer devant son bureau pour lui demander si tout va bien, et de lui proposer de travailler avec tel ou tel développeur "ancien".

[badthings]

@naholyr:

Je suis désolé, mais je ne suis pas du tout d'accord avec vous.
Il n'y a qu'à prendre la définition du mot extraverti.
Je pense être extraverti, mais pas imbu de moi-même ni egocentrique.
Au contraire, je sous-évalue constamment mes capacités et de par mon coté extraverti je n'ai pas peur d'aller demander de l'aide, même sur un problème débile qui me ferait passer pour un imbécile.

Je pars du principe que je préfère passer pour un imbécile et me débloquer de mon problème rapidement, que rester coincer 1 journée sur un truc sans être sûr de pouvoir le résoudre, ou à défaut le pallier.


Sinon, mon problème principal en tant que débutant est effectivement de mal gérer le temps pour finir un truc (mais je suis dans l'autre optique, je préfère prendre du temps, mais le faire bien, propre et commenté)
Je pense toujours à ceux qui reliront mon code d'ailleurs en adaptant une citation de Donal Knuth :
" Pensez au lecteur pour qui, de toute façon, c'est une corvée de vous lire"

Bref, je suis extraverti, et je ne pense pas faire le meilleur code (pour être le plus lisible, voir trop...), je ne codais pas à 14 ans, si j'ai un problème sans réponse au bout d'1h, je demande.
Quand aux choix qu'on me propose, si aucune argumentation (solide, compréhensible ou réaliste) n'est derrière et que mon intuition me dit que la simplicité serait de faire autrement, alors oui je remets les choix en questions.

[bubulemaster]

Envoyé par metagoto

Je trouve que les nouveaux programmeurs manquent d'expérience

C'est pour ça qu'ils sont nouveaux

Ceci dit, j'ai travaillé avec des gens d'expérience qui programmait moins bien que des débutants.

Moi ce qui m'embête c'est :

Incapacité d'estimer le temps nécessaire à l'accomplissement d'une tâche

Personne n'est capable d'estimer le temps car il y a toujours, quelque chose qui nous tombe dessus sans prévenir.
C'est juste que les gens d'expérience estime mieux si tout va bien que les gens sans expérience. Mais, le problème, c'est qu'ils surestime souvent leur capacité. du coup, ils sont dans les temps, mais le travail est pas terrible.

Ce qui est vraiement gênant c'est :

Ne pas suivre les standards de l'équipe

[tontonnux]

Envoyé par Louis Griffont

Pour moi, la plupart des soucis viennent de l'intégration du "nouveau" dans l'équipe. Et n'est pas forcément du au "nouveau" justement !

Je pense que beaucoup d'entreprise minimise l'impact de l'arrivée d'un "nouveau" sur l'équipe en place (certains vont se sentir en danger, d'autres se sentir minimiser, ...) et cela peut créer une hostilité, un ressenti vis à vis du "nouveau" qui aura déjà pas mal de stress en arrivant...

+1

[Lyche]

Envoyé par iberserk

Ce qui me choque surtout est le niveau vraiment ridicule en SQL des BAC+5...

Et moi donc, quand tu vois que sur les chat du forum, des types qui ont des master, des MBA en dev viennent se faire corriger des requêtes

Code sql :

1
2
3
 
SELECT *
FROM maTable

qu'ils ne savent pas indenter leur code qu'ils ne savent pas faire des jointures normées et qu'ils demandent qu'on les aident (voir qu'on leur fasse le boulot) pour leur entreprise. Y'a de quoi se poser des questions
1 - sur les formateurs
2 - sur les correcteurs
3 - sur le développeur qui n'a jamais essayer d'apprendre des choses par lui même.

Quand on voit que certaines personnes (je parle d'expérience) sortent d'un double cursus bac + 5 (en développement) et qu'ils ne connaissent même pas le CSS moi ça me fait peur pour les futurs générations..

Comment peut-on donner un diplôme à quelqu'un qui n'a même pas la logique de développement, qui ne s'est même pas tenu informé des normes SQL (ou autres normes de langages) qui quand tu lui parles de typage de langage te regarde avec des yeux de grenouille l'air de dire "de quoi tu me parles là?" Quand tu utilises le mot "code Behind" ne comprend pas ce que tu dis.. Bref, je suis ulcéré par les niveau des jeunes diplomés.

Envoyé par Louis Griffont

Pour moi, la plupart des soucis viennent de l'intégration du "nouveau" dans l'équipe. Et n'est pas forcément du au "nouveau" justement !

Je pense que beaucoup d'entreprise minimise l'impact de l'arrivée d'un "nouveau" sur l'équipe en place (certains vont se sentir en danger, d'autres se sentir minimiser, ...) et cela peut créer une hostilité, un ressenti vis à vis du "nouveau" qui aura déjà pas mal de stress en arrivant.

J'ai mis "nouveau" entre guillemets car je pense que l'on retrouve les mêmes problèmes que le "nouveau" soit sans expérience ou que ce soit un "confirmé". Je pense que la préparation de l'équipe est primordiale pour que tout se passe bien. Plus le "nouveau" se sentira bien accueilli, plus rapide sera son adaptation. Maintenant, il est important de vite cerné la personnalité du nouvel arrivant "grande gueule", "timide", "je sais tout et mieux que tout le monde", "pourvu que je ne fasse pas de conneries", ... Bref, quelle que soit la personnalité du "nouveau" il me semble impératif de bien l'encadrer et de le mettre en confiance.

Je suis d'accord avec ce que tu dis, en grande partie. C'est comme dans un couple, les choses ne sont jamais 100% d'un côté, ni 100% de l'autre. Le nouveau, il faut qu'il montre un minimum d'envie et de coopération dès le début pour par se faire "exclure" par les autres. Qu'il montre qu'il a les compétences et qu'il n'est pas là pour remplacer mais pour compléter. Il y a aussi le travail des chefs d'équipes qu'il ne faut pas oublier.

[naholyr]

Envoyé par bubulemaster

Moi ce qui m'embête c'est :

Personne n'est capable d'estimer le temps car il y a toujours, quelque chose qui nous tombe dessus sans prévenir.

Justement, les développeurs expérimentés savent quel est le risque d'imprévu, et quelle estimation (en %age de charge en plus) donner à cet imprévu. C'est évidemment avec plus ou moins d'exactitude, mais c'est justement ça la différence, car le vieux loup fera une estimation (précise) du temps à passer dans le cas idéal, puis saura faire une estimation du risque de dérapage afin d'appliquer un coefficient multiplicateur à son chiffrage idéal.

Envoyé par badthings

@naholyr:

Je suis désolé, mais je ne suis pas du tout d'accord avec vous.
Il n'y a qu'à prendre la définition du mot extraverti.

C'est pour ça que j'ai mis ce mot entre parenthèse, et indiqué au début de mon message que ce n'était pas forcément le mot adapté, je n'en avais simplement pas d'autre en tête à ce moment-là. En cela j'espèrais que le lecteur comprendrait que ce qui comptait c'était la description, pas le mot utilisé...
Le bon mot aurait plutôt été "arrogant", mais c'est trop méchant, je pense qu'aucun mot ne conviendrait à 100% de toute façon

Dans ta description tu corresponds d'ailleurs au mec au milieu de la ligne dont j'ai parlé (même si j'ai mal nommé les extrêmités), et qui est sans doute de loin le plus facile à gérer : pas d'excès de confiance en soi, pas de timidité maladive empêchant le dialogue.

[haygus]

Bonjour à vous je suis débutant (8 mois, toujours en alternance).
Je développe en PHP, alors mon soucis. Savoir faire un ratio entre un code propre en prenant le moins de temps (pour l'instant c'est un du code moche)
Je n'ai jamais bloqué encore 1/2 journée sur un problème (en PHP je pense moins de problématique que du développement logiciel).
Je pose des questions idiotes et souvent en posant la question la réponse me vient dans la tête.

[badthings]

@Lyche:

qu'ils ne savent pas indenter leur code qu'ils ne savent pas faire des jointures normées et qu'ils demandent qu'on les aident (voir qu'on leur fasse le boulot) pour leur entreprise. Y'a de quoi se poser des questions
1 - sur les formateurs
2 - sur les correcteurs
3 - sur le développeur qui n'a jamais essayer d'apprendre des choses par lui même.

Quand on voit que certaines personnes (je parle d'expérience) sortent d'un double cursus bac + 5 (en développement) et qu'ils ne connaissent même pas le CSS moi ça me fait peur pour les futurs générations..

Simple question,
En donnant 2,5 ans d'étude (soit 25 mois de cours, à raison de grosso modo 4 semaines mois et 40h de cours par semaine, cela fait environ 4000 h de cours. Ce qui sur-évalue grandement le nombre d'heures réélles de cours (cours, TD, TP).

Quel serait selon vous le planning pour que les étudiants sortant de BAc+5 aient les compétences que vous désirez ? (dont une bonne maitrise de SQL et de ses normes).

Le problème vient surtout du fait que les normes changent, les langages "populaires" changent, sans compter les différentes versions.

Chaque entreprise voudrait voir le nouveau comme un gars qui a fait ce pour quoi il est embauché pendant 2ans. Or, c'est surtout un large panel pour qu'il apprennent ensuite vite par eux-même.

"Je pense" que la bonne question n'est pas : les débutants ont-ils un bon niveau ou "comment se fait-il qu'il ne connaisse pas cela"

mais plutôt:
"quel est son niveau après 6 mois à faire cela"

@Naholyr:
Au temps pour moi dans ce cas.
Je n'avais pas lu la phrase indiquant que le mot n'était pas adapté.
effectivement, pour être arrogant, il faut pas faire d'erreur car personne ne te loupera

[Louis Griffont]

Le sujet semble dériver vers la formation des jeunes.

Je ne pense pas que l'apprentissage d'un langage pendant les études soit autre chose que pédagogique. C'est à dire pour étudier un langage. Ce peut-être n'importe quel langage, ça n'a aucune importance. Ce qu'il faut, c'est voir comment transposer l'analyse au langage.

Quand j'ai un CV d'un débutant dans les mains, je ne regarde pas ou peu les langages étudiés, mais plutôt ce qu'il a réaliser en stage. Un langage, ça s'apprend, comme disait mon prof (il y a ... houla des lustres ), une méthode sa s'acquiert ! Le but est d'acquérir les méthodes, le reste vient après. Les entreprises qui veulent des compétences dans tel ou tel langage et qui embauchent des débutants sont stupides, dans ce cas elles doivent se tourner vers un vieux de la vieille comme ont dit !

Je pense que les formations doivent fournir essentiellement la méthodologie afin d'aborder les différents aspects du boulot. Ensuite pour les spécificités du langage, c'est en forgeant que l'on devient forgeron !