Cómo aplicar ingeniería de software a tu vida diaria: Eat your Own Dog Food

Contenido del Bootcamp Dirigido por: | Última modificación: 8 de abril de 2024 | Tiempo de Lectura: 4 minutos

Algunos de nuestros reconocimientos:

Premios KeepCoding

Eat your own dog food

En Inglés existe la expresión «eat your own dog food», que viene a ser algo así como aplicarte tu propio cuento. La sabiduría del mismo es incuestionable, pero ¿cuándo fue la última vez que lo aplicaste? Programar es el arte y la ciencia de resolver problemas de forma sistemática y eficaz. Ahora bien, ¿aplicamos esas habilidades para resolver problemas fuera del entorno del código? Mucho me temo que no, y es una lástima. Desde hace un tiempo, intento traer mis conocimientos de programador al dominio de la vida diaria, y sorprendentemente, casi se podría escribir un libro de auto-ayuda, basado sólo en principios de ingeniería de software.
Cuando me encuentro agobiado o abrumado por la cantidad de cosas que hacer, aplico TDD: ¿Cuál es el menor paso (test) que tengo que dar (codificar) yendo en la buena dirección (todos los test green)? Hazlo y repite. Pronto te darás cuenta de lo mucho que has avanzado

Estrategias para resolver problemas

Para resolver problemas complejos, contamos con una «compañía del anillo» a cuyos miembros siempre puedes recurrir. Son 3 estrategias universales para resolver problemas:
señor de los anillos lego - Eat your Own Dog Food
La compañía del anillo
  1. Fuerza bruta.
  2. Divide y vencerás
  3. Transforma y vencerás
El primero es evidente y es la mejor primera opción: hay muchas cosas que aun se resuelven de forma ejemplar a garrotazos. Cuando la Fuerza Bruta no basta, y no dispones de brutez suficiente, hay que ser sibilinos y usar Divide y Vencerás: romper el problema intratable en problemas más pequeños. Esto se lo enseñé a mi hijo de 8 años para resolver unos deberes «super complicados» que les habían dado en el cole: resolver un sudoku de 3 pares de narices. Pude ver, con claridad, cómo se encendía una bombilla en su mente cuando vio lo que estábamos haciendo y el resultado. Por último, si no hay forma de partirlo en trozos, lo convertimos en un problema que sí sabemos resolver. Un ejemplo clásico es cómo sumar grandes números. En el colegio nadie te enseñó eso. Tú no sabes sumar 462846 y 956372. Te enseñaron algo diferente: una serie de regletas sencillas gráficas, cuyo resultado es la suma de dos números. ¿Quieres ver un ejemplo interesante? Mira cómo les enseñan a los niños en Japón a multiplicar números.
Transformamos la multiplicación en un problema gráfico y luego en varios sub problemas más pequeños y sencillos (una serie de sumas): ¡transforma y vencerás, seguido de divide y vencerás!

Más que estratégias, principios

Además de estas estrategias, otras cosas que deberíamos aprovechar fuera del dominio del código son ciertos principios de Ingeniería de Software. Veamos algunos.
Sabiduría concentrada a nivel de materia degenerada
Hay un libro casi desconocido para muchos, pero que debería de ser de lectura obligatoria para todo programador: «Programming A Problem Oriented Language» de Charles Moore, el inventor de FORTH.
FORTH, un lenguaje de alto nivel, y sin embargo ideal para dispositivos empotrados. Controla desde ascensores a sondas espaciales y es perfecto para el IoT. Y encima, como si Yoda fueses, te hace hablar.
En él, el autor describe como, practicando ciertos principios sencillos para resolver un problema concreto, termina creando uno de lenguajes de programación más interesantes que hay. Algunos de esos principios se han convertido en clásicos, pero Charles nos habla desde el pasado remoto, dejando claro que es un visionario muy adelantado a su tiempo. Veamos algunos: 1. Keep it simple! (Simplifica) 2. Do not speculate! (No inventes y no jodas) Si no aplicas el primero, el principio KISS, estás perdido. El resto del universo conspirará en tu contra siempre, para añadir más features, más complejidades y lo único que puede frenarlo es siempre tener el ojo puesto en el primer principio. El segundo es más interesante, y la lógica de Charles es aplastante:
dado que la cantidad de «cosas» que puedes añadir al sistema es infinita, la probabilidad de necesitar cualquier de ellas es cero. Así que no inventes y no jodas.

Eat your own dog food!

Desde hace un tiempo intento aplicar esto, no solo al código, sino a mi vida. En concreto, me di cuenta que las formaciones en Keepcoding necesitaban una dosis de la medicina del Dr Moore. Había que simplificar, había que romper monolitos en «micro servicios», había que quitar lo extra, para que lo esencial brillase con más fuerza que nunca. Ideas las justas, pero MUY claras.

Bootcamps Lean y ágiles

Siguiendo esta teoría, hemos creado una versión más «lean» y ágil de nuestros bootcamps, con un core ahora de 6 meses, pasados los cuales ya puedes volver al mercado laboral y empezar a ganar dinero. El resto, lo sigues teniendo disponible para una ruta de aprendizaje y especialización que puedes hacer a un ritmo más pausado y de forma concurrente con el trabajo.
Aplicando principios de ingeniería de software en otro dominio, ¡hemos logrado reducir el «time to market» de los alumnos y reducir el coste!
Te invito a que eches un vistazo a los temarios resultantes y a que tú también apliques tus habilidades de programador a tu vida. Ya sabes, esa «cosa» que ocurre mientras estamos alejados (temporalmente) del teclado. ⇒Descarga temario – Full Stack Web BootcampDescarga temario – Full Stack Mobile BootcampDescarga temario – Full Stack DevOps BootcampDescarga temario – Full Stack Big Data & Machine Learning

Posts más leídos