O senhor sabe qual é o sinal de um bom trabalho? O senhor aprende. Muito. E rapidamente. E o melhor de tudo: seu empregador e seus colegas incentivam e promovem isso. Esse tem sido o caso em meus (quase) três anos na Mozilla. A Mozilla continua a trazer à tona o que há de melhor em mim e me estimula a fazer mais e melhor. A seguir, sete das dezenas de lições que aprendi na Mozilla.
Ship. Ship. Ship.
Eu nunca tinha ouvido falar de “implantação contínua” até chegar à Mozilla – sempre trabalhei em projetos para sprints e, em seguida, forneci uma versão com tags git das melhorias de um determinado sprint. O problema era que os bugs da tag anterior eram adicionados à tag seguinte e, portanto, algumas semanas se passavam sem que o bug fosse corrigido na produção, embora o bug tivesse sido corrigido no trunk logo após seu relato. O envio para produção várias vezes ao dia promove a sensação de fluidez e permite que o senhor corrija os bugs AGORA em vez de em intervalos definidos. A implantação contínua também garante que os desenvolvedores não esperem até que acreditem que um recurso esteja 100% concluído antes de enviá-lo à produção – muitas vezes 90% é o suficiente para a primeira execução!
Não há problema em admitir a derrota
“Admitir a derrota” é um pouco duro, mas a Mozilla me ensinou que não havia problema em dizer “O senhor sabe de uma coisa? Isso não vai funcionar” ou “Podemos fazer melhor” e então começar de novo. Começar de novo é um processo doloroso, mas os desenvolvedores não são perfeitos, não podemos prever todos os problemas possíveis, e começar de novo é melhor do que ficar tentando encontrar uma solução que sempre terá falhas. Já vi muitos projetos e tarefas na Mozilla serem reiniciados e se tornarem exponencialmente melhores. O Persona foi abandonado para o Firefox Accounts, o aplicativo Firefox original para iOS foi retirado, etc. No final, é importante ter um produto sólido e não uma bola de fita adesiva, e não há problema em jogar fora a fita para obter o produto final.
Não há problema em ser um novato
A última coisa que você quer ser rotulado quando chega a um novo emprego é como um “noob” e, como a Mozilla está um passo à frente de 99% das lojas virtuais que existem, há uma grande chance de que você chegue pelo menos se sentindo como um noob por algum tempo. O que eu descobri na Mozilla é que não há problema em ser um novato. Por quê? Porque todo mundo quer ajudar o senhor a se tornar um novato e, depois, um especialista, porque tudo isso ajuda a causa geral. Tenho que acreditar que esse é o caso na maioria das organizações. Se alguma vez o senhor se sentir tolo ou inferior por saber menos, está no lugar errado. Não há problema em ser um novato, pelo menos por um curto período.
Escrever código “básico” em sites grandes ainda é desafiador e importante
Dizem que eu minimizo minhas realizações na Mozilla; ou seja, algo que considero básico não é tão fácil quanto eu acho que é. Quando eu digo que não fiz nada significativo o suficiente na Mozilla, as pessoas apontam que eu completei o redesenho da MDN. Eu sempre contra-argumento com “um desenvolvedor de 2-3 anos poderia ter feito isso”. O que eu não levo em conta é a responsabilidade: se eu errar, o senhor pode ser o responsável. milhões de outros desenvolvedores em todo o mundo teriam visto esses erros. Portanto, apesar de não ter feito o AJAX no MDN, o fato de eu não ter feito nenhum erro importante foi uma conquista em si.
Não há problema em sair do trabalho
Já fui rotulado de viciado em trabalho no passado e, embora eu lute timidamente contra esse rótulo, provavelmente é verdade. Afinal de contas, cheguei onde estou hoje fazendo horas extras por vontade própria em todos os empregos que tive. Quando meu filho nasceu, em março de 2013, comecei a precisar sair do trabalho um pouco “mais cedo” e a culpa de fazer isso estava me consumindo. Eu ainda estava cumprindo minhas 40 horas, mas não conseguia lidar com o fato de não estar lá o tempo todoespecialmente em uma organização global com funcionários que trabalham a qualquer hora. Com a ajuda do meu gerente, percebi que não há problema em avaliar cada dia com base em suas realizações, em vez de um relógio; afinal, corrigir um bug de prioridade grave em 15 minutos é mais importante do que 10 bugs de baixa prioridade em um dia.
Questões de localização
Tendo trabalhado com o Dojo Toolkit no passado, eu sabia que a localização era sempre um fator, mas a mudança para a Mozilla foi um grande alerta de que a localização era essencial. A Mozilla não apenas tem funcionários em todos os países, mas também tem colaboradores e usuários em ainda mais países, portanto, se o senhor perder uma mensagem localizada no código, saberá disso rapidamente.
As pessoas usam os rastreadores de bugs de forma diferente
Qualquer moziliano que tenha trabalhado comigo dará risada com essa. Sempre conheci os rastreadores de bugs como listas definitivas do tipo “VAMOS FAZER ISSO”, mas outros usam os rastreadores de bugs como mural de ideias, postagens de sugestões esperançosas e postagens de reclamações de preferências pessoais. Aprendi a não considerar as listas de bugs como um evangelho e, em vez disso, a me concentrar nas listas de prioridades fornecidas pelos gerentes de projeto. Isso tem sido muito bom, realmente difícil para mim, mas, quase três anos depois, consegui lidar com esse fato.
