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 estar acompanhado pelo Isaac, que é um dos nossos mantenedores e colaboradores e que recentemente deu imensa mentoria a muitos estudantes nas nossas GoHorts, as nossas turmas de aprendizagem, que fizemos durante 30 dias, acho que já duas vezes, sobretudo em Go e Elixir. E o Isaac ajudou no percurso de Go, o que foi fantástico. Por isso, Isaac, sê muito bem-vindo. Podes contar-me um pouco onde vives, de onde vens e como entraste no setor tecnológico?

Isaac: Sim, estou na Califórnia. Vivo em San Jose, na Califórnia. A verdade sincera é que entrei no setor tecnológico porque o meu irmão mais velho andava nesse meio e eu fazia tudo o que ele fazia. Tinha muitos irmãos. Gostávamos de estar uns com os outros, ou alguns de nós gostavam mais de estar com uns do que com outros. Tinha um irmão mais velho com quem gostava muito de estar. Ele não gostava necessariamente tanto de andar comigo, mas eu passava muito tempo a segui-lo por todo o lado e a querer fazer o que ele fazia. Ele pegou num livro do C for Dummies que estava por casa quando tinha uns 15 anos, e eu tinha 9, se não me engano. E ele estava a escrever C, e eu pensei: se ele está a fazer isso, também vou fazer. Os meus programas eram bastante simples e básicos para essa idade. Eram mais do tipo: qual é o teu nome, olá Bob. Exercícios desse género. Não eram muito complexos. É preciso começar por algum lado. Tive de começar por ali. Eu pensei: ah, podes imprimir o caráter do ficheiro visual e ele faz um som. Que fixe. Escrevi um programa que literalmente só imprime uma barra e um A. Mas eu estava a começar aos 9 anos. Estava a escrever programas em C. Tínhamos uma máquina antiga com Windows 3.1 que arrancava em DOS, e o meu irmão tinha montado um script batch que, quando o computador arrancava, mostrava um menu onde podias escolher, por exemplo, iniciar o Windows, iniciar jogos, havia um menu de jogos. Podias escrever, por exemplo, 5 para o Warcraft ou o que fosse. Por isso eu escrevia scripts batch, à medida que instalávamos outros jogos e coisas do género. E a partir daí foi só a progredir. O meu irmão foi para a universidade estudar engenharia informática e, mais uma vez, pensei: se ele faz isso, também vou fazer. Comecei a escrever C aos 9 anos. Escrevia... Visual Basic 6 no secundário. Tinha um Palm Pilot e escrevia vários programas no Palm Pilot no secundário. O meu professor de matemática era muito porreiro. Estava numa daquelas escolas à moda antiga...

Jonathan: Era aquela coisa tipo... lembras-te de que tentaram lançar aquilo que era como o pré-iPad, e mais ou menos, algumas pessoas puseram as mãos nisso e tinha aquela coisinha de rabiscar com a caneta. E toda a gente achava que era super fixe porque saía pela ponta, e era tipo zoop, e depois podias ir tocando nela. Era mais ou menos... não... Lembro-me sempre disso porque depois começou a aparecer o iPad e toda a gente dizia: ah, foi um pouco cedo. O Palm Pilot estava só um bocadinho à frente do seu tempo, sabes o que quero dizer?

Isaac: Foi excelente durante uns dez anos, mas sim, havia o Palm Graffiti que usavas para escrever. Havia um pequeno painel de entrada, e tinhas de escrever carateres, mas eram mais ou menos baseados no alfabeto. Por exemplo, o A era como um triângulo e o F era o ângulo reto. Sim, o meu professor de matemática do secundário dizia: olha, se escreveste o programa, não há problema se o quiseres usar no teste. Por isso escrevia programas para o Palm Pilot no secundário, o que era muito fixe. Fui para a universidade estudar Engenharia Informática. As pessoas falavam de linguagens de scripting. Eu não sabia bem o que eram, por isso peguei no Perl ao calhas. E depois acabei o mestrado, e fui contratado pela Google. Em 2013, mudaram-me da Costa Leste para a Califórnia. E foi aí que peguei no Python, há cerca de uma década. E o Python tem sido a minha linguagem principal na última década. Estive na Google, por isso o meu estilo é muito influenciado pelo estilo da Google. E é por isso que tenho escrito principalmente assim. E depois, há cerca de... quatro anos, acho que em 2018 ou assim, a Google começou a promover a linguagem Go internamente e foi aí que peguei no Go.

Jonathan: Fixe. E Isaac, quando falas do estilo da Google, havia uma noção estabelecida de que esta é a maneira certa de fazer as coisas, ou é mais... como é que... desenvolve um pouco isso, porque é interessante.

Isaac: O estilo de programação não é necessariamente a maneira correta de fazer as coisas, mas sim uma maneira uniforme que todos devem seguir. Diz-se que um bom compromisso, ou um bom acordo, é um acordo em que ninguém fica satisfeito. Ninguém está totalmente satisfeito com o guia de estilo, mas desde que todos o sigam, o código parece uniforme. Isso significa que qualquer pessoa pode pegar em qualquer pedaço de código na base de código da Google e fazer alterações, e desde que siga as mesmas diretrizes de estilo, o código é todo uniforme, não tens de pensar: ah, esta base de código usa indentação de quatro espaços e esta usa dois, ou esta tem uma convenção de nomes assim ou assado. Tudo, em toda a base de código, é feito da mesma maneira. Ninguém está completamente satisfeito com nada disto. Cada um tem as suas áreas em que gostaria que fosse feito de outra maneira, mas, dado que existe um guia de estilo documentado, que está disponível publicamente, basta pesquisares no Google pelo Google Python style guide e ele diz-te: é assim que escrevemos código na Google. Desde que todos se mantenham fiéis a esse guia, o código parece todo muito uniforme, o que é muito bom: podes abrir qualquer base de código e não há surpresas do género: ah, eles escreveriam isto de outra maneira.

Jonathan: É por isso que o Go talvez se encaixe tão bem nesse contexto? Porque é formatado e é mesmo assim, é assim que é. Vê-se perfeitamente a influência da Google nisso.

Isaac: Sim, não sei até que ponto o Rob Pike foi influenciado pela abordagem da Google ou até que ponto foi ele que a influenciou. Não sei qual veio primeiro, mas o Go leva isso definitivamente a outro nível, em que... Há ainda mais... por exemplo, no Python há estilos diferentes e as pessoas ajustam os seus linters para aceitar coisas diferentes. Por exemplo, internamente a Google usa indentação de dois espaços em Python porque há muito código profundamente aninhado e não querem ter uma parede enorme 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 sim, no que toca ao Go, levaram isso a outro nível e disseram: a própria linguagem tem a formatação integrada. Só há uma maneira de formatar. Não há debates sobre qual é a maneira correta. Só há uma maneira.

Jonathan: Poupa imensas discussões de vai e vem. Digamos assim, talvez. Sim. Muito bem.

Isaac: Sim.

Jonathan: Então, ok, quando começaste na Google, nunca tinhas feito Python ou já tinhas mexido um pouco, ou foi uma transição fácil? Como... porque fizeste parecer que arranjaste o trabalho na Google e depois foi tipo: ok, fixe, aprende Python, vamos a isso.

Isaac: É isso. Acho que antes de entrar na Google nunca tinha escrito Python. Estive a escrever Perl durante um ano ou dois. Acho que comecei a escrever Perl uns dois anos antes disso. Foi no meu primeiro trabalho de verão. É uma história completamente diferente. Comecei a escrever Perl seis anos antes de entrar na Google, por isso na altura já escrevia bastante Perl. Escrevia também um pouco de Bash, por isso estava familiarizado com linguagens de scripting. Mas nunca tinha escrito Python. Mas depois de mexeres em linguagens suficientes... A curva de aprendizagem é um pouco menos íngreme para aprender outra linguagem, porque já viste a maior parte das construções e é só uma sintaxe ligeiramente diferente, um conjunto de ferramentas ligeiramente diferente. Mas é muito a mesma coisa, só um pouco diferente, escrito de outra maneira. As construções tendem a ser bastante semelhantes. Por isso, depois de aprenderes quatro linguagens, aprender uma quinta é tipo: ah, isto é só escrito de maneira um pouco diferente.

Jonathan: Sim, sim. Isso é interessante. Então riste-te um pouco quando falaste do teu primeiro trabalho, logo a seguir ao secundário. Então, tinhas sempre pensado: vou seguir a engenharia, vou fazer a coisa dos computadores? Isso foi sempre um pensamento consciente ou era mais: é simplesmente onde me encaixo naturalmente, gosto disto e pronto. Como é que isso...

Isaac: Acho que sim. Eu estava claramente a tentar seguir os passos do meu irmão. Ele foi para engenharia informática. Começou a escrever programação. Começou a programar quando eu era miúdo. Eu segui-o. Escrevia programação desde pequeno. Ele foi para engenharia informática e era isso, sabes, eu queria fazer o mesmo que ele e também me estava a divertir imenso a programar e tudo isso. Por isso, desde que entrei no secundário, e o meu irmão já estava na universidade, eu sabia que era ali que queria acabar.

Jonathan: Ele é alguns anos mais velho do que tu, por isso parece que teve uma influência enorme em ti como pessoa. Quantos outros irmãos tens? Ou ele era simplesmente o máximo aos teus olhos?

Isaac: Tenho oito irmãos, mas ele era sem dúvida aquele com quem me dava muito bem. É um deles... acho que me dou melhor com uns do que com outros. Quando tens oito, há sempre uma escala. Dava-me muito bem com ele. Tendemos a pensar de forma muito semelhante. Tendemos a ter interesses semelhantes. Passávamos o tempo todo a falar de computadores com entusiasmo. Ainda hoje o fazemos. A mulher dele não gosta que isso se torne a conversa da mesa de jantar. Ela diz: nada de trabalho à mesa do jantar. Nós falamos de programação com entusiasmo o tempo todo e conversamos sobre isso constantemente. É muito difícil dizer quanto era só eu a querer copiá-lo e quanto era simplesmente termos interesses semelhantes. Sem dúvida que hoje temos interesses semelhantes. Não sei quanto disso é natureza e quanto é criação. Não posso realmente dizer quanto disso é eu a copiá-lo e quanto é simplesmente termos interesses semelhantes. Mas, dado que segui os seus passos desde muito cedo, eu seguia e ele, de certa forma, ia abrindo o caminho, e eu seguia-o.

Jonathan: Sim, isso é muito fixe. E ele, onde está agora? Só por curiosidade, está na Costa Leste?

Isaac: Continua na Costa Leste, trabalha no setor tecnológico. Chegámos a trabalhar na mesma empresa durante um breve período.

Jonathan: Sim, ok, fixe. Então é isso. É fixe. Só tinha curiosidade em perguntar. Agora, uma das coisas... estiveste muito envolvido na turma que acabámos de ter. Então, a última turma de aprendizagem, sobretudo com Go, estávamos a fazer uma coisa de 30 dias com Go, tipo... e depois o teu envolvimento com o Exercism antes disso tem sido mais especificamente na manutenção, mas também bastante mentoria, pelo que percebo. Como tens encarado essa divisão? Quer dizer, como é que descobriste o Exercism e quais são os diferentes aspetos para os quais gostas de contribuir?

Isaac: Descobri o Exercism originalmente porque estava a tentar reaprender Haskell. Fiz uma aula introdutória de Haskell na Google que foi bastante divertida. E depois pensei: ah, devia dedicar mais tempo a isto. E isso acabou por ficar de lado. E depois tentei voltar a isso.

Jonathan: e vemo-nos para a próxima.

Isaac: Com qualquer linguagem, acho que a maneira mais fácil de a aprender é escrevê-la de facto. A maneira mais fácil de a escrever é ter um objetivo para a escrever. Não encontrei um grande objetivo para escrever Haskell, o que tornou muito difícil de aprender. Mas descobri o Exercism e pensei: ah, isto pode ajudar-me a escrever mais Haskell. Foi assim que descobri o Exercism. Assim que lá cheguei, pensei: ah, há um percurso de Python e um percurso de Shell e montes de exercícios aqui dentro, por isso... e lá fui eu pela toca do coelho abaixo.

Jonathan: E lá foste tu pela toca do coelho abaixo.

Isaac: Sim. Comecei a resolver exercícios em Python. Comecei a resolver exercícios em Bash. Fiz alguns dos exercícios de Go. Quando surgiu a Go Horde e eu estava a rever algumas das minhas soluções anteriores, vi que muitas tinham sido submetidas três anos antes. Então, inscrevi-me no percurso de Go pela primeira vez em 2019 e resolvi uma boa parte desses exercícios nessa altura. E entretanto já andava com Python há uma década. Por isso senti-me relativamente à vontade para me juntar como mentor de Python, que é onde passo a maior parte do meu tempo com exercícios atualmente. E depois comecei a submeter PRs, pull requests, no percurso de Python porque havia coisas fora do sítio. E depois comecei a envolver-me no percurso de Bash. E não sei bem como aconteceu, mas passei de submeter correções no percurso de Bash a ser mantenedor de Bash.

Jonathan: Assim, de repente? Quer dizer, é como: tem cuidado com aquilo em que te inscreves, não é?

Isaac: Sim, e depois o Glenn escreveu o percurso de Ock e eu pensei: ah, eu conheço Ock, gosto de Ock, deixa-me entrar nessa onda. Por isso ajudei a construir os exercícios no percurso de Ock. Não tenho a certeza absoluta, mas penso que há três anos, quando vi os Exercícios de Go, completei o percurso inteiro e depois um dos mentores disse: ah, acabaste todos os exercícios, talvez devesses tornar-te mentor. Não sou suficiente... não escrevo Go com frequência suficiente, com regularidade suficiente para me sentir à vontade a dar mentoria nisso. Por isso não era propriamente um mentor de Go. Mas depois, quando me juntei à Go Hort e havia imensas pessoas que queriam mentoria, pensei: ah, acho que podia inscrever-me como mentor durante o mês e ajudar ali. Mas na verdade juntei-me recentemente à Go Hort como estudante. E depois vou deslizar da secção dos estudantes, suponho.

Jonathan: Eu acabei de deslizar da secção dos estudantes, suponho. Cuidado com aquilo em que te inscreves. Digo-te, parece estar a surgir um padrão em que te inscreves numa coisa e acabas noutra, mas isso é muito fixe. Ok, então, em termos de quando tens dado mentoria a estudantes no percurso de Go especificamente, quais são algumas das coisas mais comuns que vês? Quer dizer, o percurso de Go, provavelmente houve bastantes programadores experientes, diria eu, que o fizeram, pessoas com algum historial em desenvolvimento, mas quais foram algumas das coisas que notaste que te fizeram pensar: ok, estas são as coisas comuns em que as pessoas parecem ficar presas? Havia algum padrão ou coisas que encontraste que fossem tipo: ok, isto é comum, isto aparece com bastante... regularidade, potencialmente.

Isaac: Não sei. A maior parte da mentoria que tenho visto tem sido com pessoas que já completaram as soluções. As pessoas, mais frequentemente que não, já resolveram o exercício antes de pedirem mentoria. Por isso, na maioria das interações que tenho, as pessoas geralmente não estão presas. Por isso, é sobretudo... sabes, completaram um exercício com sucesso e depois muito do contributo é: sabes, haverá uma maneira mais eficiente de fazer isto? Haverá um algoritmo melhor? Uma das coisas comuns que surge demasiadas vezes é a construção de strings, em linguagens como Go e Python, onde as strings são imutáveis, fazer muita concatenação de strings não é muito eficiente. Por isso é muito do tipo: olha, podias construir isto usando um array e depois juntar as strings, ou podes usar um string builder em Go. Por isso há muito de, sabes, empurrá-los para melhores, digamos, padrões, boas práticas e padrões. Obrigado por assistirem.

Jonathan: Ok, isso é fixe. Isso é fascinante. Então, atualmente, como é o teu dia a dia de trabalho, em termos de onde é que o desenvolvimento se encaixa? Digamos que estás no setor tecnológico há algum tempo; como é que é o dia? Quais são os desafios? Quais são as partes de que gostas no trabalho neste momento?

Isaac: Estou numa função de engenharia de fiabilidade de sites, que é mais ou menos semelhante a DevOps. Tem alguma coisa de administração de sistemas. Tenho andado com um pager numa escala de piquete na última década, mais ou menos. Por isso o meu dia a dia depende muito de ser ou não a minha semana de piquete. Quando estou de piquete, é sobretudo vigiar o pager, há uma fila de tickets, uma fila de suporte, garantir que quaisquer processos em falha ou problemas sejam diagnosticados e corrigidos. Isso é mais ou menos uma semana em cada seis, ou conforme o tamanho atual da equipa. E no resto do tempo, estou de piquete.

Jonathan: Mm-hmm.

Isaac: Passo muito tempo a mexer em automatização, por isso é muito identificar processos que são complicados e torná-los menos complicados. Pode ser que... Pode haver uma razão para isso acontecer, mas geralmente acho que, até algo começar... sabes, quando este problema acontece, temos de executar, sabes, reparamos manualmente fazendo estes comandos e aqueles comandos, e é tipo: bem, porque é que estamos a executar estes comandos à mão? Podemos escrever um script Python que faça tudo isso por ti? Ou podemos melhorar as ferramentas para que não falhem e detetem elas próprias esse problema? E muito de simplesmente tentar melhorar o dia a dia de como gerimos os sistemas, de modo que os humanos estejam menos envolvidos ou não precisem de estar tão, sabes, tão profundamente envolvidos para manter as coisas a funcionar sem problemas.

Jonathan: Então, o teu dia... gostas de tentar encontrar essas pequenas áreas onde as coisas podem ser otimizadas? Quanto do teu trabalho é reagir a coisas e depois, a partir dessa reação, pensar: ah, fixe, esta é uma oportunidade, em vez de procurar proativamente essas pequenas áreas? Qual é normalmente o equilíbrio?

Isaac: Gosto de automatização; provavelmente é a coisa de que mais gosto no meu trabalho, poder automatizar coisas. Nem sempre é reativo. Quer dizer, reativo pode significar que algo se avaria, mas também pode ser: ah, sabes, as pessoas executam este comando, e dei por mim a ver que há este comando que costumamos copiar e colar; posso melhorá-lo? Ou vejo alguém a fazer uma alteração a um runbook em qualquer sítio ou a melhorar um comando em qualquer lado e penso: ah, esse comando está uma confusão, posso simplesmente reescrevê-lo de raiz? E claro, é preciso ter atenção a isso, tem de ser equilibrado com o apelo, tem de ter menos palavras grandes, uma linguagem melhor, esse tipo de coisas. Tens de conseguir dominar isso tentando fazê-lo. Honestamente, tudo no meu trabalho acaba por se encaixar, se penso nisso. Sou uma pessoa muito motivada, por isso... o meu trabalho, suponho, é o que é, mas em qualquer trabalho de que gosto, ... está lá só para tentar...

Jonathan: produzir, poder-se-ia dizer.

Isaac: Refatoração, notar que há ferramentas que são, sabes, complicadas de usar e decidir reescrevê-las ou escrever wrappers à volta delas. Vejo, sim, vejo alterações de código em qualquer programa grande e complicado e penso: ah, esse programa é uma confusão. Posso entrar e reescrevê-lo ou refatorá-lo? Ou criar coisas novas; quer dizer, nem sempre é refatoração, às vezes é simplesmente criar ferramentas novas. É tipo: ah, temos um processo que envolve 20 passos, deixa-me só meter isso tudo num programa. Muito disso tende a ser... sabes, tenho de descobrir estas coisas de alguma maneira. Às vezes descubro-as porque me atribuem um conjunto de tarefas e depois penso: não quero executar isto à mão. Às vezes descubro-as simplesmente por reparar, tipo, estou a procurar um pedaço de código em qualquer sítio e penso: ah, este outro código aqui, que outra equipa mantém, está a fazer as coisas mal, deixa-me refatorar isso, ou usar bibliotecas modernas ou o que seja, sim.

Jonathan: Então muito de... simplesmente conseguir ver. Então quanta liberdade tens? Tens bastante liberdade para andar por aí e intervir, ajustar aqui e ali? Quer dizer, isso deve ser bastante divertido, bastante agradável.

Isaac: O meu gestor dá-me muita liberdade, o que é muito bom. Não sei até que ponto isso vem de... já não estou na Google, mas não sei até que ponto isto vem da minha experiência na Google. Na Google, as pessoas estavam muito abertas a intervir e dizer: ah, reparei nisto, sabes, calhou usar esta biblioteca e podia ser melhorada desta maneira. Deixa-me lá corrigi-la. Trabalhei muito, muito brevemente numa startup onde a cultura era muito diferente, era muito menos aberta. E na startup, as pessoas eram muito protetoras em relação às suas bases de código e não aceitavam muito bem que outras pessoas lhes alterassem o seu código. E eu dizia: ah, há um problema com esta base de código. Vou mesmo mudá-la.

Jonathan: Sim, recua. Mas isso é interessante porque... assume-se que uma startup seria muito mais do tipo: bem, só é preciso fazer o trabalho e fazê-lo o mais barato possível, sabes, mas na verdade talvez a Google estivesse muito mais preparada para lidar com isso como conceito. E isso... desculpa, acabei de acender as luzes porque nós... neste momento não há luz, para todos os que estão a ouvir, de vez em quando não há eletricidade na Cidade do Cabo. Agora mesmo estou a cegar-me, mas não faz mal. Mas isso é interessante, voltando àquele ponto sobre a cultura das startups e como as pessoas, ironicamente, estão muito mais presas à ideia de terem a posse das coisas e depois talvez a travarem um pouco as coisas, sabes?

Isaac: Sim, não sei se ser uma startup se combina necessariamente bem com ser uma cultura de trabalho aberta, digamos, baseada na brincadeira. Na Google, muito do que as pessoas faziam era brincar, no sentido de que gostavam do que faziam. Fazem-no porque gostam. Eram muito amigáveis em relação a isso, ou muito abertos a isso. Outras culturas de trabalho são mais, menos sobre fazer as coisas porque gostas e mais sobre: é um trabalho, ou este é o meu código e eu sei como isto funciona. Não quero que outras pessoas mexam nele. Não tenho bem a certeza do que é necessário para fazer estas mudanças de cultura de trabalho. Mas a Google fomentava claramente um sentido de que todos têm acesso a todo o código. Todos têm o poder de fazer alterações. Vai em frente e faz o que achares que é a coisa certa a fazer. E no meu trabalho atual, com o meu gestor atual, ele também me deu muita liberdade. Ele diz: claro, encontraste algo para corrigir. Vai em frente e corrige-o. Encontraste uma área onde as coisas podem ser melhoradas. Eu saio simplesmente do teu caminho. Diz-me o que posso fazer para ajudar. Por isso consigo, em grande medida, dirigir sozinho muito do que faço e, sabes, se encontro uma área onde penso: ah, podia melhorar isto. Ele diz: sim, isso é fixe, vai em frente.

Jonathan: Ok, ótimo. E tu... a empresa está sediada na Costa Leste, estou certo ao dizer que trabalhas na verdade remotamente? Penso que me lembro de te ouvir dizer que estavas prestes a mudar-te para lá, e depois chegou a COVID e foi mais ou menos isso, toda aquela coisa chegou ao fim. Como estás a lidar com o remoto, a distância, o fuso horário, esse tipo de coisas? Afeta-te ou...?

Isaac: Sinto sem dúvida falta de estar num escritório e de interagir com as pessoas cara a cara. Portanto, há isso; o fuso horário... a minha equipa tem sido muito compreensiva com a diferença horária. Estou três horas atrás do resto da minha equipa. Há uma pequena reunião diária de que falto. Temos duas reuniões diárias para dois produtos diferentes. Por isso, à primeira falto, e a minha equipa tem sido muito boa a acomodar-me nisso e usamos muito o Slack internamente. Por isso, são muito bons a ter uma thread diária no Slack com os problemas que surgiram para eu poder pôr-me em dia, e se precisarem de alguma coisa, contactam-me. Eu esforço-me por ser responsivo e trato de tudo isso o mais depressa que consigo de manhã. Portanto, é um pouco... o fuso horário não é o ideal, mas também não é... temos conseguido lidar com isso bastante bem. E, inversamente, há o outro lado, em que eles sabem que têm alguém na equipa que está acordado um pouco mais tarde. Por isso já tive colegas, sabes, eram 6 da tarde na Costa Leste e diziam: ah, isto está avariado. Sabes, olha, o Isaac está na Costa Oeste, o Isaac podia ajudar-me com isto porque lá ainda são só 3 da tarde. Portanto, funciona nos dois sentidos. Sim, e...

Jonathan: Sim.

Isaac: Eu... sim, saí da Google em 2019, desculpa, em 2020. Fiz a entrevista em 2019. Devia entrar em maio de 2020. Estava a planear mudar-me em agosto... abril de 2020, mas começou a COVID e tudo isso, o escritório fechou e foi muito do tipo: ah, o escritório ainda não está aberto. Ele muda-se assim que o escritório abrir. E depois, dois anos dentro da pandemia, começaram a reabrir o escritório. E eu pensei: sabes, já não tenho a certeza se quero mudar-me. Nova Iorque parecia muito entusiasmante, mas havia todos aqueles negócios abertos e, sabes, espaços e coisas a acontecer. Mas agora que há uma pandemia, muito disso já não soa tão entusiasmante. Por isso passei para um cargo remoto depois de trabalhar remotamente durante dois anos.

Jonathan: E tu és uma pessoa de cidade, de campo, ou mais a meio caminho? Tipo o quê? Porque Nova Iorque é cidade. É 100% cidade. Quer dizer, não há duas maneiras de o ver. Sabes o que quero dizer? Por isso seria uma mudança bastante grande, suponho. Sim. É entusiasmante, ainda assim.

Isaac: Cresci numa grande área metropolitana, por isso a vida na cidade não me é estranha. Atualmente vivo nos subúrbios. Gosto de fazer caminhadas e de andar de bicicleta e tento estar ao ar livre o mais possível. Por isso gosto de viver nos subúrbios, perto de trilhos fantásticos para caminhadas e bicicletas e tudo isso. Mudar-me para Nova Iorque seria uma mudança considerável. Mas penso que variar de vez em quando não é mau. E se odiar a minha vida em Nova Iorque, posso sempre mudar-me.

Jonathan: Não é assim tão complicado fazer isso. Mas é fixe. Então agora provavelmente, corrige-me se estiver errado, passas muito tempo em frente ao ecrã, num escritório, num escritório em casa ou o que seja. Tipo, sais todos os dias para... como é que equilibras todo o mundo do ecrã versus... tens um momento diário em que dizes: tenho de sair e estar ao ar livre e fazer outra coisa?

Isaac: Gostava de o fazer. Há dias, ou meses, ou anos em que sou melhor do que noutros. Em 2020, era bastante disciplinado a andar de bicicleta quase todos os dias. Saio à rua na maioria dos fins de semana. Tento fazer uma caminhada por semana. Não tenho sido muito bom nisso, mas vou dar uma caminhada. Depende da estação. Estou na Califórnia. Há semanas extremamente quentes. Acabámos de ter uma onda de calor em que estiveram... mais de 40 graus Celsius durante cerca de uma semana seguida. O que torna difícil sair à rua. Estamos na Califórnia, onde há incêndios, por isso às vezes passamos uma ou duas semanas em que a qualidade do ar lá fora não é totalmente segura para respirar. O que torna difícil estar ao ar livre na Califórnia em algumas semanas. E depois estar dentro de casa numa pandemia também é difícil. Por isso há sem dúvida semanas em que estou muito mais dentro de casa do que noutras. Mas gosto de sair à rua. Já houve, sabes, períodos de seis meses em que fiz caminhadas, saí para caminhar pelo menos de duas em duas semanas.

Jonathan: e depois.

Isaac: Já tive períodos em que fui acampar uma vez por mês, sabes, durante seis meses seguidos. Por isso há períodos em que sou melhor do que noutros, e há outros em que fico simplesmente em casa, tipo, duas semanas seguidas.

Jonathan: Sim, isso é fixe. E então, Isaac, qual é o próximo tipo de... Talvez, não sei, talvez não tenhas pensado tão à frente, mas como é que são os próximos cinco anos para ti, em termos de... tens alguma ideia, ou estás mais do tipo: quero montar um negócio meu, ou quero fazer isto, ou estás simplesmente tipo: ah, aproveitar a vida e gostar de onde estou.

Isaac: Antes de me mudar para a Costa Oeste, pensava que tinha uma ideia mais clara de como seria o meu futuro. Mas ver tudo isso virado do avesso ensinou-me que é muito difícil prever o que vai acontecer no próximo ano, quanto mais daqui a cinco. Estou bastante feliz. Mudei de trabalho há relativamente pouco tempo. Mudei de trabalho há cerca de dois, dois anos e meio. Estou a gostar bastante do meu trabalho atual, por isso não vejo isso a mudar tão cedo. Ficaria contente por permanecer no mesmo trabalho nos próximos dois, três anos, daqui a cinco anos. Adoro viver na Califórnia. Adoro poder fazer caminhadas, andar de bicicleta, acampar e tudo isso. Por isso não me vejo a sair da Califórnia tão cedo. E não me vejo a deixar esse trabalho tão cedo, porque gosto bastante de trabalhar lá. Por isso estou bastante satisfeito e não vejo nenhuma mudança grande, não tenho nenhuma mudança grande planeada, mas é muito difícil dizer.

Jonathan: Isso é fixe. Ok, tenho mais um par de perguntas, sobre as quais gostaria muito de ouvir a tua perspetiva. A primeira provavelmente não é aquela para que te preparei, mas aquela... Então, se fosses... Se 10 pessoas entrassem agora no teu escritório, 10 completos estranhos, e não soubesses nada de programação, e tivesses, sei lá, uma harpista e um jardineiro e o que fosse, quais seriam as três principais dicas que lhes darias para aprender a começar a programar? Tipo, se pudesses resumir a: faz isto a todo o custo, quais seriam algumas dessas dicas?

Isaac: A recomendação número um que eu teria é tentar encontrar um problema que possas resolver com programação. Assim tens um projeto concreto que dá motivação, sem ser preciso um objetivo específico em mente para te fazer avançar. É extremamente difícil... aprender a programar, tal como qualquer outra competência, exige uma boa dose de tenacidade ou determinação. É preciso simplesmente não desistir. Pode ser muito difícil ao início. Pode ser muito frustrante. Sem algo que te leve por diante, é muito fácil desistir. Por isso, se for possível, ter algo que realmente queiras fazer com isso ajuda muito. É tudo mais ou menos da mesma constelação de conselhos. É só que tens de ter... tens de não desistir. Ajuda muito teres paciência contigo próprio e reconheceres que estás a aprender uma nova competência e que vais falhar muito. Já tive pessoas que tentam aprender a programar e ficam frustradas. Dizem: ah, normalmente sou bom nas coisas e isto não funciona logo à primeira. E eu digo: sim, falhar faz parte do processo de aprendizagem. E se te sentes desconfortável a falhar em algo, podes ter muita dificuldade em adquirir novas competências. Tens de ter paciência contigo próprio e com o processo, e muito de não desistir.

Jonathan: Isso é útil. Quer dizer, eu diria que isso é mais ou menos... só agora percebi como funcionam os métodos. E isso foi só por ter passado por isto, porque muito do conhecimento que... bem, quando as pessoas falam de coisas, há tanto conhecimento que se assume quando ensinam, especialmente. Por isso, de repente, toda a gente anda a atirar com a palavra métodos para o ar. E eu penso: que diabo é um método? O que se passa? E foi só através da turma com Go que comecei a perceber: ah, os métodos funcionam desta maneira. Mas foi quase como a ficha a cair, só que tive de me mergulhar neste ambiente e nesta terminologia durante tanto tempo que acaba por se entranhar. Diria que uma das maiores aprendizagens para mim foi não tentar aprender tudo, mas ir trabalhando um conceito simples de cada vez, aos poucos. Porque tudo se interliga tanto que, eventualmente, consegues começar a juntar o modelo mental, o que é muito importante. Por isso é uma ótima pequena ferramenta. Vou dar a conhecer isso às pessoas, essa recomendação do Isaac: tem paciência, sê gentil contigo próprio e avança aos poucos. Isso é muito fixe. Ok. Então a pergunta final que tenho, e antes de te deixar continuar com o resto do teu dia: falámos, enquanto equipa, deste conceito da causa pela qual darias a vida no setor tecnológico. Isso soa bastante melodramático e bastante... com muito drama envolvido. E a ideia é essencialmente: qual é a única coisa que acreditas ser absolutamente fundamental, que consideras uma mentalidade ou perspetiva inabalável no setor tecnológico. Um bom exemplo seria, não sei, a um nível muito trivial: eu coloco sempre as minhas funções primeiro e só depois escrevo o meu CSS, se estiver a fazer front end. Portanto, funcionalidade, depois lógica, depois o que for. Poderia ser, sabes, tivemos um caso, a Rebecca, que gere o percurso de Unison. Ela dizia: ter um génio que é opinativo e difícil de aturar. Ela preferia ter 50 pessoas que adoram trabalhar em equipa e resolver problemas em conjunto do que um génio que ocupa toda a largura de banda em termos de gestão. Portanto, essa foi uma das dela; e eu frasei-o de forma simpática, mas qual seria a tua causa pela qual darias a vida no setor tecnológico, aquela que é o teu inegociável.

Isaac: Isto é provavelmente muito fortemente influenciado pela maneira como a Google faz as coisas. Na Google, têm este conceito de legibilidade, em que o código deve ser fácil de ler. E muito do que faço quando escrevo código: quero que o meu código seja simples de ler e de entender. E já vi muito código, especialmente... no código, há muito foco na eficiência e no benchmarking e em tornar o código mais rápido. E muitas vezes reconheço que a maneira como o estou a fazer não é necessariamente a mais eficiente, mas se achar que o código é mais fácil de ler, prefiro código ineficiente mas fácil de ler a código super eficiente. Por isso, sabes, há aquela citação comum, não sei exatamente a quem é atribuída, de que a raiz de todos os males, de que a otimização prematura é a raiz de todos os males. E sempre que as pessoas dizem: ah, como é que isto pode ser mais eficiente? Eu digo: é preciso ser mais eficiente? Já te deparaste com... sabes, estás a correr em produção e a deparar-te com problemas de eficiência? Isto é demasiado lento para usar em produção? Se nunca experienciaste de facto um problema com o código em produção, em que ele precise de ser mais eficiente, porque é que o tornarias mais eficiente? É mais fácil de ler tal como está. É mais fácil de manter. Outras pessoas conseguem entender o que se passa. Porque é que abririas mão de código bem escrito, fácil de trabalhar e fácil de manter, para poupar uns ciclos de CPU? A eletricidade é suficientemente barata e as CPUs são suficientemente baratas para não precisarmos de otimizar código? Só para o otimizar.

Jonathan: Sim, é sempre engraçado porque é uma daquelas coisas em que eu penso: o nosso programa compilou e correu em 30 milissegundos. E eles dizem: ah, mas conseguimos baixá-lo para uns 20 milissegundos. E eu penso: não te sei dizer. Não te conseguia dizer qual era mais rápido, qual era mais lento. Isso parece rápido. Por isso acho que é um bom argumento. De certeza que gostaria de ler o teu código, mas isso é ótimo. Isaac, muito obrigado pelo teu tempo, por acordares cedo e por aturares os cortes de energia no hemisfério sul. E por me aturares sentado na escuridão completa; de certeza que isso deve ser bastante cómico para ti. Mas muito obrigado pelo teu tempo. E estou ansioso por te ver nas próximas turmas de aprendizagem e nas sessões de mentoria e tudo isso. E obrigado por todo o contributo que dás ao Exercism e em todas as frentes. Agradeço muito. E sim, muito obrigado mais uma vez. E vejo-te já a seguir. Não, foi um prazer. Porta-te bem, Isaac. Adeus.

Isaac: Muito obrigado mais uma vez. Não, foi um prazer. Porta-te bem, Isaac.