Y claro, lo mejor es encontrar compañeros que además de saber, comparten.
Un equipo no vale por lo que sabe cada uno, sino por lo que comparte. Quien explica lo que sabe, aunque sea poco, hace crecer a todos; el experto que se lo guarda todo acaba siendo un cuello de botella del que depende el proyecto.
Más vale tomar precauciones con el uso de variables y evitar que errores como NullPointerException causen dolores de cabeza.
Es la ley de Murphy aplicada al código. Si una variable puede llegar vacía, tarde o temprano llegará así, normalmente en producción. Comprobarlo antes, o usar herramientas como Optional en Java, evita que el caso se olvide.
Arreglas un error y aparece otro un poco más allá. Con prisa y a última hora del viernes, cada parche rápido solo cambia la arruga de sitio: el problema de fondo sigue ahí.
Margaret Hamilton murió el 30 de septiembre de 2026, a los 90 años. Esta ficha es de julio de 2016 y la dejamos donde estaba, solo arreglada. Su historia completa, con lo que hizo y por qué importa, está en el obituario que le dedicamos.
La frase que acompañaba a la infografía: «Ella trabajó para ganar experiencia de primera mano en una época donde las ciencias computacionales y la ingeniería de software no existían ni como disciplinas, ni como cursos universitarios».
Dos precisiones que la imagen se deja, por si alguien llega aquí buscando los datos. La pila de papel no es «el código que ella misma escribió»: son los listados del software del módulo lunar y del módulo de mando, obra del equipo que ella dirigía —más de 400 personas en 1968— en el Laboratorio de Instrumentación del MIT. Y la foto es de 1969, del Draper Laboratory, no de la NASA.
Para verlo explicado
«Great Minds: Margaret Hamilton», del canal SciShow (4:35, en inglés). Es material de otro canal, no una producción de decodigo.com. El reproductor solo se carga al pulsar, así que YouTube no recibe nada tuyo hasta entonces. También puedes verlo en YouTube.
Y si. Independientemente de tu experiencia desarrollando aplicaciones de cualquier tipo, existe siempre la posibilidad de que se escape algo y sabes que pasarán por un periodo de pruebas hasta ser estables. Pero las primeras veces parecen tan terribles que las recordarás hasta con cariño.
Todo parece ir bien en el lanzamiento… hasta que la aplicación se encuentra con el mundo real. Por eso las primeras versiones conviene publicarlas poco a poco y con un plan para volver atrás.
Aprender el segundo lenguaje cuesta mucho menos que el primero, y el tercero menos aún, porque los conceptos se repiten. Esa sensación de poder es real: cada lenguaje nuevo te enseña otra forma de pensar los problemas.
Muchos problemas de programación se resuelven lejos del teclado: dando un paseo, en la ducha o justo antes de dormir. La cabeza sigue trabajando aunque hayas cerrado el editor.
Esa sensación de empezar el día y encontrarte con el error que creías resuelto la noche anterior. Lo bueno es que, con la cabeza descansada, suele arreglarse antes.