#04 Knowledge

Software economics book resources

Sorry for the mess! This version is just a first draft ;-)

Términos a googlear

Pair programming, staff liquidity, business mapping, demand mapping, antifragile, deliberate learning, desaprender, dreyfus model, deliberate practice, t-shaped people, retrospective, Brooks law

Notes

Vincent van Gogh:

"It took me two hours to do but forty years to learn how to do it in two hours”

Kent Beck:

"Pair Programming strategy isn’t ‘go faster’, it’s ‘waste less’ (which often resultes in going faster)“

Lazy manifesto

“We focus on expanding our capabilities not on increasing our capacities”

Un entorno productivo en trabajar en pareja (originalmente publicado en programania.net)

  • un ordenador principal con dos teclados y dos ratones y espacio más que de sobra para estar cómodos y centrados frente a las pantallas.

  • un ordenador secundario. Esto es clave. En un escenario de incertidumbre máxima te atascas cada dos minutos y tienes que guguelear a mansalva. Si estás con un sólo ordenador, uno busca, y el otro tiene que andar aguantándose las ganas de buscar cosas distintas. Lo mejor es buscar en paralelo e ir comentando lo que se encuentra.

  • panel físico para gestionar el To Do. Según avanzábamos, íbamos redefiniendo una y otra vez el trabajo a hacer. Destruyendo post-its y creando unos nuevos con nuestra nueva visión de las tareas a realizar. Para nosotros era clave poder hacer esto sin los impedimentos de una herramienta electrónica como Jira, mucho más lenta. Máxime cuando la trazabilidad, en éste punto, no nos servía para nada.

  • pared pintable para discutir ideas y diagramar cosas. Tuvo mucho flow el poder discutir una idea, pintarla, e ir implementándola teniéndola siempre de referencia y pudiéndonos dar la vuelta en cualquier momento a discutir cualquier aspecto.

Es fácil enamorarse de ésta forma de trabajar. Y, al enamorarte, perder un poco la perspectiva. El sistema nos funcionó bien para su principal función: maximizar la información radiada y la comunicación entre nosotros como estrategia para abordar un producto de alta incertidumbre técnica y de dominio. Lo que no nos funcionó:

  • fuimos incapaces de mantener un sólo “to do” en el panel. Como éramos novatos en todo, aprendíamos una manera más decente de hacer las cosas cada media hora, y todo el código anterior nos parecía refactorizable (y lo apuntábamos al “to do”). Al final manteníamos el panel, un archivo todo.txt en el intellij, y las anotaciones //TODO:  en el propio código. Aunque planteábamos sesiones dedicadas sólo a fundirnos esas listas, no lo conseguíamos.

  • hacer pairing el 100% del tiempo trabajando a veces en jornadas de 10 horas es demasiado. Ya sé que esto, leído, puede sonar bastante evidente. Pero cuando estás dándolo todo, cansado, hay cosas de las que no te das cuenta. Por ejemplo, yo adquirí muchos conocimientos de “angularjs pasivo”. Como Guille es más rápido que yo pensando y empezó el proyecto manejando más de AngularJS, yo solía ser un mero espectador cuando encontrábamos una solución a un problema en JS. No soy manco: a veces se me ocurría la solución a mí… pero normalmente (especialmente cuando estábamos cansados) la implementaba él porque le suponía menos esfuerzo. Con lo que yo no terminaba de asimilar las cosas.

Lecciones aprendidas. Cómo y cuando hacemos pairing ahora:

  • hacemos pairing siempre que lo que nos impide avanzar es el conocimiento (ya sea técnico o de dominio).

  • hacemos pairing siempre que se va a tomar una decisión de diseño importante en la que se va a basar el proyecto (cómo vamos a organizar los componentes, si se va a usar tal o cuál patrón, estrategia de testeo, etc…)

  • siempre que hacemos pairing tenemos una lista preparada con el orden del día. Y sí: normalmente hacemos pairing de jornadas completas, preparando el entorno previamente para ser productivos y tener toda la información disponible y la posibilidad de tener discusiones productivas.

  • es importante no hacer pairing cuando quieres asimilar algo que has aprendido.

Como consecuencia de todo esto, en el último proyecto que hemos hecho juntos habremos hecho un día a la semana de trabajo en pareja. Al menos durante la fase principal del proyecto, acumulando en ese día las decisiones de diseño y la lista de cosas que queríamos aprender del otro. Inventándome la cifra, diré que habremos hecho un 10-15% de pairing.

¿100% o 15% de pairing? Para mí aquí ( como siempre) la clave es el contexto. Y el punto de vista desde el que analizar ese contexto, es el del conocimiento. Si analizo el proyecto en el que hicimos 100% de trabajo en pareja y soy sincero conmigo mismo, no creo que hubiéramos acabado antes ni mejor haciéndolo por separado. No creo que hubiera salido más barato ( argumento clásico en contra del trabajo en pareja). Sin embargo, si analizo el proyecto donde hemos hecho 10-15% de pairing, si que creo que más tiempo hubiera supuesto perder el tiempo. Y también sé que trabajar más por mi cuenta en AngularJS me ha hecho mucho más ágil e independiente.

Essential vs accidental complexity (post de programania)

¿Cuántas veces te pasa que, al tener implementada la solución a un problema, te das cuenta de que el problema era mucho más fácil de lo que parecía y que ahora podrías implementar una solución mucho más sencilla? ¿Cuánta de la complejidad de una solución es inherente al propio problema y cuánta se produce por la propia solución planteada?

  • La complejidad intrínseca de un problema es difícil de abordar. No la has creado tú. Tienes que convivir con ella. No puedes actuar sobre ella a corto plazo
  • La complejidad accidental de un problema es mucho más fácil de abordar. La has creado tú (o tu organización, o tu cliente…). Puedes actuar sobre ella a corto plazo y disminuirla de manera significativa.

La buena noticia es que casi toda la complejidad de lo que hacemos es complejidad accidental.

  • llevar al fondo del por qué o para qué
  • si ocurre una excepción, no convertirla en una nueva fase de nuestro proceso
  • saber que siempre al terminar vamos a entender mejor el problema y tener la oportunidad de cambiar las cosas. DArnos esa oportunidad.

Si uno es consciente de esto, puede actuar sobre ello. Por eso es importante establecer mecanismos que busquen la simplicidad y la esencia de las cosas. Una lista no exhaustiva sería:

  • pregúntate POR QUÉ y PARA QUÉ 5 elevando a la 5 veces. Usa técnicas de análisis de causa raíz.
  • plantea siempre la solución más sencilla que se te ocurra. Iterativamente, intenta reducirla al absurdo y usa a expertos para que le tiren piedras. Si no se cae, es la solución a implementar.
  • antes de automatizar procesos, replantea los procesos. Si automatizas la mierda, tendrás mierda automática.
  • refactoriza el código. Refactorizar es entender que generamos complejidad accidental y que una vez vista la solución existe una manera de hacer las cosas más sencillas. También es entender que no simplificarlo ahora, implica generar más complejidad en el futuro.

Learning to learn

Conceptos del curso:

  • sleep
  • SQ3R
  • switch you attention away
  • working memory
  • focused mode
  • pomodoro
  • chunks/chunking
  • focused practice and repetition
  • spaced repetition
  • exercise
  • underestanding
  • illusion of competence: multitasking, concept mapping, recall, iluusions of competence
  • recall
  • overlearning
  • einstellung
  • procrastination
  • learning process vs learning product (focus on the first one)
  • memory palace
  • cues: location, time, how you feel, reaction
  • habit: cue, routine, belief, reward
  • list of tasks… ¿before sleeping?
  • metaphor and analogy
  • going visual
  • Imposter syndrome
  • procrastination
  • perseverance
  • team work and study groups
  • mini testing: learning by doing tests
  • hard start, jump to easy
  • stressed? focus on breathing
  • concept mapping caca (illusion of competence)
  • highlightin more than one sencence in a paragraph caca.
  • deliberate practice
  • dreyfus model
  • dunning-kruger effect
  • Focused attention
  • Understanding
  • Practice
  • Recall: intentar recordar, ayuda a crear las conexiones neuronales
  • Transfer: un fragmento que has entendido de un área puede ayudarte a entender más fácilmente otro de otro área
  • Interleaving
  • Illusion of competence: ¡test yourself! Minimize highlighting. Mistakes are good (during learning)!, deliberate learning the most difficult parts
  • Overlearning: dedicarle mucho tiempo dividido en varias sesiones espaciadas bien. Dedicarle mucho tiempo en una sola sesión MAL (no pasa a la memoria a largo plazo)
  • Deliberate practice: concentrarte en lo más complicado para evitar illusion of competence
  • Choking:
  • Einstellung effect (einstellung = mindset): una idea previa que tienes te impide encontrar para tu problema una mejor idea o solución
  • Interleaving (intercalar): no ponerte a practiar sin leer teoría, no leer teoría sin practicar.
  • Repetición espaciada: Repetir 20 veces el mismo día es mucho menos eficaz que repetir 10 a lo largo de una semana
  • Practice makes things permanent

Links

Conocimiento antifrágil

Aprender a aprender

Apprenticeship patterns

Discovery over delivery

Liquidez del equipo

Ser profesional

Aprender a aprender

  • https://www.fs.blog/2012/04/learn-anything-faster-with-the-feynman-technique/
  • https://en.wikipedia.org/wiki/Practice_(learning_method)#Deliberate_practice
  • https://dzone.com/articles/programmers-information-diet
  • https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
  • https://en.wikipedia.org/wiki/Spaced_repetition
  • https://health.howstuffworks.com/human-body/systems/nervous-system/how-to-improve-your-memory7.htm
  • https://www.ucc.vt.edu/academic_support_students/study_skills_information/sq3r_reading-study_system/index.html
  • http://www.omniglot.com/language/srs.php

Conocimiento, aprendizaje

Images

Books