Me gustaría dar un poco más de amplitud a la atenta respuesta de Geoff . En particular, quiero darle un poco más de perspectiva sobre el valor de sus esfuerzos de programación en comparación con sus esfuerzos de investigación en su carrera inicial como académico.
Descubrirá que poder escribir software para aumentar su investigación científica lo convertirá en un miembro valioso de casi cualquier equipo de investigación. Sin embargo, esta vez no será necesariamente considerado "valioso" por sus pares académicos o aquellos que contratan para puestos académicos.
De una encuesta de investigación de 2011 realizada en Princeton, "A Survey of the Practice of Computational Science" :
Los científicos dedican una cantidad considerable de tiempo de investigación a la programación. En promedio, los científicos estiman que el 35% de su tiempo de investigación se dedica a la programación / desarrollo de software. Si bien inicialmente se dedica algo de tiempo a escribir código nuevamente, una parte considerable del tiempo se dedica a muchas actividades tediosas. Por ejemplo, los investigadores en Política y Sociología que usaron R / Stata tuvieron que hacer una programación considerable para adaptar los datos del censo a formatos que los paquetes individuales en R / Stata entendieron. Algunos investigadores en Ingeniería Química tuvieron que aplicar ingeniería inversa al código heredado indocumentado que realizaba la simulación de llama, mucho después de que los autores originales se graduaran, para adaptar el código a los combustibles más nuevos ... A pesar de esto, la gran mayoría de estos investigadores sintieron que "ellos pasar más tiempo programando de lo que deberían "
Eso no significa que no sea una buena idea implementar o rediseñar una biblioteca o aplicaciones principales, pero si va a participar en un desarrollo de software serio (más del 25% de su tiempo trabajando con código), conserve estos tres pensamientos en mente.
La complejidad y el riesgo crecen exponencialmente con el tamaño del proyecto y la cantidad de desarrolladores. Hasta que haya escrito o trabajado con piezas de software más grandes o equipos de desarrolladores que se extiendan más allá de su laboratorio, será difícil para usted obtener una buena apreciación de esto y pronosticar adecuadamente el esfuerzo.
Necesitas ser bueno. Se necesita una cierta madurez, tanto como programador y como científico de aplicaciones, para escribir software útil. Debe saber cuáles son las características importantes, dónde están los riesgos numéricos y poder pronosticar el esfuerzo de programación para un conjunto dado de características y robustez. Por supuesto, la única forma de recuperarse es pasar tiempo en proyectos en los que usted no es el líder o que pueden fallar o retrasarse de manera segura, lo que me lleva a mi punto final.
Aunque muchos laboratorios de investigación y puestos industriales valoran mucho la experiencia en programación, la programación científica puede actuar como un posible perjuicio para su carrera académica, incluso si su software beneficia a la ciencia más que sus documentos. Todo el tiempo que pasa aprendiendo a programar bien, programar, documentar su código y hacerlo robusto se traduce en documentos que no se escriben. Un asesor no siempre tendrá en cuenta los mejores intereses de su estudiante aquí, ya que este es uno de esos casos en los que el estudiante puede proporcionar trabajo que beneficie al grupo del asesor sin beneficiar el recuento de citas del estudiante. Busque uno o más mentores de confianza en el campo que le interesa y asegúrese de tener una comprensión clara de las contribuciones que se consideran valiosas. academia.stackexchange.com es un excelente lugar para hacer una pregunta de seguimiento sobre esto.
Como nota a pie de página: el número de proyectos de esfuerzo de una sola persona que avanzan significativamente en cualquier campo computacional está disminuyendo constantemente, ya sea un área de aplicación o algo más técnico, como el álgebra lineal densa. Un número cada vez mayor de paquetes de software que forman el "pan de cada día" de la investigación computacional son 10 años mayores o más. El código científico que no ha alcanzado este nivel de madurez tiende a tener más errores, menos funciones y documentación escasa. Intente evitar trabajar con código inmaduro que no se admite de forma activa, independientemente de su antigüedad.