Cuando entré a la fiesta, el discurso ya había comenzado. Michael Arrington estaba hablando extensamente sobre las dificultades de crear una empresa: muchas veces incluso solo se puede tomar una siesta sobre el escritorio. Pero quiero añadir algunas palabras. He visto muchos argumentos que dicen que esta forma de trabajar puede resultar contraproducente, hacer perder el éxito, e incluso causar graves daños a la salud de los programadores. Sin embargo, pocos hacen un análisis cuantitativo de esto. Aunque carezco de talento, a continuación daré mi humilde opinión para iniciar este tema.

Generalmente trabajamos 8 horas al día, es decir, 40 horas a la semana. En condiciones extremas (por supuesto, poco realistas), si un programador pasara una semana entera sin comer, beber ni dormir y dedicara todo ese tiempo a escribir código, serían 24×7 horas, que multiplicadas dan 168 horas, es decir, 4 veces lo normal.

Por supuesto, los seres humanos no son máquinas; es imposible trabajar las 24 horas completas. Los programadores también son personas y tienen necesidades fisiológicas normales: por ejemplo, dormir. El tiempo óptimo de sueño es de 7 a 8 horas. Quizás aguantar uno o dos días con menos sueño sea posible, pero después normalmente se necesita recuperar el sueño durmiendo más. Además, durante ese período, la eficiencia laboral suele ser muy baja. Para trabajar mejor, supongamos 7.5 horas de sueño al día; en 7 días serían 52.5 horas. Entonces, tras restar las 52.5 horas de sueño de las 168 horas, ¡quedan 115.5 horas!

Luego está comer. Comer también es indispensable: primero hay que tener comida (pedirla o cocinarla uno mismo), y luego poder llevarla al estómago. Tres comidas al día, suponiendo que cada comida necesita 30 minutos, son 90 minutos al día. Si se pide comida rápida como pizza, el tiempo por cada comida puede reducirse a 15 minutos, y al día se reduce a 45 minutos. Incluso si se necesita 60 minutos al día, es decir 1 hora para comer. Entonces 115.5-1*7=108.5 horas. Además, cepillarse los dientes, lavarse la cara, afeitarse, a veces bañarse, todo esto requiere al menos 30 minutos =>108.5-0.5*7=105 horas. También está el tiempo desperdiciado en el trayecto de ida y vuelta al trabajo. En 2007, el promedio nacional de desplazamiento fue de 45 minutos por trayecto de ida y vuelta, es decir, 5.25 horas a la semana =>105-5.25=99.75 horas, podemos decir 100 horas. Por supuesto, si quieres ahorrar ese tiempo, ¡siempre puedes dormir sobre el escritorio!

100 horas es solo una vez y media más que las 40 horas promedio. Y ni siquiera hemos mencionado actividades como la productividad, las tareas domésticas, las enfermedades, las reuniones con amigos, las citas, cortejar chicas, etc. Dejando estas de lado, suponiendo que se trabaje los 7 días de la semana, entonces serían de 10 a 14 horas de trabajo al día, y esa intensidad de trabajo solo puede ser realmente productiva durante un corto período (como máximo unos meses).

Entonces, surge la pregunta: al dedicar 2.5 veces más tiempo, ¿podemos aportar a la startup un rendimiento esperado astronómico (es decir, de 10 o 100 veces)? ¿Dónde está el valor del 150% adicional que invertimos? ¿Acaso trabajar 40 horas a la semana hace que el rendimiento empresarial sea mediocre, mientras que 100 horas hará que la empresa se convierta de la noche a la mañana en una compañía tan conocida como Facebook? Si aumentar el tiempo de los empleados puede mejorar el valor de la empresa, ¿por qué no contratar a más programadores? Sinceramente, si invertir más tiempo genera enormes rendimientos, entonces sin duda es más rentable contratar a más empleados. Esa cuenta cualquiera puede hacerla, ¿no?

Si la conclusión anterior no es correcta, ¿por qué algunos empresarios inculcan con tanto empeño una cultura de “horas extras desenfrenadas”? ¿Por qué todos elogian con tanto fervor la idea de “trabaja, trabaja... hasta morir” propuesta por Arrington y Jason Calacanis? Una posible razón es que la gente no sabe cómo medirlo y simplemente cree que trabajar horas extras siempre producirá ganancias abundantes. Sin embargo, he descubierto que hay algo más detrás de esto.

La verdad es que, por muy precisos que sean los indicadores que usamos para evaluar el trabajo, no pueden medir verdaderamente la eficiencia de un programador. Además, en la mayoría de las empresas existe un mecanismo competitivo. Incluso si algunos no quieren “disputar posiciones de poder”, igualmente tienen que dedicar mucho tiempo a revisar el código en detalle y buscar errores (bugs). Personas como Arrington no se tomarían el tiempo, ni tienen la capacidad profesional, para hacer algo tan tedioso como evaluar el desempeño de los empleados. Por lo tanto, utilizan el tiempo de trabajo como medida de la productividad de una persona. De esta manera, se puede ver de un vistazo qué programadores pasan cuánto tiempo trabajando (¡y además deben estar escribiendo código en todo momento!) o qué programadores suelen “no estar sentados frente a la computadora escribiendo código”. Por ejemplo, si cuando Arrington te llama a la 1 a.m. puedes ponerte a trabajar de inmediato sin quejarte, has estado invirtiendo tu tiempo en el trabajo. Por supuesto, los necios arrogantes no entenderán que, en realidad, contestar una llamada para arreglar un problema solo toma 10 minutos.

Por lo tanto, aunque Arrington y Calacanis insisten una y otra vez, el significado real de lo que dicen sobre querer que los programadores trabajen constantemente es que estén disponibles en cualquier momento. En gran parte, es porque sin estos programadores, muchos problemas no podrían resolverse solo con sus propios esfuerzos, pero esto no tiene relación con el éxito o fracaso de una startup. Dicho esto, en algunas empresas ya establecidas incluso hay jefes estúpidos que, en sus incomprensibles cabezas, tienen la idea de que irse un segundo antes que el jefe es un pecado mortal.

Enlace a la traducción: http://www.codeceo.com/article/how-many-hours-programming.html

Texto original en inglés: http://java.dzone.com/articles/how-many-hours-can-programmer

Autor de la traducción: Codeceo – Xiao Feng