Vi el otro día una actuación de Kate Gregory en la conferencia Pacific ++ 2018.
Kate es una buena programadora y una gran oradora. El informe en sí plantea muchas cosas interesantes sobre la programación en C ++ y la programación en general (vale la pena echarle un vistazo). Pero, sobre todo, me enganchó uno (literalmente de pasada) que pensaba que ella expresaba. Kate pudo muy brevemente y, en el caso, identificar la motivación de los programadores. Ella sonó así: "El programador, mientras trabaja, busca maximizar su felicidad". Suena cursi, pero realmente lo es.
Podemos decir que apoyamos el proyecto, el cliente, la empresa, la humanidad y la paz mundial (y esto incluso puede ser cierto). Pero seamos honestos. Somos personas y, como todas las personas, en primer lugar nos esforzamos por maximizar nuestra felicidad: globalmente a lo largo de nuestras vidas, estratégicamente en nuestras carreras, tácticamente en el proyecto actual y mezquinos aquí y ahora, al escribir esta función, esta línea de código. Sí, estamos haciendo esto y sería bueno descubrir qué nos hace más felices y qué nos hace menos. Esto nos permitirá comprender mejor a nuestros colegas, subordinados y a nosotros mismos.
Quiero poner inmediatamente entre paréntesis los problemas de remuneración, condiciones de trabajo, superiores, personal y otros. Si trabaja donde trabaja, entonces todo esto le conviene aproximadamente. Centrémonos en lo que nos hace felices e infelices cuando trabajamos directamente en el código.
Pruebas
Todos los proyectos con pruebas son igualmente felices, cada proyecto sin pruebas es infeliz a su manera. Puedo decir con confianza que los programadores en proyectos con buena cobertura de prueba son en promedio más felices que en proyectos sin pruebas en general. Incluso vi cómo los programadores, con quienes sus superiores no estaban de acuerdo en escribir pruebas completas, las escribían en secreto (a veces incluso después de horas). ¿Por qué sucedió esto? La prueba escrita hace al programador más feliz. Su propia existencia ya es una señal de que al menos algo en su proyecto se está haciendo de acuerdo con las mejores prácticas de la industria (incluso si el resto no lo es). Una prueba completada con éxito muestra una hermosa marca de verificación verde, alaba al programador (y, después de todo, tal vez nadie más lo alabe). La finalización exitosa del 100% de las pruebas proporciona algún tipo de terreno estable bajo tus pies, cuando ya puedes creer en algo, lo que se suma a nuestra confianza en hoy y mañana, nos hace más felices. E incluso una prueba fallida hace su trabajo: nos informa que la escribimos por una buena razón, elogiándonos por nuestra previsión. Si desea que un programador sea más feliz, permítale (o incluso obligarlo a forzarlo) escribir pruebas (por supuesto, todo es bueno con moderación).
Corrección de errores y desarrollo de nuevas funcionalidades.
"No te lo diré por todo Odessa", pero a la mayoría de los programadores que conocí en mi vida les gustaba más escribir nuevas funciones que arreglar el código legac. Por qué Pero porque tocar un error es tocar la desgracia de otra persona. Algo salió mal para alguien y era tan importante que no era demasiado flojo como para llevar su dolor al desarrollador. Hay que ir a su posición, tratar de reproducirse. Y luego de todo, tendrá éxito en la reproducción, y habrá un golpe a la autoestima debido a un error admitido, o no funcionará y será necesario (¡Dios mío, no!) Para contactar a una persona viva que ha descubierto el problema e intentar obtener más información. Todo esto no se puede llamar agradable.
Al mismo tiempo, escribir un nuevo funcional es un toque potencial de felicidad. Todavía no hemos roto nada, no es nuestra culpa. Estamos escribiendo un nuevo código para resolver nuevos problemas. Quizás tenga éxito. Quizás recibiremos un merecido elogio (bonificación, promoción). Esto ya está más cerca de los niveles superiores de la pirámide de las necesidades humanas
según Maslow .
¿Cuál es la conclusión? El trabajo del programador debe ser equilibrado, no debe tener una corrección de errores. Cada programador necesita confiar el desarrollo de nuevas características de vez en cuando. Sí, no hay escapatoria de la corrección de errores, pero al menos podemos tratar de lograr un equilibrio de felicidad e infelicidad "aproximadamente cero" en este asunto.
Refactorización
Trabajar con buen código es bueno. Desafortunadamente, un buen código no cae del cielo. Incluso es imposible tomarlo y escribirlo la primera vez. Tenemos que hacer un buen código de malo, porque no hay nada más que hacer con él. Aquí, los programadores eligen: todos los días, cuando vienen a trabajar, continúan sufriendo y trabajan con un código incorrecto, o aún toman y tratan de hacer un buen código. En el segundo caso, a menudo tiene que luchar con una administración que no comprende en qué se pueden pasar estas N horas de tiempo si no se agregan nuevas características al producto y tampoco se corrigen los errores antiguos. Sí, tienes que pelear. Afortunadamente, en esta guerra tenemos argumentos: el código conciso y hermoso es menos propenso a errores, su soporte lleva menos tiempo (y cuesta menos dinero), se presta mejor a los cambios cuando aparecen nuevos requisitos comerciales, etc. Además, esta guerra, por regla general, no es larga: termina con algún tipo de compromiso como "no, no daré un mes para la refactorización, sino que lo asignaremos 2 horas a la semana los viernes". De acuerdo, eso está bien. Acabamos de conseguir un pedazo de felicidad. Sí, aún tendrá que construirse con sus propias manos, pero esto ya es posible.
Usando bibliotecas y herramientas modernas
Muchos probablemente conocen el dolor de tener que trabajar en un proyecto que está atascado por alguna razón en un compilador (marco, biblioteca) hace muchos años. Nos explican que por tal o cual razón es imposible actualizar a la nueva versión aquí y ahora, pero algún día, probablemente, si funciona ... ¿Qué puede hacer? Bueno, en primer lugar, debemos admitirnos a nosotros mismos que las circunstancias no están a nuestro favor y que la situación nos hace más infelices de lo que podríamos ser. En segundo lugar, las autoridades (o el cliente) pueden expresar la misma idea. Es poco probable que alguien discuta con esto. Y en este momento puede intentar negociar por sí mismo: por ejemplo, tiempo para las mismas pruebas, nueva funcionalidad y refactorización. (Puede aumentar el salario, pero al principio del artículo prometí no incluirlo).
Por cierto, el tiempo dedicado a tareas tan útiles en realidad no solo puede hacerte un poco más feliz aquí y ahora, sino que también elimina las razones muy "aterradoras" por las que era imposible cambiar el uso de herramientas más nuevas. La situación real de mi vida:
- No estamos seguros de que la transición a una nueva biblioteca no nos traerá nuevos problemas ...
- Y aquí escribí 200 pruebas para el código usando esta biblioteca, intentemos pasar y las lanzaremos.
- Hmm, vamos.
Después de 2 semanas, una nueva biblioteca en producción.
Probablemente pueda continuar explorando otros aspectos. Pero la idea general es la misma: algunas tareas y circunstancias hacen que el programador sea más feliz, otras, más infelices. Si habrá más segundos que el primero: el estado de ánimo y la productividad del programador disminuirán, tarde o temprano esto generará problemas en el proyecto o su salida del equipo. Por lo tanto, tanto el programador como su gerente deben pensar no solo en el "bien global" del proyecto, empresa o usuario, sino también en cómo mantenerse relativamente contento con el desarrollador. De lo contrario, ¿cuál es el punto?