Первоначально опубликовано на dakotalewallen.me
Количество записей в моем журнале
Начал 4 октября и создал 147 записей на сегодняшний день (5/2/22).
Грубая математика на салфетке:
30 недель с той недели
150 будних дней (30 недель * 5, без учета выходных)
147/150 — не так уж плохо 😁.
Честно говоря, я скажу, что есть ненулевое количество дней, которые имеют несколько записей по ряду причин, поэтому воспринимайте высокий «процент завершения» с долей соли.
8 Code Kata завершены за 4 недели примерно в декабре.
Мой самый большой перерыв между записями — ~4 дня на 3-й неделе марта (3/18 (пятница) — 3/24 (четверг)). Но, опять же, если быть честным, март от начала до конца — самый пятнистый.
TL:DR;
Я ценю практику. Как человек, который имеет тенденцию оказываться связанным сразу несколькими делами, она служит почти как функция «сохранения игры» для моего мозга. Позволяет мне работать в начале и конце, сохраняя связность мысли. Он также служит местом для хранения списков дел, чтобы я мог отслеживать, что я сделал по сравнению с тем, что хотел сделать.
Главное в том, чтобы делать что-то часто, — это делать это с минимальным трением. Наличие в моем личном CMS такой системы, чтобы я мог получить к ней доступ с любого устройства в любое время, является огромным фактором, способствующим тому, что я делаю это так часто. Если бы для этого требовалось приложение, которое нужно было бы устанавливать, синхронизировать, поддерживать обновления и/или подписку, я очень сомневаюсь, что стал бы этим заниматься. Определенно, больше накладных расходов на установку и больше затрат. Но я владею источником истины для всех данных, которые я создаю, и я нахожусь только во власти самого себя в плане их структурирования и поддержания.
Истоки
Признаться, я просматриваю новости хакеров один или два раза в день. Что бы вы ни говорили о «практике» первой страницы и людях, которые ее основали, все равно там оказывается много хорошего технического контента, который я с удовольствием читаю и который иначе никогда бы не попал на мой информационный горизонт. Так что когда дело доходит до нишевой информации, иногда я просто сосуществую с людьми, с которыми я не всегда согласен во многом. Я отвлекаюсь. Среди всего этого я видел несколько упоминаний о практике ведения бортового журнала из разных областей. Для меня, не имеющего формального образования, это был своего рода момент «а-ха», когда мне это описали. Я всегда делал записи, но никогда не придерживался формальной практики. В основном они велись в блокнотах, и самой формальной частью моего процесса было написание даты в левом верхнем углу страницы. Поэтому можно с уверенностью сказать, что кроме встреч я никогда не сохранял в них полезную информацию. Короче говоря, цель журнала — вести записи о проведенных экспериментах. В этой статье(?) из Университета Индианы приводится довольно краткое описание того, как начать вести журнал. Подобное содержание определенно направило мою руку в сторону начала моей собственной практики.
Из прочитанного стало ясно несколько вещей:
- генерируемые данные должны быть временными рядами
- данные должны иметь названия
- необходимо иметь возможность встраивать различные типы данных (изображения, файлы и т.д.) в любую конкретную запись
- заметки о встречах и работе, вероятно, должны вестись с некоторым уровнем разделения.
Первые три пункта были получены в результате широкого чтения и распространены между дисциплинами. Последний пункт был получен из статей, посвященных конкретно инженерии и программной инженерии. В основном здесь автор активно делает это, и, учитывая, что лично я придаю большое значение встречам, это кажется необсуждаемым.
Начало работы
Большинство научных реализаций предъявляют жесткое требование вести записи в физическом блокноте. Хотя у меня в шкафу хранится целая куча заполненных блокнотов, всякий раз, когда я делаю заметки для работы с помощью блокнота, мне труднее придерживаться этой привычки. Это еще одна физическая вещь, которую нужно отслеживать, и единственная цель, которой она служит, — это эти заметки. Поэтому умственная нагрузка, которую он создает, по сравнению с тем, которую он снимает, для меня не так благоприятна, как хотелось бы. Я также попросил своего жениха высказаться по этому поводу, поскольку они работают в сфере обслуживания людей, где ведут обширные письменные записи, и он согласился с моими замечаниями, а затем добавил дополнительные недостатки, которые она испытывает в своем рабочем процессе и которые еще больше мешают тому, что я задумал сделать.
Деталь реализации из этой статьи и большинства других подобных ей, которую я сразу же отбросил, — это идея сделать это в виде обычных текстовых файлов, хранящихся в моей ОС. Я достаточно благословен, чтобы иметь несколько физических и виртуальных машин, на которых я работаю, поэтому централизация журналов на одной из них — это не вариант. Очевидно, есть вещи, которые я могу сделать для решения этой проблемы, но они более технически сложные. Например, настроить мою главную машину как FTP-сервер и автоматизировать копирование файлов туда и обратно с других машин. Это хорошо, но я использую двойную загрузку на своей основной машине и иногда должен принимать совещания с моей нерабочей ОС (windows). Поэтому FTP’ing с одной ОС на другую в этом случае не так прост (и, вероятно, невозможен без серьезного взлома). Решить эту проблему можно с помощью таких приложений, как Dropbox или Google Drive, но при длительной работе с ними я, скорее всего, столкнусь с ограничениями этих сервисов и потеряю контроль над своими данными. Отмена подписки, перебои в работе, закрытие аккаунтов и т. д. — все это приводит к тому, что я не могу получить доступ к своим данным. Короче говоря, локальные файлы не подходят. К счастью для меня, именно такие проблемы я люблю решать.
Будучи начинающим прагматиком, я начал искать системы, с которыми я уже регулярно взаимодействовал и которые случайно попали в мою CMS. Я запускаю strapi на экземпляре EC2 с сентября 2020 года и до начала этого проекта использовал его исключительно для поддержки контента на этом сайте. В основном это мои блоги, список для чтения и список «полезностей». Возившись с конструктором контента, я довольно быстро набросал модель данных, которая показалась мне подходящей.
- Организация: Перечисление того, на кого я работаю. (я сам и моя нынешняя компания).
- Проект: Название проекта, над которым я работал.
- Встречи: Место для подробного описания моих встреч за день
- Задачи: Место для подробного описания работы, которую я выполнял Затем я использовал поле Created At для отслеживания временных рядов и приступил к работе. Этот способ позволил решить множество проблем и обеспечил некоторые уникальные преимущества.
Плюсы:
- Я владею своими данными, и единственные люди, которые могут это изменить, — это я сам, AWS (мой облачный хост) и плохие игроки.
- Мои данные доступны до тех пор, пока у меня есть подключение к Интернету и работает моя облачная инфраструктура.
- Моя CMS предоставляет текстовый редактор, позволяющий мне писать в формате Markdown и встраивать другие типы данных (видео, изображения, аудио) по своему усмотрению.
- Я владею моделью данных, что позволяет мне добавлять, связывать или удалять данные по своему усмотрению.
- По сравнению с другими реализациями, мне не нужно поддерживать никакую автоматизацию, кроме резервного копирования. Я просто пишу в свою CMS, как и раньше.
- Никаких новых физических вещей, которые нужно помнить. Я и так каждый день пользуюсь компьютером, так что барьер для доступа — это всего лишь пара щелчков и нажатий клавиш.
Минусы:
- Я не являюсь владельцем компьютера, на котором хранятся мои данные. Говоря прямо, компьютеры, на которых хранятся данные, принадлежат Amazon. Хотя у них «нет доступа» к машинам, которые я использую, если только я сам этого не разрешу, они все равно являются поставщиком услуг, стоящим между мной и моими данными.
- Я должен платить за инфраструктуру, которую я использую. Можно утверждать, что я буду делать это независимо от реализации в той или иной форме, но здесь есть жесткий счет, который приходит в конце месяца и который должен быть оплачен так или иначе, иначе поставщик услуг имеет право лишить меня доступа к моим данным.
- Обслуживание инфраструктуры.
- Вероятно, это самый влиятельный из всех перечисленных пунктов.
- В этом случае часть расходов сводится к тому, что инфраструктура используется для нескольких проектов, поэтому технически их можно считать амортизированными, но я единственный человек, обслуживающий их все, поэтому это не имеет значения. Если есть неправильная конфигурация или обновления, которые должны быть сделаны, я должен это сделать. Конечно, я использую принцип KISS настолько широко, насколько это возможно, и эта инфраструктура не является исключением. Так что эта дополнительная нагрузка для меня сводится к часу или двум раз в пару месяцев. Но в этом вопросе все зависит от ситуации.
- Если бы мне нужно было назвать один пункт, почему большинство людей не используют этот подход, я бы сказал следующее. Если только вы не работаете в сфере ИТ и/или не хотите заниматься этим в качестве «хобби», такой подход просто не сработает. Это сродни тому, как если бы вы были автолюбителем и не имели доступа к гаражу. Вы, конечно, можете это сделать, но стоимость будет экспоненциально выше, и у вас будет заметно меньше свободы в плане деталей реализации.
На практике
С учетом всего вышесказанного, такой подход творит со мной чудеса. Моя работа стала заметно более слаженной. Но самое главное, я бы сказал, что моя коммуникация стала более последовательной. Что касается общения по работе, я знаю, чего я достиг за последнее время, и знаю, что мне еще предстоит сделать, чтобы достичь поставленных целей. Я могу передать информацию о своих встречах не только людям, не присутствующим на встрече, но и своему будущему «я». Когда я начал заниматься этим, я ожидал, что мой мозг станет более организованным, но, пожалуй, самым большим преимуществом стало общение с другими людьми. Я гораздо меньше смотрю в бездну, пытаясь вспомнить то, над чем я работал, или разговоры, которые у меня были. В конце концов, это обычно приводит к лучшему результату для всех, а не только для меня.
Модель данных
С самого начала четыре основных пункта «Организация, проект, встречи и задачи» оставались неизменными. Скажу лишь, что был небольшой период, когда я пытался привить себе привычку регулярно проводить «ката» кода. Ката — это небольшое упражнение по кодированию для отработки конкретных проблем в кодировании. На самом деле это означает, что я пытался регулярно выполнять задачи LeetCode в течение нескольких недель, но в итоге я нашел их утомительными и не приносящими особой пользы. Возможно, несколько недель — это не так уж и много с точки зрения объема данных, и я остановился, основываясь исключительно на субъективном мнении. В ЛЮБОМ СЛУЧАЕ. Данные внутри точек также оставались достаточно последовательными. Изо дня в день я обычно создаю копию записей предыдущего дня, чтобы начать работу. Обычно мне не приходится менять проект, и я никогда не меняю Организацию. Если я работаю над чем-то для другой «организации», я копирую все, что было сделано в последний раз для этой организации. Оттуда я обновляю раздел «Встречи». Если у меня нет запланированных встреч, я напишу «нет». Затем, если встречи появляются в течение дня, я удаляю «нет» и добавляю обычную запись о встрече. Типичная запись о встрече выглядит следующим образом
title @ time
## pre
- notes about things I want ready going into the meeting
## during
- notes taken during the meeting
## post
- notes taken while following up on the meeting
Импровизированные встречи не имеют записей «до», поскольку они импровизированные. «Во время» обычно служит в качестве блокнота для ключевых моментов и вещей, которые мне нужно проследить. «После» служит блокнотом для записей, которые я делаю после встречи и которые было бы полезно знать в следующий раз, когда мне понадобится обновить статус задач или на последующих встречах.
Задачи организуются по-разному. Я обычно делю их на разделы, организованные по проектам. Поэтому запись в этом разделе имеет гораздо менее жесткую структуру.
# Project
- note
- note
- note
- links to documentation
- links to useful videos
Task:
- item ✅ (done)
- item ❌ (decided not to do or blocked)
- item 🔜 (in progress)
# Project 2
...
Привычка
Свой первый журнал я написал 24 октября 2021 года. Как показывают цифры вверху, мне примерно удавалось делать записи в журнале каждый день с момента начала работы. Определенно, в этом большом числе есть и грязные данные. Но я бы не сказал, что оно ниже 80%. Благодаря тому, что журнал ведется в браузере, барьер для входа в него крайне низок. Мне приходится держать браузер открытым, чтобы выполнять свою работу, поэтому единственная причина не вести журнал — это либо забывчивость, либо лень. Другая часть, которая, я бы сказал, укрепила привычку — это частота, с которой я обращаюсь к журналам. Записывая куда-то информацию, которую мне нужно передать другим людям, я привык заглядывать туда, когда знаю, что что-то об этом написал. По сути, создается положительная обратная связь между тем, что я записываю точную информацию в свой журнал, что позволяет мне передавать хорошую информацию от людей без необходимости фиксировать ее в долговременной памяти. Таким образом, это заменяет умственную нагрузку, связанную с запоминанием всего, что, по моему мнению, может быть важно для кого-то другого (это может быть реальный человек или мое будущее «я»), действием записи этого в моем журнале. Затем, если я вдруг почувствую неясность в деталях или ощущение, что я забыл целый пункт. Я прыгаю в свой журнал. Это все еще человеческий процесс, и я кое-что упускаю, но чаще всего там есть что-то полезное.
В заключение
Если вы не ведете записи. Начните. Если вы ведете записи и у вас есть некоторые из тех оговорок, которые были у меня, попробуйте мой процесс и работайте над ним до тех пор, пока он не будет работать на вас. По моему опыту, самая сложная часть достижения чего-либо — это общение, а ведение личных записей поможет улучшить качество вашего общения.
Найдите меня в Twitter | LinkedIn
Поддержите меня на Github