Почему многие талантливые ученые пишут ужасные программы?

Я попробую. В основном это мое личное мнение, основанное на моем использовании и внедрении академического программного обеспечения. Как и многие из уже упомянутых комментариев, я не думаю, что плохое программное обеспечение является специфичным или даже более распространенным в академических кругах. Тем не менее, я думаю, что есть несколько причин, по которым это происходит, которые специфичны для этой области.

Программное обеспечение не является приоритетом

В академических кругах все ключевые показатели эффективности связаны с бумажными публикациями. Программное обеспечение, хотя и очень полезное, на мой взгляд, имеет очень небольшую ценность. Чаще всего программные реализации являются второстепенными или в лучшем случае доказательствами концепции, используемыми для увеличения количества цитирований (конечно, существуют исключения).

Как инженер-программист, я уверен, что вы осведомлены о знаниях, времени и усилиях, необходимых для создания качественного программного обеспечения. Учитывая мантру «опубликуй или умри» в академических кругах, на этот раз инвестиции часто тратятся на написание новой публикации. Это риск-вознаграждение.

Моя личная точка зрения заключается в том, что качественное программное обеспечение очень важно. Например, часто первым шагом в сравнении нового алгоритма с предыдущим современным уровнем техники является повторная реализация современного уровня техники из-за отсутствия реализации. Очевидно, что это приводит к временной задержке и может вызвать ряд ошибок. Тем не менее, я думаю, что в целом мало что изменится, пока программное обеспечение не будет каким-то образом оцениваться по показателям производительности.

Исследователи не программисты

Большинство исследователей имеют небольшой опыт программирования или вообще его не имеют, хотя YMMV зависит от области. Я думаю, будет справедливо сказать, что большинство исследователей научились программировать самостоятельно, столкнувшись с проблемами там, где им это нужно. Поверхностное изучение языка, как правило, не проблема, но вам нужно больше, чем поверхностные знания, чтобы создавать качественное программное обеспечение (выбор структур данных, шаблонов проектирования, глубокое знание языка и т. д.). Это препятствие для программистов-самоучек без образования в области компьютерных наук.

Другая проблема, с которой сталкиваются менее опытные программисты, заключается в том, что они не понимают, когда необходим рефакторинг. Вы можете найти бесчисленное количество плохо структурированного программного обеспечения. В исследованиях это естественное следствие итеративной реализации при разработке алгоритма, который превращается в чудовищную часть программного обеспечения, полную хаков. Однако этот монстр все еще может делать то, для чего он предназначен, если вы точно знаете, как его вежливо попросить. Для многих исследователей на этом история заканчивается: получить результаты и навсегда избавиться от зверя. Часто требуется серьезное время, чтобы помыть монстра перед публичной прогулкой. Это не всегда того стоит.

Тенденции в машинном обучении

Моя область — машинное обучение, в котором программное обеспечение ценится все больше. Примеры этой тенденции включают растущий репозиторий программного обеспечения и документ с изложением позиции некоторых громких имен в этой области . Я очень доволен этой эволюцией, потому что качественное программное обеспечение позволяет области в целом развиваться быстрее и повышает воспроизводимость.

Текущее решение проблемы — возможность публиковать статьи о рецензируемых реализациях программного обеспечения. Я знаю, что это возможно в машинном обучении и статистике . Такое ПО обычно более качественное.

В дополнение к ответу @MarcClaesen позвольте мне добавить точку зрения химика.

• Я программно-аффинный химик. По моему опыту, это редкий вид. Может быть, реже на этих сайтах. Хотя, возможно, не более редко, чем специалист по информатике в химической лаборатории, который внедряет хорошие лабораторные методы...

• Один важный момент, который следует иметь в виду, заключается в том, что студенты (по крайней мере, химики) не имеют никакого представления о компьютерном программировании во время учебы . Возможно, им придется познакомиться с использованием программ для работы с электронными таблицами и поиском в базе данных литературы, но это все.
  Я встречаю студентов, которые приезжают, чтобы выполнить свою исследовательскую практику и диссертацию в области, которая сильно связана с анализом данных. Крайне редко можно встретить студента, который уже имел какой-либо опыт программирования, хотя эта специализация «концентрирует» студентов, аффинных к математике. Я все еще ищу хорошие курсы в университете, куда я мог бы отправить их для введения в программирование.
  Мне нравится программная столяркаконцепция. Но обратите внимание, что даже здесь нет введения в идеи и образ мышления программирования. Точно так же вводные материалы, которые я знаю, на самом деле начинаются не там, где должны были бы начинать студенты.
  (Я долго искал хорошие знакомства, потому что мне трудно вспомнить, как выглядел мир до того, как я начал программировать в подростковом возрасте.)

• Так что большинство ученых, не занимающихся компьютерными науками, которых я знаю , изучали программирование автодидактически и методом «плавай или утони» . Обратите внимание, что большинство ученых-естествоиспытателей настроены на изучение языка программирования точно так же, как они исследуют поведение неизвестных веществ или инструментов .. Поскольку языки программирования являются детерминированными, таким образом сравнительно легко получить достаточное понимание, чтобы составить некоторый скрипт для вычисления чего-либо. (Я помню коллегу, который впервые столкнулся с языком программирования в Matlab во время работы над дипломной работой. Через год он «изобрел» концепцию функций.) Но во время работы над диссертацией у вас нет времени на изучение хорошей практики программирования. , даже если вы хотите. А потом от вас ждут работы и результатов. Изучение языков программирования не является невозможным, но обычно оно выходит за рамки того, что вы делаете. Ожидаемый объем обычно таков, что вы знаете, как это сделать, достаточно, чтобы выполнить некоторые вычисления.

• Связанная с этим практическая проблема, которую я вижу, заключается в том, что под рукой нет профессиональных программистов, поэтому для студентов нет хорошей практики программирования . Я думаю, что это все еще слепое пятно в организации рабочей группы. Ни в одной из групп, где я работал до сих пор, не было профессионального программиста. Некоторые группы были объективно слишком малы, чтобы позволить себе его (по крайней мере, если этот программист не был бы также хорош в химической/спектроскопической лаборатории... - найти это еще сложнее, чем найти химика, который изучил некоторые основы хорошей практики программирования). ).

• Большинство «монстровских» программ, которые я знаю, начинали свою жизнь как крошечный скрипт, написанный кем-то, кто только что изучил программирование, чтобы собрать воедино первые полезные строки в своей жизни. В течение следующих 2-3 лет (обычная обстановка: аспирантура) это неуклонно растет, и время всегда позволяет изменить только то, что нужно прямо сейчас. Поскольку люди хорошие, они отдают монстра другим людям, которые еще меньше разбираются в программировании. В тот момент, когда , казалось бы, достаточно опыта , чтобы отступить и провести тщательный рефакторинг на основе полученного опыта, докторская диссертация защищена, студент, как правило, переходит к совершенно другой работе, а проект по программированию забрасывается .

• Как ученый, я должен сказать, что процессы разработки программного обеспечения, на которые вы ссылаетесь, не очень хорошо применимы к большей части научного программирования, которым я занимаюсь: они требуют, чтобы у вас уже было представление о том, как проблема может быть решена (Как вы создаете результат [или спроектируйте свою архитектуру], если вы не представляете, как это может работать?). Часто даже результат неизвестен.
  С точки зрения фундаментальных исследований, когда вы знаете, как это работает, вы достигли конца фундаментальных исследований. Затем начинается прикладная разработка, и там я вижу, как можно применить процессы разработки программного обеспечения, но это по определению выходит за рамки фундаментальных исследовательских проектов.
  Базовую исследовательскую часть, OTOH, можно описать как метод проб и ошибок, позволяющий получить первое представление о конечном результате.
  Возможно, вы видите только верхушку айсберга научного кода, где было бы (было) оправдано приложить усилия для написания должным образом документированного кода с определенным интерфейсом и т. д. (другие хорошие практики, такие как модульные тесты, я бы предпочел см. уже с очень ранними попытками...): возможно, вы не видите огромных объемов кода, который создается для исследовательских идей, которые затем оказываются не очень хорошо работающими и забрасываются.

• Существует большая разница в подходах к использованию между большинством научных программ, которые я вижу, и традиционным программным проектом.. Большая часть этого программирования встречается в магистерских или докторских диссертациях. Объем всего этого довольно ограничен. Обычно это будет проект одного человека, потому что диссертация по определению является проектом одного человека. Таким образом, для единственного разработчика область возможного использования программного обеспечения составляет не более нескольких лет или этого одного проекта, и, как правило, только этот разработчик будет единственным пользователем. Это радикально отличается от «нормальной» разработки программного обеспечения. Противоположная точка зрения фундаментальных исследований заключается в том, что даже если метод станет широко использоваться и не окажется, что идея сработала только для одной проблемы, для которой она была изобретена, следующее, что произойдет, это то, что кто-то улучшит алгоритм, возможно /обычно приводит к совершенно другой реализации.
  Я не говорю, что этого нельзя или не следует делать с помощью удобочитаемой реализации. Но это не та ситуация, которая побуждает прилагать усилия, чтобы научиться писать читаемый код.

• Большая часть программирования, которое я делаю, заключается в написании скриптов для анализа данных, адаптированных к конкретному эксперименту . Прагматически, я обобщаю код в повторно используемые пакеты только тогда, когда я либо знаю с самого начала, что он мне понадобится снова, либо когда я действительно сталкиваюсь с этой ситуацией. Однако это поразительно редко по сравнению, например, с тем, с чем я сталкивался, работая студентом в качестве «обычного» разработчика приложения базы данных. Однако отчасти это, вероятно, связано с тем, что для некоторых проектов, в которых я знаю, что код будет использоваться повторно, я с самого начала настраиваю пакет/библиотеку, которую разрабатываю параллельно с имеющимся анализом данных. Но тогда моя точка зрения на это полностью отличается от точки зрения студента, поскольку я ожидаю, что буду использовать эту кодовую базу в течение многих лет.

• Один из самых приятных и удивительных (совершенно неожиданных) опытов. научное программирование, которое я сделал, было: я представил статью и параллельно выпустил программную реализацию. Один из рецензентов спросил, как я гарантирую правильность вычислений — что позволило мне ответить, что я использую юнит-тесты, и на самом деле пакет содержит примерно в два раза больше кода для тестирования, чем для вычислений. Это было неожиданно, потому что в моей области уже довольно необычно выпускать код вместе с бумагой — но я не видел до этого никакой бумаги, объясняющей, какие автоматические тесты предусмотрены для реализации, — поэтому я не ожидал, что эта информация может сделать это в настоящую бумагу.
  Я воспринимаю это как чрезвычайно многообещающий знак!

• Другим очень многообещающим признаком является то, что, когда я объясняю своим коллегам* концепцию систем контроля версий, многим нравится эта идея, и они описывают ее как то, что, по их мнению, должно существовать, но не известно, на самом деле существует за рамками отслеживания изменений Word. (Хотя для исследовательского рабочего процесса я все еще думаю, что VCS, которые я знаю (svn, git), работают так же, как и для проектов чистого кодирования.)
  Обновление несколько лет спустя: заставить коллег-непрограммистов использовать контроль версий по-прежнему очень сложно. обсуждение (также потому, что VCS, работающая с двоичными файлами, не улучшалась так быстро, как я надеялся). В основном я вернулся на один шаг назад, и теперь мы используем nextcloud для обмена данными, что, хотя и не обеспечивает реального контроля версий, по крайней мере, позволяет всем говорить об одном и том же состоянии данных/файлов.

* также те, кто вообще не занимается программированием, которые вводят измеренные данные в систему или делают, например, медицинскую/биологическую интерпретацию.

обновление: исходя из опыта, который я приобрел с тех пор, как впервые написал этот ответ, теперь я бы поставил организационные аспекты намного выше:

В основном я покинул академию, сейчас я работаю фрилансером, но у меня все еще есть исследовательские проекты, в которых я выступаю в роли субподрядчика для (академических) исследовательских институтов. Для определенной процедуры предварительной обработки, которую мне поручили предоставить, я получил категорический отказ платить за «ненужные вещи», такие как модульные тесты и инкапсуляцию рабочего кода в библиотеке/пакете с собственным пространством имен. Метод представляет собой процедуру анализа данных, поэтому наиболее важным типом ошибок являются ошибки в логике программирования (от которых модульные тесты могут обеспечить определенный уровень защиты). Он предназначен для использования в R, т.е. в сценариях интерактивной работы, что предполагает высокий риск нарушения рабочего пространства пользователя, если сторонняя функциональность не инкапсулирована в собственное пространство имен.
Этот отказ исходил от высшего руководства научно-исследовательского института.

@gerrit комментирует, что университетская бюрократия может не позволить группе иметь профессионального программиста. Я думаю, что это, вероятно, верно как повседневная реальность. Однако я также думаю, что это связано с организационной слепотой, о которой я здесь говорю. Если бы высшее руководство в академических кругах действительно понимало важность использования самых современных методов работы при обработке данных и разработке программного обеспечения, администрация университета, вероятно, также имела бы другое мнение по этому поводу. И если бы заявки на гранты действительно включали профессиональные темы управления данными и программным обеспечением, возможно, ситуация улучшилась бы и на этом уровне. Я думаю, что академические круги здесь находятся в некотором роде порочного круга: все, кроме студентов, считаются очень дорогими, поэтому в проектные предложения не смеют включать какой-либо «технический» персонал.
И, конечно, высшее руководство может быть убеждено своими коллегами или примерами в том, насколько помогает профессиональное отношение к этим аспектам, но пока оно не будет убеждено, будет крайне сложно найти деньги и разрешение на то, чтобы проверить, можно ли и как это сделать. сильно помогает.

Есть несколько отличных ответов, и я хотел бы добавить свои пять копеек по этому вопросу, поскольку это очень актуальный вопрос, о котором я часто думаю или обсуждаю с моими коллегами. Неизбежно будут некоторые совпадения с частями существующих ответов, я только надеюсь, что в этих случаях смогу дать немного другую точку зрения.

Я изучал прикладную математику по специальности и получил степень магистра в области биологического и медицинского моделирования (что бы это ни значило). У меня закончился перерыв в работе над докторской диссертацией по биоинформатике и системной биологии . Я почти исключительно работаю в silico и стал создателем многих из этих чудовищных, уродливых и грустных программ.

Во-первых, я думаю, что вы делаете небольшую, но важную ошибку, формулируя свой вопрос. Ты говоришь:

« Почему многие талантливые ученые пишут ужасные программы? »

вместо этого я бы предложил

« Почему программы, написанные талантливыми учеными, оказываются ужасными? »

Разница тонкая, но существенная для остальной части моего ответа. В конце концов, ученые не собираются за одним столом и не решают написать ужасное программное обеспечение.

Многие ученые, которые пишут код, не имеют образования для написания программного обеспечения.

Существует серьезная разница между знанием того, как программировать, и знанием того, как писать программное обеспечение . Я прошел почти столько же курсов на факультете CS, сколько и по математике, во время учебы на бакалавриате и магистратуре, поэтому я чувствовал себя довольно уверенно в своих навыках программирования. Так было до тех пор, пока я не столкнулся с такими вопросами, как упаковка, управление зависимостями, жизненные циклы, лицензирование и т. д. Во время учебы ни один из них не входил в учебную программу удаленно. Я не знаю, изучают ли эти понятия те, кто занимается компьютерными науками в качестве старшекурсника, но мне, черт возьми, это никогда не было нужно, пока я вдруг не узнал их.

Боссы/руководители многих ученых, которые пишут код, не обучены написанию программного обеспечения.

Вам не только нужно выучить кучу новых вещей, но представьте, что вы не можете объяснить, почему для вас важно выучить эти вещи своему боссу. Я довольно часто сталкиваюсь с этой проблемой, так как написание кода часто сравнимо с выполнением лабораторных работ в нашем отделе. Люди думают, что написание кода происходит само по себе и желательно быстро. У меня часто были дискуссии с коллегами, когда они в шутку упоминали, что все, что они хотят услышать от меня, это «компьютер говорит да/нет?» Сколько времени может занять что-то новое, очень часто недооценивают, постоянное написание тестов обычно рассматривается как пустая трата времени. Что подводит меня к следующему пункту....

Хорошее программное обеспечение не ценится в академических кругах, по крайней мере, не так, как в промышленности.

Мерилом компетентности в научных кругах являются публикации, а формой валюты — цитирования. Вы постоянно находитесь в форме соревнования, чтобы придумать что-то новое и полезное, и только первый получит приз. Клоны не существуют и не живут особенно долго в академических кругах. Напротив, в промышленности вы можете завоевать долю рынка за счет лучшей рекламы, более крутого графического интерфейса или более низкой цены. В академических кругах, если какой-то метод уже опубликован, вам нужно сделать что-то еще.

Точно так же, если вы уже опубликовали метод, то дополнительные функции, очистка, оптимизация и т. д. этого программного обеспечения для проверки принципа часто недостаточно хороши, чтобы гарантировать новую публикацию, что практически означает, что вы потратили месяцы работы впустую. . Печально, но факт...

Ожидания меняются, вы должны ожидать неожиданного

Может быть, это мелочь, но я не могу не подчеркнуть ее, потому что она снова и снова кусала меня в спину. Вы просто не получите надлежащих спецификаций для нового проекта. Часто они либо слишком расплывчаты, либо слишком строги (нереалистично). Иногда то, о чем никогда не упоминалось, оказывается ожидаемым. Затем, чтобы добавить оскорбление к травме, спецификации меняются в зависимости от нового формата данных, какой-то другой базы данных, новых функций или просто другой классной вещи, о которой думал босс, когда он был на конференции... Вы пишете и переписываете решения для та же проблема, он становится беспорядок.

Обычно вы не получаете необходимой поддержки

Несколько аспирантов по программированию на моем факультете, мы пытаемся улучшить себя, следя за тенденциями. Изучение лучших практик, например, через SO. Но чаще всего, когда вы хотите попробовать что-то новое, вы видите препятствия; либо ИТ-отдел считает, что вы слишком неприятны, либо начальник считает, что вы бездельничаете, либо люди, у которых вы просите помощи, думают, что вы ни хрена не знаете и зря тратите их время . Например, мне потребовалось несколько месяцев переговоров и переписки туда и обратно, чтобы получить доступ к нашему серверу контроля версий из дома. В конце концов, он просто работает быстрее, чтобы пропустить некоторые лучшие практики.

Новейшие самые крутые тенденции CS не всегда хорошо документированы для людей, которые не являются экспертами.

Я пытался запачкать руки несколькими «новыми» технологиями, которые часто требуют крутой кривой обучения. Иногда это действительно не стоит усилий. Лучший пример, который у меня есть, это Maven. Поскольку я часто работаю на Java, я подумал, что мне следует использовать современные инструменты для упаковки и управления зависимостями. Но мой вывод, после того как я так долго боролся с этим, таков: это @%&$! У меня действительно нет ни сил, ни времени, чтобы копаться в этой каше с документацией.

Нижняя граница

Погорев над этим в последние годы, я пришел к следующему выводу, который вселил в меня внутренний покой:

« Я не разработчик программного обеспечения. У меня нет образования и мне не платят за написание программного обеспечения. Написание программного обеспечения — это не моя работа; обучение решению определенных проблем — это … » .

Надеюсь, этот ответ даст вам некоторое представление о том, почему программное обеспечение, написанное учеными (исключительно талантливыми или нет), часто не соответствует стандартам, установленным разработчиками программного обеспечения.

Просто в дополнение к отличным ответам Marc Claesen и cbeleites . В академических кругах, когда люди пишут код, обычно бывает так:

• Проблемы часто бывают открытыми , поэтому, возможно, структура данных, с которой люди начинают, позже будет использоваться для чего-то другого, для чего она неоптимальна. Также многие вещи не спроектированы должным образом, потому что все меняется. Сравните это с написанием типичного коммерческого программного обеспечения, где вещи указаны с самого начала и обычно далеки от передовых (пусть даже требовательных, а не «в первый раз»).
• Сопровождаемость не является обязательным требованием — небольшая часть программного обеспечения, не используемая в дальнейшем, и никто другой не собирается брать на себя код (и гораздо легче понять свой собственный код, чем код других — даже если он хаотичен, вы знать, что где). Сравните это с ситуацией, когда после ухода автора за кодом будет следить кто-то другой (или нужно постоянно думать о найме еще одного разработчика, чтобы ускорить прогресс).
• Люди работают в одиночку или над унаследованным кодом — совершенно противоположные ситуации, но дающие схожие результаты. В первом случае (как указано выше) люди могут понять свой хаотический код; во втором (например, внесение изменений в старый код на Фортране) - людям приходится перенимать, внося небольшие, часто - не непредвиденные, изменения, приспосабливаясь к существующей кодовой базе.

Лично я (исходя из чисто академического образования) научился большинству хороших методов кодирования, сотрудничая с другими:

• учась у других - некоторые методы кодирования не требуют больших умственных способностей, но большого опыта - мудрость говорит о том, что данное «умное решение» станет проблематичным для поддержки в долгосрочной перспективе (как и большинство kludges (= уродливые хаки ) ),
• сотрудничая - много раз я понимал, что то, что было достаточно ясно для меня, было совершенно непонятным (но мощным )cthulhu fhtagn для других (и наоборот - хороший код для кого-то был сложной загадкой для меня),
• в общем, многие хорошие практики на самом деле сводятся к наименьшему общему знаменателю мастерства (а неумные люди уже близки к этому); умный код одним будет труден для других.

А десерт - проклятие одаренных , комментарий к последнему пункту:

Вы блестящий разработчик, более способный, чем я, и, возможно (я говорю это после размышлений и со всей серьезностью) лучший в традиции Unix со времен самого Кена Томпсона. Как следствие, вы страдаете от проклятия одаренного программиста — вы так сильно полагаетесь на свои способности, что никогда не научились ценить определенные виды самодисциплины программирования и мастерство проектирования, которые простые смертные должны развивать, чтобы справляться с подобными вещами . сложности проблемы, которую вы едите на завтрак.

(Источник: http://lwn.net/2000/0824/a/esr-sharing.php3 или сокращенно: http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN )

И это было адресовано Эриком С. Рэймондом Линусу Торвальдсу ...

И в качестве примечания (поскольку программирование становится все более и более распространенным), теперь ученые осознают важность хороших практик и рабочих процессов, см., например, http://software-carpentry.org/ .

Почему Руаль Амундсен не проложил дорогу к Южному полюсу?

Почему Эдмунд Хиллари не построил горнолыжный подъемник на пути к Эвересту?

Работа ученых состоит в том, чтобы находить решения проблем, ранее считавшихся неразрешимыми, учить других (и, несмотря на шаблонность в их заявках на гранты, эта целевая аудитория — другие исследователи ), как решать проблемы и делать все вышеперечисленное как можно эффективнее.

Академики заботятся о качестве своего кода только в той мере, в какой он работает «достаточно хорошо» в качестве доказательства концепции их идей и, возможно, что его можно повторно использовать в будущих проектах. Рефакторинг кода, написание документации, тщательная проверка ошибок, настройка автоматизированных сборок и т. д. — это пустая трата времени, если только время, затраченное на улучшение программного обеспечения, не сэкономит им по крайней мере столько же времени на получение рабочих результатов. Для четырех пунктов, которые я перечислил, это почти никогда не бывает.

Конечно, когда их исследования окажутся важными с практической точки зрения, многие исследователи вернутся назад и напишут хорошо спроектированные реализации своих более ранних алгоритмов (обычно в рамках соглашения о консультационных услугах с профессиональными разработчиками программного обеспечения), и у них была подготовка и талант. сделать это раньше - просто не стоило тратить время.

Даже будучи профессиональным разработчиком программного обеспечения, смогли бы вы разработать то, что вы называете хорошим программным обеспечением, когда требования меняются непредсказуемым образом каждую неделю? Это мир, в котором исследователи живут и выживают.

Заниматься научными исследованиями означает идти в неизведанные области. Исследователи не знают, какие функции им могут понадобиться от монстра завтра утром. Это зависит от результатов, которые они получат сегодня в полночь. Научная программа аккумулирует слишком много итераций, добавляя функции, которые никому и никогда не понадобятся.

Любые попытки оставить место для новых функций, добавить модульность часто даже ухудшают ситуацию, когда эти «общие подходы» должны быть позже взломаны, чтобы сделать дальнейшие изменения гораздо более радикальными, чем это ожидалось (и поддерживалось) «общая структура» .

В результате программа, которая развивается непосредственно в процессе исследования, часто может использоваться только в качестве прототипа и должна быть переписана перед выпуском ее в качестве коммерческого программного обеспечения или программного обеспечения FOSS. Профессиональный программист, если его нанять, вероятно, мог бы сделать несколько лучше, но нестабильность требований, скорее всего, все равно помешает «дойти» до действительно отличного финального дизайна.

Во многих аспектах написание программного обеспечения — это искусство. Многие великие художники не родились такими, они на самом деле научились этому искусству за годы обучения, и в промежутках между ними было много плохих результатов.

Возьмите лист бумаги и попробуйте нарисовать кого-нибудь, кого вы знаете. Даже если перед вами картинка, она, скорее всего, будет выглядеть комично. Теперь настоящий художник спросил бы вас, почему вы не видите теней, не можете придумать правильную перспективу или поставить уши в совершенно неправильное положение, хотя перед вами была четкая картинка. Однако это вызвано не вашим высокомерием, а отсутствием у вас опыта правильного взгляда на модель. Технически это как-то связано с тем, что вы используете не ту половину своего мозга, и вас можно научить менять это. Только не раньше завтра.

Ученые работают на основе теории. У них есть теория, они хотят ее доказать, они пишут код, ориентируясь только на текущую теорию. То есть вы видите нос, но не тени вокруг него. Если вы будете учить их в течение месяца или, может быть, лет использовать правильные приемы и «удары», чтобы делать это правильно, они могут измениться. Однако вы должны спросить себя, стоит ли это того времени. Иногда это так, но иногда ученые должны просто придерживаться научных вещей, а художники не должны внезапно начинать радиоактивную химию на ровном месте.

Если вы решите учить их, помните о том, что художник начинает свой первый день: это не их высокомерие, это отсутствие у них знаний о том, как использовать правильные части мозга. Есть причина, по которой «Разработка программного обеспечения» — это 3-летнее обучение, после которого вы считается уровнем «новичок».

Отличная дискуссия, и я думал то же самое много раз. Существует и другой тип программного обеспечения, который не упомянут выше — программы, разработанные в академических кругах и не являющиеся частью исследовательского проекта. Существует множество проектов по разработке программного обеспечения, которые больше ориентированы на логистику, обучение и т. д. (кликеры, захват видео, интранет, библиотечное программное обеспечение и т. д.). Иногда они обрабатываются профессионально и становятся совместными проектами и т. д., но очень часто они являются результатом того, что у кого-то есть помощники с дипломом, которые немного разбираются в программировании, которые кодируют что-то, что, возможно, работает, но, конечно, не имеет документации, тестирования, версии. контроль, документация по требованиям и т. д. - и когда они выпускаются и идут дальше, удачи всем, кто хочет попытаться поддерживать его... Частично это также является "ложной экономией"

Я лично, вероятно, также несу ответственность за какое-то дерьмовое программное обеспечение, будучи аспирантом в области компьютерного обучения. Я надеюсь, что знаю немного больше о лучших практиках, контроле версий и т. д., чем многие, но у меня никогда не было профессиональной подготовки, и, что, возможно, более важно, я никогда не был частью сообщества практиков, наставляемых лучшими исследователями. и т.д. В сфере образования в какой-то степени даже сложнее, потому что очень мало технически подкованных студентов/преподавателей. Я, конечно, очень широко использую SO, списки рассылки и т. д., но я уверен, что мой код можно было бы значительно улучшить, если бы у меня был старший коллега по коридору, который просматривал бы мой код и оставлял отзывы и т. д.

На самом деле, один из комментариев выше заставил меня задуматься об этом — в университетах довольно часто есть статистические консультанты, которые в какой-то степени доступны исследователям. (В нашей библиотеке есть кто-то, к кому мы можем получить доступ бесплатно в течение одного или двух часов, а затем мы должны заплатить плату, но я знаю, что многие люди пользуются этим, и я нашел очень полезным сесть с ними и просматривая дизайн своего исследования, свои предположения, статистический дизайн и т. д.). Было бы интересной концепцией иметь «консультанта по разработке программного обеспечения» (не уверен в названии), который в основном был бы профессиональным рецензентом кода... Но также мог бы помогать людям обдумывать свои потребности, выяснять полезные фреймворки или библиотеки, навигация по контролю версий, лицензии с открытым исходным кодом и т. д.

И, конечно же, изменить систему поощрения на вознаграждение за выпуск (или улучшение!) качественного кода невероятно важно, но очень сложно. Я думаю, что упражнение Mozilla Academic Code Review является действительно интересным экспериментом в этом отношении.

Вернемся к написанию Python-скриптов для анализа кликлогов MOOC :)

Потому что программирование похоже на езду на машине: оно нужно всем, но большинство из нас не профессионалы. Как научиться программированию? Обычно покупает/одалживает книгу "Python или что-то в этом роде для начинающих". Все будет о том, как сохранить файл, как запустить программу и как вызвать функцию. После этого я могу сделать все, что мне срочно нужно сейчас или вчера.

Где я узнаю о шаблонах проектирования, передовых методах разработки программного обеспечения, гибкой разработке и о том, как писать красивый код? НИГДЕ! Точно так же, как после прохождения курса вождения автомобиля я считаю, что у меня все в порядке, и я не читаю по 5 часов в день о том, как быстрее ездить по мокрой дороге, я не хожу по книжным магазинам и не читаю все книги по CS, чтобы это могло быть связанным со мной. Даже если я выйду в сеть, возможно, Software Carpentry — единственный подходящий ресурс! Серьезно, если кто-то знает что-то подобное, пожалуйста, напишите где-нибудь здесь!

Я не буду подрабатывать, чтобы изучить полный курс CS в MIT, чтобы собрать воедино мое «привет-слово» дня. И я не удивлюсь, если даже парни из CS в MIT выучат половину хороших практик программирования вне школы, на работе, а не после 4-5 лет сидения в школе.

Резюме: репликация или ее отсутствие.

подробности:

Мои наблюдения (к сожалению, маленькие n и единственный POV) заключаются в том, что основная причина, по которой как непрофессиональные, так и талантливые ученые пишут ужасное программное обеспечение, заключается в том, что это просто «противоположность репликации». Они не видят ценности в воспроизводимых исследованиях, они не ожидают, что их работа будет воспроизведена, и они, конечно же, не желают, чтобы их работа была воспроизведена. (Они просто хотят, чтобы их работу цитировали :-)

Я BSCS, который отсидел срок «в промышленности», включая одну известную безликую аббревиатуру. Все кодеры, которых я знал, по крайней мере, использовали и ценили программное обеспечение с открытым исходным кодом, и многие из них внесли свой вклад (особенно мой последний прямой проект кода). OSS ценится только в той мере, в какой она используется и расширяется. (AFAICS - я что-то упустил? экзотические языки, которые изучаются, но не используются?) Конечно, данная OSS используется только в том случае, если она надежна, проверена / тестируема, хорошо документирована и т. д. (и расширена только в том случае, если она общедоступна).

Теперь я вернулся в школу в качестве моделиста окружающей среды (в основном атмосферы). Люди, с которыми я работал, по большей части даже не размещают свой код в общедоступных репозиториях (даже те, которые намного моложе меня — это не проблема поколений, AFAICS), не говоря уже о создании документации, модульности, комментариев (будь то в код или в коммитах) и другие возможности, которые можно ожидать от OSS. Это, по-видимому, связано (основано исключительно на разговорах, а не на убедительных эмпирических данных) с их предположением (и, как правило, надеждой), что их код не только никогда не будет использоваться кем-либо еще (и, вероятно, никогда больше не будет использоваться кодировщиком). ), но даже не увидеть .

К сожалению, я не понимал этого, когда меня «нанимали» в качестве аспиранта. (Я почти ничего не знал об аспирантуре — я только что «выпрыгнул из окна» из-за безликой аббревиатуры и знал только то, над чем хотел работать — и был особенно невежественен в отношении культурных различий между информатикой («компьютерная наука» — это известное неправильное название) и «точная наука».) Я выбрал своим советником профессора, область работы которого меня больше всего интересовала. Как только я начал смотреть на его код, меня вырвало. Я пытался его об этом заинтересовать, и его отношение было примерно (т.е. не цитата) "бумажка имеет значение, код - нет". Он никогда не отправлял код вместе с документами и не публиковал код, а использовал почти исключительно малоизвестный, {проприетарный, дорогой} {язык, среду разработки} (как, честно говоря, делают многие из его коллег, некоторые из которых являются очень громкими именами в нашей небольшой области). Имея некоторый опыт в области философии науки и зная, что модели, над которыми мы работаем, имеют реальные последствия для государственной политики (например, серьезные расходы), я спросил, как можно воспроизвести его результаты. Он сказал (и это цитата): «Они должны доверять нам — мы ученые». Он больше не мой советник...

Хотя я подозреваю (опять же, на малом n), что приведенные выше наблюдения действительно «измеряют центральную тенденцию», все же не тьма и пустота :-) В моей собственной области есть образцовое программное обеспечение, такое как GEOS- Chem . К сожалению, GEOS-Chem «такая, какая она есть» во многом (ИМХО) благодаря команде поддержки GEOS-Chem , которая предоставляет своего рода инфраструктуру, удивительно редкую в моей области. Следовательно, я подозреваю, что GEOS-Chem, если бы качество программного обеспечения измерялось в этой области с высоким охватом (я что-то упустил?), вероятно, на 2-4σ лучше, чем среднее значение.

Короткий ответ на этот вопрос заключается в том, что ученые-исследователи (в основном) не программисты (хотя время от времени они публикуют программное обеспечение).

Я работаю в сложной вычислительной сфере, а это означает, что многие разные вещи, над которыми я работал в прошлом, могут быть упакованы в программное обеспечение. Исходя из моего собственного опыта, вот несколько препятствий, которые мешают мне написать полноценную программу на основе моей работы:

1. Многие мои исследования включают открытые исследования, поэтому код также написан для этой цели . Написание программного обеспечения подразумевает, что у меня есть существенное понимание всего, что я исследовал до сих пор, что не так (и не будет в обозримом будущем).

2. Каждая из вещей, над которыми я работал, слишком мала по отдельности, чтобы быть написанной в виде программного обеспечения . Чтобы расширить масштабы вещей, нужны исследования, а не программное обеспечение.

3. Многие исследования находятся вне моего контроля. Всегда будут новые возможности и направления для исследований, а это означает, что некоторые исследования (и код, написанный вместе с ними) будут прерваны , это восходит к пунктам, сделанным выше.

4. Большую часть времени я пишу код MATLAB в ОС Windows. Даже если я не переключаю свою ОС (скажем, на Linux), у меня есть варианты: перевести код MATLAB на какой-нибудь язык .NET или экспортировать его как объект C/C++. Я могу ошибаться, но я думаю, что разработка программного обеспечения на любом языке сложна и требует много времени .

5. Причина, по которой большинство инженеров-исследователей пишут код с использованием MATLAB, заключается в том, что время выполнения исследований имеет высокую дисперсию. В большинстве случаев что-то нужно делать еженедельно, и это может включать в себя очень новые эксперименты. Когда он занят, время оборота может быть в течение дня. Эти эксперименты оптимально проводить с использованием очень стабильной платформы, такой как MATLAB или Mathematica , тогда как для некоторых других языков ваш код не сможет скомпилироваться, если вы случайно вставите табуляцию где-нибудь или пропустите двоеточие. Опять же, это подпитывает вещи, которые я упомянул в пунктах выше, и еще больше ухудшает надлежащие навыки разработки программного обеспечения, даже если вы пишете код.

6. Комментатор упомянул, что разработка программного обеспечения отлично справляется с машинным обучением. С моей точки зрения, причина этого в том, что в таких областях, как оптимизация, машинное обучение, обработка сигналов, А. вещи можно визуализировать, Б. вещи изучаются с 1950-х годов, В. многие люди пытаются проникнуть в В этой области D. многие вещи действительно просты с вычислительной точки зрения, и во многих случаях достаточно неточного решения (которое работает в очень частных случаях). К сожалению, большинство из нас не работает в таких удобных сферах .

7. Откровенно говоря, у всех нас есть жизнь, не связанная с исследованиями . Разработка программного обеспечения может потребовать личного участия или сотрудничества, которое длится дольше, чем вся продолжительность исследовательского проекта.

Я не думаю, что я талантливый исследователь, но я занимался исследованиями в области программного обеспечения, и это фактически создало часть программного обеспечения. Для этой части я также сотрудничал с группой людей из крупной технологической компании. Очевидно, наш подход к программному обеспечению сильно отличался.

• Когда я писал программное обеспечение, я выбрал самый простой путь, чтобы продемонстрировать, что мои идеи должны быть правильными. Я не тратил много времени на разработку программного обеспечения, потому что у меня не было времени! Я изо всех сил старался заставить его работать, и я пытался сделать его читаемым и доступным для взлома (потому что я знаю, что кто-то другой в конечном итоге возьмет на себя управление), но я не тратил много времени на его разработку. Я был в основном заинтересован в том, чтобы заставить его работать, чтобы я мог что-то с ним делать (и показать, что мои идеи верны!)

• На самом деле это была хорошая часть. В моем исследовании мы использовали библиотеку исследовательского программного обеспечения, созданную другой исследовательской группой в другой стране. На самом деле они не знали, что люди используют их программное обеспечение! В результате они проверили изменения, из-за которых программное обеспечение не собиралось. Более того, код был трудно читаемым, и мы не могли его исправить сами (это был C++, поэтому сообщения об ошибках тоже не очень помогают). Нам пришлось связаться с ними лично, чтобы исправить это.

• Итак, могут ли ученые писать хорошие программы? Да, по крайней мере, многие могли (иначе они не смогли бы преподавать курсы программирования). На самом деле, у меня был профессор, который был феноменальным инструктором по программированию, но чей лично написанный код не так уж и приятен для чтения. У академиков просто нет времени ковыряться и делать свой код красивым. Если бы у них было больше времени для улучшения своего программного обеспечения, я уверен, что они бы это сделали.

• OTOH, люди в технологической компании действительно были заинтересованы в создании программного обеспечения, которое они могли бы использовать (и, возможно, в связи с этим, подготовить некоторые исследовательские работы). Они следовали своим стандартам кодирования. Они глубоко спроектировали это. Они использовали управление сборкой, интеграционные тесты и тесты покрытия. Они делают это, потому что (1) у них есть время и деньги, и им за это платят, и (2) они действительно собираются это использовать!

Качества, которые делают хорошего ученого, не всегда делают хорошего программиста (за исключением, как указал ОП, когда «наука» оказывается информатикой.

Компьютерное кодирование — это высокоточное искусство. Многие люди, включая хороших ученых, недостаточно точны, чтобы легко писать хороший код. Это особенно верно в отношении более «интуитивных» ученых.

Многие ученые находят компьютерное программирование «скучным» и по этой причине не преуспевают в этом. Это правда, что «обычная» наука требует детальной работы, но не до такой степени программирования, которое многие (включая вас) считают «отупляющим».

По сути, если существует нулевая (или очень слабая) корреляция между хорошим ученым и хорошим программистом, вы получите всю гамму способностей программирования, хороших, средних и ужасных из группы ученых.

Есть три основные причины.

Во-первых, ученые не являются профессиональными разработчиками программного обеспечения. Это верно даже для специалистов по информатике, и в большей степени для математиков, физиков, химиков, биологов, социологов и так далее. Не то чтобы они не могли, большинство людей, которые достаточно умны, могли бы стать профессиональными разработчиками программного обеспечения, если бы захотели, но большинство таковыми не являются.

Во-вторых, ученые не заинтересованы в создании чего-либо, противоположного «ужасному программному обеспечению». Обычно их интересует только результат. Это плохо, если их программное обеспечение содержит ошибки, которые приводят к неверным результатам, но достаточно близким к истине, чтобы казаться правдоподобными. К счастью, многие ошибки приводят к явно неправильным результатам. Также плохо, если программное обеспечение настолько запутанно, что никто не может точно сказать, правильное оно или нет, но, насколько мне известно, жалоб на это не так много.

И в-третьих, ученые часто находятся в цейтноте. Они могут быстро написать программное обеспечение, которое, как они знают , нужно улучшить, и они могут даже знать, как его улучшить, но у них просто нет времени.

Я очень-очень надеюсь, что причина не в том, что некоторые люди думают, что все, что они понимают, должно быть простым, а все, чего они не понимают, должно быть трудным. При этих предположениях любой ученый, пишущий программное обеспечение, которое никто не может понять, будет считаться гением, в то время как любой, кто пишет программное обеспечение, которое легко понять, будет совсем не впечатляющим. Таким образом, то, что делает профессиональный разработчик программного обеспечения, делая программное обеспечение, которое легко понять, может повредить вашей карьере в глазах этих людей. Я очень надеюсь, что это не то, что происходит, но я не удивлюсь.