Quelles sont les erreurs les plus commises par de nouveaux développeurs ?
Et comment les éviter ?

Le , par Katleen Erna, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de cinemania cinemania - Membre expérimenté http://www.developpez.com
le 05/02/2010 à 20:12
Exacte ce n'est qu'un sondage, mais je suis néanmoins d'accord avec certains qui hurlent devant le fait qu'on ose prétendre qu'une mauvaise estimation des temps est une erreur de débutant.

Quel chef de projet saint d'esprit demandera t'il a un stagiaire combien de temps il lui faudra pour effectuer une tache ?
Personnellement ne sachant pas ce que valait chaque stagiaire je leur ai fait faire une tâche avec comme révérenciel, le temps que moi je mets.
Une fois cela fait, vous leur faite faire la tache et voyez le temps effectif passé.

Vous avez alors une idée assez précise de ce qu'ils valent par rapport à vous, et vous êtes plus à même d'estimer leur temps "idéal" et leur temps "catastrophique" et de faire une moyenne.

L'erreur est toujours située du coté du chef de projet qui ose demander à un développeur non confirmé combien de temps il lui faudra pour effectuer une tâche, ou pire un stagiaire.
C'est également une raison pour laquelle mes stagiaires ne travaillaient pas sur des matériels sensibles, pas au sens données confidentielles, mais au sens, temps de traitement cours... mais sur des projets de seconde classe que l'on confie traditionnellement à des stagiaire pour se faire les dents.

il faut quand même réaliser que meme un développeur peut largement, même en étant précis habituellement se planter complètement, et sous-évaluer la tâche et le temps, car sa vision globale du problème fausse la donne.
Afin d'effectuer un chiffrage sur les temps moyens de développement, je prend toujours une journée, pour étudier à fond le cahier des charges et me faire une idée du travail à faire et des différentes phases, et des différents sous problèmes afin d'avoir une idée plus précise en temps/développeur.
Cette technique au sein de l'entreprise m'a toujours permis d'avoir des évaluations relativement juste avec générallement entre 2 et 3 jours de plus en guise de sécurité, il m'est meme arrivé de faire des chiffrages détaillés et les fournir avec les différents temps, quand toute une partie nécessitait un développement et un déploiement sur mesure chez le client.

il arrive que parfois, un élément perturbateur vienne alors "retarder" la date de délivrance, mais c'était générallement due à des déplacements non prévus, des enchainements de réunions inutiles pour planifier des réunions pour en planifier encore d'autres... comment perdre une semaine en voiture... plutot qu'a développer.
vive la bureaucratie et la hiérarchie complètement débile qui ne comprend et n'entrave rien aux raisons et à la mécanique bien huilée d'un bureau de développement.

J'en entends déjà certains me dire, oui mais une journée pour évaluer le temps... et alors ? cette journée d'étude était alors facturée au client sur le projet final comme une journée de consulting, ce qui me permettait aussi souvent d'appeler le client pour bien confirmer point par point que ce que voyait écrit dans le cahier des charges initial fonctionnel était bien conforme et correspondait bien à leur vision des choses et surtout leur besoin.
Généralement on comptait même cette journée dans le temps d'élaboration du cahier des charges et l'étude préliminaire, pour les gros projets.
sinon pour les petits je faisait ca en parallèle avec d'autres projets.

Effectivement le problème de la langue est assez génant, quand vous devez expliquer un mémo que vous avez envoyé à tout le monde parce qu'ils ne sont pas fichus de comprendre un traitre mot de ce qui est écrit en français soutenu.
Il ne faut pas oublier que beaucoup ont un vocabulaire particulièrement ... restreint...
Avatar de - http://www.developpez.com
le 05/02/2010 à 20:19
Citation Envoyé par Lavock  Voir le message
Et je suis plutôt scandalisé qu'il y en aie qui répondent ça (premier choix quand même oO). Il y a problème de formation ET de fantasme aussi >< ! Bientôt on va se plaindre que les stagiaires aient pas bouclé leurs projets à 100% aussi, et de pas avoir débugé toutes les autres applications de l'entreprise oO ?

Non, mais la question se pose quand même... D'un point de vue d'entreprise (de PME dans mon cas), un expérimenté (un gars avec 10-15 ans d'expérience) ca coûte entre 1,5 et 2 fois plus qu'un petit jeune (parfois moins en fait: les jeunes sont gourmands mais les vieux ont faim...). Actuellement, sur le marché, si tu cherches un peu, tu peux trouver des deux. Il y a, dans les faits, une concurrence entre ces deux groupes.

Dans ce contexte, pour l'entreprise, la question est de savoir si on veut trois petits jeunes, ou deux types de 35-40 ans. Vu du point de vue du jeune diplomé, il me semble que le but est de pallier ce ressenti, et la méthode Alizee (c'est pas ma faute à moi), ca n'a jamais convaincu personne (pas plus que le fait d'être scandalisé).

Enfin, moi, j'dis ca, j'dis rien...

Francois
Avatar de - http://www.developpez.com
le 05/02/2010 à 20:26
Citation Envoyé par cinemania  Voir le message
Quel chef de projet saint d'esprit demandera t'il a un stagiaire combien de temps il lui faudra pour effectuer une tache ?

Leur demander me parait sain... Les croire me parait idiot.

Maintenant, dans toutes les PME, on va très vite demander à des jeunes embauchés (après 6 mois, disons) d'avoir une idée raisonnable du temps qu'il leur faut pour une tâche. Il n'est pas question de faire du chef de projet (qui en général est le codeur principal, ou l'architecte, ou le responsable du lien client) la "nounou" des devs, même jeunes... Du coup, quand on embauche, on est assez vite exigeant sur la capacité à prévoir. Quelqu'un qui se trompe un peu une fois, ou deux, ca roule. Quelqu'un qui à la troisième fois n'a pas l'air d'apprendre...

Les stagiaires, je ne sais pas, j'en prends rarement, en général, ca ne sert à rien...

Francois
Avatar de chaplin chaplin - Membre expérimenté http://www.developpez.com
le 06/02/2010 à 13:50
Citation Envoyé par fcharton  Voir le message
Les stagiaires, je ne sais pas, j'en prends rarement, en général, ca ne sert à rien...
Francois

C'est un peu tranché comme remarque. Il faut laisser la chance à chacun et surtout un stage permet de découvrir un métier, c'est une porte vers le monde de l'entreprise.

J'ai été stagiaire à deux reprises, et un stage m'a permis de faire un diplôme tandis que l'autre m'a permis d'être embauché. Un stage peut déclencher une motivation chez un individu là ou en règle général il s'enfiche .
Avatar de - http://www.developpez.com
le 06/02/2010 à 14:31
Citation Envoyé par chaplin  Voir le message
C'est un peu tranché comme remarque. Il faut laisser la chance à chacun et surtout un stage permet de découvrir un métier, c'est une porte vers le monde de l'entreprise.

C'est exact. Je réagissais à la réponse précédente, qui semblait confondre jeunes programmeurs et stagiaires. Un stage, c'est exactement ce que tu dis, un moyen de présenter l'entreprise aux jeunes diplomés. Prendre des stagiaires pour leur faire faire le "vrai boulot" (ce qui devient malheureusement la manie de certaines boites), c'est aller droit dans le mur.

Personnellement, je recherche peu les stagiaires : il n'y a pas de contraintes, ni d'un côté ni de l'autre, pas de salaire, pas de garanties, pas d'obligations.

Je préfère un salaire et une période d'essai, c'est plus franc.

Francois
Avatar de lemerite lemerite - Nouveau membre du Club http://www.developpez.com
le 08/02/2010 à 8:20
c'est bien pour ça qu'on les appel nouveaux programmeurs
Avatar de cladsam cladsam - Rédacteur http://www.developpez.com
le 10/02/2010 à 13:48
Bonjour,

pour moi ce qui est le plus embêtant, qui passe d'ailleurs difficilement avec l'expérience, c'est de mal gérer la documentation technique.
Je travaille sur une techno -SAP- ou le code ne génère pas un exécutable mais soit de nouvelles fonctionnalités -transactions- soit des modifications à des fonctionnalités existantes -pour faire simple disons extensions-.
Les fonctionnalités existantes peuvent être utilisées partout dans le système et ajouter un morceau de code que la documentation ne permet pas de "géolocaliser" ni d'interpréter c'est comme demander au suivant de faire en 3 heures ce qu'il aurait pu faire en 5 minutes parce qu'il se transforme en sherlock holmes et que ce n'est pas élémentaire ...
Donc pour résumé, les débutants souvent ne trouvent pas le juste milieu d'une documentation complète qui ne paraphrase ni le code ni la spécification fonctionnelle.
Avatar de Jidefix Jidefix - Membre éprouvé http://www.developpez.com
le 10/02/2010 à 14:20
Citation Envoyé par cladsam  Voir le message
Bonjour,
pour moi ce qui est le plus embêtant, qui passe d'ailleurs difficilement avec l'expérience, c'est de mal gérer la documentation technique.

Mouais personellement je trouve que ce n'est pas spécialement une erreur de débutant. C'est très rare de trouver une documentation humainement compréhensible, même dans un projet relativement vieux.
Ce qui est marrant c'est que là où je bosse, ils ont acheté un outil en exigeant une documentation dans les règles.
Les prestas (qui sont de ma boite mais chut, il ne faut pas le dire) ont bien fourni un tas de papier digne des archives nationales.
Comme tout le monde s'en tapait "tant que ça marche", personne n'a jamais vraiment ouvert les documents. Maintenant on veut reprendre le truc et là... c'est le drame.
Autant décrypter le code source ça ira plus vite

Du coup pas étonnant que les débutant ne s'y mettent pas non plus...
Avatar de DrikS DrikS - Membre à l'essai http://www.developpez.com
le 11/02/2010 à 22:01
Bonjour à tous,

je suis actuellement en Bac+4 d'informatique. Je trouve les propos de certains excessifs. Certains dénoncent l'inexpérience des jeunes arrivant sur le marché (normal, non ?) et d'autres vantent le niveau et l'expérience à toute épreuve des anciens.
Je pense qu'il faut trouver le juste milieu.
Quand j'entends que certains déplorent le niveau en SQL d'un bac+5, je dis attention. Ayant été confronté à la "gestion" d'un SGBD en entreprise durant un stage, j'ai été scandalisé de voir que les administrateurs de base de données ne savaient pas de quoi je causais quand je leur proposais de fragmenter horizontalement ou verticalement une table, indexer intelligemment et non systématiquement, partitionner une table, etc... Les messieurs laissaient faire le travail à Oracle sans se poser la question que depuis la version 9.i on peut faire ce genre d'action. Où est la réduction des coûts ? l'optimisation ? la performance ?

D'un autre côté, les entreprises utilisent de plus en plus de Framework (maison ou autre) ou autres outils de simplification du travail, qui sont rarement enseignées en école. Il est plus demandé de concevoir des petits ou gros projets, de la conception jusqu'au test, en demandant en gros aux étudiants de coder comme des brutes et rendre le travail le plus propre et fonctionnel possible. On ne se soucie donc pas ici de charte de développement ou de quelconque norme. L'adaptation en entreprise est donc une étape des plus normales...

Et pour ceux qui dénigrent le niveau en programmation de la new wave des jeunes pouces, si vous pouviez m'envoyer un message en MP contenant un de vos projets étudiants pour voir qu'elle était votre niveau, lorsque vous étiez à ma place, histoire que je me fasse une idée.

Tout ça pour dire que je ne me retrouve nulle part dans les différents posts.

Cordialement
Avatar de dams78 dams78 - Membre chevronné http://www.developpez.com
le 12/02/2010 à 10:13
Citation Envoyé par DrikS  Voir le message
Bonjour à tous,

je suis actuellement en Bac+4 d'informatique. Je trouve les propos de certains excessifs. Certains dénoncent l'inexpérience des jeunes arrivant sur le marché (normal, non ?) et d'autres vantent le niveau et l'expérience à toute épreuve des anciens.
Je pense qu'il faut trouver le juste milieu.
Quand j'entends que certains déplorent le niveau en SQL d'un bac+5, je dis attention. Ayant été confronté à la "gestion" d'un SGBD en entreprise durant un stage, j'ai été scandalisé de voir que les administrateurs de base de données ne savaient pas de quoi je causais quand je leur proposais de fragmenter horizontalement ou verticalement une table, indexer intelligemment et non systématiquement, partitionner une table, etc... Les messieurs laissaient faire le travail à Oracle sans se poser la question que depuis la version 9.i on peut faire ce genre d'action. Où est la réduction des coûts ? l'optimisation ? la performance ?

D'un autre côté, les entreprises utilisent de plus en plus de Framework (maison ou autre) ou autres outils de simplification du travail, qui sont rarement enseignées en école. Il est plus demandé de concevoir des petits ou gros projets, de la conception jusqu'au test, en demandant en gros aux étudiants de coder comme des brutes et rendre le travail le plus propre et fonctionnel possible. On ne se soucie donc pas ici de charte de développement ou de quelconque norme. L'adaptation en entreprise est donc une étape des plus normales...

Et pour ceux qui dénigrent le niveau en programmation de la new wave des jeunes pouces, si vous pouviez m'envoyer un message en MP contenant un de vos projets étudiants pour voir qu'elle était votre niveau, lorsque vous étiez à ma place, histoire que je me fasse une idée.

Tout ça pour dire que je ne me retrouve nulle part dans les différents posts.

Cordialement

Pour avoir fais mes études supérieur en apprentissage, je suis d'accord avec toi.
Les deux parties ont a gagner, l'entreprise peut former le jeune sur les bonnes pratiques à prendre : travailler en équipe, documenter son code, etc.
En revanche ce qu'on apprend à l'école est souvent basé nouvelles technologie (dernière version de Java, etc) et de ce côté on peut aussi apporter un plus en l'entreprise en disant "voila ce qu'il se fait maintenant".

Et tout ce mélange peut être bénéfique aux deux parties.
Avatar de raphchar raphchar - Membre averti http://www.developpez.com
le 15/02/2010 à 10:50
Citation Envoyé par metagoto  Voir le message
Je trouve que les nouveaux programmeurs manquent d'expérience

Lapalisse n'aurait pas dit mieux
Offres d'emploi IT
Data scientist inspection générale (H/F)
Société Générale - Ile de France - Hauts-de-Seine
Ingénieur qualité logiciel au CEPS H/F
Safran - Ile de France - Osny (95520)
Ingénieur développeur intégrateur débutant H/F
Safran - Ile de France - Osny (95520)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil