10 Lições Aprendidas

Trabalho com Linux e sofware livre de maneira profissional desde 1998. Mas nunca havia trabalhado de maneira tão direta e intensa como trabalhei no Tapioca nestes últimos dois anos.

Nesse tempo, recuperei minha fé no código aberto, que devo admitir, ficou um tanto abalada devido à certas experiências ruins (ou talvez pela minha falta de experiência). Tudo bem, quem trabalha com isso diariamente deve saber do que estou falando. Mas o importante é que de um jeito ou de outro, trabalhar em um projeto de software livre te ensina muitas coisas. Há muitas lições a aprender, e eu vou falar sobre algumas que aprendi nos ultimos anos.

1. Ame o seu projeto: É mais fácil quando a idéia foi sua e você começou a coisa toda. Mas as vezes você é simplesmente designado para trabalhar nele. Não importa. A única maneira de produzir algo com qualidade é abraçar a causa. Acredite no que está fazendo, codifique, revise o código feito, teste e refaça o que achar ruim. Pense no que pode ser melhorado. Procure features novas, organize o código, organize o projeto. É como estar à bordo de um veleiro. O trabalho nunca acaba, há sempre algo que deve ser feito ou observado, caso contrário perde-se o rumo.

2. Aprenda com ele: Na minha opinião, a oportunidade de aprender algo novo é a melhor parte do trabalho.

3. Estabeleça metas: "Quem não sabe o que procura, não vê o que encontra". Procure definir bem o que seu programa vai fazer. Feche o escopo, defina as funcionalidades prioritárias e estabeleça prazos para terminá-las. Aprenda a priorizar. Deixe estas metas claras para todos os desenvolvedores e usuários, em algum lugar que todos possam ver. Muitos projetos simplesmente não dão certo porque querem abraçar o mundo. Veja o Emacs, por exemplo. :)

4. Integre: De nada adianta todo o esforço se o que você fez não pode ser instalado em lugar algum. Uma interface gráfica que não segue as "UI guidelines" do Gnome ou do Kde, uma biblioteca compartilhada que sobrescreve uma previamente instalada por outro pacote, um framework distribuído que derruba o D-Bus, e por aí vai. Tenha em mente que você deve preservar a harmonia do sistema, e tentar ao máximo usar os recursos existentes no sistema antes de reinventar a roda. Por exemplo: use o D-Bus para trocar mensagens, o GStreamer para tocar músicas, o GConf para guardar suas configurações... Faça parte do todo.

5. Evite "forks": "fork" nesse contexto significa baixar o código de um projeto em um determinado momento e começar um novo projeto a partir do original. Os forks começam geralmente porque desenvolvedores ou empresas que trabalham com software decidem transformar um projeto em um de seus produtos e tem pouca experiência com comunidades de software livre. Até aí tudo bem, só que as alterações feitas nesse novo produto muitas vezes não são devolvidas como melhorias ao projeto inicial. No longo prazo, o projeto original tende a ganhar mais adeptos e a se desenvolver mais rapidamente. O projeto derivado acaba ficando para trás, porque a empresa ou o desenvolvedor não tem "fôlego" para acompanhar as mudanças. Dividir é enfraquecer.

6. Não corrija só os seus bugs: Você certamente vai utilizar componentes externos, e muitas vezes vai se deparar com bugs nestes componentes. Seu primeiro impulso é fazer algum tipo de contorno no seu programa para evitar o bug. Antes de fazer isso, tente outra coisa. Investigue o problema, se você se sentir capaz de consertar, o faça. Mande o patch para os desenvolvedores, sugira melhorias, ou ao menos relate o bug. Desta forma você vai ganhar parceiros importantes para o seu projeto.

7. Documente: Se você não souber explicar muito bem o que você fez, ninguem vai usar.

8. Ouça os usuários: Saint-Exupery disse que "Tu te tornas eternamente responsável por aquilo que cativas". Se seu projeto evoluiu o bastante a ponto de ter usuários, você está no caminho sem volta. À partir de agora você tem a responsabilidade de mantê-los satisfeitos, responder às suas perguntas e atender às suas solicitações. Aceite as críticas e avalie a viabilidade das sugestões.

9. Termine o que começou: Não deixe o projeto parado. Lance versões novas, conserte os bugs, responda às listas de discussão. De fato seu programa nunca vai ficar "pronto", mas deve haver sempre uma versão funcional estável.

10. Ninguém é santo: O open source é uma causa nobre, revolucionária, idealista. Mas isso não quer dizer que só existem pessoas bem intencionadas e dispostas a te ajudar de maneira incondicional. Tome cuidado com oportunistas. Libere o código, mas proteja suas idéias. Não permita que decisões chave para o seu projeto acabem em mãos erradas antes de você implementá-las. Nesse caso um projeto igualzinho ao seu pode aparecer muito rapidamente, e você não levará crédito algum por isso.

Nerds, o Juízo Final está próximo!

Você também é daqueles que vê todas essas atrocidades acontecendo mundo a fora e acredita veemente que o fim do mundo como o conhecemos está próximo. Você acha que nossa civilização já foi longe de mais? Você é nerd?

Então não perca a dica que o Marcelo Lira deixou para você, bem aqui.

Sacudindo a poeira

Depois de ler o post do meu amigo Aurélio, insinunando que meu blog estaria coberto de teias de aranha, me senti compelido a fazer alguma coisa a respeito.

Então, cá estou eu, escrevendo o que me vem na cabeça.

Ah Aurélio... aquela viagem foi massa. Tão boa que você a repetiu no ano seguinte, e eu e a Tereza fizemos um trajeto parecido 3 anos depois. E pra falar a verdade, acho que já é hora de viajar novamente.

Este mês faz 2 anos que estamos na Manguetown. Quando volto para o Sul? Não sei. Abandonei todo e qualquer plano de volta.

Para quem pensa em se mudar e morar em outra cidade, posso dizer que o período de adaptação é lento e muitas vezes doloroso. O choque cultural, o clima diferente, a distância dos amigos e parentes vão fazer você se sentir menor, mas não deixe a cidade vencer você.

A Família vai bem. O Vinícius completa 1 ano esta semana. É nesta semana também que comemoro um ano de noites mal dormidas.

No trabalho, um dos meus desafios tem sido tentar equilibrar a equação família / trabalho. Crianças pequenas nos exigem muito tempo, e o fato de sermos pais de primeira viagem faz esta parcela de tempo aumentar ainda mais. Por esse motivo, tenho realizado uma cruzada em busca da maior produtividade no trabalho e mais efetividade nas coisas que faço.

Passei boa parte destes 2 anos trabalhando no Tapioca. O que me foi muito gratificante e me deu a chance de aprender muito. Outra coisa legal foi o tempo no projeto. Trabalhar em algo por muito tempo te dá a chance de aprimorar, de pensar por vários ângulos, de entender o papel de cada parte, cada módulo. É muito diferente de fazer pequenas coisas em pouco tempo e nunca mais voltar a olhar para o que foi feito. Recomendo a experiência a todos os desenvolvedores.

Algumas mudanças aconteceram no início deste ano, e agora além do Tapioca, também estou cuidando de outros projetos, que vou deixar para comentar em outros posts.

Com estas mudanças me afastei um pouco (bem mais do que eu gostaria) do desenvolvimento, e tenho exercido tarefas mais administrativas. Tenho aprendido muito com isso, mas sinto falta do tempo em que os problemas eram apenas lógicos.

Falando um pouco de projetos, já trabalhei em uma empresa onde controle de projetos era rígido, pesado, complexo, estressante - Um amigo o classificaria como "soviético", mas "britânico" seria um termo mais apropriado.

Também já trabalhei em uma empresa onde não havia qualquer tipo de controle. Caos total e demandas paralelas nos matinham patinando no mesmo lugar por meses.

O grande desafio, acredito eu, está em encontrar uma forma que se encaixe no tamanho de sua empresa ou equipe, e depois lutar para transformar isso em um hábito. Não acredito que nada feito sem um planejamento e um método tenha algum futuro.

OK, chega. Isso foi suficiente para acabar com as teias de aranha.