Aider les programmeurs juniors à surmonter leurs lacunes? [fermé]

Quels sont vos reproches courants concernant les développeurs juniors qui rejoignent votre équipe ou avec qui vous devez travailler? De toute évidence, ils sont inexpérimentés, vous ne pouvez donc pas vous attendre à ce qu'ils sachent tout, mais quelles compétences manquent souvent inexplicablement - et comment, en particulier, pouvons-nous les aider à développer ces compétences manquantes?

Je ne parle pas de compétences interpersonnelles comme «écouter des conseils», je veux dire des questions techniques comme (le cas échéant):

• «vous n'avez jamais fait de SQL?

• «vous n'avez jamais écrit un test unitaire?

• 'vous ne savez pas comment utiliser une ligne de commande Unix?'

Choses auxquelles vous vous attendez - J'aimerais entendre vos observations et vos techniques pour enseigner aux nouveaux programmeurs à surmonter ces lacunes spécifiques.

Ne pas savoir ce qu'est le contrôle de version ni comment l'utiliser correctement .

L'un des développeurs juniors qui travaille dans mon entreprise depuis plusieurs mois récemment a dû apprendre les bases de Subversion. Cela m'a vraiment fait grincer des dents ... elle vérifie le code pour vivre des projets tout le temps ... et n'avait aucune idée de ce qu'elle faisait ...?

Ne pas poser suffisamment de questions

Je sais que ce sont des juniors, je m'attends à ce qu'ils commettent des erreurs et ne sachent tout simplement pas. Tant de f ** k ups royaux auraient pu être évités en posant simplement une question au lieu de supposer quelque chose. Honnêtement, je ne peux pas être assez harcelé.

J'avais des TONNES de questions quand j'ai commencé - les demander m'a sauvé le cul à plusieurs reprises. Bon sang, j'ai encore beaucoup de questions ... J'aime juste penser que ce sont de meilleures questions maintenant.

Copiez le collage et les essais et les erreurs au lieu de chercher à comprendre les principes fondamentaux sous-jacents

De nombreux développeurs juniors copieront du code qui semble proche, puis essaieront presque aléatoirement différentes permutations de modifications par force brute jusqu'à ce qu'ils atteignent celui qui fonctionne. Si vous ne savez pas pourquoi cela fonctionne, il est probable que vous introduisiez des bogues dans les cas limites que quelqu'un qui le comprend devra nettoyer plus tard.

Garder leur "premier brouillon" de code

Lorsqu'un développeur expérimenté écrit une nouvelle fonction d'une certaine complexité, il commence avec un stub qui ne fait que compiler, puis réécrit pour ajouter des commentaires de pseudo-code de haut niveau pour l'algorithme global, puis réécrit ces commentaires un par un avec du code réel, en ajoutant et en supprimant du code factice au besoin pour les tests, puis en réécrivant pour supprimer la redondance apparue lors de la mise en œuvre, et ainsi de suite dans une série d'améliorations successives et incrémentielles.

Les développeurs juniors ont tendance à l'écrire en un seul gros morceau, puis à effectuer un débogage massif par force brute. Ils n'aiment pas supprimer une ligne de code une fois qu'elle est tapée dans l'éditeur, et sont si heureux qu'ils l'ont finalement fait fonctionner qu'ils répugnent à réécrire pour des améliorations non fonctionnelles, mais ce sont eux qui doivent le faire donc le plus.

Croire que vous êtes le premier à rencontrer une situation.

Chaque problème de programmation auquel vous êtes confronté a été rencontré par d'autres, sous une forme générale. Il y a tant à apprendre des programmeurs expérimentés. Je suis assez vieux pour me souvenir de la programmation avant Google, et ça craignait . C'était encore pire quand nous avions des moteurs de recherche, mais il n'y avait tout simplement pas encore beaucoup de bonnes informations sur le Web. La programmation est désormais beaucoup plus productive car vous avez accès à des connaissances globales en quelques secondes. Les gens qui ne l'utilisent pas l'ignorent à leurs risques et périls.

Modifier :

Juste pour être clair, je ne préconise pas la programmation copier / coller. Je suis certain, cependant, que vous devez revoir les connaissances existantes avant de pouvoir prendre de bonnes décisions vous-même.

Pensant qu'ils savent tout.

J'ai eu un jr. stagiaire qui a essayé de tout résoudre avec javascript. J'ai essayé d'expliquer plusieurs concepts, mais il a toujours pensé qu'il pouvait mieux faire. Maintenant, il a quitté et retravaillé un programme majeur qu'il a construit pour la sortie d'impression en utilisant HTML au lieu d'une technologie prête à imprimer comme PDF. Sans parler d'une pile d'autres problèmes majeurs.

La leçon est de demander aux aînés des conseils généraux importants au début d'un projet, ne quittez pas l'architecture sans aide. Vous pouvez écrire le code et les détails seuls, mais assurez-vous d'utiliser au moins la bonne technologie.

Je m'énerve rarement lorsque les juniors ne connaissent pas les bases, on ne leur enseigne pas les compétences de l'industrie comme le SCC à l'université. C'est le travail des développeurs seniors de leur enseigner. Je ne suis ennuyé que par les affrontements de personnalité. Mais je suis très ennuyé par les développeurs seniors qui ne connaissent pas les bases.

Ne voulant pas faire progresser leurs connaissances - prendre plutôt le chemin de la moindre résistance.

L'autre jour, un stagiaire et le graphiste (qui est étonnamment compétent en programmation) ont demandé de l'aide car ils avaient des problèmes pour implémenter quelque chose dans jQuery - la fermeture peut être douloureuse si vous ne pouvez pas la voir venir.

Je me suis assis avec le stagiaire et j'ai expliqué exactement ce qui n'allait pas et pourquoi. Nous avons corrigé le bogue, puis j'ai souligné plusieurs améliorations supplémentaires qui pouvaient être apportées ("puisque je suis ici") et nous avons fini par réécrire la fonction coupable en 10 lignes au lieu de 20 et sans bogues. Après avoir répondu à toutes les questions, convaincu que tout allait bien dans le monde, je suis parti.

Le lendemain, le stagiaire est venu avec une question qui a révélé qu'il "euh, voulait faire quelques changements et réécrit la fonction à ma façon parce que j'avais du mal à comprendre" (pour la plupart annuler mes améliorations).

Il aurait pu soit essayer plus fort à la place (poser des questions supplémentaires, lire les concepts que j'ai mentionnés) - un code si court ne peut jamais être si difficile à comprendre - ou prendre la solution de facilité. Cela m'attriste chaque fois que je vois quelqu'un faire ce dernier.

Je ne comprends pas la POO. Malheureusement, c'est beaucoup plus courant que la plupart d'entre nous ne le pensent probablement.

Savoir créer une classe, une classe abstraite, une interface ou même connaître le polymorphisme est une chose; comprendre comment les utiliser correctement au profit de votre programme en est une autre .

Si vous voulez éviter celui-ci, j'ai trouvé ces questions et les réponses éclairantes:

• Odeur de code: abus d'héritage - Les dangers de l'héritage
• D'où vient ce concept de «privilégier la composition à l'héritage»? - Les dangers des mantras pour éviter l'héritage

Ne sachant pas ce que vous ne savez pas et ignorant en pensant que vous savez tout.

(Et son cousin proche, ne voulant pas demander.)

C'est en partie une chose organisationnelle - une induction entrante appropriée contribuerait grandement à éviter que certaines de ces choses ne deviennent des problèmes. Mais très peu d'entreprises ont du temps ou des personnes disponibles pour une induction entrante - quelque chose qui devrait prendre de quelques jours à quelques semaines et qui décourage les développeurs de leur travail. Nous devons donc éteindre les incendies à la place.

Je suis étonné de voir combien de programmeurs juniors relativement récents d'un programme CS sont faibles avec les algorithmes. Un mauvais choix d'algorithme peut ne pas vraiment se démarquer dans la gamme d'applications métier, mais lors du traitement de milliards de demandes de service Web par jour, cela compte vraiment.

Voici une question d'entrevue que j'utilise que presque tous les programmeurs juniors manquent et qui met en évidence le problème:

Écrivez le code qui calcule le Nième numéro de Fibonacci .

Ils préfèrent presque toujours écrire le plus évident mais inefficace

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Lorsqu'on me demande de commenter la complexité algorithmique, j'obtiens généralement "c'est pire que O (N) ... uhm ... O (N logN)". C'est en fait (bien) pire que ça ...

Faire une indentation de code en arrière!

Bien sûr, ce n'est pas très "typique". Je ne pourrais jamais croire que c'était même possible, mais ce qu'un développeur normal écrirait comme

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

elle écrirait comme (Dieu, ça me semble encore impossible!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Frustrant n'est-ce pas?