Casi tan común como la mayoría de las otras carreras técnicas (muy común, pero no solo para ingenieros de software). Hay varias fuentes de estrés en nuestro campo …
- Se avecinan los plazos. Rara vez hay tiempo suficiente para hacerlo “de la manera correcta”. Todo lo que a la administración le importa a corto plazo es que la funcionalidad requerida se envía a tiempo. En la mayoría de los casos, estos plazos se rigen por necesidades comerciales, independientemente de los obstáculos técnicos que el desarrollador debe superar. Usted sabe que un buen código lleva tiempo, pero su jefe solo lo mira de forma binaria: hecho a tiempo o no a tiempo. Esta es una de nuestras mayores fuentes de estrés: completar una tarea cuyo tiempo para completar correctamente no se puede determinar con anticipación, pero debe completarse en una fecha determinada. Los empleadores no nos emplean para desarrollar el código, nos emplean para producir milagros al mando. Si eso no es un gran estrés, no sé qué es.
- Gestión de “Dilbert”. Las posiciones más agradables que he tenido son en compañías donde la gerencia tenía conocimientos técnicos y tenía una comprensión real de lo que se necesita para que podamos hacer nuestro trabajo correctamente, y por otra parte, las posiciones menos agradables han sido donde la administración fue en gran medida “negocios orientado “y no pudo escribir una línea de código para salvar sus vidas, ni siquiera parece que realmente les importe … ¡Desarrollador! Solo produce resultados para mi, ayer !! Por lo general, termino dejando esos trabajos tan pronto como me doy cuenta de que mi administración no tiene ni idea técnica. Si no tomo medidas para conservar mi cordura, entonces mi gerente de Dilbert ciertamente no lo hará por mí.
- Tratar de explicar las dificultades del desarrollo a alguien que insiste en que “es un problema simple y directo, ¿por qué lo hace parecer tan difícil?”. Este tipo de idiotas piensan que si pueden imaginar que es fácil de hacer, entonces debe ser fácil de hacer, sin ningún conocimiento de los detalles finos a los que siempre debemos prestar atención y que generalmente son las cosas más difíciles de resolver. Al igual que no obtenemos “el panorama general”, y necesitan volver a explicárnoslo una y otra vez cuando sabemos muy bien “el panorama general” y sabemos que los problemas que nos encontramos no tienen nada que ver con ” El panorama general ”, pero con los detalles extremadamente finos de la programación. Simplemente no lo entienden, es como hablar con una pared y la pared sabe tan poco que piensan que eres un idiota o que estás ordeñando el proyecto, cuando el problema es su completa falta de habilidad para entender lo que realmente es. Toma para desarrollar código.