Ya sea desarrollo, pruebas u operaciones, todo profesional técnico alberga en mayor o menor medida el sueño de convertirse en un gran maestro técnico. Después de todo, “¡los sueños siempre deben existir, por si acaso se cumplen!” Es precisamente la búsqueda del sueño técnico lo que nos impulsa a esforzarnos y mejorarnos continuamente.

Sin embargo, “los sueños son hermosos, pero la realidad es cruel”. Muchos compañeros descubren tras empezar a trabajar que, aunque sueñan con ser grandes maestros, lo que hacen no parece tener nada que ver con ser un gran maestro. Por ejemplo, los programadores dicen: “Todos los días escribo código de negocio y además hago horas extras, ¿cómo puedo convertirme en un gran maestro técnico?”; los testers dicen: “Todos los días hay casos de prueba interminables”; los de operaciones dicen: “Cargar máquinas, conectar cables de red y teclear comandos de shell, esta no es la vida de operaciones que quiero”...... En Zhihu, una pregunta similar: “Un programador que escribe código de negocio todos los días, ¿cómo se convierte en un gran maestro técnico y empieza a escribir código técnico?” tiene más de 6.000 seguidores y más de 120 respuestas. En aquel momento también respondí y obtuve la mayor cantidad de “me gusta”. Más tarde, cuando participé en evaluaciones y comunicaciones para ascensos de nivel profesional, tuve nuevos hallazgos e ideas, por lo que surgió la idea de redactar un artículo sistematizado, con la esperanza de que más compañeros puedan evitar desvíos en el camino hacia convertirse en grandes maestros técnicos.

Como soy programador, algunos de los ejemplos siguientes se basan en el desarrollo de software, pero los principios generales son comunes y pueden servir de referencia para pruebas y operaciones.

Algunos malentendidos típicos

1. Tomar a un gran maestro como mentor

En Zhihu, algunos consideran que la forma más sencilla, directa, rápida y efectiva de convertirse en un gran maestro técnico es “tomar a un gran maestro del equipo como mentor”, para que te den formación adicional personalizada y te asignen tareas difíciles.

Personalmente me opongo a este método, principalmente por varias razones:

• Los grandes maestros están muy ocupados; es poco probable que te den formación adicional personalizada, y mucho menos una hora diaria. Además, dentro de un equipo, si un gran maestro te da formación adicional con frecuencia, inevitablemente causará sospechas entre los demás miembros del equipo. Personalmente creo que, si un gran maestro del equipo realmente tiene la intención, lo mejor es ofrecer más capacitaciones al equipo. Sin embargo, quienes han dado capacitaciones saben que preparar una sesión requiere mucho tiempo: al menos 2 horas para materiales y diapositivas (y no con tiempo fragmentado), más 1 hora para explicar. Que los grandes maestros den una capacitación al mes ya es una frecuencia muy alta.
• Debido a la primera razón, generalmente cuando se busca a un gran maestro es para consultar o discutir con una pregunta concreta. Porque responder o debatir una pregunta no requiere demasiado tiempo; depende más de la experiencia y la acumulación. En tales casos, los grandes maestros están muy dispuestos a ayudar, después de todo, la influencia es un indicador importante para un gran maestro. Sin embargo, hay que prestar especial atención: si preguntas con frecuencia sobre conocimientos que se pueden encontrar fácilmente en libros o en Google, los grandes maestros también se impacientarán, pues el tiempo es valioso. A menudo hay internautas que me preguntan cosas como “¿cómo se configura el parámetro -Xmn de JVM?”. Yo respondo directamente: “ve a Google”. Porque hay demasiadas preguntas de este tipo; si no estudias sistemáticamente por tu cuenta, preguntar todo es un gran desperdicio del tiempo de los demás y del tuyo.
• No hay muchos grandes maestros; es poco probable que cada equipo tenga un gran maestro técnico. En todo caso, en un equipo puede haber personas de mayor nivel que tú. Incluso si esa persona te diera formación adicional todos los días, al final solo podrías elevarte hasta su nivel. Y si se trata de un gran maestro técnico de otro equipo, debido a la organización y asignación del trabajo, las oportunidades de consultar y recibir orientación directa son escasas. Solo con asistir a algunas capacitaciones de un gran maestro es muy poco probable convertirte en uno.

En resumen, por las razones anteriores, creo que para la mayoría de las personas, si quieren convertirse en grandes maestros técnicos, primero deben entender el principio de “depender principalmente de uno mismo”. No esperes que un gran maestro, como un maestro de artes marciales, te enseñe paso a paso de la mano. En el momento adecuado, puedes mejorar consultando a un gran maestro o debatiendo con él, pero la mayor parte del tiempo debes mejorar de forma sistemática y dirigida por ti mismo.

2. El código de negocio también puede ser igual de increíble

En Zhihu, algunas respuestas consideran que escribir código de negocio también puede ser increíble, con el argumento de que el código de negocio también puede tener varias técnicas. Por ejemplo, se puede usar encapsulamiento y abstracción para hacer que el código de negocio sea más extensible; se puede comunicar más con el equipo de producto para comprender y realizar mejor el negocio; si se lleva un buen registro de logs, la eficiencia para localizar problemas puede multiplicarse por 10... etc.

El código de negocio también tiene contenido técnico, eso es seguro. La tecnología en el código de negocio es la base de todo programador, pero solo dominar estas técnicas no te convierte en un gran maestro técnico. Es como subir de nivel derrotando monstruos en un juego: al principio, matar monstruos menores da mucha experiencia; pero cuanto más avanzas, menos experiencia otorgan. Llega un punto en que ya no se puede subir de nivel matando monstruos menores; entonces se necesitan monstruos más avanzados y mazmorras más desafiantes. No se ha visto ningún juego en el que se pueda llegar al nivel máximo solo matando monstruos menores. El camino para convertirse en un gran maestro técnico es similar: debes mejorar continuamente tu nivel, enfrentar mayores desafíos y, al superarlos, subir un escalón más en tu nivel; y así sucesivamente, hasta alcanzar el nivel de gran maestro técnico e incluso de gran maestro de la industria. Escribir código de negocio es solo un desafío en este camino de subir de nivel matando monstruos, y creo que es un desafío relativamente básico.

Por lo tanto, creo que un programador que no puede escribir bien código de negocio seguramente no podrá convertirse en un gran maestro técnico, pero un programador que solo escribe bien código de negocio tampoco podrá convertirse todavía en un gran maestro técnico.

3. Estoy demasiado ocupado en el trabajo y no tengo tiempo para estudiar por mi cuenta

Muchas personas creen que no haberse convertido en un gran maestro técnico no se debe a que no sean inteligentes ni a que no se esfuercen, sino a que, en el entorno de China, los profesionales técnicos hacen demasiadas horas extras, lo que les deja sin tiempo adicional para estudiar.

Esta razón tiene cierta objetividad; después de todo, en comparación con Europa y Estados Unidos, nosotros sí hacemos más horas extras. Sin embargo, este factor es solo un problema que hay que superar, no es una brecha insuperable. Después de todo, a nuestro alrededor hay muchos grandes maestros que también crecieron en este entorno de China.

Creo que hay varios malentendidos que llevan a esta opinión:

1) En el trabajo solo hago tareas repetitivas; para mejorar, necesito estudiar adicionalmente por mi cuenta

La razón principal de este malentendido es creer que “escribir código de negocio no tiene contenido técnico”. Y como ahora en el trabajo escribo código de negocio, pienso que no puedo mejorar en el trabajo.

2) Estudiar requiere grandes bloques de tiempo continuo

Muchas personas piensan que estudiar debe ser como ir a clases en la escuela: necesitas un día entero para estudiar. Como solemos hacer muchas horas extras y los fines de semana estamos tan cansados que solo queremos dormir hasta tarde, o solo queremos ver películas o jugar videojuegos para relajarnos, no hay tiempo para estudiar.

En realidad, el enfoque correcto es todo lo contrario: en primer lugar, debemos aprender y mejorar en el trabajo, porque cuando aplicas lo aprendido o tienes ejemplos reales de referencia, el efecto del aprendizaje es el mejor. En segundo lugar, después del trabajo no se necesitan grandes bloques de tiempo para estudiar; hay que hacer un hueco y aprovechar los fragmentos de tiempo para aprender.

La forma correcta de hacerlo

1、Do more

Haz más, haz más de lo que tu supervisor te asigna.

Cuando estaba en HW, me encargué del desarrollo de una versión. La carga de trabajo de esta versión era de unas 2000 líneas aproximadamente. Pero además de completar esta funcionalidad, dominé por completo todas las funcionalidades relacionadas y leí todo el código (unas 10000 líneas). Después de terminar esta versión, me familiaricé con todo el conjunto de negocios relacionado con ella. Tras una o dos reuniones, todos descubrieron que yo era quien mejor dominaba esta área. Entonces empezó lo interesante: el equipo de producto me buscaba para discutir requisitos, los testers me buscaban cuando tenían problemas, y mi jefe también me buscaba para dar soporte externo. Más tarde, incluso me buscaban para funcionalidades que no eran de mi responsabilidad; aunque no supiera la respuesta en ese momento, revisaba el código o buscaba documentos para ayudarles a responder... Finalmente, me convertí en el “experto” de este sistema. Aunque en ese momento todavía me dedicaba al negocio y seguía escribiendo código de negocio, ya conocía muy bien todo el negocio.

Lo anterior es solo un ejemplo sencillo. En realidad, lo que quiere decir es: para tener oportunidades, primero debes destacar entre la multitud; para destacar, debes ser diferente; para ser diferente, ¡tienes que hacer más!

¿Cómo hacer más? Se puede empezar desde los siguientes aspectos:

1) Familiarízate con más negocios, ya sea que sean de tu responsabilidad o no; familiarízate con más código, ya sea que lo hayas escrito tú o no.

Hacer esto tiene muchos beneficios; pongo algunos ejemplos sencillos:

• El análisis de requisitos es más preciso, y se pueden identificar riesgos, impactos y dificultades ya en la fase de requisitos.
• La resolución de problemas es más rápida, porque al estar familiarizado con el negocio y el código relacionados, se puede determinar rápidamente la posible causa del problema y realizar la investigación y el tratamiento.
• El diseño de soluciones es más completo, porque al tener una comprensión del negocio global, se puede diseñar una mejor solución.

2) Familiarízate con el extremo a extremo (end-to-end)

Por ejemplo, si te encargas del desarrollo de backend web, cuando un usuario realiza una solicitud HTTP, esta pasa por muchos pasos intermedios antes de llegar a tu servidor (como caché del navegador, DNS, nginx, etc.). Luego, el servidor generalmente pasa por mucho procesamiento antes de llegar a la parte del código que escribiste (rutas, permisos, etc.). En muchos de los sistemas o pasos de todo este flujo, la gran mayoría de las personas no puede participar en la escritura de código. Sin embargo, dominar estos conocimientos tiene una gran influencia en tu nivel integral. Por ejemplo, el diseño de soluciones y el manejo de fallos en producción, que son trabajos técnicos de mayor valor, requieren un nivel técnico integral.

Las palabras “sistemático”, “global” e “integral” parecen un poco abstractas, pero en realidad son cualidades imprescindibles de un gran maestro técnico. Para alcanzar ese nivel, es necesario familiarizarse con más sistemas, negocios y código.

3) Autoaprendizaje

En general, en equipos bastante maduros, como los frameworks o componentes ya están muy encapsulados, la tecnología que se usa para escribir código de negocio es realmente poca. Pero debemos entender que “lo único constante es el cambio”: los frameworks pueden necesitar mejoras, los componentes pueden reemplazarse, o puedes cambiar de empresa y la nueva no tiene ni componentes ni frameworks, y tendrás que hacerlo todo desde cero. Todas estas son oportunidades y también desafíos, y las oportunidades y los desafíos solo se asignan a los que están preparados. Por lo tanto, en esta situación necesitamos aprender más cosas por nuestra cuenta, porque cuando realmente llegue el momento de usarlas, ya no habrá tiempo para aprender.

Tomando Java como ejemplo, la mayor parte del código de negocio consiste en if-else más operaciones de base de datos. Pero podemos aprender por nuestra cuenta más conocimientos de Java, como recolección de basura (garbage collection), optimización del rendimiento, programación de redes, etc. Puede que de momento no sirvan, pero cuando realmente se necesiten, no basta con buscarlo en Google. En ese momento, la oportunidad será para quien ya haya dominado los conocimientos y habilidades relacionados.

Tomando la recolección de basura como ejemplo, yo personalmente dediqué tiempo a aprender estos conocimientos. Estuve un año sin usarlos, pero luego los usé varias veces, y cada vez resolví grandes problemas de congelación del sistema. Sin embargo, algunos compañeros que llevan varios años escribiendo código Java no tienen ni idea de qué es el concepto de stop-the-world, y mucho menos de cómo optimizarlo.

2、Do better

Hay que saber que nada en este mundo es perfecto; los sistemas y negocios de los que eres responsable siempre tienen lugares irracionales y mejorables. Estos lugares "irracionales" y "mejorables" son monstruos de nivel más alto; derrotarlos te da más puntos de experiencia. Identifica estos puntos, propón soluciones y preséntalas a tu supervisor. Si no funciona a la primera, inténtalo dos veces; presenta varias veces. Con que una se materialice, esa será tu oportunidad.

Por ejemplo:

• ¿Hay demasiado código repetido? ¿Se puede introducir un patrón de diseño?
• ¿El rendimiento del sistema es mediocre? ¿Se puede optimizar?
• Actualmente es de un solo nodo; ¿sería mejor convertirlo en dos nodos?
• ¿La calidad del desarrollo de versiones no es alta? ¿Se pueden introducir soluciones eficientes de pruebas unitarias y de integración?
• ¿El sistema actual es demasiado grande? ¿Se puede dividir en 3 sistemas mediante refactorización y desacoplamiento?
• Hay algunos sistemas del middleware de Alibaba que siento que también podríamos usar; ¿se pueden introducir?
• 。。。。。。。。。。。。。。。。。。。

Mientras pienses en ello, siempre podrás encontrar algo que mejorar. Si sientes que no hay nada que mejorar en el sistema, significa que tu nivel aún no es suficiente. Puedes aprender más sobre tecnologías relacionadas y observar cómo lo hacen otras empresas del sector y cómo lo hacen BAT.

En 2013 fui asignado a Jiuyou. Al principio me encargué de un sistema back-end simple: todos los días era hacer altas, bajas, modificaciones y consultas de datos para el front-end. Parecía completamente aburrido, ¿verdad? Si solo hicieras eso, sí sería aburrido, pero después de hacernos cargo hicimos muchas cosas:

• Desacoplar: dividimos un back-end en dos back-ends, mejorando la escalabilidad y la estabilidad.
• Doble nodo: cambiamos de un solo nodo a un sistema de doble nodo, aumentando la fiabilidad.
• Optimización: optimizamos una interfaz que originalmente tardaba 5 horas para que tardara 5 minutos.

También hubo muchas otras optimizaciones. Más tarde, nuestro grupo asumió más sistemas; luego este equipo de 5 personas fue responsable de 6 sistemas.

3、Do exercise

Durante las conversaciones sobre niveles profesionales, descubrí que muchos compañeros realmente intentan Do more y Do better, pero en el proceso de ejecución casi todos encuentran el mismo problema: solo mirar sin practicar da resultados muy pobres, ¿qué se hace?

Por ejemplo:

• He aprendido sobre la recolección de basura de JVM, pero en producción rara vez aparecen problemas de congelación causados por FGC; incluso si aparecen, restaurar el negocio es lo primero. No es probable que surja un problema en producción y que cada compañero pueda practicar con él. Entonces, ¿cómo practicar estos conocimientos y habilidades de JVM?
• También he leído sobre Netty y entiendo el principio de Reactor, pero no puedo participar en el desarrollo de Netty. ¿Cómo puedo llegar a dominar de verdad el patrón asíncrono de Reactor?
• He leído "High Performance MySQL", pero las bases de datos en producción las gestionan los DBA, y las de los entornos de prueba parecen estar configuradas al azar. ¿Cómo puedo verificar estas técnicas?
• El framework encapsula la capa DAL; no tenemos que preocuparnos por el acceso a la base de datos. ¿Cómo podemos entender la implementación de la fragmentación de bases de datos y tablas?
• 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Hay muchas preguntas similares. Aquí comparto mi experiencia personal; en resumen, son 3 palabras: learning, trying, teaching.

1）Learning

Esta es la primera fase: leer libros, usar Google, ver videos, leer blogs de otros. Pero hay que prestar atención a la "sistematización", especialmente en cuestiones básicas como los principios de JVM, programación Java, programación de red, protocolo HTTP, etc. Estas tecnologías fundamentales no se pueden aprender solo con Google o blogs. Mi método habitual es primero leer un libro completo para tener una comprensión general, y luego usar Google, videos y blogs para buscar de forma dirigida puntos dudosos o algunos trucos.

2）Trying

Este paso es la clave para resolver las dudas de muchos compañeros mencionadas antes. En términos gráficos, es "si quieres comer, ponte a trabajar", es decir, intentar construir uno mismo entornos simulados y escribir programas de prueba. Por ejemplo:

• Recolección de basura de JVM: puedes escribir un programa de prueba simple, asignar memoria sin liberarla, ajustar varios parámetros de arranque de JVM y, durante la ejecución, usar comandos como jstack o jstat para ver la distribución del montón de JVM y el estado de la recolección de basura. Escribir este tipo de programa es muy sencillo; los simples tienen pocas líneas y los más complejos unas pocas docenas.
• Principio de Reactor: intenta realmente escribir un demo del patrón Reactor. No creas que es muy difícil; el código del patrón Reactor más simple (incluidos los comentarios) no supera las 200 líneas (puedes consultar el PPT de Doug Lee). Después de escribirlo, mira cómo lo hace Netty y, al comparar, entenderás mucho más profundamente.
• MySQL: como tenemos la configuración de producción como referencia, podemos pedir directamente al DBA que nos envíe la configuración de producción (cuidando de eliminar información sensible) y aprender directamente; luego montamos nuestro propio entorno MySQL y lo iniciamos con la configuración de producción. Hay que saber que muchos compañeros han usado MySQL durante años, pero ni siquiera pueden montar un entorno MySQL simple.
• El framework encapsula la capa DAL: puedes intentar escribir tú mismo una implementación simple de fragmentación de bases de datos y tablas con JDBC, y luego compararla con la implementación del framework para ver dónde están las diferencias.
• Usa las herramientas del navegador para ver la implementación de caché HTTP, observa cómo los diferentes tipos de sitios web y diferentes tipos de recursos controlan el caché en concreto; también puedes escribir un servidor HTTP simple en Python para simular la devolución de varios encabezados HTTP y observar la reacción del navegador.
• 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Hay muchos otros métodos; no los enumeraré uno por uno. En resumen, hay que probar de verdad lo que se aprende para entenderlo más profundamente. Los indios tienen un refrán: I hear and I forget. I see and I remember. I do and I understand. Además, "probar" puede ser relativamente simple; muchas veces podemos hacerlo nosotros mismos.

Por supuesto, si puedes usarlo en el trabajo real, el efecto será mejor, porque el entorno real de producción y la complejidad del negocio no se pueden simular con un programa de prueba. Pero estas oportunidades son difíciles de encontrar; en la mayoría de los casos solo podemos confiar en simular por nuestra cuenta y, cuando el negocio realmente lo necesite, poder usarlo con soltura.

3）Teaching

En general, después de Learning y Trying se puede dominar alrededor del 70%, pero para dominarlo de verdad creo que hay que ser capaz de explicarlo claramente a otros. Porque al explicar, necesitamos sistematizar un punto de conocimiento y también considerar varios detalles, lo que nos impulsa a pensar y aprender más. Además, al exponerlo, quienes lo ven o escuchan pueden tener interpretaciones diferentes o aportar nuevos complementos, lo que equivale a seguir perfeccionando todo el sistema de habilidades y conocimientos.

Hay muchos ejemplos de esto. A mí también me pasa a menudo al escribir un blog: creía que ya lo dominaba por completo, pero al escribir descubría que había muchos puntos que no había considerado. También se ve a menudo en las formaciones internas: algunos compañeros preparan un PPT, pero al exponerlo, cuando la gente pregunta o debate, se descubre que hay muchos puntos que no se han explicado con claridad, o que algunos puntos se habían entendido mal. Escribir el PPT, exponerlo y discutirlo: recorrer todo ese proceso hace que, básicamente, se domine un punto de conocimiento de manera bastante completa.

Epílogo

Aunque el sueño de convertirse en un gran experto técnico es hermoso, hay que esforzarse mucho. Ya sea Do more, Do better o Do exercise, se necesita tiempo y energía. En este proceso puede haber momentos muy duros o muy aburridos. Aquí quiero enfatizar especialmente: lo que he dicho antes son cuestiones de metodología, pero lo que realmente decide el resultado es, en definitiva, nuestra pasión e interés por la tecnología.