Mentor prolífico y automatizador de sistemas

Jonathan: Hola a todos y bienvenidos al podcast de la comunidad de Exercism. Tengo el privilegio de estar acompañado por Isaac, que es uno de nuestros mantenedores y colaboradores y que hace poco ha hecho mucha mentoría con muchos estudiantes en nuestros GoHorts, nuestras cohortes de aprendizaje, que llevamos a cabo durante 30 días, creo que ya dos veces, sobre todo en Go y Elixir. E Isaac ayudó con el track de Go, lo cual fue genial. Así que Isaac, un enorme saludo para ti. ¿Nos contarías un poco dónde vives, de dónde vienes y cómo llegaste al sector tech? Isaac: Sí, estoy en California. Vivo en San José, California. La verdad honesta es que llegué al sector tech porque mi hermano mayor estaba metido en tech y yo hacía lo que él hiciera. Éramos varios hermanos. Nos gustaba pasar tiempo juntos, o a algunos de nosotros nos gustaba pasar tiempo con otros más que con otros. Tenía un hermano mayor con el que me encantaba pasar tiempo. A él no necesariamente le gustaba pasar tiempo conmigo tanto, pero yo lo seguía a todas partes y quería estar haciendo lo que él estuviera haciendo. Cuando él tenía unos 15 años, agarró un libro de C for Dummies que andaba por la casa, y yo tenía 9, si mal no recuerdo. Así que él escribía C, y yo pensé: si él lo hace, yo también. Mis programas eran bastante simples y básicos a esa edad. Eran más bien del tipo "¿cómo te llamas? hola, Bob". No eran demasiado complejos. Hay que empezar por algún lado. Hay que empezar por ahí. Yo pensaba: ah, podías imprimir el carácter visual de archivo, y hace un sonido. Qué genial. Escribí un programa que literalmente solo imprimía una barra invertida A. Pero estaba empezando a los 9. Escribía programas en C. Teníamos una vieja máquina con Windows 3.1 que arrancaba en DOS y luego mi hermano había configurado un script por lotes que, cuando la computadora arrancaba, mostraba un menú donde podías seleccionar, por ejemplo, iniciar Windows, iniciar juegos, había como un menú de juegos. Podías escribir, digamos, 5 para Warcraft o lo que fuera. Así que escribía scripts por lotes a medida que teníamos otros juegos instalados y demás. Y de ahí en adelante ya no hubo vuelta atrás. Mi hermano fue a la universidad a estudiar ingeniería en computación y, una vez más, yo pensé: si él lo hace, yo también. Así que empecé a escribir C a los 9. Escribía... Visual Basic 6 en la secundaria. Tenía una POM Pilot y escribía varios programas en la POM Pilot en la secundaria. Mi profesor de matemáticas era muy cool. Estaba en una de esas viejas escuelas... Jonathan: ¿Era ese tipo de cosa, te acuerdas de que intentaron lanzar como el pre-iPad y más o menos, unas cuantas personas lo consiguieron y tenía como el garabato con la plumita? Y todos pensaban que era súper cool porque salía por el extremo, y era como zoop, y luego podías tocar así. Era como que, no llegó... Siempre me acuerdo de eso porque después empezó a salir el iPad y todos decían: ah, un poco pronto. El Pilot era justo eso, un poco adelantado a su época, ¿sabes a qué me refiero? Isaac: Fue genial durante una década más o menos, pero sí, estaba el palm graffiti que usabas para ingresar. Había una pequeña almohadilla de entrada, y tenías que escribir ciertos caracteres, pero estaban como basados en el alfabeto. Así, la A era como un triángulo y la F era como el ángulo recto. Sí, mi profesor de matemáticas de la secundaria decía: oye, si escribiste el programa, está bien si quieres usarlo en el examen. Así que escribía programas para la POM Pilot en la secundaria, lo cual era genial. Fui a la universidad a estudiar ingeniería en computación. La gente hablaba de lenguajes de scripting. No sabía bien qué eran, así que agarré Perl al azar. Y luego salí del posgrado y me contrató Google. En 2013 me trasladaron de la costa este a California. Y ahí fue donde aprendí Python hace unos diez años. Y Python ha sido mi lenguaje principal durante la última década. Estuve en Google, así que mi estilo está muy influenciado por el estilo de Google. Y por eso he escrito principalmente así. Y luego hace unos... cuatro años, creo que 2018 o por ahí, Google empezó a impulsar el lenguaje Go internamente y ahí aprendí Go. Jonathan: Genial. E Isaac, cuando hablas del estilo de Google, ¿había un sentido establecido de que esta es la forma correcta de hacerlo, o es más bien... cómo... amplía un poco 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 todos deben seguir. Dicen que un buen compromiso o un buen acuerdo es un acuerdo donde nadie queda contento. Nadie está del todo contento con la guía de estilo, pero mientras todos la sigan, el código se ve uniforme. Eso significa que cualquiera puede tomar cualquier fragmento de código de la base de código de Google y hacerle modificaciones, y mientras siga las mismas pautas de estilo, el código es todo uniforme, no tienes que estar pensando: ah, esta base de código usa sangrías de cuatro espacios y esta otra usa de dos espacios, o esta tiene tal o cual convención de nombres. Todo en toda la base de código se hace de la misma manera. No todos están contentos con nada de eso. Cada uno tiene sus áreas donde desearía que se hiciera diferente, pero dado que existe una guía de estilo documentada, que está disponible públicamente, puedes simplemente buscar en Google la guía de estilo de Python de Google y te dice así escribimos código en Google. Mientras todos se apeguen a esa guía, el código se ve muy uniforme, lo cual es muy agradable, poder abrir cualquier base de código y que simplemente se vea sin sorpresas del tipo: ah, esto lo escribirían diferente. Jonathan: ¿Es por eso que Go quizá encaja muy bien en ese contexto? Porque está formateado y realmente es como que así es. Definitivamente se nota la influencia de Google en eso. Isaac: Sí, no sé cuánto influyó Rob Pike en el enfoque de Google o cuánto influyó él en el enfoque de Google. No estoy seguro de qué llevó a qué, pero Go definitivamente lleva eso a otro nivel, donde... hay incluso más, por ejemplo, con Python hay diferentes estilos y la gente ajusta sus linters para aceptar cosas distintas. Por ejemplo, internamente Google usa sangrías de dos espacios en Python porque hay mucho código anidado a gran profundidad y no quieren tener una pared enorme de espacios. Externamente, la mayoría de la gente usa cuatro espacios, y eso está como escrito en la documentación de Python. Pero sí, cuando se trata de Go, simplemente llevaron eso a otro nivel y dijeron: el lenguaje mismo tiene el formato. Solo hay una manera de formatear. No hay discusiones en línea sobre cuál es la forma correcta. Solo hay una manera. Jonathan: Ahorra muchísimo ida y vuelta. Digamos eso, mejor. Sí. Así que está bien. Isaac: Sí. Jonathan: Bien, entonces ahora, cuando empezaste en Google, ¿nunca habías hecho Python o habías jugueteado un poco, o fue un salto fácil? Porque lo hiciste sonar como que conseguiste el trabajo en Google y luego fue como: bien, genial, aprende Python, vamos. Isaac: Correcto. Creo que antes de entrar a Google nunca había escrito Python. Escribía Perl desde hacía uno o dos años. Creo que un par de años para ese entonces ya escribía Perl. Mi primer trabajo de verano. Es toda otra historia. Empecé a escribir Perl seis años antes de entrar a Google, así que en ese momento escribía bastante Perl. Escribía algo de Bash, así que estaba familiarizado con los lenguajes de scripting. Pero nunca había escrito Python. Pero una vez que jugueteas con suficientes lenguajes... la curva de aprendizaje es un poco menos empinada para aprender otro lenguaje, porque ya has visto la mayoría de las construcciones y solo es una sintaxis un poco diferente, un conjunto de herramientas un poco distinto. Pero es mucho de lo mismo, solo que un poco diferente, escrito de otra manera. Las construcciones tienden a ser bastante similares. Así que una vez que has aprendido cuatro lenguajes, aprender un quinto es como: ah, esto solo está escrito un poco diferente. Jonathan: Sí, sí. Eso es interesante. Ahora, te reíste un poco cuando hablamos de tu primer trabajo, como al salir de la secundaria. Entonces ahora tú... porque... ¿siempre habías sido como: voy a dedicarme a la ingeniería, voy a hacer lo de las computadoras? ¿Siempre había sido un pensamiento consciente, o siempre fue como: esto es simplemente donde encajo naturalmente y disfruto esto y ya? ¿Cómo fue eso? Isaac: Supongo que estaba muy empeñado en seguir los pasos de mi hermano. Él estudió ingeniería en computación. Empezó a programar. Empezó a programar cuando yo era niño. Yo lo seguía. Escribía programas desde chico. Él estudió ingeniería en computación y eso fue... quería hacer lo mismo que él, y además la estaba pasando muy bien escribiendo programas y todo eso. Así que desde que entré a la secundaria, y mi hermano ya estaba en la universidad, sabía que ahí era donde quería terminar. Jonathan: Él es unos años mayor que tú, así que parece que tuvo una influencia enorme en ti como persona. ¿Cuántos otros hermanos tienes? ¿O era él como el no va más a tus ojos? Isaac: Tengo ocho hermanos, pero definitivamente él era con quien mejor me llevaba. Es uno de... supongo, me llevo mejor con algunos de ellos que con otros. Cuando tienes ocho, siempre hay una variación. Con él me llevaba bastante bien. Tendemos a pensar muy parecido. Tendemos a tener intereses similares. Nos la pasábamos hablando de computadoras como nerds todo el tiempo. Todavía lo hacemos. A su esposa no le gusta cuando esa se convierte en la conversación de la mesa. Ella dice: nada de trabajo en la mesa. Simplemente hablamos de programación como nerds todo el tiempo y la comentamos todo el tiempo. Es muy difícil decir cuánto era solo yo queriendo copiarlo versus que simplemente tuviéramos intereses similares. Definitivamente tenemos intereses similares ahora. No sé cuánto de eso es naturaleza versus crianza. No puedo realmente decir cuánto de eso es yo copiándolo versus que simplemente tengamos intereses similares. Pero dado que seguía sus pasos desde una edad temprana, yo seguía y él de cierta forma marcaba el camino, y yo lo seguía. Jonathan: Sí, eso es genial. ¿Y él dónde está ahora? Solo por curiosidad, ¿está en la costa este? Isaac: Sigue en la costa este, trabaja en tech. Trabajamos brevemente en la misma empresa. Jonathan: Sí, bien, genial. Así que ahí está eso. Genial. Solo tenía curiosidad por preguntar. Ahora, una de las cosas que... has estado muy involucrado en la cohorte que acabamos de tener. En la última cohorte de aprendizaje, sobre todo con Go, tuvimos algo de 30 días con Go. ¿Cómo... y luego tu involucramiento con Exercism antes ha sido más bien específicamente en mantenimiento, pero también bastante en mentoría, según entiendo. ¿Cómo has encontrado esa división? Digo, ¿cómo llegaste a Exercism y cuáles son los distintos aspectos en los que disfrutas contribuir? Isaac: Llegué a Exercism originalmente porque estaba tratando de reaprender Haskell. Tomé una clase de Haskell 101 en Google que fue bastante divertida. Y luego pensé: ah, debería dedicarle más tiempo a esto. Y lo dejé de lado. Y después intenté volver a retomarlo. Jonathan: y nos vemos la próxima vez. Isaac: Con cualquier lenguaje, encuentro que la forma más fácil de aprenderlo es escribirlo de verdad. La forma más fácil de escribirlo es tener un propósito para escribirlo. No he encontrado un buen propósito para escribir Haskell, lo que hizo que fuera muy difícil de aprender. Pero descubrí Exercism y pensé: ah, esto podría ayudarme a escribir más Haskell. Así fue como encontré Exercism originalmente. Una vez que estuve ahí, pensé: ah, hay un track de Python, un track de Bash, y hay como ejercicios por aquí. Así que me metí en la madriguera, ¿y qué tan profundo? Jonathan: Y te metiste en la madriguera. Isaac: Sí. Empecé a resolver ejercicios en Python. Empecé a resolver ejercicios en Bash. Hice un par de los ejercicios de Go. Cuando salió el GoHort, y estaba revisando algunas de mis soluciones anteriores, vi que muchas estaban enviadas tres años antes. Así que me registré por primera vez en el track de Go en 2019 y resolví un buen montón de esos ejercicios en ese entonces. Y luego, ya llevaba una década haciendo Python en ese punto. Así que me sentía relativamente cómodo uniéndome como mentor de Python, que es donde paso la mayor parte de mi 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 luego empecé a involucrarme 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í como así. Digo, es como... cuidado con lo que te apuntas, ¿no? Isaac: Sí, y luego Glenn armó el track de Ock y yo pensé: ah, conozco Ock, me gusta Ock, déjame subirme a ese tren. Así que ayudé a construir los ejercicios del track de Ock. No estoy del todo seguro, pero creo que hace tres años, cuando vi los ejercicios de Go, completé todo el track y luego uno de los mentores dijo: ah, terminaste todos los ejercicios, quizá deberías ser mentor. No estoy lo bastante seguro, no escribo Go con la frecuencia ni la regularidad suficientes para sentirme cómodo haciendo mentoría al respecto. Así que en realidad no era mentor de Go. Pero 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 para mentorizar durante el mes y ayudar ahí. Pero en realidad hace poco me uní al GoHort como estudiante. Y luego me voy a deslizar desde la sección de estudiantes, supongo. Jonathan: Justo me deslicé desde la sección de estudiantes, supongo. Cuidado con lo que te apuntas. Te digo, parece que surge un patrón donde te apuntas a una cosa y terminas en otra, pero eso es genial. Bien, entonces en términos de cuando has estado mentorizando estudiantes en el track de Go específicamente, ¿cuáles son algunas de las cosas más comunes que ves? Digo, en el track de Go probablemente hay bastantes desarrolladores con experiencia, diría, que lo hicieron, gente con algo de trayectoria en desarrollo, pero ¿cuáles fueron algunas de las cosas que notaste que decías: bien, esas son las cosas comunes en las que la gente parece atascarse? ¿Hubo algún patrón o cosas que encontraste que eran como: bien, eso es común, eso aparece bastante consistentemente, potencialmente? Isaac: No sé. No he visto... la mayor parte de la mentoría que he visto ha sido con personas en soluciones ya completadas. La gente, más a menudo que no, ya resolvió el ejercicio antes de buscar mentoría. Así que por lo general la gente no está atascada en la mayoría de las interacciones que tengo. Entonces es más bien... ya completaron con éxito un ejercicio y luego gran parte de lo que aporto es: ¿hay una forma más eficiente de hacer esto? ¿Hay un mejor algoritmo? Una de las comunes que sale demasiado seguido es la construcción de strings, 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 hay mucho de empujarlos hacia mejores, digamos, patrones, mejores prácticas y patrones. Gracias por vernos. Jonathan: Bien, eso es genial. Es fascinante. Ahora, actualmente, ¿cómo se ve tu día a día con el trabajo en términos de dónde encaja el desarrollo? Digamos que llevas un tiempo en tech, ¿cómo se ve el día? ¿Cuáles son los desafíos? ¿Qué partes disfrutas del trabajo en este momento? Isaac: Estoy en un rol de ingeniería de confiabilidad de sitios, que se parece un poco a DevOps. Tiene algo de sysadmin también. He cargado un pager en una rotación de guardias durante la última década más o menos. Así que mi día a día depende mucho de si es mi semana de guardia o no. Cuando estoy de guardia, es mucho de vigilar el pager, hay una cola de tickets, una cola de soporte, asegurarme de que cualquier proceso que falle o problema se diagnostique y se arregle. Eso es más o menos una semana de cada seis, o de lo grande que sea el equipo en ese momento. Y el resto del tiempo, estoy de guardia. Jonathan: Mm-hmm. Isaac: Paso mucho tiempo metido con la automatización, así que es mucho de identificar procesos que son engorrosos y hacerlos menos engorrosos. Puede ser que... puede haber una razón para que ocurra, pero en general encuentro que hasta que algo empieza... cuando ocurre este problema, tenemos que ejecutar... reparamos manualmente haciendo estos comandos y aquellos comandos, y es como: bueno, ¿por qué ejecutamos estos comandos a mano? ¿Podemos escribir un script de Python que haga todo eso por ti? ¿O podemos mejorar las herramientas para que no fallen y detecten ese problema por sí mismas? Y mucho de simplemente tratar de mejorar el día a día de cómo operamos los sistemas, de modo que los humanos estén menos involucrados o no necesiten estar tan profundamente involucrados para que las cosas sigan funcionando sin problemas. Jonathan: Entonces, ¿tu día... disfrutas tratar de encontrar esas pequeñas áreas donde se pueden optimizar las cosas? ¿Cuánto de tu trabajo es reaccionar a las cosas y luego, a partir de la reacción, decir: ah, genial, esta es una oportunidad, frente a buscar de forma proactiva esas pequeñas áreas? ¿Cuál es el equilibrio típico? Isaac: Disfruto la automatización, probablemente eso es lo que más me gusta de mi trabajo: poder automatizar cosas. No siempre es reactivo. Digo, reactivo podría significar que algo se rompe, también podría ser como: ah, la gente ejecuta este comando, me di cuenta de que hay este comando que tendemos a copiar y pegar, ¿puedo mejorarlo? Donde veo que alguien hace un cambio a un runbook en algún lugar o mejora un comando en algún lado y pienso: ah, ese comando está bastante desordenado, ¿puedo reescribirlo desde cero? Y por supuesto, la atención es demasiada, hay que equilibrarla con el atractivo, tiene que haber menos palabras rebuscadas, un mejor lenguaje, todo ese tipo de cosas. Tienes que ponerte al frente de eso intentando hacerlo. Sinceramente, digo, todo en mi trabajo realmente encaja si lo pienso. Así que soy una persona muy motivada, como que no... mi trabajo, supongo, está ahí con cualquier cosa, pero en cualquier trabajo que amo, mato el tiempo para mí, está ahí solo para intentar... Jonathan: manufactura, podrías decir. Isaac: Refactorización, notar que hay herramientas que 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 nuevas... digo, no siempre es refactorización, a veces es solo crear nuevas herramientas. Es como: ah, tenemos un proceso que implica hacer 20 pasos, déjame meter todo eso en un programa. Mucho de esto tiende a ser... tengo que descubrir estas cosas de alguna manera. A veces las descubro porque me asignan llevar a cabo un conjunto de tareas, y entonces pienso: no quiero ejecutar esto a mano. A veces las descubro simplemente notando, por ejemplo, estoy buscando algún fragmento de código en algún lado, y veo que este otro código de acá, que mantiene otro equipo, hace las cosas mal, déjame refactorizarlo, o usar bibliotecas modernas o lo que sea, sí. Jonathan: Entonces mucho de... simplemente poder ver. ¿Cuánta libertad tienes? ¿Tienes bastante libertad para andar por ahí y meterte de repente a ajustar aquí? Digo, eso debe ser bastante divertido, bastante agradable. Isaac: Mi jefe me da mucha libertad, lo cual es muy agradable. No sé cuánto de esto vino de que... actualmente no estoy en Google, pero no sé cuánto de esto vino de mi experiencia en Google. En Google, la gente era muy abierta a meterse de repente y decir: ah, me di cuenta de que los demás... da la casualidad de que uso esta biblioteca y podría mejorarse de esta manera. Déjame arreglarlo. Trabajé muy, muy brevemente en una startup donde la cultura era muy diferente, era mucho menos abierta. Y en la startup, la gente era muy protectora con sus bases de código y no se aceptaba mucho que otras personas modificaran su código. Así que yo decía: ah, hay un problema con esta base de código, y no podía simplemente cambiarlo en esa base de código. Jonathan: Sí, retrocede. 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, ¿sabes?, pero en realidad, quizá Google era mucho más capaz de manejar eso como concepto. Y eso es, perdón, acabo de encender las luces porque nosotros... no hay luces actualmente para todos los que escuchan, no hay electricidad en Ciudad del Cabo de vez en cuando. Justo ahora me estoy cegando, pero está bien. Pero eso es interesante, volviendo a ese punto sobre la cultura de las startups y cómo la gente está, irónicamente, mucho más enganchada con tener la propiedad de las cosas y luego quizá poniendo trabas a las cosas un poco, ¿sabes? Isaac: Sí, no sé si ser una startup necesariamente se vincula bien con ser una cultura de trabajo abierta... de juego. En Google, mucho de lo que la gente hacía era jugar, donde disfrutaban lo que hacían. Lo hacen porque lo disfrutan. Eran muy amables al respecto, o muy abiertos. Algunas otras culturas laborales se tratan menos de hacer cosas porque las disfrutas y más de que es un trabajo, o esto es mi código y sé cómo funciona. No quiero que otra gente se meta con él. No estoy del todo seguro de qué se necesita para hacer esos cambios en la cultura laboral. Pero Google sí fomentaba mucho un sentido de que todos tienen acceso a todo el código. Todos tienen el poder de hacer cambios en él. Adelante, haz lo que creas que es lo correcto. Y luego, en mi trabajo actual, con mi jefe actual, él también me ha dado mucha libertad. Dice: claro, encontraste algo que arreglar. Adelante, arréglalo. Encontraste un área donde se pueden mejorar las cosas. Simplemente me quito del medio. Avísame en qué puedo ayudar. Así que puedo autodirigir mucho de lo que hago y, simplemente, si encuentro un área donde pienso: ah, podría mejorar esto. Él dice: sí, genial, adelante. Jonathan: Bien, qué bien. Y tú, la empresa está en la costa este, ¿estoy en lo correcto al decir que en realidad trabajas de forma remota? Creo recordar que dijiste que estabas por mudarte, y luego llegó el COVID y fue como que todo eso llegó a su fin. ¿Cómo estás llevando lo remoto, la distancia, el desfase horario, todo ese tipo de cosas? ¿Te afecta o...? Isaac: Definitivamente extraño estar en una oficina e interactuar con la gente en persona. Así que está eso. El desfase horario... mi equipo ha sido muy comprensivo con la diferencia de horario. Estoy tres horas detrás del resto de mi equipo. Hay un breve standup diario que me pierdo. Tenemos dos standups diarios para dos productos distintos. Así que el primero sí me lo pierdo, y mi equipo ha sido muy bueno para acomodarme ahí, y usamos mucho Slack internamente. Así que son muy buenos teniendo como un hilo diario de Slack con los problemas que surgen para que yo me pueda poner al día, y si necesitan algo, me avisan. Yo trato de ser lo más receptivo posible y respondo todo eso lo más rápido que puedo por la mañana. Así que es un poco como que... el desfase horario no es genial, pero tampoco... hemos logrado manejarlo bastante bien. Y a la inversa, está el otro lado: ellos saben que tienen a alguien en el equipo que está despierto un poco más tarde. Así que he tenido colegas que, por ejemplo, son las 6 de la tarde en la costa este y dicen: ah, esto está roto. Oye, Isaac está en la costa oeste, Isaac podría ayudarme con esto porque allá apenas son las 3 de la tarde. Así que funciona en ambas direcciones. Sí, el... Jonathan: Sí. Isaac: Sí, dejé Google en 2019, perdón, 2020. Entrevisté en 2019. Se suponía que me uniría en 2020, en mayo. Planeaba mudarme en agosto, abril de 2020, pero empezó el COVID y todo eso y la oficina se cerró, y fue mucho de: ah, la oficina todavía no está abierta. Se mudará en cuanto abra la oficina. Y luego, dos años de pandemia, empezaron a abrir la oficina otra vez. Y pensé: sabes, ya no estoy seguro de querer mudarme. Nueva York sonaba muy emocionante, pero había todos estos negocios abiertos y, ya sabes, lugares y cosas pasando. Pero ahora que hay una pandemia, mucho de eso ya no suena tan emocionante. Así que pasé a un puesto remoto después de trabajar de forma remota durante dos años. Jonathan: ¿Y eres una persona de ciudad o de campo, o algo intermedio? Porque Nueva York es ciudad. Es 100% ciudad. Digo, no hay dos maneras de verlo. ¿Sabes a qué me refiero? Así que eso habría sido un cambio bastante grande, supongo. Sí. Aun así es emocionante. Isaac: Crecí en un área metropolitana grande, así que no soy ajeno a la vida de ciudad. Actualmente vivo en los suburbios. Disfruto el senderismo y el ciclismo, y trato de salir al aire libre tanto como puedo. Así que disfruto vivir en los suburbios cerca de rutas increíbles para caminar y andar en bici y todo eso. Mudarme a Nueva York sería un cambio bastante grande. Pero pienso que variar de vez en cuando no es algo malo. Y si odio mi vida en Nueva York, siempre me puedo mudar. Jonathan: No es tan complicado hacer eso. Pero qué bien. Ahora, probablemente, corrígeme si me equivoco, pasas mucho tiempo frente a la pantalla en una especie de oficina, como una oficina en casa o lo que sea. ¿Sales todos los días a... cómo equilibras todo el mundo de la pantalla frente a... tienes como tu momento diario donde dices: tengo que salir y simplemente estar afuera y hacer algo más? Isaac: Ojalá lo hiciera. Algunos días, algunos meses o algunos años lo hago mejor que otros. En 2020 era bastante bueno andando en bici casi todos los días. Salgo al aire libre la mayoría de los fines de semana. Trato de hacer una caminata por semana. No he sido muy constante con eso, pero voy a hacer una caminata. Depende de la temporada. Estoy en California. Algunas semanas hace un calor extremo. Acabamos de tener una ola de calor donde hizo más de 40 grados Celsius durante casi una semana seguida. Así que eso dificulta salir. Estamos en California, donde hay incendios, así que a veces pasamos una o dos semanas donde la calidad del aire afuera no es del todo segura para respirar. Eso dificulta estar al aire libre en California algunas semanas. Y luego estar adentro durante una pandemia también es difícil. Así que definitivamente hay semanas en las que estoy mucho más adentro que otras. Pero sí me gusta salir. Ha habido... he tenido tramos de seis meses donde he estado haciendo caminatas, saliendo a caminar al menos cada dos semanas. Jonathan: y luego. Isaac: He tenido tramos donde he acampado como una vez al mes durante, ya sabes, seis meses seguidos. Así que hay tramos donde estoy mejor que en otros, y luego hay tramos donde simplemente estoy en la casa durante dos semanas seguidas. Jonathan: Sí, qué bien. Y entonces, Isaac, ¿cuál es la siguiente...? Quizá, no sé, quizá no lo has pensado con tanta anticipación, pero ¿cómo se ven los próximos cinco años para ti en términos de... tienes alguna idea, o estás como: quiero empezar un negocio propio, o quiero hacer esto, o simplemente estás como: ah, simplemente disfrutando la vida y disfrutando donde estoy? Isaac: Yo, antes de mudarme a la costa oeste, pensaba que tenía una mejor idea de cómo sería mi futuro. Pero que todo eso se pusiera patas arriba me enseñó que es muy difícil predecir qué va a pasar el próximo año, y mucho menos en cinco. Estoy bastante contento. Acabo de cambiar de trabajo hace relativamente poco. Cambié de trabajo hace unos dos, dos años y medio. Disfruto bastante mi trabajo actual, así que no veo que eso cambie pronto. Estaría contento de quedarme en el mismo trabajo durante los próximos dos, tres años, cinco años. Me encanta vivir en California. Me encanta poder ir a caminar, andar en bici, acampar y todo eso. Así que no me veo dejando California pronto. Y no me veo dejando ese trabajo pronto porque disfruto bastante trabajar ahí. Así que estoy bastante contento y no veo ningún cambio importante, no tengo ningún cambio importante planeado, pero es muy difícil decirlo. Jonathan: Genial. Bien, tengo un par de preguntas más sobre las que me encantaría conocer tu perspectiva. La primera probablemente no es la que te preparé, pero la... Entonces, si fueras a... Si 10 personas entraran a tu oficina justo ahora, 10 completos desconocidos, y no supieran nada de programación, y tuvieras como una 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? Como, si pudieras reducirlo a: haz esto a toda costa, ¿cuáles serían algunos de esos consejos? Isaac: Mi recomendación número uno sería tratar de encontrar un problema que puedas resolver con programación. Así tienes un proyecto concreto que te dé motivación; sin un objetivo específico en mente que te impulse hacia adelante, es extremadamente difícil aprender a programar. Similar a cualquier otra habilidad, aprender a programar requiere bastante tenacidad o aguante. Solo tienes que persistir. Puede ser muy difícil al principio. Puede ser muy frustrante. Sin algo que te impulse hacia adelante, es muy fácil rendirse. Así que, si es posible, tener algo que realmente quieras hacer con la programación ayuda mucho. Es como... todo está en la misma constelación de consejos. Es que tienes que... hay que persistir. Ayuda mucho tener paciencia contigo y reconocer que estás aprendiendo una nueva habilidad y que vas a fallar mucho. He tenido a algunas personas que intentan aprender a programar y se frustran. Dicen: ah, normalmente soy bueno en las cosas y esto no funciona a la primera. Y yo digo: sí, el fracaso es parte del proceso de aprendizaje. Y si fracasar te resulta incómodo, puedes tener muy difícil aprender nuevas habilidades. Tienes que tener paciencia contigo y con el proceso, y simplemente persistir mucho. Jonathan: Eso es útil. Digo, yo diría que es como... apenas me di cuenta de cómo funcionan los métodos. Y eso ha sido simplemente pasar por... porque mucho del conocimiento que, bueno, cuando la gente habla de cosas, hay tanto conocimiento que se da por sentado cuando la gente enseña, sobre todo. Así que, de repente todos lanzan la palabra métodos. Y yo digo: ¿qué diablos es un método? ¿Qué está pasando? Y fue solo a través de la cohorte con Go que empecé a darme cuenta: ah, los métodos funcionan de esta manera. Pero fue casi como que se me cayó el veinte, pero tuve que sumergirme en este entorno y esta terminología durante tanto tiempo que se filtra. Yo diría que ese fue uno de los mayores aprendizajes para mí: no tratar de aprenderlo todo, sino ir picando poco a poco un concepto simple. Porque todo se interconecta tanto que eventualmente uno puede empezar a armar el modelo mental, lo cual es muy importante. Así que es una gran herramienta. Se la haré saber a la gente, la recomendación de Isaac: sé paciente y trátate con cariño, e ir picando poco a poco. Eso es genial. Bien. Entonces la última pregunta que tengo, y antes de dejarte continuar con el resto de tu día, hablamos como equipo de este concepto de la colina por la que morirías en tech. Suena bastante melodramático y bastante... mucho drama de por medio. Y la idea es esencialmente cuál es la única cosa que crees que es absolutamente clave, que piensas que es una mentalidad o perspectiva inamovible que hay que tener en tech. Así que un buen ejemplo sería, no sé, en un nivel muy trivial, yo siempre pongo mis funciones 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 una, Rebecca, que lleva el track de Unison. Ella decía que preferiría tener un genio que es opinionado y difícil de tratar... Ella preferiría tener 50 personas que realmente amen trabajar en equipo y resolver problemas juntos, que un genio que acapare todo el ancho de banda en términos de gestión. Así que esa fue una de las suyas, y lo expresé de forma bonita, pero ¿cuál sería tu colina por la que morirías en el ámbito tech que sea tu tipo de no negociable? Isaac: Esto probablemente está muy fuertemente influenciado por cómo hace las cosas Google. En Google tienen este concepto de legibilidad, donde se supone que el código debe ser fácil de leer. Y mucho de lo que hago cuando escribo código... quiero que mi código sea simple de leer y entender. Y he visto mucho código, sobre todo en código, hay mucho enfoque en la eficiencia y en las pruebas de rendimiento 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 encuentro que el código es más fácil de leer, preferiría código ineficiente que sea fácil de leer antes que código súper eficiente que... Así que, por ejemplo, hay una cita común, no estoy seguro de a quién se le atribuye exactamente, de que la raíz de todos los males... que la optimización prematura es la raíz de todos los males. Y siempre que la gente dice: ah, ¿cómo puede ser esto más eficiente? Yo digo: ¿necesita ser más eficiente? ¿Te topaste con... estás corriendo en producción y te topaste con problemas de eficiencia? ¿Esto es demasiado lento para usarlo en producción? Si en realidad no has experimentado un problema con el código en producción, donde necesite ser más eficiente, ¿por qué lo harías más eficiente? Es más fácil de leer tal como está. Es más fácil de mantener. Otras personas podrían entender qué está pasando. ¿Por qué regalarías código bien escrito que es fácil de manejar y fácil de mantener para ahorrar algunos ciclos de CPU? ¿La electricidad es lo bastante barata y las CPU son lo bastante baratas como para que no necesitemos optimizar el código solo por optimizarlo? Jonathan: Sí, siempre es gracioso porque es una de esas cosas donde yo digo: nuestro programa compiló y corrió en 30 milisegundos. Y ellos dicen: ah, pero lo bajamos a como 20 milisegundos. Y yo digo: no podría decirte. No podría decirte cuál fue más rápido, cuál fue más lento. Eso parece rápido. Así que creo que es un buen punto. Estoy seguro de que disfrutaría leer tu código, pero eso es genial. Isaac, muchas gracias por tu tiempo, por despertarte temprano y por aguantar los cortes de energía en el hemisferio sur. Y por mí sentado en completa oscuridad, estoy seguro de que eso es bastante cómico para ti. Pero muchas gracias por tu tiempo. Y espero 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. Así que lo aprecio. Y sí, muchas gracias de nuevo. Y te veo en un segundo. No, un placer. Cuídate, Isaac. Adiós. Isaac: Muchas gracias de nuevo. No, un placer. Cuídate, Isaac.