Techlead Skyeng Kirill Rogovoy ( flashhhh ) habla en conferencias en las que habla sobre las habilidades que todo buen desarrollador necesita desarrollar para convertirse en el mejor. Le pedí que compartiera esta historia con los lectores de Habra, le paso la palabra a Cyril.
El mito sobre un buen desarrollador dice que él:
- Escribe código limpio
- Conoce mucha tecnología
- Codificar tareas más rápido
- Conoce un montón de algoritmos y patrones de diseño.
- Puede refactorizar cualquier código usando Clean Code
- No pierde tiempo en tareas no programáticas
- 100% maestro de tu tecnología favorita
Así es como los recursos humanos ven a los candidatos ideales, y las vacantes, respectivamente, también se ven así.
Pero mi experiencia dice que esto no es muy cierto.
Primero, dos renuncias importantes:
1) mi experiencia son equipos de productos, es decir empresas con su producto, no externalización; la subcontratación puede ser muy diferente;
2) si eres un junior, entonces no todos los consejos serán aplicables, y todavía me concentraría en programar en tu lugar.
Buen desarrollador: realidad
1: Codite es mejor que el promedio
Un buen desarrollador sabe cómo crear una arquitectura genial, escribir código genial y no crear demasiados errores; en general, todo es mejor para él que el promedio, pero no está en el 1% de los mejores especialistas. La mayoría de los desarrolladores más geniales que conozco no son codificadores tan buenos: están bien versados en su campo, pero no pueden hacer nada super-super.
2: resuelve problemas, no los crea
Imagine que necesitamos integrar un servicio externo en un proyecto. Obtenemos TK, miramos los muelles, vemos que algo está desactualizado allí, entendemos que necesitamos pasar parámetros adicionales, mudar algo, tratar de implementarlo de alguna manera y hacer que algún tipo de método de curva funcione correctamente, finalmente, después de un par días entendemos que además es imposible. El comportamiento estándar del desarrollador en esta situación es volver al negocio y decir: "Hice esto y aquello, este no funciona así, y no funciona en absoluto, en general, descúbrelo tú mismo". El negocio tiene un problema: necesita profundizar en lo que sucedió, comunicarse con alguien, tratar de resolverlo de alguna manera. El teléfono roto comienza: "díselo, le escribiré, mira lo que contestaron".
Un buen desarrollador, ante tal situación, encontrará los contactos él mismo, cancelará la llamada, hablará por teléfono sobre el problema y, si todo lo demás falla, reunirá a las personas adecuadas, explicará todo y ofrecerá alternativas (lo más probable es que haya otro servicio externo con mejor soporte). Tal desarrollador ve un problema comercial y lo resuelve. Su tarea se cerró cuando resolvió el problema de los negocios, y no cuando se topó con algo.
3: Intenta gastar un mínimo esfuerzo, obteniendo los máximos resultados, incluso si tienes que escribir muletas.
El desarrollo de software en las empresas de comestibles es casi siempre el mayor gasto: los desarrolladores son caros. Y un buen desarrollador comprende que una empresa quiere obtener la cantidad máxima de dinero gastando el mínimo. Para ayudarlo, un buen desarrollador quiere gastar la cantidad mínima de su tiempo costoso para obtener el máximo beneficio para el empleador.
Aquí surgen dos extremos. Una es que es posible resolver todos los problemas en una muleta, no molestarse con la arquitectura, no refactorizar, etc. Todos sabemos cómo suele terminar esto: nada funciona, reescribimos el proyecto desde cero. La otra es cuando una persona intenta encontrar una arquitectura ideal para cada botón, pasa una hora en una tarea y cuatro en refactorizar. El resultado de este trabajo se ve muy bien, pero el problema es que el botón tarda diez horas desde el lado comercial, que en el primero, en el segundo caso, simplemente por varias razones.
Un buen desarrollador puede equilibrar estos extremos. Él entiende el contexto y toma la mejor decisión: en esta tarea estaré cortando una muleta, porque este es un código que se toca una vez cada seis meses. Pero en este caso, estoy confundido y haré todo lo más correctamente posible, porque cien nuevas características que aún no se han desarrollado dependerán de lo que pueda hacer.
4. Tiene su propio sistema de gestión empresarial, es capaz de resolver proyectos de cualquier complejidad.
Trabajar de acuerdo con los principios de Cómo hacer las cosas : cuando escriba todo en un sistema de texto, no olvide ningún acuerdo, empuje a todos, aparezca en todas partes a tiempo, sepa lo que es importante, lo que no es importante en este momento, nunca pierde tareas. La característica general de tales personas es que cuando se llega a un acuerdo con ellas, nunca se preocupa de que se olviden; y también sabes que todos escriben y no harán miles de preguntas, cuyas respuestas ya se han discutido.
5. Dudas y aclara cualquier condición e introducción
También hay dos extremos aquí. Por un lado, puede ser escéptico de todos los introductorios. Antes de usted, la gente encontró algunas soluciones, y usted piensa que puede hacerlo mejor y comenzar a volver a discutir todo lo que vino antes que usted: diseño, soluciones comerciales, arquitectura, etc. Esto pasa mucho tiempo tanto para el desarrollador como para otros, y afecta negativamente la confianza dentro de la empresa: otras personas no quieren tomar decisiones porque saben que ese tipo vendrá nuevamente y lo romperá todo. El otro extremo es cuando un desarrollador percibe cualquier deseo introductorio, de conocimientos tradicionales y de hotel como algo tallado en piedra, y solo cuando se encuentra con un problema insoluble, comienza a pensar si está involucrado en ello. Un buen desarrollador aquí también encuentra un punto medio: tratando de comprender las decisiones tomadas con o sin él, antes de que la tarea entre en desarrollo. ¿Qué quiere el negocio? ¿Resolvemos sus problemas? El diseñador del producto encontró una solución, pero ¿entiendo por qué esta solución funcionará? ¿Por qué el líder del equipo ideó tal arquitectura? Si algo no está claro, entonces debes ir a preguntar. En el proceso de esta aclaración, un buen desarrollador puede ver una solución alternativa que simplemente no se le ocurrió a nadie antes que él.
6. Mejora los procesos y las personas que te rodean.
Hay un montón de procesos a nuestro alrededor: reuniones diarias, reuniones, estafas, esas revisiones, revisiones de códigos, etc. Un buen desarrollador se pondrá de pie y dirá: escucha, vamos a discutir lo mismo todas las semanas, no entiendo por qué, con el mismo éxito, podrías pasar esta hora en "Contra". O: la tercera tarea consecutiva no puedo ingresar el código, nada está claro, la arquitectura está llena de agujeros; tal vez nuestro código de revisión es poco convincente y necesitamos refactorizar, realicemos una refactorización mitap una vez cada dos semanas. O durante una revisión de código, una persona ve que uno de sus colegas no está utilizando una determinada herramienta de manera suficientemente efectiva, lo que significa que debe aparecer y contarlo más tarde. Un buen desarrollador tiene este instinto, hace esas cosas en la máquina.
7. Maneja perfectamente a otros, incluso si no es un gerente
Esta habilidad está bien vinculada al tema de "resolver, no crear problemas". A menudo, no se escribe nada acerca de la administración en el texto de la vacante a la que llegamos, pero luego, cuando se enfrenta a un problema más allá de su control, todavía tiene que administrar a los demás de una forma u otra, obtener algo de ellos, si lo olvida, empuje, asegúrese que todos entendieron. Un buen desarrollador sabe quién está interesado en qué, puede reunir una reunión con estas personas, escribir acuerdos, descartarlos, recordarles el día correcto, asegurarse de que todo esté listo, incluso si él personalmente no es directamente responsable de esta tarea, pero su resultado depende desde su implementación.
8. No percibe su conocimiento como un dogma, constantemente abierto a la crítica.
Todos pueden recordar a un colega de un trabajo anterior que no puede comprometerse con su tecnología, grita que todos se quemarán en el infierno por algunas mutaciones incorrectas. Un buen desarrollador, si ha estado trabajando durante 5, 10, 20 años en la industria, comprende que la mitad de su conocimiento está podrido, y en la mitad restante no sabe diez veces más de lo que sabe. Y cada vez que alguien no está de acuerdo con él y le ofrece una alternativa, este no es un ataque a su ego, sino la oportunidad de aprender algo. Esto le permite crecer mucho más rápido que otros.
Compare mi idea de un desarrollador ideal con el generalmente aceptado:
En esta imagen, puede ver cuántos puntos de los anteriores están relacionados con el código y cuántos no. El desarrollo en una empresa de comestibles es solo un tercio de la programación, los 2/3 restantes tienen poco que ver con el código. Y aunque escribimos mucho código, nuestra efectividad depende en gran medida de estos dos tercios "no relacionados".
Especialización, generalismo y la regla "80-20"
Cuando una persona aprende a resolver algunos problemas limitados, aprende durante mucho tiempo y con dificultad, pero luego los resuelve de manera fácil y sencilla, pero no tiene experiencia en campos relacionados: esta es una especialización. El generalismo, por otro lado, es cuando la mitad del tiempo de capacitación se invierte en una zona de su propia competencia, y otra mitad en campos relacionados. En consecuencia, en el primer caso, hago una cosa perfectamente, y el resto, mal, y en el segundo, hago todo más o menos bien.
La regla 80-20 nos dice que el 80% del resultado se logra a través del 20% del esfuerzo. El 20% de los clientes aporta el 80% de los ingresos, el 20% de los empleados genera el 80% de las ganancias, etc. En el entrenamiento, esto significa que obtenemos el 80% del conocimiento en el primer 20% del tiempo invertido.
Existe una idea: los codificadores solo deben codificar, los diseñadores deben diseñar, los analistas deben analizar y los gerentes deben administrar. En mi opinión, esta idea es tóxica y no funciona muy bien. No es que todos deberían ser soldados universales, se trata de ahorrar recursos. Si un desarrollador es un poco versado en gestión, diseño y análisis, podrá resolver muchos problemas sin involucrar a otras personas. Si necesita hacer alguna función y luego verificar cómo los usuarios trabajan con ella en un determinado contexto, lo que requerirá dos consultas SQL, entonces es genial poder no distraer el análisis. Si necesita presionar un botón por analogía con los existentes, y comprende los principios generales, puede hacerlo sin involucrar a un diseñador, y la compañía le dará las gracias por eso.
Total: puede pasar el 100% del tiempo aprendiendo cierta habilidad hasta el límite, o puede pasar el mismo tiempo en cinco áreas, bombeando el 80% en cada una. Siguiendo estas ingenuas matemáticas, podemos obtener cuatro veces más habilidades al mismo tiempo. Esto es una exageración, pero ilustra la idea.
Las habilidades adyacentes se pueden entrenar no en un 80%, sino en un 30-50%. Después de pasar 10-20 horas, bombeará notablemente en áreas relacionadas, obtendrá una gran comprensión de los procesos que tienen lugar en ellas y se volverá mucho más autónomo.
En el ecosistema de TI moderno, es mejor tener tantas habilidades como sea posible y no ser un experto en ninguna de ellas. Porque, en primer lugar, todas estas habilidades se desvanecen rápidamente, especialmente cuando se trata de programación, y en segundo lugar, porque el 99% del tiempo usamos no solo habilidades básicas, sino ciertamente no las más sofisticadas, y esto es suficiente incluso en la codificación, incluso en empresas geniales.
Y finalmente, la capacitación es una inversión, y la diversificación es importante en las inversiones.
Que enseñar
Entonces, ¿qué enseñar y cómo? Un desarrollador típico en una empresa fuerte usa regularmente:
- comunicacion
- autoorganización
- planificación
- diseño (generalmente código)
- y, a veces, gestión, liderazgo, análisis de datos, redacción, contratación, tutoría y muchas otras habilidades.
Y prácticamente ninguna de estas habilidades se cruza de ninguna manera con el código en sí. Deben ser entrenados y bombeados por separado, y si esto no se hace, permanecerán en un nivel muy bajo, lo que no les permite ser utilizados de manera efectiva.
¿Qué áreas vale la pena desarrollar?
Habilidades blandas: esto es todo lo que no se aplica a las pulsaciones de botones en el editor. Así es como escribimos mensajes, cómo nos comportamos en las reuniones, cómo nos comunicamos con los colegas. Parecen todas las cosas obvias, pero muy a menudo se subestiman.
Sistema de autoorganización. Para mí, durante el año pasado, este se ha convertido en un tema súper importante. Entre todos los excelentes trabajadores de TI que conozco, esta es una de las habilidades más desarrolladas: están superorganizados, siempre hacen lo que dicen, saben exactamente lo que harán mañana, en una semana, en un mes. Es necesario construir un sistema a su alrededor en el que se registren todos los asuntos y todas las preguntas, esto facilita enormemente el trabajo en sí y ayuda enormemente a interactuar con otras personas. Según mis sentimientos, durante el año pasado, el desarrollo en esta dirección me ha impulsado mucho más que bombear habilidades técnicas, comencé a hacer mucho más trabajo por unidad de tiempo.
Proactividad, mentalidad abierta y planificación. Los temas son muy generales y vitales, no exclusivos de TI, y todos deberían desarrollarlos. Proactividad significa no esperar una señal para actuar. Eres la fuente de los acontecimientos, no las reacciones a ellos. Mente abierta: la capacidad de relacionarse objetivamente con cualquier información nueva, para evaluar la situación de forma aislada de su propia visión del mundo y sus viejos hábitos. La planificación es una visión clara de cómo la tarea de hoy resuelve el problema durante una semana, mes, año. Si ve el futuro más allá de una tarea específica, es mucho más fácil hacer lo que necesita y no tener miedo de darse cuenta con el tiempo de que se ha desperdiciado. Esta habilidad es especialmente importante para una carrera: durante años puede lograr resultados exitosos, pero no donde lo necesita, y eventualmente perder todo el equipaje acumulado cuando queda claro que se estaba moviendo en la dirección equivocada.
Todas las áreas relacionadas con el nivel básico. Todos tienen sus propias áreas específicas, pero es importante comprender que al pasar de 10 a 20 horas bombeando algún tipo de habilidad "extranjera", puede descubrir muchas oportunidades nuevas y puntos en común en el trabajo diario, y estas horas pueden ser suficientes para fin de carrera
Que leer
Hay muchos libros sobre autoorganización, esta es una industria completa donde algunos tipos oscuros escriben colecciones de consejos y capacitaciones. Sin embargo, no está claro lo que ellos mismos han logrado en la vida. Por lo tanto, es importante poner filtros en los autores, para ver quiénes son y qué tienen detrás de ellos. Cuatro libros influyeron en mi desarrollo y perspectiva sobre todo, todos ellos de una forma u otra relacionados con el bombeo de las habilidades descritas anteriormente.
1. Dale Carnegie "Cómo hacer amigos e influir en las personas" . Un libro de culto sobre habilidades blandas, si no está claro por dónde empezar, elegirlo es una opción de ganar-ganar. Se basa en ejemplos, es fácil de leer, no requiere mucho esfuerzo para comprender lo que se leyó y las habilidades adquiridas se pueden aplicar de inmediato. En general, el libro revela el tema de la comunicación con las personas.
2. Stephen R. Covey, "7 habilidades de personas altamente efectivas" . Una combinación de diferentes habilidades, desde la proactividad hasta las habilidades blandas, con énfasis en lograr la sinergia, cuando necesita convertir un pequeño equipo en una gran fuerza. Fácil de leer
3. Los principios de Ray Dalio . Revela los temas de mentalidad abierta y proactividad, basados en la historia de la empresa construida por el autor, que dirigió durante 40 años. Una gran cantidad de ejemplos de la vida duramente ganados, excelentes muestra cuán prejuiciosa y dependiente puede ser una persona, cómo deshacerse de ella.
4. David Allen "Cómo poner las cosas en orden" . Lectura requerida para aprender autoorganización. Leerlo no es tan simple, pero proporciona un conjunto exhaustivo de herramientas para organizar la vida y el trabajo, examina en detalle todos los aspectos y lo ayuda a decidir lo que necesita. Con su ayuda, construí mi sistema, que me permite hacer siempre lo más importante, sin olvidar el resto.
Debes entender que solo leer no es suficiente. Puedes tragar incluso un libro a la semana, pero el efecto permanecerá durante varios días y luego todo volverá a su lugar. Los libros deben usarse como una fuente de asesoramiento que se prueba inmediatamente en la práctica. Si esto no se hace, todo lo que darán es una expansión de horizontes.