Хорошо, вот основная проблема, с которой я сталкиваюсь в большей части своей работы (которая связана с экспериментальными/вычислительными исследованиями): я аспирант и провожу большую часть своего дня, выполняя 5, 10, 20 и 30-минутные эксперименты (как биологические, так и вычислительные). ), которые требуют настройки и мониторинга, но приводят к небольшим и средним отрезкам времени, когда я действительно мало что делаю (по сути, просто проверяю каждые 1-2 минуты, чтобы убедиться, что все еще работает). В эти периоды времени я либо а) пытаюсь заняться другой работой, либо б) откладываю на потом. И то, и другое не очень хорошо, поскольку либо а) я постоянно переключаю свое внимание с последнего проекта и в конечном итоге делаю в нем ошибки, либо б) я откладываю на потом (обычно читая статьи, твиттер и т. д.)
Есть ли у кого-нибудь совет, как справиться с этим небольшим, неудобным периодом времени (< 30 минут) - есть ли что-то, что вы считаете полезным делать, что вы также можете постоянно переключать внимание?
Например: http://xkcd.com/303/
Ответ ff524, как обычно, великолепен, но основная проблема для вас может заключаться в том, что большинство этих предложений не являются или, по крайней мере, не являются непосредственно полезными для вашего исследования. Если, как вы говорите, большую часть своего дня вы проводите таким образом, даже «продуктивная прокрастинация» может быть слишком большой прокрастинацией и слишком малым реальным прогрессом.
В таком случае у вас есть два варианта:
На практике вы, вероятно, захотите использовать комбинацию обоих этих вариантов. Попробуйте увеличить время, в течение которого ваши эксперименты продолжаются сами по себе. Параллельно тренируйтесь, максимально используя это время.
Изменить: этот вопрос был добавлен ОП в комментарии. Я думаю, что это интересно, поэтому я добавил это в свой ответ:
что вы можете сделать в случае активной разработки кода? Например, когда я активно разрабатываю фрагмент кода для анализа данных, этот код может выполняться несколько минут (до 10), после чего я оцениваю, работает ли он. Как вы автоматизируете этот процесс?
На самом деле это больше связано со стандартной практикой разработки программного обеспечения, чем с наукой, но тем не менее я думаю, что это полезная концепция. Когда вы пробуете разные реализации с большой вероятностью ошибки, убедитесь, что ваше приложение быстро выходит из строя . То есть сделайте так, чтобы ваше приложение не терпело неудачу десять минут, а выполняло сложные, подверженные ошибкам действия непосредственно в начале. Два простых примера из моего собственного исследования:
Пример 1. Допустим, вы занимаетесь исследованиями в области машинного обучения. Ваше приложение сначала обучает искусственную нейронную сеть (ИНС) на ваших данных (просто, поскольку вы используете внешнюю библиотеку, но занимает ~15 минут из-за алгоритмической сложности), после чего вы выполняете некоторую постобработку (тривиальную, выполняется быстро) и статистическую обработку. анализ результатов (выполняется также быстро, но относительно сложный, подверженный ошибкам код). Если теперь вы всегда запускаете приложение целиком и код дает сбой во время статистического анализа, вы всегда теряете 15 минут на каждый запуск шага, который, как вы уже знаете, работает. Лучшим решением было бы обучить модель один раз и сохранить ее на диск. Затем напишите код, который только загружает ИНС с диска и сразу после этого дает сбой.. Почти нет мертвого времени больше. Когда статистический анализ работает, вы можете вернуться к выполнению всего в ожидаемом порядке.
Пример 2. Вы написали сложный многопоточный тестовый стенд, который работает на нескольких физических серверах. Вы знаете, что у вас где-то есть проблема с синхронизацией, так как ваше приложение недетерминировано умирает каждые пару минут. Вы понятия не имеете, где именно. Следовательно, вы многократно выполняете все приложение, ждете возникновения ошибки, а затем отлаживаете оттуда в разных направлениях. Учитывая, что ошибка возникает только каждые несколько минут, вы тратите большую часть времени на ожидание. Лучший способ — взять страницу из передовой практики разработки программного обеспечения. Убедитесь, что все компоненты протестированы отдельно, прежде чем собирать все вместе. В частности, постарайтесь охватить исключительные случаи. Научитесь писать хорошие фиктивные объекты. Некоторый объем отладки системы интеграции все равно потребуется, но вы не будете тратить часы на отладку компонентов, которые принципиально сломаны.
Учитывая, что вы не можете делать что-то, что требует вашего полного внимания в это время, я бы, по крайней мере, посоветовал последовать совету Мэтта Майта продуктивно откладывать метаработу :
Многие вещи, которые мы уже изучили, постепенно теряются в нашем мозгу. Небольшие отрезки времени, подобные этому, идеально подходят для небольшой консолидации памяти . Я бы предложил провести быструю повторную сессию по вещам, которые вы хотите узнать лучше.
Лучше всего выбирать знания, которые будут наиболее полезными, если их запомнить . Игнорируйте любые знания, которые проще найти в Google (например, 5 крупнейших городов), и сосредоточьтесь на знаниях, которые помогут вам в повседневной жизни (например, сочетания клавиш Chrome).
Как создать сводку ключевой информации для обучения
Как только у вас есть резюме
Удачи!
Отказ от ответственности/самореклама:
Я создатель www.revisy.com — инструмента, который помогает автоматизировать все эти шаги.
Я хотел бы добавить точку зрения экспериментальной науки. Я занимаюсь спектроскопией биологических образцов, и у меня тоже есть подобные эксперименты.
Абстрактный:
По моему опыту, есть люди, которые относительно спокойно справляются с такими ситуациями: они исчезают в лаборатории, проводят свои эксперименты, не впадают в припадки из-за потерянного времени, а возвращаются после того, как эксперименты закончены. Другие люди (например, я) абсолютно ненавидят эту ситуацию, потому что нужно сделать массу других вещей, и они не делаются, пока вы ждете экспериментов в мельчайшие отрезки времени, которые на самом деле не позволяют вам что-либо делать.
Лично я нашел 2 возможных способа справиться с такими ситуациями, и основная идея состоит в том, чтобы заранее решить, где приоритет.
Эксперименты имеют высокий приоритет: в этом случае я считаю, что время и концентрация зарезервированы для экспериментов. Любые другие вещи, которые случаются быть сделанными, являются излишком. Я обнаружил, что большинство пунктов из списка @ff слишком сильно отвлекают мое внимание. Что, в конце концов, приводит к хаосу в экспериментальных данных (например, немного различающиеся имена файлов, которые впоследствии требуют ручной корректировки и т. д.). в порядке. (Хотя многие из моих экспериментов проходят в темноте, поэтому подготовка в той же лаборатории на самом деле невозможна). Помимо этого, я делаю такие вещи, как проверка (электронной) почты, планирование встреч, подготовка списков TODO и выполнение мелких задач. Если время ожидания больше получаса, я могу убрать свой стол/лабораторию, но, например,
Я не люблю читать газеты или заниматься поиском литературы по расписанию будильника. Такую работу я делаю только тогда, когда
Эксперименты имеют более низкий приоритет: у меня часто бывают эксперименты, в которых мне нужно менять образцы после завершения измерений, скажем, через 30 минут, но ничего действительно плохого не произойдет, если я заменю образец через 30 минут или 1 час позже. В этом случае я часто решаю проводить эксперименты с более низким приоритетом, читая или пишу статьи, занимаясь поиском литературы и т. д. Итак, я что-то делаю, и когда после того, как кусок работы сделан, происходит естественный перерыв, я иду и меняйте образцы, прежде чем я начну следующий кусок работы.
Таким образом, я получаю, может быть, только треть или четверть выполненных экспериментов по сравнению с ситуацией эксперимента с «высоким приоритетом», но возможна и другая работа.
В общем, первый сценарий эмоционально утомительнее, чем больше вы не любите перерывы и беспокоитесь обо всей работе, которая не сделана. Это тем более осуществимо, чем лучше вы можете прийти и мысленно в состояние, когда вы концентрируетесь только на эксперименте . Эксперименты — тоже серьезная и изматывающая работа. Одна из причин заключается в том, что вы должны быть гораздо более сконцентрированы, чем за компьютером*: если я сделаю опечатку, будет пробел. Если я напечатаю неловкое предложение, я могу изменить его позже. Если я пипетирую неправильно, мне приходится начинать сначала или даже вынимать все и чистить инструмент. И это тем более утомительно, если речь идет о неудобном графике. И странное небольшое время ожидания, по моему опыту, так же утомительно, как экспериментальный график, за которым вы едва успеваете.
* в большинстве случаев: очевидно, анализ данных должен быть правильно настроен. Но и там, например, грамотное программирование позволяет потом перепроверить, что все сделано правильно. Это невозможно для экспериментов - там я должен быть сконцентрирован, поэтому я потом уверен, что сделал все правильно, хотя у меня очень ограниченные возможности для двойной проверки.
Если вам приходится проводить свои эксперименты таким образом, то лучший способ справиться с этим — также мысленно принять это и сделать это своей задачей. Убедитесь, что эксперименты действительно остаются главным приоритетом, если вы так решили: не читайте SX, если понимаете, что это на самом деле приводит к тому, что эксперимент ждет вас, когда вы решили, что вам следует дождаться эксперимента.
Второй путь, конечно, возможен только в том случае, если это позволяют эксперименты. И если лаборатория достаточно мало используется, чтобы ваши коллеги не убили вас за то, что вы не использовали в полной мере ценное лабораторное время, которое вы зарезервировали.
Что касается автоматизации (биологических) лабораторных экспериментов, я, например, распечатываю «формы экспериментов», которые имеют предопределенную структуру для моих заметок, поэтому не забывайте ни о каких параметрах. Это помогает мне совершать меньше ошибок.
В некоторых случаях я даже пишу специальные измерительные программы, но эти усилия обычно имеют смысл только в том случае, если вы знаете, что последует большая серия экспериментов (по совершенно ненаучным и неудобным причинам: программное обеспечение прибора часто допускает лишь очень ограниченное запрограммированное взаимодействие, и если далее не так много экспериментов, не стоит опускаться до низкоуровневого контроля, который предлагает SDK - если SDK вообще доступен).
Если ты
в) Ненавижу предлагать это... но... есть ли возможность немного вздремнуть или просто спокойно посидеть в своем офисе, не подвергая свой мозг какому-либо дополнительному потоку информации? Кроме того, Twitter, проверка электронной почты, Facebook — все это хорошие примеры мгновенной стимуляции, но это тема для другого разговора.
г) В двух словах, тривиальные вещи, такие как запахи, звуки с улицы, чей-то голос и т. д., являются примерами дополнительной информации, которой вы подвергаете себя, которая ежедневно непреднамеренно бомбардирует наш мозг и еще больше затрудняет фокусировку и вернуться к реальным проектам.
ff524
Дж. Циммерман
Дэнни В.
суперлучший
км.
Франк Дернонкур
Франсиско Пресенсиа
Пасьер
пользователь52813