Como desarrollador de software, ¿cómo debo mantenerme fuerte y seguro cuando alguien dice que mis habilidades técnicas son malas?

Supongo que eres bastante nuevo en el desarrollo de software o tal vez estás en una depresión de mitad de carrera. Todos nosotros hemos estado en la primera situación y muchos de nosotros hemos pasado o también pasaremos por la segunda.

Si las habilidades técnicas a las que se refiere esta persona son críticas para su situación laboral, entonces debe realizar un esfuerzo adicional necesario para mejorar rápidamente.

Esto puede significar trabajar de 10 a 20 horas adicionales por semana durante unos meses. Considere esta parte de “pagar sus cuotas”. Casi cualquier persona en este negocio tiene que hacer esto varias veces en su carrera. Todos tenemos que seguir aprendiendo y las habilidades técnicas de nadie son perfectas para cada situación cuando se toman en cuenta períodos de tiempo más largos.

He estado en el desarrollo de software durante mucho tiempo, pero sigo estudiando los fundamentos de las matemáticas discretas y de otro tipo, así como la informática, las arquitecturas de máquinas, etc. Esto es parte de permanecer en la cima de mi juego , ya sea o no. Veo resultados directos o inmediatos del estudio.

Depende de quién lo dijo.

¿Es tu crítico un mal desarrollador? En caso afirmativo, dígalo a la cara y aléjese . Pero intente entender por qué su crítico lo dijo.

¿Es tu crítico un buen desarrollador pero arrogante? Simplemente aléjate . Algunas batallas no se pueden ganar. Pero intente entender por qué su crítico lo dijo.

¿Tu crítico es bueno pero no arrogante? Luego pregúntele cómo puede mejorar. Intenta entender por qué lo dijo tu crítico. Aprende de él / ella. ¡Y luego aléjate!


¡Haz eso y te llamaré fuerte y confiado!

Solo recuérdese que si quien dice que no puede proporcionarle una crítica detallada y útil de su trabajo, probablemente no sea un juez confiable de sus habilidades. Si pueden, entonces te dieron las claves para ser mejor de lo que eras, así que escucha atentamente y mejora.

Convertirse en experto en una profesión compleja como el desarrollo de software es un largo viaje, y muchas cosas son altamente subjetivas. No importa cuánto avance en su carrera, es probable que recuerde su código de hace uno o dos años y piense: “Eso podría ser mejor”. Vale la pena confiar, pero también ser crítico con su código propio trabajo. Las buenas críticas externas te ayudarán en esto en cualquier momento de tu carrera.

A la gente le encanta hacer declaraciones negativas radicales porque aviva sus propios egos, pero soy muy escéptico con respecto a cualquiera que no pueda ser específico.

Un tema común en Internet es atacar al Nodo JS debido a las muchas fallas, tanto percibidas como reales, integradas en el lenguaje Javascript, y sin embargo, el Nodo JS sigue siendo la plataforma de más rápido crecimiento y se debe considerar altamente exitoso. A los empollones les encanta criticar.

Solo recuerda: “Para evitar las críticas, no digas nada, no hagas nada, no seas nada”.

Depende de quién lo diga.

Primero, ¿tus habilidades técnicas son malas o no? Si no crees que faltan tus habilidades en un área u otra, podrías tener el efecto Dunning / Kruger. En la vida real, las personas generalmente no son buenas en todo, por lo que pensar que eres bueno en todo puede ser una señal de que no te estás evaluando muy bien.

A continuación, ¿qué están diciendo realmente? ¿Están diciendo que te estás perdiendo un conjunto particular de habilidades, o que tus habilidades técnicas en general son malas? Si ha aprobado la evaluación D / K anterior, debe pensar: ¿es correcta esta persona?

Si lo son, entonces mejora esas habilidades si te interesan las habilidades o simplemente dices “No hago eso”. Como ejemplo, soy terrible en el control de calidad. He mejorado, pero hay tanto esfuerzo que voy a gastar en la mejora de las habilidades de control de calidad. También soy un asco en la gestión de PBX, la gestión de CMTS, Cisco iOS y mil cosas más. Si tuviera algo de calor por esos, diría “sí, tienes razón”.

La confianza no siempre es algo bueno. A menudo está fuera de lugar y conduce a errores costosos.

Una vez vi a un presentador que dijo: “Hay dos tipos de personas: las que han jodido la producción y las que están a punto de hacerlo”. Estaba hablando de personas que tienen una confianza injustificada en cosas que aún no saben. No entienden completamente.

Por supuesto, la duda flotante es inútil. Si alguien dice que tus habilidades técnicas son malas, eso no es algo sobre lo que puedas hacer nada, y esa persona no está siendo útil. “Solo necesita trabajar más duro” es la peor forma de retroalimentación administrativa posible.

Por otro lado, si alguien dice “realmente no sabes cómo hacer X de manera efectiva”, eso es al menos algo que puedes solucionar mejorando en X.

Entonces, lo que pasa con el software es que podrías seguir intentando para siempre aprender todo lo que no arañarás la superficie, incluso después de varios años de trabajar en él. Tengo unos 15 años y todavía estoy aprendiendo. Si a la persona no le gustas y dijo eso, simplemente ignórala, si no pueden tener una conversación constructiva sobre cómo mejorar tus habilidades, probablemente no tengan nada útil que decir. Sin embargo, si yo fuera el desarrollador principal en ese caso y alguien entrara con muy poca experiencia en lugar de insultarte, te entrenaría o te diría que tomes una clase nocturna o algo así, para que podamos estar en la misma página.

Una vez fui a una entrevista y no estaba en la parte superior de mi formulario. En la parte de codificación de la entrevista (estábamos haciendo programación por pares), me dijeron que no conocía la programación básica, porque mi técnica e ideas no eran las mismas que las del entrevistador. Le expliqué que había estado programando desde antes de que él fuera un brillo en los ojos de su padre, y que realmente no quería trabajar para alguien como él.

También tuve un amigo que fue a una entrevista y lo interrogaron sobre los detalles de Hibernate 4.0. Decía claramente en su currículum que todavía no había trabajado con Hibernate. Pero definitivamente podría aprenderlo. El entrevistador solo estaba tratando de mostrar cuánto sabía (que es una bandera roja que muestra que realmente no sabía mucho).

Practique la programación todos los días (por práctica, busque Katas de codificación y hágalas).

Constantemente aprende más. Adquiera nuevas habilidades y siempre esté abierto a aprender más.

En primer lugar, verifique si tiene razón, si es así, considere un cambio de carrera. Si no lo está, no hay razón para que su confianza esté en peligro.