Eu trabalhei como o único desenvolvedor de uma empresa que conhecia uma tecnologia específica, como o único que fazia o tipo de programação que eu fazia e como contratado em situações semelhantes. (Também trabalhei em ambientes de equipe com outros desenvolvedores que conheciam ferramentas diferentes e com outros desenvolvedores que fizeram exatamente o que eu fiz.)
Prós de ser o único programador
- Como você mencionou, você freqüentemente tem a liberdade de usar quaisquer ferramentas ou idiomas que achar que pode aprender. Você nem sempre precisa defender seus colegas para obter permissão para trabalhar com a Nova Tecnologia X enquanto todos os outros estão usando a Tecnologia Atual Y.
- Você tem mais responsabilidades. Essencialmente, você atua como líder e desenvolvedor de projetos em cada um de seus projetos e, com sua capacidade de identificar e implementar novas coisas, também é efetivamente o chefe de departamento. (Não conte isso aos vendedores. Eles adoram conversar com os tomadores de decisão e você não tem tempo para conversar com eles.)
- Não há dúvida sobre crédito pelo trabalho que é feito: é obviamente você e você quem fez as coisas acontecerem.
- Você pode gastar mais tempo realmente trabalhando em seus próprios projetos e menos tempo em reuniões sobre projetos que são basicamente de outras pessoas (mas você está lá como uma pessoa de suporte, possível backup ou qualquer outra coisa.)
Contras
- Como David aponta em um comentário, você é o único desenvolvedor, portanto, nenhum desenvolvimento é feito sem você. Certa vez, eu me gabava de meu irmão de que eu era "o cara" de um projeto específico no trabalho. Ele descreveu com precisão minha situação para mim: eu estava preso. Não consegui seguir em frente nessa empresa porque nunca seria capaz de me livrar desse projeto. (Ele também estava certo. Foram necessários vários meses de treinamento por um longo período de tempo até que eu pudesse entregá-lo a alguém que fosse capaz de apoiá-lo.) Você pode achar difícil tirar férias verdadeiras quando nada puder seja feito sem você.
- Como aponta Pierre, não há ninguém no local para fazer revisões de código ou compartilhar as melhores práticas com você. Você pode entrar em contato com colegas de várias maneiras, mas nada é tão eficaz quanto dar um tapinha no ombro de uma colega de trabalho e pedir que ela olhe seu código por 5 a 10 minutos.
- Da mesma forma, você pode ter dificuldade em obter experiência com novas ferramentas. O treinamento externo pode ser tão raro quanto o período de férias: alguém se queixará de que a empresa não pode se dar ao luxo de ficar com o Language 3.0 por uma semana, quando não há ninguém para manter os aplicativos do Language 2.0 funcionando.
- O avanço na carreira pode ser extremamente difícil de gerenciar. Você pode não ter uma posição pela qual possa se esforçar, mesmo uma mudança no título pode ser difícil de obter e as revisões de final de ano não têm nenhum quadro de referência; portanto, um excelente trabalho pode passar despercebido, se não houver outra. razão do que ninguém realmente entende o que você faz.
Se você decidir se mudar para uma empresa na qual trabalharia como parte de uma equipe de programadores, não acho que sua experiência solo provavelmente a machuque muito. Sua falta de experiência com padrões de design não é necessariamente tão importante quanto sua vontade de aprendê-los. (Pode haver situações em que você esteja entrevistando um candidato com um histórico semelhante e também tenha experiência em quaisquer métodos usados pela empresa, mas isso é verdade para basicamente todos.)
Na mesma linha, sua falta de experiência em uma equipe é equilibrada por sua capacidade de usar muitos chapéus. Existem alguns desenvolvedores que são bons jogadores de equipe, mas nunca desenvolvem a capacidade de gerenciar um projeto; você já mostrou que pode fazer isso.
Eu recomendaria que, quando você é um desenvolvedor solo, gaste algum tempo lendo sobre ferramentas e técnicas que desenvolvedores semelhantes estão usando. Portanto, mesmo que você não as use, saiba que elas existem e você pode consultar eles durante uma entrevista, mesmo que apenas para dizer "Sim, eu li um pouco sobre os frameworks MVC, mas não os usei". Faça o possível para manter contato com outros desenvolvedores: vá a reuniões locais de grupos de usuários, leia e comente em blogs (ou mantenha um dos seus), tente participar de workshops periodicamente, assista a seminários on-line e outros. (Você também pode considerar sites como o lynda.com para treinamento interno: não é tão bom quanto uma conferência de uma semana em outro lugar, mas você pode assistir aos vídeos em seu próprio tempo e não deixar todos em pânico porque está fora do escritório.)