Todavía no me he dado cuenta, ya es fin de año; suspiro por cómo la flecha del tiempo pasa tan rápido, y en un instante la vida se reduce en uno. Mirando hacia atrás, ya soy programador desde hace más de siete años. Aunque no he logrado gran cosa, tampoco he desperdiciado todo. Hago un pequeño resumen para no perder el tiempo transcurrido, y también será de gran beneficio para el camino futuro. Si esta publicación puede ayudar a ustedes en algo, me alegraré mucho.


La carrera profesional es un maratón de muchos tramos conectados entre sí


En la primaria sabíamos claramente que nos graduaríamos en cinco años (en mi época era un plan de cinco años; parece que en algunos lugares todavía es así). No importa cuánto odiaras a los maestros, compañeros o la escuela, sabías que a lo más duraría cinco años y terminaría. En la secundaria y preparatoria igual: tres o cuatro años, pasan rápido, y tantas alegrías y tristezas pasarán pronto. En la universidad es aún más así: desde el día en que entras al campus empiezas la cuenta regresiva, sabes que un día dentro de cuatro años te irás; por más que valores el tiempo o lo desperdicies, el tiempo sigue corriendo en una dirección a su velocidad inmutable.



¿Pero qué hay del ámbito laboral? Después de cinco años, sigues trabajando y tendrás que trabajar; después de diez, veinte, treinta o incluso cuarenta años, todavía tendremos que trabajar. Aunque renuncies, tendrás que volver a emplearte, y el nuevo trabajo no es esencialmente diferente al anterior. Entendí que la vida laboral es un gran ciclo de cuarenta años; por lo tanto, es un maratón ultralargo. No hay sprint para el examen de ingreso a la secundaria, ni para el de la universidad, mucho menos ese “entrar a una buena universidad y ya puedes jugar sin preocupaciones”. No hace falta correr a toda velocidad con desesperación; eso no daría buenos resultados. Lo más importante es seguir aprendiendo continuamente, sí, aprender durante décadas.


El único camino para convertirse en experto o en un gran maestro es aprender constantemente.


No sueñes con que entrar en una gran empresa, unirte a un equipo increíble, sentarte al lado de un gran maestro, o asistir a más eventos offline te convertirá en un gran maestro. Eso es ser demasiado joven, demasiado simple. ¿Por qué te querría una gran empresa? ¿Por qué te querría un equipo increíble? Primero tienes que tener algo de habilidad. Conseguir la guía de un experto depende de la suerte. Quizás has visto demasiados dramas: ¿caes en un valle, te encuentras con un mono blanco con el “Jiuyang Zhenjing” escondido en el vientre? ¿O ruedas por el valle, ves un águila enorme y aprendes el “Dugu Jiujian”? Entre la multitud, hay millones de programadores en el país, ¿cuántas probabilidades crees que tienes de encontrarte con un gran dios? ¿Cuál es la probabilidad de que el gran dios quiera comunicarse contigo? ¿Sueñas con que un gran dios te enseñe paso a paso? A menos que seas su amante con beneficios.


Por supuesto, hay quienes tienen la suerte suficiente para recibir algunos consejos de un maestro. Pero creemos que para la gran mayoría, incluso si el experto está a tu lado, no tendrás suficientes oportunidades para que te oriente. La empresa nos contrató para trabajar, para generar valor y ganar dinero para ella. Los expertos tienen tareas más pesadas y más cosas que hacer; ¿por qué deberían además orientarte?


Las grandes empresas tienen muchos recursos y material, y también muchas oportunidades de capacitación, pero debes verlas, escucharlas y aprender por ti mismo. En cuanto a las actividades offline, la mayoría son para hacer publicidad; las demás charlas también suelen tocar solo la superficie. Es imposible aprender algo sustancioso; en unas decenas de minutos, ¿cuánto puede exponer? ¿Y cuánto puedes entender tú? Por eso las actividades offline son buenas oportunidades para la promoción, ampliar horizontes (puedes escuchar muchos conceptos) y ampliar contactos (de verdad puedes conocer a mucha gente, expertos y personas de tu nivel), no para aprender.


En una palabra, para convertirte en un experto, debes estudiar con los pies en la tierra, leer libros, leer código, escribir código; no hay otro camino. Sobre esto, puedes consultar un artículo de un gran maestro (Escribiendo código de negocio todos los días, ¿cómo convertirse en un gran experto técnico?), me parece muy razonable.


Elige una industria o una tecnología, y luego dedícate a ella en profundidad.


Aunque no se recomienda hacer planes de cinco años como algunos, porque nuestra industria, empresa, proyectos, personal, etc. cambian demasiado rápido; estos cambios son factores inciertos que alterarían todos los planes, especialmente los de largo plazo. Pero aun así debemos tener objetivos. Creo que para la mayoría de las personas, el objetivo final no es más que la libertad financiera. ¿Cómo lograr la libertad financiera? La suerte tiene cierto papel, pero lo más importante es la fuerza real. ¿Qué es la fuerza real? Es poder resolver problemas que otros no pueden resolver; por ejemplo, si el jefe quiere hacer un cierto negocio, tú conoces especialmente bien las reglas de ese negocio y puedes dirigir el equipo para ayudar al jefe a lograrlo; o si surge un problema técnico, tú puedes resolverlo. Sin fuerza real, solo con suerte, aunque hubieras estado en el auge de Taobao, ahora quizás no tendrías libertad financiera.


¿De dónde viene la fuerza real? No es más que de la acumulación. ¿Acumular qué? ¿Qué te vuelve cada vez más valioso? No es más que la industria o la tecnología.


¿Qué es una industria? El automóvil es una industria, las finanzas son una industria, la ropa es una industria, el turismo y los viajes son una industria, etc. ¿Y qué es una tecnología? La seguridad, el audio, Webkit, las imágenes, el aprendizaje profundo, etc. son tecnologías. En una industria, la tecnología puede no ser compleja, se usan tecnologías convencionales, pero si puedes conocer en profundidad una industria—cuáles son sus reglas del juego, qué trampas tiene, qué políticas y regulaciones, qué riesgos, cómo hacer para obtener el máximo beneficio—todo esto solo se sabe después de un tiempo trabajando en esa industria. La tecnología es más fácil de entender: usar tecnología empaquetada es fácil; por ejemplo, WebView es muy conveniente de usar, pero su implementación técnica—WebKit—es muy compleja; sin varios años no puedes entenderla.


Por supuesto, poder profundizar siempre en el mismo campo (ya sea industria o tecnología) no es fácil; depende de la suerte. Pero hay que entender que solo profundizando en una industria o tecnología maximizarás tu valor. Por eso, cuando tengas opciones, acércate lo más posible a tu objetivo.


La responsabilidad es más importante que la tecnología.


El trabajo de un programador, ya sea en internet o en software empresarial, es ingeniería, es la aplicación de tecnología. En la mayoría de los casos, la mayoría de la gente no se encuentra en el trabajo con problemas técnicamente irresolubles o desafíos de nivel mundial. En otras palabras, los problemas que surgen en el trabajo, aunque no sepas cómo resolverlos, se pueden resolver rápidamente consultando documentación, libros, internet y con la ayuda de colegas. Además, escribir buen código, hacer suficientes pruebas, aumentar la robustez: estas cosas no requieren tecnologías muy profundas o vanguardistas. Con poner empeño, se puede hacer muy bien.


Por el contrario, quienes hacen mal su trabajo no es porque su nivel técnico sea malo; la evaluación de los demás hacia ellos seguramente es “irresponsables”. Como se dice, la actitud lo decide todo; la consecuencia de la actitud es la responsabilidad. Aunque el nivel técnico sea promedio, si la actitud es seria y el trabajo responsable, ese es un empleado excelente y más valioso para la empresa. En cambio, algunos aunque sean técnicamente fuertes, tienen mala actitud y no son responsables; ese tipo de personas son parásitos que solo comen sin trabajar y esperan la muerte, son tumores que tarde o temprano serán extirpados.


Conviértete en un programador profesional.


Aquí “profesional” se refiere más a la forma y al método de hacer las cosas. Antes de explicar qué es profesional, veamos algunos ejemplos de lo que no es profesional:


  • Durante una entrevista telefónica, sin preguntar si la otra persona puede escuchar con claridad, comienzas a hablar “blah blah blah”, y después de hablar unos diez minutos, el otro suspira y dice: “Lo siento, la señal es mala, no te oí...”.
  • Por ejemplo, en una entrevista telefónica, el candidato dice: “Déjame buscar un lugar conveniente”, luego te llama, dice que ya lo encontró, y entonces comienza la entrevista telefónica... ¡Pero fue el candidato quien te llamó!...
  • Por ejemplo, llegar tarde a las reuniones, por ejemplo, hablar de tonterías durante la reunión...
  • Llegar a conclusiones apresuradas sin aclarar los hechos, especialmente las personas de mal genio, incluso empiezan a insultar...

Creo que ejemplos de este tipo son innumerables, y estoy muy seguro de que los programadores y programadoras también se encuentran con estas cosas a menudo en su trabajo diario. A menudo respondemos ante tales cosas con “no profesional”. Sí, eso es no ser profesional.


Al revés, eso es ser profesional:


Antes de la entrevista telefónica, primero pregunta si la otra persona puede oír con claridad, y luego “blah blah”. Si el candidato te dice “ahora estoy disponible, podemos hacer la entrevista”, eso es un aviso. Debes colgar y luego llamar tú. En las reuniones, ten un tema claro, no llegues tarde. Después de aclarar los hechos, entonces puedes reclamar... etc.


Hay quienes aprenden el Dao antes y quienes después; en las artes, cada uno tiene su especialidad. Eso es todo.


El conocimiento es inagotable; siempre hay cosas que no sabes, cosas que no puedes hacer. Aunque lleves décadas como programador y te jactes de saberlo todo, con el apodo de “sabelotodo”, no es difícil que te dejen sin respuesta; hasta un niño en la escuela tiene conocimientos que tú ignoras. La industria del software se divide en muchos campos. Se dice que cada profesión es un mundo aparte, pero también hay brechas entre distintos campos, por ejemplo, desarrollo de clientes, backend, frontend, controladores, motores de juegos, gráficos e imágenes, seguridad, etc. Por lo tanto, debemos mantener una mente curiosa y una actitud humilde. Aunque seas un gran experto en frontend, cuando te enfrentes a problemas de controladores, eres un ignorante; debes aprender humildemente y pedir consejo a los demás.


Además, en las entrevistas, como entrevistador que tiene el poder de decidir la vida o la muerte, debes mostrar respeto hacia el candidato. No debes poner dificultades deliberadamente por razones no técnicas como el origen (no haber estudiado informática o tener un título de formación profesional), la experiencia (empresas pequeñas, empresas externalizadas), la experiencia en años (poca experiencia, proyectos sin brillo), o que no sea muy adecuado (necesitas a alguien de cliente, y la mayoría de su experiencia es frontend). Tampoco hacer la entrevista solo para cumplir con el jefe aunque claramente no lo quieres, ni menospreciar al candidato por otras razones (una vez encontré a una persona de una empresa extranjera que despreciaba a la gente de empresas nacionales, diciendo que en el país todo se copiaba de las extranjeras). Como dice el refrán: “Si dudas de alguien, no lo emplees; si lo empleas, no dudes”. Como entrevistador, puedes descartar a esa persona, es tu derecho, pero debes respetar a los demás, incluso si esa persona realmente no es muy capaz. Todos tienen momentos de humillación. ¿Son las empresas extranjeras tan increíbles? Las empresas extranjeras en China no son más que subcontratadas de la sede, haciendo trabajos menores. Motorola, qué tan increíble era en su tiempo, con buenos salarios y contratación exigente; ahora sus empleados se han dispersado como monos cuando cae el árbol. Como dice el refrán: “No presumas, tarde o temprano te caerá un rayo”.


Cómo poner fin a la mirada perdida y asentar el corazón impetuoso


Cada vez que estás confundido, es porque piensas demasiado en el futuro y haces demasiado poco en el presente. Cada vez que estás impetuoso, es porque esperas demasiado y logras muy poco. No importa cómo seas en el futuro o hacia dónde vayas, lo más importante es empezar desde ahora. No puedes soñar con volar directamente hasta allí; no hay helicóptero ni globo aerostático que despegue del suelo. Solo puedes empezar desde el presente, con los pies en la tierra, avanzando paso a paso.


Esto sigue siendo un poco vago y un poco “sopa de pollo” (autoayuda). A continuación, hablemos de cómo hacerlo concretamente:


  • Primero, aclara a qué te dedicas. Sí, eres un maldito escritor de código. ¿En qué capa escribes código? ¿Android? ¿Apple? ¿Aplicaciones? ¿Frameworks? ¿Controladores? ¿En qué área? ¿Gráficos e imágenes? ¿Webkit? ¿Redes? ¿Bluetooth? ¿Finanzas? ¿Seguridad? ¿Qué? ¿No escribes código, solo le das mantenimiento y resuelves bugs (hay bastantes personas, como las de soluciones integrales de Android, que solo mantienen y resuelven bugs)? Igual: ¿en qué capa, en qué área? Acláralo.
  • Luego, una vez que sepas qué es lo que haces, las cosas se vuelven fáciles: haz bien lo que debes hacer, conócelo a fondo, hasta lograr que te tome solo medio día terminar lo que debería hacerse en un día.
    Escribir código: hay que aprender a hacerlo bien y rápido, es decir, poder completar rápidamente los requisitos especificados y con pocos bugs. Yendo más allá, también incluye escribir código limpio, comprensible, con una estructura razonable, nombres fáciles de entender, etc. Esto es una práctica de habilidades básicas y siempre ha sido ignorada, porque en casi ninguna empresa los KPI tocan si el código es bueno o malo; como mucho miden la cantidad de bugs, la tasa de crashes, el rendimiento y la estabilidad. Esos son indicadores del software, no del código. La mejor manera de medir si el código es bueno o malo es ver la reacción de la persona que hereda tu código y contar cuántas veces te maldice. Para la práctica del código puedes leer libros como *Código completo* y *Código limpio*, pero lo más importante es leer buen código abierto.
  • Otra cosa es familiarizarse con el código existente, y procurar que, cuando llegue una nueva necesidad, sepas qué clases hay que modificar y dónde añadir código nuevo; cuando corrijas un bug, pienses un poco y ya sepas aproximadamente dónde está, qué clase o qué método causa el problema.
  • También está el conocer la lógica de negocio. Cualquier software se hace para implementar un negocio. Hay que familiarizarse con la lógica de negocio: primero la lógica del módulo pequeño del que eres responsable, y luego la lógica de negocio de todo el software. Esto es muy beneficioso para evaluar nuevos requisitos y resolver bugs, porque pensarás desde una perspectiva global. Hay algunos indicadores concretos: por ejemplo, puedes organizar los documentos de requisitos y, a partir de ellos, generar varios casos de prueba y escenarios, lo cual es de gran ayuda para verificar la corrección del código.
  • Después, hay que preparar y respaldar los entornos de prueba, los datos de prueba y los casos de prueba de uso común. Cuando haya nuevos requisitos y después de corregir bugs, también debes organizarlos y añadirlos a la base de pruebas, para facilitar las autopruebas y las regresiones. Aunque haya QA que garantice la calidad del software, nuestro software al menos tiene que poder funcionar y cumplir los requisitos antes de entregarlo a QA. En resumen, un programador profesional tiene que hacer suficientes pruebas por sí mismo. Y probar a veces no es tan cómodo. Por ejemplo, en el caso del cliente, algo frecuente es que los datos del backend aún no están listos y necesitas mockear datos; algunos datos solo aparecen en contados escenarios, así que también hay que mockear para probar; antes del lanzamiento hay que probar en el entorno de pruebas con un servidor de pruebas; etc. Lo que quiero decir es: si a menudo necesitas estas cosas, como datos simulados, proxies, etc., debes dedicarles atención, organizarlas y respaldarlas, e incluso buscar maneras (ya sea escribiendo código o usando bibliotecas de código abierto) de montar un entorno de pruebas cómodo de usar. Esto es muy útil para el desarrollo. Quizás recuerdes que un bug es fácil de corregir, pero difícil de verificar: hay que usar proxy, simular datos, escenarios especiales, ajustar el entorno de red, etc.
  • También hay que respaldar las configuraciones de entorno de uso común. Por ejemplo, tu código tiene diferentes personalizaciones para diferentes escenarios. En ese caso, lo mejor es hacer una copia de cada uno y configurar cada copia, en lugar de usar diferentes ramas, aunque también se pueda. Hay dos razones:
    Después de varios años en este oficio, sabemos bien que la configuración del entorno también es parte del desarrollo, y normalmente es muy molesta: hace que algo que parece de diez minutos se convierta en dos días sin haberse resuelto. El código actual es muy complejo; la complejidad está en que en sí no es complejo, pero las dependencias son especialmente complejas. Quienes suelen pelear con software de código abierto deberían saber que una biblioteca en sí puede no ser compleja, pero para usarla hay que instalar y configurar un montón de dependencias. Imagina que, sin usar un gestor de paquetes (como apt-get, brew, pip), intentas instalar OpenCV manualmente, o compilar directamente su código fuente.
    • Aunque las ramas de código pueden distinguir diferentes códigos, las configuraciones de dependencias del entorno a menudo no están en el repo, lo que significa que después de cambiarte de rama igual tienes que arreglar la configuración del entorno y lidiar con las dependencias.
    • Otra razón es el problema de lo paralelo. Supón que estás desarrollando una funcionalidad nueva en la rama de la versión A, y entonces la versión B (asumiendo que A y B son para clientes distintos y las dos ramas se diferencian) necesita corregir un bug. ¿Crees que es más cómodo cambiarte de rama, o ir a otro directorio a trabajar? Yo creo que es mejor esta separación física.
  • Si logras todo lo anterior, creo que las tareas que te corresponden ya no serán un problema. Entonces hay que pasar a un aprendizaje profundo y entender bien aquello de lo que dependes. Por ejemplo, si usas bibliotecas de red como OkHttp o Retrofit, ¿por qué son más cómodas que las nativas? ¿Cuál es su principio principal? ¿Cuál es su filosofía de encapsulamiento? También, bibliotecas de carga de imágenes como UIL, Picasso, etc., ¿cuál es su principio? Las bibliotecas subyacentes de las que dependen están especialmente bien encapsuladas y son muy cómodas de usar. Cuanto más así sea una biblioteca, si solo sabes cómo usarla, estás perdido. Porque incluso alguien que nunca la ha usado, con leer un tutorial unos minutos ya sabrá usarla. Solo entendiendo a fondo los detalles de implementación y aprendiendo los usos avanzados podrás no haber usado en vano estas excelentes bibliotecas.
  • Además, sin importar el campo o la capa, el ajuste de rendimiento es un símbolo de un experto. El trabajo de optimización de rendimiento de un proyecto normalmente lo hacen los expertos. Así que, si estudias y practicas la optimización de rendimiento, sin duda será un gran impulso para tus habilidades, y en las entrevistas será un gran punto a favor.
  • Por último, es ser dedicado y tratar el trabajo con seriedad: tratar con seriedad cada línea de código y cada bug. Aunque no te guste tu trabajo actual, aunque sientas que estás perdiendo el tiempo y la vida, corrigiendo bugs todos los días sin ninguna diversión, aun así debes tratarlo con seriedad y hacer bien el trabajo. Como dice el refrán: quien recibe dinero, elimina calamidades. Si cobras el sueldo de la empresa, tienes que hacer bien el trabajo. Que algún día encuentres algo mejor es otro asunto, es cosa del futuro; hoy estás aquí, y tienes que hacer bien lo que corresponde. Si eres muy impulsivo, ambicioso pero incompetente, y siempre andas chapuceando, ¿crees que podrás ascender? ¿El jefe te confiará cosas más importantes? Aunque el mundo es extraño y de verdad hay algunos que consiguen mejores sueldos o trabajos no por su habilidad, creo que en la mayoría de los casos es proporcional. Quienes tienen mejor trato que tú tienen razones legítimas. Si no estás convencido, entonces esfuérzate aún más; cuando algún día mejores de posición, demuestra a los demás: ¡yo soy más fuerte que todos ustedes!

Si puedes hacer los puntos sugeridos arriba y persistes un poco, en menos de medio año sin duda habrá un cambio cualitativo.


A la mierda la planificación profesional y los planes a largo plazo.


La planificación profesional es una cosa metodológica, todavía menos fiable que los malditos patrones de diseño. Los planes a largo plazo son aún más dañinos; los que superan un año, incluso los que superan seis meses, son tonterías. Ve y pregunta a esos grandes maestros: pocos tienen un maldito plan profesional o un plan a largo plazo claro. Su característica común es: son buenos profundizando, pueden devorar libros, pueden leer código, tienen un pensamiento ágil, sus ideas son claras y, al resolver problemas, su enfoque es más elegante que el tuyo.


¿Por qué digo que esto no sirve para nada? Porque en la vida real las cosas cambian demasiado rápido. Un proyecto puede dejarse de hacer después de unos meses; en cuanto al personal, hoy dimite Zhang San, mañana Li Si se cambia de puesto; antes de que termines, cambian los requisitos, o se cancela la actividad de operación porque el jefe no aprueba el presupuesto...


Pondré un ejemplo concreto de mi entorno: el año pasado llegó un becario al equipo, contratado como cliente Android. Cuando llegó, la primera semana le asignaron trabajo de Android. La segunda semana llegó un nuevo requisito grande que necesitaba H5 (Mobile HTML5), y el chico tuvo que ponerse con H5 (tuvo que aprender JavaScript desde cero). Más o menos a los tres meses, cambiaron las políticas de la empresa, no podían tener tantos becarios, y el chico tuvo que volver a la escuela. Si tú fueras ese chico, ni siquiera podrías cumplir un plan de estudio de un mes, porque no sabes qué pasará la semana que viene, ni siquiera mañana.


Para obtener un mejor entorno de crecimiento y aprendizaje, hay que ir a una gran empresa.


Ir a una gran empresa o a una pequeña puede incluirse como un tema inmortal a la altura de la disputa entre C y C++, la de GNOME y KDE, y la de Vim y Emacs. Yo creo que cuando estás al principio de tu carrera, por ejemplo recién graduado, o dentro de los dos o tres años después de graduarte, una gran empresa es sin duda una muy buena opción. Aquí, "gran empresa" incluye las de primer nivel nacional, como BAT, NetEase y otras conocidas, así como grandes empresas extranjeras como Intel, Microsoft, Facebook, Google, etc.


A continuación, las razones: la empresa nos contrata para trabajar, para crear valor, para ayudar a ganar dinero; no para que estudies, amplíes horizontes, te acerques a los expertos ni discutas problemas. Una gran empresa, porque es grande, tiene fuentes de ingresos estables y rentabilidad, por lo que su ritmo es regular y relativamente flexible. Sus proyectos o bien son maduros y estables, o bien no se hacen para obtener beneficios a corto plazo. Por eso, en la formación de talento tiene un plan. En otras palabras, puede tolerar que aprendas, e incluso que retrases un poco las tareas de trabajo (digo un poco), porque la empresa también espera que aprendas y mejores tus capacidades técnicas, y tiene espacio para aceptar a un mejor tú. Dicho claramente, tiene suficiente espacio para que mejores y asciendas, y también tiempo y paciencia para que completes ese proceso. ¿Una empresa pequeña puede tener ese espacio? ¿Puede permitir que digas: primero estudio unos meses? Puede que en unos meses, cuando termines de aprender y vuelvas, la empresa ya haya quebrado.


Además, en una gran empresa hay mucha gente: muchos buenos, muchos expertos, también hay malos, y bastantes impostores. Puedes conocer a más personas, puedes entender cómo opera una gran empresa, gracias a qué se hizo tan grande, y cómo mantiene su funcionamiento sin decaer. En una gran empresa puedes tener tiempo y espacio para aprender, ampliar tu visión y ampliar tus contactos. Esto es algo que una empresa pequeña no puede darte.


En una frase: cuando estás en el período de aprendizaje rápido de tu carrera, la gran empresa es la mejor opción; y cuando sientes que ya has aprendido algo, o te has topado con un nuevo cuello de botella, entonces la empresa pequeña es un buen lugar para desplegar todo tu talento. Así que, mira, la gente que sale de BAT, ya sea para emprender o para unirse a una iniciativa emprendedora, tiene un muy buen destino. Es un ganar-ganar. Para nosotros, en la empresa pequeña hay más espacio, menos gente y más tareas; es un gran escenario para ti. Y la empresa pequeña precisamente necesita este tipo de talento compuesto: uno que vale por diez, que es CTO y a la vez programador, que hace desarrollo y también operaciones.


La comunicación y la mantenibilidad del código dependen de si el autor piensa en los demás.


Si a una persona le importa pensar en los demás y sabe ponerse en su lugar, creo que su capacidad de comunicación no será mala; la legibilidad de su código tampoco será demasiado mala. Si no te preocupas por los demás, solo hablas por hablar y listo, por más que te comuniques, no habrá comunicación; si no piensas que otros tendrán que mantener tu código, ni siquiera piensas que tú mismo tendrás que leer el código que escribes ahora (mira, ni siquiera piensas en ti), entonces si ese código resulta mantenible, yo he vivido en vano.


Para resistir a los enemigos externos, primero hay que pacificar el interior.


Esa frase del Generalísimo tiene bastante nivel y profundidad, y también tiene valor orientativo. Mi entendimiento de esta frase es: desde lo pequeño, como individuos, equipos, departamentos, hasta lo grande, como empresas y países, no se pueden llevar a cabo dos o más asuntos importantes al mismo tiempo. Solo después de resolver uno puedes ocuparte de los demás. Es un poco difícil de entender; déjame explicarlo poco a poco.


Como dice el refrán: "panza llena, corazón contento" (cuando tienes comida y abrigo, piensas en deseos carnales). Cuando ni siquiera tienes asegurada la próxima comida, ¿en qué piensas en ligar? Cuando ni siquiera has dominado una tecnología, un lenguaje de programación o una plataforma, ¿en qué piensas en multiplataforma o en amplitud técnica? Todo son tonterías. Si cavas pozos por todos lados, pero no profundizas, al final nunca encontrarás agua en toda tu vida. Es como dice el dicho: diez veces 10% no equivale a un 100%.


Otro ejemplo: el equipo. Si cada lanzamiento de versión es un caos, ¿de qué sirve hablar de XP o de innovación tecnológica? Domina bien las tecnologías que el negocio necesita, entiéndelas a fondo, y primero haz bien tu trabajo, hazlo con soltura. Cuando puedas manejar cada lanzamiento de versión con facilidad, e incluso cuando el trabajo de 10 personas lo puedan hacer 5, entonces es el momento de innovar tecnológicamente, de hacer UT, XP, impulsar la tecnología, la cultura de ingeniería, etc.


A gran escala, las empresas: cuando ni siquiera tienen una cuota de mercado estable en su propio sector, imitan a otros en hacer "planes de expansión". Si otros hacen finanzas, tú también; si otros hacen autos, tú también; si otros hacen cine, tú también. Tarde o temprano esto te matará. Por ejemplo, el actual Jia Yueting: de los televisores, teléfonos y deportes de LeEco, ¿cuál tiene una cuota de mercado estable? ¿Cuál puede mantener a la familia? ¿Y en este momento vas a jugar a la expansión? ¿Hacer autos? Esto es "No zuo, no die". El maestro Ma es bueno en planificar, pero siempre después de monopolizar un área: cuando creó Taobao, fue porque B2B ya se había consolidado y podía mantener a la familia; en otras palabras, B2B ya estaba bastante maduro y ocupaba la mayor parte del mercado, generaba ingresos. Aunque Taobao fracasara y perdiera dinero, no era gran cosa. Luego creó Alibaba Cloud, y ahora el negocio de cine, Cainiao, la estrategia Doble H; todo esto requiere invertir dinero continuamente. ¿Por qué? Porque Taobao y Tmall pueden mantener a todo Alibaba; aunque estas apuestas pierdan, pueden permitírselo.


A gran escala, los países también son así. Cuando el pueblo aún no tiene suficiente para comer ni vestirse, ¿de qué sirve hablar de construcción de civilización espiritual o de innovación tecnológica? Por ejemplo, la China de los años 70 y 80, o el Sudeste Asiático de hace una década (los países más débiles, no los cuatro tigres asiáticos). Hablar de protección ambiental... Para los seres humanos, cuando se enfrentan a la disyuntiva entre la propia supervivencia y la protección del medio ambiente, solo pueden elegir lo primero. Por eso, cuando un país subdesarrollado avanza hacia convertirse en un país medianamente desarrollado, el desarrollo económico siempre es lo primero. El proceso de desarrollo humano es igual en todas partes: primero contaminar, buscar el desarrollo, y luego restaurar.


Dicho esto, creo que ya entiendes lo que quiero decir.


Aumentar la competitividad para incrementar el valor propio.


¿Qué es la competitividad? Creo que es cultivar especialmente la capacidad de resolver problemas que no se pueden resolver con un simple Google. En pocas palabras, es el sistema de conocimiento. Un problema que se resuelve con un Google siempre es un punto. Ya sea StackOverFlow o un blog, tratan de un punto concreto; no puede ser demasiado grande, porque si es grande, ¿cómo podría explicarse claramente en un solo artículo? Múltiples puntos, conectados entre sí, forman un sistema. Esto requiere múltiples búsquedas en Google durante mucho tiempo, junto con reflexión y resumen. Eso es la competitividad, y es donde reside el valor de los veteranos.


Mucha gente debate: ¿debería uno seguir escribiendo código después de los 30? ¿Y después de los 40? Es cierto que con la edad, el cuerpo y la energía decaen; ya no se puede trasnochar como cuando eras joven. Por eso, la situación del personal de primera línea de treinta y tantos es muy difícil. Los primeros años después de graduarse son un período de rápido crecimiento. Mientras estés dispuesto a estudiar con esfuerzo, tus habilidades técnicas e ingresos suben en línea recta. Pero para un programador de primera línea que se acerca a los 30, volver a subir el nivel de habilidad y el salario es bastante difícil. La familia, la vida y la salud no te dejan tanto tiempo para estudiar. En ese momento, lo que puedes hacer, lo pueden hacer también los recién graduados de dos o tres años; ellos tienen más energía y mejor salud, por eso muchos optan por pasar a gestión o cambiar de sector, y los restantes siempre están pensando en cuándo cambiar.


Creo que la razón más importante de esta situación incómoda es no haber seguido aprendiendo, no haber formado suficiente competitividad. Aunque no te conviertas en gerente ni en un gran experto (en la vida real es imposible que todos los mayores de 30 sean gerentes o grandes expertos), si sigues aprendiendo y mejoras continuamente tu competitividad, siempre aumentarás tu valor, aunque la empresa solo te dé un aumento general anual.


Salario: hay que calcularlo por tiempo unitario. Supongamos que el salario mensual es de 2150 yuanes; en realidad viene de 21,5 x 100. Si pides un día de permiso, te descuentan 100 yuanes. Además, 8 x 12,5 = 100, es decir, tu salario por hora es de 12,5 yuanes. Supongamos que dos personas tienen el mismo salario mensual de 2150, pero uno tiene más nivel y termina el trabajo de un día en 2 horas, y el trabajo de un mes en una semana; el otro necesita trabajar horas extra todos los días para terminarlo. ¿Quién tiene el salario más alto? Por supuesto, aquí hay muchas simplificaciones; la vida real es más compleja. Aunque todos tienen un período de rápido crecimiento, y las empresas también tienen una rápida expansión, al final se llega a la estabilidad; la llamada estabilidad es cuando te encuentras con un cuello de botella. Por ejemplo, en las grandes empresas como BAT, tomando a Alibaba como ejemplo, la gran mayoría de personas, después de ascender a P7, seguramente se detienen ahí; sin ser gerente, ascender a P8 es muy difícil, y cada vez será más difícil. Entonces, estas personas solo pueden recibir el aumento general anual. Para mejorar el nivel salarial, solo pueden aumentar su valor mejorando su eficiencia laboral.


Alguien podría decir: esto no es realista, las tareas no siempre se reparten por igual; a los "viejos zorros" les pueden asignar más trabajo. En realidad, el poder de decidir está en uno mismo. Si ya eres un "viejo zorro" y no ves esperanza de ascenso, ¿por qué trabajar de más? Esta es una era en la que "el trasero decide la cabeza", es decir, el salario decide la responsabilidad; el esfuerzo que pone el empleado depende del salario que le pagan. Diciéndolo claro: te pagan el sueldo de un recién graduado y esperan que hagas el trabajo de un arquitecto y asumas la responsabilidad de un CTO. Eso solo lo harías al inicio de tu carrera, cuando estás en la etapa de aprendizaje rápido y crecimiento; y una vez que sientes que has aprendido lo suficiente, te cambias a un puesto mejor de inmediato.


En resumen, solo aprendiendo y resumiendo continuamente, y cultivando mucha competitividad, puedes lograr que cuanto más mayor, más valioso seas.


Las cosas importantes no tienen que ser siempre lo primero.


Cuando hay varias cosas grandes que hacer, por ejemplo, una nueva función, varios bugs de la versión ya publicada, y el diseño de la solución técnica para la actividad de operaciones del próximo mes, cuando estas tres cosas están sobre la mesa, solo puedes elegir hacer primero la más importante. Aquí ciertamente hay que aplicar el principio de "lo importante primero".


Pero si además hay otras pequeñas cosas que hacer: por ejemplo, recargar el móvil, comprar algo en línea, actualizar un software, etc. Estas pequeñeces que se pueden resolver en 10 minutos es mejor hacerlas primero. Así tu mente queda despejada y no estarás pensando constantemente: "tengo que acordarme de recargar el móvil". Estas cosas pequeñas se olvidan fácilmente, por lo que el cerebro nos lo recuerda de forma subconsciente. Eso interrumpe el pensamiento normal de trabajo, afecta la concentración y, por tanto, la eficiencia en las cosas importantes. Además, si aplicas "lo importante primero", estas pequeñas cosas pueden quedar sin hacer hasta la noche y posponerse al día siguiente.


El principio para distinguir es: si una cosa pequeña se puede resolver en 10 minutos, hazla rápidamente. Debes entender que tu lista de tareas (ToDo) debe ser lo más corta posible. Aquellas cosas que requieren media jornada o un día completo, por supuesto, deben manejarse siguiendo el principio de "lo importante primero".


No te esfuerces en hacer horas extra para trabajar en el negocio, sino en hacer horas extra para estudiar.


En la industria del software, las horas extra son inevitables, especialmente en Internet. En la era actual de Internet móvil, el 996 es un fenómeno común. Quizá te sientas realizado, quizá sientas logros, quizá cansado. Pero trabajar horas extra todos los días como un buey en el negocio, al menos para el crecimiento personal, es lo más letal. Ahora es fin de año: mira hacia atrás, ¿qué has hecho este año? ¿En qué has crecido? Descubrirás que hiciste muchas cosas, pero creciste poco. Cuando encuentras algo que no sabes, buscas en Internet, haces copiar y pegar, y listo. Has hecho tanto trabajo de negocio, ¿eso te da sensación de logro? La sensación de logro de un programador proviene más del propio crecimiento, de poder hacer cosas que antes no podías, no de cargar ladrillos todos los días.


Por ejemplo, sabes construir casas, pero este año todo el tiempo has estado construyendo casas del mismo tamaño más o menos. ¿Cuánto puedes progresar? Cuando llegue un trabajo de construir un hermoso castillo, ¿podrás asumirlo? La empresa nos paga para que generemos valor; para la empresa, la casa es el valor. Mientras podamos producir más casas, justificamos el salario que nos pagan. El día que envejezcas, te enfermes y no puedas construir casas, inmediatamente buscarán a una persona más joven y fuerte para reemplazarte. Pero a la empresa no le importa cómo te conviertes en alguien que construye castillos.


Por eso, si sientes que estás cargando ladrillos todos los días, que llevas varios meses, incluso medio año, sin ningún progreso, sin aprender cosas nuevas, sin entender claramente los problemas que encuentras, entonces debes tener cuidado: reduce la velocidad de cargar ladrillos. Aunque tengas que renunciar a los KPI, detente a aprender, a resumir y pensar cómo hacerlo mejor. Por ejemplo, ciertos trabajos repetitivos, ¿no se pueden hacer con scripts, como empaquetar y publicar? Por ejemplo, ante los requisitos de producto y operaciones, hay que saber rechazarlos razonablemente. Por ejemplo, para las actividades operativas repetitivas, ¿no se pueden crear plantillas de configuración, etcétera?


Trabajar horas extra en el negocio todos los días no te hará progresar. Para progresar, solo hay que estudiar.


Aprende a trabajar de forma inteligente.


En un examen, ¿cuál es el mejor método? No es adivinar a ciegas, no es hacerlo tú mismo, sino copiar la respuesta correcta. Cuando te asignan una tarea, ¿cuál es la mejor manera? No es hacerla tú mismo, aunque ya la domines a la perfección, sino hacer que alguien más la haga por ti. La forma más fácil y que requiere menos esfuerzo es que la hagan otros. Hay muchas maneras de hacer algo; debemos elegir la forma de menor costo.


Aquí no quiero decir que todos sean oportunistas y deleguen en otros lo que deberían hacer ustedes mismos. Claro que si tienes la habilidad de delegarlo y el otro está dispuesto a aceptarlo, también vale. Lo que digo es que hay que ser inteligente al trabajar y no gastar energías en cosas que debería manejar otra persona. Por ejemplo, las dependencias de software actuales son bastante complejas; los problemas suelen manifestarse en la capa superior. Si descubres que la causa está en la capa inferior, no sigas investigando (excepto si tienes tiempo libre y es por estudio o investigación); deja que el responsable correspondiente lo revise. Él está más familiarizado con eso; quizás tú pases un día entero sin entenderlo, y esa persona lo resuelve de un vistazo.


Además, las molestas operaciones manuales y repetitivas deben automatizarse con scripts. La mayor ventaja de la computadora es que puede realizar tareas de manera repetitiva y sin cometer errores. Su gran fortaleza es la repetición; los humanos no somos tan buenos en tareas repetitivas y además cometemos errores, como errores de ortografía, etc. Muchas cosas, como empaquetar, publicar, etc., se pueden hacer con scripts.


Aprende a aprovechar las ventajas de ser programador.


El software ya no es algo misterioso e incomprensible que solo aparecía en los experimentos universitarios; se ha integrado en la vida de la gente. Hasta las personas mayores que bailan en la plaza usan teléfonos inteligentes, WeChat y Taobao. Creo que cada vez serán menos las personas que preguntan a los informáticos si saben arreglar computadoras. Esto significa que todos los días tratamos con software y no podemos vivir sin él. Si sabes escribir software, debes aprovechar tus propias ventajas. A continuación, pongo ejemplos:


  • Debes saber identificar los SMS de phishing y las llamadas fraudulentas. Si siendo programador caes en una estafa telefónica, solo se puede decir que este "mono" es un fracaso.
  • Con respecto a los distintos software, también debes poder identificar cuál es auténtico, cuál es una imitación o falso, cuál puede tener virus, cuál puede tener troyanos. Además, debes tener conciencia de seguridad. Hoy en día, la filtración de información personal a través de aplicaciones móviles y sitios web es muy grave; por eso, presta más atención al control de los permisos de las aplicaciones móviles, y regístrate en menos sitios web si puedes, etc. Además de cuidar tu propia seguridad de la información, debes recordar a las personas que te rodean.
  • Otro ejemplo: la forma en que la gente común obtiene información es visitando sitios web y usando motores de búsqueda; pero los programadores y programadoras, ¿no pueden usar rastreadores web (crawlers)?
  • Otro ejemplo: agarrar sobres rojos, conseguir entradas, compras flash (no vayas a agarrar pasteles de luna, jaja), inflar votos, inflar comentarios, etc. La gente común depende del esfuerzo humano, del trabajo manual y de publicar en WeChat Moments; nosotros, como programadores (猿媛), definitivamente tenemos que apoyarnos en la tecnología: escribir un script o un fragmento de código que nos ayude a completar estas tareas. Esta también es una ventaja que nos aporta nuestra profesión.

De: El cielo estrellado del vagabundo
Autor: alexhilton
Enlace: http://blog.csdn.net/hitlion2008/article/details/54089376