_Hablar, escribir, pensar el software no es un trabajo de escritori_

· osiux's blog

.org | .md | .gmi | .html

En la búsqueda permanente de mejorar mis skills encontré este excelente post de Daniel Fone y comparto una mala traducción :P

Hablar, escribir, pensar: el software no es un trabajo de escritorio {#hablar-escribir-pensar-el-software-no-es-un-trabajo-de-escritorio-1} #

Octubre de 2020 · aproximadamente 7 minutos para leer

tl;dr Los desarrolladores optimizan demasiado la ergonomía de la mecanografía y no lo suficiente para la ergonomía del pensamiento.

Tuve una ducha maravillosa el otro día.

Era tarde en la mañana (como suelen ser las mejores duchas) y estaba reflexionando sobre cómo paso mi tiempo durante el día. Como consultor que trabaja desde casa, constantemente necesito justificar mi facturación y mi tiempo, y en este caso estaba justificando gastar más en la ducha.

Como la mayoría de nosotros, comencé mi carrera con la impresión de que pasé un día productivo ergonómicamente equilibrado sobre un teclado escribiendo cientos de líneas de código en Microsoft Visual Basic 6.0 Professional Edition, y no parado en una corriente perfectamente caliente de agua dulce a alta presión. Sin embargo, cuanto más tiempo paso como desarrollador, menos estoy convencido de que necesito estar en mi escritorio para entregar el valor comercial verdaderamente asombroso de la hoja de cálculo a la aplicación web que brindamos los consultores de ingeniería senior.

Para que usted también pueda justificar pasar la mayor parte de la mañana envuelto en un capullo de calidez limpiadora, analicemos esto y veamos 5 actividades físicas del desarrollo de software eficaz. Como todas las listas buenas, esto está ordenado aproximadamente en orden creciente de tiempo e importancia.

5. Hablar #

Algunos desarrollos de software probablemente no necesitan hablar para ser efectivos. Entiendo, por ejemplo, que se considera universalmente de mala educación hablar en voz alta sobre el desarrollo del kernel de Linux. El contenido de ~/bin también, no hablamos.

Pero cada proyecto comercial en el que he trabajado ha necesitado al menos una charla. Cuando las personas están demasiado ocupadas o son demasiado tímidas para hablar, la falta de comunicación de gran ancho de banda puede dificultar la identificación de los requisitos y la descomposición de los problemas comerciales mal explicados.

Pero lo que es más importante, la falta de conversación dificulta la creación de confianza y comunicación, algo fundamental en las primeras etapas de cualquier nueva relación. Como animales sociales, somos particularmente buenos para hacer esto verbalmente, y no particularmente buenos para hacerlo con correos electrónicos y subtweets picantes.

Por otro lado, he trabajado en proyectos donde hablar es un apoyo para disfrazar que nadie sabe qué hacer. Donde una docena de personas se sientan en una habitación y hablan durante una hora sin decir nada y todos salimos más tontos que cuando entramos.

Entonces, para la mayoría de los casos: hablar es fundamental, pero en la cantidad correcta.

4. Escuchar #

Honestamente, solo incluí esto por simetría. Lo único que agregaré es que tenemos dos oídos y una boca, por lo que la audición binaural ofrece una ventaja evolutiva contra cierta presión de selección o se supone que debemos escuchar el doble de lo que hablamos.

Toma tu sabiduría concisa como quieras.

(busca rápidamente en Google por qué tenemos dos orejas)

3. Escritura #

¡Escribiendo código por supuesto! Pero también ... READMEs, comentarios, documentación en línea, descripciones de relaciones públicas, revisiones de código, git commits; todo esto es parte del trabajo principal. Es tentador ver esta metaescritura como una sobrecarga además de la escritura de "código" real. Pero la escritura efectiva en estos otros lugares es un multiplicador de fuerza para su código.

Sin embargo, lo que es mucho más importante, en mi experiencia, la mejor comunicación está escrita.

Debido a esto, animo a que las comunicaciones del equipo se escriban en su mayoría. Jira, Slack, correos electrónicos, trello, publicaciones de blog, lo que sea. Incluso una foto en alta resolución de una pared de notas post-it ha sido en ocasiones una hoja de ruta arquitectónica indispensable. Independientemente de cómo se publique, la redacción detallada y bien pensada es 💯.

Quizás incluso más importante que escribir es ...

2. Lectura #

Habiendo ensalzado las virtudes de escribir READMEs, enviar mensajes, descripciones de relaciones públicas, etc., obviamente debería animarle a leerlos. Se llama README EN MAYÚSCULAS por una razón, y no solo porque sea un acrónimo. Sin embargo, si tuviera un dólar por cada vez que alguien me hiciera una pregunta que ya fue respondida en el README, tendría tres dólares. 💰

Esto se debe a lo que yo llamo sucintamente el ciclo vicioso-lectura-escritura-retroalimentación. Cuando la gente no actualiza el comentario, la gente se capacita para ignorarlo, por lo que la gente no lo actualiza, etc. A decir verdad, si sabes que alguien está leyendo tus git commits, su calidad mejorará rápidamente. Incluso si nunca antes ha leído un compromiso de Git coherente de sus colegas, nunca es demasiado tarde para pedirles que expliquen lo que finalmente significa arreglarlo.

Pero al igual que la escritura, el valor de la lectura se extiende mucho más allá del depósito de código.

Recientemente comencé un proyecto que involucraba un campo completamente desconocido de la tecnología médica (ps, todavía eres mi paciente favorito 2 01-004 📊❤️). La actividad más valiosa que encuentro en esta etapa de un proyecto es leer.

Tenemos que analizar un formato de archivo especializado 3, para el cual hay una gema 4. Pero, ¿por qué dejar todo ese contexto útil enterrado dentro de la gema? La especificación del archivo 5 no es tan larga, incluso si se necesitan muchos intentos para comprenderla. Leer la especificación del formato de archivo hace que sea mucho más fácil entender por qué la gema necesita load_digital_signals_by_epoch 6, lo que a su vez sugiere soluciones alternativas al problema que tiene entre manos.

Ninguno de los posibles adyacentes se puede descubrir sin los conocimientos adquiridos al leer estas fuentes, así que sea lo que sea con lo que esté tratando, vaya a la fuente y lea, lea, lea ...

... ya captas la idea, solo encuentra el documento autorizado y sorpréndelo en tu cerebro. Incluso si parece que nada se pega, un breve encuentro con el texto dejará una impresión duradera. Es como la homeopatía pero real.

Hablar / escuchar ... escribir / leer ... y finalmente ... ruidos de redoble de tambores

1. Pensando #

Cuando lo reduce, este es el esfuerzo principal para mí y, sin embargo, es algo oculto.

¿Cuánto de mi tiempo de programación / codificación / desarrollo se dedica a pensar en los problemas? Modelar el dominio, pensar en los casos extremos, jugar mentalmente con abstracciones.

Y es obvio cuando piensas en lo que hace buenos desarrolladores. Las personas con las que más valoro trabajar no son mecanógrafos precisos, son pensadores claros.

Sin embargo, persiste la imagen de que escribir es funcionar y trabajar es escribir y un día productivo es en su silla en su escritorio. Así que tenemos monitores duales de 4k, teclados mecánicos, sillas aeron, barra táctil, atajos de vim, lo que sea que nos optimice al hacer tapping en nuestras computadoras.

Pero, ¿cuánta atención prestamos a la ergonomía del pensamiento?

Cuando elevamos el "pensamiento" al trabajo principal, naturalmente comenzamos a optimizarlo específicamente. En general, no necesitamos estar frente a nada para pensar con eficacia y, a menudo, creo que es mejor no estarlo. Mis momentos de mayor claridad son invariablemente cuando me muevo, a menudo cuando hago ejercicio. Además, puedo leer en mi teléfono prácticamente en cualquier lugar, y las mejores conversaciones se mantienen a menudo mientras paseo.

Entonces, aunque estoy contento por toda la ergonomía de mi espacio de trabajo, cada vez más encuentro que escribir código es la parte breve en la que simplemente estoy cosechando toda la cosecha mental que he sembrado de hablar, escuchar, leer y pensar.

Para resumir esto en algo un poco más aliterativo, a veces lo he descrito como las 3 Ts (talking typing thinking) del desarrollo de software ...

Hablar · Tipear · Pensar #

Hablar y escuchar; las discusiones verbales. La mayoría de las veces necesitamos una cantidad pequeña pero crítica de comunicaciones síncronas de gran ancho de banda.

Escribir comentario de código: READMEs, revisiones de código, descripciones de relaciones públicas; y toda la comunicación asincrónica: actualizaciones del proyecto, descripciones técnicas, correos electrónicos con los próximos pasos; Todos estos son una parte esencial del trabajo y no solo un trabajo auxiliar o ajetreado. También escribiendo código real en algún momento. Pero encuentro que cuanto más tiempo pasas escribiendo las otras cosas, menos tiempo necesitas dedicar (re) escribir código.

Pensamiento: (incluido, a efectos de aliteración, lectura)

Hablar, escribir, pensar: este es el trabajo que hacemos. Y yo, por mi parte, quiero darme el espacio para hacer todas las partes realmente bien.

De todos modos, tengo que ir a darme una ducha. 🚿

Te recomiendo leer #

ChangeLog #

  1. https://alistapart.com/article/writing-is-thinking/ ↩︎

  2. https://twitter.com/danielfone/status/1318026784454045703 ↩︎

  3. https://en.wikipedia.org/wiki/European_Data_Format ↩︎

  4. https://github.com/nsrr/edfize ↩︎

  5. https://www.edfplus.info/specs/edf.html ↩︎

  6. https://github.com/nsrr/edfize/blob/93566cdc82b160ef319c51908c1c4a19666e2625/lib/edfize/edf.rb#L243 ↩︎

  7. https://www.postgresql.org/docs/current/index.html ↩︎

  8. https://redis.io/documentation ↩︎

#hablar-escribir-pensar-el-software-no-es-un-trabajo-de-escritorio-1