Mentor prolífico y automatizador de sistemas

Jonathan: Hola a todos y bienvenidos al pódcast de la comunidad de Exercism. Tengo el privilegio de contar con Isaac, que es uno de nuestros mantenedores y colaboradores y que hace poco ha hecho mentoría con un montón de estudiantes en nuestros GoHorts, nuestras cohortes de aprendizaje, que organizamos durante 30 días, creo que ya dos veces, sobre todo de Go y Elixir. Y Isaac ayudó con el track de Go, lo cual fue genial. Así que, Isaac, un enorme saludo para ti. ¿Nos cuentas un poco dónde vives, de dónde eres y cómo llegaste a la tecnología? Isaac: Sí, estoy en California. Vivo en San José, California. La verdad, sin rodeos, es que me metí en la tecnología porque mi hermano mayor estaba metido en la tecnología y yo hacía lo que hiciera él. Tenía un montón de hermanos. Nos gustaba pasar tiempo juntos, o a algunos de nosotros nos gustaba pasar tiempo con unos más que con otros. Tenía un hermano mayor con el que me encantaba pasar el rato. A él no le hacía tanta gracia pasar el rato conmigo, pero yo le seguía a todas partes y quería hacer lo que fuera que él estuviera haciendo. Se hizo con un libro de «C for Dummies» que andaba por casa cuando él tenía unos 15 años y yo 9, si no recuerdo mal. Así que él escribía en C y yo pensaba: si él lo hace, yo lo hago. A esa edad mis programas eran bastante simples y básicos. Eran más bien ejercicios del tipo «¿cómo te llamas?», «hola, Bob». No eran muy complejos. Hay que empezar por algún sitio. Hay que empezar por ahí. Yo pensaba: ah, puedes imprimir el carácter y hace un sonido. ¡Qué guay! Escribí un programa que literalmente imprimía una barra invertida y una A. Pero empecé a los 9 años. Escribía programas en C. Teníamos una máquina vieja con Windows 3.1 que arrancaba en DOS y mi hermano había montado un script de batch que, cuando arrancaba el ordenador, mostraba un menú donde podías elegir cosas como iniciar Windows, iniciar juegos, había como un menú de juegos. Podías teclear un 5, por ejemplo, para Warcraft o lo que fuera. Así que yo escribía scripts de batch según íbamos instalando otros juegos y demás. Y a partir de ahí todo fue rodado. Mi hermano se fue a la universidad a estudiar ingeniería informática y, una vez más, yo pensé: si él lo hace, yo lo hago. Así que empecé a escribir C con 9 años. Escribía... Visual Basic 6 en el instituto. Tenía un Palm Pilot en el que escribía distintos programas en el instituto. Mi profesor de matemáticas era genial. Estaba en uno de esos de la vieja escuela... Jonathan: ¿Era algo así como...? ¿Te acuerdas de que intentaron lanzar eso anterior al iPad y la cosa tuvo..., unos pocos se hicieron con él y tenía esa cosita de garabatear con el lápiz? Y todos pensaban que era súper guay porque salía al final y era como ¡zoop!, y luego podías dar toquecitos en él. Era un poco..., no acabó de..., siempre me acuerdo de eso porque después empezó a salir el iPad y todo el mundo decía: ah, un poco pronto. El Palm Pilot se adelantó un poco a su tiempo, ¿sabes a lo que me refiero? Isaac: Fue genial durante más o menos una década, pero sí, tenía el Graffiti de Palm ese con el que escribías. Tenía una pequeña zona para escribir y tenías que dibujar algo parecido a caracteres, pero basados en el alfabeto. Por ejemplo, la A era como un triángulo y la F era como el ángulo recto. Sí, mi profesor de matemáticas del instituto decía: oye, si escribiste el programa, no hay problema en que lo uses en el examen. Así que escribía programas para el Palm Pilot en el instituto, lo cual era genial. Fui a la universidad a estudiar ingeniería informática. Veía que la gente hablaba de lenguajes de scripting. Yo no sabía muy bien qué eran, así que me puse con Perl un poco al azar. Después salí de la escuela de posgrado y me contrató Google. En 2013 me trasladaron de la costa este a California. Y ahí fue donde me puse con Python hace unos diez años. Python ha sido mi lenguaje principal durante la última década. Estuve en Google, así que mi estilo está muy influido por el estilo de Google. Por eso he escrito sobre todo así. Y luego, hace unos... cuatro años, creo que en 2018 o por ahí, Google empezó a impulsar el lenguaje Go internamente y fue entonces cuando me puse con Go. Jonathan: Genial. Y, Isaac, cuando hablas del estilo de Google, ¿había una idea establecida de que esta es la forma correcta de hacerlo, o era más bien...? ¿Cómo...? Explícame un poco más eso, porque es interesante. Isaac: El estilo de programación no es necesariamente la forma correcta de hacerlo, sino más bien una forma uniforme que todo el mundo debe seguir. Dicen que un buen acuerdo, o un buen trato, es aquel en el que nadie queda contento. Nadie está del todo contento con la guía de estilo, pero mientras todo el mundo la siga, el código parece uniforme. Eso significa que cualquiera puede coger cualquier trozo de código de la base de código de Google y modificarlo, y mientras siga las mismas directrices de estilo, el código es uniforme, no tienes que andar pensando: ah, esta base de código usa sangrías de cuatro espacios y esta otra de dos, o esta usa tal convención de nombres y aquella otra. Todo el código, en toda la base de código, se hace de la misma manera. A nadie le gusta todo al cien por cien. Cada cual tiene sus rincones donde le gustaría que se hiciera de otra forma, pero como existe una guía de estilo documentada y disponible públicamente, basta con buscar en Google «Google Python style guide» y te dice cómo escribimos código en Google. Mientras todo el mundo se ciña a esa guía, el código se ve muy uniforme, lo cual está muy bien: puedes abrir cualquier base de código y no te llevas sorpresas del tipo ah, esto lo escribirían de otra manera. Jonathan: ¿Es por eso que Go encaja tan bien en ese contexto? Porque está formateado y realmente es como «esto es así y punto». Sin duda se nota la influencia de Google ahí. Isaac: Sí, no sé cuánto le influyó a Rob Pike el enfoque de Google o cuánto influyó él en el enfoque de Google. No sé qué llevó a qué, pero Go desde luego lo lleva a otro nivel, donde... Hay todavía más variedad; con Python hay estilos distintos y la gente ajusta sus linters para aceptar cosas diferentes. Por ejemplo, internamente Google usa sangrías de dos espacios en Python porque hay mucho código muy anidado y no quieren tener una pared enorme de espacios. De cara al exterior, la mayoría de la gente usa cuatro espacios, y eso está más o menos recogido en la documentación de Python. Pero sí, con Go se llevó eso a otro nivel y dijeron: el propio lenguaje ya impone el formato. Solo hay una forma de formatear. No hay debates en internet sobre cuál es la forma correcta. Solo hay una. Jonathan: Ahorra un montón de idas y venidas. Digámoslo así, quizá. Sí. Está bien. Isaac: Sí. Jonathan: Vale, entonces, cuando empezaste en Google, ¿no habías tocado Python nunca o ya habías trasteado con él, o fue un salto fácil? ¿Cómo fue? Porque diste a entender que más o menos conseguiste el trabajo en Google y luego fue como: vale, genial, aprende Python y adelante. Isaac: Correcto. Creo que antes de entrar en Google nunca había escrito Python. Llevaba uno o dos años escribiendo Perl. Bueno, creo que en ese momento llevaba ya un par de años escribiendo Perl; empecé con mi primer trabajo de verano. Es otra historia completamente distinta. Empecé a escribir Perl seis años antes de entrar en Google, así que en aquel momento escribía bastante Perl. También escribía algo de Bash, así que estaba familiarizado con los lenguajes de scripting. Pero nunca había escrito Python. Ahora bien, cuando ya has trasteado con suficientes lenguajes... la curva de aprendizaje es menos pronunciada para aprender otro, porque ya has visto la mayoría de las construcciones y solo cambia un poco la sintaxis, un poco el conjunto de herramientas. Pero es en gran parte lo de siempre, solo que algo distinto, escrito de otra forma. Las construcciones suelen ser bastante parecidas. Así que una vez que has aprendido cuatro lenguajes, aprender un quinto es como: ah, esto solo está escrito un poco distinto. Jonathan: Sí, sí. Eso es interesante. Ahora bien, has soltado una risita cuando hablabas de tu primer trabajo, al salir del instituto. Entonces, ¿siempre tuviste claro que te ibas a dedicar a la ingeniería, a lo de los ordenadores? ¿Había sido siempre un pensamiento consciente o era más bien: esto es simplemente donde encajo de forma natural, me gusta y ya está? ¿Cómo fue eso...? Isaac: Supongo. Yo intentaba seguir los pasos de mi hermano. Él estudió ingeniería informática. Empezó a programar. Empezó a programar cuando yo era un crío. Yo le seguía. Programo desde que era pequeño. Él estudió ingeniería informática y eso fue, ya sabes, yo quería hacer lo mismo que él y además lo pasaba genial programando y todo eso. Así que, desde que entré en el instituto, cuando mi hermano ya estaba en la universidad, tenía claro que ahí era donde yo quería acabar. Jonathan: Él es unos años mayor que tú, así que parece que ejerció una influencia enorme sobre ti como persona. ¿Cuántos hermanos más tienes? ¿O era la octava maravilla a tus ojos? Isaac: Tengo ocho hermanos, pero él era sin duda con el que mejor me llevaba. Es uno de... supongo que con algunos me llevo mejor que con otros. Cuando tienes ocho, siempre hay de todo. Con él me llevaba bastante bien. Solemos pensar de forma parecida. Solemos tener intereses similares. Nos pasábamos el día frikeando con los ordenadores. Y todavía lo hacemos. A su mujer no le gusta cuando eso se convierte en la conversación de la cena. Dice: nada de trabajo en la mesa. Nosotros frikeamos con la programación todo el rato y hablamos de ello constantemente. Es difícil decir cuánto era yo queriendo copiarle y cuánto era simplemente que teníamos intereses parecidos. Ahora desde luego tenemos intereses parecidos. No sé cuánto hay de naturaleza y cuánto de crianza. La verdad es que no puedo decir cuánto era yo copiándole y cuánto era que simplemente teníamos intereses similares. Pero dado que le seguía los pasos desde muy pequeño, yo seguía y él, en cierto modo, marcaba el camino, y yo lo seguía. Jonathan: Sí, eso está muy bien. Y él, ¿dónde está ahora? Por curiosidad, ¿está en la costa este? Isaac: Sigue en la costa este, trabaja en tecnología. Trabajamos un tiempo en la misma empresa. Jonathan: Sí, vale, genial. Pues eso es todo. Está bien. Solo me interesaba preguntarlo. Ahora, una de las cosas... Has estado muy implicado en la cohorte que acabamos de tener. O sea, en la última cohorte de aprendizaje, sobre todo con Go, organizamos una cosa de 30 días con Go. ¿Cómo fue? Y luego tu implicación en Exercism antes ha sido más bien en el mantenimiento, pero también bastante mentoría, por lo que tengo entendido. ¿Cómo has llevado esa división? Es decir, ¿cómo conociste Exercism y qué aspectos distintos te gusta aportar? Isaac: Conocí Exercism porque estaba intentando volver a aprender Haskell. Hice una clase de introducción a Haskell en Google que fue bastante divertida. Y luego pensé: ah, debería dedicarle más tiempo. Pero lo dejé aparcado. Y después intenté retomarlo. Jonathan: y nos vemos la próxima vez. Isaac: Con cualquier lenguaje, me parece que la forma más fácil de aprenderlo es ponerse a escribirlo de verdad. Y la forma más fácil de escribirlo es tener un motivo para escribirlo. No he encontrado un buen motivo para escribir Haskell, lo cual hizo que me costara mucho ponerme. Pero descubrí Exercism y pensé: ah, esto puede ayudarme a escribir más Haskell. Así fue como conocí Exercism. Una vez dentro, pensé: ah, hay un track de Python y un track de shell y un montón de ejercicios aquí dentro, así que me metí en la madriguera del conejo, ¿no? Jonathan: Y por la madriguera del conejo te fuiste. Isaac: Sí. Empecé a resolver ejercicios en Python. Empecé a resolver ejercicios en Bash. Hice un par de los ejercicios de Go. Cuando surgió el GoHort y estuve revisando algunas de mis soluciones anteriores, vi que muchas las había enviado tres años antes. Así que sí, me apunté al track de Go por primera vez en 2019 y resolví un montón de esos ejercicios entonces. Y a estas alturas llevaba ya una década con Python. Así que me sentía relativamente cómodo apuntándome como mentor de Python, que es donde paso la mayor parte del tiempo con ejercicios estos días. Y luego empecé a enviar PRs, pull requests, al track de Python porque había cosas fuera de lugar. Y después empecé a implicarme en el track de Bash. Y no estoy del todo seguro de cómo pasó, pero pasé de enviar correcciones al track de Bash a ser mantenedor de Bash. Jonathan: Así, de repente. Quiero decir, es como: cuidado con lo que te apuntas, ¿verdad? Isaac: Sí, y luego Glenn escribió el track de OCaml y yo pensé: ah, conozco OCaml, me gusta OCaml, voy a subirme a ese carro. Así que ayudé a construir los ejercicios del track de OCaml. No estoy del todo seguro, pero creo que hace tres años, cuando vi los ejercicios de Go, completé el track entero y entonces uno de los mentores dijo: ah, has terminado todos los ejercicios, quizá deberías hacerte mentor. Yo no me sentía lo bastante seguro; no escribo Go con la suficiente frecuencia ni regularidad como para sentirme cómodo haciendo mentoría con él. Así que no era realmente mentor de Go. Pero luego, cuando me uní al GoHort y había un montón de gente que quería mentoría, pensé: ah, supongo que podría apuntarme a hacer mentoría durante el mes y echar una mano. Pero en realidad hace poco me uní al GoHort como estudiante. Y luego me pasaré del lado de los estudiantes, supongo. Jonathan: Yo también me pasé del lado de los estudiantes, supongo. Cuidado con lo que te apuntas. Te digo, parece que se está formando un patrón en el que te apuntas a una cosa y acabas siendo otra, pero eso está muy bien. Vale, entonces, en cuanto a cuando has estado haciendo mentoría con estudiantes en el track de Go en concreto, ¿cuáles son algunas de las cosas más habituales que ves? Es decir, en el track de Go probablemente haya bastantes desarrolladores con experiencia, diría yo, que lo hicieron, gente con cierto historial en el desarrollo, pero ¿cuáles fueron algunas de las cosas que notaste y que te hicieron pensar: vale, esto es lo típico con lo que la gente parece atascarse? ¿Había patrones o cosas que encontraras y que pensaras: vale, esto es común, aparece de forma bastante... consistente, potencialmente? Isaac: No sé. La mayor parte de la mentoría que he hecho ha sido con gente que ya había completado las soluciones. Lo más habitual es que la gente ya haya resuelto el ejercicio antes de pedir mentoría. Así que, en general, no suelen estar atascados en la mayoría de las interacciones que tengo. Eh, entonces, sobre todo, ya sabes, han completado un ejercicio con éxito y buena parte de lo que les comento es, mmm, ya sabes, ¿hay una forma más eficiente de hacer esto? ¿Hay un algoritmo mejor? Mmm, una de las cosas habituales que salen demasiado a menudo es la construcción de strings, eh, en lenguajes como Go y Python, donde los strings son inmutables, hacer mucha concatenación de strings no es muy eficiente. Así que es mucho de: oye, podrías construir esto usando un array y luego unir los strings, o puedes usar un string builder en Go. Así que es mucho de, ya sabes, empujarlos hacia mejores, digamos, patrones, buenas prácticas y patrones. Gracias por ver. Jonathan: Vale, eso está bien. Es fascinante. Ahora, actualmente, ¿cómo es tu día a día con el trabajo, en cuanto a dónde encaja el desarrollo? Digamos que llevas un tiempo en tecnología: ¿cómo es un día normal? ¿Cuáles son los retos? ¿Qué partes de tu trabajo actual son las que disfrutas? Isaac: Estoy en un puesto de site reliability engineering, que es más o menos parecido a DevOps. Tiene también algo de sysadmin. Llevo unos diez años llevando una busca en un turno de guardia. Así que mi día a día depende mucho de si es mi semana de guardia o no. Cuando estoy de guardia, es sobre todo estar pendiente de la busca, hay una cola de tickets, una cola de soporte, y asegurarme de que cualquier proceso que falle o cualquier problema se diagnostique y se arregle. Eso es más o menos una semana de cada seis, o de las que sean según el tamaño actual del equipo. Y el resto del tiempo, estoy de guardia. Jonathan: Ajá. Isaac: Paso mucho tiempo trasteando con la automatización, así que gran parte es identificar procesos que son engorrosos y hacerlos menos engorrosos. Puede que... Puede que haya una razón para que ocurra, pero en general me encuentro con que, hasta que algo empieza, ya sabes, cuando ocurre este problema tenemos que ejecutar, ya sabes, reparamos a mano ejecutando estos comandos y aquellos, y piensas: bueno, ¿por qué estamos ejecutando estos comandos a mano? ¿Podemos escribir un script de Python que haga todo eso por nosotros? ¿O podemos mejorar las herramientas para que no fallen y detecten ese problema por sí solas? Y mucho de intentar mejorar el día a día de cómo gestionamos los sistemas para que los humanos intervengan menos o no necesiten implicarse tan a fondo para que todo funcione sin sobresaltos. Jonathan: Entonces, ¿disfrutas tu día intentando encontrar esos pequeños rincones donde las cosas se pueden optimizar? ¿Qué parte de tu trabajo es reaccionar ante las cosas y, a partir de esa reacción, pensar: ah, genial, esto es una oportunidad, y qué parte es buscar proactivamente esos pequeños rincones? ¿Cuál suele ser el equilibrio? Isaac: Disfruto con la automatización; probablemente lo que más me gusta de mi trabajo es poder automatizar cosas. No siempre es reactivo. Quiero decir, reaccionar puede ser que algo se rompa, pero también puede ser: ah, ya sabes, la gente está ejecutando este comando y he visto que hay uno que tendemos a copiar y pegar, ¿puedo mejorarlo? O veo que alguien hace un cambio en un runbook por ahí o mejora un comando en algún sitio y pienso: ah, ese comando está bastante desastroso, ¿puedo reescribirlo desde cero? Y, por supuesto, tampoco hay que pasarse: tiene que compensar el esfuerzo, tiene que haber palabras más simples, un lenguaje mejor, ese tipo de cosas. Hay que dominar eso intentándolo. Sinceramente, si me pongo a pensarlo, todo en mi trabajo encaja. Soy una persona muy motivada, así que, no, mi trabajo... supongo que está donde esté, pero en cualquier trabajo que me guste, mataría el tiempo para mí, solo se trata de intentar... Jonathan: fabricación, por así decirlo Isaac: Refactorizar, darme cuenta de que hay herramientas que, ya sabes, son engorrosas de usar y decidir reescribirlas o escribir envoltorios alrededor de ellas. Veo, sí, veo cambios de código en algún programa grande y complicado y pienso: ah, ese programa es un desastre. ¿Puedo entrar y reescribirlo o refactorizarlo? O crear cosas nuevas; quiero decir, no siempre es refactorizar, a veces es simplemente crear herramientas nuevas. Es como: ah, tenemos un proceso que implica hacer 20 pasos, voy a metérselos todos a un programa. Mucho de esto tiende a ser, ya sabes, tengo que descubrirlo de alguna manera. A veces lo descubro porque me asignan una serie de tareas y pienso: no quiero ejecutar esto a mano. A veces lo descubro simplemente porque me doy cuenta; por ejemplo, estoy buscando algún fragmento de código por ahí y pienso: ah, este otro código de aquí, que mantiene otro equipo, está haciendo las cosas mal; voy a refactorizarlo o a usar bibliotecas modernas o lo que sea. Sí. Jonathan: Así que mucho de... simplemente ser capaz de verlo. Entonces, ¿cuánta libertad tienes? ¿Tienes bastante libertad para ir por ahí y meterte a retocar cosas aquí y allá? Quiero decir, eso debe de ser bastante divertido, bastante agradable. Isaac: Mi jefe me da mucha libertad, lo cual está muy bien. No sé cuánto de esto viene de... ahora mismo no estoy en Google, pero no sé cuánto viene de mi pasado en Google. En Google, la gente era muy abierta a meterse y decir: ah, me he dado cuenta de esto, ya sabes, resulta que uso esta biblioteca y se podría mejorar de tal manera. Voy a arreglarlo. Eh, trabajé muy, muy brevemente en una startup donde la cultura era muy distinta, mucho menos abierta. Eh, y en la startup la gente era muy protectora con sus bases de código, y que otras personas modificaran su código no estaba nada bien visto. Así que yo pensaba: ah, hay un problema en esta base de código, ¿lo cambio? Y ellos: ni de broma, no toques esa base de código. Jonathan: Sí, aparte. Pero eso es interesante, porque... uno asume que una startup sería mucho más de: bueno, simplemente haz el trabajo y hazlo lo más barato posible, ya sabes, pero en realidad puede que Google fuera mucho más capaz de manejar eso como concepto. Y eso es..., perdón, acabo de encender las luces porque ahora mismo no tenemos luz, para todos los que nos escucháis, en Ciudad del Cabo se va la electricidad de vez en cuando. Ahora mismo me estoy deslumbrando yo solo, pero no pasa nada. Pero es interesante, volviendo a ese punto sobre la cultura de las startups y cómo la gente, irónicamente, está mucho más enganchada a tener la propiedad de las cosas y eso quizá lo lastra un poco, ¿sabes? Isaac: Sí, no sé si ser una startup va necesariamente de la mano de ser una cultura de trabajo abierta... de trabajo basada en el juego. En Google, gran parte de lo que hacía la gente era jugar, donde disfrutaban con lo que hacían. Lo hacen porque les gusta. Eran muy amables con ello, o muy abiertos. Otras culturas laborales van menos de hacer las cosas porque te gusten y más de que es un trabajo, o de que este es mi código y sé cómo funciona. No quiero que otra gente lo toque. No estoy del todo seguro de qué hace falta para cambiar esas culturas laborales. Pero Google sí fomentaba mucho la idea de que todo el mundo tiene acceso a todo el código. Todos tenéis potestad para cambiarlo. Adelante, haced lo que creáis que es lo correcto. Y luego, en mi trabajo actual, con mi jefe actual, él también me ha dado mucha libertad. Dice: claro, has encontrado algo que arreglar, adelante, arréglalo. Has encontrado un área que se puede mejorar, yo me aparto de tu camino. Dime en qué puedo ayudar. Así que puedo autogestionar gran parte de lo que hago y, ya sabes, si encuentro un área donde pienso: ah, podría mejorar esto, él dice: sí, genial, adelante. Jonathan: Vale, bien. Y tú, la empresa tiene su sede en la costa este, ¿me equivoco si digo que en realidad trabajas en remoto? Creo recordar que dijiste que estabas a punto de mudarte y luego llegó el COVID y fue como que todo aquello se acabó. ¿Cómo llevas el remoto, la distancia, el desfase horario, todas esas cosas? ¿Te afecta o...? Isaac: Desde luego echo de menos estar en una oficina e interactuar con la gente en persona. Eh, así que eso está ahí. Mmm, el desfase horario... mi equipo ha sido muy, eh, comprensivo con la diferencia horaria. Yo llevo tres horas de retraso respecto al resto de mi equipo. Eh, hay una breve reunión diaria que me pierdo. Tenemos dos reuniones diarias para dos productos distintos. Eh, así que la primera sí me la pierdo, y mi equipo se ha portado muy bien conmigo en ese sentido, y usamos mucho Slack internamente. Así que son muy buenos teniendo, por ejemplo, un hilo diario en Slack con los problemas que han surgido, para que yo pueda ponerme al día, y si necesitan algo me avisan. Eh, yo, yo intento responder lo mejor que puedo, eh, y atiendo todo ese tipo de cosas lo antes que puedo por la mañana. Así que, eh, es un poco... el desfase horario no es ideal, pero tampoco es... han sido, hemos conseguido llevarlo bastante bien. Eh, y, a la inversa, está el otro lado, que es que ellos saben que tienen a alguien en el equipo que está despierto un poco más tarde. Así que he tenido compañeros que, ya sabes, eran las 6 de la tarde en la costa este y decían: ah, esto está roto. Oye, Isaac está en la costa oeste, Isaac me puede echar una mano con esto, porque allí todavía son las 3 de la tarde. Eh, así que funciona en ambos sentidos. Eh, sí, lo... Jonathan: Sí. Isaac: Estaba, sí, así que dejé Google en 2019, perdón, en 2020. Hice las entrevistas en 2019. Se suponía que me incorporaba en mayo de 2020. Tenía pensado mudarme en agosto, en abril de 2020, pero llegó el COVID y todo aquello, y cerraron la oficina, y fue mucho de: ah, la oficina todavía no está abierta. Se mudará en cuanto abra la oficina. Y luego, dos años después de la pandemia, empezaron a reabrir la oficina. Y yo pensé: ya sabes, no estoy seguro de querer mudarme ya. Nueva York sonaba muy emocionante, pero era todo eso de negocios abiertos y, ya sabes, locales y cosas pasando. Pero ahora que hay una pandemia, gran parte de eso ya no suena tan emocionante. Así que pasé a un puesto remoto después de trabajar en remoto durante dos años. Jonathan: Y tú, ¿eres más de ciudad o de campo, o algo intermedio? ¿Cómo? Porque Nueva York es ciudad. Es ciudad al cien por cien. Quiero decir, no hay duda. ¿Sabes a lo que me refiero? Así que habría sido un cambio considerable, supongo. Sí. Aun así, es emocionante. Isaac: Yo me crié en una gran área metropolitana, así que la vida de ciudad no me es ajena. Actualmente vivo en una zona residencial de las afueras. Me gusta el senderismo y el ciclismo, e intento salir al aire libre todo lo que puedo. Así que sí, me gusta vivir en las afueras, cerca de rutas increíbles para hacer senderismo y ciclismo y todo eso. Mudarme a Nueva York sería un cambio considerable. Pero creo que cambiar de aires de vez en cuando no está mal. Y si odio mi vida en Nueva York, siempre puedo mudarme. Jonathan: No es tan complicado hacerlo. Pero está bien. Ahora probablemente, corrígeme si me equivoco, pasas mucho tiempo delante de la pantalla, en una oficina, en tu oficina en casa o lo que sea. ¿Sales todos los días para...? ¿Cómo equilibras todo el mundo de la pantalla con...? ¿Tienes como un momento diario en el que piensas: tengo que salir y estar al aire libre y hacer otra cosa? Isaac: Ojalá lo hiciera. Algunos días, o algunos meses, o algunos años, lo llevo mejor que otros. En 2020 era bastante constante y montaba en bici casi todos los días. Salgo casi todos los fines de semana. Intento hacer una ruta de senderismo a la semana. No he sido muy constante, pero voy a hacer una ruta. Depende de la estación. Estoy en California. Algunas semanas hace un calor extremo. Acabamos de tener una ola de calor en la que estuvimos por encima de los 40 grados durante casi una semana seguida. Así que eso hace difícil salir. Estamos en California, donde hay incendios, así que, ya sabes, a veces pasamos una o dos semanas en las que la calidad del aire en el exterior no es del todo segura para respirar. Así que eso hace difícil estar al aire libre en California algunas semanas. Y luego estar en interiores durante una pandemia también es complicado. Así que hay sin duda algunas semanas en las que estoy mucho más en casa que otras. Pero sí me gusta salir. Ha habido, ya sabes, temporadas de seis meses seguidas en las que he estado haciendo senderismo, saliendo de ruta al menos cada dos semanas. Jonathan: y luego. Isaac: He tenido temporadas en las que he ido de acampada una vez al mes durante, ya sabes, seis meses seguidos. Así que hay temporadas en las que lo llevo mejor y otras en las que estoy simplemente en casa dos semanas seguidas. Jonathan: Sí, está bien. Y entonces, Isaac, ¿qué es lo siguiente...? Quizá, no sé, quizá no lo hayas pensado con tanta antelación, pero ¿cómo pintan tus próximos cinco años? ¿Tienes alguna idea o eres más de: quiero montar mi propio negocio o quiero hacer esto, o simplemente de: ah, disfrutar de la vida y de donde estoy? Isaac: Yo, antes de mudarme a la costa oeste, creía que tenía más claro cómo iba a ser mi futuro. Pero que todo eso se pusiera patas arriba me enseñó que es muy difícil predecir qué pasará el año que viene, y ya no digamos en cinco. Estoy bastante contento. Acabo de cambiar de trabajo hace relativamente poco. Cambié de trabajo hace unos dos, dos años y medio. Estoy disfrutando bastante con mi trabajo actual, así que no veo que eso cambie pronto. Estaría encantado de seguir en el mismo trabajo los próximos dos, tres años, o dentro de cinco. Me encanta vivir en California. Me encanta poder hacer senderismo, montar en bici, ir de acampada y todo eso. Así que no me veo dejando California pronto. Y tampoco me veo dejando ese trabajo pronto, porque me gusta bastante trabajar allí. Así que estoy bastante satisfecho y no veo ningún cambio importante, no tengo planes de cambios importantes, pero es muy difícil de decir. Jonathan: Está bien. Vale, tengo un par de preguntas más sobre las que me encantaría conocer tu punto de vista. La primera probablemente no sea para la que te preparé, pero es la... Así que si fueras a... Si ahora mismo entraran 10 personas en tu oficina, 10 completos desconocidos, y no supieras nada de programación, y tuvieras por ejemplo un arpista y un jardinero y lo que sea, ¿cuáles serían los tres mejores consejos que les darías para aprender a empezar a programar? O sea, si pudieras reducirlo a: haced esto cueste lo que cueste, ¿cuáles serían algunos de esos consejos? Isaac: Así que la recomendación número uno que daría es intentar encontrar un problema que puedas resolver con programación. Así tienes un proyecto concreto que te da motivación sin necesidad de tener un objetivo específico en mente que te impulse. Es extremadamente difícil ponerse a aprender a programar; como cualquier otra habilidad, aprender a programar requiere bastante tenacidad o aguante. Solo tienes que insistir. Puede ser muy difícil al principio. Puede ser muy frustrante. Sin algo que te impulse, es muy fácil rendirse. Así que, si es posible, tener algo que de verdad quieras hacer con ello ayuda mucho. Es todo un poco el mismo conjunto de consejos. Es solo que tienes que, hay que insistir. Ayuda mucho tener paciencia contigo mismo y reconocer que estás aprendiendo una habilidad nueva y que vas a fallar mucho. He conocido a gente que intenta aprender a programar y se frustra. Dicen: ah, normalmente se me dan bien las cosas y esto no funciona a la primera. Y yo les digo: sí, el fracaso forma parte del proceso de aprendizaje. Y si te incomoda fracasar en algo, puedes pasarlo realmente mal aprendiendo habilidades nuevas. Tienes que tener paciencia contigo mismo y con el proceso, e insistir mucho. Jonathan: Eso es útil. Quiero decir, yo diría que..., acabo de darme cuenta de cómo funcionan los métodos. Y eso ha sido solo cuestión de ir pasando por ello, porque mucho del conocimiento... bueno, cuando la gente habla de cosas, hay muchísimo conocimiento que se da por supuesto cuando se enseña, sobre todo. Así que, de repente, todo el mundo suelta la palabra métodos por ahí. Y yo pienso: ¿qué demonios es un método? ¿Qué está pasando? Y fue solo a través de la cohorte con Go cuando empecé a darme cuenta: ah, los métodos funcionan así. Pero fue casi como cuando se me encendió la bombilla, aunque tuve que sumergirme en este entorno y en esta terminología durante tanto tiempo que se te va metiendo dentro. Diría que uno de mis mayores aprendizajes fue no intentar aprenderlo todo, sino ir poco a poco con un solo concepto sencillo. Porque todo está tan interconectado que al final eres capaz de empezar a armar el modelo mental, lo cual es muy importante. Así que es una pequeña gran herramienta. Se lo contaré a la gente, esa recomendación de Isaac: ten paciencia, sé amable contigo mismo e ir poco a poco. Está muy bien. Vale. Entonces la última pregunta que tengo, y antes de dejarte seguir con el resto de tu día, hablamos en equipo de ese concepto de la cuestión por la que darías la vida en la tecnología. Suena bastante melodramático y con bastante drama. Y la idea es, básicamente, cuál es la única cosa que crees que es absolutamente clave, esa mentalidad o perspectiva inamovible que hay que tener en tecnología. Un buen ejemplo sería, no sé, a un nivel muy trivial, yo siempre pongo mis funciones primero y luego escribo mi CSS si estoy haciendo frontend. O sea, funcionalidad, luego lógica, luego lo que sea. Podría ser, ya sabes, tuvimos un caso, Rebecca, que lleva el track de Unison. Ella decía que prefería tener un genio con muchas opiniones y difícil de tratar... Ella preferiría tener 50 personas a las que de verdad les encante trabajar en equipo y resolver problemas juntos, que un solo genio que consuma todo el ancho de banda en cuanto a gestión. Así que ese era uno de los suyos, y lo he expresado con tacto, pero ¿cuál sería tu cuestión por la que darías la vida en el mundo de la tecnología, esa que para ti es no negociable? Isaac: Esto está probablemente muy influido por cómo hace las cosas Google. En Google tienen este concepto de «readability», según el cual se supone que el código debe ser fácil de leer. Y gran parte de lo que hago cuando escribo código es querer que mi código sea sencillo de leer y de entender. Y he visto mucho código, sobre todo... en el código hay mucho empeño en la eficiencia y en los benchmarks y en hacer tu código más rápido. Y a menudo reconozco que la forma en que lo hago no es necesariamente la más eficiente, pero si me parece que el código es más fácil de leer, prefiero código ineficiente y fácil de leer antes que código súper eficiente. Así que, ya sabes, está esa cita famosa, no estoy seguro de a quién se atribuye exactamente, de que la raíz de todos los males, de que la optimización prematura es la raíz de todos los males. Y siempre que la gente dice: ah, ¿cómo se puede hacer esto más eficiente?, yo pregunto: ¿necesita ser más eficiente? ¿Te has encontrado con...? ¿Lo estás ejecutando en producción y te estás topando con problemas de eficiencia? ¿Es demasiado lento para usarlo en producción? Si en realidad no has tenido un problema con el código en producción en el que necesite ser más eficiente, ¿por qué ibas a hacerlo más eficiente? Es más fácil de leer tal como está. Es más fácil de mantener. Otra gente puede entender qué está pasando. ¿Por qué ibas a renunciar a código bien escrito, fácil de trabajar y fácil de mantener, para ahorrar unos ciclos de CPU? ¿Es la electricidad lo bastante barata y las CPU lo bastante baratas como para que no necesitemos optimizar código? Solo por optimizarlo. Jonathan: Sí, siempre hace gracia porque es una de esas cosas en las que yo digo: nuestro programa se compiló y se ejecutó en 30 milisegundos. Y ellos dicen: ah, pero lo hemos bajado a unos 20 milisegundos. Y yo: no sabría deciros. No sabría deciros cuál era más rápido, cuál era más lento. Eso parece rápido. Así que creo que es un buen punto. Estoy seguro de que disfrutaría leyendo tu código, pero está muy bien. Isaac, muchísimas gracias por tu tiempo, por madrugar y por aguantar los cortes de luz en el hemisferio sur. Y por mí sentado en total oscuridad; seguro que eso es bastante cómico para ti. Pero muchísimas gracias por tu tiempo. Y me alegra mucho poder verte en futuras cohortes de aprendizaje y en los streams de mentoría y todo eso. Y gracias por toda la contribución que haces a Exercism y en general. Lo agradezco mucho. Y sí, muchísimas gracias otra vez. Y te veo en un segundo. No, un placer. Cuídate, Isaac. Adiós. Isaac: Muchísimas gracias otra vez. No, un placer. Cuídate, Isaac.