Я бы хотел еще больше расширить вдумчивый ответ Джеффа . В частности, я хочу дать вам немного больше представления о ценности ваших усилий по программированию, а не о ваших исследовательских усилиях в начале вашей карьеры в качестве академика.
Вы обнаружите, что способность писать программное обеспечение для расширения ваших научных исследований сделает вас ценным членом практически любой исследовательской группы. Однако это время не обязательно будет считаться «ценным» для ваших академических коллег или тех, кто нанимает на академические должности.
Из исследования 2011 года, проведенного в Принстоне, "Обзор практики вычислительной науки" :
Ученые тратят значительное количество времени на исследования программирования. В среднем, по оценкам ученых, 35% их исследовательского времени тратится на программирование / разработку программного обеспечения. Хотя первоначально некоторое время уходит на написание кода заново, значительная часть времени уходит на многие утомительные действия. Например, исследователи в области политики и социологии, которые использовали R / Stata, должны были сделать значительное программирование для преобразования данных переписи в форматы, понятные отдельным пакетам в R / Stata. Некоторым исследователям в области химического машиностроения пришлось перепроектировать недокументированный унаследованный код, который выполнял моделирование пламени, задолго до того, как первоначальные авторы закончили обучение, чтобы адаптировать код для более новых видов топлива ... Несмотря на это, подавляющее большинство этих исследователей считали, что «они тратить больше времени на программирование, чем они должны "
Это не означает, что это не очень хорошая идея для реализации или редизайна базовой библиотеки или приложений, но если вы собираетесь заниматься какой-либо серьезной разработкой программного обеспечения (более 25% времени вы работаете с кодом), оставьте эти три мысли в уме.
Сложность и риск растут в геометрической прогрессии в зависимости от размера проекта и количества разработчиков. Пока вы не написали или не работали с более крупными программами или командами разработчиков, выходящими за пределы вашей лаборатории, вам будет трудно хорошо оценить это и правильно спрогнозировать усилия.
Тебе нужно быть хорошим. Для написания полезного программного обеспечения требуется определенная степень зрелости, как программиста, так и ученого. Вы должны знать, каковы важные функции, где находятся числовые риски, и уметь прогнозировать усилия по программированию для данного набора функций и надежности. Конечно, единственный способ добиться успеха - это тратить время на проекты, которыми вы не руководите или которые могут благополучно провалиться или быть отсроченными, что подводит меня к моему последнему пункту.
Хотя многие исследовательские лаборатории и промышленные должности высоко ценят опыт программирования, научное программирование может стать потенциальным вредом для вашей академической карьеры, даже если ваше программное обеспечение приносит пользу науке больше, чем ваши статьи. Все это время вы тратите на изучение того, как правильно программировать, программировать, документировать свой код и делать его надежным, что превращается в статьи, которые не пишутся. В этом случае консультант не всегда будет иметь в виду интересы своего ученика, поскольку это один из тех случаев, когда ученик может выполнять работу, которая приносит пользу группе консультанта, без учета счетчика цитирования студента. Найдите одного или нескольких доверенных наставников в интересующей вас области и убедитесь, что у вас есть четкое понимание того, какой вклад считается ценным. academia.stackexchange.com это отличное место, чтобы задать дополнительный вопрос по этому вопросу.
В качестве сноски: число проектов с одним человеком, которые значительно продвигают любое вычислительное поле, неуклонно уменьшается, будь то область применения или что-то более техническое, такое как плотная линейная алгебра. Все большее число программных пакетов, которые образуют «хлеб с маслом» вычислительных исследований, старше 10 лет и более. Научный код, который не достиг такого уровня зрелости, имеет тенденцию иметь больше ошибок, меньше возможностей и редкую документацию. Старайтесь избегать работы с незрелым кодом, который активно не поддерживается, независимо от его возраста.