Sou um grande defensor da aprendizado no campo de batalha. E isso certamente inclui aquela que pode ser a batalha mais épica de todas: software de código aberto.
Contribuir para um projeto de código aberto. Há milhares deles, portanto, escolha o que mais lhe agradar. Mas escolha uma e realmente se dedique a ela, tornando-se um colaborador ativo. Absolutamente nada é mais prático, mais real, do que trabalhar em colaboração com desenvolvedores de software de todo o mundo e de todas as esferas da vida.
Se o senhor deseja aprimorar suas habilidades de programação, o que poderia ser melhor e mais digno de uma experiência profissional do que mergulhar em um projeto real de software de código aberto? Existem milhares, talvez centenas de milhares, e alguns deles, sem dúvida, mudaram o mundo.
Infelizmente, não foi isso que aconteceu com um desenvolvedor de código aberto em particular. Em um e-mail anônimo enviado a mim, ele relatou suas experiências:
Sou um programador com 14 anos de experiência, tanto na área acadêmica quanto no setor comercial, e atualmente estou procurando emprego. Tanto em minhas cartas de apresentação quanto em meu currículo, indico que Sou o arquiteto de alguns projetos Java de código aberto em que o código, o design e os aplicativos estavam disponíveis na Web.
Uma empresa pareceu impressionada com meu entusiasmo pelo trabalho, mas fazia parte de sua política fornecer testes de codificação. Isso me pareceu perfeitamente razoável e eu fiz isso usando a primeira solução que me ocorreu. Quando cheguei para a entrevista por telefone, o senhor passou cerca de cinco minutos me dizendo como minha solução de codificação era ineficiente e que eles não estavam muito impressionados. Em seguida, perguntei se ele havia analisado os projetos de código aberto que mencionei. Ele disse que não, mas parece que sua impressão já estava definida com base no meu desempenho no teste de codificação. O teste de codificação não indicava quais critérios eles estavam usando para a avaliação, mas minha solução parecia ter matado a entrevista.
Em outra ligação, eu estava conversando com um recrutador que estava tentando colocar alguém para um contrato de desenvolvimento em Java. Eu disse a ela que a maior parte do meu trabalho recente era de código aberto e que ela poderia inspecioná-lo se quisesse avaliar minha competência técnica. Cinco minutos depois, ela ligou de volta e disse que eu parecia não ter nenhuma experiência comercial recente. Eu tinha aplicativos de código aberto comprovados que usavam as tecnologias que eles queriam, mas isso não parecia importar.
Com outro recrutador, eu lhe disse que, mesmo anos atrás, quando trabalhei em projetos comerciais, antes de voltar a estudar, a natureza proprietária dos meus empregos me impedia de mencionar os detalhes de muito do que eu fazia. O crachá de experiência em software comercial não provava necessariamente minha competência técnica nem minha contribuição relativa para os projetos. O que minha experiência de trabalho no setor há muito tempo me ensinou foi como preencher uma planilha de horas e estimar o tempo para as entregas. Mas essa experiência parece um pouco ultrapassada agora para os recrutadores.
Esse é um péssimo histórico de entrevistas para a experiência de código aberto que eu defendia com tanta veemência. Ele continua:
Acho que é importante tentar ver o ponto de vista deles. Muitos projetos de código-fonte aberto provavelmente são mal escritos e criados em resposta a uma ideia genial, e não a requisitos de alguma comunidade de usuários. No meio acadêmico, o objetivo do desenvolvimento geralmente é mais a publicação de artigos do que o estabelecimento de uma base de usuários. O pessoal do setor às vezes tem a opinião (às vezes justificada e às vezes não) de que os desenvolvedores de código aberto que surgem de projetos acadêmicos não têm habilidades práticas. Não afirmo necessariamente que meu código-fonte aberto é o melhor do mundo, mas ele funciona, está documentado e está disponível para análise. Um dos motivos pelos quais trabalhei tanto em projetos de código aberto foi para facilitar as entrevistas de emprego. Ao fornecer aos possíveis empregadores grandes amostras de códigos de trabalho disponíveis publicamente, achei que daria a eles algo mais útil para pensar do que meu desempenho em um determinado teste de codificação ou se os acrônimos nas habilidades de trabalho correspondiam aos meus “anos de trabalho”. Estou muito ciente do hype por trás do código aberto. Já ouvi, já vivi e até mesmo já falei um pouco sobre isso. Mas, às vezes, é bom dar uma olhada na realidade. a experiência em código aberto é superestimada?
É desanimador ouvir tantos empregadores em potencial desconsiderarem completamente a experiência em projetos de código aberto. É uma parte da seu portfólio de programaçãoe qualquer empresa que não esteja disposta a dar uma olhada rápida em seu portfólio antes de entrevistá-lo já é suspeita. Isso reflete mal nos empregadores. Não sei se o senhor quero trabalhar em um lugar onde o conjunto de trabalhos anteriores de um programador é tratado como inconsequente.
Por outro lado, talvez a escolha do projeto de código aberto seja quase tão importante quanto a própria programação. Quantos projetos de código-fonte aberto trabalham em total obscuridade, resolvendo problemas com os quais ninguém se importa, problemas tão incrivelmente restritos que os autores são os únicos beneficiários possíveis? Assim como o software comercial não pode existir sem clientes, talvez a experiência com código-fonte aberto só seja válida se o senhor trabalhar em um projeto que atinja algum nível moderado de massa crítica e base de usuários. Lembre-se, o envio não é suficiente. Com código aberto ou não, se o senhor não estiver criando um software que alguém considere útil, se o senhor não estiver convencendo pelo menos um pequeno público de programadores que seu projeto vale a pena o suficiente para participar —
Então, o que o senhor está realmente fazendo?