Il existe de nombreux cours sur la façon de former des personnes, certains en ligne, d'autres issus d'institutions d'apprentissage du monde réel. Je ne pense pas que vous ayez le temps pour cela.

Alors, commençons par un cours intensif de 10 minutes.

1. Documentez les processus : Votre point de départ sera la documentation de votre produit. Chaque étape détaillée, chaque référence, chaque technologie supplémentaire dont elle est suspendue. Obtenez-le sur papier.
2. Établissez une base de référence : établissez un niveau de compétence minimum à atteindre pour comprendre vos documents. Par exemple, la remise du support d'application peut nécessiter des connaissances C #, des capacités SQL, Cobol ... Établissez une ligne de base en listant le niveau de compétence de base pour chaque technologie. N'oubliez pas Windows, certaines personnes sont des idiots.
3. Développer un plan : une fois que vous avez votre base de référence, commencez à mettre votre documentation dans un plan de formation. Cela va prendre du temps. Commencez par les concepts les plus simples et développez-les. N'oubliez pas que vous écrivez ceci en partant du principe qu'un entrepreneur pourrait entrer et toucher le sol après l'incident de votre bus.
4. Testez-le : testez votre formation sur quelqu'un. Ils trouveront les trous que vous avez négligés. Réparez les trous, rincez, répétez.

Comme pour tout, chaque étape peut être décomposée en étapes plus détaillées. Avoir un google / bing pour rédiger de la documentation technique, créer des modules de formation, etc.

En tant que spécialiste des données, je serais extrêmement ennuyé si quelqu'un voulait essayer de faire de moi un développeur d'application pour le facteur bus. C'est juste à courte vue de la part de votre direction. C'est comme demander à un comptable de se former aux RH. J'en parle uniquement parce que vous risquez de faire face à la résistance de ces personnes. J'en parle aussi parce qu'ils ne sont pas non qualifiés, ils ont un métier complètement différent et si vous les traitez comme étant non qualifiés et stupides, cela se produira dans votre formation, ce qui créera des problèmes.

Je crois que le premier L'étape consiste à identifier les choses dont ils auront probablement besoin pour pouvoir faire et à les documenter dans un wiki. Il est peu probable qu'ils veuillent que ces personnes créent des choses à partir de zéro, mais qu'elles résolvent les problèmes et tiennent les choses ensemble jusqu'à votre retour ou à l'embauche d'un nouveau développeur d'applications. Si c'est vrai, triez ce que vous voulez pour leur dire les choses les plus importantes. Faites une liste des problèmes de production les plus courants, puis créez une aide-mémoire pour chaque problème sur ce qu'il faut faire pour le résoudre.

Apprenez-leur des choses comme comment interpréter les messages d'erreur et comment trouver des informations dans la journalisation de votre système et quand redémarrer le serveur et ce qui sera affecté si vous le faites. Apprenez-leur vos normes de codage. Apprenez-leur où le code est stocké dans le contrôle de code source et comment l'utiliser (alors que je pense que la plupart des travaux de base de données devraient être dans le contrôle de code source, ce n'est pas dans beaucoup d'endroits, donc ils ne savent peut-être pas comment l'utiliser.) Donnez-leur une liste. de tous les noms de serveurs et mots de passe applicables et assurez-vous qu'ils disposent des droits appropriés pour travailler sur ces serveurs.

Trouvez un contact local pour un endroit où des développeurs indépendants sont disponibles. Assurez-vous que votre entreprise sait qu'elle peut obtenir le soutien de ces personnes si le problème dépasse les compétences des personnes chargées des données. Vous, les data people et finalement votre direction serez plus heureux s'il y a un plan de secours. Les chances que vous puissiez transformer ces personnes en développeurs d'applications en peu de temps sont faibles. Le mieux que vous puissiez espérer est qu'ils peuvent résoudre des problèmes simples et ils savent où tout se trouve et peuvent expliquer l'entreprise à un pigiste pour des choses compliquées.

Le document tout ce que vous pouvez. L'objectif est que les gens puissent trouver ce dont ils ont besoin pour faire le travail si vous n'êtes pas là.

Je vous suggère également de lancer un processus de révision du code avec ces personnes. Dans ce cas, il ne s'agit pas tant de trouver des problèmes de code que de les familiariser avec votre code le plus récent et ses exigences, votre style de codage et vos processus de réflexion sur votre conception. En leur expliquant les choses, vous remarquerez probablement des bogues que vous n'aviez pas remarqués.

Lorsque vous avez un problème de production courant à résoudre après avoir passé en revue les problèmes les plus courants dans une formation session, demandez-leur de vous suivre et documentez chaque étape que vous faites. Assurez-vous de leur faire comprendre que vous encouragez les questions. S'ils font la documentation, ils seront plus susceptibles de l'écrire de la manière qui leur convient le mieux. Différentes personnes ont des styles d'apprentissage différents et vous créez essentiellement un Wiki qui leur sera plus utile que vous. Alors laissez-les décider comment l'organiser.

Si leurs tâches les empêchent de vous observer, alors faites le wiki tout seul pendant que vous travaillez sur les problèmes pendant qu'ils sont frais dans votre esprit.

Pour certains problèmes simples, une fois qu'ils vous ont suivi et que les étapes ont été documentées, vous leur demandez de suivre les étapes pendant que vous les observez. Cela leur donnera plus de confiance dans leur capacité à accomplir la tâche. C'est ce que nous avons fait lorsque nous avons récemment converti certains développeurs d'applications en spécialistes des données.

La philosophie d'enseignement de base devrait être

• Identifier ce qui doit être formé en se concentrant sur les questions les plus courantes
• S'assurer qu'ils ont accès aux choses ils doivent accéder pour résoudre les problèmes
• Créer de la documentation
• Passez en revue les étapes pour effectuer la tâche
• Faites-leur vous suivre et créez une documentation supplémentaire qui répond à leurs besoins
• Observez-les en exécutant la tâche en utilisant la documentation pendant que vous êtes disponible pour les aider à se sortir des ennuis si nécessaire.

J'étais dans une situation très similaire il y a quelques années - autodidacte, propriétaire unique de dizaines de services utilisés par des centaines de personnes, facteur de bus élevé. Votre question décrit exactement ma situation en 2014.

Beaucoup de ces réponses semblent suggérer de la documentation, mais ce n'était pas un bon plan pour moi - mes services ont changé rapidement , car aussi vite que des réorganisations ou des changements de politique pourraient se produire La documentation est connue pour être lente à produire et presque immédiatement obsolète. Ce n'était pas une question pour moi d'essayer de rassembler rétroactivement des pages de spécifications expliquant les minutae. Et les seules personnes qui le liraient seraient les personnes sous-qualifiées venant m'aider - qui finiraient toujours par me demander de clarifier ce que j'avais écrit de toute façon.

J'ai abordé ce problème de plusieurs manières.

1. N'essayez pas de créer une série de masterclasses - vous êtes occupé. Vous êtes le seul à pouvoir faire votre travail, votre temps est donc précieux. Invitez vos nouvelles personnes à vous observer / à vous associer pendant que vous déboguez un problème ou implémentez une fonctionnalité mineure. N'attendez pas que "le bon" bug arrive, prenez simplement l'un de vos membres et asseyez-le pendant que vous racontez ce que vous faites. Cela vous ralentira, mais pas autant que d'essayer d'organiser des présentations - et cela leur donnera une expérience directe. L'appariement était (pour moi) l'utilisation la plus précieuse du temps pour la formation - il permet aux nouvelles personnes de se relever très rapidement par rapport aux documents wiki.

2. Comprenez que vous ne le serez pas capable de tout leur apprendre. Il est moins important qu'ils comprennent ligne par ligne chaque classe que vous avez créée, et plus important qu'ils comprennent la géographie du code - s'ils comprennent à quels fichiers de code aller pour trouver comment quelque chose fonctionne, cela les aidera beaucoup plus qu'une présentation approfondie sur une chose spécifique.

   Surtout si vos employés sont des DBA de métier, ils comprendront probablement d'abord la logique en termes de schémas et de fonctionnalités seconde. Essayez d'identifier quelques chemins de données de base. La plupart des applications prennent les données d'une ou deux sources principales et les font muter à la demande de l'utilisateur. Si vous pouvez l'identifier, expliquez autant que possible ce chemin de données à vos développeurs. Parcourez physiquement (dans adebugger) ce qui se passe lorsqu'un utilisateur fait une requête, d'où proviennent les données, quelles classes sont responsables de leur chargement / enregistrement, si vous avez des caches, montrez où ils vivent et quelle est leur fraîcheur attendue.

3. Divisez les connaissances. Ne leur apprenez pas exactement les mêmes choses - si ce n'est pas une partie importante de vos services, n'ayez pas peur de le distribuer à différentes personnes. Cela profite du fait qu'ils auront besoin de temps pour absorber ce qu'ils apprennent, mais vous pouvez enseigner beaucoup plus rapidement que ce temps d'absorption. Cela leur permet également de se concentrer sur un plus petit morceau de l'image, même s'il s'agit toujours d'un gros morceau. Vous n'êtes pas obligé de les séparer, mais diviser et conquérir l'espace du problème est utile.

4. Vous avez probablement quelques refactors que vous vouliez faire depuis un moment - un service difficile à déboguer même pour vous. Faites-les. Et comme toujours, attrapez l'un de vos collaborateurs vers la fin pour lui montrer comment fonctionne le système refactorisé.

5. Parlez-lui , ne laissez pas ils vous donnent la politesse qu'ils suivent. Ils vont être perdus et confus. Lancez quelques phrases comme "Je sais que c'était beaucoup à comprendre, c'est assez compliqué. Est-ce que tout cela n'a pas de sens?" et essayez de les inviter à poser des questions autant que possible - vous ne pouvez pas leur enseigner si vous ne savez pas ce qu'ils absorbent.

   De plus, s'ils passent et vous posent une question, c'est votre priorité absolue , même si c'est juste de les regarder et de dire "Je vais à une réunion maintenant, ça va probablement durer 30 minutes, je te trouverai après".

6. Après avoir passé un certain temps à leur montrer les cordes, trouvez quelque chose à leur remettre. Une tâche non urgente qui vous convient et qui prend une semaine ou plus à terminer. Planifiez des associations avec eux pour voir ce qu'ils ont et où ils vont avec - corrigez-les bien sûr et donnez-leur des conseils sur la façon de coder pendant que vous y êtes (trucs comme "vous pouvez utiliser un foreach ici").

7. Revues de code. Demandez-leur de vous envoyer les différences (ou d'utiliser un système de révision de code) et de les passer en revue. Ne «notez» pas les évaluations, notez simplement où se trouvent les erreurs ou décrivez comment les améliorer. S'il n'y a pas de bogues, ne les empêchez pas de contribuer au code (ne les faites pas se sentir exclus par vous) - mais assurez-vous qu'il y a un élément pour qu'ils puissent suivre et nettoyer immédiatement.

Plus important encore, étant donné que votre équipe s'agrandit manifestement et que vous n'avez pas mentionné l'intention de quitter, maintenant il est temps de commencer à prendre au sérieux la qualité du code. Cela ne fera qu'empirer à partir de là, donc chaque classe et méthode que vous (et eux) éditez à partir de maintenant devrait recevoir un commentaire autodoc. Si vous ne l'avez pas déjà fait, commencez à modulariser votre code et essayez de séparer les méthodes qui s'exécutent sur des centaines de lignes, et démêlez les classes imbriquées.

Créez de la documentation pour commencer, des procédures étape par étape de ce que vous voulez enseigner avec des explications détaillées si nécessaire.

Cela crée une référence de base sur laquelle vous pouvez construire et répondre aux questions et qui est probablement l'aspect le plus important. Il a également le gros avantage de concentrer vos connaissances d'une manière que vous n'avez peut-être pas essayée auparavant. Je trouve certainement cela utile même pour moi-même, car beaucoup de choses que je fais sont assez complexes et cela m'évite de repenser mon chemin à travers un tas d'étapes si je l'ai déjà fait.

Le reste est fondamentalement travailler sur ce matériel de référence en y ajoutant ou en le modifiant au fur et à mesure. Sans cela, vous ne ferez que sauter ici et là sans jeter les bases nécessaires. La moitié de ce que vous avez enseigné sera rapidement oublié et vous risquez de rater beaucoup d'étapes en supposant qu'ils comprennent quand en fait ils se sont perdus une demi-heure à l'avance et n'ont aucune idée de ce que vous faites.

Il semble que vos collègues aient des connaissances techniques générales, mais ne sont pas qualifiés dans les technologies spécifiques dont vous avez besoin. Cela semble être une excellente opportunité pour les cours en ligne tels que Plurarsight ou Egghead.

La vérité est que la plupart d’entre nous ne sont pas de grands enseignants car être enseignant est un ensemble de compétences différent de celui avec lequel nous sommes normalement formés. Au lieu de cela, pourquoi créer des plans de cours sur les bases de la technologie alors qu'il y en a déjà beaucoup qui existent déjà?

Vous avez mentionné que la direction souhaite vous voir mettre en place un plan, alors pourquoi ne pas demander à la direction un abonnement Pluralsight et dépenser quelques heures par semaine pour suivre l'un des cours? De cette façon, vous avez

1. Un plan de cours de haute qualité sur lequel vous n'avez pas eu à passer du temps.
2. Il est entièrement externe, donc il n'y a pas de facteur de bus à l'enseignement .
3. Un environnement ouvert où les gens peuvent poser des questions et collaborer.
4. Une opportunité pour vos collègues de s'auto-apprendre à leur rythme.
5. Une chance pour vous de revoir toutes les bases que vous avez peut-être manquées ou que vous avez mal vues.

Si ce que je lis est vrai - que vous êtes le seul survivant de la connaissance, - votre propre sécurité d'emploi peut être en jeu dans le sens où vous pourriez être bloqué si vous le faites et bloqué si vous ne le faites pas. place le transfert de connaissances.

Je sais que l'entreprise pour laquelle j'ai marché a reconnu une situation où tous ses œufs étaient dans le même panier (du point de vue des compétences techniques) et a décidé de mettre fin à un projet et de couper une unité commerciale / division plutôt que essayez de se creuser dans un trou dans lequel ils n'auraient jamais dû entrer en premier lieu. Le talentueux développeur principal a été licencié lorsqu'il est devenu clair que les technologies utilisées avaient été remplacées et que le rapport coût-bénéfice de conserver une capacité n'en valait pas la peine.

La vraie question est ... (indépendamment de tout problèmes de contrôle de la qualité - car il semble que l'entreprise a peu à perdre à cet égard à l'heure actuelle) - l'entreprise peut-elle tous vous tromper - en prenant tout cela à l'étranger en utilisant plus de personnel coûtant une petite fraction des cadeaux?

Si "oui", alors le temps est déjà compté pour vous, il se peut que chaque homme / femme soit pour lui-même - donc je serais plus concerné par votre propre recyclage. Reconnaissance en tant que responsable RH / formateur en gestion des connaissances (si vous le pouvez que l'entreprise paie pour cela) peut être un bon filet de sécurité.

Si la réponse à cette question était "non", alors je vous souhaite la meilleure des chances de vous tenir à la barre, - parce que si le la gestion stratégique de votre entreprise est aussi impitoyable que l'un de mes anciens employeurs - vous en aurez peut-être besoin.

En supposant qu'ils veulent apprendre, faites-leur suivre un cours d'introduction aux technologies / langages / etc que vous utilisez. Cela n'a pas besoin d'être sophistiqué, juste quelque chose pour les démarrer. L'argent de l'entreprise est bien mieux dépensé pour obtenir un enseignement professionnel de quelqu'un qui est un enseignant professionnel plutôt que de vous chausser dans le rôle.

Personnellement, j'apprends beaucoup mieux en faisant qu'en me faisant dire par quelqu'un. La programmation est un métier et une compétence, pas une question de mémorisation par cœur. Vous devriez le faire avec eux aussi. N'entrez pas dans une salle de réunion avec eux et ne parlez pas pendant des heures. Sortez les ordinateurs et faites de la vraie programmation.

Commencez petit, vraiment petit. "Ecrivez cette petite application", "modifiez ce petit script". Des changements simples avec un début et une fin définis qui ne devraient prendre que quelques heures. Les premières fois, asseyez-vous avec eux et suivez le processus. Vous pourriez même envisager la programmation par paires ou similaire. Demandez-leur de vous suivre pendant une journée et de commencer à faire le travail, mais à chaque fois que vous les faites, faites-les faire de plus en plus pendant que vous donnez des conseils et à la fin, regardez simplement.

Rien que de l'expérience ne se passe pour leur donner de l'expérience. Donc, la meilleure chose que vous puissiez faire est de leur donner cette opportunité tout en fournissant des conseils et en protégeant l'entreprise contre toute erreur potentielle.

En tant que personne occupant une position légèrement similaire, je ne saurais trop insister pour documenter à la fois vos processus et votre code, et les tenir à jour. Même s'il existe déjà de la documentation, cela ne fait pas de mal de la réécrire et de mettre en évidence les étapes qui peuvent ne pas être claires ou qui ont changé au fil du temps. Vous devriez le faire, que vous soyez ou non responsable de la formation, au cas où vous seriez renversé par un bus.

Commencez par documenter vos processus réguliers. Rédigez un plan et remplissez les détails.

S'il y a un codage impliqué, assurez-vous qu'il existe au moins un ensemble de normes de base que tout le monde comprend et respecte.

N'oubliez pas de partager les documents avec vos collègues avant de planifier la formation, afin qu'ils puissent les consulter et poser des questions.

En ce qui concerne la formation elle-même, une chose que j'ai faite dans le passé est de m'asseoir et d'observer mes collègues pendant qu'ils font le travail.

L'enseignement est un ensemble de compétences entièrement différent - il faudra beaucoup de temps et beaucoup de pratique pour devenir bon. Je pense que votre meilleur pari sera de réduire votre travail.

Vous avez dit que la direction voulait surtout que vous montriez que vous essayez, ce qui est bien. Cependant, je suis sûr que vous et vos collègues n'aimez pas perdre leur temps, alors vous devriez probablement essayer de faire en sorte que les efforts que vous dépensez en valent la peine.

Si j'étais à votre place, la première chose que je ferait est de rencontrer vos collègues et de leur demander ce qu'ils souhaitent apprendre. Cela réduira considérablement la quantité de choses que vous pourriez leur apprendre. Vous aurez également une idée de ce qu'ils pensent être leurs forces et leurs faiblesses, et comment cela correspond à votre perception. Cela vous donnera ce dont vous avez besoin pour concevoir le premier «cours». Envisagez de vous rencontrer en tête-à-tête si possible, car les gens seront plus honnêtes.

Pour votre premier cours, n'atteignez pas trop haut. En utilisant ce que vous avez appris de vos premiers exposés, dressez une liste des 1 à 3 concepts ou compétences les plus importants dont vous aurez besoin pour les enseigner. S'ils sont courts, allez-y avec 3, sinon, restez-en un. Ensuite, prévoyez de passer environ une heure à leur apprendre ces choses. Imaginez que vous en savez autant qu'ils en savent sur le sujet. De quelles informations auriez-vous besoin pour apprendre la compétence ou le concept? Quels exercices vous aideraient à les pratiquer? Créez une courte conférence et un exemple d'exercice pour chaque sujet. Créez également un très court devoir de "devoirs" pour leur donner de la pratique.

Faire tout cela prendra quelques jours - afin que vous puissiez voir pourquoi il est important de limiter votre champ d'action autant que possible. Après votre premier «cours», vous aurez une bien meilleure compréhension de ce que sont vos forces et faiblesses en termes d’enseignement. Maintenant, votre mission est de travailler sur les faiblesses tout en continuant à concevoir et à enseigner des cours courts sur le modèle de ce qui a fonctionné dans le premier.

Pendant que vous suivez ces cours, gardez vos notes organisées. Ceux-ci deviendront votre documentation. Au fur et à mesure que vous vous améliorerez dans l'organisation et la communication des informations, la documentation s'améliorera et facilitera également l'enseignement.

Il sera difficile de vous apprendre à enseigner, mais vous avez en fait un avantage à être vous-même - développeur enseigné - vous savez ce dont vous aviez besoin pour être bon dans votre travail. Beaucoup de gens qui n'ont eu que de bons professeurs n'apprennent jamais à comprendre cela par eux-mêmes. L'inconvénient est que vous ne connaissez pas non plus la plupart des techniques d'enseignement standard ou des moyens de structurer la formation, vous devrez donc apprendre cette partie au fur et à mesure. Je chercherais les manuels standard dans la langue ou le domaine dans lequel vous travaillez. Cela vous donnera des exemples sur la façon de structurer les connaissances.

Bonne chance!

La plupart des réponses semblent supposer que les sujets veulent apprendre (par exemple, Tim B). Je prendrais du recul et confirmerais cette hypothèse, avant de comprendre le «comment». Lorsque les apprenants sont désengagés et démotivés, la formation ne sera pas efficace aussi bonne soit-elle, en particulier dans une discipline pratique où la pratique est absolument essentielle à l'acquisition des connaissances et à une utilisation efficace.

Je suppose que l'objectif est que ces développeurs de base de données deviennent compétents au point de remplir vos grandes chaussures, si nécessaire. Leur a-t-on demandé si cela semble être un excellent plan ou ont-ils sollicité de manière proactive une formation dans ces domaines? La prise de conscience d'un besoin commercial et une attitude proactive pour le réaliser sont des choses différentes, nécessitant un mélange différent de conditions pour les soutenir. Ainsi, même si ces développeurs peuvent hocher la tête lorsque le sujet est abordé par la direction lors de réunions, ils peuvent être au mieux passifs, voire ouvertement résistants en ce qui concerne l'apprentissage réel et le changement de comportement (comme objectif).

sont quelques avantages significatifs à prendre du recul et à confirmer la motivation à apprendre avant de se lancer avec des solutions:

1. Ajuster les attentes et l'approche: si les développeurs ne sont pas motivés et sont susceptibles de l'être apprenants passifs, il faudra une approche de formation, tandis que s'ils sont proactifs à ce sujet, l'approche serait différente (par exemple, moins de supervision / prise en main requise, structure d'incitation différente / suivi des progrès, plus ou moins d'autonomie donnée aux apprenants, plus ou moins moins de flexibilité requise en termes de choix des sujets, d’ordre des sujets, de modalités de présentation, etc.).

2. Gain de temps et d'efforts en s'assurant que la stratégie de formation adoptée correspond aux besoins et aux objectifs des apprenants pour la formation (par exemple, en évitant de consacrer du temps / de l'argent à la création d'aides à l'emploi ou en les abonnant à des cours en ligne, pour en constater une utilisation minimale /le progrès). Lorsque les gens ne veulent pas faire quelque chose, ils ont tendance à exceller pour trouver des excuses créatives et des justifications pour ne pas le faire (par exemple, charge de travail, différents styles d'apprentissage). Il peut être difficile, voire impossible, de discerner lesquelles de ces excuses sont valables et lesquelles ne le sont pas.

3. Partir du bon pied. Un excellent moyen de s'assurer que la formation échouera est de l'exiger (forcer) les participants. D'un autre côté, un excellent moyen de maximiser le retour sur investissement de la formation est de créer une structure d'incitation telle que les participants seraient intrinsèquement motivés à s'engager dans le matériel (c.-à-d. l'objet). Dans ce dernier cas, les participants adapteront eux-mêmes le contenu à leur style d'apprentissage, l'intégreront à leur emploi du temps, rythmeront l'apprentissage de manière appropriée, etc. Le meilleur type d'apprenti est celui qui prend toutes ces décisions individualisées pour lui-même, avec peut-être des conseils / conseils de l'extérieur (quand ils en ont besoin). Pensez simplement au mal de tête que cela peut vous faire économiser et au crédit que vous pouvez prendre pour amener ces personnes à apprendre par elles-mêmes - si vous réussissez à atteindre un tel apprentissage auto-motivé de leur part (qui peut ou non être possible).

J'espère que ces réflexions vous aideront à réfléchir plus largement à ce qui se passe (ou non) en termes de présentation et de structuration de la formation, à faire quelques ajustements qui aideront à maximiser son efficacité à long terme. Bonne chance!

Beaucoup de bonnes idées. Jusqu'à présent, je n'ai vu aucune recommandation sur le développement de petites vidéos à l'aide d'outils de capture d'écran. Documentez les processus à l'aide de PSR.exe que beaucoup de gens ne connaissent pas cet outil, mais il est intégré à Microsoft O / S. C'est un didacticiel d'écran que vous pouvez annoter.

Ne présumez rien de leurs connaissances. Validez-le. Au lieu de dire qu'ils sont sous-qualifiés, laissez une autorité respectée leur expliquer. Microsoft, Brainbench, je suis sûr qu'il y a plus de fournisseurs de tests là-bas. Brainbench avait l'habitude de montrer les points faibles et les points forts, ainsi que le score du test et où vous vous situez - tout cela peut être utilisé. Faire un test standardisé est important car il élimine le facteur subjectif.

Une fois la base de référence prise, ne formez pas les compétences de base. Laissez les autres le faire pour vous. Les cours en ligne, tels que Udemy, Pluralsight et d'autres, peuvent aider tout le monde à revenir à la base. C'est beaucoup moins cher que toute autre alternative. Et ils peuvent faire un meilleur travail pour deux raisons:

• Vous êtes peut-être dépassé de quelques années. Au moment où tout le monde sera formé, l'écart sera plus grand. Pour rester à la fine pointe de la technologie, vous devez arrêter de faire des affaires, la plupart des gens ne peuvent pas se le permettre.

• Ils savent se former. Et oui, il y a de la science derrière l'enseignement. Vous ne pouvez pas simplement transférer des connaissances dans le cerveau de quelqu'un d'autre via USB. Vous ne pouvez pas non plus en parler et espérer que votre élève se souviendra de quoi que ce soit. Beaucoup de psychologie impliquée.

Si vous voulez améliorer vos chances de succès, recherchez et choisissez des cours pour eux. Malheureusement, il y a beaucoup de déchets disponibles en ligne.

Prochaine étape (ou vous pouvez le faire en parallèle) - Documentez ce que vous savez sur les applications que vous avez construites à un niveau élevé. Supposons que vous ayez besoin d'expliquer à un autre développeur comme vous qui connaît la pile, beaucoup d'expérience, y compris les dernières astuces, mais qui vient de rejoindre l'entreprise et ne sait rien de votre code.

Commencez à sonder les gens si votre documentation logique. Laissez-les poser des questions. Agréger, voir quel domaine soulève le plus de préoccupations. Entrez dans les détails ici. Rincez, répétez.

Il existe une réponse différente au problème du "facteur bus". Si quelque chose se passe (je préférerais penser à vous gagner à la loterie et décider d'arrêter sur-le-champ, pas à une rencontre avec un vrai bus), bien sûr, l'entreprise est dans une mauvaise passe. Mais les choses fonctionneront pendant un certain temps sans vous, et c'est la situation où vous obtenez un entrepreneur pour une solution à court terme, et vous embauchez un nouveau développeur avec l'expérience appropriée par la suite.

Bien sûr, ils devront payer beaucoup d'argent pour un bon entrepreneur qui pourra prendre le relais de votre travail. Mais quelqu'un qui est vraiment bon dans ce domaine n'aura aucun problème à vous remplacer. Et après quelques mois, laissez les choses en bon état pour qu'un développeur moyen prenne le relais. Le recyclage de vos collègues pour qu'ils puissent faire un travail qu'ils ne feront probablement jamais sera à la fois coûteux et pas très utile.

Assurez-vous simplement qu'il n'y a rien dans votre esprit et nulle part ailleurs. Procédures à suivre pour que les choses fonctionnent. Les mots de passe nécessaires (et que vous n'êtes pas censé noter). Et au lieu de documenter les choses, lorsque vous faites des choses où les procédures doivent être suivies, demandez à votre patron de vous donner une secrétaire pendant quelques heures qui écrit exactement tout ce que vous faites et qui est strictement chargée de ne laisser aucun détail.

Faites-leur faire votre travail pendant un certain temps.

Par exemple, si votre travail en tant que développeur d'applications consiste à développer une application, assignez-leur votre prochaine tâche de développement d'applications.

Dites-leur que:

• Vous voulez qu'ils fassent le travail
• Vous êtes disponible pour répondre à leurs questions
• Vous attendez de se charger de vous poser des questions

Parce que:

• Vous ne savez pas ce qu’ils ne savent pas (que vous devez dire leur); donc, au lieu de vous demander quoi leur dire, il est plus efficace qu'ils vous disent ce qu'ils ne savent pas et veulent savoir (en posant des questions).
• Cela leur demande de vouloir faire le travailler et s'engager à trouver comment.
• Cela garantit que toute la formation est pertinente pour la tâche à accomplir: qu'elle est nécessaire et suffisante.

Étant donné que vous êtes capable de faire le travail, vous êtes probablement capable (si on vous le demande) d'expliquer n'importe quel aspect spécifique de celui-ci avec n'importe quelle quantité de détails.

Attendez-vous à ce que cette (formation) prenne un certain temps. Espérons que la direction s'y attend et qu'elle soit d'accord avec cela. Lorsque j'ai aidé (formé) de nouvelles recrues de cette façon, j'ai estimé qu'il me faudrait autant de temps pour expliquer une tâche en détail qu'il faudrait en fait la terminer moi-même; cela a pris encore plus de temps que pour le nouvel employé. Par exemple, un travail (par exemple une nouvelle fonctionnalité) qui pourrait me prendre trois jours à faire par moi-même me prendrait trois jours à expliquer en détail, et prendrait le stagiaire quelques semaines.

, ou gain de temps), par conséquent, ce n'est pas immédiat: le gain est des mois plus tard, lorsque la nouvelle recrue est à la hauteur et est capable de travailler plus ou moins indépendamment.

Oh oui, en plus de les amener à poser des questions ad hoc , vous devriez faire des révisions / inspections de code de tout ce qu'ils finissent. Lorsqu'ils disent qu'ils sont prêts pour une révision de code, votre première question pourrait être "Avez-vous testé ceci?" Dans votre revue de code, vous recherchez des bogues évidents. La clarté idéale à viser est que le code est complet non pas quand "il n'a pas de bogues évidents", mais quand "il n'a manifestement aucun bogue".

Vos critiques de révision de code devraient être soit:

• Doit corriger immédiatement, avant l'enregistrement (par exemple, un bogue, ne répond pas aux exigences ou ne peut pas être maintenu)
• Facultatif (par exemple, "Je vois ce que vous avez fait, et ce n'est pas un bug, mais pour info, je l'aurais fait de cette façon ")

Apprendre à enseigner

Vous êtes un programmeur informatique et non un enseignant, cependant, il fut un temps où vous n’étiez pas un programmeur informatique. Tout comme vous avez appris à faire le premier, vous pouvez apprendre à faire le second.

Parlez à votre entreprise de la manière de vous apprendre à éduquer les autres.