Jefe técnico Skyeng Kirill Rogovoy () realiza una presentación en conferencias en las que habla sobre las habilidades que todo buen desarrollador debe desarrollar para convertirse en el mejor. Le pedí que compartiera esta historia con los lectores de Habra, le doy la palabra a Kirill.
El mito sobre un buen desarrollador es que él:
- Escribe código limpio
- Conoce muchas tecnologías.
- 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 que no son de programación
- 100% maestro de tu tecnología favorita
Así es como RR.HH. ve a los candidatos ideales y, en consecuencia, las vacantes también se ven así.
Pero mi experiencia dice que esto no es muy cierto.
Primero, dos advertencias importantes:
1) mi experiencia son los equipos de productos, es decir. empresas con producto propio, no subcontratado; en el outsourcing todo puede ser muy diferente;
2) si eres un junior, entonces no todos los consejos serán aplicables, y si yo fuera tú, me concentraría en la programación por ahora.
Buen desarrollador: la realidad
1: código mejor que el promedio
Un buen desarrollador sabe cómo crear una arquitectura interesante, escribir código interesante y no cometer demasiados errores; En general, le va mejor que la media, pero no se encuentra entre el 1% superior de los especialistas. La mayoría de los mejores desarrolladores que conozco no son tan buenos programadores: son excelentes en lo que hacen, pero no pueden hacer nada súper extraordinario.
2: Resuelve problemas en lugar de crearlos
Imaginemos que necesitamos integrar un servicio externo al proyecto. Recibimos las especificaciones técnicas, miramos la documentación, vemos que algo está desactualizado allí, entendemos que necesitamos pasar parámetros adicionales, hacer algunos ajustes, intentar implementarlo todo de alguna manera y hacer que algún método torcido funcione correctamente, finalmente, después de un par de días entendemos que no podemos seguir así. El comportamiento estándar de un desarrollador en esta situación es volver al asunto y decir: “Hice esto y aquello, este no funciona de esa manera y aquel no funciona en absoluto, así que descúbrelo tú mismo. " Una empresa tiene un problema: es necesario ahondar en lo sucedido, comunicarse con alguien e intentar resolverlo de alguna manera. El teléfono roto empieza: “dile tú, le mando un mensaje, mira lo que respondieron”.
Un buen desarrollador, ante tal situación, buscará contactos por sí mismo, se comunicará con él por teléfono, discutirá el problema y, si nada funciona, reunirá a las personas adecuadas, le explicará todo y le ofrecerá alternativas (lo más probable es que haya otro). servicio externo con mejor soporte). Un desarrollador así ve un problema empresarial y lo resuelve. Su tarea se cierra cuando resuelve un problema empresarial y no cuando se topa con algo.
3: Intenta hacer el mínimo esfuerzo para obtener los máximos resultados, incluso si eso significa escribir con muletas
El desarrollo de software en las empresas de productos es casi siempre el gasto más grande: los desarrolladores son caros. Y un buen desarrollador entiende que una empresa quiere obtener la máxima cantidad de dinero gastando el mínimo. Para ayudarle, un buen desarrollador quiere dedicar la mínima cantidad de su costoso tiempo a obtener el máximo beneficio para el empleador.
Aquí hay dos extremos. Una es que generalmente puedes resolver todos los problemas con una muleta, sin preocuparte por la arquitectura, sin refactorizar, etc. Todos sabemos cómo suele acabar esto: nada funciona, reescribimos el proyecto desde cero. Otra es cuando una persona intenta encontrar una arquitectura ideal para cada botón, dedicando una hora a la tarea y cuatro a la refactorización. El resultado de este trabajo parece excelente, pero el problema es que desde el punto de vista empresarial se necesitan diez horas para completar un botón, tanto en el primer como en el segundo caso, simplemente por diferentes motivos.
Un buen desarrollador sabe cómo equilibrar estos extremos. Entiende el contexto y toma la decisión óptima: en este problema cortaré una muleta, porque este es un código que se toca una vez cada seis meses. Pero en este me esforzaré y haré todo lo más correctamente posible, porque de mi éxito dependerán cien nuevas funciones que aún están por desarrollarse.
4. Tiene su propio sistema de gestión empresarial y es capaz de trabajar en proyectos de cualquier complejidad en el mismo.
Trabajando en principios – cuando anotas todas tus tareas en algún tipo de sistema de texto, no olvidas ningún acuerdo, presionas a todos, llegas a todas partes a tiempo, sabes qué es importante y qué no es importante en este momento, nunca pierdes tareas. La característica general de estas personas es que cuando estás de acuerdo con ellos en algo, nunca te preocupas de que lo olviden; y sabes también que lo escriben todo y no harán luego mil preguntas cuyas respuestas ya se han comentado.
5. Cuestiona y aclara las condiciones y presentaciones.
También aquí hay dos extremos. Por un lado, puede mostrarse escéptico ante toda la información introductoria. A las personas anteriores a ti se les ocurrieron algunas soluciones, pero crees que puedes hacerlo mejor y comienzas a volver a discutir todo lo que te precedió: diseño, soluciones comerciales, arquitectura, etc. Esto hace perder mucho tiempo tanto al desarrollador como a quienes lo rodean, y tiene un impacto negativo en la confianza dentro de la empresa: otras personas no quieren tomar decisiones porque saben que ese tipo volverá y lo arruinará todo. El otro extremo es cuando un desarrollador percibe cualquier especificación técnica introductoria y deseo comercial como algo grabado en piedra, y solo cuando se enfrenta a un problema sin solución comienza a pensar si eso es lo que está haciendo. Un buen desarrollador también encuentra aquí un punto medio: intenta comprender las decisiones tomadas antes o sin él, antes de que la tarea entre en desarrollo. ¿Qué quieren las empresas? ¿Estamos solucionando sus problemas? Al diseñador del producto se le ocurrió una solución, pero ¿entiendo por qué funcionará? ¿Por qué al líder del equipo se le ocurrió esta arquitectura en particular? Si algo no está claro, entonces debes preguntar. En el proceso de esta aclaración, un buen desarrollador puede ver una solución alternativa que simplemente no se le había ocurrido a nadie antes.
6. Mejora los procesos y las personas que te rodean
Hay muchos procesos a nuestro alrededor: reuniones diarias, encuentros, scrums, revisiones técnicas, revisiones de códigos, etc. Un buen desarrollador se levantará y dirá: mira, nos reunimos y discutimos lo mismo todas las semanas, no entiendo por qué, bien podríamos dedicar esta hora a Contra. O: en la tercera tarea consecutiva no puedo acceder al código, no hay nada claro, la arquitectura está llena de agujeros; Tal vez nuestro código de revisión sea deficiente y necesitemos refactorizarlo. Refactoricemos la reunión 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 con la suficiente eficacia, lo que significa que necesita acercarse más tarde y dar algún consejo. Un buen desarrollador tiene este instinto; hace esas cosas automáticamente.
7. Excelente para gestionar a otros, incluso si no eres un gerente.
Esta habilidad encaja bien con el tema de “resolver problemas en lugar de crearlos”. A menudo, en el texto de la vacante a la que postulamos, no se escribe nada sobre gestión, pero luego, ante un problema que escapa a tu control, aún tienes que gestionar a los demás de una forma u otra, lograr algo de ellos, si Lo olvidé: presione, asegúrese de que hayan entendido todo. Un buen desarrollador sabe quién está interesado en qué, puede convocar una reunión con estas personas, redactar acuerdos, enviarlos a slack, recordarles el día adecuado, asegurarse de que todo esté listo, incluso si no es personalmente responsable directo de ello. esta tarea, pero su resultado depende de su implementación.
8. No percibe sus conocimientos como dogmas, está constantemente abierto a la crítica.
Todos pueden recordar a un colega de un trabajo anterior que no puede comprometer su tecnología y grita que todos arderán en el infierno por algunas mutaciones incorrectas. Un buen desarrollador, si trabaja 5, 10, 20 años en la industria, comprende que la mitad de su conocimiento está podrido y 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, no es un ataque a su ego, sino una oportunidad para aprender algo. Esto le permite crecer mucho más rápido que quienes lo rodean.
Comparemos mi idea de desarrollador ideal con la generalmente aceptada:
Esta imagen muestra cuántos de los puntos descritos anteriormente están relacionados con el código y cuántos no. El desarrollo en una empresa de productos es sólo 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 eficacia depende en gran medida de estos dos tercios "irrelevantes".
Especialización, generalismo y la regla 80-20
Cuando una persona aprende a resolver algunos problemas específicos, estudia mucho y con ahínco, pero luego los resuelve fácil y simplemente, pero no tiene experiencia en campos relacionados, esto es especialización. El generalismo es cuando la mitad del tiempo de formación se invierte en el área de competencia propia, y la otra mitad en áreas afines. Por tanto, 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 del 80-20 nos dice que el 80% del resultado proviene del 20% del esfuerzo. El 80% de los ingresos proviene del 20% de los clientes, el 80% de las ganancias proviene del 20% de los empleados, y así sucesivamente. En la enseñanza, esto significa que el 80% del conocimiento lo adquirimos en el primer 20% del tiempo dedicado.
Hay una idea: los codificadores sólo deberían codificar, los diseñadores sólo deberían diseñar, los analistas deberían analizar y los gerentes sólo deberían gestionar. En mi opinión, esta idea es tóxica y no funciona muy bien. No se trata de que todos tengan que ser un soldado universal, sino de ahorrar recursos. Si un desarrollador entiende al menos un poco de gestión, diseño y análisis, podrá resolver muchos problemas sin involucrar a otras personas. Si necesita crear algún tipo de característica y luego comprobar cómo trabajan los usuarios con ella en un contexto determinado, lo que requerirá dos consultas SQL, entonces es genial no poder distraer al analista con esto. Si necesita incrustar un botón por analogía con los existentes y comprende los principios generales, puede hacerlo sin involucrar a un diseñador y la empresa se lo agradecerá.
Total: puedes dedicar el 100% de tu tiempo a estudiar una habilidad al límite, o puedes dedicar el mismo tiempo a cinco áreas, subiendo de nivel hasta el 80% en cada una. Siguiendo estas matemáticas ingenuas, podemos adquirir cuatro veces más habilidades en la misma cantidad de tiempo. Esto es una exageración, pero ilustra la idea.
Las habilidades relacionadas se pueden entrenar no en un 80%, sino en un 30-50%. Después de pasar entre 10 y 20 horas, mejorará notablemente en áreas relacionadas, comprenderá mucho los procesos que ocurren en ellas y se volverá mucho más autónomo.
En el ecosistema TI actual, 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 utilizamos no solo habilidades básicas, sino ciertamente no las más sofisticadas, y esto es suficiente incluso en codificación, incluso en empresas geniales.
Y por último, la formació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 de una empresa sólida utiliza habitualmente:
- comunicación
- 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í. Es necesario enseñarlos y mejorarlos por separado, y si no se hace esto, permanecerán en un nivel muy bajo, lo que no permitirá su uso eficaz.
¿En qué áreas vale la pena desarrollarse?
Las habilidades sociales son todo lo que no tiene que ver con presionar botones en el editor. Así escribimos mensajes, cómo nos comportamos en las reuniones, cómo nos comunicamos con los compañeros. Todas estas cosas parecen obvias, pero muy a menudo se subestiman.
Sistema de autoorganización. Para mí personalmente, este se ha convertido en un tema muy importante durante el año pasado. Entre todos los buenos trabajadores de TI que conozco, esta es una de las habilidades más desarrolladas: son súper organizados, 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; Siento que durante el año pasado el desarrollo en esta dirección me ha mejorado mucho más que mejorar mis habilidades técnicas, comencé a hacer mucho más trabajo por unidad de tiempo;
Proactiva, de mente abierta y planificadora. 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. La mentalidad abierta es la capacidad de tratar cualquier información nueva de manera objetiva, de evaluar la situación independientemente de la propia visión del mundo y de los viejos hábitos. La planificación es una visión clara de cómo la tarea de hoy resuelve el problema de la semana, mes, año. Si ves el futuro más allá de una tarea específica, será mucho más fácil hacer lo que necesitas y no tener miedo de darte cuenta con el tiempo de que fue en vano. Esta habilidad es especialmente importante para una carrera: puede lograr resultados con éxito durante años, pero en el lugar equivocado, y eventualmente perder todo el equipaje acumulado, cuando queda claro que se estaba moviendo en la dirección equivocada.
Todas las áreas afines al nivel básico. Cada uno tiene sus propias áreas específicas, pero es importante comprender que al dedicar de 10 a 20 horas a mejorar alguna habilidad "extranjera", puede descubrir muchas oportunidades y puntos de contacto nuevos en su trabajo diario, y estas horas pueden será suficiente hasta el final de la carrera.
que leer
Hay muchísimos libros sobre autoorganización; es toda una industria en la que algunos tipos extraños escriben colecciones de consejos y reciben capacitación. Al mismo tiempo, no está claro qué han logrado ellos mismos en la vida. Por eso, es importante poner filtros a los autores, fijarse en quiénes son y qué tienen detrás. Mi desarrollo y perspectiva estuvieron más influenciados por cuatro libros, todos ellos relacionados de una forma u otra con la mejora de las habilidades descritas anteriormente.
1. Dale Carnegie "Cómo ganar amigos e influir en las personas". Un libro de culto sobre habilidades sociales, si no sabes por dónde empezar, elegirlo es una opción en la que todos ganan. Se basa en ejemplos, es fácil de leer, no requiere mucho esfuerzo para comprender lo que lee y las habilidades adquiridas se pueden aplicar de inmediato. En general, el libro cubre el tema de la comunicación con las personas.
2. Stephen R. Covey "7 hábitos de las personas altamente efectivas". Una combinación de diferentes habilidades, desde proactividad hasta habilidades sociales, con énfasis en lograr sinergia cuando necesitas convertir un equipo pequeño en una fuerza enorme. También es fácil de leer.
3. "Principios" de Ray Dalio. Revela temas de apertura de mente y proactividad, a partir de la historia de la empresa que el autor construyó y que dirigió durante 40 años. Muchos ejemplos de vida ganados con esfuerzo muestran cuán prejuiciosa y dependiente puede ser una persona, y cómo deshacerse de ellos.
4. David Allen, "Hacer las cosas". Lectura obligatoria para aprender a autoorganizarse. No es tan fácil de leer, pero proporciona un conjunto completo de herramientas para organizar la vida y los asuntos, examina todos los aspectos en detalle y le ayuda a decidir qué es exactamente lo que necesita. Con su ayuda, construí mi propio sistema que me permite hacer siempre las cosas más importantes sin olvidarme del resto.
Debes entender que leer no es suficiente. Puedes tragar al menos un libro a la semana, pero el efecto durará varios días y luego todo volverá a su lugar. Los libros deben utilizarse como fuente de consejos que se pongan a prueba inmediatamente en la práctica. Si no haces esto, lo único que te darán será una ampliación de tus horizontes.
Fuente: habr.com
