Month: dezembro 2015

Como ensinar?

Uma das coisas que mais aprendi ao longo dos anos foi como ensinar. O legal disso é que ensinar me levou a aprender, o que é um círculo virtuoso que eu quero manter pelos próximos 50 anos ou mais. Nesse humilde post vou contar como foi a minha história com aprendizagem, como comecei a ensinar e finalmente hoje treino todo o tipo de pessoas, CEOs de grandes organizações até universitários ávidos por conhecimento que os diferencie no mercado.

Sou filho de uma professora e isso foi muito impactante para essa carreira. Minha mãe, como criou a mim (e a meu irmão) sozinha fez o melhor que pode dentro dos seus recursos para nos prover uma ótima educação. Desde de muito jovem eu via como um educador fazia a diferença na vida das pessoas. Ela foi por alguns anos professora na zona rural da cidade, quando ia todas as manhãs pegar um ônibus que a levava para a fazenda, passava o dia em uma turma multiseriada (acho que era de 1º à 4º anos) e no fim do dia regressava para casa. Aquelas pessoas sentiram na educadora alguém que se importava, que lhes oferecia bem mais do que conteúdo mas valores que pautaram suas vidas. Quem não ia querer ser essa pessoa.

Eu mesmo comecei a ensinar já na infância. Na escola, o nerd/gordo/zarolho/filho da professora não tinha como ser mais zuado. Não tendo mais o que fazer na escola, com pouca interação social, me restava então me dedicar às aulas e isso eu fazia. Acompanhava as aulas e como não me distraia aprendi sempre com relativa facilidade os conteúdos. Obviamente os caras mais sociais da sala, como estavam ocupados em ser populares não tinham o mesmo desempenho. Aí que eu me tornei “popular“. As pessoas com dificuldade me buscavam querendo aprender sobre os conteúdos. Isso se dava por algumas razões. A primeira e mais óbvia: eu sabia e eles não. Simplesmente eu tinha um conhecimento que mesmo com a mesma oportunidade de aprendizado foi melhor aproveitada por mim. A segunda razão, um pouco mais sutil é: eu sabia falar a língua deles. Era mais simples perguntar ao colega de mesma idade do que para outra pessoa com 20, 30 ou 40 anos a mais que você. Fora a intimidação que a figura do professor passava, que gerava um certo temor em perguntar e ser repreendido. Outra vantagem em aprender comigo e não com o professor eram as metáforas. Eu conseguia fazer paralelos, explicar usando outros exemplos, trazer aquilo para uma realidade mais simplificada do que o conteúdo formal da sala de aula.

Em um determinado ano o diretor da escola resolveu trazer um curso de informática para a cidade, algo inovador em 1989. A minha mãe, como trabalhava na escola sugeriu colocar o filho para ajudar na parte burocrática do curso em troca de um desconto nas mensalidades. E assim eu ajudava com as matrículas, com o recebimento das mensalidades, organizava a sala entre as turmas, essas coisas que uma criança pode fazer. E assim eu consegui fazer meu primeiro curso de informática. No ano seguinte o curso se renovou e então eu pude continuar trabalhando, mas agora com uma pequena renda. Foi então que aconteceu de um professor faltar um dia. E faltou outro. E mais outro. E então eu comecei a buscar novos professores de informática sem muito sucesso, afinal, era o início dos anos 90 e informática não era tão trivial como é nos dias de hoje. Consegui alguns, mas poucos se mantinham no curso. Foi então que me vi obrigado a tomar uma decisão. Levantar a bandeira branca e dizer ao diretor que não tínhamos como continuar ou ousar dar uma aula seguindo o conteúdo que eu já conhecia, mesmo que obviamente sem a profundidade de um professor. Acabei optando pela segunda. Saí petrificado da primeira aula, nervoso como um adolescente no seu primeiro beijo (sim, sou velho o suficiente para crer que isso deva acontecer na adolescência, mas enfim…) mas consegui. E a medida que os dias iam passando e os dias se tornando meses, os meses se tornaram anos e aquilo realmente ficou fácil para mim. Estudei programação nessa época, com uma apostila que um colega de classe tinha me presenteado por te-lo ajudado a concluir um software. Era em Clipper. Bons tempos. Estudei o suficiente para então começar a desenvolver meus próprios softwares e então poder ensinar a programar.

Nesse momento eu tinha entendido uma coisa interessante. Se você sabe fazer de fato, sabe o que você está ensinando na prática, o ensino se torna leve. Você não está mais ensinando um conteúdo formal vindo de um livro ou treinamento. Nada contra conteúdos formais, nem tudo dá para praticar. Mas ter vivência naquilo que se ensina te dá bagagem, exemplos, te permite ter alternativas para aquelas perguntas mais inesperadas. E assim, ensinando um curso após o outro, uma aula após a outra, eu pude ir entendendo os pequenos meandros dessa arte.

Quando eu finalmente concluí um curso universitário (iniciei 4, papo para outra conversa) eu pude perceber o valor daquele modelo de formação. Não pelo conteúdo, já me considerava um programador experiente naqueles dias (pra minha sorte o mercado também) mas pelo ambiente. É um local de estudo, um ambiente focado em aprendizagem, com pessoas que também exercem funções no mercado durante o dia, que buscam se atualizar, criando atalhos para um conhecimento que existe, está ali solto no ar, mas que eles já fizeram a coleta, processaram e te entregaram prontinho. Veja, não estou elogiando o modelo de ensino que muitos criticam por aí. É só a impressão que deixou em mim. Fiz amigos para a vida toda por lá e sempre fui humilde e respeitoso com meus professores, mesmo os mais jovens que eu. Eles deram inputs interessantes para a minha melhoria como profissional.

Após a universidade eu voltei dar treinamentos, agora ensinando como as pessoas poderiam melhorar o seu jeito de trabalhar utilizando as tais práticas ágeis que tanto falo aqui no blog. Via os discursos inflamados e cheios de paixão desses caras e os diferentes tipos de treinamentos. Alguns eram mais formais, com projeção, flip-charts e apostilas. Outros eram mais dinâmicos, com práticas, papéis coloridos, bolinhas e dinâmicas que movimentavam, divertiam, mas ainda assim ensinavam. Nesse momento eu entendi que ensino não é sobre transmissão de conteúdo, mas sim sobre levar o educando a entender um conceito. Isso significa que eu posso até te contar sobre algo, você pode entender a minha mensagem e isso seria muito bom. Agora se eu te fizer sentir, provocar a surpresa, a sensação, o sentimento que te conecte ao conteúdo o resultado é muitas vezes mais efetivo. É como se o aprendizado formal se formasse no cortex e o informal se desse no límbico.

Já havia lido sobre Teaching from the back of the room e achava suas ideias interessantíssimas para ligar aluno e conteúdo ensinado. Usei muitas delas em meus treinamentos, mas sentia que poderia fazer melhor, dar um certo polimento naquilo. Seguindo nessa linha, nesse último ano tive a grata oportunidade de me juntar com outras pessoas que assim como tinham entendido que aprender tem que ser algo que venha de dentro dos educandos e fui apresentado ao conceito de Learning 3.0. Nessa maneira de entender o aprendizado, o treinador é um mero maestro, orquestrando seus alunos na construção do conhecimento. A ideia é que, usando técnicas de aprendizagem emergente, os alunos construam um conteúdo próprio, em conjunto, que provavelmente será muito mais retido do que num modelo tradicional de estuda-decora-prova.

Hoje eu sinceramente não sei como definiria meus próprios treinamentos. Uso projeção (sem vergonha alguma de dizer isso) porém poderia talvez dar um treinamento sem ela. Uso flipcharts porque os treinandos gostam de ver que você pode construir seu próprio material sem depender de recursos como o PPT. Dá a elas a sensação de que existe um domínio forte do que está sendo apresentado. Uso o máximo de dinâmicas que posso para esclarecer o conteúdo e levar os treinandos a sentir mais do que saber. Enfim, talvez não é um estilo que se encaixe em uma descrição, mas é o meu estilo. O que sei é que os feedbacks têm sido positivos, melhorando a cada classe e cada dia que ensino aprendo um pouco mais sobre essa arte.

Portanto como se ensina algum conteúdo? Não ensine. Promova o sentir, fomente a interação e permita que eles construam o conhecimento sob sua regência. Bom aprendizado/ensino e até a próxima.

Agilidade na Praça

Curte agilidade, métodos ágeis e outras boas práticas de programação? Cara, a gente precisa conversar! Durante a semana a vida de todo mundo é bem corrida, com muito trabalho, estudo e outras coisas que complicam a gente parar e refletir um pouco sobre como melhorar, trocar experiências e descobrir novas maneiras de trabalhar.

Eis o meu plano. Ao invés de tentar montar um grande evento, com palestrantes, inscrições e tudo o mais, vamos só marcar de tomar uma cerveja na praça, com um flipchart do lado pra ajudar e bater um papo sobre agilidade? Cada encontro a gente pega um tema diferente e vai debatendo. Cada semana um pode conduzir a conversa e quem sabe a gente pode ir variando as praças. A ideia é que seja um encontro leve, simples, sem frescura, onde possamos trocar ideias e crescer pessoal e profissionalmente!

Para iniciar, essa semana vamos começar com uma conversa aparentemente leve: o manifesto ágil!
Venha, vai ter cerveja 🙂

Extreme Pair Programming

É importante destacar, antes de mais nada, que programação em pares é uma das responsabilidades sua como desenvolvedor em XP. Não cabe ao seu chefe, à sua organização muito menos ao seu cliente interferir nessa sua decisão de qual dessas práticas no centro do diagrama você vai utilizar ou não. Então da próxima vez que alguém disser: “eu não faço programação em par porque meu chefe não deixa” mostre esse desenho abaixo e peça para ele repensar o assunto.

xp practices

Eu sempre começo meus textos com definições. Elas ajudam a entender melhor do que estamos falando e quando eu for contar os meus causos a coisa fica um pouco mais clara. Já que é assim, precisamos entender dois conceitos importantes antes de continuar. O de par e o de programação. Para começar, o par é um conjunto com dois elementos de mesma natureza, mesma espécie. Duas criaturas semelhantes juntas então formam um par. Já programação é o ato de elaborar um programa de computador. Assim, criamos código para solucionar os problemas do mundo. De maneira mais bonita é mais ou menos isso o que fazemos. Bom, então estamos falando de duas criaturas da mesma espécie trabalhando na mesma solução de um problema, no caso através de um código de computador.

Uma das maneiras que mais vejo o pessoal usando para explicar é a metáfora do piloto e navegador. O piloto, responsável pelo controle da aeronave, deve ficar atento aos controles, como dirigir para que tudo flua bem. Já o navegador é o responsável pela rota, verifica o caminho, observa aqueles controles que estão fora do campo de visão do piloto e ajuda na difícil tarefa de levar a aeronave em segurança. Na nossa prática é muito semelhante. A diferença fica que fazemos alternancias entre os papéis de tempos em tempos. Ora você é o piloto, ora você é o navegador. Usualmente o que tenho visto são duplas fazerem isso em ciclos de 15 minutos para a troca, mas não há um consenso sobre o assunto então combine entre vocês qual o tempo que lhes é mais confortável.

A prática em si é essa, alternancia de controles entre piloto e navegador, enquanto navega o desenvolvedor tem um foco um pouco mais amplo ao mesmo tempo que o piloto está focado na escrita da sua ideia de melhoria no código. Existem alguns mitos sobre programação em pares. Vamos falar de alguns.

  • Improdutivo: se medido num curto espaço de tempo, a impressão que se tem é que realmente programar em par é improdutivo e portanto mais caro para a empresa. Afinal você coloca dois “recursos” para resolver uma única tarefa, portanto estaríamos custando o dobro nesse cenário. Essa é uma visão de curto prazo e já está mais do que provado que a longo prazo esse custo se paga, com a redução da quantidade de bugs e elevada manutenabilidade do software. O código tende a ficar mais limpo e compreensível, entre outras vantagens que falarei mais a seguir.
  • Invasão de privacidade: certamente que sim. Você divide parte do seu tempo com outro desenvolvedor num espaço físico mais restrito (o espaço de uma mesa). Assim, aquela notificação que chegou para você no cantinho da tela inevitavelmente vai ser percebida pelo colega. Aquele assunto pessoal que você tinha para resolver pelo celular também agora já tem um expectador extra. Parte da sua vida será sim compartilhada.
  • Cansativo: muito! Trabalhar focado em par gera um cansaço acima da média. É recomendável o uso de outras técnicas auxiliares como pomodoro para garantir que não se exagere quando estiver trabalhando demais.
  • Sagrado: de maneira alguma! Se em algum momento você julgar que a tarefa é demasiadamente simples para colocar desenvolvedores nela então não faça programação pareada. Somente tenha cuidado para agora não usar isso como desculpa para não experimentar essa técnica.

As principais vantagens dessa técnica são:

  • Aprendizado: as duplas tendem a colaborar em experimentar novas técnicas e novas maneiras de escrever soluções para os problemas do dia à dia.
  • Motivação Mútua: pode parecer piegas, mas quando o problema que se está tentando resolver for complicado demais, você tem um amigo ao seu lado com o mesmo objetivo que você lhe motivando a seguir em frente.
  • Padronização: o código após a adoção da programação pareada migra de ter a “cara” de determinado programador para ter a “cara” da equipe. É difícil identificar qual o indivíduo dentro da equipe escreveu aquela funcionalidade, o diminui os dedos apontados em caso de falha e distribui o mérito em caso de sucesso. Fortalece o espírito de identidade do time.
  • Redução de Bugs: você tem dois cérebros, duas máquinas pensantes, duas threads abertas para resolver um problema. Enquanto um está focado no micro escopo, olhando aquela função ou aquela parte dela o outro tem uma visão mais macro, pensando nos impactos e se o restante do código fica bem com aquela alteração. Suas chances de criar algo que venha a dar defeito diminuem drasticamente dessa maneira.
  • Proximidade: sim, saímos do nosso mundinho fechado e começamos a conversar uns com os outros e em alguns casos até de coisas não relacionadas à software. Descobrimos novas afinidades, marcamos mais churrascos e confraternizações simplesmente porque começamos a ver mais fortemente mais interseções do que divergências.
  • Comunicação: aprendemos a nos comunicar, temos de expressar nossas ideias ao par antes de implementar para validar se existe alguma brecha de problema nela.
  • Foco: as distrações são bem menos percebidas quando você não está sozinho. Aquela notificação você deixa para ler depois, aquela mensagem do whatsapp que chegou provavelmente pode esperar até a próxima pausa. É mágico perceber que até mesmo o ambiente de trabalho respeita o par, pois sabe que ele está focado resolvendo um problema e interfere menos no seu trabalho.
  • Disseminação do conhecimento: deixei esse para o final pois é, na minha opinião, a mais importante das vantagens. Você reduz drásticamente o tempo de treinamento, pois agora você tem o suporte de alguém muitas vezes mais experiente para realizar a tarefa. Não existe mais o dono de uma parte do código, no mínimo existe uma dupla que é dona. Assim, se você rodar (trocar os pares) de tempos em tempos (algo como quinzenal) é visivelmente a maneira mais interessante de fazer o conhecimento circular dentro da sua equipe e quem sabe até da sua organização.

Com todas essas vantagens, fica difícil se posicionar contra uma prática tão difundida e tão bem defendida na comunidade. Se você ainda não tentou, experimente hoje mesmo e veja o seu código melhorar além é claro, de você crescer muito como profissional.

O problema não é da arquitetura

Estive recentemente palestrando na XP Conf BR, iniciativa muito legal dos meus amigos gaúchos para falar um pouco sobre “agilidade de raiz”. Essa agilidade de quem realmente faz o código, de quem escreve código e quer fazer bem feito. Falamos muito sobre as práticas da programação extrema e algumas outras coisas correlatas. É legal que, de uns tempos para cá, eu ando muito reflexivo e questionando quase tudo e todos. Talvez seja só um mal (ou bem) da idade mas o fato é que toda situação que me deparo tem me puxado um pensamento e esses eu tenho compartilhado por aqui. Foi muito bom rever meus amigos falando de Pair Programming, de Histórias de Usuário, de metáforas, entre outros assuntos legais. Assuntos teóricos, outros com casos reais de implantação, enfim, tudo ótimo. Mas a reflexão que isso me puxou é a seguinte: o problema realmente está na arquitetura?

Eu por vezes me vi tentado a pensar que sim, que como desenvolvedor eu via meus pares criando códigos de maneira quase irresponsável. Sim, irresponsável, afinal, a responsabilidade pelo código que escreviam era do gestor, do dono da empresa, ou ainda da criatura maligna do cliente que realmente não sabe o que quer, ou ainda não sabe pedir direito. Quando a gente vai num evento como esse, cheio de desenvolvedores, ávidos por escrever código de qualidade eu me questiono aonde estamos errando pois a realidade é bem distante da utopia que falamos nas palestras.

Nas palestras a gente fala de como deveria ser. De como nos fariam felizes que nossos ambientes de desenvolvimento fossem. De como seria legal que os valores ágeis, aqueles do manifesto, fossem seguidos como um código de conduta. É assim que baseio a minha vida e me parece plausível fazê-lo quando estou trabalhando. Pensar em pessoas e interações, software que funciona, colaboração com cliente e adaptação serem mais importantes que processos, documentos, contratos e planos parece fazer bastante lógica na cabeça de todo mundo que eu converso. Mas aonde estamos errando? Por que temos tanta dificuldade de convencer gestores sobre isso? Uma ideia que vem martelando na minha cabeça há tempos é que nós não entendemos o manifesto. Não entendemos a profundidade da mudança de pensamento exigida para fazer aquilo ali ser real. Vejo usualmente os desenvolvedores traduzindo “indivíduos” como “minha equipe”. É fácil se esquecer que em todos os níveis da nossa organização existem indivíduos, pessoas, seres humanos, de nossa espécie, e que esses são afetados se fizermos um trabalho mal feito.

De novo, não acho que o problema seja de arquitetura, tenho plena fé que meus amigos desenvolvedores são extremamente hábeis técnicamente para resolver os problemas que surgem e se não forem são capazes de evoluir a ponto de superar os obstáculos. Eventos como o XP Conf me mostram isso. O problema é que nós não nos importamos com as pessoas. Nem mesmo aquelas dentro da nossa organização, quem dirá aqueles que vão usar o nosso código para solucionar problemas em suas vidas.