Как стать автором
Обновить
2
0

Пользователь

Отправить сообщение

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

Как можно видеть даже по одной из картинок в статье, Parul Pandey — женщина. Так что она не «уверен», а «уверена» в том, какой этот Филипп источник вдохновения для всех.

«когда начал работу в качестве доктора философии» — это очень корявый перевод. Имеется в виду, очевидно, начало обучения в аспирантуре. Тут схема в СНГ и в Европе одна и та же: поступил на кафедру, подписал с ней контракт, работаешь там и там же диссер пишешь. Градус пафоса сильно ниже.

«После я должен был стать профессором, это интриговало меня.» — тут я даже не знаю, переводчик ли накосячил, или сам парень в оригинале такой непростой человек. Но вероятность сразу после аспирантуры быть взятым в профессоры — почти ничтожна и доступна только редким гениям. Более обычная схема: человек остается у себя на кафедре/в лабе постдок исследователем [доцнетом], преподает лет сколько-то, руководит чужими дипломными, иногда даже кандидатскими, а потом уже попадает в профессора лет через 10 при большой удаче. Перепрыгавают все эти ступеньки только уникумы вроде Ричарда Фейнмана. Тогда непонятно, почему интервьюерка вообще не впечатлена такими рассказами. Оригинал искать лень, но у меня есть ощущение, что там он как-то попроще выразился, вроде не «должен был стать», а «рассматривал возможность стать» или «хотел стать».
Вот мне, если честно, рожать страшно. Потому что муж всё время за компьютером, я всё время за компьютером, целый день работа-работа-работа, после работы учёба у обоих (институты давно окончены, но за современными технологиями надо как-то успевать, щупать их, верно?), свои проекты, и тут бы хоть выспаться или в кино вдвоем сходить. Безо всяких детей.
А если их заводить, то кто по ночам ребёнка будет вставать и успокаивать — Пушкин или Дед Мороз? Я не знаю.
Короче, если вы каким-то образом всё успеваете, то напишите статью на Хабр. Это действительно суперполезная и интересная информация.
А женщины — существа хитрые. Женщины полуторогодовалыми детьми на руках, как правило, не пилят сук на котором сидят и не ссорятся основным кормильцем в семье. Вы бы тоже не стали на её месте. Т.е. показания получаются постольку-поскольку показательные, приходится разве что честному слову верить.
А вот не соглашусь. На публичном выступлении можно видеть сою аудиторию и корректировать своё выступление в зависимости от этого (например, видим, что слайд скучный и аудитории не идёт — по возможности проскакиваем. Или видим, что аудитории интереснее всего про какой-то один аспект — говорим про него чуть подробнее). А на видео-конференциях, как правило, ни на что, кроме собственной презентации и записок, смотреть не получается. Итого, можно сильно не угодить в настроение аудитории.
У меня был один такой очень печальный опыт, когда я на позитиве, очень бравурным тоном, как привыкла, вещала что-то иностранным коллегам по видео-связи, а потом оказалось, что у них на совещаниях принят более строгий стиль изложения (это был мой первый доклад на подобном мероприятии) и улыбка в моем голосе звучала жутко неуместно. В процессе-то оно было комфортно. А вот потом из этого столько дискофморта вылезло, что по сумме значений личный формат — мой выбор :).
Экспериментальщики чаще доверяют установкам, теоретики — бумаге.

Вы как себе физический эксперимент представляете? Типа, спаял установку, нажал большую красную кнопку, подождал годик, а потом — бац! — открытие? Да если бы… Данные надо анализировать (на данный момент, для этого нужны люди, причём очень много очень умных людей), под анализом я имею в виду историю про восстановление спектров масс, определение углов смешивания и прочие чудесные вещи, для извлечения которых вам нужно писать какой-то код, а не просто с задумчивым лицом рассматривать график. Данных очень много (миллионы собтытий, гигабайты логов), а всякие классные штуки типа QCD — очень сложные и тяжёлые. На бумажке с ручкой их уже профессиональные математики упростили до максимума. И это всё равно часы работы для суперкомпьютера.
А у теоретиков — куча своего специфического ПО. Давно не видела хорошего теоретика, который работал бы вообще голыми руками, не используя ну хотя бы Matlab вместо карманного калькулятора.
Один из лучших умов, что я знаю, пишет макаронный код

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

Есть такая штука — юнит-тесты. Это когда тестируешь маленькие кусочки своего кода, например, функции, на то, правильно ли они работают. Чтобы потом не случалось печальных историй по типу тех, о которых ещё один наш коллега выше рассказывал, когда «считали 2 года на суперкомпьютере, потом нашли ошибку в формуле, и весь результат пошёл коту под хвост». Не путайте с приёмочными тестами, это другое.
Вот это подтверждает мою версию, что у вас очень спецефичная группа. Обычно значительную часть времени занимают обсуждения, анализ, чтение свеженьких статей, и так далее.
«Значительный» != «весь». Это относительная речевая формулировка. А то скажете ещё, что я статей не читаю :)). Или что обсуждение алгоритма вашей программы с группой не является частью её написания (программисты точно обалдеют, а менеджеры побегут срезать им з/п за то время, пока они у доски с маркерами формулы рисуют от лентяйства :) ).
Добрый день, уважаемый коллега! Я произвожу физические расчёты по работе и надеюсь, что мой опыт может быть полезным здесь. [Длинна у этого коммента получилась почти статейная, но в статью это превращать я не вижу смысла.]
Когда я в районе N лет назад, свеженькая и зелёненькая, пришла из Универа в НИИ писать диссер, первая я же вещь, от которой я сильно прибалдела, это то, как хорошо люди, чья профессия (ну, официально-то) не программирование, шарят в языках и технологиях. Тут были и С/С++, и Python, и Matlab, и Julia, и R (но, по-честноку, на крестах писалось и пишется 2/3 всего кода, а остальное, по моим глазомерным прикидкам, составляет всего 1/3), для работы на серверах использовались bash и perl, а до кучи к этому мои коллеги знали и были готовы с интересом обсудить за чашкой кофе кучу прочего, казалось бы, совсем не связанного: SQL и noSQL БД, html/php/JavaScript/CSS, bf и кучу всего ещё. Так же в «джентельменский набор» уважаемого коллегами сотрудника лаборатории входило знание основных паттернов программирования и основ вычислений на GPU (или, программа минимум — запуска своей программы в несколько процессов на нескольких ЦПУ). Крутым качеством считалось умение написать «самодокументированный» поддерживаемый код (хотя писать комменты многие мои коллеги крайне не любят и представление о «самодокументированности» у них бывает несколько завышенным. что уж там, мне тоже мои программы кажутся кристально ясными и без всяких комментов… где-то первые два дня после написания, а потом я радуюсь, что комменты я всё-таки оставила ;)) ).
Причины тому были достаточно просты:
  • расчёты действительно бывают очень «тяжёлыми», для среднестатистического ноута — практически неподъемными, по крайней мере, у те сроки, в которые зачастую надо решить задачу. Поэтому они запускаются на больших вычислительных фермах. И хотя в наше время проблема вычислительного времени, пожалуй, не стоит так остро, как в какие-нибудь 80-е, но таки прождав в очереди на выполнение часов 6, вылететь из неё с segfault'ом (из-за неграмотной работы с памятью) за 10 секунд и потом стоять ещё сколько же, чтобы перезапустить — удовольствие сомнительное. А ещё более сомнительное удовольствие — это узнать, что ты стоял в очереди 6 часов, а не 10 минут, потому что некий твой коллега безответственно закушал себе целое лезвие на 48 потоков (про скопипастил чей-то чужой запускающий скрипт, например), а программу на выполнение поставил однопоточную, ибо строчку #pragma omp parallel for на своём самом верхнем самом тяжёлом цикле ниасилил.
  • не знаю, как у вас в Донецке, а з/п среднеститистического российского учёного заставляет его вертеться, как белка в колесе (а то если будешь умным бедным, поди докажи кому, что ты правда умный :) ). Поскольку значительное количество рабочего времени ты пишешь код, отсюда логическим образом вытекает тот факт, что многие учёные предпочитают научиться программированию всерьёз и подрабатывать этим в свободное от работы время (насколько я заметила, мои зарубежные коллеги тоже так часто делают). Т.е., в некоторой степени по крайней мере треть моих знакомых из научного сообщества — профессиональные программисты (которые основную часть времени занимаются наукой «для души», а основной доход имеют к фриланса. Да, немного странно и весьма печально, но факт).

В вашей статье я заметила определённое количество бед, связанных с организацией рабочего процесса в организации (что-то имеет место и у нас):
  • Отсуствие ТЗ. Воистину, программист в науке иногда — сам себе бизнес-аналитик. Встречаются крутые начальники, которые могут таки объяснить, чего они хотят и как, но, вообще говоря, во основном встречается ситуация, когда твой начальник — это твой заказчик и твоя первейшая задача — это формализовать размытые требования и самому себе это ТЗ составить. Минусы — хочется готовых ответов, а тут приходится самому поднапрячься. Плюсы: нет или почти нет «испорченного телефона» между заказчиком и разработчиком;
  • Код никто не защищает от неправильного ввода и нет никакого UX.
    Одним из первых моих действий после освоения «джентельменского набора» стало прослушивание курса по UX. В ускоренной перемотке, и, имхо, там было многовато воды. Но пару адекватных мыслей я оттуда выхватила и стараюсь применять. Суть в том, что все мы люди, и удобный API, а иногда и UI — это то, что делает твою программу более популярной (если ты пишешь «долгострой» — библиотеку или фреймворк, который будет достаточно часто использоваться другими, как в моём случае) и может заставить людей ссылаться на твои статьи почаще, например. И да, от сложных «нелюдских» интерфейсов, которые в legacy коде приходится видеть во множестве, быстро начинается головная боль, вспоминается куча обсценной лексики, и приходит понимание того, что ты просто не хочешь писать код, который будет заставлять людей страдать;
  • Большая часть кода будет использоваться один, или два раза.
    «Нет ничего более постоянного, чем временное». Вот вы сколько раз запускали каждую программу как минимум для того, чтобы отладить? А когда вы докрутите какой-нибудь новый параметр в вашей системе, вы заново весь код для получения новых картинок преписывать будете? Или «макаронный код» наплодите? Или вы больше никогда не будете решать уравнения численно и возвращаться к этому коду, чтобы «подглядеть» свой собственный опыт?
  • если студент делает некий расчёт <...> код почти никогда не абстрактен, и в нём может повстречаться костыль любого вида и размера.
    А вы-то тут причём? Я встречала очень разных студентов — кто-то на третьем курсе имел опыт стажировки в Google, а кто-то, ниасилив цикл while, запускал подсчёт на 1000 итераций, в надежде, что оно за столько-то шагов точно сойдётся. Задача научрука — учить студента уму-разуму, передавать знания. Задача студента — учиться, и не только решать уравнения, но и жизни. Например, принимать ответственность за собственные косяки и самостоятельно исправлять их.
    Я вообще не очень поняла эту тенденцию наезда на языки. Если я прощёлкала клювом и у меня память течёт, то это я прощёлкала клювом, сейчас пофиксим. Если студент лажает и не знает, где в Интернете StackOverflow — то я ему тактично разъясню. Но с языка-то какой спрос, если он Тьюринг-полный? Моя бабушка, вон, до сих пор с придыханием вспоминает тот момент, когда появился ассемблер и прогать стало, как два пальца от асфальт. А то в машинных кодах, конечно, тоже весело было, но сильно медленнее.
  • Я не решала уравнения Рунге-Кутты где-то с института (где в учебных целях заставляли писать всё from scratch), и не думаю, что могу дать хороший совет в том, как это лучше делать. Но при том, что это стандартная лаба по численным методам где-то за 3-ий курс, я подозреваю, что подключаемых библиотек с простым интерфейсом, которые могут порешать это за вас, должно быть достаточно. Искать можно здесь, в гугле, и сразу на mathoverflow. Успехов!
  • Есть такой грустный момент во многих научных организациях, который роднит их с бизнесом. А именно то, что код редко всерьёз покрывается тестами, а про CI остаётся только мечтать. История и там, и там одинаковая: над работником умственного труда стоит дядя или тётя-управленец и вещает: «Чего ты мне тут юнит-тесты пилишь! Это же просто лишний код, а у нас времени нет! Ты не баги фикси, а фичи выдавай!» И это боль, да.

Итого: работа в науке имеет свои специфические горести и радости, а ещё содержит в себе кучу палок о двух концах. Например, само слово «учёный» подразумевает человека, который много чего изучает, учит. Например, высшую математику, как свой рабочий инструмент (хотя он, может, и не профессиональный математик), или программирование (хотя и не программист) или, например, основы геологии (подставьте сюда любую науку, которая не ваша), если коллеги из соседнего НИИ просят помочь с расчётами. Даже с CMS'ами и кастомным довёрстыванием сайтов иногда, ведь нужны же вашим проектам сайты, а денег нет. Короче, разбираться приходится быстро, чёрт пойми в чём, и чем качественнее, тем лучше. С одной стороны — напряжно, с другой — весело и всё время что-то новое. За последнее, как я подозреваю, мы и любим эту работу и стараемся в ней профессионально расти.
И спасибо создателям языком программирования и библиотек для научных вычислений за то, что облегчают наш труд, а местами в принципе делают его возможным.

P.S. Как сказала мне ещё в студенчестве одна мудрая пожилая доктор наук: «Тебе что, не пофиг на каком языке программировать? Взяла методичку и вперёд!»
Полагаю, что исходная посылка статьи растёт из определённого, достаточно распространённого метода преподавания. И не является, в общем случае, универсальной истиной.
Нам, отличникам, всё это ни к чему. Зачем писать столько ненужных промежуточных действий, когда можно сразу готовый ответ?

Звучит примерно как: «Тестировать свой код — это для троечников. Зачем писать столько ненужного лишнего когда, если программа и так будет работать как-нибудь?» Ну… Чем не точка зрения, конечно.
Я тоже училась на все пятёрки и помню, какой это был понт, когда ты промежуточных вычислений не записываешь. Зачастую это приводило к ошибкам, которые трудно было отследить и исправить (что осложняло работу учителя в разы, как я поняла в дальнейшем, когда сама стала преподавать), но мы велись, и это всё счастье до сих пор живо в наших школах. Но мало ли на что школьники ещё ведутся: что курить — это круто, что если все пойдут с крыши прыгать…
Называть ли это всё «горем от ума»? Я бы, скорее, говорила о попытке самоутвердиться в своей социальной группе. У разных групп — свои критерии «крутизны», одними и теми же методами стать крутым вообще везде сложно (и это очевидно). А оценки — это просто оценки, они учителе-зависимые. Когда ты ещё ребёнок и не понимаешь, что оценивание твоей контрольной работы на 5 или 4 не имеет ничего общего с оценкой тебя, как человека, ты начинаешь за этой оценкой гоняться. А учителя — разные. Кто-то за многостраничную работу сразу ставит 5, не читая (ибо лень), а кто-то гарантированно снижает на балл-другой (потому что читать было лень, но всё равно пришлось).
Если ребёнку на уроках информатики начать снижать оценки за нечитабельный код, то через пару месяцев у «завзятого отличника» код станет самым читабельным в классе. Не думаю, что он от этого как-то резко поглупеет.
Школа она в любом случае и хорошо, что была, и хорошо, что была окончена. Если её выкинуть из головы, хуже не станет.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность