🌓

Por qué debemos evitar interrumpir a los Desarrolladores / Programadores Los desarrolladores trabajan en un "mundo" de abstracción que requiere de largos períodos de concentración ininterrumpida para ser productivos y evitar errores

by
on July 17, 2017
(13 minute read)

Imagina que empezamos un nuevo proyecto tecnológico común: una página web, App para móvil, una nueva funcionalidad, etc. Algo que con un equipo de desarrolladores y unos pocos meses/semanas podremos completar con buenos resultados.

Please donate to keep this server up

Para cualquier proyecto, vamos a necesitar a responsables de definición del producto, negociaciones y reuniones con el cliente o stakeholders de la propia empresa, estimaciones de tiempo, costes y presupuestos, documentación, asignación de recursos, contratación de servidores y otros servicios de terceros, creación de contenido y material, comunicación… (dejaremos aparte el marketing y demás acciones posteriores).

Un error muy común es escoger a uno de los desarrolladores para que, además de desarrollar, se encargue de todas las demás tareas del proyecto.

Lo que visto desde fuera cuesta entender es que hay muchas diferencias entre las tareas de un Desarrollador de Software y las de gestión y administración relacionadas. Por querer optimizar recursos y salir del paso, suele acabar pasando factura. Las diferentes especialidades trabajan codo a codo paralelamente, pero son maneras muy diferentes de pensar y ejecutar.

Mentalidad de un Desarrollador

Los desarrolladores y programadores trabajan inmersos en la abstracción: símbolos, algoritmos, matrices de información multidimensionales, flujos de información intangible que forma hilos complejos de datos conectados… Y todo lo hacen en su pensamiento. El desarrollador necesita de una gran concentración para entrar en este “mundo” al que, para hacernos una idea, podemos comparar con construir una casa mentalmente desde cero:

Empezando por visualizar los cimientos y cada pieza de hormigón armado, la distancia entre ellas, su grosor, peso, dureza… Y subiendo con todos y cada uno de los detalles: todas las tuberías, paredes, cableado de luz y agua, las juntas, cada ladrillo, cada puerta y su marco, cada capa de pintura y punto de toma eléctrica, cada tornillo e interruptor, cada tubería desde su inicio a su fin con todas sus conexiones…

Y una vez el desarrollador lo tiene todo pensado, repensar varias veces si existe una manera más óptima: utilizar menos recursos para economizar materiales sin perder estabilidad, cómo construirlo de forma más veloz para ahorrar tiempo sin perder seguridad, pensar en cómo podrá luego ampliarse sin complicaciones si se quiere añadir una planta más o una piscina… Estas micro y macro optimizaciones las irá repensando constantemente durante todo el proceso de “construcción” de la obra.

Como decía, todo esto el desarrollador lo “dibuja” mentalmente, puede tomar apuntes, notas y pseudocódigo, pero al ser casi toda la información intangible y a su vez multidimensional, se hace muy poco viable e impráctico, si bien en la arquitectura puedes dibujar planos y esbozos, con el código es muy difícil. Con lo que la mejor opción es almacenar mentalmente mucha información y tener una gran capacidad de concentración para poder ir construyendo toda la obra y moverse por todos los datos, analizando diferentes opciones, casuísticas y demás hasta encontrar con la mejor opción: más viable, más rápida, más escalable… Y que no se rompa.

Os he puesto un ejemplo de una construcción arquitectónica para familiarizaros, ahora entramos un poco más en materia y os pongo un ejemplo sobre un extracto de código bastante simple (el lenguaje es JavaScript):

for ( currentDay = 1; currentDay < 8; currentDay++ ){
	for ( currentHour = 0; currentHour < 24; currentHour++ ){
		if ( checkCurrentDay+'-'+currentHour ).checked ){
			if ( slot.weekday === null ){
				slot.weekday = currentDay;
				slot.startTime = currentHour;
			}
			slot.duration = slot.duration + 60;
		}else if ( slot.weekday !== null ){
			schedule.push( slot );
			slot = {
				weekday: null,
				startTime: null,
				duration: 0,
			};
		}
	}
}

Este código de arriba es de una aplicación logística y nos sirve para calcular la disponibilidad semanal, hora a hora de un proveedor y guardarlo en “slots” (huecos) de tiempo para su asignación y cálculo posterior. A su vez también optimizamos el espacio de almacenamiento en la base de datos y su procesamiento.

Traduciendo el código de arriba al castellano se resuelve en:

Creamos un contador de días para cada día de la semana, empezando por el Lunes y hasta el Domingo, haremos lo siguiente:
1. Creamos un contador de horas y lo ponemos a las 12 de la madrugada
2. Para cada hora del día, haremos lo siguiente:
	2.1. Si el proveedor ha seleccionado esa hora del día:
		2.1.1. Si no tenemos un slot activo en ese día creamos un nuevo slot en el día de la semana y la hora y lo dejamos en 0
		2.1.2 Ahora le sumamos una hora a ese slot
	2.2. Si no se ha seleccionado esa hora del día, terminamos con ese slot:
		2.2.1 Lo guardamos en la Base de Datos
		2.2.2 Reseteamos el slot
	2.3. Volvemos al punto 2 y seguimos con la siguiente hora hasta llegar a las 23h
3. Volvemos volvemos al punto 1 y seguimos con el siguiente día hasta llegar al Domingo

Todo esto el desarrollador lo está traduciendo en su cabeza a medida que lee o escribe código, sin apuntar nada. En este ejemplo os he puesto menos de 20 líneas de código de las más de 1,000 o 10,000 o 100,000 que suele tener un proyecto y que un programador debe leer, interpretar y memorizar a corto y largo plazo en su día a día durante el proyecto.

¿Multitarea o monotarea?

Un desarrollador efectivo tiene que ser todo lo contrario a multitarea (trabajar en varias cosas a la misma vez, por ejemplo: coger el teléfono y solventar una duda o gestión de un cliente, resolver una duda de un compañero, estar pendiente de si entra alguien por la puerta, tomar una decisión sobre algo urgente, etc.).

Un Desarrollador trabaja en una sola tarea, pero ésta es una tarea enorme y que debe salir perfecta al 100%, no se acepta un 99.99%: los ordenadores no tienen compasión, no perdonan y si no les gusta algo lo cancelan, dejan de trabajar y muestran un error sin dar otra oportunidad lo que suele causar errores y fallos que pueden ser catastróficos.

Interrupciones durante el desarrollo

Para que un desarrollador pueda hacer su trabajo, debemos evitarle a toda costa cualquier interrupción, por pequeña que sea. Ya que se encuentra en este “mundo” de información abstracta que requiere de largos períodos de concentración ininterrumpida.

Cualquier interrupción desmorona todo lo que estaba construyendo. Ponte en su lugar, imagínate que estás leyendo el código de arriba entendiendo línea a línea y memorizando lo que está pasando, por donde van los contadores, memoria almacenada y los flujos de información y lógica, etc. De repente, alguien te interrumpe cuando vas por la mitad para preguntarte una duda sobre cómo convertir un Excel a PDF, piensas la respuesta y le contestas, y cuando quieras continuar leyendo el código tendrás que volver a empezar desde el principio. Puede que seas muy inteligente y el ejemplo de arriba te parezca poco, pero imagínate un desarrollador que en vez de leerse las 20 líneas de código de este ejemplo se ha leído 1,000, y no de la traducción que te he puesto si no de código que suele ser mucho más complejo, aunque lo entienda, tiene que procesarlo y en grandes cantidades.

Después de una interrupción como la de un compañero preguntando una simple duda, es muy común que un programador tarde de 23 a 33 minutos en volver a crearse su estructura de información mental para poder seguir con lo que estaba haciendo. Así que una simple distracción se pagará muy cara, y a veces no volverá a ser productivo hasta el día siguiente (más artículos hablando al respeto aquí, aquí, aquí, aquí, aquí…).

Interrupciones y reuniones provocan una gran pérdida de productividad a los desarrolladores/programadores

Puede que no te lo diga, pero por muy paciente y educado que sea el Desarrollador, le estás tirando a la basura media hora de su tiempo, esfuerzo y sudor. Esto incrementa su frustración e irá acabando con su paciencia y humor. Programar es muy agotador mentalmente. Este cómic nos da otro ejemplo de lo que estoy explicando:

This is why you shouldn't interrupt a programmer

Interrumpir a un desarrollador cada media hora estamos desperdiciando su productividad. Tendiendo en cuenta el salario que cobra un buen programador y a su vez, la escasez de programadores, es una auténtica catástrofe ya que acabamos desperdiciando un día entero de trabajo y salario de un activo escaso. Por suerte, hay muchas empresas que lo entienden y realmente valoran a sus desarrolladores, más abajo lo explico.

Además, cada vez que se interrumpe a un Desarrollador, estás creando un alto riesgo de que se generen errores en el código ya que quizás se olvida de un detalle que luego resulta fatal, y puede que nadie lo detecte hasta dentro de días o incluso meses que puede aparecer en el peor momento y crear un desastre, véanse las noticias como cada semana ocurren hackeos, pérdidas de datos, caídas de páginas web y servicios… Y estas catástrofes ocurren en las mejores empresas del mundo que pagan millones de dólares a los mejores desarrolladores del mundo, imagínate en una empresa más “normal”.

Evolución del desarrollo a lo largo de los años

Cuando empecé a desarrollar páginas web a finales de los años 90 la profesión de hacer páginas web era la de “webmaster”, en la que básicamente alguien espabilado lo podía hacer todo, por aquel entonces todo era mucho más sencillo que hoy en día aunque es cierto que no teníamos ni un 10% de las posibilidades que tenemos hoy en día.

Desde entonces, la tecnología ha avanzado muchísimo, tanto que, por ejemplo, para llevar a cabo una empresa tecnológica con su página web y App para móvil necesitas varios expertos en estos perfiles:

  • Front-end Developer
  • Back-end Developer
  • Android App Developer
  • iOS App Developer
  • Database Developer
  • DevOps / Systems Administrator
  • IT Support
  • Quality Assurance / Testing

Y otras responsabilidades que, pese a no ser estrictamente de programación, van muy relacionadas y también se les suele encomendar a ellos:

  • Web, UI, UX, Graphic Designer
  • Scrum Master
  • Project Manager
  • Product Owner
  • Architecture Engineer
  • Chief Technology Officer

Cada título de esta lista es una profesión en sí, ocupan una jornada laboral, cobran muy bien y tienen una manera de pensar y ejecutar distinta. Por desgracia, la mayoría de desarrolladores acaba ocupándose de varias de ellas simultáneamente, mezclando dedicación y perdiendo productividad debido a las interrupciones que ocurren al cambiar constantemente de “mentalidad”.

Aumentando la productividad de los desarrolladores

Para que los desarrolladores puedan realizar su trabajo con el máximo de productividad y el mínimo de errores deben llegar a un estado mental óptimo, como comentaba, sin interrupciones y con el mínimo de estímulos externos que les distraigan.

Dónde

Una oficina sin personas hablando entre ellas o al teléfono, sin música, en una silla y escritorio cómodos y con un ordenador y pantalla decentes, con una temperatura y luz agradable, que tengan profundidad visual para relajar la vista al pasar largos ratos mirando la pantalla.

Qué

Lo ideal es que tengan una sola especialidad de las mencionadas arriba y que trabajen en el menor número de proyectos simultáneos posible. Así evitamos la multitarea, interrupciones, reuniones…

Cómo

Para que los desarrolladores trabajen al máximo de sus capacidades y hagan su trabajo más rápido y mejor, es importante que estén bien cuidados: han de estar descansados, sin estrés, ni preocupaciones ya que estas preocupaciones pueden entrar en su pensamiento y distraerlos de su trabajo.

Recuerdo el caso de cuando trabajaba en una de las mayores empresas de Reino Unido (que más tarde fue comprada por Amazon). Cuando  un desarrollador estaba distraído, cansado o poco atento, nuestro Manager lo detectaba y le decía tranquilamente, sin ningún problema ni reparo y con una sonrisa amigable, que se fuese a casa a descansar o atender sus problemas personales y volviese por la tarde o al día siguiente, sin afectar a su salario ni vacaciones.

Por un lado lo hacía para mitigar la baja productividad del Desarrollador y, por otro, para reducir código mediocre y/o con errores que muy probablemente más tarde pasarían factura al romperse y tener que replantear proyectos y fechas para arreglarlo (creando otra interrupción), o creando deuda técnica que tendría que rehacerse de nuevo el día que se necesitara programar por encima de ese código, o alarmas a las 4 de la madrugada para el ingeniero que le toca la guardia porque “el servidor ha caído” o “algo se ha roto”…

Incluso algunas empresas ya publicitan que son conscientes de ello y en su día a día evitan proactivamente las interrupciones y los meetings:

Cuándo

Otro de los aspectos que a veces cuesta valorar para los poco tecnológicos son los horarios flexibles. Un día el desarrollador puede no ser nada productivo, y otro puede estar adentrado en “el estado de productividad” y dedicarle horas y horas de pura inspiración, rendimiento y lucidez y sacar adelante cantidades de trabajo espectaculares. Si tienes una política estricta de “8 horas al día”, te recomiendo que no la fuerces con tus desarrolladores, puede que a la hora de cerrar se encuentren en un momento súper-productivo y perderán esa inercia. O que puedan dormir unas horas más y venir descansados al trabajo, el sueño es un enemigo brutal de la concentración. Algunos desarrolladores incluso trabajan mejor de noche, hay muchos estudios que lo corroboran (más aquí y aquí) y yo mismo tengo temporadas que me va mejor trabajar mientras el mundo duerme: cero ruidos, cero estrés, nadie molestando y toda la noche por delante.

O trabajar desde la tranquilidad, confort y silencio de sus casas, mis momentos más productivos son, sin lugar a dudas, cuando estoy solo en el despacho de mi casa.

O en la empresa tener separado al equipo de Developers en otra sala lejos de llamadas telefónicas, conversaciones, interrupciones, visitas, ruidos, música (si alguien quiere escuchar música se pone auriculares), gente paseando cerca, estímulos o incluso olores del microondas o de café.

Muchas empresas de desarrollo optan por tener espacios con sofás, zonas de descanso, juegos, comida, etc. Que tengan todas las necesidades cubiertas para minimizar aún más las distracciones y necesidades de tener que relajarse o salir a tomar aire fresco. Es algo que parece un desperdicio pero que con buenos desarrolladores se nota y sale a cuenta.

La triste realidad es que debido a la escasez de desarrolladores, muchas mentes brillantes acaban marchando de la empresa donde estaban para ir a otra donde les ofrecían mejores condiciones y donde se les valora y respeta, hay muchas empresas que ya lo saben y lo aplican. Y eso sale caro ya que un Desarrollador, por bueno que sea, necesita meses para llegar a conocerse todo el código e infraestructura tecnológica y, cuando se va de la empresa donde está, es una pérdida económica increíble.

Además, algunas empresas están empezando a ofrecer vacaciones ilimitadas para que los desarrolladores puedan “desconectar” completamente y volver frescos y al 100% libres de preocupaciones personales.

Interacción y equipo

Herramientas de comunicación

Si no tienes más remedio que interrumpir a un desarrollador, utiliza medios pasivos para comunicarte (siempre que no sea algo realmente urgente/crítico que no pueda esperar unos minutos): déjale un mensaje en el chat o escríbele un email antes de llamarle o presentarte en su escritorio creando así la fatídica interrupción inevitable.

Facilítale la vida: ponle en situación desde cero y da detalles concretos. Piensa que quien programa está en un mundo paralelo de lógica abstracta y va a tener que “aterrizar” en el mundo real para atenderte y ponerse en situación de lo que le pides. Cambia el “no puedo enviar un mail” por “he intentado adjuntar un archivo ZIP que pesa 100MB a un email y me dice que el tamaño es demasiado grande“.

Si ves que alguien lleva auriculares, no le molestes, es una manera amistosa de decir “no me molestes, estoy concentrado”.

Flujos organizativos empresariales

Equipo desarrollador óptimo

En el gráfico y resumiendo muchísimo:

  • Los Stakeholders son los que piensan en lo que necesita el producto final, pueden ser inversores, clientes o incluso los propios empleados y directores de otros departamentos.
  • El Product Owner se encarga de decidir qué funcionalidades y cambios son prioritarios.
  • El Project Manager se encarga de estimar timmings y recursos para poder entregar el proyecto a tiempo.
  • El Scrum Master ayuda al Project Manager a estimar mejor las tareas y ayuda a los Desarrolladores además de tener una visión más general a nivel tecnológico.
  • Los Developers se encargan de desarrollar y programar.
  • Los Quality Assurance se encargan de testear que todo lo que hacen los Developers funcione correctamente.

Es cierto que muchas veces no nos lo podemos permitir con presupuestos bajos, y el PM acaba haciendo de SM también, es muy difícil y sacrificado porque existe un conflicto de intereses. Tiene que ser especialmente cuidadoso de respetar la concentración de los desarrolladores y a su vez apagar fuegos de otros lados.

El papel del Scrum Master

En equipos medianos y grandes se suele tener una persona extra entre el equipo de desarrollo y el Project Manager, este es el papel del Scrum Master. ¡Su papel es el de evitar que el Project Manager interrumpa a los desarrolladores!

El papel del Quality Assurance

La concentración de los desarrolladores es tan importante, que incluso se suele contar con QA Engineers, que son, ni más ni menos, que personas dedicadas simplemente a testear y comprobar que todo lo que el desarrollador ha programado funcione correctamente, de este modo, mantenemos al desarrollador en su “mundo”, evitando aún más las distracciones al tener que testear a fondo que todo funciona tal y como ha planteado, aumentando así su tiempo útil y productivo. Y sí, el salario de un QA es mucho más bajo que el de un Dev.

 

Me he dejado muchos detalles y roles, solo quiero dar una visión general de cómo se evita que los Developers tengan distracciones, ya que por desgracia, aún existen muchas empresas en las que los Stakeholders hablan directamente con los Developers y eso es fatal para su rendimiento y el éxito final de la empresa. O aún peor, que el propio Desarrollador hace dos, tres o muchas otras funciones.

Simple Cloud Hosting Built for Developers

 

Artículos interesantes:
Créditos

El gráfico de la distracción está realizado por mi y inspirado en un artículo en Inglés que leí hace muy poco y trata sobre cómo las reuniones afectan al desarrollo de software, no consigo encontrar la fuente.

Free 100% online banking account

💳 Get your free debit Mastercard

2 comments

  • Alex says:

    Me dejas tu teléfono para llamarte e interrumpirte cada día cuando me apetezca? :P jajaja te entiendo totalmente, me ocurre muchas veces tanto lo de necesitar horas para concentrarme como lo de ponerme de mal humor si alguien me interrumpe.. pero es cierto que es difícil en un equipo pequeño colaborar con el resto sin que haya ninguna interrupción.

  • Xavi Author says:

    Toda la razón Alex!
    En equipos pequeños es necesaria mucha interacción, sobretodo porque un Developer tiene muchos otros papeles (Project Manager, Product Owner, etc.). En ese caso lo mejor es educar al equipo para que sepa cómo interrumpir lo mínimo y en qué momentos (valorando si es una urgencia y/o usando comunicación no intrusiva: Slack, email, etc.).
    Un abrazo

Treasure Chest

Get notified of new projects I make
Usually one email every 3 months

Follow me for cool new products and interesting findings on graphic design, web development, marketing, startups, life and humor.


/*Twitter*/ !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs"); /*Facebook (function(d, s, id) {var js, fjs = d.getElementsByTagName(s)[0];if (d.getElementById(id)) {return;}js = d.createElement(s); js.id = id;js.src = "//connect.facebook.net/en_GB/all.js#xfbml=1&appId=28624667607";fjs.parentNode.insertBefore(js, fjs);}(document, 'script', 'facebook-jssdk'));*/ /*Google+*/ window.___gcfg = {lang: 'en-GB'};(function() {var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;po.src = 'https://apis.google.com/js/plusone.js';var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);})();