Eu gostaria de dar um pouco mais de profundidade à resposta pensativa de Geoff . Em particular, quero lhe dar um pouco mais de perspectiva sobre o valor dos seus esforços de programação, em oposição aos seus esforços de pesquisa no início de sua carreira como acadêmico.
Você descobrirá que ser capaz de escrever um software para aumentar sua pesquisa científica fará de você um membro valioso de quase qualquer equipe de pesquisa. No entanto, esse tempo não será necessariamente considerado "valioso" por seus colegas acadêmicos ou por aqueles que estão contratando cargos acadêmicos.
De uma pesquisa de 2011 realizada em Princeton, "Uma pesquisa sobre a prática da ciência computacional" :
Os cientistas gastam uma quantidade substancial de programação em tempo de pesquisa. Em média, os cientistas estimam que 35% de seu tempo de pesquisa é gasto em programação / desenvolvimento de software. Embora inicialmente seja gasto algum tempo na redação do código, uma parte considerável é gasta em muitas atividades tediosas. Por exemplo, pesquisadores de Política e Sociologia que usaram o R / Stata tiveram que fazer uma programação considerável para adaptar os dados do censo em formatos que os pacotes individuais no R / Stata entendessem. Alguns pesquisadores em Engenharia Química tiveram que fazer engenharia reversa de código legado não documentado que executava simulação de chama, muito tempo após a conclusão dos autores originais, para adaptar o código a combustíveis mais novos ... Apesar disso, uma grande maioria desses pesquisadores considerou que "eles gastam mais tempo programando do que deveriam ",
Isso não significa que não é uma boa ideia implementar ou redesenhar uma biblioteca ou aplicativos principais, mas se você estiver envolvido em algum desenvolvimento sério de software (mais de 25% do seu tempo trabalhando com código), mantenha esses três pensamentos em mente.
A complexidade e o risco crescem exponencialmente com o tamanho do projeto e o número de desenvolvedores. Até que você tenha escrito ou trabalhado com partes maiores de software ou equipes de desenvolvedores que se estendem além do seu laboratório, será difícil obter uma boa apreciação disso e prever o esforço adequado.
Você precisa ser bom. É preciso uma certa maturidade, tanto como programador quanto como cientista de aplicativos, para escrever software útil. Você precisa saber quais são os recursos importantes, onde estão os riscos numéricos e ser capaz de prever o esforço de programação para um determinado conjunto de recursos e robustez. Obviamente, a única maneira de melhorar é gastar tempo em projetos nos quais você não é o líder ou que pode falhar ou atrasar com segurança, o que me leva ao meu ponto final.
Embora muitos laboratórios de pesquisa e posições industriais valorizem muito a experiência em programação, a programação científica pode atuar como um prejuízo potencial para sua carreira acadêmica, mesmo que seu software beneficie mais a ciência do que seus trabalhos. Todo esse tempo você gasta aprendendo a programar bem, programando, documentando seu código e tornando-o robusto, traduz-se em documentos que não estão sendo escritos. Um orientador nem sempre terá os melhores interesses do aluno em mente aqui, pois esse é um daqueles casos em que o aluno pode fornecer um trabalho que beneficia o grupo do orientador sem beneficiar a contagem de citações do aluno. Procure um ou mais mentores confiáveis no campo em que você está interessado e verifique se você tem um entendimento claro de quais contribuições são consideradas valiosas. academia.stackexchange.com é um excelente lugar para fazer uma pergunta de acompanhamento sobre isso.
Como nota de rodapé: o número de projetos de esforço individual que avançam significativamente em qualquer campo computacional está diminuindo constantemente, seja uma área de aplicação ou algo mais técnico, como álgebra linear densa. Um número crescente de pacotes de software que formam o "pão com manteiga" da pesquisa computacional tem 10 anos ou mais. O código científico que não atingiu esse nível de maturidade tende a ter mais erros, menos recursos e documentação esparsa. Tente evitar trabalhar com código imaturo que não é suportado ativamente, independentemente da idade.