Mentor prolífico e automatizador de sistemas

Jonathan: Olá a todos e bem-vindos ao podcast da comunidade do Exercism. Tenho o privilégio de conversar com o Isaac, que é um dos nossos mantenedores e contribuidores e que recentemente fez bastante mentoria para muitos estudantes nas nossas GoHorts, as nossas turmas de aprendizado, que rodamos por 30 dias, duas vezes eu acho, especialmente em Go e Elixir. E o Isaac ajudou na trilha de Go, o que foi ótimo. Então, Isaac, seja muito bem-vindo. Você poderia me contar um pouco sobre onde você mora, de onde você vem e como você entrou no mercado de tech? Isaac: Sim, eu moro na Califórnia. Vivo em San Jose, na Califórnia. A verdade honesta é que eu entrei no mercado de tech porque meu irmão mais velho estava nesse mundo e eu fazia tudo o que ele fazia. Eu tinha vários irmãos. A gente gostava de ficar junto, ou alguns de nós gostavam mais de ficar juntos do que outros. Eu tinha um irmão mais velho com quem eu adorava passar tempo. Ele não gostava necessariamente tanto assim de ficar comigo, mas eu vivia atrás dele, querendo fazer tudo o que ele estava fazendo. Ele pegou um livro de C for Dummies que estava largado em casa quando ele tinha uns 15 anos, e eu tinha 9, se bem me lembro. Então ele escrevia em C, e eu pensei: se ele está fazendo isso, eu também vou fazer. Meus programas eram bem simples e básicos naquela idade. Era mais do tipo: qual é o seu nome, olá Bob. Não eram nada complexos. Todo mundo precisa começar em algum lugar. Precisa começar por ali. Eu pensava: ah, dá para imprimir um caractere de arquivo visual, e ele faz um som. Que legal. Eu escrevi um programa que literalmente só imprimia uma barra A. Mas eu estava começando aos 9 anos. Eu escrevia programas em C. A gente tinha uma máquina antiga com Windows 3.1 que iniciava no DOS, e aí meu irmão tinha montado um script em batch que, quando o computador ligava, mostrava um menu em que você podia escolher, tipo, iniciar o Windows, iniciar jogos, tinha um menu de jogos. Você podia digitar 5 para Warcraft ou qualquer coisa assim. Então eu escrevia scripts em batch conforme a gente instalava outros jogos e tal. E dali foi só ladeira abaixo. Meu irmão foi para a faculdade de engenharia de computação e, mais uma vez, eu pensei: se ele está fazendo isso, eu também vou fazer. Então comecei a escrever C quando eu tinha 9 anos. Eu escrevia... Visual Basic 6 no ensino médio. Eu tinha um Palm Pilot onde escrevia vários programas no ensino médio. Meu professor de matemática era muito legal. Eu estava numa daquelas escolas antigas... Jonathan: Era mais ou menos aquela coisa, lembra que tentaram lançar tipo o pré-iPad, e meio que, poucas pessoas conseguiram um, e ele tinha aquela coisinha de rabiscar com a caneta. E todo mundo achava super legal porque a caneta saía pela ponta, e era tipo zoop, e você podia ficar tocando na tela. Era meio que, não foi muito longe, eu sempre lembro disso porque depois o iPad começou a surgir e todo mundo ficou tipo, ah, um pouco adiantado demais. O Pilot estava só um pouquinho à frente da curva, você entende o que eu quero dizer? Isaac: Foi ótimo por uns dez anos, mas é, tem o Graffiti do Palm que você usava para entrada. Tinha um pequeno painel de entrada, e você tinha que escrever tipo caracteres, mas eram meio que baseados no alfabeto. Então o A era só um triângulo e o F era tipo um ângulo reto. É, meu professor de matemática do ensino médio falou: ei, se você escreveu o programa, tudo bem se você quiser usar na prova. Então eu escrevia programas para o Palm Pilot no ensino médio, o que era muito legal. Eu fui para a faculdade de engenharia de computação. Vi gente falando sobre linguagens de script. Eu não sabia bem o que eram, então escolhi Perl meio que ao acaso. E aí eu saí da pós-graduação, fui e acabei contratado pelo Google. Em 2013, eles me mudaram da Costa Leste para a Califórnia. E foi aí que eu aprendi Python, há uns dez anos. E o Python é minha linguagem principal há dez anos. Eu passei pelo Google, então meu estilo é muito influenciado pelo estilo do Google. E é por isso que eu tenho escrito principalmente. E então, uns... quatro anos atrás, acho que 2018 por aí, o Google começou a incentivar a linguagem Go internamente e eu aprendi Go nesse momento. Jonathan: Legal. E Isaac, quando você fala de estilo do Google, havia uma noção definida de que este é o jeito certo de fazer, ou é mais tipo, como foi, só desenvolve um pouco mais isso porque é interessante. Isaac: Estilo de código não é necessariamente o jeito correto de fazer, e sim um jeito uniforme que todo mundo deve seguir. Dizem que um bom acordo, ou um bom negócio, é aquele em que ninguém fica satisfeito. Ninguém fica totalmente satisfeito com o guia de estilo, mas desde que todo mundo o siga, o código fica uniforme. Isso significa que qualquer pessoa pode pegar qualquer pedaço de código na base de código do Google e fazer modificações, e desde que siga as mesmas diretrizes de estilo, o código fica todo uniforme, você não precisa ficar tipo, ah, esta base usa recuo de quatro espaços e esta usa dois, ou esta tem uma convenção de nomes assim ou assado. Tudo na base de código inteira é feito do mesmo jeito. Ninguém está satisfeito com nada disso. Cada um tem suas áreas em que gostaria que fosse diferente, mas como existe um guia de estilo documentado, que é público, você pode simplesmente pesquisar no Google o guia de estilo de Python do Google e ele diz: é assim que escrevemos código no Google. Desde que todo mundo siga esse guia, o código fica todo muito uniforme, o que é ótimo, poder abrir qualquer base de código e não haver surpresas do tipo, ah, eles escreveriam isso de outro jeito. Jonathan: É por isso que o Go talvez se encaixe tão bem nesse contexto? Porque ele é formatado e é bem assim, é deste jeito. Dá para ver claramente a influência do Google nisso. Isaac: É, eu não sei o quanto o Rob Pike foi influenciado pela abordagem do Google ou o quanto ele influenciou a abordagem do Google. Não sei qual levou a qual, mas o Go com certeza leva isso a outro nível, onde... Tem ainda mais, tipo, com Python existem estilos diferentes e as pessoas ajustam seus linters para aceitar coisas diferentes. Por exemplo, internamente o Google usa recuo de dois espaços em Python porque há muito código profundamente aninhado e eles não querem uma parede gigante de espaços. Externamente, a maioria das pessoas usa quatro espaços, e isso está mais ou menos escrito na documentação do Python. Mas é, quando se trata de Go, eles levaram isso a outro nível e disseram: a própria linguagem tem a formatação. Só existe um jeito de formatar. Não há fóruns online sobre qual é o jeito correto. Só existe um jeito. Jonathan: Isso economiza um monte de discussão ida e volta. Vamos colocar desse jeito, talvez. É. Então isso é bom. Isaac: É. Jonathan: Então, tá, agora que você começou no Google, você nunca tinha feito Python ou já tinha mexido um pouco, ou foi meio que um salto fácil? Tipo, como, porque você fez parecer que você conseguiu o emprego no Google e aí foi tipo, ok, legal, aprende Python, vamos lá. Isaac: Isso mesmo. Acredito que antes de entrar no Google eu nunca tinha escrito Python. Eu escrevia Perl havia um ano ou dois. Acho que uns dois anos naquele ponto eu tinha começado a escrever Perl. Meu primeiro emprego de verão. É uma história inteiramente diferente. Comecei a escrever Perl seis anos antes de entrar no Google, então eu escrevia bastante Perl naquele momento. Escrevia um pouco de Bash, então eu estava familiarizado com linguagens de script. Mas nunca tinha escrito Python. Mas depois que você mexe com linguagens suficientes... A curva de aprendizado fica um pouco menos íngreme para pegar outra linguagem, porque você já viu a maioria das construções e é só uma sintaxe um pouco diferente, um conjunto de ferramentas um pouco diferente. Mas tipo, é muita coisa do mesmo velho, só um pouco diferente, escrito de outro jeito. As construções tendem a ser bem parecidas. Então depois que você aprende quatro linguagens, aprender uma quinta é tipo, ah, isso aqui é só escrito de um jeito um pouco diferente. Jonathan: É, é. Isso é interessante. Então agora você riu um pouco sobre o seu primeiro emprego, tipo, saindo do ensino médio. Então agora você, porque é, você sempre foi tipo, vou trabalhar com engenharia, vou fazer a coisa dos computadores. Isso sempre foi um pensamento consciente ou sempre foi tipo, é só onde eu me encaixo naturalmente e eu gosto disso e pronto. Tipo, como foi isso... Isaac: Acho que sim. Eu estava muito tentando seguir os passos do meu irmão. Ele foi para engenharia de computação. Ele começou a programar quando eu era criança. Eu fui junto. Eu programava desde pequeno. Ele foi para engenharia de computação e era isso, sabe, eu queria fazer a mesma coisa que ele e também estava me divertindo muito programando e tudo o mais. Então, desde que entrei no ensino médio, e meu irmão já estava na faculdade, eu sabia que era ali que eu queria chegar. Jonathan: Então ele é alguns anos mais velho que você, e parece que ele teve uma influência enorme sobre você como pessoa. Quantos outros irmãos você tem? Ou ele era tipo o máximo aos seus olhos? Isaac: Tenho oito irmãos, mas ele era definitivamente aquele com quem eu me dava muito bem. Ele é um dos, acho que me dou melhor com alguns deles, mais do que com outros. Quando você tem oito, sempre tem uma variação. Eu me dava muito bem com ele. A gente costuma pensar de forma bem parecida. Costumamos ter interesses parecidos. A gente ficava horas falando de computadores o tempo todo. Ainda fazemos isso. A esposa dele não gosta quando isso vira conversa de mesa de jantar. Ela fica tipo, nada de trabalho à mesa do jantar. A gente fica falando de programação e discutindo isso o tempo todo. É difícil dizer quanto disso era só eu querendo copiá-lo e quanto era só a gente tendo interesses parecidos. Hoje a gente definitivamente tem interesses parecidos. Não sei quanto disso é natureza e quanto é criação. Não consigo realmente comentar quanto disso é eu copiando ele e quanto é a gente só tendo interesses parecidos. Mas como eu seguia os passos dele desde cedo, eu seguia e ele, de certa forma, abria o caminho e eu ia atrás. Jonathan: É, isso é bem legal. E ele, onde ele está agora? Só por curiosidade, ele está na Costa Leste? Isaac: Ele continua na Costa Leste, trabalha no mercado de tech. A gente trabalhou na mesma empresa por um breve período. Jonathan: É, tá, legal. Então tem isso. Que legal. Eu só fiquei curioso para perguntar. Agora, uma das coisas que, então você se envolveu bastante na turma que a gente acabou de ter. Então na última turma de aprendizado, especialmente com Go, a gente rodou uma coisa de 30 dias com Go, tipo, como, e aí o seu envolvimento com o Exercism antes era mais especificamente em manutenção, mas também bastante mentoria pelo que eu entendo. Então como você viu essa divisão? Tipo, quero dizer, como você conheceu o Exercism e quais são os diferentes aspectos nos quais você gosta de contribuir? Isaac: Eu conheci o Exercism originalmente porque estava tentando reaprender Haskell. Fiz uma aula de introdução a Haskell no Google que foi bem divertida. E aí eu pensei: ah, eu deveria passar mais tempo fazendo isso. E aí deixei de lado. E depois tentei voltar. Jonathan: e nos vemos na próxima. Isaac: Com qualquer linguagem, acho que o jeito mais fácil de aprendê-la é de fato escrevendo nela. O jeito mais fácil de escrever nela é ter um propósito para escrever nela. Não encontrei um bom propósito para escrever Haskell, o que tornou muito difícil aprender. Mas descobri o Exercism e pensei: ah, isso pode me ajudar a escrever mais Haskell. Então foi assim que encontrei o Exercism originalmente. Quando eu cheguei lá, pensei: ah, tem uma trilha de Python e uma trilha de shell e um monte de exercícios aqui, então eu mergulhei de cabeça na toca do coelho. Jonathan: E na toca do coelho você foi. Isaac: É. Comecei a resolver exercícios em Python. Comecei a resolver exercícios em Bash. Fiz alguns exercícios de Go. Quando o Go Hort surgiu e eu estava olhando algumas das minhas soluções anteriores, vi que muitas tinham sido enviadas três anos antes. Então eu me inscrevi na trilha de Go em 2019 e resolvi um monte desses exercícios naquela época. E aí eu já estava trabalhando com Python havia uma década nesse ponto. Então eu me sentia relativamente confortável em entrar como mentor de Python, que é onde passo a maior parte do meu tempo com exercícios hoje em dia. E aí comecei a enviar PRs, pull requests, para a trilha de Python porque tinha coisas fora de lugar. E então comecei a me envolver na trilha de Bash. E não sei bem como aconteceu, mas passei de enviar correções para a trilha de Bash a ser mantenedor de Bash. Jonathan: Assim, do nada, quer dizer, é tipo, cuidado com o que você se inscreve, né? Isaac: É, e aí o Glenn montou a trilha de Ock e eu pensei: ah, eu conheço Ock, eu gosto de Ock, deixa eu entrar nessa onda. Então ajudei a montar os exercícios da trilha de Ock. Não tenho certeza, mas acho que três anos atrás, quando vi os exercícios de Go, completei a trilha inteira e aí um dos mentores falou: ah, você terminou todos os exercícios, talvez devesse virar mentor. Não é suficiente, eu não escrevo Go com frequência suficiente, regularmente o bastante, para me sentir confortável em mentorar isso. Então eu não era exatamente um mentor de Go. Mas quando entrei no Go Hort e tinha um monte de gente querendo mentoria, eu pensei: ah, acho que eu poderia me inscrever para mentorar no mês e ajudar ali. Mas na verdade eu entrei recentemente no Go Hort como estudante. E aí vou acabar migrando da seção de estudantes, eu acho. Jonathan: Eu simplesmente fui e migrei da seção de estudantes, eu acho. Cuidado com o que você se inscreve. Eu te digo, parece estar surgindo um padrão em que você se inscreve para uma coisa e acaba virando outra, mas isso é bem legal. Tá, então em termos de quando você tem mentorado estudantes na trilha de Go especificamente, quais são algumas das coisas mais comuns que você vê? Quero dizer, a trilha de Go provavelmente tem bastante desenvolvedores experientes, eu diria, que a fizeram, tipo pessoas que já tinham um certo histórico em desenvolvimento, mas quais foram algumas das coisas que você notou que te fizeram pensar, ok, essas são as coisas comuns em que as pessoas parecem travar? Havia padrões ou coisas que você achou que eram tipo, ok, isso é comum, isso aparece de forma bastante... consistente, potencialmente. Isaac: Não sei. Eu não vi... a maior parte da mentoria que eu vi foi com pessoas em soluções já concluídas. As pessoas, na maioria das vezes, já resolveram o exercício antes de procurar mentoria. Então as pessoas geralmente não estão travadas na maioria das interações que eu tenho. Então é mais, sabe, elas concluíram um exercício com sucesso e boa parte do retorno é, sabe, existe um jeito mais eficiente de fazer isso? Existe um algoritmo melhor? Uma das coisas comuns que aparece vezes demais é tipo construção de string, em linguagens como Go e Python, onde strings são imutáveis, fazer muita concatenação de strings não é muito eficiente. Então é muito tipo, ei, você poderia construir isso usando um array e depois juntar as strings, ou você pode usar um string builder em Go. Então é muito, sabe, empurrar as pessoas para melhores, digamos, padrões, boas práticas e padrões. Obrigado por assistir. Jonathan: Tá, legal. Isso é fascinante. Então agora, atualmente, como é o seu dia a dia no trabalho, em termos de onde o desenvolvimento se encaixa? Digamos que você está no mercado de tech há um tempo, como é o dia? Quais são os desafios? Quais são as partes que você curte no trabalho no momento? Isaac: Então eu trabalho na função de engenharia de confiabilidade de sites, que é mais ou menos parecida com DevOps. Tem umas coisas de administração de sistemas ali. Eu carrego um pager numa escala de plantão há uns dez anos. Então meu dia a dia depende muito de ser ou não a minha semana de plantão. Quando estou de plantão, é muito vigiar o pager, tem uma fila de tickets, fila de suporte, garantir que qualquer processo com falha ou problema seja diagnosticado e corrigido. Isso é mais ou menos uma semana a cada seis, ou qualquer que seja o tamanho atual da equipe. E no resto do tempo, eu fico de plantão. Jonathan: Mm-hmm. Isaac: Passo muito tempo mexendo com automação, então é muito identificar processos que são complicados e torná-los menos complicados. Pode ser que... Pode haver um motivo para isso acontecer, mas em geral acho que, até algo começar, sabe, quando esse problema acontece, temos que rodar, sabe, reparamos manualmente executando estes comandos e aqueles comandos, e aí é tipo, bem, por que estamos rodando esses comandos à mão? Podemos escrever um script em Python que faça tudo isso por você? Ou podemos melhorar as ferramentas para que não falhem e detectem esse problema sozinhas? E muito de só tentar melhorar o dia a dia de como operamos os sistemas, de modo que os humanos estejam menos envolvidos ou não precisem estar tão profundamente envolvidos para manter as coisas rodando tranquilamente. Jonathan: Então o seu dia, você curte tentar encontrar esses pequenos pontos em que as coisas podem ser otimizadas? Quanto do seu trabalho é reagir a coisas e, a partir da reação, pensar, ah legal, esta é uma oportunidade, versus procurar proativamente esses pequenos pontos? Qual é o equilíbrio normalmente? Isaac: Eu curto automação, provavelmente é a coisa de que mais gosto no meu trabalho, poder automatizar coisas. Nem sempre é reativo. Quer dizer, reativo pode significar que algo quebrou, também pode ser tipo, ah, sabe, as pessoas estão rodando este comando e eu descobri que existe aquele comando que a gente costuma copiar e colar, será que posso melhorar isso? Onde eu vejo alguém fazendo uma mudança em tipo um runbook em algum lugar ou melhorando um comando em algum lugar e eu penso: ah, esse comando está bem bagunçado, posso simplesmente reescrevê-lo do zero? E claro, atenção demais também não dá, tem que equilibrar com apelo, tem que ter palavras menos complicadas, uma linguagem melhor, esse tipo de coisa. Você tem que dar conta disso tentando fazer isso. Honestamente, quer dizer, tudo no meu trabalho é adequado se eu pensar bem. Então eu sou uma pessoa muito motivada, tipo, não, meu trabalho eu acho que está em qualquer lugar, mas em qualquer trabalho que eu ame passar o tempo, ele está lá só para tentar e Jonathan: fabricação, digamos assim Isaac: Refatorar, perceber que existem ferramentas que são, sabe, complicadas de usar, e decidir reescrevê-las ou escrever wrappers em volta delas. Eu vejo, é, tipo, vejo mudanças de código em algum programa grande e complicado e penso: ah, esse programa é uma bagunça. Posso entrar e reescrevê-lo ou refatorá-lo? Ou criar ferramentas novas, quer dizer, nem sempre é refatoração, às vezes é só criar ferramentas novas. É tipo, ah, temos um processo que envolve fazer 20 etapas, deixa eu enfiar tudo isso num programa. Boa parte disso tende a ser, sabe, eu tenho que descobrir essas coisas de alguma forma. Às vezes descubro porque me atribuem um conjunto de tarefas, e aí eu penso: não quero rodar isso à mão. Às vezes descubro simplesmente notando, tipo, estou procurando algum trecho de código em algum lugar, e vejo: ah, aquele outro código ali, que outro time mantém, está fazendo as coisas mal, deixa eu refatorar aquilo, ou usar bibliotecas modernas, ou sei lá, é. Jonathan: Então muito de... só conseguir enxergar. Então quanta liberdade você tem? Você tem bastante liberdade para andar por aí e meio que aparecer, ajustar aqui? Quero dizer, isso deve ser bem divertido, bem prazeroso. Isaac: Meu gerente me dá bastante liberdade, o que é muito bom. Não sei quanto disso vem de, tipo, eu não estou mais no Google, mas não sei quanto disso vem da minha experiência no Google. No Google, as pessoas eram muito abertas a aparecer e dizer: ah, eu notei, sabe, eu por acaso uso esta biblioteca e ela poderia ser melhorada deste jeito. Deixa eu ir lá e corrigir. Eu trabalhei muito, muito brevemente numa startup onde a cultura era bem diferente, era muito menos aberta. E na startup, as pessoas eram muito protetoras em relação às suas bases de código e ter outras pessoas modificando o código delas não era muito aceito. Então eu pensava: ah, tem um problema nesta base de código. Será que dá para mudar isso naquela base de código... Jonathan: É, dá um passo atrás. Mas isso é interessante porque... você supõe que uma startup seria muito mais do tipo, bem, só faça o trabalho e faça o mais barato possível, sabe, mas na verdade, talvez o Google conseguisse lidar muito melhor com isso como conceito. E isso é, desculpa, eu acabei de acender as luzes porque a gente, ninguém está com luz agora para quem está ouvindo, não tem eletricidade na Cidade do Cabo de vez em quando. Só que agora estou me cegando, mas tudo bem. Mas isso é interessante, voltando àquele ponto sobre a cultura de startup e como as pessoas ficam, ironicamente, muito mais presas a ter a propriedade das coisas e talvez prejudicando um pouco as coisas, sabe? Isaac: É, eu não sei se ser uma startup necessariamente se relaciona bem com ser uma cultura de trabalho aberta... tipo, uma cultura de trabalho baseada em brincadeira. No Google, boa parte do que as pessoas faziam era brincar, elas gostavam do que faziam. Faziam porque gostavam. Eram muito amigáveis com isso, ou muito abertas. Algumas outras culturas de trabalho são menos sobre necessariamente fazer as coisas porque você gosta e mais sobre isso é um emprego, ou este é o meu código e eu sei como isso funciona. Não quero outras pessoas mexendo nele. Não sei exatamente o que entra na criação dessas mudanças de cultura de trabalho. Mas o Google certamente cultivava a sensação de que todo mundo tem acesso a todo o código. Todos vocês têm o poder de fazer mudanças nele. Vá em frente e faça o que você acha certo. E no meu trabalho atual, com meu gerente atual, ele também me deu muita liberdade. Ele fica tipo, claro, você encontrou algo para corrigir. Vá em frente e corrija. Você encontrou uma área em que as coisas podem melhorar. Vou simplesmente sair do seu caminho. Me avise no que posso ajudar. Então eu consigo autodirecionar boa parte do que faço e, sabe, se encontro uma área em que penso, ah, eu poderia melhorar isso, ele fica tipo, é, legal, vai fundo. Jonathan: Tá, ótimo. E você, a empresa é baseada na Costa Leste, certo, então você na verdade trabalha remoto? Acho que lembro de você dizer que estava prestes a se mudar, e aí veio a COVID e foi meio que, toda aquela coisa chegou ao fim. Como você está achando o remoto, a distância, o fuso horário, esse tipo de coisa? Isso te afeta ou tipo? Isaac: Eu definitivamente sinto falta de estar num escritório e interagir com as pessoas pessoalmente. Então tem isso, o fuso horário, minha equipe tem sido muito compreensiva com a diferença de horário. Então eu estou três horas atrás do resto da minha equipe. Tem um standup diário curto de que eu não participo. Temos dois standups diários para dois produtos diferentes. Então o primeiro eu perco e minha equipe tem sido muito boa em me acomodar nisso, e usamos muito o Slack internamente. Então eles são muito bons em ter tipo uma thread diária no Slack com os problemas que surgiram, para que eu pudesse me atualizar, e se precisarem de algo, eles me chamam, eu tento ao máximo ser responsivo e respondo tudo isso o mais rápido que consigo de manhã. Então é um pouco, o fuso horário não é ótimo, mas também não é, eles têm sido, a gente conseguiu lidar com isso muito bem. E, por outro lado, tem o outro lado, em que eles sabem que têm alguém na equipe que está acordado um pouco mais tarde. Então eu tive colegas que, sabe, eram 18h na Costa Leste e eles falavam: ah, isso aqui quebrou. Ei, o Isaac está na Costa Oeste, o Isaac poderia me ajudar com isso porque lá ainda é 15h. Então funciona nos dois sentidos. É, o... Jonathan: É. Isaac: Eu estava, é, então eu deixei o Google em 2019, desculpa, 2020. Fiz as entrevistas em 2019. Eu deveria entrar em maio de 2020. Eu estava planejando me mudar em agosto, abril de 2020, mas a COVID começou e tudo aquilo e o escritório foi fechado, e foi muito tipo, ah, o escritório ainda não está aberto. Ele se muda assim que o escritório abrir. E aí, dois anos dentro da pandemia, eles começaram a reabrir o escritório. E eu pensei: sabe, não tenho certeza se ainda quero me mudar. Nova York parecia muito empolgante, mas tipo, tinha todos aqueles negócios abertos e, sabe, casas de show e tudo acontecendo. Mas agora que tem uma pandemia, boa parte disso não soa tão empolgante assim. Então eu passei para uma posição remota depois de trabalhar remotamente por dois anos. Jonathan: E você é tipo uma pessoa de cidade ou de campo, ou no meio do caminho? Tipo, o quê? Porque Nova York é cidade. É 100% cidade. Quer dizer, não tem como negar. Sabe o que eu quero dizer? Então teria sido uma mudança e tanto, eu acho. Sim. É empolgante, ainda assim. Isaac: Eu cresci numa grande área metropolitana, então não sou estranho à vida na cidade. Atualmente moro num subúrbio. Gosto de fazer trilhas e andar de bicicleta e tento ficar ao ar livre o máximo que posso. Então eu gosto de morar num subúrbio perto de trilhas incríveis para caminhada e ciclismo e tudo mais. Me mudar para Nova York seria uma mudança e tanto. Mas acho que mudar as coisas de vez em quando não é ruim. E se eu odiar minha vida em Nova York, eu sempre posso me mudar. Jonathan: Não é tão difícil fazer isso. Mas que legal. Então agora você provavelmente, me corrija se eu estiver errado, passa muito tempo na frente da tela, tipo num escritório, tipo home office ou sei lá. Tipo, você sai todos os dias para tipo, como você equilibra todo esse mundo da tela versus, tipo, você tem um horário diário em que pensa, eu preciso sair e simplesmente ficar ao ar livre e fazer outra coisa? Isaac: Quem dera eu tivesse. Alguns dias, alguns meses, alguns anos eu sou melhor do que em outros. 2020. Eu estava bem constante andando de bicicleta quase todos os dias. Eu saio na maioria dos fins de semana. Tento fazer uma trilha por semana. Não tenho sido ótimo nisso, mas vou fazer uma trilha. Depende da estação. Estou na Califórnia. Algumas semanas são extremamente quentes. A gente acabou de ter uma onda de calor em que fez... mais de 40 graus por cerca de uma semana seguida. Então isso torna difícil sair. Estamos na Califórnia, onde tem incêndios, então sabe, às vezes passamos uma ou duas semanas em que a qualidade do ar lá fora não é totalmente segura para respirar. Então isso torna difícil ficar ao ar livre na Califórnia em algumas semanas. E aí ficar dentro de casa numa pandemia também é desafiador. Então com certeza tem algumas semanas em que fico muito mais dentro de casa do que em outras. Mas eu gosto de sair. Tem sido, sabe, eu fiquei tipo uns seis meses seguidos fazendo trilhas pelo menos a cada duas semanas. Jonathan: e aí. Isaac: Já tive períodos em que acampei tipo uma vez por mês, sabe, seis meses seguidos. Então tem períodos em que sou melhor e tem períodos em que fico simplesmente dentro de casa por tipo duas semanas seguidas. Jonathan: É, legal. E então, Isaac, qual é o próximo tipo de... Talvez, não sei, talvez você não tenha pensado tão longe, mas como parecem os próximos cinco anos para você em termos de, você tem alguma ideia ou é mais tipo, quero abrir um negócio próprio ou quero fazer isso, ou você está mais tipo, ah, só curtindo a vida e curtindo onde estou? Isaac: Eu, antes de me mudar para a Costa Oeste, achava que tinha uma noção melhor de como seria meu futuro. Mas ter tudo isso de cabeça para baixo me ensinou que é muito difícil prever o que vai acontecer no próximo ano, quanto mais em cinco. Estou bem feliz. Acabei de mudar de emprego há relativamente pouco tempo. Mudei de emprego há uns dois, dois anos e meio. Estou gostando bastante do meu trabalho atual, então não vejo isso mudando tão cedo. Eu ficaria feliz em permanecer no mesmo emprego pelos próximos dois, três anos, cinco anos. Adoro morar na Califórnia. Adoro poder fazer trilhas, andar de bicicleta, acampar e tudo isso. Então não me vejo saindo da Califórnia tão cedo. E não me vejo deixando esse emprego tão cedo porque gosto muito de trabalhar lá. Então estou bem contente e não vejo nenhuma grande, não tenho nenhuma mudança grande planejada, mas é muito difícil dizer. Jonathan: Que legal. Tá, então eu tenho mais algumas perguntas, sobre as quais eu adoraria ouvir sua opinião. A primeira provavelmente não é aquela para a qual eu te preparei, mas é a... Então, se você fosse... Se 10 pessoas entrassem no seu escritório agora, 10 completos desconhecidos, e eles não soubessem nada de programação, e tivesse tipo uma harpista e um jardineiro e sei lá o quê, quais seriam as três principais dicas que você daria para eles aprenderem a começar a programar? Tipo, se você pudesse resumir a tipo, faça isso a todo custo, quais seriam algumas dessas dicas? Isaac: Então a recomendação número um que eu teria é tentar encontrar um problema que você possa resolver com programação. Então você tem um projeto concreto que dá motivação, sem um objetivo específico em mente para te impulsionar. É extremamente desafiador aprender a programar, como qualquer outra habilidade, exige bastante tenacidade ou garra. Você só precisa continuar. Pode ser muito desafiador no começo. Pode ser muito frustrante. Sem algo que te impulsiona, é muito fácil desistir. Então, se for possível, ter algo que você realmente queira fazer com isso ajuda muito. É tudo meio que a mesma constelação de conselhos. É só que você precisa ter, você precisa continuar. Ajuda muito ter paciência consigo mesmo e reconhecer que você está aprendendo uma habilidade nova e que vai falhar muito. Já vi pessoas que tentam aprender programação e se frustram. Elas ficam tipo, ah, eu costumo ser bom nas coisas e isso não funciona de primeira. E eu fico tipo, é, a falha faz parte do processo de aprendizado. E se você se sente desconfortável em falhar em algo, pode ter muita dificuldade em aprender habilidades novas. Você precisa ter paciência consigo mesmo e com o processo, e continuar muito. Jonathan: Isso é útil. Quer dizer, eu diria que é meio que, eu só percebi agora como métodos funcionam. E isso veio de tanto passar por isso, porque muito do conhecimento que, bem, quando as pessoas falam sobre coisas, tem muito conhecimento pressuposto quando as pessoas ensinam, especialmente. Então, tipo, de repente todo mundo fica jogando essa palavra métodos por aí. Eu fico, o que diabos é um método? Tipo, o que está acontecendo? E foi só por meio da turma com Go que comecei a perceber, ah, métodos funcionam deste jeito. Mas foi quase como a ficha caindo, mas eu tive que me imergir nesse ambiente e nessa terminologia por tanto tempo que meio que se infiltra. Eu diria que esse foi um dos maiores aprendizados para mim, não tentar aprender tudo, mas ir tirando de pouco em pouco um conceito simples. Porque tudo se interliga tanto que, eventualmente, você consegue começar a montar o modelo mental, o que é muito importante. Então essa é uma ótima ferramenta. Vou avisar as pessoas sobre isso, que a recomendação do Isaac é: tenha paciência e seja gentil consigo mesmo e vá tirando de pouco em pouco. Isso é bem legal. Tá. Então a última pergunta que eu tenho, e antes de te deixar tocar o resto do seu dia, a gente conversou como equipe sobre esse conceito da causa pela qual você morreria no mercado de tech. Isso soa bem melodramático e bem, com muito drama envolvido. E a ideia é essencialmente: qual é a única coisa que você acredita ser absolutamente essencial, que você considera uma mentalidade ou perspectiva imutável no mercado de tech. Então um bom exemplo seria, sei lá, num nível bem trivial, eu sempre coloco minhas funções e depois escrevo meu CSS se estou fazendo frontend. Então funcionalidade, depois lógica, depois o que for. Poderia ser, sabe, a gente teve uma, a Rebecca, que administra a trilha de Unison. Ela falou algo como: em vez de ter um gênio que é opinativo e difícil de trabalhar, ela preferiria ter 50 pessoas que realmente amam trabalhar em equipe e resolver problemas juntos, do que um gênio que consome toda a largura de banda em termos de gestão. Então essa foi uma das dela, e eu coloquei de forma educada, mas qual seria a sua causa pela qual você morreria no espaço da tecnologia, que é meio que o seu inegociável? Isaac: Isso provavelmente é extremamente influenciado por como o Google faz as coisas. No Google, eles têm esse conceito de readability, em que o código deve ser fácil de ler. E muito do que faço quando escrevo código, quero que meu código seja simples de ler e entender. E já vi muito código, especialmente em código, há muito foco em eficiência e benchmarking e em deixar seu código mais rápido. E muitas vezes eu reconheço que o jeito como estou fazendo não é necessariamente o mais eficiente, mas se eu achar que o código é mais fácil de ler, prefiro código ineficiente e fácil de ler a código supereficiente. Então, tipo, sabe, tem aquela frase comum, não sei exatamente a quem é atribuída, de que a raiz de todo mal, que a otimização prematura é a raiz de todo mal. E sempre que as pessoas dizem: ah, como isso pode ser mais eficiente? Eu respondo: precisa ser mais eficiente? Você esbarrou em, sabe, você está rodando em produção e encontrando problemas de eficiência? Isso é lento demais para usar em produção? Se você na verdade não viveu um problema com o código em produção em que ele precise ser mais eficiente, por que você o tornaria mais eficiente? Está mais fácil de ler como está. É mais fácil de manter. Outras pessoas conseguem entender o que está acontecendo. Por que você abriria mão de um código bem escrito, fácil de trabalhar e fácil de manter, para economizar alguns ciclos de CPU? Será que a eletricidade é barata o suficiente e as CPUs são baratas o suficiente para que não precisemos otimizar código só para otimizar? Jonathan: É, é sempre engraçado porque é uma dessas coisas em que eu fico tipo... nosso programa compilou e rodou em 30 milissegundos. E eles ficam tipo, ah, mas a gente conseguiu baixar para tipo 20 milissegundos. Eu fico tipo, eu não saberia te dizer. Não saberia dizer qual era mais rápido, qual era mais lento. Parece rápido. Então acho que é um bom ponto. Tenho certeza de que eu gostaria de ler seu código, mas isso é ótimo. Isaac, muito obrigado pelo seu tempo, por acordar cedo e por aguentar os apagões no Hemisfério Sul. E por eu estar sentado no escuro completo, tenho certeza de que isso deve ser bem cômico para você. Mas muito obrigado pelo seu tempo. E espero te ver nas próximas turmas de aprendizado e nas transmissões de mentoria e tudo isso. E obrigado por toda a contribuição que você faz para o Exercism e de modo geral. Então, agradeço muito. E é, muito obrigado de novo. E te vejo num instante. Não, o prazer é meu. Se cuida, Isaac. Tchau. Isaac: Muito obrigado de novo. O prazer é meu. Se cuida, Isaac.