Juegos de mesa educativos para programadores.

Existe una situación interesante en el mercado laboral en el desarrollo de Java. Hay más de 100,000 hojas de vida activas para desarrolladores, y una vacante por hoja de vida. Al mismo tiempo, los empleadores y las agencias de contratación se quejan de la falta de personal y, a pesar de miles de currículums, es difícil encontrar un buen especialista. Por ejemplo, un desarrollador de Java tiene un producto escaso: es raro, sus recortes no se ven afectados, los salarios están creciendo y la competencia está cayendo. No investigaremos las causas del fenómeno, pero hablaremos sobre una de las formas de resolver este problema.



Puede buscar especialistas técnicos durante mucho tiempo, pero el trabajo no espera, por lo que debe contratar personal no calificado y capacitarse en el proceso. De las opciones: autoestudio en tu tiempo libre o cursos y seminarios en el lugar de trabajo, pero puedes elegir juegos. Artyom Larin ( artem_larin ) explicará por qué los métodos de enseñanza tradicionales no son confiables y por qué los juegos son en algunos aspectos mejores que otros.

Los juegos de mesa de equipo especiales no solo enseñan temas complejos de desarrollo de software, involucrando activamente a cada participante, sino que también forman un lenguaje técnico común en el equipo, así como también resuelven el problema del trabajo en equipo y forman una cultura corporativa.



Sobre el orador: Artyom Larin en Java desde 2004. Trabaja como desarrollador líder y, como senior, capacita periódicamente a colegas, imparte conferencias y seminarios de capacitación interna. Desafortunadamente, hubo una experiencia de aprendizaje negativa que llevó a Artyom a la idea de que los juegos de mesa son lo que se necesita en el desarrollo.



Se tratará de cómo bombear en el equipo no es difícil, sino habilidades técnicas difíciles. El informe consta de dos partes: humanitario y creativo. Incluso si no eres un experto en tecnología, en la segunda parte tendrás que forzar tu cerebro humanitario, porque sin información técnica, en ninguna parte, hablaré sobre las habilidades difíciles y su nivelación.

Problemas de TI

Creo que hay un gran problema en TI, y esta es la escasez de personal . El tema ha sido discutido muchas veces, hay estadísticas de hh.ru y publicaciones sobre este tema. Por si acaso, revise las estadísticas nosotros mismos. Si ingresa "Java" en el motor de búsqueda de hh.ru, veremos entre 5 y 6 mil empleos en Rusia, y la cantidad de currículums en el mismo hh.ru es más de 100 mil. Parece que no hay escasez de desarrolladores: el currículum es un orden de magnitud mayor que las vacantes .





Miremos desde el otro lado. El sitio hh.ru tiene un índice especial, que se llama hh-index . Esta es la proporción de currículums activos y vacantes. Para una solicitud Java, es aproximadamente igual a uno: para una vacante, un currículum. Nuevamente, ¿resulta que no hay escasez de personal? La empresa necesita un programador, abre una vacante y, según el índice, la persona mayor debe venir de inmediato, conseguir un trabajo y cerrar la vacante.

El señor "debe" venir, pero no viene. Las cifras dicen que no hay escasez de personal, pero sí en el mundo real, y no en el mundo del índice hh. Java es una profesión súper escasa. Hay una sangrienta caza de cabezas para los adultos mayores de Java: RR.HH. y reclutadores que los asedian con ofertas para conseguir un trabajo. En promedio, un desarrollador de Java recibe 5-6 ofertas , incluso si está empleado.

Cual es el problema ¿De dónde vino la escasez de personal? Desde mi experiencia de entrevista personal, creo que el problema es que la mayoría de los solicitantes de empleo que envían currículums y acuden a entrevistas tienen una educación insuficiente y calificaciones bajas. Pero dado que hay escasez de personal, las empresas se ven obligadas a contratar a estas personas y capacitarse por su cuenta: las personas con altas calificaciones pasan su tiempo educando a personas con pocas habilidades.

No podemos vencer el hambre del personal, solo para declarar. Por lo tanto, nos adaptamos y resolvemos el problema por otro lado: entrenamos. Pensemos en cómo educar a las personas en la industria de TI.

Formas de aprender en la industria de TI

En 1980, los Laboratorios Nacionales de Capacitación en los Estados Unidos realizaron investigaciones sobre la efectividad de diferentes métodos de capacitación. Resultó que las conferencias y la lectura de libros tienen una eficiencia extremadamente baja, solo 5-10% . Lo siguiente es ver conferencias en video y escuchar audio. La eficiencia máxima del 90% es la capacitación por parte de personas de otras personas: la tutoría y la aplicación inmediata de los conocimientos adquiridos en la práctica.





Con base en la pirámide de capacitación, realizaremos un análisis expreso de los métodos de capacitación de TI.

Cursos

Seguramente conociste la publicidad contextual en Internet que promete convertir a los principiantes en programadores profesionales: "Conviértete en desarrollador en 3 meses". Yo mismo tomé tales cursos varias veces por interés, y se los aconsejé a mis alumnos. Puedo decir que sí, estos cursos son efectivos, pero tienen dos problemas: solo se brindan conocimientos básicos en los cursos: no convertirán el mes de junio en un senior, y la efectividad de la capacitación no es superior al 20% . Los cursos son una forma ineficiente, por lo que nos olvidaremos de ello.

Talleres internos

Realmente amo los seminarios internos y los he celebrado muchas veces. Creo que son efectivos solo si la audiencia interactúa interactivamente con el maestro. Desafortunadamente, este rara vez es el caso. Por lo general, las personas acuden a un seminario, se sientan y escuchan pasivamente a un profesor mientras beben gaviotas. Sin interactividad, baja eficiencia: máximo 50% . Por lo tanto, los seminarios también se pueden olvidar.

Conferencias

El objetivo de la conferencia es presentar innovaciones de la industria, pero no una capacitación intensiva. Las conferencias son comunicación , ideas nuevas, pero no capacitación: la efectividad en este caso es solo del 5-30%. Las conferencias tampoco son lo que necesitamos.

Autoaprendizaje

Yo, como la mayoría de mis amigos, programadores, ingresé a la profesión a través de la autoeducación. Este es un método efectivo, le daría un 75% de eficiencia , si no fuera por un gran inconveniente: una lista de libros para estudiar.



Esta es una lista que doy a las personas que desean convertirse en desarrolladores de Java y escribir código real de la industria. Cuando se lo muestro a los principiantes, veo miedo, desesperación y desesperanza en sus ojos. El entusiasmo se está desvaneciendo rápidamente.

Para convertirse en un programador, una persona necesita pasar por la "meseta de la desesperación". Según este concepto, después de que una persona ha recibido conocimiento inicial a raíz del entusiasmo, llega un largo período en el que ya no recibe conocimiento y la autoestima está disminuyendo rápidamente.



Por analogía con la "meseta de la desesperación" introduje el concepto de "muro de la desesperación". Este es un muro de 15 libros gruesos, que no permite que cientos de miles de desarrolladores principiantes con hh.ru ingresen a las codiciadas 5 mil vacantes activas de senior y middle.



Resulta que para convertirse en desarrollador, un principiante dedica tiempo a la autoeducación y no a una familia o un pasatiempo. Parece que este método tampoco es muy bueno.

Mentoring y Coaching

Esta es la forma más efectiva, según la pirámide de aprendizaje: 90% de eficiencia . Pero también tiene inconvenientes que no permiten llamar a este método una "píldora mágica".

La tutoría es siempre una relación 1: 1 , es decir, un mentor y un mentor : el alumno . En mi práctica, no he visto casos en los que un mentor pueda capacitar a 10 personas. La tutoría está escasamente escasa y distrae a las personas mayores del trabajo principal. Puedo decir personalmente por mi cuenta: tuve 2 menti, máximo. Y al mismo tiempo, la mitad de mi tiempo de trabajo, y algunas veces más, lo dediqué a la tutoría y no a resolver tareas de producción por las cuales me pagaron dinero. Por lo tanto, de 3 a 4 personas o más, es imposible ser mentor si hablamos de mentoría de alta calidad.

Estudios a largo plazo : 1-2 años. En mi experiencia, un programador ha estado trabajando durante un promedio de 2 años en una empresa. Resulta una imagen triste: usted es mentor de una persona, lleva el conocimiento a él y luego alguien renuncia, ya sea usted o él, y toda la tutoría no va a ninguna parte.

La tutoría es efectiva, pero debido a las deficiencias, pensé: ¿por qué no encontrar alguna forma que sea efectiva como tutoría, pero sin las desventajas: divertida, interesante y escalable? Pensando, se me ocurrió la idea de los juegos: es divertido, me gustan las personas y resuelve los problemas de la tutoría.

Juegos!

¿Qué juegos sabemos? Damas, ajedrez, carretes y dominó son una ocupación intelectual, a pesar de la simplicidad.



Las cartas también son un juego intelectual. A quién no le gusta el clásico, está "Magic: The Gathering". Mucha gente de TI ama este juego, incluyéndome a mí. Muchas compañías de TI organizan torneos enteros dedicados a ella.



Todos estos juegos son juegos de entretenimiento, no para programadores, y me preguntaba: ¿hay algún juego para programadores? Y encontré, por ejemplo, un juego así.



El jugador opera con bloques de colores, compila el código fuente de ellos para controlar al astronauta. Obviamente, el juego es completamente infantil, yo diría: jardín de infantes. Ella no convierte al jugador en un senior.

Entonces el juego es abruptamente: paisaje 3D y héroe-robot tridimensional.



En algún lenguaje tipo C, debe escribir un pseudocódigo para controlar el robot.

A continuación se muestra una captura de pantalla del tercer juego que encontré.


Aquí, de nuevo, en un pseudocódigo, debe escribir un programa para controlar el personaje: moverlo a través del laberinto, abrir y cerrar puertas, manipular objetos.

Todos los otros juegos son similares a estos tres, y todos tienen muchos defectos serios.

Desventajas del juego

Estos juegos solo enseñan conceptos básicos , como variables, bucles, funciones, algo que incluso los jóvenes aprenden en el instituto. Los juegos están divorciados de las tareas industriales reales , ya que no tienen multiproceso ni transaccionalidad, todo lo que sabe el senior o el middle. Juegos como este no se enseñan, y este es su problema.

El jugador controla el personaje o el "robot" , mientras que en realidad los señores y los medios trabajan con objetos comerciales muy complejos. Y además, el jugador siempre está solo , mientras que en TI trabajan en equipos. Cualquier proyecto de software es un trabajo en equipo. Dado que muchos programadores han crecido de introvertidos y el trabajo en equipo a menudo es difícil para nosotros, me gustaría que el juego también impulse las habilidades de equipo.

Experiencia de juego personal

Al mismo tiempo, existe una rica cultura de juegos de mesa en el mundo: Munchkin, Magic: The Gathering, Dungeons & Dragons. Pero, desafortunadamente, no conocí el "escritorio" para programadores.

Personalmente, yo y toda mi familia: esposa, hija y gato Tishka, nos encantan los "escritorios". Además, a mi hija y a mí nos encanta crearlos. Inventamos el juego de acuerdo con el popular programa "Revizorro" y otros juegos de aventuras. En estas fotos simples hay 3 ejemplos de nuestros "escritorios".



¿Cómo se me ocurrió la idea de los juegos de mesa para programadores? Pasé por cuatro etapas: la experiencia negativa de capacitar a los empleados, el análisis decepcionante de los juegos actuales , la experiencia de jugar "trucos" y la experiencia de crearlos . Todo esto me llevó al "escritorio" para programadores. De hecho, ¿por qué no hacer el juego tú mismo?

Requisitos del juego

¿Cuánto debería ser futurista o realista?



Una sesión de juego corta no dura más de 15-20 minutos, porque según lo planeado, debes jugar este juego durante las horas de trabajo. Jugando durante más de 20 minutos, la gente se dejará llevar y abandonará el proceso de producción, y los jefes caminarán y cortarán el césped. Por lo tanto, 20 minutos es ideal: jugamos y pasamos a trabajar.

El juego debe enseñar tareas industriales reales a las que se enfrentan las personas mayores y medianas reales: subprocesos múltiples, JPA, bases de datos y estructuras de datos concurrentes . Estos son los temas que a menudo no permiten a los juniors saltar a la cabeza un cierto nivel técnico y convertirse en seniors. No solo estoy hablando de Java, sino en general de todos los lenguajes, incluidos Python, C ++: en todas partes hay subprocesos múltiples, bases de datos y estructuras concurrentes.

La siguiente tarea que debe resolver el juego es impulsar las habilidades en el trabajo en equipo : la formación de un solo lenguaje técnico dentro del equipo y la capacidad de discutir el código. Ahora, casi todas las empresas tienen una revisión del código, y a menudo se encuentra una situación: los desarrolladores, especialmente los principiantes, ven el código fuente, pero no pueden describir con palabras lo que está sucediendo en él. Pueden escribir código, pero no pueden discutirlo: no hay un diccionario técnico en la cabeza. Me gustaría que el juego bombeara este diccionario técnico. Además, tener un lenguaje técnico lo ayuda a escribir documentación de calidad.

El trabajo en equipo es un requisito que HR disfrutará. No estoy hablando del trabajo en equipo, donde las personas se reúnen y beben alcohol, sino de reuniones donde discuten el código fuente. Existe tal trabajo en equipo, y la tarea del juego reside en ello.

Para complacer al señor y al equipo. Quiero que me guste personalmente el juego, como el señor y el anfitrión de este juego, y el equipo, para que sea interesante, divertido, incluso provocativo en alguna parte.

El último requisito es muy importante: el juego debe ser un verdadero juego de mesa real, no en línea, solo fuera de línea . Varias veces me pidieron que escribiera una versión en línea de este juego, pero siempre me negué. Muchos están familiarizados con el juego de Go, pero no todos saben que en un juego chino real, las fichas negras están hechas de basalto y blancas, de una concha marina especial. Las fichas de plástico ya no son el juego de Go. Los chinos son sensibles a las sensaciones táctiles durante el juego, deberían ser parte de él. Pienso exactamente lo mismo. Por lo tanto, mi juego también debe ser animado y dar placer táctil.

Un ejemplo de "tablas"

El juego que desarrollé se llama "¿Quién robó el monitor?" Como todos somos expertos en tecnología, sabemos que el monitor no es la televisión que estamos viendo en el trabajo, sino el concepto de subprocesos múltiples. El objetivo del juego es introducir al equipo en un punto muerto en el subprocesamiento múltiple de Java . Los jugadores en un equipo no compiten entre sí, sino que resuelven conjuntamente un problema común: una verdadera formación de equipo. Elegí el tema de subprocesamiento múltiple, porque este es el listón para junio, a través del cual a menudo no puede saltar, y comenzar a escribir un código industrial realmente bueno. Las empresas requieren grandes capacidades de nuestra parte, y casi todos los programas industriales son multiproceso . Por lo tanto, es fundamental que tanto las empresas como los programadores sepan qué es el subprocesamiento múltiple.

Elementos del juego

El primer elemento es el campo Código fuente en una hoja grande de cartón grueso. Muestra un cierto fragmento de código, en nuestro lenguaje Java.



El siguiente elemento son las varitas de las líneas actuales . Estos son marcos de colores hechos de alambre.



Cada jugador, a su vez, mueve su personal de transmisión a través del código fuente, mostrando así la barra de progreso actual.



El juego tiene dos campos de juego. La primera es una máquina de estados : cuadrados y flechas con inscripciones.



Tomé la máquina de estado de la documentación estándar de Java. Todo senior, intermedio e incluso un junior debería conocer esta máquina de estado de memoria, pero en mi experiencia no todos los desarrolladores de Java lo saben, muchos escriben código sin este conocimiento. Una de las tareas del juego es impulsar las habilidades para conocer la máquina de estado de los hilos de Java .

El siguiente elemento son los tokens de flujo de doble cara .



Por un lado, se dibujan los ojos cerrados, esto significa que la secuencia está inactiva. Por otro lado, un hombre corriendo, hay una transmisión activa.

Ilustraré cómo se mueven los chips alrededor de la máquina de estado. Si el hilo comenzó a funcionar, entonces el jugador mueve la ficha de estado al estado " nuevo" , el estado inicial cuando se acaba de crear el hilo.



Durante el juego, como resultado de algunos eventos, el jugador mueve la ficha al estado " ejecutable" , sin olvidar darle la vuelta con el lado en el que se dibuja la pequeña persona corriendo, lo que significa que ahora su flujo está funcionando.



El siguiente elemento del juego son las tarjetas de monitor .



Estas cartas se encuentran primero en la pila común, y luego los jugadores las toman en sus propias manos. Cada monitor está conectado a un objeto Java, de los cuales hay dos: "uno" y "dos".

El último elemento son las horas de los flujos .



Probablemente, todos los técnicos saben que los hilos pueden "quedarse dormidos" por un tiempo determinado. Para medir este tiempo en el juego, hay relojes donde puedes mover las manos.

Considere algunos movimientos de una sesión de juego.

Ejemplo de sesión de juego

Tenemos tres jugadores:

• Michael trabaja para el hilo "principal", el hilo principal de Java.
• Eugene - flujo "t1".
• Svetlana - la corriente "t2".

Cada uno de los jugadores se coloca en el lugar de una de las transmisiones y vive su vida en el proceso del juego. Entonces entiende lo que significa ser un hilo de Java.

Michael mueve la varita de flujo a la primera línea de código.



Eugene y Svetlana todavía están durmiendo: sus hilos no se han creado, y Mikhail mueve su personal de transmisión a la siguiente línea de código, donde dice <code> Thread t1 = new Thread () </code> - esto significa que la transmisión se creará Eugene "t1" .



Eugene no bosteza, toma su chip de transmisión y lo pone en el estado "ejecutable", del lado del hombre que corre.

Ejemplo de trabajo en equipo

Svetlana le dice a Eugene:

• Eugene, ¿por qué pusiste el chip de tu transmisión no en el estado "nuevo", sino inmediatamente en el estado "ejecutable"?

• Por que no

Se puede ver que Eugene es el junior más inexperto del equipo, pero Svetlana tiene más experiencia y dice:

• Eugene, según la máquina de estados, el estado inicial del flujo es "nuevo".

Eugene está de acuerdo con Svetlana y mueve el chip de su flujo a la posición correcta.



Este es un ejemplo de cómo el equipo transfiere conocimiento durante el juego. El juego continúa ...

En cierto movimiento, Michael ya le hace un comentario a Eugene:

• Eugene, ingresaste al bloque de sincronización, pero olvidaste hacer algo ...

• ¡Exactamente, olvidé levantar el monitor de este objeto!

Eugene toma el monitor del objeto " uno" . Resulta que la secuencia "t1" Eugene posee este monitor.



Luego viene el juego: muchos movimientos, omisiones, trabajo con el reloj. Lea más en el video o en las diapositivas de la presentación .

Al final del juego, Eugene tiene un monitor, y Svetlana tiene otro, y la expectativa de los monitores bloquea el flujo de cada uno de ellos. Como resultado, tanto la secuencia "t1" como la secuencia "t2" están en estado "bloqueado", es decir, observamos un punto muerto.

Durante la sesión del juego, cada uno de los jugadores comprobará personalmente, sentirá qué es un punto muerto, cómo surge y qué es.

Conclusiones

La sesión del juego es corta . 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 o en GitHub. Desde aquí puedes descargar los elementos e intentar implementar el juego en casa.

Este informe es solo uno de los que nos ayudó a comprender la relevancia del tema de la capacitación y la transferencia de conocimiento. Como resultado, el 26 de abril llevamos a cabo KnowledgeConf totalmente dedicado a esto. Y sobre las formas modernas de aprendizaje no estándar y sobre la transferencia de experiencia a los principiantes, habrá muchos informes útiles . Únase a nosotros, y el problema del crecimiento de los empleados y el intercambio de conocimientos en un equipo dejará de ser insoluble para usted.