«En la casa de mi Padre hay muchas habitaciones. Voy a prepararles un lugar». Jesús

Julio de 2025.

Estaba en Tailandia con mi esposa. Habíamos estado ocupados casi todo el día y apenas habíamos mirado los teléfonos.

Hacia las once de la noche tuvimos un rato libre y por fin los revisamos.

Había decenas de llamadas perdidas de mi hermano en Canadá, de mi familia en Filipinas y de mi cuñado en Singapur. Distintas personas, distintos lugares, pero todos decían lo mismo.

Puede que a Karen no le quede mucho tiempo.

No recuerdo bien el resto de aquella noche. Hay fragmentos que todavía puedo recuperar, pero todo lo demás se mezcla y se vuelve borroso.

Recuerdo discutir con mi esposa por algo. Algún desacuerdo, o quizá muchos, no lo sé. Recuerdo que me dijo que estaba buscando vuelos de vuelta a Singapur, y que el primero que podíamos tomar salía sobre las cinco de la mañana del día siguiente.

Así que se lo dije a mi familia.

A las cinco de la mañana. Ese era el primer vuelo que podíamos conseguir.

Después intenté, al menos, hacer algo de trabajo.

Abrí el portátil y me quedé mirando lo que hubiera en la pantalla. Probablemente contesté algo o entré en una reunión. Creo que escribí algunos correos, quizá respondí a alguien.

La verdad es que no lo recuerdo.

Mi cuerpo estaba en Tailandia, tenía el portátil delante, pero mi cabeza volvía una y otra vez al mismo pensamiento, como si buscara la manera de decirme: yo no debería estar aquí.

Esta noche no. Ahora no.

Con mi melliza​

Tengo una hermana melliza.

Karen y yo nacimos juntos. Técnicamente, yo era mayor, quizá por unos cuarenta minutos, y a veces usaba eso como justificación suficiente para fingir que tenía alguna autoridad de hermano mayor sobre ella.

Pero, en realidad, no la tenía.

Al crecer, sin embargo, teníamos una conexión extraña. No sé si la llamaría telepatía, porque suena ridículo al decirlo en voz alta, pero había momentos en los que parecía que nuestras mentes sabían lo que pensaba el otro sin necesidad de decir nada.

En la universidad hubo una noche en la que salió a beber con sus amigas. Todas chicas.

Y sí, una de ellas era mi ex. Vamos a llamarla el Misterio Gozoso. Era una de las mejores amigas de mi hermana. Es complicado. No preguntes.

El caso es que intenté llamarlas porque ya era tarde y nuestra madre iba a volver pronto, pero no conseguí localizarlas.

No soy precisamente el mejor hermano del mundo. Estoy lejos de ser un ejemplo, yo también he tomado un montón de decisiones estúpidas y, repito, solo era cuarenta minutos mayor que Karen.

Pero quería protegerla.

Solo que no se me daba muy bien demostrarlo.

Así que salí a buscarlas.

Por suerte, en la universidad yo también bebía bastante, lo que me había dado algunos conocimientos útiles sobre adónde solían ir los universitarios borrachos antes de volver a casa.

Había sitios donde comíamos algo caliente y se nos pasaba un poco la borrachera para que nuestros padres no supieran de inmediato qué habíamos estado haciendo toda la noche. Normalmente eran lugawans, locales que servían lugaw, arroz caldo, gachas de arroz y cosas así.

Miré en uno. Nada.

Luego fui a otro. Y allí estaban.

Mi hermana, sus amigas y el Misterio Gozoso, con quien en realidad todavía no salía por entonces.

Todas vivas, todas borrachas.

Por supuesto, no entré como un hermano extraordinario que había recorrido calles y locales buscando a su hermana desaparecida.

Simplemente me acerqué, esperé a que terminaran de comer y luego Karen y yo volvimos al apartamento.

Apenas hablamos por el camino. Notaba que estaba enfadada, o quizá avergonzada, o quizá preocupada porque yo se lo contara a nuestra madre.

Cuando llegamos, cada uno se fue a su cama.

Nunca volvimos a hablar de aquella noche.

Hablábamos de muchas cosas, pero, de alguna manera, también había muchas de las que nunca necesitábamos hablar.

Cuando vivíamos en Antipolo, ¿hacia 2007, quizá?, yo tenía mi propia habitación. La suya estaba al lado, pero a veces usaba la mía cuando yo estaba en Manila.

Una tarde llegué a casa y nuestra tita, nuestra tía, empezó a regañarme de inmediato.

Había encontrado un cenicero en mi habitación. Colillas, ceniza y todo lo demás.

Lo que vino después debió de ser una o dos horas de sermón sobre fumar siendo joven, las malas influencias, las malas decisiones, destruir mi futuro y todas las terribles elecciones de vida que, al parecer, empezaban con aquel cenicero.

Estuve furioso todo el rato.

Yo no tenía cenicero. Ni siquiera fumaba, joder.

Después de aquel día, nunca volví a ver una colilla en mi habitación. Tampoco volvió a oler a humo.

No llegué a hablarlo con mi hermana.

Quizá no había una forma natural de sacar el tema, o quizá ninguno de los dos sabía cómo.

Así que lo dejé pasar. O quizá simplemente lo olvidé.

Entre nosotros había muchas cosas así: algunos temas no se discutían, simplemente nos entendíamos en silencio.

Eso también incluía al Misterio Gozoso, que era una de sus mejores amigas.

Había sido madre joven y ya tenía un hijo, y sinceramente no creo que a Karen llegara a gustarle del todo la idea de que estuviéramos juntos.

Nunca me dijo directamente que no saliera con su amiga. En realidad, nunca dijo nada.

Quizá no quería que yo saliera con su amiga. Quizá no quería que su amiga saliera conmigo. O quizá nos conocía lo suficiente a los dos como para darse cuenta de que juntarnos era una jodida estupidez.

Creo que fue en 2013 cuando el Misterio Gozoso y yo fuimos a casa.

No estábamos haciendo nada. Literalmente, estábamos sentados a la mesa del comedor cuando Karen abrió la puerta y nos vio.

Entonces volvió a cerrar la puerta de inmediato y se alejó tan deprisa que mi cerebro entró en pánico.

Dejé al Misterio Gozoso sentado allí y corrí detrás de mi hermana y, por extraño que parezca, ni siquiera sabía por qué me estaba entrando el pánico.

¿Estaba enfadada Karen? Tampoco tenía idea.

Quizá ni siquiera lo estaba. Quizá solo lo supuse.

Bueno, ese fue el incidente. El primero y el último.

Y, naturalmente, como al parecer así resolvíamos Karen y yo la mitad de nuestros problemas, nunca volvimos a hablar de ello.

Es curioso.

Puedes crecer al lado de alguien, compartir cumpleaños, padres, recuerdos de infancia, amigos, secretos y el mismo jodido útero.

Y aun así ser pésimo para comunicarte.

Quizá siempre dimos por hecho que habría más tiempo para hablar después.

Una hora​

Pasadas las nueve de la mañana, aeropuerto de Changi.

Nuestro avión acababa de aterrizar en Singapur.

Yo estaba dormido cuando las ruedas tocaron la pista. El chirrido del caucho contra el hormigón me despertó y, durante unos segundos, mi cabeza todavía no había terminado de ubicarse.

Abrí los ojos y miré a mi esposa, sentada a mi lado, junto a la ventanilla.

Miraba su teléfono.

Había algo raro en su cara. No físicamente, sino en la expresión. Pensé que seguía molesta por la discusión, o quizá todavía estaba asimilando algo. No supe interpretarlo.

Entonces me miró.

«Karen ha muerto».

Mi cerebro no lo registró. No de inmediato.

Ella seguía hablando de las llamadas de mi hermano, de mi madre, de mi tita y de la gente que intentaba contactarnos.

Pero yo no estaba oyendo realmente las palabras.

Era como si alguien hubiera bajado de golpe el volumen de todo el avión.

Saqué el teléfono y llamé a mi cuñado.

Contestó con dificultad para hablar. Luego, de alguna manera, logró decirlo.

Karen había dejado de respirar.

Y de pronto mi cabeza lo entendió.

Fue como recibir el golpe de algo enorme. Un camión, un muro, un pájaro, un avión. No lo sé.

Bajamos del avión, recogimos nuestro pequeño equipaje y pedimos un coche directo al Hospital General de Singapur.

Al llegar, entramos corriendo.

Fuera de la sala de Karen, mi madre y mi tita estaban sentadas en los asientos metálicos. Tenían los ojos hinchados y la cara agotada. Mi esposa y yo entramos.

La cama de Karen estaba al fondo, detrás de una cortina verde gruesa. Mi cuñado nos vio, se acercó y los tres cruzamos juntos la cortina.

Y allí estaba. Karen.

Lo primero que me vino a la cabeza fue increíblemente estúpido.

Este es el primer cadáver que veo en mi vida.

He visto cadáveres en películas, series y documentales. Los ves tantas veces que, de alguna manera, la imagen se vuelve familiar.

Una persona inmóvil. Los ojos cerrados. Sin movimiento.

Creo que también había visto alguno antes en la vida real, pero no lo recuerdo.

Pero esto era distinto, porque no era una persona cualquiera ni una desconocida.

Nuestra madre solía decirnos que habíamos compartido la misma «cama» dentro de su vientre.

Nueve meses juntos antes siquiera de ver el mundo. Nacidos el mismo día, en el mismo lugar, con cuarenta minutos de diferencia.

Técnicamente, habíamos entrado juntos en este mundo. Nunca me había detenido a pensar qué significaba eso.

Quizá en algún rincón estúpido de mi cabeza daba por hecho que también nos iríamos más o menos al mismo tiempo.

No exactamente juntos, pero lo bastante cerca.

Los dos discutiendo sobre quién tenía peor memoria. Algo así.

En cambio, allí estaba. Era mi mejor mitad, literalmente mi otra mitad. Desde antes de nacer.

Todos lloraban. Mi esposa. Mi madre. Mi tita. Mi cuñado.

Él nos contó que Karen había intentado mantenerse despierta a pesar de que le costaba respirar. Probablemente ya sabían hacia dónde iba todo. Probablemente sabían que estaban viendo acercarse la línea de meta.

Y llegamos tarde, por alrededor de una hora.

Cruzamos países y volamos de vuelta tan rápido como pudimos, y aun así nos faltaron sesenta minutos para verla con vida.

De puta madre, Jesús.

No sé con quién estaba enfadado.

¿Conmigo? ¿Con la aerolínea? ¿Con Tailandia? ¿Con el cáncer? ¿Con Dios? ¿Conmigo? ¿Con el tiempo? ¿Conmigo?

Probablemente con todos. Quizá con ninguno. No lo sé.

El espacio vacío​

Al final, las enfermeras se llevaron el cuerpo de Karen.

Mi cuñado fue con ellas, mientras los demás volvimos a nuestras casas.

Porque, al parecer, cuando alguien muere el mundo no puede detenerse, y esa es una de las partes más extrañas.

Siguen quedando cosas por hacer, llamadas, horarios que organizar, preparativos del funeral, personas que preguntan y personas que esperan respuestas.

La vida sigue haciendo todas esas cosas completamente normales mientras sientes que la tuya acaba de partirse por la mitad.

El velatorio se celebraría en el espacio comunitario abierto de la planta baja de su bloque, el void deck.

He pasado junto a innumerables velatorios en esos espacios por todo Singapur.

Ves las mesas, las sillas de plástico, las cortinas, a la gente sentada en silencio y un ataúd en algún lugar del interior. A veces hay música. A veces, oraciones.

Y casi siempre, cuando pasas junto a uno, sigues caminando. Porque no es tu funeral.

No es tu familia. Solo eres alguien que pasa. Alguien que mira desde fuera.

Esta vez tenía que entrar. Y no era por una persona cualquiera que conociera.

De puta madre, Jesús.

El primer día del velatorio todavía tenía trabajo. Mi familia intentó entenderlo.

Hasta entonces no había contado a mi equipo lo que estaba pasando. Ese día, por fin, les dije que no podría estar disponible hacia el final de la semana porque sería el entierro de mi hermana.

Creo que me apoyaron y fueron comprensivos. La verdad es que no lo recuerdo. Quizá no me importó recordarlo.

Mi esposa, en cambio, estaba molesta conmigo. Quizá enfadada. Creo que discutimos porque yo seguía trabajando mientras preparaban el cuerpo de mi hermana en el hospital para el funeral. Sinceramente, no recuerdo exactamente qué dijimos, ni qué dije yo.

Apenas recuerdo aquella semana entera.

Esos días se sienten como si alguien lo hubiera grabado todo, hubiera borrado partes al azar y luego hubiera cosido los fragmentos restantes.

Esa noche bajé al espacio del velatorio.

Todavía no había nadie, pero ya estaba todo preparado.

Las mesas y sillas estaban ordenadas. Delante había una cruz con Jesús mirando hacia abajo y, debajo, el lugar donde iría el ataúd de Karen. Su cuerpo llegaría al día siguiente y comenzaría el velatorio.

Pero aquella noche solo era un espacio vacío. Me senté a una de las mesas, frente a él.

Solo yo. Y ese espacio vacío.

No sé cuánto tiempo estuve sentado allí.

Quizá esperaba algo.

Quizá quería que alguien entrara y me dijera que estaba en el lugar equivocado. Quizá quería despertarme, pero ni siquiera estaba dormido, joder. Quizá odiaba con toda el alma aquel espacio vacío.

Al final dejé de mirar. Cerré los ojos, me cubrí la cara con ambas manos y me quedé así.

Hay momentos en los que el cuerpo parece entender algo antes que la mente.

Tu cerebro sigue intentando negociar.

Quizá esto. Quizá aquello. Quizá de alguna manera.

Pero tu cuerpo ya se ha rendido ante la verdad.

Sin mi melliza​

Llegó el último día.

Estábamos en la iglesia, con el ataúd de Karen delante. Entró un sacerdote y empezó la misa.

Agradecí que estuviera allí la familia de mi cuñado. No creo que la mayoría fueran católicos. Quizá ninguno lo era.

No importaba.

Vinieron.

Se sentaron con nosotros, se levantaron cuando los demás se levantaron y se quedaron.

A veces eso basta.

Después de la misa seguimos el ataúd hacia fuera, mientras lo llevaban al vehículo que la trasladaría al crematorio.

Nuestra familia y la de mi cuñado subimos a un autobús que habían alquilado.

Unos minutos después llegamos.

Entramos en la sala de observación, donde un gran ventanal daba a la planta de abajo.

Entonces apareció Karen. O, más bien, su ataúd.

Avanzaba despacio mientras sonaba música de fondo.

Lo vi dirigirse hacia otra sala, donde estaba el horno.

La sala donde la madera, la tela, las flores y el cuerpo desaparecerían en el calor.

Ahí fue cuando algo terminó de encajar.

No en el hospital.

No cuando mi esposa me lo dijo en el avión.

No cuando la vi en la sala.

No cuando la vi dentro del ataúd.

Ni siquiera durante la misa.

Ahí.

Viendo cómo aquel ataúd se alejaba lentamente de nosotros.

Ya no había forma de negociar con esa imagen.

No había quizá.

No había después.

No habría más conversaciones sin terminar.

No volveríamos a entendernos en silencio.

No volveríamos a enfadarnos y decidir que ya lo hablaríamos otro día.

No habría otro día.

Durante casi toda mi vida, la palabra mellizos significaba que éramos dos.

No era algo en lo que pensara.

No piensas en tener dos manos hasta que te falta una.

Algunas cosas simplemente están ahí.

Permanentes.

Forman parte de la estructura de tu mundo. Ella era así.

Yo nunca había existido en un mundo sin mi melliza.

Parecía una estupidez pensar en eso en aquel momento, pero lo cierto es que nunca me había imaginado de verdad un mundo en el que solo quedara uno de nosotros.

Incluso antes de que yo tuviera recuerdos, ella ya estaba ahí.

Antes de que tuviéramos nombres.

Antes de que cualquiera de los dos hubiera visto a nuestra madre.

Antes de la luz.

Antes del sonido.

Antes del primer aliento.

Éramos dos.

Teníamos al otro.

Entonces el ataúd desapareció dentro de la sala.

Y, de pronto, solo queda uno.

Sin su melliza.

No sé si se supone que tiene que haber una gran lección al final de algo así.

Quizá una versión anterior de mí habría intentado encontrarla.

Forjar el carácter.

Hacerte más fuerte.

Cambiar tu perspectiva.

Alguna mierda poética de ese estilo.

Pero el cáncer no siempre te deja sabiduría.

A veces solo se lleva a alguien.

A veces deja una silla vacía, unas gafas que nadie usa, un cumpleaños que ahora pertenece a una sola persona viva y fotografías que de pronto valen más porque nunca habrá otra nueva.

A veces deja a un mellizo mirando la palabra mellizo y preguntándose si todavía tiene derecho a usarla.

¿Sigo siendo mellizo si ella ya no está? No lo sé.

Qué puto pensamiento tan estúpido y egoísta.

La gente dice que alguien sigue vivo en los recuerdos.

Quizá sea verdad.

Yo tengo muchos.

Discusiones que nunca empezamos.

Discusiones que nunca terminamos.

Cosas que entendíamos sin decir nada.

Cuarenta minutos.

Toda una vida.

Y una hora demasiado tarde.

Todavía no sé qué se supone que debo hacer con toda esa información.

Quizá nada.

Quizá a algunas personas no las «superas». Quizá simplemente sigues avanzando mientras llevas contigo el espacio que ocupaban.

Y, de vez en cuando, miras esa silla vacía del salón esperando que todavía estén ahí.

Durante casi cuatro décadas, sabía que en algún lugar de la Tierra había otra persona con el mismo cumpleaños, la misma infancia, los mismos padres y partes de la misma historia.

Entonces el cáncer decidió que solo debía quedar uno de nosotros.

Así que sí.

Que te jodan, cáncer.

Este es un borrador que escribí hace tiempo, probablemente hacia diciembre de 2021.

Cuando tengo un mal día, o pasa algo de mierda y nada quiere salir como lo había planeado, suelo recurrir a una de dos cosas.

O salgo a correr hasta perderme por completo en el momento, o me siento a escribir lo que me pasa por la cabeza.

Por desgracia, se espera que una tormenta toque tierra en nuestra zona y no me apetecía quedarme atrapado por ahí cuando empezara el aguacero.

Antes sí pude saltar un rato a la cuerda en la zona de la piscina de mi edificio.

Y, mientras buscaba el equilibrio entre saltos, mi mente decidió pasar una presentación continua de todo lo ocurrido durante los últimos seis meses.

Como al empezar cada año, solemos ser optimistas y pensar que los próximos 365 días traerán algo mejor.

Al menos así me imaginaba 2021.

No esperaba que todo volviera de pronto a la normalidad, claro. Seguíamos en plena pandemia, y salir sin mascarilla todavía quedaba bastante lejos.

Los países empezaban a abrirse y a relajar algunas restricciones conforme avanzaba la vacunación, aunque seguía habiendo muchas limitaciones en todas partes.

Aquí también se vacunaba a la gente, pero a un ritmo mucho más lento y dando prioridad a quienes más lo necesitaban.

Por mi parte, ninguna queja.

Pudimos registrarnos para la vacunación a través del gobierno local, así que solo nos quedaba esperar nuestro turno.

En fin.

Volviendo al tema.

Terminé mi primer reto #100DaysOfCode el 14 de febrero.

Con la sensación de haber ganado, decidí empezar otra ronda de inmediato.

Al día siguiente volvió a ser el día 1.

Después, el día 2.

El día 3.

Hubo algunos baches, pero seguí adelante. Entonces alguien me contactó por una oportunidad para un puesto nuevo en su empresa. No estaba pensando seriamente en cambiar de trabajo, pero me pareció que no perdía nada por escuchar.

Una persona de selección me llamó e hicimos una breve entrevista inicial.

No estaba demasiado preparado, así que probablemente dejé fuera algunos puntos importantes que debería haber mencionado.

Después no volvieron a llamar.

Y, sinceramente, no me preocupó, porque poco después me contactaron otras dos empresas.

En su momento no lo admití, pero aquellas llamadas sí alimentaron un poco mi ego.

Sabía que probablemente buscaban a alguien con mucha más experiencia, y yo todavía me veía en un punto intermedio en cuanto a capacidades.

He aprendido mucho trabajando en distintos sectores durante los últimos cinco años, pero también sé que aún estoy lejos de ser un experto.

Aun así, decidí intentarlo.

Pasé las entrevistas telefónicas, renové mi perfil, actualicé todo y empecé a enviar candidaturas.

Luego me enganché a las reuniones y entrevistas con distintas empresas después del trabajo.

Al final, dejé mi #100DaysChallenge y me concentré en esas reuniones.

Los dos «casi»​

Llegué bastante lejos en el proceso con dos empresas distintas.

Un puesto se centraba en automatización de infraestructura con AWS.

El otro era de soporte de Docker y Kubernetes.

Ambos parecían prometedores.

Ambos mostraban interés.

Valoré con cuidado mis posibilidades en cada uno y, después de varias conversaciones con mi esposa, decidí que estaba listo para dar el paso hacia algo nuevo.

En ese momento solo quedaba una cosa por hacer. Esperar.

Así que esperé.

Y pasó una semana.

Por fin llegó una oferta para el puesto de soporte.

Por desgracia, era inferior a lo que esperaba, y no quería dejar las oportunidades que ya tenía en mi trabajo para ir a otro sitio con unas condiciones casi iguales.

Había tenido buenas conversaciones con tres responsables de equipo distintos, y me dieron la impresión de que de verdad querían que me incorporara.

Lamentablemente, la persona de selección terminó diciéndome que no continuarían con mi candidatura.

Eso dolió un poco.

Por supuesto, entiendo que una empresa tiene todo el derecho a reconsiderarlo si deja de ver sentido en la contratación.

Le comenté mi preocupación a la persona con la que llevaba más de un mes coordinándome, pero ya intuía que habíamos llegado al final.

Así que le agradecí toda su ayuda y seguí adelante.

Además, todavía me quedaba otra oportunidad.

O eso creía.

La segunda se alargó casi dos meses y exigió muchos mensajes de seguimiento.

Cada vez que preguntaba, me decían que la dirección seguía revisándolo todo.

Así que esperé. Y seguí esperando.

Para entonces, ya había dejado de atender a otros posibles empleadores porque me había centrado casi por completo en esta oportunidad.

Sabía que no debía hacer planes alrededor de una decisión que todavía podía cambiar.

Pero tenía buenas sensaciones sobre cómo había ido la entrevista con el panel técnico.

Tres semanas se convirtieron en cinco.

Cinco en siete.

En la octava semana contacté a mi amigo, que trabajaba allí y me había recomendado para el puesto.

Le pregunté si había sabido algo de la persona de selección.

Recibió exactamente la misma respuesta que yo.

A la semana siguiente me escribió.

Habían decidido dejar mi perfil en espera por el momento.

Eso sí fue devastador.

Con las dos oportunidades perdidas, volvía a la casilla de salida.

Ya había pasado por muchos rechazos.

Y cuando digo muchos, son muchos.

Probablemente he dedicado cientos, quizá miles, de horas a candidaturas y entrevistas desde que terminé la universidad.

¿Pero estos dos?

Joder.

Se sintieron distintos.

Levántate cinco veces​

Intenté volver a mi rutina habitual.

Admito que no fue fácil sacarme de la cabeza esas dos posibilidades que no llegaron a ser.

Entonces enfermé.

Dos veces.

Perdía muchos líquidos y me quedé tan débil que apenas podía funcionar durante casi una semana en cada ocasión.

No quise darle demasiadas vueltas porque acabé recuperándome con medicación, pero en esos dos periodos pasé la mayor parte del tiempo en la cama.

Sin correr.

Sin entrenar.

Sin nada.

Mi cuerpo estaba, básicamente, fuera de servicio.

Con el tiempo me recuperé físicamente.

¿Pero la ansiedad que seguía bullendo debajo de todo?

Esa no desapareció tan fácilmente.

Levántate seis veces​

Al final llegó otra llamada.

Y esta vez me llevé el oro.

Todavía le di muchas vueltas antes de decirles a los equipos de mi trabajo que me marchaba para tomar otro rumbo.

Todos fueron increíblemente amables.

Mis compañeros y responsables fueron cálidos, generosos y me apoyaron.

La verdad es que, de haber podido, probablemente me habría llevado a algunos compañeros conmigo.

Cambiar es difícil.

Cambiar es incómodo.

Pero, a veces, cambiar es necesario para crecer.

Levántate siete veces​

Unos días antes de mi última semana de trabajo, volví a enfermar.

Esta vez fueron los ojos.

No entraré demasiado en los detalles, pero afectó seriamente a mi productividad.

Por esas fechas intenté reiniciar otra vez mi reto #100DaysOfCode.

Y, una vez más, tuve que abandonarlo porque todo lo que estaba pasando me tenía demasiado desorientado.

Entonces, como si la vida no nos hubiera dado ya bastante, a mi esposa le diagnosticaron nódulos en dos partes distintas del cuerpo.

Naturalmente, estábamos preocupados.

Esperábamos que el médico nos dijera que bastaba con vigilarlos de momento o que recetara alguna medicación.

En lugar de eso, nos dijeron que había que extirparlos.

Lo que siguió fue una tarde entera corriendo de un sitio a otro para hacer pruebas de laboratorio y entregar todos los documentos necesarios.

Al día siguiente estábamos en una habitación de hospital.

Por suerte, nuestro seguro médico cubría los gastos.

En ese momento, lo único por lo que teníamos que preocuparnos era por cómo saldría la operación.

Levántate ocho veces​

Han pasado casi cuatro días desde que salimos del hospital y volvimos a casa.

Mi esposa está mucho más fuerte, aunque los puntos todavía están cicatrizando.

Mis ojos también se están recuperando.

Si el tiempo acompaña, quizá mañana por la mañana vuelva a intentar correr.

Y, en medio de todo lo ocurrido, también conseguí aprobar el examen de certificación AWS SysOps Associate.

Ahora estoy en el día 3 de mi nuevo trabajo.

Hace seis meses, probablemente no habría creído a nadie que me dijera que así sería mi primera semana en una empresa nueva.

Empezar un trabajo mientras estoy completamente ocupado con lo que pasa en casa.

Siempre me he dicho que, al entrar en un entorno nuevo, quiero dedicarle toda mi atención, sin dividirla.

Bueno.

Hasta ahí llegó aquel plan.

Por mucho que fastidiara recibir un golpe tras otro durante los meses anteriores, no puedo decir que fueran los peores días de nuestra vida.

Hemos pasado por cosas peores.

Aunque, desde luego, recibimos una buena paliza.

Pero lo superamos, ¿no?

Vaya si aquellos baches me obligaron a frenar más veces de las que quería.

A veces no tienes opción.

Bajas el ritmo.

Te reorganizas.

Recargas energías.

Recuperas el aliento.

Usa el verbo que quieras.

Y, por extraño que parezca, a veces el universo sí parece echar una mano cuando todo empieza a pesar demasiado.

No espero que, a partir de ahora, todo vaya sobre ruedas.

Probablemente no será así.

Lo que sí sé es que intentaré resolver lo que tenga solución.

Aceptar las pérdidas cuando haga falta.

Recibir los golpes.

Y después levantarme.

A la octava.

A la novena.

O a la centésima.

Las veces que haga falta.

Si has leído hasta aquí, quiero darte las gracias de corazón.

Sé que este suele ser un espacio para temas técnicos, pero quería compartir una parte de mí que no se limita al trabajo, los estudios, las certificaciones o la programación.

A veces también está todo lo que ocurre entre una cosa y otra.

Borrador de noviembre de 2021.

Y ese, creo, es el verdadero cambio de mentalidad: pasar de ser alguien que aprende a alguien que resuelve problemas.

Me di cuenta de que, una vez que terminas un curso, aprendes lo básico y empiezas a trabajar en proyectos reales, rara vez vuelves a ver una sección entera del curso solo porque tenga relación con el problema que intentas resolver.

En su lugar, sueles hacer una de dos cosas.

O bien:

a. Revisas tus apuntes o documentación para comprobar si ya te has encontrado con ese problema, siempre que confíes lo suficiente en tus notas, o

b. Tomas el camino mucho más fácil y rápido: buscar en Google, en Stack Overflow o un caso parecido en YouTube.

Por eso creo que los cursos estructurados son muy útiles durante la etapa de descubrimiento.

Te presentan la tecnología, explican la terminología, muestran cómo se conectan las cosas y te dan una idea de con qué estás tratando.

Pero, cuando intentas utilizar esa tecnología para resolver tus propios problemas, las cosas cambian.

En ese momento suele entrar en juego el instinto.

Buscas el error en Google y esperas que alguien ya haya hecho exactamente la misma pregunta en Stack Overflow.

O quizá alguien subió hace tres años un vídeo de doce minutos a YouTube que, de alguna manera, resuelve justo tu problema.

También he notado que los cursos pueden quedarse obsoletos bastante rápido, sobre todo cuando las tecnologías avanzan a un ritmo muy, muy acelerado.

Se me ocurren ejemplos de la computación en la nube de AWS (puedes saltarte la lista si no te interesan los detalles):

1. Un día, los límites de EC2 se expresan como un número fijo de instancias por región.
2. Después, se basan en la cantidad de vCPU que puedes ejecutar.
3. Un día, ZooKeeper es una pieza importante de la arquitectura que estudias.
4. Después, las versiones más nuevas de la tecnología empiezan a prescindir de él por completo.

A veces el cambio es importante.

A veces solo es un botón que ha cambiado de sitio en la interfaz.

Pero, cuando sumas todos esos pequeños cambios a todo lo demás que ya intentas aprender, empiezan a pesar bastante.

Un día quizá tengas varias semanas para experimentar con esa fascinante tecnología que acabas de descubrir.

Y al siguiente alguien te dice que tienes dos semanas para entenderla y entregar una solución mínimamente utilizable.

Así que sí.

Las cosas cambian bastante rápido.

Supongo que lo que quiero decir es que tardé casi cuatro años, y sinceramente todavía sigo trabajando en ello, en alejarme de esa forma de aprender estructurada, al estilo universitario, y adaptarme más a cómo se adquiere el conocimiento en la industria.

Cuando digo aprendizaje al estilo universitario, me refiero a aquel en el que tienes un esquema claro que seguir.

Empiezas con los primeros pasos.

Quizá abres tu primera terminal.

Luego aprendes los comandos.

Después los conceptos se van complicando.

Y acabas llegando a las partes más difíciles.

Normalmente sabes qué intentas aprender, cuál es el problema y qué debes lograr antes de pasar a la siguiente lección.

La industria no siempre funciona así.

A veces solo te dan una lista de requisitos.

Y ya está.

Nadie te entrega una lista ordenada de todas las tecnologías que debes aprender de antemano.

Te toca averiguar qué herramientas necesitas.

A veces ni siquiera te dan un problema técnico claramente definido.

Primero tienes que descubrir qué preguntas hay que hacer.

Y luego empiezas a buscar las respuestas.

Supongo que esto entra dentro de lo que se llama problemas mal definidos, donde no siempre existe una solución perfecta o única.

Durante mi trabajo anterior y ahora en el actual, he aprendido mucho sobre cómo se construyen realmente las soluciones.

Puede que tengas ayuda de un proveedor.

Puede que trabajen contigo servicios profesionales externos.

Puede que haya documentación, arquitectos, ingenieros y otros equipos implicados.

Pero, al final, te das cuenta de que resolver problemas no siempre es tan sencillo como parece desde fuera.

De repente, unas tareas pasan a ser más importantes que otras.

Puede surgir algo del lado del negocio a mitad del sprint.

Cambia un requisito.

Se mueve una fecha límite.

Aparece una dependencia.

Y ahora tienes que replantearte cuál de las diez preguntas que tienes delante necesita respuesta primero.

Así que aprender en la industria puede ser bastante desordenado.

Buscas lo que necesitas en ese momento.

Lo pruebas enseguida en tu entorno de pruebas.

Si funciona, genial.

Quizá empiezas a incorporarlo poco a poco al código o a la configuración.

Después vuelves a probarlo.

Revisas los registros.

Ejecutas las pruebas unitarias.

Haces pruebas de aceptación operativa, o cualquier otro proceso de validación que tengas.

Si todo parece correcto y no empiezan a saltar alarmas en los registros, quizá termine llegando a producción.

Ah, y aquí viene la parte divertida:

Tienes que terminar todo esto en cuatro sprints o menos.

Sin presión.

Ahora bien, estas situaciones pueden introducir lo que llamamos deuda técnica.

Suele ocurrir cuando eliges hoy una solución más rápida o más fácil, sabiendo que probablemente tendrás que revisarla o mejorarla después.

¿Es mala la deuda técnica?

Sí.

No.

No lo sé.

Supongo que la verdadera respuesta es: depende.

A veces, sencillamente, no puedes hacer que algo sea perfecto.

Tu solución puede depender de una plataforma gestionada por otro equipo.

Una nueva versión puede cambiar el comportamiento del código.

Otro sistema puede actualizarse.

Los requisitos pueden volver a cambiar.

Siempre habrá factores fuera de tu control.

Y, a veces, poner en marcha una solución que funcione te permite aprender algo que nunca habrías descubierto dedicando otro mes a intentar que todo fuera perfecto.

Cuanto antes falle algo en un entorno controlado, antes podrás entender por qué falló y mejorarlo.

Así que, de una forma extraña, buscamos constantemente maneras de romper cosas de forma segura para averiguar cómo mejorarlas.

Espera. ¿Por dónde iba?​

Ah, sí.

Un cambio en la forma de pensar.

Supongo que he dedicado todo este tiempo a explicar en qué se diferencia el aprendizaje estructurado de aprender cuando ya estás intentando resolver un problema real.

Entonces, ¿debería dejar los cursos y centrarme solo en proyectos?​

No.

Si algo es completamente nuevo para ti, sigues necesitando alguna base.

Y los cursos son muy buenos para eso.

Te dan herramientas básicas que quizá necesites más adelante.

Te muestran lo que es posible.

Te presentan la terminología.

Te dan suficiente conocimiento como para saber, al menos, qué buscar cuando todo se rompa.

Luego, en algún punto del camino, empiezas a usar esas herramientas para responder tus propias preguntas.

A veces seguirás utilizándolas.

Otras descubrirás que la herramienta que aprendiste no es la mejor para el problema que tienes delante.

Así que la dejas y aprendes otra.

Y no pasa nada.

Sigo confundido​

Bueno, no eres el único.

Yo tampoco he resuelto todo esto.

Sigo teniendo en el portátil una cantidad absurda de cursos sin terminar.

Y, como el tiempo es limitado, he ido desarrollando mi propia estrategia para aprender cosas y aplicarlas de verdad.

Si mi objetivo es hacer un examen de certificación, normalmente sigo el curso, hago las prácticas, tomo apuntes y después me preparo con exámenes de prueba.

¿Y cuando apruebo?

Borro el curso.

Sí.

Sin dudarlo.

Llegado ese punto, sé que probablemente no volveré a sentarme a verlo entero.

Si más adelante necesito esa tecnología para un proyecto y me encuentro con un problema, lo más probable es que busque directamente ese problema.

Y, sinceramente, lo prefiero así.

En vez de repasar horas de vídeo, puedo buscar exactamente lo que necesito.

Es un poco como recoger manzanas.

Coges las que necesitas y dejas el resto del árbol en paz.

Lo importante es que, durante la etapa de descubrimiento y repaso, utilicé el curso para construir una base.

Aprendí lo suficiente para conocer la terminología.

Aprendí lo suficiente para comprender los conceptos básicos.

Y, con suerte, aprendí lo suficiente para reconocer lo que no sé.

Después llega la etapa de aplicación.

Ahí empiezo a depender más de mis propias herramientas.

Mis apuntes.

La documentación.

Los experimentos.

Y, por supuesto, mi Google-fu.

Ahora mismo estoy preparándome para hacer el RHCSA el año que viene.

Así que, para entonces, espero haber eliminado la mayoría de los cursos de RHEL que tengo en el disco duro.

Al borrarlos, también me obligo a pensar por mi cuenta en vez de volver constantemente a copiar los pasos exactos del instructor.

Si quiero recordar cómo hice una práctica, consulto mis apuntes.

Si no está ahí, probablemente esté en algún lugar de la documentación oficial.

¿Y si tampoco está?

Bueno.

Google seguramente conoce a alguien que lo sabe.

Vale, creo que lo he entendido​

Si es así, probablemente ya me lleves un paso de ventaja.

Repito: no tengo todas las respuestas.

La mitad del tiempo ni siquiera sé todavía cuáles son las preguntas correctas.

Pero espero ir entendiendo más a medida que continúe.

Haré más prácticas.

Romperé más código.

Seguiré más registros en tiempo real.

Probaré soluciones que no funcionen.

Y acabaré encontrando otras que sí.

Después documentaré lo ocurrido para, quizá, no tener que sufrir dos veces el mismo problema.

Y, en algún punto de ese proceso, algo cambia.

Dejas de preguntar únicamente: «¿Qué debería aprender ahora?».

Y empiezas a preguntar: «¿Qué necesito para resolver esto?».

Ese, creo, es el verdadero cambio de mentalidad.

Pasar de ser alguien que aprende a alguien que resuelve problemas.

Y quizá, después de resolver suficientes problemas, acabes entrando en otra forma de aprendizaje:

Transmitir lo que has aprendido a otra persona.

Tercera vez que termino este audiolibro.

La primera fue justo después de terminar la universidad. La segunda, más o menos un año después. Y la tercera fue la semana pasada.

Lo que me llamó la atención esta vez, y que me parece increíble, es cuánto ha cambiado mi perspectiva sobre el libro con los años.

El libro seguía siendo el mismo.

Yo no.

La primera vez que lo escuché, muchas de las historias me parecían intensas, impresionantes y quizá un poco lejanas a mi situación. Años después, algunas de esas mismas partes empezaron a tener más sentido porque había vivido más trabajo, más incertidumbre, más malas decisiones, más presión y más momentos en los que no había una respuesta evidente.

Creo que esa es una de las mejores cosas de volver a un libro así. A veces no es que lo «superes». Simplemente, por fin llegas a comprender algunas de sus partes.

¿La mejor lección?

Haz preguntas realmente buenas.

¿Y cómo se aprende a hacer preguntas realmente buenas?

Haciendo primero un montón de preguntas malas.

Equivocándote.

Pasando cosas por alto.

Preguntando algo obvio.

Dándote cuenta después de que deberías haber preguntado algo completamente distinto.

Con el tiempo, aprendes a reconocer qué preguntas importan de verdad.

Y sí, a veces una jodida buena dosis de valor puede abrir caminos y mover montañas.

• Vincent van Gogh

¿Ser generalista o especialista?

Antes pensaba que tarde o temprano había que elegir.

Pero después de leer Range, de David Epstein, creo que la respuesta más interesante es que quizá no tengas que apresurarte a hacerlo.

Explora distintos campos.

Siente curiosidad por cosas que estén fuera de tu terreno habitual.

Prueba algo, déjalo, vuelve a ello años después y, a veces, te sorprenderá lo útiles que resultan esas experiencias aparentemente inconexas.

Y cuando encuentres algo que de verdad despierte tu interés, profundiza.

Aprende las tecnologías que lo componen.

Entiende cómo funcionan las cosas por debajo.

Domínalo lo suficiente como para poder construir, romper, arreglar y explicar cosas.

Pero tampoco tienes que pasarte la vida entera con el pie en el acelerador.

A veces puedes bajar el ritmo.

Dejarte llevar un rato.

Mirar a tu alrededor.

Probar otra cosa.

Y luego volver con una perspectiva distinta.

Quizá ser generalista y ser especialista no sean realmente opuestos. Puedes explorar muchos campos y, al mismo tiempo, profundizar en lo que te importa.

Y, a medida que el mundo a tu alrededor cambie, parte de lo que sabes se volverá útil, parte quedará obsoleta y algunas cosas tendrás que replanteártelas por completo.

Aprende.

Desaprende.

Y vuelve a aprender.

Comparto mis apuntes y reflexiones sobre el examen AWS SysOps Administrator Associate.

Antes que nada, quiero decir que resulta sumamente útil presentarse primero al examen AWS Solutions Architect Associate antes de abordar los otros dos exámenes de nivel Associate: SysOps Associate y Developer Associate.

Hacer primero el examen de Solutions Architect te ayuda a entender cómo funcionan los distintos servicios de AWS, cómo se conectan y cómo se utilizan para construir soluciones.

Como con cualquier habilidad, creo que es importante empezar por lo básico.

Aprende la teoría.

Experimenta.

Rompe cosas.

Y después intenta arreglarlas.

Una vez que entiendes bien cómo se diseñan las soluciones, puedes empezar a aprender a operarlas y mantenerlas.

Y ahí entra AWS SysOps Administrator Associate.

Para darte algo de contexto, empecé mi carrera en redes informáticas, trabajando con routers, switches y herramientas de gestión de redes.

También pasé un breve periodo en soporte de aplicaciones en una empresa de tecnología financiera, y en mi anterior trabajo tuve la oportunidad de trabajar con servidores Linux.

En conjunto, diría que soy más bien alguien de infraestructura con un poco de programación.

Aunque todavía sigo en construcción.

Me quedan muchas tecnologías por aprender, así que intento participar en tantos proyectos de Linux y Python como puedo.

La automatización sigue siendo un concepto relativamente nuevo para mí, pero poco a poco me siento más cómodo creando mis propios scripts y procesos.

Mi recorrido por AWS empezó con el examen AWS Cloud Practitioner en agosto pasado.

Luego, 29 días después, me presenté al examen AWS Solutions Architect Associate.

Después puse la mira en SysOps.

Por desgracia, en ese momento había otras cosas del trabajo que requerían mi atención, así que tuve que aparcar los estudios de SysOps un tiempo.

Retomé el repaso entre enero y febrero y decidí empezar a publicar mis apuntes en GitHub.

Por esas fechas también surgieron algunas dificultades personales en casa que me frenaron un poco.

Aun así, intenté recomponerme, seguir adelante con la misión y fijarme el objetivo de hacer el examen en marzo.

Poco sabía entonces que acabaría posponiéndolo otros dos meses.

En mi primer intento tuve problemas con la conexión a internet y el supervisor canceló el examen mientras esperaba a que se cargara la ventana de la prueba.

Ya había hecho varios exámenes de certificación en línea con Pearson VUE, pero era la primera vez que cerraban uno sin avisarme antes.

Informé del problema y, unos cuatro días después, me devolvieron tanto el importe del examen como el cupón que había utilizado.

Como iba algo justo de presupuesto, esperé a recibir el reembolso antes de programar el segundo intento.

Y llegó el 24 de mayo.

Preparé el escritorio de casa, despejé la mente y me senté a hacer el examen.

La verdad es que recé con ganas para que esta vez todo funcionara, porque ya había dedicado muchísimo tiempo a prepararlo.

Tras unos 48 minutos, envié la respuesta a la pregunta 65.

Unos clics más tarde, apareció el resultado delante de mí.

RESULTADO: APROBADO

Y, vaya, qué bien sabe esa victoria.

Apuntes que quizá te ayuden​

Por supuesto, es bastante probable que hayas encontrado este artículo buscando apuntes y consejos para preparar el examen AWS SysOps Administrator Associate.

Así que sí, también los incluyo aquí.

Puedes encontrar mis apuntes de GitHub aquí.

No olvides revisar también los resúmenes.

Estos fueron los materiales en los que me centré:

• Ultimate AWS Certified SysOps Administrator Associate 2021 de Stephane Maarek

• (NEW) AWS Certified SysOps Administrator Associate 2021 de Neal Davis

• AWS Certified SysOps Administrator Associate Practice Exams 2021 de Tutorials Dojo

• Documentación oficial de AWS

• Guía del examen AWS SysOps Administrator Associate

Por dónde empezar​

Yo recomendaría empezar por el curso de Stephane Maarek o por el de Neal Davis.

Sinceramente, completar uno de los dos ya debería aportarte mucho.

Yo hice ambos porque tienen enfoques algo distintos y me gustaba la idea de que uno cubriera los detalles que pudiera haber pasado por alto en el otro.

Pero no te limites a ver vídeos.

Asegúrate de pasar tiempo de verdad dentro de la consola de AWS.

Creo que es imprescindible familiarizarse con las pestañas, opciones, menús y ajustes, porque verlos y utilizarlos ayuda a afianzar los conceptos que aprendes en los cursos.

Y, además de seguir las prácticas, intenta romper algunas de las cosas que construyas.

En serio.

Rómpelas.

Y luego averigua cómo arreglarlas.

Así no te limitas a memorizar los pasos de un tutorial. También entrenas tu capacidad para diagnosticar problemas, consultar documentación y aprovechar tus habilidades de búsqueda.

Una vez que hayas terminado el curso y te muevas con soltura por la consola de AWS, puedes pasar a los exámenes de práctica.

Puedes probar los de Maarek y Davis, también disponibles en Udemy, y combinarlos con las pruebas de Tutorials Dojo.

Algo que me gustó mucho de los exámenes de Tutorials Dojo es que cada pregunta viene con una explicación de las respuestas correctas e incorrectas.

No memorices solo qué opción es la correcta.

Lee las explicaciones.

Entiende por qué una respuesta funciona y las otras no.

Hay preguntas en las que más de una respuesta parece razonable a primera vista, así que es muy importante comprender las diferencias.

Por último, complementa los cursos y los exámenes de práctica con la documentación oficial de AWS.

Por supuesto, no podrás leer todas las páginas de documentación de cada servicio.

Probablemente perderías la cabeza intentándolo.

Pero leer la documentación oficial de los servicios y conceptos que te cuestan sí puede ayudarte a cubrir las lagunas.

REFLEXIONES FINALES​

Pensé en poner esta sección al principio porque creo que es algo que deberías tener claro antes incluso de empezar a estudiar.

Hazte todas estas preguntas.

¿Por qué quieres hacer el examen?​

Quizá sea para avanzar en tu carrera.

Quizá quieras aprender una habilidad nueva.

Quizá estés intentando entrar en un puesto relacionado con la nube.

Quizá simplemente sientas mucha curiosidad por AWS.

Sea cual sea tu razón, creo que es importante conocerla, porque determinará cómo afrontas todo el proceso de aprendizaje.

No hagas el examen solo por conseguir la certificación o la insignia​

Está bien tener una certificación, pero, en cualquier puesto relacionado con la nube, tarde o temprano tendrás que respaldarla con habilidades y experiencia reales.

Y la única forma de hacerlo es construir algo.

No tiene que ser enorme.

No tiene que ser una arquitectura disparatada, lista para producción y con veinte servicios de AWS.

Simplemente construye.

Rompe cosas.

Arréglalas.

Vuelve a probar algo.

Manos a la obra.

Yo sigo en esa misma búsqueda, intentando conocer tantas tecnologías de la nube como sea posible.

Y sería estupendo que más personas se subieran al mismo tren.

Aprende por el placer de aprender​

Aprende porque algo te despierta muchísima curiosidad.

Aprende porque hay algo que todavía no entiendes y quieres descubrirlo.

Si consigues mantener esa mentalidad, creo que llegarás lejos en lo que decidas emprender.

¡Y ahora, a disfrutar aprendiendo!

Y llegó el día.

Iniciando sesión por última vez.

Es extraño cómo algo que has hecho casi a diario acaba convirtiéndose en algo que harás por última vez.

Un último inicio de sesión.

Una última mirada a las herramientas, mensajes, tickets, sistemas y todas esas otras cosas que poco a poco se volvieron parte de la rutina.

Una última mirada a Disneyland.

Me llevo mucho de mi tiempo aquí.

Aprendí muchísimo del equipo de Filipinas, especialmente al ver cómo se construyen, mantienen y arreglan las aplicaciones, y cómo a veces se rompen antes de volver a arreglarse.

Aprendí tanto o más del equipo de Estados Unidos. Las redes ya eran un terreno conocido para mí, pero siempre hay una diferencia entre lo que sabes por los libros y las certificaciones y lo que ves cuando todas las piezas funcionan juntas en el mundo real.

Y, por supuesto, también aprendí muchísimo de la Casa del Ratón.

Distintos equipos. Distintas personas. Distintos problemas.

Algunos días fueron tranquilos.

Otros, desde luego, no.

Hubo cosas que entendí de inmediato y otras que me llevaron a pasar horas buscando en Google, leyendo documentación, mirando registros y preguntándome qué demonios se me escapaba.

Pero supongo que es parte del proceso.

No te das cuenta de cuánto has aprendido por el camino hasta que estás a punto de irte y, de repente, empiezas a mirar atrás.

Los sistemas en los que he trabajado, los problemas que he encontrado, las personas de las que he aprendido e incluso los errores que he cometido se han convertido en pequeñas experiencias que me llevaré adonde vaya.

Y ahora toca cerrar este capítulo.

Tomando prestada una frase de Closing Time:

«Todo nuevo comienzo nace del final de otro comienzo».

Así que sí.

A por un nuevo comienzo increíble.

Luego leíste el título y te preguntaste de qué va este blog tan genial.

Bueno, antes que nada, quiero aclarar que esto no trata sobre la emocionante serie de ciencia ficción The 100.

Aunque te recomendaría verla. Seguro que te atrapan su ambiente posapocalíptico, la forma en que la humanidad intenta reconstruir la sociedad y cómo la serie pone a prueba tus ideas sobre el liderazgo y las decisiones cuando apenas quedan buenas opciones.

La verdad es que no empecé a disfrutarla de verdad hasta el cuarto episodio, más o menos.

Y, de alguna manera, acabé aplaudiendo al llegar al final de la quinta temporada.

Dato curioso: el primer episodio de la quinta temporada se llama «Eden».

En fin, ¿por dónde iba?

Ah, sí. De qué trata realmente este artículo tan genial.

Vale, un poco de contexto.

Empecé el reto #100DaysOfCode el 6 de noviembre de 2020, y hoy puedo decir con orgullo que lo he conseguido.

He completado los 100 días.

Entonces, ¿de qué demonios va esto?​

He estado leyendo blogs de desarrolladores y he visto mencionar mucho el reto #100DaysOfCode.

La idea es bastante sencilla.

Programas de forma constante durante 100 días consecutivos y publicas tus avances en Twitter, o en la red social que uses, con la etiqueta #100DaysOfCode.

No hay reglas estrictas sobre qué lenguaje debes usar ni qué tipo de proyectos debes construir.

Solo tienes que seguir haciendo algo cada día durante 100 días.

Como soy un tipo aventurero, reuní todos los cursos que quería estudiar, hice una lista de lo que quería lograr y empecé el día 1 el 6 de noviembre del año pasado.

Incluso escribí un artículo entonces, que puedes leer aquí.

Durante las primeras semanas estaba lleno de entusiasmo.

Seguí con ganas los vídeos y las prácticas de Git for Developers using Github en Coursera, pasé a la introducción de Todd McLeod a Visual Studio Code y después empecé el popular curso de Python de Al Sweigart, Automate the Boring Stuff with Python.

Pude acceder gratis a todos estos cursos gracias a varios cupones de Udemy y a un programa de estudios de Coursera patrocinado por el gobierno.

Así que sí, eso ayudó mucho.

La cuesta arriba​

Por supuesto, sientes esa pequeña oleada de satisfacción cada vez que terminas un cuestionario, una práctica o una etapa del curso.

Por fin aciertas la respuesta.

Terminas el ejercicio.

Ves esa pequeña marca verde.

La vida es buena.

Luego está la otra cara.

Llegas a una práctica que no consigues superar porque es condenadamente difícil.

Pasas horas intentando resolverla, decides dejarla hasta después de dormir, te despiertas a la mañana siguiente, abres exactamente la misma práctica...

Y sigues atascado.

Solo que en otro día.

También ves la madriguera, pero nunca llegas al fondo​

Otra cosa que me resultó agotadora fue lidiar con problemas inesperados.

Cada vez que algo no funcionaba, buscaba el error en Google, abría los primeros tres o cinco enlaces y empezaba a probar las soluciones sugeridas.

A veces funcionaba alguna.

La mayoría de las veces, una solución solo me daba un mensaje de error completamente distinto.

Así que, naturalmente, también buscaba ese nuevo error.

Luego leía otros cuantos enlaces.

Veía un vídeo en YouTube.

Probaba otro comando.

Recibía otro error.

Volvía a buscar.

Y, antes de darte cuenta, has caído hasta el fondo de una madriguera.

Solo querías resolver un problemita, pero, de alguna manera, has descubierto otros cinco por el camino.

Pero ¿sabes qué?

De tanto excavar en madrigueras salió algo bueno.

Empecé a darme cuenta de cuándo los problemas nuevos me estaban alejando poco a poco del que realmente quería resolver.

Y, cuando eso ocurría, aprendí a parar, ordenar mis ideas y preguntarme si de verdad necesitaba seguir excavando.

Un ejemplo fue cuando un instructor de KodeKloud estaba instalando Docker en su máquina Ubuntu mientras yo usaba una instancia EC2 con RHEL 8.

Me apareció un error al utilizar uno de los scripts de instalación rápida del sitio de Docker.

La verdad es que ya no recuerdo el error exacto.

Pero tenía la sensación de que podía estar relacionado con RHEL 8.

Nunca llegué a confirmarlo porque, en vez de seguir buscando el error en Google, decidí comprobar si AWS tenía una AMI de RHEL 7 disponible.

Por desgracia, no la tenía.

Así que probé con CentOS.

¿Y sabes qué?

Todo funcionó.

Así que supongo que, con el tiempo, desarrollas una especie de extraño sentido sobrehumano para detectar cuándo un problema está a punto de llevarte por una madriguera interminable de mensajes de error.

Entonces decides si merece la pena seguir por ahí o si existe otra forma de llegar a donde necesitas sin perder otras tres horas.

Por cierto, en algún momento también aprendí el término deuda técnica.

Aunque no diría que se aplica a todas las situaciones de este tipo.

Lo que sí aprendí es que no deberías dejar que se acumule indefinidamente, porque tarde o temprano volverá para darte una buena mordida en el trasero.

Quizá algún día haga una pequeña búsqueda para averiguar por qué aquel script de Docker no funcionaba en RHEL 8.

Ya sabes.

Para cerrar el tema.

La realidad se hace sentir​

Pasaron unas semanas y llegó mi primer bajón.

Seguía haciendo prácticas, pero ya no terminaba tantas como antes.

Había mucho trabajo en ese momento, y el esfuerzo mental adicional de estudiar y hacer prácticas por mi cuenta empezaba a pasar factura.

Así que reduje la actividad durante unos días.

Por mucho que quisiera parar y descansar del todo, ese pequeño cabr*n dentro de mi cabeza no me dejaba abandonar el reto.

Tampoco pude seguir el plan original del día 1.

Por ejemplo, al final no hice otro curso de desarrollo web porque decidí centrarme más en la automatización.

El segundo y tercer mes fueron una especie de montaña rusa.

En total, tuve unos tres periodos en los que bajé mucho el ritmo.

Y debo admitir que hubo bastantes dudas durante aquellos 100 días.

Hubo momentos en que me pregunté de verdad si todo ese esfuerzo serviría para algo.

Quizá estaba perdiendo el tiempo.

Quizá nada de esto me ayudaría.

Quizá las cosas no saldrían como esperaba.

Y, por extraño que parezca, no intenté expulsar esos pensamientos por completo.

Les di espacio.

Dejé que se quedaran en mi cabeza.

Pero, de alguna manera, había una versión testaruda de mí que se negaba a tirar la toalla.

¿Y sabes qué?

Consiguió vencer esos miedos cada vez.

Para cerrar este capítulo​

Ahora que por fin han terminado los 100 días, he repasado todos mis tuits desde el principio y me he permitido descansar un poco.

Sé que no he producido una enorme cantidad de proyectos.

Pero, al mirar atrás, sí aprendí mucho sobre Linux, Python, Git, automatización e incluso sobre mi manera de abordar los problemas en general.

Y, por extraño que parezca, después de todo, los 100 días se me hicieron cortos.

Por eso he decidido emprender otra aventura.

Segunda ronda del reto #100Days.

Solo que esta vez me lanzo a dos retos a la vez:

• #100DaysOfCode
• #100DaysOfFit

El #100DaysOfCode continuará, básicamente, donde acabó la primera ronda, pero esta vez me limitaré a temas más relacionados con mi trabajo actual:

• Apache Kafka
• Docker y Kubernetes
• Python para automatización
• AWS SysOps, aunque esto es más bien un objetivo personal

Luego está #100DaysOfFit, que en realidad son dos retos más pequeños que decidí unir:

• 100 días de ayuno: mantener un ayuno de 16 horas de forma constante
• 100 días corriendo: correr al menos 30 minutos, al aire libre o en una cinta

De nuevo, no espero que todo vaya como la seda durante los próximos 100 días.

Será difícil.

Probablemente me sentiré abrumado de vez en cuando, sobre todo cuando la vida decida intervenir.

Seguramente volveré a atascarme con otro problema.

Seguramente pasaré tardes enteras enterrado en documentación.

Y sin duda habrá días en los que me dé demasiada pereza leer y decida ver vídeos de YouTube.

Probablemente surgirán muchas preguntas al empezar otra vez.

Pero espero que al final también me esperen menos «¿y si...?».

«Puedes hacerlo. Deberías hacerlo. Y si eres lo bastante valiente para empezar, lo harás».

• Stephen King

Me he dado cuenta de que el deseo de aprender a veces puede chocar de frente con el deseo de estabilidad.

Queremos sistemas fiables. Predecibles. Tranquilos.

Queremos que las cosas funcionen tan bien que nadie tenga que pensar en ellas.

Pero entonces llega alguien con una función nueva, un requisito nuevo, una forma mejor de hacer algo o, quizá, simplemente una pregunta:

¿Podemos mejorar esto?

Y la respuesta casi siempre es sí.

¿Llegaremos alguna vez a un punto en el que no quede absolutamente nada por mejorar?

Probablemente no.

Mientras haya personas usando un servicio, encontrarán nuevas maneras de utilizarlo, nuevos problemas con los que tropezar y nuevas cosas que esperar de él.

Lo curioso es que mejorar algo a menudo implica alterar lo que ya funciona.

Cambias el código.

Sustituyes un componente.

Mueves algo a otro lugar.

Pones a prueba una suposición y descubres que era incorrecta.

A veces rompes cosas.

Y, por extraño que parezca, de ahí viene buena parte de la emoción.

Hay algo satisfactorio en encontrar ese punto débil de un sistema, averiguar por qué falló, reunir los datos y construir poco a poco una solución a su alrededor.

Lo arreglas.

Lo haces más resistente.

Lo proteges.

Y, con el tiempo, encuentras lo siguiente que necesita atención.

Todavía me quedan muchas cosas por romper y arreglar.

Muchas por construir y reconstruir.

Muchas más por mover, sustituir, mejorar y, probablemente, volver a romper.

Y, sinceramente, disfruto viendo ese proceso.

Ver cómo algo empieza como una prueba de concepto rudimentaria y crece poco a poco hasta convertirse en algo real, estable y útil en producción.

Quizá ese sea el extraño equilibrio de la ingeniería.

Pasas la mitad del tiempo intentando que las cosas sean estables.

Y la otra mitad cambiándolas antes de que se acomoden demasiado.

Me encontré con esto al intentar instalar htop en una de mis instancias EC2 de pruebas con RHEL. Estaba siguiendo los pasos de esta guía.

Esto también me llevó a aprender un poco más sobre los procesos defunct, o zombis, en Linux. Puedes leer más sobre ellos aquí.

Qué ocurrió​

Tenía dos terminales abiertas, ambas conectadas a la misma instancia EC2.

En la primera estaba ejecutando:

yum update -y

Mientras seguía la actualización, intenté instalar otro paquete desde la segunda terminal.

Apareció este mensaje:

Running transaction check
Waiting for process with pid 5941 to finish.

Así que comprobé qué proceso estaba usando el PID 5941:

$ ps -ef | grep 5941

root        5941    5939 18 06:00 pts/0    00:01:42 yum update -y
root       36173   36153  0 06:09 pts/2    00:00:00 grep --color=auto 5941

Efectivamente, el PID 5941 correspondía al proceso yum update que se ejecutaba en la primera terminal.

Como la actualización estaba tardando, decidí cancelarla para instalar primero los paquetes que necesitaba y volver a ejecutarla después.

Pero, al intentar instalar de nuevo el paquete, seguía apareciendo el mismo mensaje sobre el PID 5941.

Al revisar otra vez el proceso, vi algo distinto:

$ ps -ef | grep 5941

root        5941    5939 18 06:00 pts/0    00:01:42 [yum] <defunct>

El proceso yum aparecía ahora como <defunct>.

Naturalmente, lo primero que pensé fue:

kill -9 5941

Problema resuelto, ¿no?

Pues no exactamente.

El proceso seguía apareciendo como <defunct>.

¿Qué significa <defunct>?​

Un proceso marcado como <defunct> ya ha terminado de ejecutarse.

En otras palabras, técnicamente ya no queda nada que terminar.

Cuando un proceso hijo finaliza, su proceso padre debe recoger su estado de salida. Hasta que lo hace, Linux conserva una pequeña entrada del hijo en la tabla de procesos.

Esa entrada restante es lo que llamamos un proceso zombi.

Y, al ejecutar ps, los procesos zombis suelen mostrarse así:

<defunct>

Por eso ejecutar:

kill -9 PID

no lo elimina.

El proceso ya está muerto. SIGKILL no tiene nada que terminar.

Qué hacer​

Primero, localiza el proceso padre del proceso defunct.

Puedes usar:

$ ps -ef | grep defunct

UID          PID    PPID  C STIME TTY          TIME CMD
root        5941    5939  6 06:00 pts/0    00:01:42 [yum] <defunct>
eden       36210    6097  0 06:24 pts/2    00:00:00 grep --color=auto defunct

Las columnas importantes son estas:

PID     PPID
5941    5939

5941 es el proceso zombi.

5939 es su proceso padre.

Antes de terminar nada, conviene comprobar qué es exactamente ese proceso padre:

ps -fp 5939

Si se puede finalizar de forma segura, puedes intentar detenerlo normalmente:

sudo kill 5939

Después, vuelve a comprobarlo:

ps -ef | grep defunct

Si el padre se resiste a terminar y estás seguro de que es seguro finalizarlo, puedes recurrir a SIGKILL como último recurso:

sudo kill -9 5939

Una vez que finalice el proceso padre, normalmente otro proceso, como init o systemd, debería adoptar y recoger el zombi.

Algo que conviene recordar​

No ejecutes kill -9 de inmediato contra todos los procesos que veas.

Sobre todo al tratar con procesos padre, comprueba siempre primero de qué proceso se trata:

ps -fp <PPID>

Un proceso defunct no está consumiendo CPU ni ejecutándose activamente. Es, en esencia, una entrada que espera a que su padre reconozca que ya ha terminado.

Así que, si alguna vez ves:

[process] <defunct>

recuerda:

El proceso ya está muerto. Lo que realmente debes investigar es su padre.

Referencias​

• Cómo instalar htop en RHEL 8 usando yum
• ¿Qué es un proceso defunct y por qué no se puede terminar?
• ¿Procesos zombi frente a procesos defunct?

DÍA 1: ¿Por dónde empezar?

El reto #100DaysOfCode es uno de esos objetivos que he pospuesto varias veces, ya fuera por falta de tiempo o por alguna carga de trabajo que tenía pendiente.

De hecho, hubo algunas veces en las que empecé el reto y lo dejé después de una semana porque, bueno, sencillamente todavía no sabía lo suficiente.

Lo que quiero decir es que mi forma de aprender nunca fue muy estructurada. En vez de estudiar los fundamentos de una habilidad, solía saltar directamente a lo que necesitaba para resolver el problema que tenía delante.

Y sí, es una manera eficiente de hacer que algo funcione rápido. Pero no es demasiado sostenible. Tarde o temprano, la falta de bases te alcanza.

Puede que consigas resolver un problema, pero, cuando algo vuelve a fallar, de pronto te das cuenta de que no entiendes del todo por qué funcionó aquella solución.

No puedes saltarte el proceso​

Otra cosa que siempre se ha interpuesto es mi propia manera de pensar.

Era más joven, tenía poca experiencia, pero mucho entusiasmo y empeño para lanzarme a los retos sin revisar antes qué hacía falta.

De verdad: de niño era divertido enfrentarse a cualquier cosa que te lanzara el mundo, porque así se enfrentan los niños a las cosas. Sin tonterías. Sin complicarse. Solo por diversión.

Pero, de adulto, o al menos de veintitantos, no siempre puedes agarrar un problema e intentar resolverlo sin examinarlo con cuidado primero. Para empezar, nuestras acciones tienen consecuencias.

Por pequeño que creamos que es un efecto, el verdadero problema comienza cuando esos efectos se encadenan y bajan como una bola de nieve por una montaña empinada.

Un día crees que no necesitas aprender estructuras de datos y algoritmos porque ya has conseguido montar un script con fragmentos de varias fuentes de internet.

Y al día siguiente te encuentras de frente con un problema que nadie ha preguntado todavía en Stack Overflow.

No puedes saltarte el proceso.

Puede parecer que aprender algo bien lleva más tiempo, pero oye, no se mueven montañas a la fuerza. Lo que haces es dividir el Everest en sus piezas más pequeñas y moverlo piedra a piedra.

Cambiar de lugar​

He pasado a puestos para los que estaba solo parcialmente cualificado o, sinceramente, para los que no estaba cualificado en absoluto.

Supongo que el entusiasmo y la perseverancia me ayudaron a conseguir esos trabajos, pero he aprendido que los fundamentos siempre vuelven. Estás investigando un problema y, de pronto, otra vez estás buscando lo básico en internet.

Bueno, quizá exagero un poco cuando digo que nunca me preocupé por aprender los fundamentos de nada.

Sí empecé desde lo más básico de redes cuando volví a estudiarlo todo para mi CCNA el año pasado. Fue muy satisfactorio comprender bien las subredes, cómo funcionan las redes y cómo el enrutamiento permite que los datos lleguen a su destino.

Pero también sé que las redes son solo una de las bases que debería tener un profesional de TI.

Y, a medida que descubro más sobre el mundo de DevOps, he aceptado que saber de redes no basta si de verdad quiero tener éxito como ingeniero de DevOps o de la nube.

Por eso empecé a aprender Linux el pasado febrero.

Resultó bastante útil cuando pasé a mi trabajo actual, donde me encargo de algunos de nuestros sistemas de gestión de redes. Todas esas herramientas NMS están alojadas en servidores Linux Red Hat 7 con los que he tenido la suerte de experimentar.

Bueno, sobre todo en los servidores de laboratorio.

Practicar en servidores de producción es, obviamente, un NO rotundo.

Vale, creo que ya basta de historia y de memes.

Ya he dedicado más o menos una hora a investigar en qué me centraré durante este reto y, por supuesto, a buscar los estupendos memes que pondré aquí.

Por ahora, he reducido mi lista a esto:

1. Estandarizar mis convenciones de nombres: Sí, sé que parece algo bastante trivial, pero creo que ayudará a largo plazo, sobre todo si algún día vuelvo a revisar mis archivos antiguos.

2. Linux: Todavía me considero relativamente nuevo en Linux, pero ahora estoy mucho más cómodo trabajando en servidores Linux y en mis máquinas virtuales. Solo han pasado unos meses desde que me metí de lleno, así que todavía queda mucho por aprender.

   Otro buen lugar para practicar Linux es KodeKloud. Entra en www.kodekloud-engineer.com, crea una cuenta e intenta completar tu primera tarea de administración de sistemas.

3. Git: Ya tengo una cuenta de Git y he aprendido a trabajar con mis repositorios locales, pero todavía no sé trabajar bien con GitHub.

   Así que sí, el día 1 será para Git y GitHub.

   Para ello usaré un proyecto guiado de Coursera llamado Git for Developers Using GitHub, que puedes encontrar aquí:

   https://www.coursera.org/learn/git-for-developers-using-github/

4. Python: Entre tantos lenguajes, he decidido centrarme en Python durante, supongo, los primeros 50 días.

   Eso incluirá resolver problemas en HackerRank y trabajar de verdad en proyectos.

   Python es un lenguaje bastante cercano para mí porque llevamos un tiempo con una relación intermitente. Hay temporadas en las que me concentro mucho en hacer cosas con Python y luego paro de repente porque tengo otra carga de trabajo o porque estoy preparando otro examen de certificación.

   Esta vez quiero ser más constante.

   Usaré el certificado profesional Google IT Automation with Python de Coursera:

   https://www.coursera.org/professional-certificates/google-it-automation

Certificado profesional Google IT Automation with Python​

Para volver a aprender Python como es debido, empiezo con el Google IT Automation with Python Professional Certificate de Coursera, que se compone de seis cursos.

La plataforma indica que puede completarse en ocho meses dedicándole unas cuatro horas de estudio a la semana.

Como pienso trabajar en esto a diario, incluidos los fines de semana, y normalmente veo los vídeos al doble de velocidad, mi objetivo es terminar el certificado completo en unos dos meses.

Eso sí, a lo que realmente quiero dedicar más tiempo es a los ejercicios prácticos.

De momento, sigue siendo un plan aproximado.

Si has leído la sección de Python de arriba, esto es solo lo que tengo previsto para la primera mitad de los 100 días.

Para la segunda mitad, quiero trabajar en desarrollo web.

Puede que digas que 50 días son muy pocos para terminar ese curso.

Y sí, probablemente tengas razón.

Simplemente terminaré lo que pueda entre el día 50 y el 100. Lo que quede, lo continuaré en mi próximo #100DaysOfCode.

En definitiva, creo que este reto #100DaysOfCode es, para mí, más bien un reto de constancia.

Quiero comprometerme de verdad con algo y seguir hasta alcanzar cierto nivel de dominio.

Por supuesto, convertirse en experto lleva mucho más de 100 días. Pero creo que estos 100 días pueden, al menos, ponerme en el camino adecuado.

Además, todavía no tengo muy claro dónde publicaré todo esto, porque he abierto mis cuentas de Twitter e Instagram hace poco.

Supongo que usaré ambas.

El problema de Twitter es el límite de caracteres, así que quizá tenga que dividir las publicaciones: poner la primera mitad en el tuit principal y continuar en las respuestas.

O podría publicar todo también en dev.to o Hashnode.

Lo único que me preocupa es si todas las imágenes que pongo aquí se verán bien en esas plataformas.

En cuanto a Instagram...

Sí, eso todavía no lo tengo resuelto.

Y una última cosa: mis próximas publicaciones o tuits probablemente serán mucho más cortos. Serán, sobre todo, actualizaciones sobre cómo fue el reto ese día.

Luego, quizá al final de cada mes, haga un resumen más largo como punto de control y lo publique en dev.to, Hashnode o freeCodeCamp.

Bien.

Entonces, día 1. ¿Por dónde empezar?

Sí.

Git.

Mi forma de entender la programación. También he incluido algunos conceptos fundamentales que creo que todos deberían conocer cuando empiezan a adentrarse en el código.

Para empezar, quiero decirte que has hecho bien en abrir este artículo.

Puede que lleves jugando con el código desde pequeño, o que simplemente hayas seguido una cadena de enlaces interesantes en Google y, de alguna manera, hayas acabado con ganas de aprender más sobre programación.

En cualquier caso, seguramente hay una idea, o más bien una pregunta, rondándote la cabeza:

¿De verdad es fácil programar?

Bueno, intentemos responder esa pregunta de una vez por todas.

Programar es relativamente fácil.

Repítelo conmigo.

Sí, en gran medida, programar consiste en juntar palabras clave e instrucciones en líneas que el ordenador pueda entender, y luego pasar a la siguiente línea.

Algo así como formar una oración.

Pero ¿de verdad es solo eso?

Piensa en cómo formas una oración en inglés. Hay ciertas reglas que debes seguir. Tienes que pensar qué tiempo verbal usar, desde qué punto de vista escribes, dónde van las palabras y con qué signo de puntuación terminar.

La programación funciona de manera parecida.

Tienes unas reglas, un vocabulario y una estructura que debes seguir.

Por supuesto, hay otros conceptos fundamentales que conviene entender antes de empezar a crear tus propios programas.

¿Cómo se dice?​

Cuando empiezas a aprender un idioma nuevo, por ejemplo japonés, puede que esta sea tu reacción al encontrarte por primera vez con los kanji:

Parece complicado, así que debe de ser complicado.

Pero no es tan difícil cuando das los primeros pasos y empiezas a aprender lo básico.

Todo puede resultar confuso y frustrante la primera vez. Pero, cuando empiezas a descomponerlo en piezas y a entender cómo funcionan juntas, las cosas poco a poco cobran sentido.

Y, con el tiempo, se convierte en pan comido.

Lo que vino antes​

Sea cual sea el lenguaje de programación que intentes aprender, notarás que muchos comparten ideas similares.

Los lenguajes suelen crearse para resolver determinados problemas, introducir nuevas formas de hacer las cosas o superar limitaciones de lenguajes anteriores.

Por eso, los lenguajes más nuevos suelen tomar conceptos, técnicas e incluso sintaxis de los antiguos.

Por supuesto, no todos funcionan exactamente igual, pero, una vez que aprendes los fundamentos de un lenguaje, probablemente reconocerás muchos conceptos familiares al pasar a otro.

Así que podría decirse que los lenguajes de programación hablan de formas distintas, pero muchos piensan de manera parecida.

En el fondo​

Como he mencionado, muchos lenguajes comparten los mismos conceptos básicos. La principal diferencia suele ser cómo se escriben o se implementan.

Estas son algunas de las cosas que encontrarás casi en todas partes.

• Sintaxis

  Recuerda que cada lenguaje tiene sus propias reglas.

  Pueden estar influidas por lenguajes anteriores, pero cada uno tiene su propia manera de escribir instrucciones.

  

  Cuando leíste el título de este artículo en inglés, quizá notaste que había algo un poco raro en cómo estaba escrito.

  Si fue así, enhorabuena. Ya entiendes la idea básica de la sintaxis.

  La sintaxis es, en esencia, el conjunto de reglas que te dice cómo debe escribirse algo.

  Entonces, programar sí que es fácil, ¿verdad? 😄

• Variables

  La idea principal de las variables es asociar un valor con un nombre.

  Piensa en una variable como un recipiente con etiqueta en el que puedes guardar información para usarla después.

  Puedes cambiar esos valores, pasarlos de un lugar a otro, compararlos, hacer cálculos con ellos, mostrarlos y utilizarlos a lo largo de tu programa.

  Por ejemplo, en vez de escribir una y otra vez la edad de una persona como 25, podrías asignar ese valor a una variable llamada age.

  A partir de ahí, el programa puede referirse a age cada vez que necesite ese valor.

  

• Mostrar resultados

  Mostrar un resultado consiste, básicamente, en decirle al programa que presente algo como salida.

  Puede ser el resultado de un cálculo, el valor de una variable, un mensaje o prácticamente cualquier cosa que quieras que vea el usuario o el programador.

  Quizá escuches a los programadores decir algo como:

  «El código devolvió este valor».

  Lo que suelen querer decir es que, después de procesar las instrucciones, el programa produjo algún resultado.

  Pero los programas no siempre muestran esos resultados automáticamente.

  A veces el cálculo ocurre en segundo plano y, si quieres ver el resultado, debes indicarle al programa expresamente que lo imprima o lo muestre.

  Probablemente ya viste un adelanto de esto en el ejemplo de variables de arriba.

  

• Comentarios

  Los comentarios son notas que los programadores dejan dentro del código.

  Sirven para explicar qué hace una sección, por qué se escribió de una manera determinada, qué representa una variable o cualquier otra cosa útil para quien lea el código después.

  Y sí, esa persona podrías ser tú dentro de seis meses, preguntándote:

  «¿Por qué demonios escribí esto?».

  El programa no procesa los comentarios como instrucciones.

  Cada lenguaje tiene su propia forma de marcar los comentarios.

  En Python, por ejemplo, puedes poner un # al principio de una línea para indicar que es un comentario y que no debe ejecutarse.

  

• Cadenas de texto

  Antes hablamos de los comentarios y de cómo Python reconoce una línea que empieza con # como algo que no debe ejecutarse.

  Pero ¿y si quieres que tu programa trabaje con palabras u oraciones?

  Ahí entran las cadenas de texto.

  Una cadena es, básicamente, texto almacenado como datos.

  

  Cuando asignas texto a una variable, normalmente lo rodeas de comillas para que el lenguaje sepa que está tratando con texto y no con otra instrucción.

  También puedes combinar cadenas con otros valores mediante el formateo.

  Por ejemplo, si tienes una variable con el nombre de alguien, puedes insertar su valor en una oración en vez de escribir el nombre manualmente cada vez.

• Arreglos

  Un arreglo es, básicamente, una colección de valores agrupados.

  En vez de crear una variable diferente para cada dato, puedes guardar varios valores relacionados en una sola colección.

  Según el lenguaje, estas colecciones pueden contener números, cadenas, objetos o incluso otras colecciones.

  Python, por ejemplo, suele utilizar algo llamado lista para este propósito.

  

  También es importante entender que los valores dentro de estas colecciones ocupan posiciones.

  Así que, si solo quieres un valor concreto, no necesitas recuperar todo. Puedes referirte a su posición, normalmente mediante lo que llamamos un índice.

  Por ejemplo, si tienes una lista de cinco nombres y solo necesitas el primero, puedes acceder directamente a ese elemento.

  Y aquí va algo que al principio puede resultar extraño:

  En muchos lenguajes de programación, la cuenta empieza en 0, no en 1.

  Bienvenido a la programación.

Espera, hay más​

A estas alturas, espero que entiendas mejor por qué digo que programar es relativamente fácil.

Mucha gente se centra de inmediato en esta pregunta:

¿Qué lenguaje de programación debería aprender primero?

Y está perfectamente bien.

Pero creo que es más importante entender los conceptos que los lenguajes tienen en común.

Una vez que entiendes ideas como variables, sintaxis, cadenas, colecciones, condiciones, bucles y funciones, pasar de un lenguaje a otro resulta mucho menos intimidante.

La sintaxis puede cambiar.

Las palabras clave pueden cambiar.

Pero las ideas generales suelen seguir ahí.

Si quieres conocer algunas cosas que puedes explorar antes de adentrarte de lleno en la programación, puedes consultar el curso de Evan Kimbrell en Udemy, Pre-Programming: Everything you need to know before you code.

Desde luego, puedes lanzarte directamente al lenguaje que te interese.

Pero si no tienes un perfil técnico y has empezado a interesarte por la programación hace poco, creo que aprender primero estas ideas básicas puede hacer que todo resulte mucho menos abrumador.

Porque programar en sí no es la parte que da miedo.

Lo difícil suele ser averiguar qué quieres que haga el ordenador y descomponer ese problema en instrucciones que pueda entender.

Cuando te acostumbras a hacerlo, el código empieza a tener mucho más sentido.

Como siempre, ¡que disfrutes aprendiendo!

«Las metas no distinguen a las personas porque, como puedes ver, quienes ganan y quienes pierden suelen tener las mismas metas. La verdadera pregunta es: ¿quién seguirá adelante y estará a la altura?».

En realidad, terminé este libro en octubre, pero con todo lo que pasó durante los últimos dos meses de 2019, solo logré alcanzar la mitad de mi objetivo de leer 100 libros en el año.

Aun así, se siente bien estar de vuelta.

Es hora de sembrar nuevos hábitos para 2020.

«Cuando no puedas ganar siendo mejor, gana siendo diferente».

Haz las preguntas adecuadas​

Cuando te planteen un problema, asegúrate de hacer las preguntas correctas. Puede que al principio no se te ocurran todas porque todavía no dispones de todos los datos, pero, a medida que ganes experiencia, desarrollarás una idea de cómo deberían arrancar los proyectos y acabarás teniendo un conjunto de preguntas habituales para cuando te presenten requisitos de negocio.

Ejemplo:

El responsable del proyecto le dice al equipo:

Necesitamos una función que invierta cualquier cosa que le pasemos.

Las preguntas habituales:

• ¿Qué significa «cualquier cosa»?

  ¿Qué hay que invertir? En el contexto de las estructuras de datos, solo:

  • Cadenas de texto
  • Números
  • Arreglos

  Los diccionarios no tienen un orden bien definido ni índices, por lo que no se pueden invertir. Los siguientes elementos no pueden invertirse:

  • Diccionarios u objetos
  • Booleanos

• ¿Qué hacemos si se pasa otra cosa?

  ¿Cómo debemos manejar entradas que no sean cadenas, números ni arreglos?

• ¿Qué debería devolver la función?

  ¿Debería devolver siempre una cadena? ¿Debería devolver el mismo tipo que recibió?

Divide y vencerás​

Divide un problema grande en partes manejables o problemas más pequeños para que sea mucho más fácil resolverlo. Al descomponerlo, también podemos comprenderlo mejor.

Con el ejemplo anterior, estos serían los pasos para dividir el problema en otros más pequeños:

• Comprobar si el argumento es una cadena, un número o un arreglo
• Implementar la inversión de un número
• Implementar la inversión de una cadena
• Implementar la inversión de un arreglo
• Devolver el valor invertido

Investiga todo lo que necesites​

Al principio, deberíamos intentar resolver los problemas pequeños por nuestra cuenta y con nuestras propias capacidades. Sin embargo, si sigues encontrando obstáculos, conviene recurrir a fuentes externas, como Google o Stack Overflow.

En la práctica, lo normal es ir directamente a Google y comprobar si ya existe una solución al problema.

Escribe pseudocódigo​

Para los problemas más grandes, resulta útil escribir alguna forma de pseudocódigo antes del código real. El pseudocódigo es una descripción informal del código. Por ejemplo:

function reverse(value) 

  if type(value) == string
    reverse_value = reverse string 
    return reverse_value

  else if type(value) == number
    reverse_value = reverse string 
    return reverse_value

  else if type(value) == array
    reverse_value = reverse string 
    return reverse_value

  else
    return "Invalidy input type"

A partir de aquí, puedes usar el lenguaje que prefieras, como Python, y seguir este flujo para crear la función.

El proceso de depuración​

1. Detectar el error

   Darse cuenta de que hay un error. Puede descubrirse:

   • Durante el desarrollo
   • Al probar el software
   • En distintos contextos: navegadores, usuarios, etc.
   • A través de informes de usuarios en producción, el peor caso porque llegó a publicarse sin ser detectado

2. Localizar el error

   Aislar la parte del código donde se encuentra el error.

   • Aislarlo mediante la consola de desarrollo
   • Para errores complejos, usar un depurador

3. Corregir el error

   Corregirlo y asegurarse de que no exista en ninguna otra parte del código.

   • Sustituir la solución existente por una que funcione
   • Buscar el error en código similar
   • Escribir pruebas con herramientas de testing

Ideas principales:

1. Es muy fácil quedarse sentado e inventar grandes teorías sobre cómo cambiar el mundo, pero, la mayoría de las veces, nuestras intuiciones son erróneas.

2. A menudo nos preocupa tanto equivocarnos que ni siquiera salimos al terreno de juego para intentarlo.

3. Al final, hay que recordar que el éxito es solo la punta del iceberg. Bajo la superficie, fuera de nuestra vista y muchas veces de nuestra conciencia, hay una montaña de fracasos necesarios que lo precedieron.

Sé que los casos que presenta este libro contienen muchas más ideas, pero estas tres fueron las que de verdad se me quedaron.

También fueron las únicas que logré anotar mientras escuchaba, más o menos a mitad del libro. Jajaja.

Como dice el libro, el mundo es demasiado complejo para entenderlo desde un sillón.

Sal ahí fuera.

Pon a prueba tus ideas.

Equivócate. Aprende. Fracasa otra vez. Vuelve a intentarlo.

Y quizá, después de haber probado todo lo humanamente posible, llegue un momento en que puedas decir por fin:

«Esta vez sé que es lo correcto».

Así que sí.

Aprende de tus propios errores, pero también de los errores de los demás.

Como dice Levenson:

«Aprende de los errores de los demás. No puedes vivir lo suficiente como para cometerlos todos tú mismo».

«El duelo resulta ser un lugar que ninguno de nosotros conoce hasta que llega a él».

Joder. Qué lectura tan triste.

Habla de perder a alguien y de lo que esa pérdida les hace a quienes se quedan. Y, aun leyendo todo ese dolor, seguía esperando encontrar algún rayo de esperanza en la última página.

La verdad es que no lo había.

Pero entre sus tapas sigue habiendo muchísimo valor.

Quizá no del que hace que todo mejore por arte de magia, sino del que te permite continuar aunque las cosas nunca vuelvan a ser como antes.

Llora.

Acepta.

Sigue adelante.

Libro 13 de 100

«Quiero escribir sobre personas que sueñan y esperan a que termine la noche; que anhelan la luz para poder aferrarse a quienes aman».

Y con esto prácticamente termina mi recorrido por las obras de Murakami.

Todavía hay algunos libros suyos que no he descargado ni escuchado, pero después de tantos, siento que me he hecho una idea bastante clara del hombre que hay detrás de las historias.

Algunas observaciones:

1. Le gusta fumar.
2. Le gustan las gatitas. Los gatos, quiero decir. Gatos. Sus protagonistas casi siempre tienen uno, pierden uno, buscan uno o conocen a alguien que tiene uno.
3. Está claro que ha vivido lo suficiente como para tener una cantidad absurda de material extraño al que recurrir.

Su estilo, desde luego, no es el convencional al que estamos acostumbrados la mayoría.

No siempre hay una trama cautivadora que te empuje de un capítulo al siguiente. No todos los «por qué» tienen respuesta. Los cabos sueltos no siempre quedan bien atados y, a veces, aparecen tramas enteras, se cruzan con todo lo demás y luego desaparecen sin darte el cierre que esperabas.

Y sí, eso puede ser frustrante.

Pero creo que también es parte de lo que hace interesantes sus historias.

Murakami deja mucho espacio para que el lector decida qué significan las cosas, cómo ve a los personajes y si alguna de esas pequeñas experiencias extrañas importaba realmente.

Y, si lo piensas, la vida real también funciona un poco así.

No todo lo que nos ocurre tiene un significado trascendental.

Buena parte es solo ruido.

Encuentros al azar. Conversaciones extrañas. Personas que desaparecen de nuestras vidas. Cosas que nos preocuparon durante semanas y que al final no significaron absolutamente nada.

Probablemente, la mayor parte de lo que vivimos acaba convertida en pequeñas trivialidades dentro de una historia más grande.

Así que quizá la decisión sea si pasamos la vida obsesionados con cada cosa que no tuvo sentido, o si aceptamos que no todo necesita una explicación y seguimos adelante.

No siempre puedes decidir hacia dónde fluye la corriente.

Pero sí puedes decidir qué llevar en tu barco.

Libro 12 de 100

«Si tú me recuerdas, no me importa que todos los demás me olviden».

Joder. Qué final tan abierto.

Hubo tantos momentos en este libro en los que seguía esperando que todo encajara por fin, como si tuviera que existir una explicación clara que uniera todos aquellos sucesos extraños.

Y entonces Murakami básicamente dijo: pues no.

Hay sueños, recuerdos, gatos que hablan, coincidencias extrañas, metáforas que quizá sean metáforas o quizá no, y personas que entran y salen de la vida de los demás.

Luego el libro termina y te quedas ahí sentado pensando:

Espera. ¿Eso es todo?

Pero, por extraño que parezca, probablemente por eso se te queda dentro.

No porque todo quedara explicado, sino porque no fue así.

Hay cosas en las que sigo pensando incluso después de terminarlo, pero la que de verdad se me quedó grabada fue:

¿Qué fue de Hoshino después de que el gato le respondiera?

¿Cambió algo de verdad?

¿Fue solo otro encuentro extraño?

¿O era simplemente la forma de Murakami de recordarnos que no todo necesita quedar perfectamente resuelto para que la historia continúe?

Sinceramente, no lo sé.

Y quizá de eso se trata.

Algunas historias terminan.

Otras simplemente se detienen.