Como é a rotina de uma pessoa programadora? - LabeCast #10

Neste episódio do LabeCast, Letícia Chijo e Luciano Naganawa contam os detalhes da rotina de uma pessoa programadora.

Do momento em que você pega o computador para olhar o calendário, faz reuniões, planeja a sprint do momento, senta para codar, corrige bugs, até o release do produto. Sério, é muita tarefa, mas é muito legal!

Luciano Naganawa:

Oi, pessoal! Tudo bem? Eu sou o Luciano Naganawa.

Letícia Chijo:

Eu sou a Letícia Chijo, e esse é o LabeCast, o podcast oficial da Labenu.

Lu:

Oi, gente, no LabeCast de hoje, então, a pergunta vai ser como que é o dia a dia de uma pessoa programadora? Eu gosto muito desse tema, Chijo, porque é um pouco misterioso pra quem está fora do ambiente do dia a dia de uma empresa de tecnologia, da rotina e do ambiente profissional de uma empresa de tecnologia. Acho que as pessoas vão se surpreender um pouco com o que a gente vai trazer aqui. Como que é o dia a dia de uma pessoa programadora? Mas eu gosto de passar um pouco essa rotina, porque é a vida da pessoa, é a vida profissional da pessoa. Então, se você quer entrar na área de tecnologia, você está meio com dúvida ali. Putz, como que vai ser isso? O que será que eu posso fazer isso? Eu acho que entender como é a rotina é interessante. Talvez tenha, teria me ajudado a entender melhor como que é ser uma pessoa programadora. E eu acho que é um jeito interessante de a gente apresentar essa oportunidade, essa profissão, para as pessoas que talvez estejam interessadas aí ou que estejam buscando uma oportunidade profissional que a gente fala tanto que tem no mercado de tecnologia. Vamos montar mais ou menos, ou vamos passo a passo ali, como que vai ser uma rotina de uma pessoa, e depois a gente vai discutindo esses pontos. Para esclarecer, tanto eu como a Chijo já fomos pessoas programadoras de um jeito mais tradicional, trabalhando em projetos com equipes de tecnologia. Então, a gente vai trazer um pouco da nossa experiência, o que a gente observa no mercado também, né? Tanto das empresas que a gente conhece, tantos colegas que a gente tem dentro desse mercado, mas também dos estudantes que vão se formando, começam a trabalhar e assim por diante.

Chijo:

Eu acho que a primeira coisa que eu gostaria de falar não é nem tanto sobre a rotina, mas foi a coisa que acho que mais me surpreendeu no começo, que é o ambiente de trabalho. Eu esperava que fosse uma coisa muito mais séria. Não que não seja sério, programar é uma coisa séria, mas em geral, pelo que eu vejo das pessoas e os ambientes que eu passei são ambientes um pouco mais descontraídos, mais colaborativos ali. Então, muitos escritórios são meio abertos e todo mundo fica trabalhando meio junto e conversando e trocando ideias sobre os projetos e o que vão fazer. E eu não esperava isso. Pra mim foi meio assim: ah, nossa, legal, mas não era o que eu esperava.

Lu:

Isso já dá uma pista que o trabalho de uma pessoa programadora tem mais colaboração do que só sentar e ficar programando. Mas a gente vai falar um pouquinho de como é o dia a dia e discutir um pouco isso. Chijo, vamos tentar resgatar como que era um dia normal. Quando você programava como começava o dia? Qual era a primeira coisa ali no tempo passado e chegava no escritório da sua empresa, do time, junto com seu time de pessoas programadoras ali pra trabalhar. Como era?

Chijo:

Eu chegava e dava bom dia para todo mundo, "oi, gente, tal". Aí pegava o computador, e era engraçado muitas vezes eu nem começava a trabalhar com o computador. Muitas vezes era primeiro conversando com as outras pessoas que estavam no projeto para entender o que aconteceu. Entre a hora que eu saí no dia anterior e momento em que eu cheguei lá, porque também tem um pouco isso, né? Os horários muitas vezes são meio flexíveis. Então, se eu saía cedo, tinha gente que ficava até mais tarde ainda mexendo no projeto. Então acho que quando eu chegava era tentar entender de onde eu tinha que partir num primeiro momento. Então, conversar um pouco com os outros devs, ou principalmente com a P.O. da equipe, que a Product Owner, que era quem cuidava ali das tarefas que estão sendo feitas, que conversa com o cliente para entender o que tem que acontecer e tudo mais. Então tinha muito esse momento de me localizar antes de começar a trabalhar e programar efetivamente.

Lu:

Acho que isso é um ponto superimportante. O ambiente de trabalho, de tecnologia, ele tem esse aspecto, um pouco de ter horários mais flexíveis. Eu lembro que quando a gente trabalhava na mesma empresa, tinha gente que chegava às oito e saía umas cinco. E tinha gente que chegava tipo meio dia e saí às nove. Então, assim a gente tá falando que é um trabalho colaborativo, mas também tem essa flexibilidade, porque você vai ter momentos ali, mais juntos, trabalhando junto, a gente vai falar de reuniões e coisas que tem que tá todo mundo ali fazendo. Mas tem momentos onde as pessoas estão trabalhando, independente e quando tem esse descasamento dos horários, é muito importante ter esses momentos de alinhamento. Não é sempre assim. Eu sei que muitos times gostam de fazer isso, mas na parte da manhã ter uma pequena reunião que normalmente o pessoal chama de stand up ou de daily pra fazer esse alinhamento. Cada um fala o que está fazendo, quais são os problemas que está me bloqueando e que tipo de ajuda eu preciso ali, dentro do contexto da equipe, como que  eram esses momentos para você?

Chijo:

Sempre tinha. Não era tão de manhã, justamente por causa dessa característica que você falou, que tinha gente que chegava depois das dez, mas sempre quando já estava maior parte da equipe. A gente fazia essa reunião que ela chama stand up, justamente, que é para as pessoas ficarem de pé e ela acontecer rápido. E aí às vezes, a gente se alongava um pouco e acabou criando uma versão de você fazer a reunião de prancha para você ir logo também, aconteceu esse momento. Mas a ideia é realmente a gente se atualizar do que cada um está fazendo, contar ali quais estão sendo as coisas que estão te impedindo para ver se alguém consegue te ajudar. E é uma reunião rápida de 15 minutinhos só com a equipe que está naquele projeto. Então, geralmente vai. Quantas pessoas deve ter uma equipe? Umas seis pessoas, não são equipes muito grandes.

Lu:

Entre seis e dez, eu acho.

Chijo: 

Entre 6 e 10 pessoas ali em cada projeto. E essas pessoas não são todas programadoras também. Então vai ter um designer, vai ter um P.O., vai ter, enfim, outras pessoas ali junto e esse é o momento que está todo mundo ali para discutir o que está fazendo e com o que precisa de ajuda, o que está impedindo ali para tirar esses bloqueios do caminho. Então, é um momento que eu acho que é bem comum assim até essa reunião em várias empresas de várias coisas. Na verdade, mas principalmente na programação, eu vejo que é bem frequente e eu acho que é um momento muito bom do dia, porque está todo mundo ali e nem sempre você consegue estar com todas as pessoas. Então é um momento de alinhamento muito importante.

Lu:

Então, também pensando nos momentos ali de começo de trabalho, pelo menos duas coisas que eu acho que eu gostava de fazer e que acho que é bem frequente. E aí a Chijo me fala se também fazia isso. O trabalho ele mudava muito. Você não faz sempre a mesma coisa, tanto na rotina da semana quanto nos projetos. Então, num projeto tem que fazer uma coisa. No outro projeto tem uma coisa completamente diferente, tudo entre aspas, programação, mas tem formas diferentes de fazer, tem tarefas diferentes e assim por diante. São duas das coisas que eu gostava de fazer também nesse horário da manhã. Além do alinhamento com o time, é olhar ferramenta de gestão de tarefas que é um Jira, um Trello tem tantos outros. Onde está ali determinado quais são as tarefas que o time tem que fazer. Normalmente tem tarefas atribuídas para as pessoas. Então, se a gente está desenvolvendo uma rede social. E aí tem que ter várias tarefas para que no final a gente consiga avançar dentro desse projeto. Então, putz, eu tenho que implementar um post. Eu tenho que implementar um comentário, eu tenho que implementar uma feature, um comportamento esperado ali e aí essas tarefas elas têm os cartões, que é a forma de organizar. Normalmente tem um kanban onde você avaliava ali o que tem a ser feito, o que está sendo feito e o que acabou, simplificando, normalmente esses processos são um pouco mais complexos. E ali me orientava muito do tipo a que eu vou focar hoje, o que eu tenho que fazer. Isso é um primeiro passo, são tarefas que eu tenho que implementar. E outra coisa é ver a agenda, porque, como a gente falou, tem várias dinâmicas ali dentro de uma equipe de tecnologia. Então tem, sei lá, reuniões, tem várias dinâmicas que acontecem ali durante a semana e é isso variado dia a dia. Algumas coisas cumprem uma rotina do tipo tem time que toda sexta feira fazia uma retrô, sei lá, mas o jeito mais fácil saber exatamente o que vai acontecer no dia é abrir o calendário, ver as reuniões. E aí você já programa o seu dia, putz eu tenho tarefas pra fazer que eu vi lá no Trello, por exemplo, e eu tenho reuniões que eu tenho que participar. Essas coisas não podem acontecer ao mesmo tempo normalmente. Então eu tinha que organizar o meu dia entre as janelas das reuniões e as tarefas que eu tenho que fazer. Fez sentido isso?

Chijo:

Fez bastante sentido. E eu acho que, unindo um pouco essas duas coisas que você falou, uma coisa que eu acho que também é bastante comum aí na área de tecnologia é a gente ter uma reunião. Então, toda semana, a cada 15 dias, que é uma reunião de planejamento, do que vai acontecer, aonde são escritos esses cards das tarefas, então, normalmente essa figura do P.O. ou P.M., enfim, faz qual é o macro de cada coisa que tem que acontecer ali. Então vai ter uma área de login que tem que ter essas coisas, tudo mais. E aí a gente discute nessa reunião o que a gente tem que fazer agora, como vai priorizar, quanto tempo que leva cada tarefa mais ou menos quem vai fazer cada coisa ali e é o planejamento do que vai acontecer naquela semana ou duas semanas são tempos comuns. Aí que a gente chama de sprint, que é um tempinho que a gente vai se dedicar a fazer determinadas tarefas. E aí, quando termina esse sprint, a gente faz uma nova planning, um novo planejamento, para determinadas tarefas que vão ser naquele novo sprint. Então, o sprint ele pode variar o tamanho normalmente uma ou duas semanas ali, e a equipe se reúne para discutir ah, tá bom, a gente conseguiu fazer as coisas que estava no sprint passado? Agora vamos avançar. Ou, ah não, aconteceu algum problema e a gente não conseguiu terminar tal tela. Então tem que priorizar isso e fazer outra coisa depois.

Lu:

Então, esse é o momento que a gente tem com a equipe para definir quais são essas tarefas. E aí, depois que está tudo definido, você tem lá durante o sprint  as tarefas para ir pegando,  e aí quando você termina, alguém vai testar e se estiver tudo certinho, ela é aprovada e vai lá para o seu aplicativo, para o seu site. Então tem um ritmo de trabalho. A gente chama de sprint, mas são ciclos que variam normalmente de uma ou duas semanas, onde tem um planejamento e tem um tempo de execução. E no final a gente faz uma avaliação da onde a gente chegou e parte dali, do final do ciclo para o planejamento de um próximo ciclo. É um jeito interessante de trabalhar, que tem a ver com práticas ágeis e assim por diante, tem a ver com scrum. Cada empresa aplica essas metodologias de um jeito diferente. Acho que isso é interessante, então cada time, cada empresa aplica, mas tem muitas semelhanças. E o que a gente trouxe aqui se vê presente em grande parte dos times. Como a gente falou, tem muitas reuniões, mas eu queria deixar as reuniões um pouquinho para depois  pro pessoal não se entediar muito. Vamos supor, então, que a gente já viu ali no começo do dia o que tem a ser feito. Já fizemos esses alinhamentos com o nosso time para saber como estão as coisas e aí realizar uma tarefa.  Então acho que uma coisa interessante é que a gente, quando está programado novamente, a gente trabalha em ciclos de tarefas também, ciclos menores, tipo, eu tenho que implementar uma coisa. E aí é a hora de pôr entre aspas a mão na massa de fato, entregar ali alguma coisa que vai chegar no produto. E aí acho que é um momento interessante. Talvez seja o cerne do trabalho da pessoa programadora, apesar de a gente já deixar claro que você não vai ficar fazendo isso a todo momento, não vai só sentar ficar fazendo tarefas, tarefas, tarefas, vai ter outras coisas. Mas talvez seja o core ali do trabalho. E ai, como que era para você, Chijo? Como que você lidava com as tarefas ali, com a programação, a implementação de uma feature, por exemplo?

Chijo:

Eu acho que dentro de uma tarefa, a gente pensa, ah, vou programar várias coisas, mas acho que a menor parte do tempo era programando. Na verdade, primeiro tinha muito aquele momento meio contemplativo do: tá, o que eu tenho que fazer? Primeiro, entender aquela tarefa muito bem, porque às vezes a gente acha que entende, mas não entendeu e ainda tem que refazer tudo. Então eu gosto de ter esse momento de ler direitinho, perguntar para o designer, perguntar para P.O., perguntar para todo mundo envolvido se eu entendi aquilo realmente do jeito que era para fazer e pensar dentro do contexto do projeto, do código que eu tenho, como é uma boa forma de implementar aquilo, então, muitas vezes isso passa por um pouco de pesquisa. Olhar código antigo, pedir ajuda para outros devs, tudo isso antes de começar a pensar e escrever, muitas vezes no papel. Eu gosto muito de papel, de fazer desenho, diagrama para entender todos os fluxos antes de começar a programar. Mas isso também foi algo que eu adquiri com o tempo. Acho que quando a gente é muito iniciante, a gente já quer começar a escrever vários códigos e tal. Só que depois você tem que refazer o negócio tantas vezes que você aprende que é bom, dar uma planejadinha, dar uma entendida ali melhor, então passava muito por isso. Conversar com as pessoas pra entender de fato a tarefa e pensar em como eu vou implementar antes de começar a implementar mesmo. E aí, se a gente fosse passar para programação de fato, estamos falando há tanto tempo com quem estava fazendo, falando de código, quase nada. E aí eu vou dar uma uma parte triste que antes de começar a programar de fato a tarefa, já tinha entendido que eu tenho que fazer. Já tem um plano ali de como programar.

Lu:

Tem uma parte que às vezes tomava mais tempo do que eu gostaria, que é atualizar o código, seja pegar as coisas que as pessoas fizeram nesse nesse meio tempo. Da última vez que eu programei até agora, então só atualizar uma base de código. Mas eventualmente eu vou trabalhar num sistema novo e fazer um projeto do zero. Eu preciso fazer, clonar um projeto pela primeira vez, e esse é às vezes era uma coisa difícil, principalmente quando se trabalha equipes grandes, que têm projetos complexos. Antes de começar a programar, você não programa do zero, numa folha em branco, você já vai trabalhar em cima de um código. E a primeira coisa muito importante que você aprende muito rápido que você tem que fazer. Na primeira semana, já aprende que você não pode deixar de fazer. É atualizar todo o código disponível que você está trabalhando antes, começar a trabalhar e ter certeza que você está trabalhando num ambiente atualizado e funcional. Nem sempre isso acontece.

Chijo:

O famoso "na minha máquina funciona". A primeira vez que você vai rodar o projeto, gente, não vai funcionar. Tá tudo bem, é um processo. Tem em diferentes computadores, diferentes versões das coisas. Então é um processo mesmo, dá um trabalhinho. Mas uma coisa que eu acho muito importante é que as pessoas acham que eu vou começar vários projetos do zero e telas do zero. Gente, isso não vai acontecer. Os projetos, eles muitas vezes já estão lá. Eu acho que depende um pouco da característica da equipe que você está também no lugar que eu trabalhei. Era uma software house. Então, a cada três meses ali a gente trocava de projeto, tinha projetos novos, eram projetos mais curtos. Então criava-se coisas novas com uma frequência um pouco maior. Mas muitas vezes você vai trabalhar em uma empresa que tem lá o site dela e é aquele site para sempre, que você vai mexer. Anos, trabalhando em cima do mesmo projeto. É aí que você tem que fazer um código muito legal, porque você vai viver com aquilo por muito tempo. Então esse acho que é um mito que acontece de ah, vou criar várias telas, vários projetos, e não a maior parte do tempo. Ou você está criando uma parte nova de um projeto que já existe. Mas acho que mais frequente que isso é ficar consertando bugs que você mesmo criou, que seus colegas criaram e foram acumulando. Então, muito do meu tempo era mais corrigindo o bug do que criando coisas novas. A quantidade de tarefas do tipo corrigir um bug realmente era grande, e é isso.

Lu:

Então você está trabalhando ali numa base de código que existe de novo, começar a trabalhar uma base de código principalmente grande traz problema se você gasta um tempo só para organizar o espaço de que você está trabalhando. E aí assumindo que deu tudo certo a gente vai para de fato programar, acho que programar uma feature, no geral, muito do que você vai implementar já existe, então tem várias formas de você implementar uma feature, muitas vezes, principalmente telas. Você vai pegar várias coisas que já existem, vai juntar algumas delas, fazer pequenos ajustes, colocar um código. E é isso ver se funciona. Tem outras estratégias de você implementar features. Então, por exemplo, você pode pegar código da internet, então você dá a pesquisada como que implemento um feed de posts em ordem cronológica. Aí você dá uma pesquisada, você dá uma olhada na internet. Quais estratégias já foram usadas? Como isso pode ser feito em linguagem de programação X, Y, Z? Uma coisa também importante ver se alguém já implementou isso ali dentro do seu time. Às vezes, muitas vezes você desenvolve um código e você vai ver que putz, alguém já fez exatamente a mesma coisa ali dentro do seu código, numa página diferente assim por diante. E grande parte do tempo você vai estar ali juntando peças existentes. Muitas vezes são bibliotecas, então código aberto, open source que você encontra na internet, que ele implementa uma feature, e o que você tem que fazer é trazer essa biblioteca para o seu código. E a implementação tem mais a ver com juntar peças do que de fato escrever muito código. Como era para você?

Chijo:

Eu acho que era exatamente assim. A gente tinha que passar um tempo, principalmente quando eu estava mais no começo, vendo o código que já estava no projeto, porque, por exemplo, me deram uma tela de login que tem dois input. Eu posso criar aquele input do zero e fazer toda a estilização dele para ficar igualzinho, mas alguém já pôs um outro input em outra tela e já está pronto. Então você tem que descobrir onde ele está, descobrir como você usa para manter o padrão do projeto. Se cada um for fazer um input novo, vai ficar 1000 anos fazendo o input. E não faz sentido, porque aí cada página vai estar de um jeito diferente, fica super confuso. Então é sempre ir olhando o projeto, você não vai conseguir olhar todo o projeto, sentar e falar, agora eu vou ver todo o código, não vai, é muita coisa, mas é tentar criando técnicas ali para você encontrar o que você quer. Então, saber pesquisar dentro do seu código e saber pedir ajuda mesmo. Muitas vezes essa questão que o Lu falou de ter coisas que alguém já fez está meio escondido. Você não encontrou ou às vezes já teve algum projeto super parecido na empresa que tem essa lógica que você precisa fazer e alguém já fez. Isso você só vai saber conversando. Você não vai olhar todos os projetos da empresa e tudo mais. Então é muito essa coisa de investigar. É quase um detetive ali tipo, vamos ver se existe isso aqui. Vai procurando pistas até achar onde é que está aquele input que você queria. Então é muito olhar para o seu próprio projeto. E se não tem lá no próprio projeto, aí sim tem na internet. Então eu acho que é sempre uma mistura das coisas que já tem com as coisas novas que você vai pesquisando e aprendendo. E aí, com o tempo, depois que você faz 20 telas de login, aí você decora como que faz e isso sai da sua cabeça, e tudo bem. Mas no começo é muito comum. Acho que isso também é algo que o pessoal que é junior, os nossos estudantes se preocupam muito do tipo mas toda hora eu tenho que ficar olhando o código de referência. Toda hora eu tenho que ir no Google porque eu não sei fazer nada sozinho. Gente, ninguém sabe. Está tudo bem, tá todo mundo olhando o código de referência, está todo mundo olhando stack overflow. porque acho que essa é uma característica interessante da profissão. Você não precisa decorar coisas, você precisa entender como elas funcionam e saber pesquisar e saber integrar aquilo no seu código. Eu acho que a maior parte do trabalho não é uma coisa super criativa que sai da sua cabeça. São coisas que você vai pesquisando e juntando e fazendo funcionar.

Lu:

Desmistifica um pouco o trabalho do programador daquela pessoa que putz nossa! sei fazer um código excepcional, ou que só uma pessoa muito fora da caixa, que entende coisas complexas e que de fato tem mais que seguir padrões e seguir boas práticas de código de trabalho ali dentro do time. Muita pesquisa, muita investigação, como você falou, e a gente vai para o próximo passo, que eu acho que é tão importante quanto essa implementação. Vamos dizer que você encontrou ali soluções dentro do código, um pouco na internet. Você pensou um pouco, refletiu, escreveu um pouco de código e você conseguir implementar a feature. Eu acho que todo mundo que programou gasta um tempo ali fazendo um teste do que você implementou, porque você vai escrever o código, ele vai fazer sentido para você, mas você tem que ver o comportamento, se tá adequado ou não. E é isso que a gente faz rodando o código. Normalmente você roda num ambiente da sua própria máquina, um ambiente de testes ali que a sua empresa tem. E você mesmo está testando: isso aqui que eu escrevi, o que acontece quando esse código de fato roda? E a gente vai para um ciclo ali de testar e ajustar o código, que pode ser de forma automatizada, com testes automatizados. E aí você simplesmente tem que rodar os testes e ver se você passou nesses testes automatizados. Uma coisa que tem um pouco de polêmica ali pessoas que gostam mais, pessoas que gostam menos. Mas você tem que de alguma forma testar, garantir que o que você implementou ali está fazendo algum sentido e está tendo, pelo menos na sua opinião, um comportamento esperado. 

Chijo:

Quando você acha que você terminou de fazer a tarefa, muitas vezes você descobre que você não está nem na metade porque se fez ali o fluxo principal. Mas você precisa pensar nos erros possíveis que vão acontecer ali. Então, se a pessoa colocou login e senha e colocou a senha errada, ela não pode conseguir entrar no aplicativo. E se ela colocou a senha errada, o que tem que fazer? Tem que mostrar uma mensagem. Então é ir testando fluxos diferentes e ver se aquilo de fato está completo, porque muitas vezes as tarefas são meio genéricas. Tipo, sei lá, fazer uma tela de login, muitas vezes são descritas bonitinhas, depende do projeto, mas enfim, às vezes é algo mais genérico. Mas você não pode simplesmente entregar uma tela que faz o login com qualquer e-mail e qualquer senha. Tem que funcionar, tem que estar tudo direitinho. E esse momento de testar é para evitar que essa tarefa volte para você mesmo depois. Então, agora que você está com a cabeça focada nisso, aproveita e estressa aquilo. Faz vários testes de várias coisas, faz teste automatizado e aí, quando estiver pronto, você fala: Agora eu acho que está funcionando. Passei por vários casos aqui, e aí você pega, e acha que esse código já está pronto e o usuário vai usar? Não, está bem longe ainda. Primeiro a gente vai pegar esse código e pedir uma permissão para colocar ele no projeto, que a gente faz o pull request, que é para pedir para colocar esse seu pedacinho de código no projeto inteiro e alguém da sua equipe vai fazer um code review, que é uma revisão do que você escreveu. Então, Lu falou você acha que você terminou ali, que está ótimo, então ai vai vir seus coleguinhas pra ver se está ótimo mesmo ou não.

Lu:

Isso é uma coisa super importante. São várias pessoas trabalhando na mesma base de código e o padrão de mercado que todo mundo faz é esse ciclo de você programa dentro de um ambiente ali que é seu, e você não está influenciando o código diretamente das outras pessoas ao mesmo tempo. É um pouco complexo essa questão de git, colaboração, parte técnica, mas pensa que você está ali testando você mesmo dentro da sua máquina, no seu device de teste. Você falou: putz, acho que está funcionando. Gostei do código que eu escrevi, está funcionando. Agora eu vou falar putz, eu tenho essa implementação. Eu tenho esse código que eu quero que ele vá pra base de que todo mundo está usando. E nesse momento é importante ter esse processo de pedir, de deixar claro quais são as adições e remoções do código que você está propondo e aí uma pessoa fazer o review disso. E acho que review tem dois principais objetivos, que é o teste de sanidade para ver se o que está acontecendo está fazendo sentido e muitas vezes as pessoas, uma pega das outras, e putz, isso aqui está faltando alguma coisa e tal. É uma coisa que você tocou Chijo, hoje, que é bem importante é que a qualidade do código, a organização e os padrões ali de como fazer as coisas precisa ser mantido, para o código ele está limpo e está organizado, para ele está seguindo um padrão que todo mundo concorda e isso é um super passo importante para ter ali, quando vai ter essa revisão do código.

Chijo:

Eu acho que às vezes, quando a gente está num projeto que está meio atrasado, que a gente não dá a devida importância para esse tipo de coisa. Mas o projeto é isso. Quem vai continuar mexendo nesse código é você e sua equipe, provavelmente. Então se está desorganizado, gente, sua cabeça não vai lembrar porque que você fez de um jeito x ou de um jeito Y, sabe? Então você tem um padrão sistema, uma organização. Fica mais fácil tanto de você voltar para consertar algum errinho ali que foi achado ou agora mudou completamente o feed, a gente vai fazer um algoritmo novo. Você precisa entender aonde que estava antigo, que você precisa mudar. Então essa parte de ter padrões e documentar esses padrões, ela às vezes parece, assim, eu não vou fazer agora porque estou com pressa. Não é o foco, mas é muito importante fazer isso para não atrasar tudo depois. E parece que é algo que não vai ter valor naquele momento. Mas você só vai perder mais tempo depois para entender o que aconteceu. Com certeza é bom manter esses padrões e os times, o rigor dos times varia bastante, mas acho que é interessante ter  esse processo, todo mundo usar ele faz com que a gente mantenha um mínimo de qualidade ali.

Lu:

É interessante. Assumindo que seu código foi aprovado, e muitas vezes, você entra num ciclo do tipo puts faz essa alteração aqui e você ajusta seu código. Ver que isso testa de novo, faz outro pull request, isso pode ter vários ciclos, mas assumindo que depois de algumas poucas alterações, seu código for aceito, ele pode ser o que a gente chama de "mergeado", que é você juntar esse código à base de código de todo o mundo, e aí o seu código agora faz parte da base de códigos que todo mundo compartilha. Não é um código que está só na sua máquina. Ele é um código que está ali em ambiente de nuvem, provavelmente de todos os pessoas que compartilham essa base de código. Importante lembrar que não necessariamente isso já implica que seu código vai estar disponível para o usuário. Então, normalmente tem um outro ciclo de release, que acho que é o melhor jeito de falar, de você lançar uma nova versão do seu produto e o seu produto, contemplar os códigos mais recentes que foram incorporados.

Chijo:

É isso, geralmente a gente junta o nosso código, ali, com a base das outras pessoas, das outras pessoas desenvolvedores, e cria uma versão para alguém testar. Então essa versão é uma versão meio interna, não é do que vai ser o usuário final e vai ser bem testado ali para pegar qualquer errinho. Então, quando você faz uma tarefa de criar uma tela de login, por exemplo, será que você não quebrou alguma outra coisa que já estava pronta e você nem testou? Então alguém vai lá, vai testar o produto como um todo, ver se estar funcionando direitinho. E aí, depois que está tudo aprovado e não vai ser de primeira, talvez nem de segunda. E acho que até é uma coisa importante de falar. Os programadores mais iniciantes ficam às vezes muito frustrados com o quão errado as coisas dão. E essa é uma coisa que eu já adianto para vocês, que vai ser um erro atrás do outro mesmo, tá? A gente trabalha muito com tela vermelha explodindo na nossa cara. Tá tudo bem! Com o tempo, você se acostuma porque é isso, não é que você vai conseguir de primeira, tipo, peguei um código da internet juntei com o que tinha aqui, apareceu e deu tudo certo. Isso é bem improvável, na verdade. E não é porque você é júnior não, gente. Isso acontece com todo mundo para sempre, ficar dando erros faz muita parte do trabalho. Então eu sei que no começo pode ser um pouquinho frustrante, mas é isso, não é você que está fazendo nada muito errado. Faz parte do processo de criar alguma coisa, que ele dê errado, que apareça erros para você. Mas não só isso. Às vezes ele funciona. O seu programa roda bonitinho lá no celular, onde for, mas vai ter algum comportamento inesperado. Então esse é um outro tipo de erro que vai acontecer, que alguém vai identificar e vai passar para a equipe corrigir e não se sinta frustrado quando isso acontecer. Porque vai acontecer. Acontece com todo mundo. Tem casos que a gente não prevê e outra pessoa vai lá e testa. Tem casos que a gente só vê que deu errado quando o usuário usa e fala que deu errado. Então isso é bem normal. A gente não tem como prever todos os casos ali. Óbvio que com experiência você vai ganhando, ali vai… os erros mais comuns que aparecem, você já fala: ah, não, esse aí eu já fiz 20 vezes. Agora sei como arruma.

Lu:

Mas faz parte do processo ter muitos erros. Isso acho que lidar com com esses imprevistos e, na verdade, toda a rotina da equipe que está programando em todos os processos, todas as ferramentas estão muito adequadas a isso, de tem muitas prevenções para você testes automatizados, processos de teste de qualidade. O código não vai direto, tem um review, tem depois um processo de release, tudo isso porque a gente sabe que erros vão aparecer no processo e é melhor pegar eles em desenvolvimento, em teste do que no final do usuário, porque ali que está no usuário, aí tem um impacto de negócios, e desfazer uma coisa ali em produção, é um pouco mais sofrido. Então é um trabalho ali que contempla esse ciclo de testar, errar, refazer e corrigir. Até que a gente fique satisfeito com o que a gente está entregando.

Chijo:

E aí eu acho que depois de passar por todo esse processo de juntar código, testou e corrigiu todos os erros, aí vem essa parte de publicar o projeto para as pessoas conseguirem usar que é outra parte, que parece que vai ser fácil, mas nunca é fácil. Gente, principalmente, eu acho que com aplicativos que foi essa experiência que eu tive de subir os aplicativos na loja tem várias regrinhas que você tem que seguir. Aí você manda lá para eles revisarem e aí eles encana com uma picuinha pequenininha e tem que trocar essa letra pra minúscula. E aí você tem que ir lá, trocar, gerar uma versão nova, testar e enviar. Então, essa questão de publicar o seu site, seu aplicativo para as pessoas usarem. Ela também leva um tempo e dá um certo trabalho.

Lu:

Com certeza. Então, acho que a gente passou pelo ciclo completo de implementar uma feature, um comportamento ali e realizar o que a gente poderia chamar de tarefa, no dia de uma pessoa programadora, vários passos a gente está ali falando Putz, como que é o dia a dia? Mas acho que essas etapas, às vezes, elas tomam vários dias de uma pessoa programadora. Então, putz, num dia de manhã eu fiz a implementação. Aí eu pedi o code review, e o code review às vezes demora um, dois dias para acontecer e você fica meio travado ali tem que fazer umas outras coisas. E aí, nesses ciclos de teste, pode ter um vai e volta de tipo. Putz, encontrei uma coisa e volta, corrige e assim por diante. E essas coisas que a gente falou elas podem acontecer ao longo de vários dias. E aí é importante a pessoa programadora se organizar contemplando isso também. A tarefa não vai ser feita e vai estar pronta e aprovada de um dia para o outro. É um ciclo, então as pessoas vão se acostumando com esse ritmo. Eu vou fazer uma tarefa e ele vai para um ciclo de aprovação, um ciclo de teste. Aí eu tenho que ir adiantando uma outra tarefa que eu estou fazendo traz uma complexidade ali de trabalhar questões de git, que às vezes dá um pouquinho de ruim. Mas do ponto de vista de rotina, eu acho que é isso. As tarefas, as coisas, não a programação em si.

Chijo:

Eu acho que normalmente a etapa de programação, na grande maioria dos casos, tarefas mais simples, que se atém ali a um dia ou um momento que você senta programa. Mas o ciclo ali de aprovação de code review, toda essa parte, acaba tomando pouco mais de tempo. Algumas pessoas se frustram pouco com isso. Eu prefiro eu mesmo sozinho aqui programando, que eu mesma aprove e vou seguindo, mas é uma coisa que você tem que se acostumar. E é importante as equipes e as empresas terem esse ritmo e não deixar que isso, que esse ritmo atrapalhe o fluxo do projeto como um todo. Por exemplo, se um code review demorar uma semana, você atrapalhou muito a rotina da pessoa programadora e o avanço do seu projeto. É importante a gente entender esse ritmo e ter ferramentas e processos para garantir que ele aconteça da melhor forma. Sim, e inclusive o próprio code review também é uma tarefa que faz parte do dia a dia da pessoa. A gente falou de você, receber uma revisão, mas você também revisa o código dos amiguinhos. Então, muitas vezes eu gostava inclusive de fazer isso mais no início do dia, então chegava, já via todos os PRs que tinha aberto, dava uma analisada ali comentava, se estava tudo ok, aprovava e tudo mais. Então isso também é uma rotina que vai fazer parte do seu dia a dia.

Lu:

Às vezes tem que pagar uma cerveja pro coleguinha aprovar o seu código, porque fica um pouquinho difícil.

Chijo:

E outra coisa que você falou que eu achei interessante dessa parte realmente de programar, de pegar uma tarefa e fazer. Tem tarefas que duram duas horas, tem tarefas que duram três dias e varia muito do que você está fazendo. Tem coisas que você nem sabe quanto tempo vai durar, principalmente quando investigar algum bug estranho. Você não sabe o que está errado, então você não sabe se vai demorar dez minutos ou uma semana. Já aconteceu algumas coisas estranhas comigo nesse sentido. Tipo, ah, vou fazer essa tarefas acho que eu termino em uma semana e está lá um mês depois, fazendo a mesma tarefa. Tem algumas coisas que são mais previsíveis, mas tem outras que não são tanto. E tudo bem. Às vezes sempre importante comunicar com a equipe o que está acontecendo, porque se vocês falaram, eu acho que isso aqui leva dois dias, mas a tarefa era mais difícil do que a gente pensava e levou uma semana. Precisa se adaptar ao planejamento e tudo mais. Mas isso também é uma preocupação que nossos alunos trazem bastante, de: Se falaram que a tarefa vai durar duas horas, eu sou iniciante, eu vou levar cinco horas, e agora o que vai acontecer, tipo, não, gente. É tranquilo. Primeiro que quando você é junior, as pessoas sabem que você demora mais para fazer as coisas e está tudo bem. Mas tendo essas reuniões diárias com a equipe, vocês vão sempre se atualizando. Então, eu estou demorando mais nessa tarefa, porque eu precisei usar uma ferramenta que eu não conhecia e eu estou estudando. Está tudo bem. É uma coisa que é dinâmica ali.

Lu:

Acho que deu uma resumida ali, grande de como que é de fato o trabalho de você colocar uma implementação, uma feature dentro do seu código. Vamos voltar para as reuniões, Chijo? Não vamos gastar muito tempo aqui, mas é isso. Dentro de uma rotina de uma pessoa programadora. Assim, intencionalmente ou não, a desgosto a gosto das pessoas. Acabam acontecendo essas reuniões têm uma frequência grande e que tipo de reuniões assim eram mais comuns quando você trabalhava como pessoa programadora?

Chijo:

Eu acho que trabalhando nessas metodologias ágeis, a gente tem algumas reuniões meio clássicas. Então a gente já falou da daily que é essa que acontece todos os dias e da planning que acontece no início de cada ciclo para planejar aquele ciclo. Mas tem mais algumas. Então, por exemplo, quando você está terminando um ciclo, é interessante ver o que aconteceu, o que deu certo, o que deu errado, pegar umas métricas ali para enfim ir melhorando nas próximas. Então a gente chama essa de review, retrô, varia o nome. Ela é basicamente para a gente entender tudo que aconteceu, o que deu errado, que a gente pode melhorar para não acontecer no próximo, entender o que está bloqueando ali, o que é o projeto e tudo mais. Então tem essa, tem uma que é um pouco mais voltada para como a equipe está naquele momento. Então tem essa que é um pouco mais números, o que aconteceu e, enfim, entender se as tarefas foram feitas ou não. Mas também existe uma outra, que é um pouco mais voltada para como a equipe lidou com aquelas situações e como a equipe está interagindo. Como é que está se sentindo naquele momento com aquelas tarefas, se tem alguém muito sobrecarregado, tudo mais. Então, para ir pensando, enfim, de forma geral, em como está a equipe naquele momento. Às vezes, acontecem reuniões com os próprios clientes do projeto que você precisa ter uma pessoa técnica ali para ajudar, para opinar e tudo mais. Então essas não são tão frequentes assim, do tipo toda semana tem, em geral, não é tão frequente, certinho assim, mas em alguns momentos do projeto alguém vai ter que conversar com o cliente, entender o que tem que ser feito. Então também tem essa. Tem algumas reuniões, às vezes, que abrangem várias pessoas da empresa e não só a sua equipe. Então, normalmente as empresas têm um momento de atualização do que está acontecendo ali em geral, ou enfim, mostrar os projetos, dar informes. Então essa também acontece com alguma frequência, falei várias, Lu, o que você acha?

Lu:

Eu acho que tem algumas reuniões, que é por você está fazendo parte de um time, de uma organização. Então tem, aqui na Labenu, a gente faz o all hand,  uma reunião ali quinzenal com todo mundo da empresa. Isso faz parte de uma dinâmica organizacional, mas você faz parte de um time. Então, às vezes você tem 1:1 com as pessoas, mentorias. Às vezes você tem coisas organizacionais que você tem que fazer análises de desempenho, feedback, tudo, várias coisas que tem a ver com coisas do dia a dia de trabalho, não tanto a ver com a programação. E tem algumas que estão mais direcionadas aos projetos, ao produto que você está fazendo. Então é importante a pessoa que está programando, ela vai ter, a gente falou de dinâmica de time, de alinhamento, do que o time está fazendo, entendimento do que tem que ser feito, uma revisão do que a gente fez. Mas também tem uns momentos que você tem que interagir, por exemplo, com clientes. Como você falou, ou com outras áreas da empresa. Você trabalha num produto grande. Vai ser importante você trabalhar com reuniões ou conversas com time de operação, com o time de marketing, porque o produto e a implementação, tem a ver com o produto, é que você não vai ficar focado, eu vou fazer e funcionar. Você tem que entender qual o objetivo, qual é o negócio, como que isso impacta um usuário, como o que impacta uma pessoa da operação? Caso seja uma ferramenta interna, então a pessoa programadora, os times de programação precisam ter essas dinâmicas.

Chijo:

Acho que a melhor forma de trabalhar, ou a mais bem vista hoje em dia é que a própria pessoa programadora participe dessas dinâmicas para não ser uma coisa tão descolada. Às vezes tem gente que acha o P.O. ou o P.M.  vai fazer isso. Eu quero só programar me fala o que tem que fazer, eu quero só programar, mas não, na prática, a gente vê que você está lá conversando com as pessoas que vão usar o produto ou que entendem de uma área da empresa que que é importante para o seu produto, vai te dar um entendimento. Você vai conseguir explicar muitas coisas do produto, o que pode, o que não pode? Quais são as ideias que você tem e quais as ideias que as outras áreas da empresa tem? Esse é uma dinâmica muito rica, muito importante também para acontecer. E é importante estar nessas discussões, até mesmo para ver às vezes a viabilidade de algumas coisas, porque às vezes alguém pensou vamos fazer um botão que gira incrível, em um dia, e você fala, pô, não dá. Precisa de mais tempo. Se a gente fizer um botão que só gira um pouquinho, então são coisas que ter o conhecimento técnico e tá nessas conversas para tomar algumas decisões, é bem importante. E mesmo no dia a dia também você está lá fazendo o seu código. Você fala, Nossa, a gente previu fazer desse jeito, mas esse outro jeito é bem legal e não é muito mais difícil. Eu acho que eu consigo fazer aqui. Então, você começa a entender melhor o produto. Entender o objetivo dele. Você consegue dar mais um feedback do que você acha que pode funcionar bem também e vai construindo mesmo esse produto junto com todo mundo. Não vai só executar tarefas ali no dia a dia.

Lu:

E eu sei também, Chijo, tem algumas reuniões técnicas que as equipes fazem. Varia de empresa para empresa, como é feito, mas normalmente tem uma dinâmica ali. Por exemplo, todos os programadores de front end se juntam e aí conversam sobre o que está sendo feito ou tem algum tipo de treinamento, palestra essas discussões técnicas. Elas são bem importantes e fazem que você colabore num escopo além do seu time, geralmente, seu time, ele trabalhando ali dentro de um escopo determinado, mas às vezes tem outras pessoas da empresa que estão fazendo coisas semelhantes ao que você faz. Mas num contexto diferente, a empresa pode ter vários produtos ou pode ter um produto que tem várias features, e as pessoas são separadas, então tem algumas reuniões técnicas mais transversais. Às vezes até com gente fora da empresa também faz parte do dia de trabalho.

Chijo:

E é bem interessante porque a gente falou muito de manter o padrão dentro de um projeto, mas é legal manter o padrão dentro de todos os projetos da empresa. Isso fica mais difícil. É claro que não vai ser 100% padronizado ali, mas você ter esse momento de trocar uma ideia com todos os desenvolvedores de uma área, falar nossa, a gente está usando uma biblioteca nova que eu achei que é muito legal ensinar mais ou menos como usa, ter esses momentos às vezes é uma apresentação, às vezes é mais uma conversa, mais de trocar mesmo as experiências. É bem importante, é bem enriquecedor mesmo. Era um dos momentos que eu gostava mais assim. É bem legal e tem um foco muito grande em aprendizado de empresas de tecnologia.

Lu:

Então tem um foco em colaboração, aprendizado e interações ali dentro da equipe das equipes para tanto alinhamento de produto, mas também para as pessoas estarem bem ali. Eu acho que isso é uma ênfase grande e aí acaba que você não está, de tudo que a gente falou, a parte de programar, mesmo escrevendo código, ficou a parte pequenininha. Umas horinhas ali por dia.

Chijo:

Eu acho que depende muito do momento também que você está naquele projeto que, dentro do ciclo de desenvolvimento dentro da sprint, vai ter no começo, talvez um pouco mais de reuniões para definir as coisas, aí no meio você consegue desenvolver um pouco mais e depois as pessoas começam a testar e voltam algumas coisas. Então acho que dentro de um ciclo não é frequente, tipo, vou programar duas horas por dia, todos os dias. Não é muito constante assim, mas dentro de um ciclo as coisas vão se repetindo. Por isso que é um ciclo. E aí você consegue ir entendendo essa rotina um pouco melhor com o tempo e depende da empresa. Depende de muitas coisas e isso ela varia um pouquinho ao longo do tempo e vai ter dias que você talvez nem programe. Acontece um dia que juntou um monte de reunião umas discussões de como a gente vai fazer tal tela. Não sei o que. Vai ter dias que você vai ter um monte de tarefa para fazer. Vai ficar codando o dia inteiro, então varia um pouco. Mas eu acho que a gente quis trazer um pouco aqui é que é isso você não vai só programar o dia inteiro, sabe? Tem muitas etapas que compõem aquele produto que vai chegar no final.

Lu:

E aí, Chijo. Vamos tentar dar uma resumida, então, como que seria um dia? E eu acho que no começo do dia você vai ali talvez fazer uma reunião de alinhamento com seu time, olhar o seu calendário, sua ferramenta de gestão de tarefas pra ver o que você já fez, o que está sendo feito e o que tem para fazer. Talvez um algumas horas programando as features. Manda esses códigos ali para revisão. Aproveita esse tempo ali pra rever um código de um colega. Acho que é importante ter esse ritmo ali diariamente está revisando o código dos colegas, faz algumas reuniões com equipes de operação, com a sua própria equipe. Acho que uma média de uma ou duas reuniões por dia talvez seja o mais frequente ali dentro das equipes. Às vezes vai aumentando essa quantidade e essa frequência aí prejudica um pouquinho o dia a dia de trabalho. Muita pesquisa, né, Chijo, de do que fazer, muita refaturação de código, que é você pegar o código que você escreveu e refazer ou pegar um código antigo e melhorar. E aí tem algumas coisas pontuais ali que vai depender do dia, tem o dia de release que é sofrido, às vezes um pouco tenso. Tem uns dias que você vai participar de mais dinâmicas ali da empresa. Vai ter uns dias que você vai ter a oportunidade de conversar com os outras pessoas técnicas da empresa para conversar, trocar informações. E varia, é isso, acho que é uma rotina que não é tão repetitiva. E eu gostava dessa parte de poder ter várias dinâmicas diferentes. 

Chijo:

E inclusive uma parte que eu gostava trabalhando numa empresa que tinha vários projetos, era ter a possibilidade de mexer em projetos diferentes também, porque aí você vai aprendendo com os devs que estavam em cada equipe. Então é um trabalho que pode ser bem variado ali, no dia a dia. Então acaba que não cansa tão rápido. Eu acho.

Lu:

Acho que é isso. Eu dei uma resumida boa ali de como que funciona ali o dia a dia de uma pessoa programadora. Eu acho que a gente quis trazer mais alguns pontos, que são mais frequentes, mas varia de contexto, de equipe e de empresa. E acho que é interessante quando você vai encontrar uma nova equipe, uma nova empresa que vai ter a oportunidade de trabalhar, entender como que é essa dinâmica. Mas eu acho que, no geral, as empresas que seguem as práticas que a gente colocou aqui estão bem frequentes, bem representadas no mercado. Provavelmente, você não vai fugir tanto disso. E eu gostei de relembrar como eram as nossas dias de programadores, Chijo, obrigado, e espero que tenha ajudado a esclarecer aí para o pessoal como funciona o dia a dia de uma pessoa programadora. 

Chijo:

E se vocês gostaram, aí se identificaram com esse dia a dia e considerarem virar uma pessoa programadora dá uma olhadinha lá no site da Labenu para conferir o nosso curso: www.labenu.com.br e vê lá as turmas que estão abertas e se inscreve para fazer o curso aí com a gente. Então é isso, gente, tchau tchau! Gostou do episódio de hoje? Você pode interagir com a gente lá pelo Instagram. O nosso perfil é: @labenu_ e a gente pode discutir mais sobre o assunto de hoje. A gente também disponibiliza as informações do episódio, a transcrição lá no nosso blog: www.labenu.com.br/blog

Lu:

Por fim, você pode acompanhar os episódios do LabeCast no YouTube, no Spotify ou em todas as plataformas de áudio. A gente lança episódios novos toda terça feira.

Chijo:

Se você gostou do episódio, já deixa seu like, ativa o sininho para receber as notificações dos próximos episódios e se inscreve no canal, até a próxima!