Comment inclure des développeurs débutants dans votre projet?

Nous envisageons d'enseigner à certains employés qui ont une expérience de programmation de niveau amateur zéro ou générale à me décharger de la charge de travail.

Nous utilisons Python / Django qui a une partie de la documentation la plus conviviale et un jeu d'enfant à apprendre.

Je suis actuellement un service informatique pour mon entreprise et je n'ai pas assez d'heures pour développer tout ce dont l'entreprise a besoin. Nous ne sommes pas une société de logiciels, mais cela aide d'avoir une informatique interne pour automatiser les tâches, développer les fonctionnalités de service client, analyser les données, etc.

Comment intégrez-vous lentement les recrues travaillant sur votre base de code? Disons que vous avez un stagiaire - que font-ils? Je suis totalement réticent à les laisser concevoir ou développer du code de base car nous allons faire face à leurs erreurs / modèles de conception étranges pendant des années. En tant que développeur principal, je serai celui qui devra contourner leur code.

Ma pensée était que les novices ne modifient que le code existant, sans jamais construire de fonctionnalités de base. Je peux leur décharger du travail avec des tâches simples après avoir construit la fonctionnalité elle-même.

Nous aimerions que nos employés apprennent / trouvent de la valeur dans l'entreprise, et nous avons généralement des gens qui «gravissent les échelons».

Est-ce une pratique courante d'enseigner aux personnes ayant une programmation de niveau général / amateur? Comment fonctionne la «montée en grade» dans une entreprise de logiciels pour les programmeurs débutants? Quand commencent-ils à travailler sur le code principal?

J'essaie de décider si cela va causer plus de dégâts que l'aide, et s'il y a un moyen d'utiliser leur aide sans risquer de risquer le code du site principal (environnements isolés?).

Si vous déléguez la recrue à un rôle inefficace, il / elle n'apprendra jamais rien de substantiel, et ils ne vous seront certainement pas trop terriblement utiles.

Permettez-moi de vous donner un conseil, mon premier emploi informatique hors de l'école était dans une entreprise de fabrication relativement petite où j'allais travailler sur un logiciel pour aider les ingénieurs commerciaux à rédiger des devis pour divers projets. J'étais également censé aider le responsable informatique qui gérait à lui seul l'informatique pour toute l'entreprise.

Le gars était un gâchis surchargé de travail et le pire perfectionniste de la micro-gestion avec lequel j'ai jamais travaillé. J'étais censé alléger sa charge de travail, mais il a passé presque autant de temps à me surveiller et à surveiller mon travail que je passais à travailler (il n'a presque jamais quitté le bureau, je pense qu'il méprisait sa famille). Si je commettais une seule erreur, il perdrait complètement la tête et commençait à faire une crise de colère: "Je savais que je n'aurais pas dû te faire confiance, c'était trop important!" et autres coups de gueule.

Le point que j'essaie de faire est de ne PAS être de cette façon. Non seulement cela rendra les recrues misérables et détruira leur moral, mais vous brûlerez la bougie aux deux extrémités en vous souciant de leur travail.

Donnez-leur une chance de faire leurs preuves, mais ayez des spécifications techniques formelles, des revues de conception et des revues de code. Vous pouvez également tester ce qu'ils produisent pour vous assurer qu'il répond aux exigences.

Je pense que vous serez surpris de la capacité de certains d'entre eux.

Je travaillais dans un magasin de logiciels, où nous codions un grand projet (temps de montée en puissance important).

Les recrues étaient traitées comme des vétérinaires. Un responsable technique leur a été attribué et les fonctionnalités ont été lancées "par leurs propres moyens". Le style d'architecture a été dicté, mais ils étaient libres de proposer leur propre design épuré. Les «modèles de conception étranges» ont été éliminés lors des révisions (quotidiennes) du code par les pairs.

Une erreur que j'ai vue dans une autre boutique: supposons que "core" est difficile et "ui" est facile. Les débutants ont eu un temps plus facile dans le noyau et ont foiré le code frontal de l'interface utilisateur.

Bonne chance!

Vous voulez commencer par leur donner des fonctionnalités de petites pièces discrètes à mettre en œuvre. Définissez l'entrée que vous promettez et la sortie que vous attendez, et laissez-les connecter les points. Ensuite, utilisez la révision du code par les chefs d'équipe pour garantir la qualité et la révision par les pairs pour les former à apprendre les uns des autres et à s'enseigner eux-mêmes.

Cela suppose que vous disposez d'une architecture d'application globale qui permet de construire des unités atomiques de logique de manière découplée. Sinon, vous vous dirigez vers un monde de chagrin alors que plusieurs développeurs y travaillent - ce serait le cas même avec de vieux pros.

Inévitablement, vous aurez certaines personnes qui s'y attaqueront, apprendront vite et se lèveront. Assurez-vous de continuer à leur fournir des tâches qui ne sont qu'un petit pas au-delà de leurs capacités actuelles. Rien n'éduque quelqu'un comme une tâche qui commence impossible. Inévitablement, vous aurez des gens qui essaient de ne jamais vraiment s'en emparer. Ces personnes devraient être remerciées pour leurs efforts et transitions avec grâce vers autre chose.

Comment votre entreprise peut-elle se permettre de prendre du temps loin des autres employés, sans embaucher quelqu'un ayant de l'expérience en programmation? Le temps que vous consacrez à la formation, au dépannage et à la tenue de la main est coûteux.

La seule chose que j'ai jamais faite dans ce domaine est d'enseigner aux gens comment utiliser un rédacteur de rapport ou peut-être un code VBA / Macro pour Excel. Je donne généralement les ensembles de données à réutiliser. Leur faire apprendre le SQL est un tronçon, mais je l'ai vu faire (payé pour qu'ils reçoivent une formation en dehors.) La plupart de ces personnes étaient des analystes financiers qui ont la capacité d'apprendre à coder, mais n'ont peut-être pas pris le temps. Essayer cela avec certaines personnes en opération est un processus de longue haleine.

Assurez-vous d'avoir la bonne personne et elle veut vraiment apprendre à coder. Vous n'aurez pas le temps de tout leur apprendre. Ils devront faire beaucoup par eux-mêmes.

@louisgab avait raison sur la révision du code. Ce serait aussi ma première étape. Une chose essentielle qui vous aidera est de vous assurer qu'ils doivent corriger leurs propres erreurs, que vous les trouviez dans la révision du code ou plus tard. Ils ont gagné; ils ne réalisent même pas qu'ils font des erreurs à moins de devoir les réparer. Assurez-vous également d'expliquer pourquoi la solution qu'ils ont utilisée est une erreur et pourquoi ce que vous proposez est meilleur. Les premières semaines, vous aurez l'impression d'avoir plus de travail à cause de ces autres personnes, mais si vous faites vos révisions de code et expliquez les choses et que vous attendez qu'elles apprennent, dans quelques semaines, elles seront beaucoup plus utiles que si vous venez faites-le vous-même. Mais il y a un engagement initial de votre temps pour les mettre à jour dont votre direction doit être consciente.