Una guía para desarrolladores para tratar el crecimiento, el agotamiento y el síndrome del impostor

Una guía para desarrolladores para tratar el crecimiento, el agotamiento y el síndrome del impostor

Este artículo fue publicado originalmente en .culto por Ryan Latta. .cult es una plataforma de medios para historias de desarrolladores no contadas, donde los desarrolladores pueden leer contenido en el lado más suave del desarrollo y ver documentales sobre la tecnología que aman. Puedes leer esta pieza original aquí.

Esos primeros días de un nuevo trabajo están llenos de emoción, nervios y sueños del futuro. A medida que finaliza la incorporación, quedan millones de preguntas sobre cómo comenzar a hacer un trabajo valioso. Este momento donde termina la incorporación y comienza el trabajo es a menudo un poco abrumador, y aún más para los desarrolladores al principio de su carrera. Esto es lo que puede experimentar y cómo manejarlo.

Síndrome de Imposter

¿Alguna vez sintió que era un fraude y que, tarde o temprano, todos lo descubrirían? Ese es el síndrome impostor. La gente siente esto a lo largo de sus carreras. Todavía lo siento después de una década. Para las personas nuevas en el campo, puede crear niveles increíbles de ansiedad y duda. ¡Ojalá fuéramos tan buenos como esos otros desarrolladores! Cuando te enfrentas a esos sentimientos, ¿qué haces? ¿Qué plan pones en acción para dejar de sentirte como un fraude? Resulta que sentirse como un impostor insta a los desarrolladores a sentir que tienen que ponerse al día.

Alcanzando

Casi todos los desarrolladores que he conocido, incluido yo mismo, sienten que necesitamos ponernos al día. Tenemos que aprender las tecnologías, la base del código, las normas sociales y un millón de otros detalles antes de que podamos ser productivos. Para empezar, no sabemos dónde buscar en la base de código. No sabemos qué diseño de sistema existe, por lo que no podemos comenzar a construir. ¿Cuáles son los estándares que debemos seguir? ¿Cuál es el proceso que utiliza el equipo para revisar el código y compartir código?

La forma en que la mayoría de los desarrolladores se ponen al día es básicamente la misma forma en que aprendieron a codificar. Este enfoque generalmente implica tratar de leer cada bit de documentación que existe. De repente están viendo tutoriales, leyendo documentación sobre Redux y documentos internos de Wiki. Intentan desesperadamente consumir todo el material que pueden. Creen que si conocen toda esta información, no estarán tan atrasados.

Excepto que realmente no funciona de esa manera. En algún momento, tienen que dejar de leer y comenzar a desarrollarse. A pesar de todo lo desconocido, deben escribir su primera línea de código. Escribir esa primera línea es cuando esa información se pone en práctica. No puedes leer tu forma de escribir código, tienes que escribirlo.

Quemar

La sensación de que eres un fraude te lleva a pensar que tienes que ponerte al día, y la presión de terminar los artículos de trabajo y mantenerte al día con tus compañeros significa que comienzas a trabajar las noches y los fines de semana. Tratando de leer todo el material que no pudieron mientras trabajaban. Entonces podrías hacer un proyecto paralelo para esforzarte aún más. Trabajarás hasta altas horas de la noche persiguiendo constantemente esa voz en tu cabeza, la que te dice que deberías ser mejor.

El agotamiento comienza a establecerse.

¿Cuánto tiempo puede alguien mantener este ritmo continuo mientras se siente constantemente inadecuado? Todos tenemos límites, y cuando esta es la forma en que trabajamos, no hay línea de meta. Siempre hay alguien que lo hace mejor y sabe más, al tiempo que hace que nuestros esfuerzos incansables parezcan fáciles. Nunca podemos seguir el ritmo, por lo que nos agotamos.

¿Cómo sabes que te estás quemando? Se muestra de manera diferente para todos, pero hay algunos signos clave a tener en cuenta:

  • Pérdida de apetito
  • Grandes fluctuaciones de peso
  • Mal genio
  • Sueño irregular
  • Pesadillas
  • Un sentimiento diario de desesperanza.
  • Aumento de las posibilidades de enfermedad.

Al principio de mi carrera, desarrollé una regla para mí. Cuando comencé a tener pesadillas sobre el trabajo, renuncié. Me di cuenta de que cuando tenía pesadillas sobre mi trabajo, algo se había salido de los rieles, y al quedarme solo prolongaría mi sufrimiento.

Debes prestar atención a lo que le está sucediendo a tu cuerpo y alma si experimentas el síndrome impostor. Piense en el agotamiento como la culminación de innumerables pequeñas heridas. Cada individuo parece tolerable, pero juntos pueden dañar su salud, su estado mental y su vida. Puede tomar años para que esas innumerables pequeñas heridas sanen.

¿Cómo lo manejan los demás?

Todas esas personas que crees que actúan juntas también se ocupan de esto. Van a nuevos trabajos, inician nuevos proyectos, también manejan nuevas tecnologías. ¿Cómo afrontan estos momentos de duda?

Es importante saber que todos nosotros enfrentamos el síndrome del impostor.

Los desarrolladores al principio de su carrera creen que carecen de información y conocimiento. Los desarrolladores senior entienden que nunca lo sabrán todo y aprovechan los procesos para potenciarlos en adelante.

Esa es la diferencia. Los primeros desarrolladores se centran en la información, y los desarrolladores principales se centran en el proceso.

¿Cómo se ve esto? Bueno, un desarrollador senior cuando encuentra una nueva base de código enfrenta el mismo problema que el junior. Necesitan entenderlo rápidamente para poder comenzar a hacer cambios. Un desarrollador más experimentado puede aplicar las siguientes técnicas:

  • Coincidencia de patrones de diseño / arquitectura existentes
  • Depuración para bisecar la funcionalidad
  • Ejecutando pruebas
  • Pidiendo ayuda

Ahora, algunas de estas cosas vienen con la práctica. Una diferencia sería que los desarrolladores senior tienden a cerrar su brecha de conocimiento con un proceso diferente.

Cada una de las técnicas enumeradas anteriormente es un enfoque práctico de la base de código. Este enfoque práctico es un marcado contraste con el intento de leer a través de las incógnitas. La coincidencia de patrones es una técnica que viene con la experiencia. Cuando se desarrolla, un desarrollador puede ver una nueva tecnología o una base de código y hacer inferencias muy precisas sobre cómo funciona en comparación con patrones similares que han visto en otros lugares. Esta técnica les permite centrarse en los elementos excepcionales en lugar de los comunes.

La depuración requiere iniciar la aplicación con la capacidad de interrumpirla en puntos clave de la base de código. Esta técnica les permite ver lo que está sucediendo en lugar de leer al respecto. La ejecución de pruebas proporciona un nivel de conocimiento muy similar al tiempo que comunica el comportamiento previsto. El último es el que llama la atención.

Pidiendo ayuda

Los desarrolladores más experimentados han aprendido a sentir cuándo están girando sus ruedas y no progresan mucho. También aprendieron desde el principio que no hay ninguna razón para luchar solo. Buscarán ayuda a los pocos minutos de encontrar una sorpresa. Alguien en la compañía tiene la respuesta.

Levantarse y preguntarles en comparación con revisar la documentación es más rápido, más efectivo y proporciona una retención de información más duradera. El desarrollador hace una pregunta sobre una parte del código hoy, y cuando vengan mañana, el contexto ya está allí. Esto significa que las respuestas se enriquecen y se hacen más apropiadas a medida que la conversación continúa.

Entonces, para todos los que sienten que tienen que ponerse al día, ¡pida ayuda! Cuando te quedes atascado, configura un temporizador para 5 minutos. Cuando se apaga, deja de luchar solo y ve a pedir ayuda. Alguien ya tiene la respuesta para ti. Esto te ahorrará días de lucha, te protegerá del agotamiento y te ayudará a moverte antes. Eventualmente, verá que todos estos modelos de productividad siguen siendo solo personas.

Publicado el 15 de julio de 2020 – 06:30 UTC

Deja un comentario