A finales de 2017, decidí firmemente que quería pasar a un puesto directivo.
La programación en sí me atrajo mucho menos que lo que sucedió en un nivel superior, es decir, pensar en los procesos de negocio, planificar la arquitectura de aplicaciones y organizar el trabajo.
Me sentí menos como un jardinero que cultiva una pequeña parcela de tierra día tras día, viendo los brotes emerger del suelo, como un agricultor que tiene que cosechar y luego vender cosechas de un campo gigante del tamaño de un país europeo.
La escala y la eficiencia me inspiraron.
Quería hacer lo que me gustaba, pero eso era imposible hasta que me convertí en líder.
Mientras tanto, mi carrera en mi trabajo actual claramente ha alcanzado el techo. Durante dos años, planteé varios proyectos, me convertí en desarrollador senior ... Además, aquí solo era posible progresar en el fútbol de mesa.
Por lo tanto, cuando me ofrecieron un trabajo en Sberbank, me alegré de irme. Específicamente, en DomClick.
DomClick
Cuando crucé el umbral de la nueva oficina, me encontré en una posición única: resultó que sería el único desarrollador Ruby de la empresa.
En un equipo de trescientos empleados, simplemente no había un departamento físicamente apropiado. Ni siquiera tenía dónde ponerme. Cuando surgió esta pregunta, el director de TI de la empresa pensó durante exactamente dos segundos y señaló una mesa cercana, que estaba vacía por una razón obvia. Es tan inspirador cuando la gerencia puede ver la pantalla de su computadora portátil con un leve giro de cabeza (no).
Me necesitaban para una tarea específica. La gerencia estaba decidiendo si comprar una startup bancaria estadounidense para complementar la línea de productos de DomClick. Se planeó que los gastos fueran grandes, por lo que fue necesario adaptar y lanzar el proyecto para demostrar a la gente quién sacará ese dinero de su bolsillo.
La startup estaba en Ruby, así que me necesitaban. Fue una oportunidad. Si lo compraran, se necesitarían más rubistas. y con un alto grado de probabilidad me convertiría en su jefe. Una pequeña larva alienígena atrapada en un organismo gigante DomClick. Me gustaba pensarlo de esta manera, imaginando que a partir de este momento comienza mi toma de posesión de este universo.
Pero dos meses después, en el nuevo lugar, resultó que ya no se necesitaba al violinista. Los tops miraron el proyecto en el que estaba trabajando y decidieron esperar.
Los rubistas no pertenecen aquí
Me encontré sin trabajo, un solo programador Ruby rodeado de docenas de equipos bien coordinados de javistas, pitonistas y desarrolladores frontend. No se planeó contratar a ningún otro rubista.
Afortunadamente, a mi dirección en general le gustó la forma en que hice el trabajo, por lo que no era cuestión de despedirme. Tampoco sabían qué hacer conmigo. “Camine por ahora, piense en cómo puede ser útil para la empresa. ¿Quizás puedas probar algún código Go? " - me dijo el jefe. Era tan innecesario que en algún momento dejó de parecer una mala idea. Para imaginar la desesperación de mi situación, es necesario comprender qué estaba pasando en la empresa en ese momento y qué es DomClick en general.
Si en los últimos 5 años ha comprado / vendido bienes raíces, entonces con un alto grado de probabilidad debería conocer este sitio. En particular, gracias a él, NTV ya no hace seriales sobre malditos agentes inmobiliarios y no escuchamos estas escalofriantes historias sobre cómo alguien fue secuestrado / torturado / asesinado cuando decidió intercambiar la pieza de kopeck de su abuela en el centro. DomClick ofreció al mercado una forma cómoda y segura de comprar / vender vivienda.
El proyecto era aún joven, pero ya en ese momento todos entendieron que estaban presentes en vísperas de una grandiosa nix. Nace un sitio web gigantesco con decenas de servicios que se utilizarán en todo el país y más allá. Se necesitarán millones de líneas de código, lo que significa que muchos programadores podrán alimentar a sus familias durante años, comprando vales para suegras en un sanatorio y sellos para esposas.
Pero primero era necesario decidir sobre qué se escribirían estos servicios. Desafortunadamente para mí, la discusión se cerró cuando llegué, la copa se dividió entre los desarrolladores de Java y Python. Los javistas se dedicaron principalmente a servicios internos y cargados, integraciones con el banco y los pitonistas obtuvieron más tareas orientadas al cliente y nuevos lanzamientos. Cada uno de ellos se estaba preparando para comprar un apartamento y un bloque de acciones de Tesla en los próximos 5 años, ir a Ba̒li y encontrar una chica instamodel.
Encajar entre ellos con alguna otra tecnología no era realista.
Por lo general, el nacimiento de un nuevo proyecto se producía de esta manera: la empresa tenía una idea, acudían al director de TI y él ya estaba seleccionando un equipo vacante de programadores para el proyecto o contratando uno nuevo.
¿Qué podría hacer un rubyista en tal situación? ¿Podría levantar la mano y decir: "Pero Ruby ya tiene gemas listas para todo esto"? Este sería un caso completamente perdido por tres razones:
- Todos pensaron que Ruby era innecesaria. Python y Java son suficientes para los ojos.
- Además del hecho de que Ruby es innecesario, también es un mal lenguaje de programación. Absolutamente sin frotar.
- La tercera razón, quizás la más grave: soy el único programador Ruby de la empresa, lo que significa que no voy a trabajar en nada más o menos serio.
En general, de una forma u otra, pero había consenso en la empresa: no hay lugar para los rubyistas. Mi aparición fue un accidente, lo que confirma la regla: se me recomendó encarecidamente que comenzara a codificar en otra cosa.
Pero una persona que ha aprendido el poder de los rieles no puede detenerse fácilmente.
Rubí
A pesar del status quo de "Ruby es malo", todo el mundo conocía su fuerza: la velocidad de desarrollo. Decidí aprovechar esto y sugerí a los jefes que hicieran prototipos de los servicios que se planeaba lanzar. Algo así como "déjeme escribir rápidamente una muestra de su inicio y luego quedará claro con seguridad si vale la pena reescribirlo en un lenguaje" normal ", o mejor inmediatamente para el bloc de notas".
La idea fue apreciada y bendecida. Esta fue mi segunda oportunidad. El pájaro azul de la suerte estaba prácticamente revoloteando en mis manos cuando sentí que estaba perdiendo la carrera. Después de un pequeño MVP, la empresa me lanzó la funcionalidad que quería ver en la versión de prueba de CRM, y fue una cantidad de trabajo completamente abrumadora, a pesar de la velocidad del lanzamiento inicial. Solo por mis fuerzas, incluso cargadas de falta de voluntad para cruzar a los pitonistas, era imposible hacer la prueba requerida en el futuro previsible.
Me senté frente a mi computadora portátil y miré con tristeza cómo llegaba cada vez más tarde. Junto con la última esperanza de seguir siendo un rubyista, las ambiciones profesionales también desaparecieron: un Pasta Monster sabe cuánto tiempo tomará lograr en un nuevo idioma la competencia necesaria para gritar su nombre nuevamente en la elección de un nuevo Kraken.
Esto sin contar el hecho de que al cambiar el idioma, por ejemplo, en Python, automáticamente obtengo 150 rivales más merecidos para la promoción.
Fue un callejón sin salida.
Se me quitó la tarea y volvió a pensamientos ansiosos sobre mi futuro. Vi batallas de Versus, escuché música deprimente y bebí Dr. Pepper. Aparentemente, debido a la abundancia de azúcar, la solución apareció con bastante rapidez.
Aprendí una lección del último fiasco: no puedes morder una pieza que no puedes masticar. La gente ve cómo te engañaron y recuerda. Uno o dos intentos más de este tipo y me acabarán aquí, decidiendo que soy un fracaso.
Ahora necesitamos una tarea de la que estaré seguro de que no se producirán fallos de encendido. Lo suficientemente grande para ser impresionante, pero lo suficientemente pequeño para estar a mi alcance. Pero, ¿dónde puedo conseguir uno y cómo puedo conseguir que me lo asignen?
La forma más fácil de encontrar tal tarea era en el marco de un proyecto ya desarrollado. El plan era pretender ser un desarrollador de Java.
Alborotador
Los javistas estaban bien. Al principio, me pareció que me unía a un equipo de verdaderos programadores que trabajaban con patrones e interfaces claros. Nunca antes me había sentido tan programador como ese par de semanas.
Debido a mi conocimiento superficial de casi todos los lenguajes web populares, me adapté rápidamente y comencé a ser útil. El trabajo estaba en marcha. El proyecto incluso se lanzó en varias regiones para comenzar a detectar errores. El problema fue que el movimiento fue muy pausado, a pesar de que éramos cinco. Hice un descuento por el hecho de que debería ser así, porque esto es una empresa, es necesario comprender, pero rápidamente quedó claro que todo es mucho más serio.
El equipo estaba en conflicto con el propietario del producto. Juraron, casi sin elegir expresiones.
La primera línea de código se escribió hace un año y medio, pero el proyecto todavía no ha funcionado realmente. Una buena idea de negocio se encontró con problemas inexplicables durante la fase de implementación. La principal queja de PO, actuando como intermediario entre la empresa y los programadores, fue la imposibilidad de realizar cambios rápidos. Cuando se le pidió alguna revisión, escuchó: "Mes, mes, mes". Y se requirieron muchas ediciones. El sistema era tan inconveniente que un operador podía procesar un máximo de una o dos solicitudes por día. La funcionalidad parecía funcionar, pero había tantos errores que al lanzarla en todo el país, uno simplemente podía ahogarse en quejas. Algunas operaciones se realizaron solo tras una llamada al programador, quien cambió manualmente los datos en la base de datos o expresó la información necesaria. La interfaz de usuario estaba torcida. No se trataba de ninguna automatización.
Y en medio de todos estos problemas, los programadores lograron inventar bicicletas como un análogo autoescrito de tablas o un servicio de listas de correo. Las más leves mejoras llevaron al hecho de que algo en algún lugar debe caerse. Cada plazo imaginable se ha desperdiciado durante mucho tiempo.
¿Y sabéis cómo se explicaban los programadores lo que estaba pasando? "PO es estúpido y todas sus sugerencias son sobre nada".
Me pareció que el punto no estaba en PO, sino en el código. Cuando llegó la siguiente tarea urgente, me di cuenta de que era hora de quitarme las máscaras. Fue necesario hacer un sistema de cuestionarios, de acuerdo con los resultados del pasaje del cual se formará un documento terminado. Los programadores de mi nuevo equipo, después de consultar, expresaron al PO que harían lo requerido en tres meses con el esfuerzo de dos desarrolladores.
¡Tres meses y dos programadores!
El sofá debajo del PO estaba humeando. Se puso verde, pero, enseñado por la amarga experiencia, guardó silencio, sabiendo que era inútil preguntar, suplicar o quejarse. La perspectiva del despido se avecinaba. Pero los muebles humeaban no solo debajo de él. Sabía a ciencia cierta que la funcionalidad que acababa de anunciar aparecería en Ruby con el clic de un dedo.
"Escribiré esto en una semana", hice un movimiento. - Y todavía tengo tiempo para revisar todas las batallas con Oksimiron.
La tarea era exactamente lo que estaba esperando para entrar en este juego de tronos.
PO no lo creyó. El equipo también. En su Universo, la unidad mínima de tiempo era un mes, pero los plazos eran realmente ardientes, así que después de un breve arreglo de las formalidades, me dieron una semana.
Como probablemente sepa, Ruby es divino para el desarrollo de la velocidad. Me retorcería el corazón si dijera que me estoy esforzando o que de alguna manera estoy preocupado por mi tercera oportunidad. La gema que resolvió mi problema se perfeccionó en Ruby y funcionó como un reloj.
Después de una semana, mostré el resultado.
- ¿Por qué no hacemos todo en Ruby entonces? Preguntó el propietario del producto. Para ser honesto, todavía no sé la respuesta.
Ese día tuvimos una conversación franca. Ostap sufrió y me reveló el verdadero estado de las cosas. El proyecto se convirtió en una construcción infernal a largo plazo. Los jefes inmediatos del PO ya habían insinuado directamente su despido. Dejó de dormir. Simpaticé con él y le pedí que describiera toda la lógica que tenía que ejecutar la aplicación. Cuando terminó, me quedó claro que con dos camaradas reescribiría todo el proyecto en tres meses.
Los programadores del proyecto no eran malas personas ni saboteadores. Realmente lo intentaron. Es solo que su herramienta no era adecuada para la tarea. Cavaron un pozo de cimentación con cucharas. Pero tenía una topadora.
Cuarta oportunidad
Cuando PO y yo llegamos al CIO, parecía que ya había empezado a entender que no había funcionado bautizarme de nuevo, y curiosamente esperaba lo que se me ocurrió esta vez.
Sugerí reescribir el proyecto. En tres meses con dos asistentes, repetiré por completo la funcionalidad que han hecho 5 programadores en año y medio, y también arrojo chips encima. A su vez, RO confirmó que esto era necesario: el código del proyecto comenzó a vivir su propia vida, prácticamente no reacciona a los intentos de hacer cambios y, al parecer, pronto comenzará a exigir sacrificios humanos en forma de vírgenes.
Se decidió que la decisión final sobre este tema se tomará en el próximo comité de arquitectura, una reunión especial donde los directores se reúnen con los arquitectos y aprueban algún tipo de proceso.
Como puede adivinar, el hecho de que esté leyendo estas líneas sugiere que se me permitió reescribir el proyecto. Con una mínima mayoría de votos, el Archcomité dio luz verde a esta aventura. Entre otras cosas, se me permitió reclutar a dos rubyistas como asistentes.
Finalmente me convertí en líder.
Según tengo entendido, un papel importante en la aprobación de mi iniciativa lo jugó el hecho de que la dirección comenzó a darse cuenta de la relajación y la excesiva confianza en el futuro de algunos de los equipos de programación de la empresa.
Necesitaban un látigo, una amenaza, para motivarlos a trabajar mejor. Una palabra amable y un arma pueden lograr mucho más que una palabra amable, como solía decir Al Capone.
Y les puse esta pistola en la mano.
Al dar el visto bueno para reescribir el proyecto, los jefes parecían estar diciendo a los programadores de la empresa: "Si te equivocas, llamaremos a este tipo y te reescribirán".
Pero primero, tenía que no fallar en la tarea, que se convirtió en mi cuarta oportunidad. Cuando regresé de la reunión, era una empresa completamente diferente. Ahora me odiaban. Mi conflicto con el ecosistema de software DomClick, que comenzó desde el principio, alcanzó su clímax. No me hablaron, no se sentaron en la misma mesa del comedor. Tan pronto como entré en la habitación, todos los presentes comenzaron a examinarme. Susurraron a mis espaldas. Me encontré en completo aislamiento.
Para ser honesto, tal reacción me dio fuerzas. La vida se llena de significado cuando te sientes como la mano cortante del Señor. Decidí que sería una muy buena pistola.
Literalmente esa noche, llamé a un viejo amigo que estaba codificando en Ruby y estaba seguro de su profesionalidad. Aceptó unirse sin más preámbulos. Un par de semanas después, llegó el segundo desarrollador y resultó ser un tipo realmente duro que fortaleció enormemente nuestro pequeño desapego.
El organismo de programación de la empresa nos rechazó. No se comunicaron con nosotros. Todo el mundo estaba esperando nuestro fracaso. Y paradójicamente, nos unió y nos hizo crecer.
Una característica de Ruby es su alta velocidad de desarrollo. Por alguna razón, se cree que esto es a expensas de la calidad. Dicen que un proyecto perfectamente ejecutado en Ruby será peor que un proyecto ideal en cualquier otro idioma.
Pero, ¿dónde has visto los diseños ideales?
Los desarrolladores casi siempre no tienen tiempo suficiente para escribir código de alta calidad, adherirse estrictamente a los patrones y hacer todo como en los libros de texto. Como resultado, este código ideal, que todo el mundo amenaza, nunca aparece.
Pero Ruby, debido a su velocidad, permite obtener el mismo tiempo sobrante que se puede dedicar a pensar en arquitectura y buscar mejores abstracciones. El código resultante, paradójicamente, también resulta ser de la más alta calidad.
Cuando lanzamos una nueva versión del proyecto tres meses después, además de errores menores, funcionó perfectamente. Los usuarios finales del proyecto, los abogados de Domclick, estaban inicialmente descontentos porque las interfaces de usuario habían cambiado, pero después de un par de semanas, sus voces se calmaron. El proyecto funcionó como un reloj. Se desplegó casi de inmediato en toda Rusia.
RO estaba feliz. El antiguo equipo del proyecto se disolvió.
Se me permitió reclutar a dos programadores más.
Mi pequeño pelotón de bombardeo se convirtió en una compañía en toda regla. Nos odiaban, pero no podían hacer nada.
Mis muchachos sintieron la peculiaridad de su posición. Se apresuraron y lo consiguieron. Había una sensación de fluir, un estado de máxima concentración y disposición para la acción. Podríamos reescribir a todos de manera rápida y eficiente aquí.
Esto estimuló a toda la empresa.
Además del miedo a ser sobrescrito, había una sana sensación de competencia. Si estos recién llegados pueden trabajar de manera tan rápida y eficiente, ¿por qué somos peores? ¡Defenderemos nuestra propia empresa! ¡Devolvamos a estos advenedizos al inframundo del que vinieron!
Parte del equipo levantó el guante arrojado por los rubistas, y esto benefició a toda la empresa. De hecho, el equipo se dividió en hermanos y lachers.
Los hermanos se saltan los patrones, siempre están dispuestos a ayudar, piensan en los beneficios de la empresa y el éxito de su proyecto. Los lanzadores están jugando por el tiempo, no admiten errores, no quieren reaprender y negociar. Lo haces claramente, hermano. Eres estúpido, pones un radio en las ruedas, haces daño, quieres ganar mucho, pero hacer poco es un lacher.
Hicimos un gran trabajo y colocamos el estandarte de Ruby sobre el DomClick conquistado cuando el jefe final de esta historia me descubrió.
En una de las reuniones en los altos cargos, después de una larga historia sobre un nuevo proyecto, un hombre muy inteligente preguntó en voz baja: "Muéstrame esto el lunes".
Y no había nada que mostrar. Era viernes por la noche. Cuando me llamaron a la sala de reuniones, había rostros tensos sentados y sosteniendo sus cabezas con las manos, pensando qué hacer. El período mínimo durante el cual los demás estuvieron listos para completar el proyecto fue “no menos de dos semanas”, pero fue de tres días. Estuve de acuerdo.
Toda la compañía estaba esperando cómo terminaría. Empleados ordinarios con curiosidad, jefes con una sensación de desastre inminente. Y cuando salió el sol el lunes, nadie tuvo que escribir una carta de renuncia, dispararse o huir a través de la frontera estatal.
Todo funcionó en producción. Se presionaron los botones, se actualizaron las páginas y todos estaban felices. Y en algún lugar de Moscú, tres programadores sin afeitar dormían como un sueño muerto.
Cuando levanté el teléfono por la noche, me dijeron las tres palabras principales de mi vida: "Contrata más programadores".
Hoy en día, el departamento de Rubyists tiene aproximadamente 20 personas, más de 6 proyectos de diversa complejidad, y continuamos expandiéndonos.
Y ahora la moraleja de la historia.
Una vez, en una de las reuniones trimestrales, se le hizo una pregunta a nuestro líder permanente: "¿Cómo puedo convertirme en líder?", A lo que se le dio la cita: "no dan poder, toman poder". Sea eficaz, esfuércese por el éxito y si realmente está dispuesto a mejorar cada día, lo logrará.
En general, la vida es demasiado corta para escribir código largo. ¡Usad gemas, amigos!
PD Además, aquí tienes un video con nuestras actuaciones, a partir del cual podrás entender qué nos permite ser rápidos y eficientes: