Habilidades permanentes en el desarrollo de software
Por David Vallejo, Profesor Titular de Universidad en ESI-UCLM.
“Read what you love until you love to read”. La propuesta que dibuja esta famosa cita de Naval Ravikant hizo que diera, hace unos años, con Morgan Housel. Ahora es uno de mis escritores favoritos. Morgan tiene la asombrosa capacidad de hacerte pensar sobre un montón de temas, relacionados con la vida y el comportamiento de las personas, mediante ideas y argumentos que entrelaza con pequeñas historias.
Su último libro, titulado Same as Ever, se centra en el conocimiento de las cosas que nunca cambian, mientras que la tendencia generalizada de la mayoría de nosotros es la de realizar predicciones inciertas sobre un futuro cada vez más desconocido.
En uno de los episodios de su podcast, también muy recomendable, Morgan reflexiona sobre las habilidades que expiran o caducan y las habilidades que son permanentes.
Las habilidades que expiran suelen atraer mucha atención. Al menos, temporalmente. Suelen ser hot topics demandados por la industria para mejorar el rendimiento a corto plazo. También suelen generar el efecto FOMO (fear of missing out).
Por el contrario, las habilidades permanentes son diferentes. Siempre han estado ahí, y siempre lo estarán. Son sencillas. Son básicas. Son incluso silenciosas. Pero marcan la diferencia en el largo plazo. Interés compuesto en estado puro.
Todo esto me hizo pensar en habilidades permanentes desde el punto de vista del desarrollo de software. Y en este artículo voy a enumerar 7 que considero especialmente relevantes.
- Habilidad número 1. Darse cuenta de que tener unos fundamentos sólidos de programación representa la piedra angular. Esto es tan importante como que una casa tenga buenos cimientos sobre los que construir. La deuda técnica es un problema recurrente en muchos proyectos de programación. Para mitigarla, debes plantear un buen diseño software. Y para plantear un buen diseño es necesario que cuentes con unos sólidos fundamentos de programación. Lo siento, pero no puedes aprender a programar en 21 días.
- Habilidad número 2. Tener la capacidad para manejar abstracciones, aplicando soluciones existentes a problemas recurrentes. Exacto; seguramente lo estés pensando: patrones de diseño. La rueda ya existe, no la reinventes constantemente. Usar lo que está bien probado y funciona ahorra tiempo y combate la deuda técnica.
- Habilidad número 3. Identificar la complejidad de las cosas y aceptarla con humildad cuando no se puede evitar. El principio KISS (Keep it Simple, Stupid) es tu aliado atemporal, pero hay proyectos que son inherentemente complejos. A veces, no hay más remedio que lidiar con la complejidad y plantear simplificaciones no es realista.
- Habilidad número 4. Ser capaz de crear prototipos de forma ágil, de forma que el paradigma de desarrollo o la tecnología utilizada no represente una barrera significativa. Yo lo llamo software liquidity. Las herramientas, las tecnologías, los lenguajes e incluso los paradigmas cambian constantemente. Ser capaz de entender cómo funcionan en poco tiempo y usarlos de manera práctica y ágil es clave. Domina la habilidad número 1 antes de enfrentarte a la habilidad número 4.
- Habilidad número 5. Entender el problema que tu cliente necesita resolver. Este paso, anterior al diseño y desarrollo de software, es fundamental para llegar a buen puerto. La capacidad para interactuar y entender a tu cliente es insustituible. Casi tanto como la capacidad de decirle que no cuando sus expectativas (requisitos planteados) superan a la realidad (recursos disponibles).
- Habilidad número 6. No sobreoptimizar. La economía se puede entender como la definición de políticas de asignación de unos recursos que son escasos. Esto aplica también al desarrollo de software. Recuerda: “time is your most valuable asset”. Concepto de vía negativa. Warning que se activa cada vez que algún compañero usa la expresión “pues ya que estamos”.
- Habilidad número 7. Ser generoso. Esta es una habilidad permanente que se podría aplicar a cualquier ámbito humano o profesional. El desarrollo de software es un trabajo colaborativo. El código que un desarrollador escribe lo deben entender y utilizar otros compañeros. Presentes y futuros. Con la documentación de código ocurre lo mismo, incluso en proyectos unipersonales: “Documentation is a love letter that you write to your future self”. Si estás pensando que ChatGPT puede hacerlo por ti, pregúntate si realmente le encargarías que escribiera una carta de amor en tu lugar.
Referencias
- El almanaque de Naval Ravikant.
- Same as Ever. Morgan Housel.
- The Morgan Housel Podcast.
- El cisne negro. Nassim N. Taleb.
- Quit: The Power of Knowing When to Walk Away. Annie Duke.
