Jeux de société éducatifs pour les programmeurs

Il existe une situation intéressante sur le marché du travail dans le développement Java. Il y a plus de 100 000 CV actifs pour les développeurs et un poste vacant par CV. Dans le même temps, les employeurs et les agences de recrutement se plaignent du manque de personnel et malgré des milliers de CV, il est difficile de trouver un bon spécialiste. Par exemple, un développeur Java a un produit rare: il est rare, ses coupes ne sont pas affectées, les salaires augmentent et la concurrence baisse. Nous n'enquêterons pas sur les causes du phénomène, mais nous parlerons de l'une des façons de résoudre ce problème.



Vous pouvez chercher des spécialistes techniques pendant longtemps, mais le travail n'attend pas, vous devez donc embaucher pas assez de personnel qualifié et vous former au processus. Des options: auto-apprentissage dans votre temps libre ou cours et séminaires sur le lieu de travail, mais vous pouvez choisir des jeux. Artyom Larin ( artem_larin ) expliquera pourquoi les méthodes d'enseignement traditionnelles ne sont pas fiables et pourquoi les jeux sont d'une certaine manière meilleurs que d'autres.

Les jeux de société en équipe spéciaux enseignent non seulement des sujets complexes de développement de logiciels, impliquant activement chaque participant, mais forment également un langage technique commun dans l'équipe, et résolvent également le problème de l'esprit d'équipe et forment une culture d'entreprise.



À propos du conférencier: Artyom Larin à Java depuis 2004. Il travaille en tant que développeur principal et en tant que senior, forme régulièrement des collègues, donne des conférences et des séminaires de formation internes. Malheureusement, il y a eu une expérience d'apprentissage négative qui a conduit Artyom à l'idée que les jeux de société sont ce qui est nécessaire au développement.



Il s'agira de pomper dans l'équipe non pas des compétences techniques difficiles, mais difficiles. Le rapport se compose de deux parties: humanitaire et créative. Même si vous n'êtes pas un technicien, dans la deuxième partie, vous devrez forcer votre cerveau humanitaire, car sans informations techniques, nulle part - je parlerai des compétences et de leur mise à niveau.

Problèmes informatiques

Je crois qu'il y a un gros problème dans les TI - et c'est une pénurie de personnel . La question a été discutée à plusieurs reprises, il existe des statistiques de hh.ru et des publications sur ce sujet. Au cas où, vérifiez les statistiques nous-mêmes. Si vous entrez «Java» dans le moteur de recherche hh.ru, nous verrons 5-6 mille emplois en Russie, et le nombre de CV sur le même hh.ru est supérieur à 100 000. Il semble que les développeurs ne manquent pas - le CV est d'un ordre de grandeur plus grand que les offres d'emploi .





Regardons de l'autre côté. Le site hh.ru possède un index spécial, appelé hh-index . Il s'agit du rapport entre les CV actifs et les postes vacants. Pour une demande Java, elle est approximativement égale à un: pour un poste vacant, un CV. Encore une fois, il s'avère qu'il n'y a pas de pénurie de personnel? L'entreprise a besoin d'un programmeur, elle ouvre un poste vacant et, selon l'indice, la personne âgée devrait immédiatement venir chercher un emploi et fermer le poste vacant.

Le seigneur "doit" venir, mais ne vient pas. Les chiffres indiquent qu'il n'y a pas de pénurie de personnel, mais dans le monde réel, et non dans le monde de l'indice hh, c'est le cas. Java est une profession super rare. Il y a une chasse sanglante aux seniors Java: les RH et les recruteurs les assaillent d'offres d'emploi. En moyenne, un développeur Java reçoit 5-6 offres , même s'il est employé.

Quelle est la question? D'où vient la pénurie de personnel? D'après mon expérience d'entrevue personnelle, je crois que le problème est que la plupart des demandeurs d'emploi qui envoient un curriculum vitae et viennent pour des entretiens ont une éducation insuffisante et de faibles qualifications. Mais comme il y a pénurie de personnel, les entreprises sont obligées d'embaucher ces personnes et de se former par elles-mêmes - des personnes hautement qualifiées passent leur temps à former des personnes peu qualifiées.

Nous ne pouvons pas vaincre la famine du personnel - seulement pour déclarer. Par conséquent, nous adaptons et résolvons le problème d'autre part - nous nous entraînons. Réfléchissons à la façon d'éduquer les gens de l'industrie informatique.

Façons d'apprendre dans l'industrie informatique

En 1980, les National Training Laboratories des États-Unis ont mené des recherches sur l'efficacité des différentes méthodes de formation. Il s'est avéré que les conférences et les livres de lecture ont une efficacité extrêmement faible - seulement 5-10% . Ensuite, regardez des conférences vidéo et écoutez de l'audio. L'efficacité maximale de 90% est la formation par des personnes d'autres personnes - le mentorat et l'application immédiate des connaissances acquises dans la pratique.





Sur la base de la pyramide des formations, nous procéderons à une analyse express des méthodes de formation informatique.

Cours

Vous avez sûrement rencontré de la publicité contextuelle sur Internet qui promet de transformer les débutants en programmeurs professionnels: "Devenez développeur en 3 mois". J'ai moi-même suivi de tels cours plusieurs fois par intérêt et je les ai conseillés à mes élèves. Je peux dire que oui, ces cours sont efficaces, mais ils ont deux problèmes: seules les connaissances de base sont données dans les cours - elles ne transformeront pas le juin en senior, et l'efficacité de la formation ne dépasse pas 20% . Les cours sont un moyen inefficace, nous l'oublierons donc.

Ateliers internes

J'adore les séminaires internes et les ai maintes fois tenus. Je crois qu'ils ne sont efficaces que si le public interagit de manière interactive avec l'enseignant. Malheureusement, c'est rarement le cas. Habituellement, les gens viennent à un séminaire, prennent place et écoutent passivement un conférencier en buvant des mouettes. Aucune interactivité, faible efficacité - maximum 50% . Par conséquent, les séminaires peuvent également être oubliés.

Conférences

L'objectif de la conférence est de présenter les innovations de l'industrie, mais pas la formation hardcore. Les conférences sont de la communication , de nouvelles idées, mais pas de la formation - l'efficacité dans ce cas n'est que de 5 à 30%. Les conférences ne sont pas non plus ce dont nous avons besoin.

Auto-apprentissage

Comme la plupart de mes amis, programmeurs, je suis entré dans la profession grâce à l'auto-éducation. C'est une méthode efficace, je lui donnerais 75% d'efficacité , sinon pour un énorme inconvénient - une liste de livres à étudier.



Voici une liste que je donne aux personnes qui souhaitent devenir développeurs Java et écrire du vrai code de l'industrie. Quand je le montre aux débutants, je vois dans leurs yeux la peur, le désespoir et le désespoir . L'enthousiasme s'éteint rapidement.

Pour devenir programmeur, une personne doit passer par le «plateau du désespoir». Selon ce concept, après qu'une personne a reçu des connaissances initiales dans le sillage de l'enthousiasme, une longue période survient lorsqu'elle ne reçoit plus de connaissances et que l'estime de soi diminue rapidement.



Par analogie avec le «plateau du désespoir», j'ai introduit le concept de «mur du désespoir». Il s'agit d'un mur de 15 livres épais, qui ne permet pas à des centaines de milliers de développeurs débutants avec hh.ru d'accéder aux 5 000 postes vacants actifs des seniors et des intermédiaires.



Il s'avère que pour devenir développeur, un débutant passe du temps sur l'auto-éducation, et non sur une famille ou un passe-temps. Il semble que cette méthode ne soit pas non plus très bonne.

Mentorat et coaching

C'est le moyen le plus efficace, selon la pyramide d'apprentissage - 90% d'efficacité . Mais il a aussi des inconvénients qui ne permettent pas d'appeler cette méthode une «pilule magique».

Le mentorat est toujours un ratio de 1: 1 , c'est-à-dire un mentor et un menti - l'apprenant . Dans ma pratique, je n'ai pas vu de cas où un mentor peut former 10 personnes. Le mentorat est très mal dimensionné et distrait les personnes âgées du travail principal. Je peux dire personnellement par moi-même - j'avais 2 menti, maximum. Et en même temps, la moitié de mon temps de travail, et parfois plus, était consacrée au mentorat, et non à la résolution de tâches de production pour lesquelles j'étais payé. Par conséquent, 3-4 personnes ou plus, il est impossible de mentorer, si nous parlons d'un mentorat de haute qualité.

Études à long terme - 1-2 ans. D'après mon expérience, un programmeur travaille en moyenne 2 ans dans une entreprise. Cela se révèle triste: vous encadrez une personne, vous lui transmettez des connaissances, puis quelqu'un quitte - vous ou lui, et tout mentorat ne va nulle part.

Le mentorat est efficace, mais en raison des lacunes, j'ai pensé - pourquoi ne pas trouver un moyen qui serait efficace comme mentorat, mais sans les inconvénients: amusant, intéressant et évolutif. En pensant, j'ai eu l'idée des jeux - c'est amusant, j'aime les gens et ça résout les problèmes de mentorat.

Jeux!

Quels jeux connaissons-nous? Les dames, les échecs, les bobines et les dominos sont une occupation intellectuelle, malgré la simplicité.



Les cartes sont aussi un jeu intellectuel. Qui n'aime pas le classique, il y a "Magic: The Gathering". De nombreux informaticiens adorent ce jeu, y compris moi. De nombreuses sociétés informatiques organisent des tournois entiers qui lui sont dédiés.



Tous ces jeux sont des jeux pour le divertissement, pas pour les programmeurs, et je me suis demandé - y a-t-il des jeux pour les programmeurs? Et j'ai trouvé, par exemple, un tel jeu.



Le joueur fonctionne avec des blocs de couleur, compile le code source à partir d'eux pour contrôler l'astronaute. Évidemment, le jeu est complètement enfantin, je dirais - la maternelle. Elle ne transforme pas le joueur en senior.

Ensuite, le jeu est brusquement: paysage 3D et héros-robot en trois dimensions.



Dans certains langages de type C, vous devez écrire un pseudo-code pour contrôler le robot.

Voici une capture d'écran du troisième jeu que j'ai trouvé.


Ici, encore une fois, sur un pseudo-code, vous devez écrire un programme pour contrôler le personnage: le déplacer dans le labyrinthe, ouvrir et fermer des portes, manipuler des objets.

Tous les autres jeux sont similaires à ces trois, et tous ont de nombreux défauts graves.

Inconvénients du jeu

Ces jeux n'enseignent que des concepts de base - tels que les variables, les boucles, les fonctions - quelque chose que même les juniors apprennent à l'institut. Les jeux sont séparés des vraies tâches industrielles , car ils n'ont ni multithreading, ni transactionnalité - tout ce que le senior ou le middle connaît. Des jeux comme celui-ci ne sont pas enseignés, et c'est leur problème.

Le joueur contrôle le personnage ou le "robot" , alors qu'en réalité les seigneurs et les intermédiaires travaillent avec des objets métier très complexes. Et d'ailleurs, le joueur est toujours seul , alors qu'en informatique il travaille en équipe. Tout projet logiciel est un travail d'équipe. Étant donné que de nombreux programmeurs sont passés d'introvertis et que le travail d'équipe est souvent difficile pour nous, j'aimerais que le jeu renforce également les compétences de l'équipe.

Expérience de jeu personnelle

Dans le même temps, il existe une riche culture des jeux de société dans le monde: Munchkin, Magic: The Gathering, Dungeons & Dragons. Mais, malheureusement, je n'ai pas rencontré le «bureau» pour les programmeurs.

Personnellement, moi et toute ma famille: épouse, fille et chat Tishka, nous adorons les «ordinateurs de bureau». De plus, ma fille et moi adorons les créer. Nous avons inventé le jeu selon le populaire programme à la fois «Revizorro» et divers autres jeux d'aventure. Dans ces photos simples, il y a 3 exemples de nos «ordinateurs de bureau».



Comment ai-je eu l'idée de jeux de société pour les programmeurs? J'ai traversé quatre étapes: l' expérience négative de la formation des employés, l' analyse décevante des jeux actuels , l' expérience de jouer des «trucs» et l' expérience de les créer . Tout cela m'a conduit au "bureau" des programmeurs. En effet, pourquoi ne pas faire le jeu vous-même?

Exigences du jeu

Combien devrait-il être futuriste ou terre à terre?



Une courte session de jeu ne dure pas plus de 15-20 minutes, car comme prévu, vous devez jouer à ce jeu pendant les heures de travail. Jouant pendant plus de 20 minutes, les gens se laisseront emporter et abandonneront le processus de production, et les patrons marcheront et tondront. Par conséquent, 20 minutes sont idéales: nous avons joué et continué à travailler.

Le jeu devrait enseigner de vraies tâches industrielles auxquelles sont confrontés de vrais seniors et intermédiaires: multithreading, JPA, bases de données et structures de données simultanées . Ce sont des sujets qui souvent ne permettent pas aux juniors de sauter dans la tête d'un certain niveau technique et de devenir seniors. Je ne parle pas seulement de Java, mais en général de tous les langages, y compris Python, C ++ - partout où il y a du multithreading, des bases de données et des structures simultanées.

La prochaine tâche que le jeu devrait résoudre est de pomper les compétences en travail d'équipe : la formation d'un langage technique unique au sein de l'équipe et la capacité de discuter du code. Maintenant, presque toutes les entreprises ont une révision du code, et une situation est souvent rencontrée: les développeurs, en particulier les débutants, voient le code source, mais ne peuvent pas décrire avec des mots ce qui s'y passe. Ils peuvent écrire du code, mais ils ne peuvent pas en discuter - il n'y a pas de dictionnaire technique dans la tête. J'aimerais que le jeu pompe ce dictionnaire technique. De plus, le fait d'avoir un langage technique vous aide à rédiger une documentation de qualité.

Le team building est une exigence que les RH apprécieront. Je ne parle pas du teambuilding, où les gens se rassemblent et boivent de l'alcool, mais des réunions où ils discutent du code source. Il y a un tel team building, et la tâche du jeu réside en lui.

Pour faire plaisir au seigneur et à l'équipe. Je veux que le jeu soit apprécié personnellement par moi, en tant que senior et leader de ce jeu, et par l'équipe - afin que ce soit intéressant, amusant, peut-être même quelque part de manière provocante.

La dernière exigence est très importante - le jeu doit être un vrai jeu de société réel, pas en ligne, uniquement hors ligne . Plusieurs fois, on m'a demandé d'écrire une version en ligne de ce jeu, mais j'ai toujours refusé. Beaucoup connaissent le jeu de Go, mais tout le monde ne sait pas que dans un vrai jeu chinois, les jetons noirs sont faits de basalte et de blanc - à partir d'un coquillage spécial. Les jetons en plastique ne sont plus le jeu de Go. Les Chinois sont sensibles aux sensations tactiles pendant le jeu - ils devraient en faire partie. Je pense exactement la même chose. Par conséquent, mon jeu doit également être vivant et donner du plaisir tactile.

Un exemple de "Tables"

Le jeu que j'ai développé s'appelle "Who Stole the Monitor?" Puisque nous sommes tous des techniciens, nous savons que le moniteur n'est pas la télévision que nous regardons au travail, mais le concept du multi-threading. L'objectif du jeu est d'initier en collaboration l'équipe à l'impasse dans le multithreading Java . Les joueurs d'une équipe ne se font pas concurrence, mais résolvent ensemble un problème commun - un véritable team building. J'ai choisi le sujet du multithreading, car c'est la barre du mois de juin, à travers laquelle il ne peut souvent pas sauter, et commencer à écrire un très bon code industriel. Les affaires nécessitent de grandes capacités de notre part, et presque tous les programmes industriels sont multithread . Par conséquent, il est essentiel pour les entreprises et les programmeurs de savoir ce qu'est le multithreading.

Éléments du jeu

Le premier élément est le champ Code source sur une grande feuille de carton épais. Il montre un certain morceau de code - dans notre langage Java.



L'élément suivant est les baguettes des lignes actuelles . Ce sont des cadres colorés en fil de fer.



Chaque joueur déplace à son tour son personnel de flux à travers le code source, affichant ainsi la barre de progression actuelle.



Le jeu a deux terrains de jeu. Le premier est une machine d'état - des carrés et des flèches avec des inscriptions.



J'ai pris la machine d'état de la documentation Java standard. Chaque senior, middle et même un junior devrait connaître cette machine d'état par cœur, mais d'après mon expérience, tous les développeurs Java ne le savent pas, beaucoup écrivent du code sans cette connaissance. L'une des tâches du jeu est de pomper des compétences pour connaître la machine d'état des threads Java .

L'élément suivant est les jetons de flux double face .



D'un côté, les yeux fermés sont dessinés - cela signifie que le flux est inactif. De l'autre côté - un homme qui court - un flux est actif.

Je vais illustrer comment les puces se déplacent autour de la machine d'état. Si le thread a commencé à fonctionner, alors le joueur déplace le jeton d'état vers le « nouvel» état - l'état initial lorsque le thread vient d'être créé.



Pendant le jeu, à la suite de certains événements, le joueur déplace la puce à l'état " exécutable" , sans oublier de la retourner avec le côté sur lequel le petit bonhomme en cours d'exécution est tiré, ce qui signifie que maintenant son flux fonctionne.



L'élément suivant du jeu est les cartes de contrôle .



Ces cartes se trouvent d'abord dans la pile commune, puis les joueurs les prennent en main. Chaque moniteur est attaché à un objet Java, dont il existe deux: «un» et «deux».

Le dernier élément est les heures des flux .



Probablement, tous les techniciens savent que les fils peuvent "s'endormir" pendant un certain temps. Pour mesurer ce temps dans le jeu, il y a des montres où vous pouvez déplacer les mains.

Considérez quelques mouvements d'une session de jeu.

Exemple de session de jeu

Nous avons trois joueurs:

• Michael travaille pour le thread «principal» - le thread Java principal.
• Eugene - flux "t1".
• Svetlana - le flux "t2".

Chacun des joueurs se met à la place de l'un des streams et vit sa vie dans le processus de jeu. Il comprend donc ce que signifie être un thread Java.

Michael déplace la baguette de flux vers la première ligne de code.



Eugene et Svetlana dorment toujours - leurs fils n'ont pas été créés, et Mikhail déplace son personnel de flux vers la ligne de code suivante, où il est indiqué <code> Thread t1 = nouveau Thread () </code> - cela signifie que le flux sera créé Eugene "t1" .



Eugene ne bâille pas, prend sa puce de flux et la met dans l'état «exécutable» - du côté de l'homme qui court.

Exemple de travail d'équipe

Svetlana dit à Eugene:

• Eugene, pourquoi avez-vous mis la puce de votre flux non pas dans le "nouvel" état, mais immédiatement dans l'état "exécutable"?

• Pourquoi pas?

On peut voir qu'Eugene est le junior le plus inexpérimenté de l'équipe, mais Svetlana est plus expérimentée et dit:

• Eugene, selon la machine à états, l'état initial du flux est «nouveau».

Eugene est d'accord avec Svetlana et déplace la puce de son flux dans la bonne position.



Ceci est un exemple de la façon dont l'équipe transfère ses connaissances pendant la partie. Le jeu continue ...

À un certain moment, Michael fait déjà un commentaire à Eugene:

• Eugene, vous êtes entré dans le bloc synchro, mais vous avez oublié de faire quelque chose ...

• Exactement, j'ai oublié de prendre le moniteur de cet objet!

Eugène prend le moniteur de l'objet " un" . Il s'avère que le flux "t1" Eugene possède ce moniteur.



Vient ensuite le jeu: nombreux mouvements, omissions, travail avec l'horloge. En savoir plus sur la vidéo ou sur les diapositives de la présentation .

À la fin du jeu, Eugene a un moniteur et Svetlana en a un autre, et le flux de chacun d'entre eux est bloqué par l'attente des moniteurs . En conséquence, le flux "t1" et le flux "t2" sont tous deux dans l'état "bloqué", c'est-à-dire que nous observons un blocage.

Pendant la session de jeu, chacun des joueurs vérifiera personnellement, ressentira ce qu'est l'impasse, comment elle survient et ce que c'est.

Conclusions

La session de jeu est courte . 20 , , , . , — 1:n .

— . , , . Deadlock — — , «» — heisenbug, .

— . , , , . .

. , . : Delphi, — C++, — Haskell.

, Java- 20 . 5 , .



, — , , , . .

deadlock, :

• Race conditions — , .
• wait/notify .
• join/isAlive .

?

, , . , .

JPA- JEE/Spring. , JPA-.

Google, « JPA-».



, , — .



, «» .

• JEE.
• SQL.
• : , , HashMap.
• java.util.concurrent.

, , .

, , - . , - , . - , .

, . , . , : , , , . - , , .

— «». , . , . .

Linkedin-Artyom Larina ou sur GitHub. De là, vous pouvez télécharger les éléments et essayer de mettre en œuvre le jeu à la maison.

Ce rapport n'est que l'un de ceux qui nous ont aidés à comprendre la pertinence du sujet de la formation et du transfert de connaissances. En conséquence, le 26 avril, nous organisons KnowledgeConf entièrement dédié à cela. Et sur les méthodes d'apprentissage non standard modernes et sur le transfert d'expérience aux débutants, il y aura de nombreux rapports utiles . Rejoignez-nous et le problème de la croissance des employés et du partage des connaissances au sein d'une équipe cessera d'être insoluble pour vous.