Atualizando-se com podcasts de tecnologia

Uma coisa que eu acho muito legal no lugar em que trabalho é que as entrevistas relacionadas a novas contratações são responsabilidade de todos na empresa independente da experiência. Uma vez com uma lista de interessados (que qualquer um pode fazer parte), o time de recrutamento marca as entrevistas de acordo com a disponibilidade dos envolvidos, de forma que sempre seja uma dupla entrevistando, com pelo menos uma pessoa com experiência. Ao fim das várias entrevistas os interessados se reúnem e compartilham suas impressões.

Além de deixar o processo de contratação bastante transparente, não sobrecarrega poucos indivíduos e faz todos se sentirem parte disso, fora que ajuda a evitar algum viés que naturalmente ocorre quando uma só pessoa fica responsável por todo um processo.

Graças a essa prática, já tive a oportunidade de entrevistar vários candidatos, especialmente em entrevistas técnicas. Uma das perguntas que muitas vezes costumo fazer é como a pessoa costuma se informar sobre novidades na área de tecnologia. Normalmente as respostas variam entre blogs e conversas com os amigos. Em menor número é citado o Twitter, livros e listas de email.

Todas essas são excelentes ferramentas para se atualizar sobre as novidades, entretanto uma forma bastante interessante de se atualizar que eu pouco ouvi ser mencionada nessas entrevistas foi podcasts. Existem atualmente uma gama de podcasts abordando o tema de tecnologia. É uma forma de se atualizar que complementa muito bem as demais e que descobri somente recentemente, pois embora soubesse da existência de muitos podcasts sobre tecnologia, não sabia que existiam específicos para desenvolvedores e analistas. Esses podcasts normalmente reúnem pessoas com bastante conhecimento no assunto, com uma abordagem mais leve do que um livro mas não menos informativa. Alguns reúnem inclusive escritores de publicações, palestrantes e pessoas bastante ativas nas comunidades de tecnologia. São excelentes oportunidades de ouvir conversas e discussões bastante enriquecedoras sobre temas que nem sempre temos um amigo ou um conhecido falando sobre.

Existem uma infinidade de podcasts, e o jeito é garimpar pela internet, mas entre os que eu tenho escutado e recomendo:

Tecnologicamente Arretado: Um podcast relativamente novo criado pelo ThoughWorker Gregório, com capítulos sobre diversos temas da atualidade como Segurança, AngularJs, Programação Funcional entre outros temas. Sempre com a presença de convidados que manjam muito do assunto.

Grok: Um dos podcasts mais antigos do Brasil com mais de 4 anos de atividade, e talvez também o mais famoso. Excelente fonte de informação, não apenas sobre tecnologias, mas também com edições sobre conferências como RubyConf e mulheres em TI.

Pra quem tem o inglês afiado, as opções são muitíssimas, mas fica a dica do Functional Geekery, que trata especificamente de programação funcional mais a fundo. No caso de podcasts em inglês, além do conteúdo propriamente dito, é uma ótima oportunidade para treinar o ouvido pra discussões que não são em Português.

Como passei a gostar de TDD

Já é lugar comum a importância de testes automatizados em desenvolvimento de software. Não somente pela confiança que eles dão ao desenvolvedor na hora de fazer refatorações e correções de bug, mas também porque para ter testes em todos os níveis, o código precisa necessariamente ser testável.

Código testável, isto é, aquele em que dependências podem ser facilmente isoláveis, não é algo sempre trivial de fazer. Normalmente requer um design mais criterioso em que os pedaços de código sejam distribuídos em classes pequenas e coesas, caso contrário,  os testes ficam muito grandes, trabalhosos e as vezes até mesmo impossíveis de fazer. 

Sendo assim, a presença de testes está não somente influenciando pela sua presença per se, mas também pela consequente melhora no design que a inclusão deles forçou acontecer.

É por isso que era um pouco reticente com TDD. Se o programador não abre mão dos testes, pra mim pouco importava se os testes eram escritos antes ou depois da feature propriamente dita.

Entretanto com o tempo acabei mudando de opinião. Acredito que design (pensar em como resolver o problema) e codificação (a escrita de código) não são atividades isoladas. É necessário codar para ter insights sobre o design, assim como para codar é necessário pensar no design que se quer atingir. Design e codificação são atividades que devem andar juntas pois há uma simbiose natural nelas. 

Portanto, para mim, a forma de codar mais efetiva é aquela em que mescla design e codificação o máximo possível para um retroalimentar o outro, num algoritmo que seria mais ou menos assim:

1. Coda um pouquinho
2. Analisa o design da solução
3. Volta pro passo 1 até terminar a feature

Dessa forma, o código está em constante evolução, em vez de codar toda a solução, ver que não gostou e refatorar tudo de uma vez (o que eu costumava fazer quando implementava os testes depois da feature, nada ágil).

Codando dessa maneira, TDD se encaixa como uma luva no desenvolvimento, pois cada caso de teste e sua implementação até ficar verde ficam sendo a perfeita unidade de medida e ponto para reavaliar o andamento do design.

Onboardings efetivos

Quando um integrante novo é adicionado a uma equipe de desenvolvimento, é padrão (mesmo que informalmente) fazer algum tipo de onboarding, isto é, uma introdução as regras de negócio e a arquitetura do sistema. Esse onboarding pode ocorrer de muitas maneiras, mas normalmente ocorre com integrantes mais seniors do time explicando em linhas gerais o que for julgado necessário, e em times que exploram pair programming esse processo continua naturalmente até o novo integrante se tornar tão habituado como os demais. Pair programming é extremamente efetivo nesse caso (especialmente quando é uma equipe acostumada com isso, e não apenas uma forma de onboarding).

Infelizmente, a maior parte das empresas e seus times não são habituados ao pair programming, e nesse caso, após as explicações iniciais, normalmente o novo integrante recebe uma tarefa e deve executá-la sozinho, com a premissa de que pode pedir ajuda sempre que necessário.

Entretanto, as vezes a própria disposição das mesas na empresa (por exemplo cubículos) ou mesmo uma personalidade mais introspectiva pode desestimular perguntas. Embora possa acontecer com qualquer nível de senioridade dependendo da personalidade e especialmente do grau de auto-exigência / ansiedade em colaborar logo, isso fica ainda mais crítico quando o desenvolvedor a ser agregado ao time tem pouca experiência profissional codando (por exemplo um estagiário ou desenvolvedor júnior).

Nesse caso, a preocupação compreensível de estar "atrasando o projeto" com perguntas "óbvias", ou tomando tempo dos outros desenvolvedores que certamente tem tarefas "mais essenciais ao projeto" fica ainda mais evidente. Isso constantemente leva esses desenvolvedores a perguntar menos e tentar resolver suas tarefas sozinhos com ajuda de ferramentas como o stackoverflow ou fóruns.

Isso tem seu lado positivo já que procurar essas ferramentas e tentar buscar um certo nível de autonomia são indicadores de amadurecimento. Contudo, essas tarefas iniciais caso não possam ser acompanhadas com pair programming devem ser atribuídas de forma mais criteriosa.

Caso não seja possível dar uma tarefa fácil por falta delas no backlog, ou ainda exista o interesse proposital de atribuir uma tarefa um pouco mais difícil para de forma saudável desafiar o novo integrante, deixe isso bem claro de forma transparente. Muitas vezes essa pequena informação pode aliviar sentimentos que podem surgir na cabeça do novo desenvolvedor em que ele acha que está performando mal ou tendo dificuldades demais, o que desmotivam e tornam a curva de aprendizado menos efetiva.

Ou como Katherine Wu disse no excelente post how to be a better junior developer (infelizmente apenas em inglês, trecho traduzido livremente):

".. se como mentor você quer intencionalmente deixar um desenvolvedor junior sofrer um pouquinho para aprender alguma coisa, deixe-o saber que você está fazendo isso. Dessa forma elimina-se sentimentos como o da síndrome do impostor, no qual a pessoa perde sua auto-confiança porque acredita erroneamente que a tarefa deveria ser mais fácil mesmo que de fato seja difícil.  Eu mesma fiz esse erro muitas vezes. É preciso ter cuidado quando atribuímos desafios para pessoas e deixá-las saber o quão difícil é esperado que um problema seja."