A Humildade Na Arrogância Do Conhecimento - Parte II

Tenho cerca de três momentos marcantes na minha carreira que me mostraram o quanto foi bom para mim ter a abertura de me colocar numa posição em que ou observei, ou pedi ajuda, despindo-me do meu conhecimento.

Primeiro

O meu primeiro projeto profissional foi uma introdução bastante boa de trabalhar com tecnologias que desconhecia (VB6 e VB.NET), tarefas que não sabia se conseguia executar, e também um ambiente de trabalho de outsourcing já que estava no cliente.

Eu era péssimo em SQL, e como rebento que era a minha principal tarefa passava por fazer cálculos complexos recursivos. Já pouco me lembro do contexto, mas tinha a ver com orçamentação num pacote de seguros. Creio que gastei no total umas 2 semanas no “algoritmo” e não foi sozinho.

Durante os primeiros dias tentei ir programando, e à medida que me ia encalhando desenhava numa folha de papel o meu raciocínio todo de novo e tentava perceber onde é que poderia estar a falhar. Ia no comboio para casa só a pensar naquilo porque sabia que era a grande feature do meu projeto.

Entretanto conheci um developer do cliente que era a pessoa mais bruta que alguma vez conheci em SQL e após vários dias de tentativas fui falando com ele para lhe explicar o que queria fazer e pedi primeiro para ele me explicar o seu raciocínio sem programar nada, e creio que foi aí que compreendi um pouco melhor a recursividade que precisava.

Não me recordo quantos dias foram, mas fui tentando evoluir com o que ele me ia ensinando, e um certo dia ele viu que eu talvez ainda estivesse longe da solução e veio para o meu computador ajudar-me a fazer grande parte da feature, e o mais ridículo é que fez em cerca de 10 minutos mais do que eu fiz em dias.

A sua solução era no entanto demasiado complexa para mim, então isso causava um problema que era a manutenção, ou seja, não só tinha de acabar o algoritmo, como tinha de resolver bugs futuros, e não compreendendo a 100% o código XPTO que ele escreveu, precisei de estudar bloco de código a bloco de código a sua solução para mais tarde chegar à minha.

Sendo sincero não sei o quão bem sucedido fui. Sei que a primeira vez que disse “já está” o meu team leader testou uma vez e aquilo rebentou. Típico Picoito. Nunca testava bem as coisas, fazia uma vez, tava a funcionar, fazia mais uns casos super simples, e pronto siga para a frente.

Isso foi das coisas mais difíceis de superar, porque demorou imenso tempo a entender que não existem apenas caminhos felizes, mas também caminhos muitos infelizes, porque como todos sabemos o end-user é um macaco que tecla com uma mão cerrada e coça os tomates com a outra enquanto nos chama de anormais porque a sua password não funciona. Lembro-me que uns meses mais tarde falei com o meu team leader novamente e ele riu-se quando falou de mim, mas aparentemente tavam-se só a meter comigo. Pelo menos é o que eu digo a mim mesmo para não chorar na banheira enquanto oiço Celine Dion e me pergunto porque é que estou nesta área.

Portanto o que aprendi com esse developer, o Miguel, é que mesmo que sejamos muito bons, a nossa solução por vezes é muito complexa, porque não é por nós percebermos a nossa solução que ela é uma boa solução. Se fosse ele a fazer a manutenção daquele código seria óptimo, o código era extremamente elegante, com muito menos linhas de código do que o meu, mas o meu nível de SQL não me permitia entender.

Também percebi que é muito positivo tentar entrar na cabeça de alguém com muita experiência, daí que a minha primeira abordagem é sempre “não me digas a solução, apenas explica-me como chegar até lá” porque mais tarde aquele código poderá ser nosso novamente, e se não o entendermos mais tempo perdido, e francamente menos conhecimento adquirido.

Segundo

Na minha segunda empresa encontrei vários casos de trabalhadores muito aplicados, mas em destaque é um developer que apareceu lá como outsourcing chamado Alexandre. Ele era relativamente novo, creio que tinha mais ou menos os mesmos anos de experiência do que eu, mas era um tanto mais apaixonado e ousado.

Naquela empresa lembro-me perfeitamente de haver uma framework de JavaScript e C# criada por um dos chefes para ajudar a criar já uma estrutura para o tipo de projetos que fazíamos lá que envolviam imensos formulários. Nem eu conhecia bem a framework pois trabalhava pouco com ela, e o Alexandre tão pouco pois tinha acabado de entrar na empresa.

Foi-lhe atribuída uma tarefa qualquer relacionada com essa framework ao qual ele disse, com toda a confiança do mundo, que se ele quisesse aquilo feito demoraria pelo menos 1 mês pois teria que estudar bem a framework. Ao ouvir a conversa achei muito tempo, mas fiquei surpreendido quando o criador da framework lhe deu razão. Foi uma das muitas provas que presenciei de alguém que tinha completa confiança naquilo que dizia e fazia.

A sua vontade de aprender mais também surpreendia imenso pois era com ele que costumava falar mais sobre código e ele tinha entusiasmo por ensinar. Normalmente ele explorava imenso novas tecnologias ou metodologias, o que também era ao mesmo tempo prejudicial pois houve algumas vezes que ficou encalhado por querer fazer tudo demasiado bem. Isso também me ajudou a reforçar a ideia que sempre tive do meu próprio trabalho, no qual consoante o tempo escolho fazer ou bem ou menos bem, sendo que mesmo o bem é relativo pois o que fazemos bem hoje amanhã está mal feito.

Estar lado-a-lado a aprender, ou a ver a sua postura perante os chefes e perante o seu trabalho, fez-me perceber que a confiança que depositamos em nós mesmos permite-nos ter uma abordagem muito mais assertiva do nosso trabalho, e permite-nos também tomar decisões mais conscientes, e poder, acima de tudo, defender-las, pois à medida que vamos ganhando mais responsabilidade vamos lentamente sendo colocados em situações onde teremos que ser nós a tomar decisões importantes, e se não tivermos confiança em nós mesmos, no nosso trabalho, e não soubermos manter um punho firme, facilmente seremos derrubados principalmente por nós mesmos, pelas nossas dúvidas, pelos nossos momentos de fraquezas, e poderemos pôr em causa o nosso trabalho, mostrando que não estamos apto para aquele tipo de posição.

Terceiro

Sempre quis ser um Team Leader. Não era uma ambição por quem tem sede de poder, porque aí seria apenas o desejo de ser actor porno e no final do dia ter de recorrer a viagra para manter a bandeira hasteada durante a guerra inteira.

Na universidade sempre tomei a posição de defender os meus projectos, por mais que os professores pudessem levar a mal e prejudicar-me por isso, e sempre fui uma pessoa bastante disponível, tanto que muita vez quando estava na Mediateca do IPS a fazer os projectos normalmente pediam-me ajuda, e eu sentia um orgulho imenso em mim mesmo por isso, e ainda mais quando conseguia efectivamente ensinar e explicar as coisas de forma a que entendessem e não simplesmente tivessem a solução, mas uma das minhas formas de fazer isso era precisamente não dar a solução, e normalmente quem me pedia só recebia ajuda uma vez porque notava que se estavam a lixar para a parte da aprendizagem.

A minha maior surpresa foi quando na cadeira de Engenharia de Software o grupo com quem trabalhei me nomeou para Project Manager, e diga-se de passagem que o meu grupo era constituído por excelentes alunos.

Na altura senti orgulho, tentei organizar as coisas o máximo possível, mas fazendo a retrospectiva vejo que na altura sempre fui melhor programador do que era gestor, tanto que literalmente no último dia tive um almoço importante familiar, ao qual me tentei esquivar, e tive de pedir ao meu melhor amigo, que estava no grupo, para tomar as rédeas e organizar a documentação. Falha minha, pois a documentação estava mesmo feita em cima do joelho, houve alguma documentação que estava básica demais, tudo fruto da minha falta de gestão, mas no entanto o projecto em si estava muito bom.

Esse desejo de ser Team Leader continuou durante a minha carreira, aos poucos fui tendo uma pequena prova do que significava ser um, mas nunca fui verdadeiramente à séria pois as estruturas onde o consegui ser não tinham lugar para um, então era sempre algo temporário. Nessas poucas vezes sempre tive bom feedback de estar disponível para ajudar, ter bastante mais atenção com prazos, mas acima de tudo de poder servir o máximo que pudesse de escudo para a equipa, porque nesta área quanto mais baixo na pirâmide estamos menos sofremos com as porcarias que vêm de cima, e que são em torno os nossos superiores que têm (ou deveriam) de as filtrar.

Alguma vez se perguntaram “porque é que tenho de fazer as coisas para ontem?”. Um dia que estejam na posição em que tenham de passar essa mensagem a alguém vão perceber que provavelmente tiveram uma discussão desagradável com alguém que vos fez esse pedido… E se forem bons chefes vão tentar não fazer esse pedido, ou negociar de algum modo, ou no pior caso possível o pedido será feito, mas haverão de arranjar maneira de recompensar a devido tempo quem esteve lá pelo amor à camisola.

Durante esse meu pequeno tempo, tentei ensinar ao máximo, e curiosamente tentei mais ensinar na forma como abordar o trabalho do que propriamente como o fazer. O que vi em demasia foram pessoas que não sabiam distinguir entre o que é passar demasiado tempo a ver uma tarefa sozinhos, e quem achava que olhar durante cinco minutos para algo era o tempo suficiente para ir pedir ajuda.

Não só isso mas a mentalidade da nossa área, em que muita gente pensa que o trabalho acaba efectivamente no local de trabalho, e isso revela muita falta de tacto com uma área onde miúdos que saem da universidade têm muita mais vontade de aprender do que nós e que facilmente nos conseguem ultrapassar tecnicamente, e o pior no meio disso são os que são arrogantes o suficiente por acharem que só porque são “melhores” tecnicamente e conseguem pegar no martelo do Thor, não fazem ideia do que significa estruturar uma aplicação correctamente, ou o que significa sequer manutenção de projecto, entre muitas outras coisas…

Portanto o terceiro exemplo, na minha carreira, sou eu. Temos de nos saber valorizar pelas pequenas vitórias que vamos conseguindo alcançar ao longo do tempo. Umas vezes somos aprendizes, noutras somos mestres. Tanto deveremos ser humildes quando aprendemos, como deveremos ser confiantes quando ensinamos.

É importante que não deixemos que seja alguém mais jovem e inexperiente a ensinar-nos algo, ou que sejamos nós, nessa posição mais jovial, a ensinar alguém com mais experiência, pois somos seres humanos, as nossas experiências, perspectivas e vivências são diferentes, e cada pessoa olha para a paisagem da vida de uma forma única e peculiar, daí que deveremos ter humildade mesmo quando achamos que sabemos muito, pois mesmo na arrogância do conhecimento ninguém sabe tudo, todos temos conhecimento para partilhar, e todos temos conhecimento para receber, e nunca é demais ouvirmos as histórias dos outros, e contarmos as nossas, porque dessa partilha poderemos pavimentar o caminho para a nossa próxima conquista, ou ajudar outrém nessa mesma jornada.