Nosotros en Veeam tenemos un proyecto educativo con el nombre lacónico de Veeam Academy . Está dedicado a la práctica de desarrollo de C #. Si no entra en detalles, la esencia de esto es esto: tomamos estudiantes de último año y en tres meses traemos su conocimiento del instituto puramente teórico de acuerdo con la realidad circundante. Esto se hace con la ayuda de conferencias, donde revelan el significado práctico de la aburrida teoría que lograron darles en la universidad, y con la ayuda de un proyecto común, cuyo desarrollo participan a lo largo de la capacitación.
En el camino hacia el primer lanzamiento de la Academia, nos enfrentamos a muchos problemas interesantes, tanto puramente organizativos como legales. (Si alguien no lo sabía, la capacitación es una actividad autorizada, por lo que no puede comenzar a aprender algo, incluso si realmente lo desea, para no aumentar el interés de las autoridades reguladoras).
¿Pero de dónde obtienen los estudiantes esas mismas habilidades prácticas? La respuesta está en nuestros desarrolladores, quienes de manera completamente voluntaria actúan como consultores, hacen revisiones de códigos para niños y simplemente comparten sus experiencias. Además, solo los desarrolladores senior participan en esta actividad. Fue con ellos (después de 3 graduaciones de la academia) que decidimos hablar para averiguar:
- ¿Por qué pasan su valioso tiempo con los estudiantes?
- ¿Cómo se siente ser un mentor novato?
- ¿Cómo / por qué / por qué vivir con código heredado?
- ¿Qué falta en la educación moderna?
- ¿Por qué la gente va al desarrollo de productos en caja?
Hicimos una pequeña serie de entrevistas en video con el estilo Dud, y habrá un pequeño extracto textual de las respuestas más interesantes. Se han publicado dos entrevistas completas (están en el artículo), pero pronto se publicarán tres más.
Actores:
Alexander Baranov - Gerente de Desarrollo, Veeam Backup & Replication.
Artyom Grigoriev - Desarrollador experimentado.
Dmitry Babushkin - Desarrollador Senior.
Kirill Lukyanov - Jefe del Departamento de Desarrollo de Hyper-V, líder del proyecto de una manera simple.
Philip Guzeev - Desarrollador experimentado.
¿Cómo nació la idea de Veeam Academy?
Alexander - La idea era conjunta. En el curso de numerosas entrevistas, surgió un entendimiento de lo que faltaban los candidatos. Muchos juniors vienen a nosotros (desarrollador junior). Como regla general, se trata de personas que se han graduado recientemente del instituto, con una experiencia de aproximadamente 1 año o ninguna. Como regla general, carecen de práctica. Esto significa que hay que hacer algo para que, si este déficit no se elimina por completo, se llenen al menos las brechas principales. Comenzamos a pensar cómo encajar nuestra experiencia existente en cursos concisos de dos o tres meses: este fue el comienzo.
Los cursos sobre algoritmos y estructuras de datos que se enseñarán en las facultades de matemáticas no son malos en sí mismos. El problema es que a menudo van aisladas de las aplicaciones prácticas en el desarrollo, por lo que no se absorben muy bien. Estamos tratando de estructurar un poco este conocimiento y darle una idea práctica de cómo funciona. Y no solo "cómo funciona la tecnología", sino cómo funciona el proceso en su conjunto: cómo funciona el equipo, cómo se distribuyen las tareas, cómo sincronizar a los miembros del equipo, etc.
¿Cómo llegaste a la Academia?
Artyom - Se ofrecieron a participar en la Academia como revisor, pensé: "¿Por qué no?". Al mismo tiempo, actualizaré mis conocimientos y adquiriré experiencia para hablar. Era mi primera experiencia casi desde la universidad, así que estaba muy preocupado.
Por otro lado, la Academia es una oportunidad para contratar más empleados y, en cualquier caso, es una experiencia interesante y una oportunidad para comprender cómo es transferir conocimientos.
Philip - Inmediatamente de acuerdo, como se sugiere. Siempre es interesante ver qué personas tienen formas de pensar, notar algo nuevo por sí mismas. Y siempre es útil compartir tus conocimientos.
Cyril : cuando comenzó el proyecto, era solo una idea atraer a los desarrolladores al proceso. Eso tenía sentido porque En la práctica nos enfrentamos constantemente a problemas técnicos específicos y conocemos bastantes aspectos que estamos dispuestos a compartir. Recibí una propuesta, acepté espontáneamente, y cuando ya había comenzado a abordarlo más cuidadosamente, ya había objetivos y un deseo de alcanzarlos.
¿Qué hiciste en la academia?
Dmitry : preparó preguntas para las pruebas en línea, participó en la selección y entrevista de estudiantes, y también actuó como mentor para algunos estudiantes.
Alexander : hice lo que pensé y planeé al principio, qué deberíamos hacer y decir, y lo que nos falta [en los candidatos], y que sería interesante para las personas que vienen a esta Academia.
Philip : en la Academia, fui y soy un mentor, una persona que revisa el código de los estudiantes y los dirige hacia el verdadero camino, dando todo tipo de consejos.
¿No te arrepientes del tiempo dedicado?
Dmitry - No, por supuesto. Ayudé a contratar a tres hombres con talento, incluso en los departamentos vecinos, pero al final tenemos un gran equipo, una familia, si lo desea. Cuantas más personas en el próximo departamento, menos perderán sus tareas para nosotros =)
Cyril - pensé - esta es una buena oportunidad para mejorar mis habilidades de la misma sociabilidad y hablar en público. Todos sabemos que este tema es terrible para muchos desarrolladores, así que superé mis temores.
Como resultado, contraté a dos estudiantes, los muchachos están trabajando con éxito.
¿Por qué te convertiste en mentor?
Dmitry : me gusta desarrollarme en varias direcciones, y fue una gran ocasión para demostrarme a mí mismo en todo. En la época de la juventud violenta, los pensamientos se deslizaron en lo pedagógico, pero no funcionó, aunque quedó cierta experiencia.
Philip - No pasa nada por nada. Por ejemplo, la gente viene a la Academia no solo así, sino, por ejemplo, para ocupar un lugar en el equipo más tarde. Y el papel de la tutoría, entre otras cosas, es seleccionar una persona válida en el equipo.
¿Qué les falta a los estudiantes modernos?
Dmitry - Vienen muchos tipos talentosos que piensan bien, pero, desafortunadamente, solo lentamente. Todavía no tenían experiencia práctica, su cerebro no fue reconstruido para la programación. No pueden encontrar rápidamente ninguna solución; necesitan sentarse en silencio y pensar en un ambiente acogedor. Esto no es un problema cuando resuelve algunos problemas académicos en el hogar, pero cuando se fusionan en el proceso de trabajo, esas personas simplemente no pueden tirar.
Cyril : si designa grandes temas, las principales brechas en el conocimiento después de las universidades son la programación multiproceso. Probablemente la zona más desastrosa, a juzgar por el análisis de nuestras tareas de prueba.
Pero, creo, esto es una consecuencia de la falta de práctica. Hay suficiente teoría alrededor, pero en las universidades, por regla general, la dan muy unilateral. Por ejemplo, en C # toman tareas, llamadas asíncronas y las analizan. Este mecanismo es conveniente, pero no le permite mirar debajo del capó. El estudiante mismo debe ir y comenzar a entender, pero casi nadie lo hace. La curiosidad es algo bueno, pero a menudo simplemente no hay suficiente tiempo para ello.
¿Qué es tan interesante sobre las revisiones de códigos de estudiantes?
Artyom : en principio, es interesante en sí mismo mirar el código de otras personas. No utilizamos muchas innovaciones en el flujo de trabajo, por lo que incluso aprendí algo interesante para mí con respecto a tecnologías relativamente nuevas.
Los estudiantes escribieron en el séptimo sharpe, en el decimoséptimo estudio, respectivamente, hubo algunos momentos que aún no había encontrado en la práctica. Por ejemplo async / await.
Una revisión de código es, digamos, la práctica de escribir un buen código. Cuando lo escribe usted mismo, involuntariamente piensa: "Bueno, puede obtenerlo, aquí es mejor, aquí es peor, luego lo rehaceré, etc." Y cuando mira el código de otra persona, no tiene restricciones de que necesita corregir 10 errores antes del almuerzo. Y puede profundizar tranquilamente en dónde es malo, dónde puede mejorar y dónde rehacerlo por completo. Esto ayuda a ver el proceso de escribir código desde el exterior, y en el futuro es más fácil resolver problemas como hacer un esquema de llamadas, responsabilidad de clase, etc.
¿Qué esperas de un estudiante para una entrevista?
Dmitry : quiero ver su enfoque. La gente viene, dicen que leen, por ejemplo, Richter. No leí a Richter, pero cuando comienzas a hablar con ellos, resulta obvio que encontraron una respuesta a su propia pregunta y eso es todo, es decir no lo leyeron [pensativamente]. Hojearon un libro, pero no están interesados en lo que escribe, no están interesados en cómo se organiza el .Net Framework en su interior. Este es un enfoque válido si usted es un especialista establecido. Pero si vio C # en su primer año y comenzó a ignorar algunos detalles de implementación, cómo se organiza todo bajo el capó, esto es una garantía de que comenzará a pisar el rastrillo. Y si en este momento ingresas al proyecto del equipo, inevitablemente afectará tu resultado. Todos te regañarán, tu motivación disminuirá y surgirá la pregunta sobre el trabajo futuro.
Hay otro aspecto de tener tiempo libre. Incluso si sus ojos [de estudiante] están ardiendo, pero pasará dos horas camino a la Academia, más su trabajo a tiempo parcial, más problemas de la vida y un gato hambriento en casa, queda claro que no tiene tiempo libre y simplemente arderá como un fósforo para Tres meses de estudio.
¿Es difícil enseñar a escribir código "correctamente y como necesitamos"?
Philip : no puedes decir "lo estás haciendo bien o mal". No hay tal cosa. Crea un código compatible o crea un código no compatible. Supongamos que tiene la tarea de redactar un proyecto en 5 horas en un hackathon. Y, por supuesto, no pensarás en la belleza de la arquitectura y la belleza del código. "Te equivocas" al trabajo, y con razón. Por otro lado, si trabaja en una empresa [de una empresa grande - ed.], Entonces ha asignado tiempo para tareas y ciertos requisitos para el código, y esto es lo que estamos luchando y lo que estamos buscando.
Alexander - Hay dos situaciones. Si una persona ya ha hecho algo similar en otra compañía de alimentos, entonces lo hará con relativa facilidad. El mercado estandariza los procesos.
Otra cosa es cuando ya tienes experiencia, pero hiciste algunas otras cosas. Esto plantea la pregunta, "¿Cómo quieres desarrollarte más?" Si su objetivo es trabajar en una gran empresa, mudarse a otro país, tendrá que soportar un período de ruptura. Es como un automóvil personal después del transporte público (o viceversa): al principio es doloroso y triste, pero luego se vuelve muy cómodo y conveniente.
Dmitry : de hecho, si una persona tiene un nivel mínimo de habilidad, no tiene que "romperlo". Pero cuando vienen programadores experimentados, ya tienen su propio conjunto de prácticas, su propio estilo de código, que puede diferir del nuestro, y comienzan las conversaciones: "¿Por qué me estás prohibiendo usar vars? Tengo un código tan bueno, ni un solo tipo es visible, y todo está como debería estar en la programación funcional ". Pero con esas personas es más difícil.
Y si este es un estudiante, incluso del último año, con una docena de proyectos en el github, simplemente no tuvo tiempo para adquirir prácticas viciosas. Bueno, trabajar con personas completamente "puras" es un placer.
Los estudiantes pueden sorprender gratamente?
Artyom : Digamos que a veces hubo situaciones en las que abriste el código, y hay construcciones en todas partes que nunca has visto antes. Tuve que sentarme con ellos y descubrir cómo usarlos correctamente. Sucedió que yo mismo no entendí correctamente la primera vez.
¿Fue Veeam Academy útil para usted personalmente?
Dmitry : Sí, por supuesto. Como de costumbre, cuando le dices a alguien cómo hacerlo, en primer lugar, entiendes cómo hacerlo. En segundo lugar, sistematizas tu propio conocimiento e incluso en el proceso de conferencias encuentras respuestas para ti mismo a algunas preguntas que te han atormentado durante mucho tiempo. Por lo tanto, compartir sus conocimientos con otra persona es una excelente manera de desarrollarse.
Alexander : en primer lugar, quedó claro lo que la gente espera, incluso del lugar de trabajo futuro. Cuando usted, como líder, está en el proceso, cocina más bien en el desarrollo de negocios. Y donde la situación es más informal, como en la academia, queda claro qué mueve a las personas, qué quieren y cuáles son sus intereses.
Aprendes, incluso mucho, sobre ti, y esto es lo más importante.
Por ejemplo, usted comprende que muchas cosas necesitan ser simplificadas. Cuando trabajas en un área durante mucho tiempo, el ojo se vuelve borroso y las cosas que son obvias para ti se vuelven completamente incomprensibles para otras personas, especialmente para los principiantes.
Philip : cuando cocinas constantemente en medio de desarrolladores de cierto nivel, comienzas a hablar en algún tipo de lenguaje que solo tú entiendes. Y cuando llega una persona que está entrando en este entorno, comienza a explicar todo en palabras más simples, aprende a transmitir información de una manera más estructurada.
Al trabajar con los estudiantes, también aprendes paciencia, algún tipo de compasión y comprensión =) Pero luego comienzas a ver algunas cosas que él mismo sabía, pero olvidó. Debe profundizar en la tecnología para transmitir mejor a la persona el significado de lo que está sucediendo. Más bien, el significado de por qué es mejor hacerlo así, pero es mejor no hacerlo así.
El desarrollo empresarial siempre se trata de legado?
Cirilo : afirmación absolutamente correcta. Cuando un proyecto se ha escrito durante 10 años y está en constante evolución, habrá un cierto porcentaje de código heredado.
Otra pregunta es cómo las diferentes compañías pueden abordar esto.
Mientras el módulo funciona, intentamos no entrar en él. Fue depurado hace 5 años y más de una versión ha estado funcionando de manera constante. Otra pregunta es cuando obtienes un código en el que constantemente necesitas cambiar algo. En este caso, no está prohibido mejorarlo gradualmente: refactorización, etc. Hace 10 años había un estándar de lenguaje diferente, otras construcciones léxicas. Nadie se molesta en tomar, refactorizar y transferir a nuevos diseños.
El código rejuvenece gradualmente, pero todo está en manos del desarrollador. Puede martillar un tornillo, resolver el problema actual y quizás esto sea suficiente para la empresa, porque Se logrará el objetivo final en forma de un producto funcional. Bueno, lo que hay dentro ... Hay muchas historias en Internet, especialmente sobre el comienzo de gamedev, cuando solo aparecían clases en C ++ ... abres el código; hay clases, hay muchas inclusiones en cada una. Está claro que ahora lo llamarían una palabra muy específica.
Pero, en general, con el código heredado debes poder vivir. No hay necesidad de tenerle miedo.
Dmitry : el código heredado, por supuesto, está presente y, por supuesto, necesita vivir de alguna manera con él. Pero no vives con él por desesperación, sino porque no tiene sentido tocarlo. Muy a menudo, el código heredado son algunos componentes ya depurados, incluso si están escritos en algún tipo de .Net 2.0. Funcionan durante años, no es necesario agregarles nuevas funcionalidades, y por qué tocarlos si funcionan y funcionan bien ?
Hay situaciones en las que ve un error en el código anterior que ha pasado varias versiones, pero de repente se disparó. Ahí es cuando comienza a reescribir el código anterior, tal vez cubrirlo con pruebas unitarias para no romper nada. O simplemente confías en los probadores sin fin. Es decir solo tienes un buen momento, por supuesto, no para el lanzamiento, sino todo tipo de beta solo para esto e inventado.
En cuanto a la Academia, este proyecto también nos permite mantenernos al día. Vienen nuevos tipos, siguen activamente las noticias del mundo de C #, .Net, etc. Les gustan algunas construcciones nuevas, "azúcar sintáctico" de las últimas versiones. Y, de hecho, a través de los líderes de su equipo, fuerzan [promueven] estos diseños en el proyecto. Sí, puede causar resistencia, es posible que las personas no lo acepten de inmediato, pero todo es temporal y si una característica realmente útil entra en el nuevo marco, entrará en el proceso.
Philip - Tengo que lidiar con lo que se escribió hace 10 años. No obtendrás nada de esto. Naturalmente, nos esforzamos por actualizar nuestra pila, pero tenemos 180 proyectos en desarrollo, se han escrito varios millones de líneas de código durante este tiempo, y es muy difícil saltar sobre él. Debemos entender y de alguna manera aceptar esto.
Alexander : una vez leí una presentación de Mercedes Benz sobre por qué son tan conservadores e introducen tecnologías con cierto retraso. La respuesta es simple: todo lo que no beneficia al cliente va "en un balde". El desarrollo empresarial sigue el mismo principio. Las primeras "víctimas" de la nueva tecnología deben ser analistas, desarrolladores, un laboratorio de pruebas o cualquiera, pero no el cliente. Cualquier tecnología antes de que aparezca en el producto debe estar en ejecución. Desde el exterior, parece un legado, pero desde el interior no lo es. Es solo que todo lo moderno debemos probar primero "en gatos" y solo luego aplicarlo en la vida.
Artyom : sí y no. Nuestro producto tiene 10 años, por lo que tenemos mucho legado, pero esto no significa que arrastremos ciegamente los componentes antiguos y no hagamos nada con ellos. Sucede que lo reescribimos por completo.
Entonces, ¿cómo es la introducción de nuevas características?
Alexander : en primer lugar, explica qué problema estás resolviendo. Si trajo el proyecto del rover lunar, esto es ciertamente genial, pero explique por qué es necesario. Si puede explicar por qué nos será útil, entonces, por supuesto, lo implementaremos.
Cyril : primero debes entender qué es, porque Puede tener consecuencias. Si presentamos alguna biblioteca nueva, no solo los desarrolladores están involucrados aquí. Se incluye el departamento de pruebas, que deberá volver a probar toda la lógica que dependía del antiguo código de trabajo, y ahora hemos cambiado todo.
Por lo tanto, la introducción de algo nuevo en el desarrollo de la producción a menudo se asocia con grandes gastos generales. Y si la ganancia de la implementación excede estos costos, entonces, como regla, se toma una decisión sobre la implementación. Y si por el contrario, ¿por qué? No es necesario que te dispares en el pie.
¿Qué pasa con el fervor de los Jones y su deseo de mejorar todo?
Dmitry : todavía no resuelven tareas serias y complejas debido a la falta de competencia. La edad temprana (en términos del desarrollador) es una gran oportunidad para darte golpes, especialmente si no crees en los camaradas mayores. Si el precio de la pregunta es de dos días, durante los cuales comprenderá que su idea "ingeniosa" no despegará y ya no lidiará con esta basura, entonces es mejor darle la oportunidad de pisar este rastrillo personalmente. Es mucho peor prohibirle que haga esto, y durante meses pensará que "el desagradable líder del equipo me prohibió cortar lo bueno".
Cyril : todo lo que se da en la Academia permite a los estudiantes, en primer lugar, mirar la pila de tecnologías modernas. En segundo lugar, todo lo que damos, intentamos utilizarlo al máximo.
Nuestro producto no es joven, pero cuando se escribe una nueva característica, se crea desde cero y el uso de nuevas tecnologías conlleva menos riesgos. Así que déjelos usarlo.
Artyom : las nuevas funciones son buenas para aplicar en nuevas áreas. Nuestro proyecto no es tan monolítico que resuelve solo un problema, y eso es todo. Tiene muchas funciones, y siempre hay un lugar para aplicar lo nuevo.
Cuando llega una nueva persona, se le asignan primero tareas educativas, luego pequeñas. En cualquier caso, primero necesita familiarizarse con el proyecto, porque es enorme. Parece que ya hay más de un millón de líneas de código, pero puedo mentir. En cualquier caso, echar un vistazo en una semana, e incluso en un mes, no tendrá éxito. Pero cuando comienza a entender, podemos hacer un experimento, por qué no.
¿Cómo ser un joven con un legado?
Philip - En primer lugar, no puedes decir que estas cosas están completamente desactualizadas. Hay todo tipo de "know-how" directo, ok, trabajamos en gran medida sin ellos. Pero, en cualquier caso, una persona aprenderá de nosotros el enfoque correcto para la organización y el diseño del código. Esto no va a ninguna parte.
También enseñaremos cómo trabajar con legado. Esta también es una habilidad muy importante. No puede pensar que vendrá y comenzará a diseñar el mejor sistema del mundo. No Muy a menudo, al llegar a la empresa, te encuentras con un producto terminado. [ — .], [ — .].
— . backlog [ , — .], , . , - , , - .
-, . , , , .
, , ?
— Enterprise- , . , , , . , “ ”, “”. , enterprise[-]. , , , , . , Veeam 5 , SMB [small & medium businesses — .] Enterprise. enterprise[-], , , . , , .
. , enterprise. : , enterprise “”, . , , . , enterprise, . : - 5 ( ) , , , . , .
. , . , . , , .
— . , , - , , .
[.. — .] . , .
? , , . , , — . : , . .
, 2-3 . , . , Veeam, , - , - . — .. , , .
— , . , . , enterprise- , .
, , , . , Amazon , Facebook , , .
, enterprise. , .
— “, , ” , . . , . , , - , , , . , .
, , . , , .. , . . , , .
enterprise?
— , . , , , “ ”, .
— . - - . - , “”. . 8 , , . , .
— , enterprise. , , , . , , ..
— , — . , , .
?
— , . , . - , , .
, . — , . , , , . , . -, , , “” [ — .]. , , . .
?
— , . .
— , , .
— . -, . 15 - , , , [Microsoft Visual Studio — .], , - .
— , .
— , , . , , , . , , , .
, , , .