¿Por qué se espera que los programadores trabajen muchas horas? [cerrado]

No creo que esto sea específico de la industria del desarrollo, pero puede parecer que sucede mucho, pero tampoco todos los trabajos (de programación) son así.

¿Por que sucede?

La causa más común de esto es la falta de personal o la mala planificación. Hay prácticamente tres factores en el desarrollo: características, calidad, tiempo. Si fija el tiempo y la calidad, limita automáticamente las funciones que puede ofrecer. Algunos lugares quieren las tres características de buena calidad dentro de un plazo específico. Pero no quieren contratar más personal (principalmente por razones de dinero, pero a veces un nuevo desarrollador puede terminar ralentizando un proyecto), por lo que el equipo actual termina con más horas por persona.

Vinculado a esto está la expectativa de que un desarrollador codificará durante 7,5 horas al día si tiene un contrato de 7,5 horas. Esto no sucede. Los desarrolladores necesitan descansos para tomar café y para ir al baño, revisan correos electrónicos, asisten a reuniones. Por lo tanto, para realizar las 7,5 horas de tareas esperadas, necesitan 10 horas para hacerlo.

La gerencia debe tener en cuenta los imprevistos y planificar que solo algunas de esas 7,5 horas se dediquen a tareas de desarrollo (mi preferencia personal es planificar unas 5-6 horas "en la tarea" cada día).

Otra razón, y he visto que esto está más dentro de la industria del juego que en otros lugares, pero también se aplica en general, los desarrolladores se están poniendo al día por holgazanear al principio del proyecto (o incluso el día). De acuerdo, no del todo holgazaneando... Pero muchos planes de proyectos de la gerencia no dan cuenta fácilmente de la investigación y el descubrimiento. Escuché historias de estudios de desarrollo de juegos donde probarían todo tipo de ideas y programas extraños y extravagantes como investigación durante el primer año o dos en un plan de dos o tres años... Luego se darían cuenta de que tienen que entregar un producto. , y luego pasar un año haciendo todo el trabajo que no hicieron el año anterior. Esto puede pasar en el día, donde terminan poniéndose al día por hacer un desarrollo no productivo en la mañana.

¿Es común?

Como dije, esta práctica no es universal. Tenemos una semana laboral mínima de 37,5 horas, y casi todos pasan menos de 40 horas en el trabajo, la mayoría de las semanas. Después de algunos cambios en la planificación del proyecto, solo hubo dos quincenas separadas en las que se solicitaron horas extra en casi tres años. Tampoco hemos perdido una fecha límite.

Hay muchos otros lugares para trabajar, y cada uno tiene una cultura diferente. Si no le gustan las horas excesivas, debería poder encontrar un lugar de trabajo que ofrezca horas de trabajo más estables.

Las horas trabajadas son irrelevantes para su empleador. Lo que importa es la productividad. Estos muchachos pueden estar trabajando hasta tarde para hacer más, o trabajando hasta tarde para hacer lo suficiente.

En igualdad de condiciones, si logran más, son mejores empleados, por ahora... suponiendo que puedan mantener ese ritmo sin agotarse. Trabajar de manera más inteligente es mejor que trabajar más duro, pero con el tiempo suficiente puedes clavar un clavo con un destornillador. Por supuesto, el destornillador se va a golpear bastante en el proceso; es posible que no desee adoptar ese enfoque.

Si trabajan más tiempo y no producen resultados de mayor calidad, eso es un punto a su favor; tienes más capacidad de reserva.

El hecho de que otra persona pueda ser más productiva no debería, por sí solo, asustarte. Siempre habrá personas que pueden codificar anillos a tu alrededor y personas que luchan por mantenerse al día contigo. Concéntrese en desarrollar sus propias habilidades para ser el mejor empleado que pueda ser, lo que incluye ayudar a otros a tener éxito. Esos no son competidores, son recursos que pueden ayudarlo a hacer mejor su trabajo... y posiblemente personas que podrían aprender algunas cosas de usted, lo que también cuenta para su valor como empleado.

Como hemos dicho en otras respuestas, este es un juego de suma positiva. Trabajar con personas te llevará más lejos y más rápido que trabajar contra ellas.

Conclusión: se le paga por un número específico de horas. Necesitas trabajar esas horas. Depende de usted donar tiempo adicional a la empresa. No tienes que ser el tipo que está casado con su teclado para ser un miembro valioso de la comunidad, pero si quieres ir por ese camino y realmente puedes mantener el ritmo más alto, esa es una forma de alcanzar "supera con creces las expectativas". No es la única manera, ni la mejor manera para la mayoría de las personas, y un simple "excede" puede ser suficiente si no tiene el corazón puesto en ser vicepresidente a los 30 años.

Tiene una cantidad determinada de trabajo que debe realizarse antes de una fecha límite y una cantidad determinada de personal que realiza el trabajo. Puede verlo de esta manera para cualquier número de proyectos. Entonces, tome la cantidad de trabajo y divídala por la cantidad de personas que realizan el trabajo: ¿se puede hacer si todos trabajan 40 horas a la semana? La forma en que las personas manejan su tiempo dependerá en gran medida de una serie de factores, pero el trabajo: el personal frente a la fecha límite es un principio subyacente.

Por ejemplo: para algunos trabajos, trabajar más duro durante el mismo turno no produce el mismo efecto que trabajar más horas, y para otros, es deseable llevarse el trabajo a casa en lugar de agotarse terriblemente durante un turno largo.

Creo que gran parte de esto se remonta a los primeros días de horas sin sentido de asignación de memoria, compilaciones largas y mensajes de error ambiguos. Y también empuja de un lanzamiento de versión.

Con las mejores herramientas de hoy los programadores son mucho más eficientes y tienen menos tiempo muerto. La norma parece estar pasando a una semana laboral más normal.

En algo como los juegos, la norma es 60+ y probablemente continuará.

Mi experiencia con el desarrollo de software es que es una combinación de cosas:

No hay suficientes recursos asignados a un trabajo, combinado con una mala planificación.

Hay una broma que dice que los desarrolladores siempre agregan un 50 % al tiempo que realmente van a tomar para hacer algo en una cotización, y luego sus PM agregan otro 50 % además de eso. Esto no es totalmente falso y tampoco siempre es una mala idea. Un trabajo que cree que le tomará 4 horas puede, de hecho, tomarle un par de días una vez que solucione los errores imprevistos, lidie con las complicaciones que traen los nuevos requisitos (y me encanta Agile, pero eso es algo que sucede con él), pruebas unitarias, pruebas de control de calidad, revisión de código, etc.

La única forma de solucionarlo es planificar con suficiente antelación, y nadie quiere parecer el desarrollador lento del grupo.

Preparándote para el fracaso

Como contratista, una de las cosas que me gustan de aceptar nuevos trabajos es el cambio de ritmo y, a menudo, los problemas enormes y enormes que me trajeron para solucionar. Es perfectamente natural trabajar más para solucionar esos problemas evidentes y, además, debo decir que al principio es muy divertido lidiar con problemas completamente nuevos. Eso, creo, hace que mucha gente trabaje mucho tiempo extra, pagado o no, al comienzo de un concierto.

Donde esa idea falla es que a veces, especialmente si no tiene muy claro el hecho de que está trabajando más tiempo para cumplir con los plazos, etc., los que no son programadores en su equipo, especialmente los BA y las partes interesadas, obtienen una falsa idea de cuánto se puede producir en una semana. Eso hace que sea más difícil reducir la escala 3 meses después, ya que luego tiene que discutir por qué ha disminuido su productividad.

La constante marcha de la muerte

Una cosa que también he visto bastante es que un equipo está en modo de crisis constante. Está bien trabajar un par de 50 o 60 horas a la semana para cumplir con una fecha límite en particular, o si hay un error importante que debes eliminar ahora mismo, pero he estado en lugares donde la gerencia parece arreglar las cosas para que siempre haya un crisis inminente a la vuelta de la esquina por... razones. Algunas personas piensan que esto hace que las personas sean más productivas (no estoy de acuerdo, pero esa es la idea de todos modos), a veces estás llegando a un punto negativo porque el equipo anterior dedicó un año a hacer algo que debería haberles llevado seis meses, y así sucesivamente. .

Es difícil encontrar una buena solución para este problema, ya que tiende a no provenir de los desarrolladores sino de la administración. Todo lo que puedo decir a esto es, asegúrese de mantenerse en comunicación constante con dicha gerencia para que al menos entiendan la cantidad de estrés que le están poniendo a usted y a su equipo.

fluencia del alcance

Como se señaló, disfruto Agile, y una de las cosas que más disfruto es la comunicación semanal o quincenal constante que puede tener con las personas que van a usar su producto. Muestras lo que agregaste, te hablan sobre cómo difiere de lo que querían, haces esos cambios y los muestras en el próximo sprint, etc. Creo que evita perfectamente el gran problema de Waterfall, que es que puedes pasar meses trabajando en algo solo para terminar con un producto final que está completamente mal.

Dicho esto, Agile se presta muy bien a las personas que presentan nuevas ideas en esas reuniones de planificación/demostración, y una vez más es difícil ser ese tipo que dice "eso no está en la documentación. Podemos agregarlo pero agregará X semanas al proyecto". Pero alguien tiene que ser ese tipo si quieres evitar el aumento del alcance que posiblemente conduzca a la Marcha de la Muerte Constante.

Es solo la forma en que trabajamos

Creo que este es realmente el menos importante del grupo, pero muchas veces, si se me presenta un problema, simplemente me siento y trabajo en él hasta que se resuelva. Si eso requiere un par de días de 14 horas, entonces requiere un par de días de 14 horas. Y si no puedo salir temprano en algún momento durante el resto de la semana, tal vez termine con 50 horas o más.

Este no es un trabajo de oficina normal en el que ingresa a las 9 a.m., almuerza durante 1 hora y sale a las 6. He notado que los no programadores tienden a ser un poco menos conscientes de esto cuando ven a un desarrollador tomando a las 2 de la tarde de un miércoles (no ven, por supuesto, que llegaste a las 5 de la mañana porque hubo un problema que no pudiste resolver hasta que lo resolviste), pero el punto general permanece: este es un trabajo en el que al final del día no eres juzgado por las horas que trabajas sino por las cosas que entregas.

Inauguración

No siempre tendrá que trabajar 70 horas a la semana en una empresa nueva, pero tenga en cuenta que para una empresa pequeña que recién está comenzando, no solo está trabajando por un cheque de pago, está trabajando para mantener su empresa en los negocios. Lo siento, pero a veces simplemente no puedes evitar esto. Si desea mantenerse alrededor de la marca de las 40 horas, busque una empresa Fortune 500 para trabajar.

Los programadores son autores.

Si un autor estuviera escribiendo un libro, bueno, sería realmente extraño que alguien más se hiciera cargo de la mitad del párrafo y se lo pasara a otro autor.

Hay algunas tiendas donde los programadores escriben todo el libro y otras donde se encargan de sus propios capítulos.

Sin embargo, si eres bueno, preferirían que alguien trabaje 15 horas escribiendo bien que tener 8 horas de buena escritura y 7 de galimatías.

Si quiere trabajar menos horas como programador, vaya a una tienda ágil, vaya a una empresa con muchos programadores (mejores que usted), vaya a una empresa con una línea de productos madura o sea mucho más rápido.