5 cosas que odio de ser desarrollador



Este artículo fue publicado originalmente en .culto por patricio zawadzki. .cult es una plataforma comunitaria para desarrolladores con sede en Berlín. Escribimos sobre todo lo relacionado con la carrera, hacemos documentales originales y compartimos montones de otras historias no contadas de desarrolladores de todo el mundo.

El desarrollo de software como carrera se ha disparado en los últimos años. Y con la popularidad de los campos de entrenamiento y los movimientos laterales, es un buen momento para involucrarse.

Sin embargo, detrás de toda la pelusa y el dinamismo de Ingeniería de software, hay un lado que no es tan glamoroso. Y si eres como yo, probablemente quieras saber la sucia verdad antes de dedicar tiempo, energía y dinero.

Con cualquier trabajo, hay días buenos y días malos. Me gusta decir que si disfrutas de tu trabajo al menos el 70% del tiempo, tienes un gran trabajo. Personalmente, me encanta el desarrollo; No podría estar más feliz, pero eso no debería impedirme abordar el otro 30 %… esos días malos, esos problemas recurrentes, esos momentos en los que el puño atraviesa la pared.

Puede haber muchos problemas con cualquier trabajo a lo largo del tiempo, pero con el desarrollo, hay algunos recurrentes que siempre parecen aparecer en algún momento de mi carrera. Así que hablemos de las cinco peores cosas de ser un desarrollador (sin ningún orden en particular).

1. Problemas de depuración en una base de código sobre la que no tiene control directo

Los errores no son algo que la gente quiera encontrar. Es genial cuando lo haces, pero un error en última instancia significa que en algún momento se omitió un paso o se malinterpretó un proceso. En el contexto de esos tipos de errores, son el mejor subconjunto de todos los errores porque al menos podemos controlarlos. Los podemos encontrar en el código base y arreglarlos. Pero, ¿qué pasa con los errores importados de una biblioteca o los errores importados de un proveedor externo?

Podría decirse que la depuración de problemas a los que no puede acceder fácilmente es una de las partes más desafiantes y frustrantes de ser un desarrollador. Tal vez sea una biblioteca que importó, pero la biblioteca se minimizó o compiló, por lo que es ilegible para el ojo humano. Afortunadamente, esta biblioteca es de código abierto… ¿verdad? No siempre, y eso es lo peor de lo peor en esta categoría. Ahora debe dedicar más tiempo a aislar el problema, en un sistema externo, de manera reproducible para poder enviar este problema a los propietarios de dicha biblioteca, con la esperanza de que puedan solucionarlo en el horario que necesita.

Estos son desafíos que enfrentan muchos equipos a diario y, en última instancia, no se pueden evitar. Puede mitigar este tipo de preocupaciones optando por soluciones de código abierto o de cosecha propia al elegir su base de código. Pero si no hay opciones, estás acorralado y tienes que morder la bala.

2. Mantener un proyecto antiguo, sin ningún conocimiento contextual

Imagínese esto, usted es un sobreviviente entrenado y experimentado que decide unirse a un programa de televisión algo así como Solo con algunos giros. Ha hecho este tipo de cosas durante miles de horas, es un experto en lo que hace y tiene un historial comprobado de éxito. Aquí está el giro, esta temporada, te recogen al azar y te dejan en un área completamente desconocida para ti.

Para ser un sobreviviente exitoso, necesita saber adónde va, cómo es allí y tal vez incluso algunos métodos para tener éxito. Necesita saber por qué va a traer ciertos artículos, cómo podrían ser útiles, y tal vez incluso hablar con algunos compañeros de supervivencia que han estado en un entorno como este antes. Lo que funcionó, lo que no funcionó y tal vez algunos trucos del oficio que son únicos en este entorno. Pero no, esta temporada de “Alone+” pondrá a prueba tus habilidades al máximo.

Ser un desarrollador de software metido en un nuevo proyecto, sin ningún contexto o sin nadie a quien puedas hacerle preguntas es bastante similar a esto. Lo que pasa con el software es que hay una multitud de formas de abordar un solo problema y, a veces, el camino de las decisiones que alguien tomó para elegir su enfoque fue sistemático y profundamente debatido.

Estar en un proyecto sin ningún contexto o personas a las que pueda hacer preguntas significa que puede encontrar cosas extrañas y luchar para entender por qué están allí. ¿Fue un desarrollador siendo perezoso? ¿Fue una solución alternativa o un truco que necesitaban hacer para cumplir con una fecha límite? ¿Se debió a alguna restricción exterior que obliga a diseñar el código de esta manera? Es imposible saberlo, simplemente está perdido en el vacío. El giro de todo esto es que aún necesita aprender cómo tener éxito en este entorno, ya que su propio éxito como desarrollador depende de ello.

Desafortunadamente, este tipo de proyectos pueden llevar a muchos desarrolladores al extremo de su ingenio y hacer que algunas personas odien su trabajo. Estos proyectos tardan en comenzar y parecen tratar de navegar a ciegas en un campo minado. Por eso es tan importante un código bien escrito y un código con documentación actualizada.

Si estás leyendo esto, probablemente seas un desarrollador o quieras convertirte en uno. Trate de ser el que tome nota de estas rarezas en su base de código para que la próxima persona que interactúe con él tenga más facilidad para reconstruir las cosas, ya sea que esté allí para responder preguntas o no.

3. Cuando las personas que NO entienden el desarrollo de software toman las decisiones

Una composición típica de un equipo en el mundo del software son los desarrolladores de software, un gerente de proyecto y algún tipo de propietario del producto. Tal vez el gerente del proyecto y el propietario del producto sean las mismas personas, pero en última instancia, hay alguien que escribe el código y alguien con una visión de lo que quieren que sea el producto. En la mayoría de los escenarios, la persona con la visión es la persona que lleva a cabo las reuniones con las partes interesadas, establece los plazos y, en última instancia, «vende» el producto a los demás.

La relación entre este tipo de individuo y el desarrollador es bastante crucial para el éxito de un proyecto y, a veces, para la alegría del desarrollador en un equipo. Con demasiada frecuencia, los desarrolladores son vistos como «monos del código» en los proyectos y los requisitos simplemente se les imponen sin mucha discusión de ida y vuelta y, a veces, con plazos poco realistas. Esto conduce a productos apresurados, expectativas no cumplidas y, en última instancia, a un producto fallido porque no hace lo que la empresa tenía en mente y se rompe constantemente.

Como programador, encontrar un equipo que tenga una relación equilibrada y de trabajo entre los gerentes de proyecto y los propietarios de productos es importante no solo para el éxito de un producto, sino también para la alegría del programador en su rol.

4. No tener suficiente tiempo ininterrumpido en tu día

Hay muchas tareas excelentes que abarcan el rol del desarrollador, y la mayoría de los desarrolladores tienden a apreciar estas partes de su trabajo diario. La capacidad de crear rápidamente una visión y convertirla en realidad en cuestión de minutos es una de las partes más adictivas de ser programador.

Otra parte realmente sorprendente solo puede describirse como «el flujo». Es la sensación de inmersión casi completa que uno experimenta al profundizar en su trabajo y proceso de pensamiento. Es una parte muy común de entrar en un lugar de gran productividad y progreso y una parte de la programación que muchos desarrolladores necesitan para ser efectivos.

Sin embargo, en el mundo laboral moderno, es fácil que lo agreguen constantemente a las reuniones o que le envíen mensajes asincrónicamente con preguntas/inquietudes a lo largo del día. Lo inconstante de «el flujo» es que puede ser difícil entrar, pero es fácil sacarlo.

Además, el desarrollo de software es un tipo de trabajo altamente individualista, en el sentido de que usted es un colaborador individual al que se le asignan tareas y problemas y se espera que los complete. Con una comunicación asíncrona constante y reuniones consecutivas, puede ser un desafío encontrar el tiempo suficiente para entrar en el flujo y permanecer en el flujo el tiempo suficiente para completar las tareas en cuestión. La clave aquí es un período «ininterrumpido» de su día, porque incluso cambio de contexto encajar en pequeñas tareas a lo largo del día es demasiado agotador.

Encontrar un espacio de tiempo ininterrumpido, tal vez 3-4 horas idealmente donde pueda entrar completamente en su zona y concentrarse en su trabajo es increíblemente importante. Los días repletos de reuniones o, lo que es peor, las reuniones con una diferencia de entre 30 y 45 minutos son perjudiciales para la productividad y la eficacia de muchos desarrolladores en todo el mundo.

5. Síndrome del impostor

Para muchos programadores de todo el mundo, es desafortunado decir que tarde o temprano experimentarán algún nivel de síndrome del impostor durante sus carreras. Tal vez sea comenzar un nuevo proyecto, unirse a un nuevo equipo o simplemente una mezcla repentina de malas emociones en un día que hace que las dudas se infiltren en sus decisiones y afecten las elecciones que haga a lo largo del día.

Según Merriam Webster, el síndrome del impostor se define como:

… una condición psicológica que se caracteriza por la duda persistente sobre las habilidades o los logros de uno, acompañada por el temor de ser expuesto como un fraude a pesar de la evidencia del éxito continuo de uno.

Es un escenario bastante contraproducente y contradictorio que muchos luchan por sacudirse. Algunas personas lo experimentan a menudo y otras nunca. Algunas personas lo experimentan con más frecuencia de lo que esperarían. De cualquier manera, lo mejor de la comunidad de software es que muchos la han experimentado hasta cierto punto en algún momento de su carrera y muchas personas están dispuestas a ayudar.

Resumen

La ingeniería de software es un gran campo con muchos beneficios para muchas personas y es un campo interesante en el que estar con oportunidades aparentemente infinitas. Sin embargo, cada campo y carrera tiene sus pros y sus contras. La mayoría de las veces la gente solo habla de los pros de una carrera, pero rara vez de los contras, seamos honestos, a veces los contras pueden superar a los pros. Y las desventajas para algunas personas pueden no serlo para otras.

Independientemente de su situación, espero que ver algunos de los aspectos negativos de un desarrollador de software pueda ayudar a brindar una perspectiva a cualquiera que esté pensando en unirse al campo y a cualquiera que recién ingrese al campo. Esto no pretende asustar a nadie, sino más bien una pequeña luz que brilla en los rincones oscuros que no se comparten con frecuencia. Después de todo, estar al tanto de los problemas y las cosas que pueden afectarlo a menudo es mejor que no estar al tanto.



Fuente: TNW

Compartir:

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para fines de afiliación y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Ver Política de cookies
Privacidad