Hablar, escribir, pensar: el software no es un trabajo de escritorio
index | OSiUX | archive | charlas | docs | links
dot
|
git
|
img
|
plt
|
tty
|
uml
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
- Fuente: https://daniel.fone.net.nz/blog/2020/10/21/talking-typing-thinking-software-is-not-a-desk-job/
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.
- Es asincrónico, lo que significa que se puede consumir cuando sea conveniente para cada lector (es decir, después de una ducha matutina).
- Se puede distribuir fácilmente y no tiene pérdida de fidelidad cuando se comparte (en comparación con hablar con John sobre lo que Sarah le dijo que Steve dijo en la reunión en la que ninguno de ustedes estuvo).
- Crea un registro, en lugar de «espera, ¿por qué hicimos …?»
¡Escribir es pensar!
1 Escribir te obliga a estructurar tus ideas de manera coherente (al menos, lo parece para algunas personas). Revela deficiencias o lagunas en su comprensión o plan.
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 …
- documentación (leer el
manual de postgres
7 muy bien escrito o losdocumentos de Redis
8 es la experiencia más íntima que tuve con Neo descargando kung-fu en su cerebro) - código (muy subestimado: no hay una gema en mis archivos Gem que no haya agrupado al menos una vez)
- archivos de registro (log files), mensajes de error, ese tutorial sobre cómo leer gráficos de llamas
- la especificación, la legislación, el documento de política, la directriz del NIST, el artículo original en open access journal.
… 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
2022-11-13 20:39
agregar y actualizar tags OpenGraph2021-03-24 23:21
corregir formato link footnote2021-03-24 23:19
agregar traducción de talking - typing - thinking