Umas coisas que aprendi no trabalho

Estou há um pouco mais de um ano e meio trabalhando (estagiando) no mesmo local e além do conhecimento técnico, aprendi muitas coisas importantes que eu gostaria de compartilhar. Muitas delas não se aplicam apenas ao ambiente de trabalho, mas acho que pra qualquer atividade que envolva esforço mental, individual ou coletivo essas coisas são úteis. Lá vai:

Conheça seus limites

Quando você não souber o que está fazendo, não faça. Principalmente se isso envolve sérios riscos, como por exemplo mexer em ambientes de produção ativos. Pare, analise a situação, planeje e pergunte. Pergunte pra alguém mais experiente se o modo que você planejou fazer aquilo é razoável. Peça dicas sobre como realizar os passos, sugestões no planejamento, que cueca usar, whatever. Se puder fazê-lo supervisionado, nem pense duas vezes, faça.

A primeira vez que eu fui mexer em um ambiente de produção, foi justamente para configurá-lo e o expor ao mundo. Se eu fizesse alguma besteira, nenhum sistema iria cair, nem o mundo iria acabar, mas os primeiros momentos não foram bons.

A tarefa era relativamente simples, mas a ideia de que aquilo iria pro cliente e que se falhasse a responsabilidade era minha me deixou estressado. Fiquei umas duas ou três horas fazendo as tarefas iniciais. Um probleminha ali outro aqui, nada demais, porém eu já sentia um pouco de torcicolo e sentia umas dores no ombro. Parei.

O prazo não era longo, nem curto. Eu podia parar por ali pra continuar no dia seguinte. Foi a melhor coisa que eu fiz. Tomei uma coca e fui pra casa ouvindo música. Tive tempo de, no caminho, perceber que meu nervosismo era bobo. Eu sabia o que fazer e como fazer. Era a primeira vez que eu fazia aquilo. Foi um choque inicial, mas quem liga? Se alguém me incumbiu com aquela tarefa, era por que confiava em mim e em minhas habilidades para fazer aquele trabalho importante.

Na manhã seguinte, como esta era minha única tarefa, nem fui pro local de trabalho. Loguei via ssh nas máquinas e terminei relativamente rápido a tarefa.

Cansaço mental

Tem horas que simplesmente não dá pra continuar. Seja estudando ou trabalhando, quando você enfrenta um problema daqueles cabeludos, que envolve toda a filosofia da ferramenta que você usa ou que simplesmente requerem muita queimação de neurônios, você começa a ficar viciado em algumas tentativas de solução. Pelo menos eu fico. Tento uma, outra. Volto pra uma, tento a outra novamente e este processo cansa. Cansa muito.

Já houveram vezes em que eu me sentia cansado como se tivesse feito alguma atividade física pesada, apesar de ter ficado o dia inteiro na frente do computador e assistindo aula. O cansaço mental é muito pior, pois não causa aquela sensação boa que a prática de um esporte trás. Ao invés disso, deixa angústia, baixa a auto-estima e me deixa triste.

O que fazer então, quando você está há três horas encarando aquela stacktrace supimpa e suas idéias acabaram? É hora de dar uma descarga em todo o lixo que está na cabeça. Eu leio feeds de humor, vou tomar um café, comer alguma coisa… Chamo o pessoal pra ir junto e bater um papo. Esqueça aquele problema. Fale do que você fez no fim de semana passado, daquele jogo novo que saiu, etc.

Sabe aquele insights que o House tem quando está infernizando a Cuddy e resolvem o caso num piscar de olhos? Isso realmente acontece às vezes. E quando acontece, não há sensação melhor de realização. Veja bem: não disse que isso vai resolver seu problema, mas esfriar a cabeça é o primeiro passo para resolvê-lo, com certeza. Quando o negócio está feio mesmo, eu apelo pra uma noite de sono. Faz milagres. Essa é mais infalível do que a “descarga mental”. Já cansei de ir pra casa estressado com algum problema, dormir, sentar no dia seguinte e pimba! Achei a solução! De primeira mesmo e sem usar game shark !

Nada é simples

Essa aqui é decorrente da lei de Murphy. Seu chefe pede pra você mudar o nome de uma variável. Simples, não? NÃO! Vai dar merda, capitão. Nem que seja um bug no seu ambiente de desenvolvimento, mas algum galho vai dar. É incrível como no ramo da computação sempre existe uma mágica pra atrapalhar. Principalmente com hardware. Montar algum pc sempre dá uma titica. Encaixou mal a memória, sujou uns conectores, cabos soltos…

Programando não é diferente: já cansei de ter que aturar tpm do Eclipse pra resolver alguma coisa simples.

Se algum superior lhe pedir pra implementar ou fazer alguma manutenção simples, esteja preparado. Nunca fale “isso é facil, faço em 5 minutos!”, “isso é só mudar duas linhas naquele xml…” a não ser que seja acompanhado de “…se não der nenhum galho”, ou “se não quebrar alguma coisa…”.

Ambiente descontraído

Não há nada melhor que trabalhar com os amigos. Fazer aquela piada sobre a dondoca horrorosa que alguém pegou no fim de semana, zoar o notebook lerdo do amigo do lado, registrar no quadro uma frase comprometedora que escapou… Enfim, rir e fazer alguém rir integra as pessoas e torna o ambiente mais agradável.

intantsfun.es aberto na aba ao lado é sempre uma promessa de boas risadas .

Trabalhar em par

Onde eu trabalho usamos eXtreme Programming. Um dos valores do XP é a programação em par. Por experiência própria, eu digo que não existe modo mais produtivo de programar. A quantidade de erros bobos diminui absurdamente e a troca de experiências é fantástica. Não existe modo melhor de aprender e ensinar a programar como programando em par.

Acompanhar Listas de desenvolvimento/usuários/commits

Eu tinha muito medo de olhar o código de ferramentas que eu uso. Medo bobo, de achar que não estou num nível bom para entender como os frameworks funcionam. Foi a coisa mais ingênua da minha vida. Certo dia, eu estava com dificuldades na integração do Seam com o Drools 5 e queria saber a quantas andava a integração no desenvolvimento. Assinei a lista de desenvolvimento do Seam e perguntei se havia algum pra integração ficar pronta, dando alguns exemplos de funcionalidades que me seriam úteis. Calhou de que algumas funcionalidades que eu falei nem terem sido pensadas por eles e as idéias acabaram sendo adotadas, dizendo que as implementariam.

Assinei então a lista de commits do Seam, pra acompanhar o desenvolvimento das features que sugeri. E comecei a ler os códigos que recebia por email dos commits e pra minha surpresa, eram claros como água de nascente. Comecei a ter mais “coragem” pra olhar os códigos e acabei tendo um aprendizado enorme sobre a ferramenta através do seu código.

Acho esse medo até natural para alguém que começou a programar agora, mas quanto mais cedo esse medo for superado, melhor será para seu aprendizado.

Listas de desenvolvimento/usuários também são uma ótima maneira de se informar sobre bugs, features novas e mudanças quaisquer no projeto que você participa/usa.

É isso. Existem outros tópicos, certamente, mas estes ficam pra um próximo post .