Спасибо, есть ещё один не очевидный вывод, что можно просто начать изучать что-то, даже не важно что вы все не знаете, процесс обучения это ответы на свои вопросы, читать, смотреть и слушать это не обучение, хотя часто кажется что это оно самое
Конкретно здесь это было не специально — я больше фокусировался на цели и общей архитектуре текста. Из частностей, конечно, мне очень сильно понравился хук с архитектурным мышлением, да и вообще кросс-линковка вышла очень неплохая.
Что касается сложности текста, я заметил интересную штуку. Я ведь ещё веду социальные сети, и как-то попробовал сильно упрощать тексты для лучшего понимания — и оказалось, что это мешает восприятию информации.
Иногда запутанный текст заставляет читателя приложить больше усилий, и таким образом ты отсекаешь тех, кто хотел просто просмотреть, зато помогаешь тем, кто действительно хочет разобраться. Ведь разобраться человек может только сам.
Да вообщем никак, последний раз сталкивался только в виде книги: Искусство любить Эрика Форма. Сейчас погуглил определение, и в целом мето-знание и способ его получение как раз примерно оно и есть
Такой вариант рассмотрения тоже имеет место быть — что уж там говорить, если у нас существует более 150 определений термина «архитектура программного обеспечения».
Но согласно тому же архитектурному подходу, мы должны пересматривать наши установки, если они мешают нам достигать цели.
С точки зрения подхода, который рассматривает скорочтение не только как скорость чтения, а как итоговый результат этого процесса — усвоение, где скорость чтения лишь модуль системы скорочтения, — это помогает достигать цели и перестаёт быть постулатом.
Поэтому я не вижу причин, по которым нужно брать неэффективное определение и пользоваться этой концепцией.
Возможно, в этом случае стоит пересмотреть свои взгляды, исходя из вашей цели познания.
Спасибо! К сожалению, это было так давно, когда я только приступил к этой теме, что я и не помню, что именно читал. Сейчас эти знания уже интегрировались и трансформировались.
Но, к счастью, я рассказал базовый подход, и с этой точки зрения вообще не так важно, что именно читать. Нужно поставить себе цель: прочитать две–три самые популярные книги на эту тему, попробовать систематизировать каждую, а затем попытаться объединить их в единую систему.
После этого можно читать вообще всё подряд, даже не по теме. Как вы могли заметить, я приводил примеры из разных областей. У вас включается селективность восприятия: как только появляется зародыш какой-то идеи, вы начинаете видеть её везде. Процесс обучения и познания запущен.
Так, например, сейчас я изучаю тему архитектуры — и вижу её везде. В любой статье, книге, даже в художественной литературе я обучаюсь этому ещё больше.
Но в целом я могу порекомендовать некоторую базовую литературу, не связанную напрямую с обучением:
про человеческие системы: «Радикальная откровенность»,
про системный подход: ТРИЗ и теория ограничений Голдратта (серия книг «Цель»),
про когнитивные ошибки и искажения: Канеман «Думай медленно... решай быстро»,
в вопросах целеполагания — на удивление — советую почитать его друга Талеба, например, «Рискуя собственной шкурой» — очень хорошая книга.
Спасибо! К сожалению, про биологию ничего сказать не могу, но реактивное мышление подсказывает, что, наверное, так оно и есть. Минимум, я замечал на своём опыте корреляцию между голодом и способностью к обучению.
Из забавных моментов: я замечал следующую проблему — иногда задача, которую мы перед собой поставили, намного меньше требует нашей концентрации внимания чем у нас есть, и мы начинаем убегать от темы. Случайно можно найти себя где-нибудь в TikTok или в интернете.
Нам просто сложно сконцентрироваться на чём-то простом — точно так же сложно, как сконцентрироваться на чём-то сложном.
Для себя лично я нашёл следующий лайфхак: если есть некая важная задача, которая требует значительно меньше моего умственного ресурса, то я начинаю добавлять внешние помехи — например, музыку или неудобную позу при выполнении работы — чтобы загрузить свой мозг "шумом", который станет буфером.
Удивительным образом это работает и позволяет входить в состояние потока даже на таких задачах.
Можно, конечно, использовать и более извращённые способы добиться того же.
Например, если программисту требуется тупой поиск по коду — много и долго — можно начать делать это в Vim, компенсируя простоту задачи сложностью способа. Или, например, включить белую тему.
Я не уверен, что здесь есть универсальный ответ, но добавлю ещё одно забавное сходство.
Есть такой не очень популярный подход управления работой — скрам, который разделяет работу удивительным образом похожим способом. Правда, мало кто этому следует.
В нём есть этап планирования, когда мы думаем.
В нём есть этап работы, когда мы делаем.
И в нём есть этап рефлексии, когда мы подводим итоги: что мы хотели получить и что мы получили, а также оцениваем свои методы — почему произошло не так и что можно сделать лучше.
И там есть одна важная идея: человек очень плохо совмещает этапы «думать» и «делать» одновременно.
Как я говорил, подход обучения фрактален.
Ты можешь читать таким образом главу или даже что-то меньше, но лучше не путать эти этапы.
Ты себе обозначаешь цель (кстати, в скраме рассказывается про цель спринта, и все на неё забивают), строишь план — в нашем случае план ожиданий и общую структуру.
Если бы мы писали код, это была бы архитектура, которую мы хотим получить для достижения нашей цели.
После этого ты спокойно идёшь делать своё дело и ни на что не отвлекаешься.
Ретроспективы ещё полезны тем, что это гарантированный фрейм: если её не делать системно, мы начинаем смешивать как достижение цели, так и её способы, начинаем спорить и уходим в пустые блуждания.
Здесь то же самое.
Бесцельное блуждание, кстати, тоже инструмент — его можно применять, но просто не нужно путать его с обучением.
Он бывает полезен, но не как основной инструмент и не в процессе обучения.
Это как R&D: ты себе задаёшь временные рамки и просто копаешь, так как всё равно не знаешь, как достигнуть цели, просто балуешься.
А потом садишься и подводишь итоги этого баловства в виде выводов.
Ограничение по сроку — ключевой момент.
Думаю, при свободном блуждании по тексту, если его выделять из этапа обучения, часто бывает так, что мы просто не знаем, куда дальше копать.
И вот там разрешить себе пару часиков просто рандомно побегать, покопать, а потом подвести итоги — почему бы и нет.
Это большая боль у ребят кто пытается идти в эту сторону, а особенно не застрять на пол пути. Я сам прошел схожий путь, поэтому поделюсь своими мыслями после прочтения. Возможно, это будет полезно тем, кто сейчас думает о том: "а куда дальше?".
В общей картине разработка больше про людей и взаимодействие между ними, что, безусловно, входит в зону ответственности ЕМ.
Забавно, люди и их взаимодействие являются узким местом в разработке, а не технологии.
С этой точки зрения конечно все зависит от продукта, но очень часто EM, может прийти к выводу, что для выполнения своих обязанностей надо сначала команду построить из кучи людей (то бишь быть TL). Отсюда кстати как по мне и путаница.
А вот когда TL сделал свою работу, или у тебя есть команда, которая поддается изменением уже можно и начать задачи EM выполнять.
Предлагаю рассмотреть гипотетический путь от инженера к TL и потом к ЕМ
Если у тебя нет команды, сначала построй её. Это частый путь для разработчика через team lead. Кому-то повезёт: всё готово, и можно сразу переходить в ЕМ.
TL может совмещать работу PM, но для ЕМ это необычно и неправильно.
"Код" — это продукт для разработчиков, а разработчики — его пользователи. Их работа (coder story 🤣) — менять его. Значит, тут должен быть product owner. Эта метасистема — больше, чем архитектура, она про скорость изменений и про то, насколько более сложные задачи команда может решать на базе существующего кода. Вот EM и развивает этот метапродукт
Обосновывай переход выгодой для твоего руководителя и компании.
Это очень важно. Часто люди на этом спотыкаются. Когда разбираешь это с ними, они удивляются: "О, это так просто! Я вообще не так думал, всё усложнял и спорил."
Четвёртый пункт — про поиск вакансии внутри компании и продажу себя.
У C-level всегда проблема найти человека, готового взять на себя хоть маллую часть ответственности. Как только ты начнёшь это делать, система сама будет тебя продвигать. Такие кадры в дефиците, и всегда найдётся, чем их занять. Иногда достаточно просто помочь коллеге из другого отдела настроить Google Sheets, когда в фичу не делали год для него, сэкономив время и проявив неравнодушие.
Тут кстати есть спасение - PlantUML, можно диаграмму хранить тексом, а потом рисовать, мы использовали это, удобно в целом, например когда дока в git + Docsify
да и Сonfluence то же поддерживает и прочие wiki-системы
Спасибо, есть ещё один не очевидный вывод, что можно просто начать изучать что-то, даже не важно что вы все не знаете, процесс обучения это ответы на свои вопросы, читать, смотреть и слушать это не обучение, хотя часто кажется что это оно самое
Спасибо, главное перейти от теории к практике, это самая страшная ловушка в изучении чего-то.
Конкретно здесь это было не специально — я больше фокусировался на цели и общей архитектуре текста. Из частностей, конечно, мне очень сильно понравился хук с архитектурным мышлением, да и вообще кросс-линковка вышла очень неплохая.
Что касается сложности текста, я заметил интересную штуку. Я ведь ещё веду социальные сети, и как-то попробовал сильно упрощать тексты для лучшего понимания — и оказалось, что это мешает восприятию информации.
Иногда запутанный текст заставляет читателя приложить больше усилий, и таким образом ты отсекаешь тех, кто хотел просто просмотреть, зато помогаешь тем, кто действительно хочет разобраться. Ведь разобраться человек может только сам.
А как бы ты переписал этот кусочек?
Да вообщем никак, последний раз сталкивался только в виде книги: Искусство любить Эрика Форма. Сейчас погуглил определение, и в целом мето-знание и способ его получение как раз примерно оно и есть
Кстати как вариант, ты можешь после каждого блока спрашивать себя: а почему это интересно? Это же тоже фокус внимания
Часто интересная составляющая бывает не очевидна, и нужно посидеть и подумать
Спасибо! Ты прямо круто это сформулировал. Меня как-то в Твиттере, один умный человек написал такой тезис, мне он очень понравился
Не стоит путать средства достижения цели и цель
К сожалению данный совет настолько же прост, насколько сложен в реальной жизни
Кстати да, тоже очень хорошая книга, я правда не смог перевести эти знания в навык, хотя рекомендую к прочтение
В целом Дорофеев и вдохновлялся примерно тем же списком литературы что я и озвучил, построив поверх этого свою систему
Когда-нибудь я тоже напишу свою книжку
Такой вариант рассмотрения тоже имеет место быть — что уж там говорить, если у нас существует более 150 определений термина «архитектура программного обеспечения».
Но согласно тому же архитектурному подходу, мы должны пересматривать наши установки, если они мешают нам достигать цели.
С точки зрения подхода, который рассматривает скорочтение не только как скорость чтения, а как итоговый результат этого процесса — усвоение, где скорость чтения лишь модуль системы скорочтения, — это помогает достигать цели и перестаёт быть постулатом.
Поэтому я не вижу причин, по которым нужно брать неэффективное определение и пользоваться этой концепцией.
Возможно, в этом случае стоит пересмотреть свои взгляды, исходя из вашей цели познания.
Спасибо! К сожалению, это было так давно, когда я только приступил к этой теме, что я и не помню, что именно читал. Сейчас эти знания уже интегрировались и трансформировались.
Но, к счастью, я рассказал базовый подход, и с этой точки зрения вообще не так важно, что именно читать.
Нужно поставить себе цель: прочитать две–три самые популярные книги на эту тему,
попробовать систематизировать каждую,
а затем попытаться объединить их в единую систему.
После этого можно читать вообще всё подряд, даже не по теме.
Как вы могли заметить, я приводил примеры из разных областей.
У вас включается селективность восприятия: как только появляется зародыш какой-то идеи, вы начинаете видеть её везде.
Процесс обучения и познания запущен.
Так, например, сейчас я изучаю тему архитектуры — и вижу её везде.
В любой статье, книге, даже в художественной литературе я обучаюсь этому ещё больше.
Но в целом я могу порекомендовать некоторую базовую литературу, не связанную напрямую с обучением:
про человеческие системы: «Радикальная откровенность»,
про системный подход: ТРИЗ и теория ограничений Голдратта (серия книг «Цель»),
про когнитивные ошибки и искажения: Канеман «Думай медленно... решай быстро»,
в вопросах целеполагания — на удивление — советую почитать его друга Талеба, например, «Рискуя собственной шкурой» — очень хорошая книга.
Спасибо! К сожалению, про биологию ничего сказать не могу, но реактивное мышление подсказывает, что, наверное, так оно и есть. Минимум, я замечал на своём опыте корреляцию между голодом и способностью к обучению.
Из забавных моментов: я замечал следующую проблему — иногда задача, которую мы перед собой поставили, намного меньше требует нашей концентрации внимания чем у нас есть, и мы начинаем убегать от темы. Случайно можно найти себя где-нибудь в TikTok или в интернете.
Нам просто сложно сконцентрироваться на чём-то простом — точно так же сложно, как сконцентрироваться на чём-то сложном.
Для себя лично я нашёл следующий лайфхак: если есть некая важная задача, которая требует значительно меньше моего умственного ресурса, то я начинаю добавлять внешние помехи — например, музыку или неудобную позу при выполнении работы — чтобы загрузить свой мозг "шумом", который станет буфером.
Удивительным образом это работает и позволяет входить в состояние потока даже на таких задачах.
Можно, конечно, использовать и более извращённые способы добиться того же.
Например, если программисту требуется тупой поиск по коду — много и долго — можно начать делать это в Vim, компенсируя простоту задачи сложностью способа. Или, например, включить белую тему.
Я не уверен, что здесь есть универсальный ответ, но добавлю ещё одно забавное сходство.
Есть такой не очень популярный подход управления работой — скрам, который разделяет работу удивительным образом похожим способом. Правда, мало кто этому следует.
В нём есть этап планирования, когда мы думаем.
В нём есть этап работы, когда мы делаем.
И в нём есть этап рефлексии, когда мы подводим итоги: что мы хотели получить и что мы получили, а также оцениваем свои методы — почему произошло не так и что можно сделать лучше.
И там есть одна важная идея: человек очень плохо совмещает этапы «думать» и «делать» одновременно.
Как я говорил, подход обучения фрактален.
Ты можешь читать таким образом главу или даже что-то меньше, но лучше не путать эти этапы.
Ты себе обозначаешь цель (кстати, в скраме рассказывается про цель спринта, и все на неё забивают), строишь план — в нашем случае план ожиданий и общую структуру.
Если бы мы писали код, это была бы архитектура, которую мы хотим получить для достижения нашей цели.
После этого ты спокойно идёшь делать своё дело и ни на что не отвлекаешься.
Ретроспективы ещё полезны тем, что это гарантированный фрейм: если её не делать системно, мы начинаем смешивать как достижение цели, так и её способы, начинаем спорить и уходим в пустые блуждания.
Здесь то же самое.
Бесцельное блуждание, кстати, тоже инструмент — его можно применять, но просто не нужно путать его с обучением.
Он бывает полезен, но не как основной инструмент и не в процессе обучения.
Это как R&D: ты себе задаёшь временные рамки и просто копаешь, так как всё равно не знаешь, как достигнуть цели, просто балуешься.
А потом садишься и подводишь итоги этого баловства в виде выводов.
Ограничение по сроку — ключевой момент.
Думаю, при свободном блуждании по тексту, если его выделять из этапа обучения, часто бывает так, что мы просто не знаем, куда дальше копать.
И вот там разрешить себе пару часиков просто рандомно побегать, покопать, а потом подвести итоги — почему бы и нет.
Как-то так я думаю.
Это большая боль у ребят кто пытается идти в эту сторону, а особенно не застрять на пол пути. Я сам прошел схожий путь, поэтому поделюсь своими мыслями после прочтения. Возможно, это будет полезно тем, кто сейчас думает о том: "а куда дальше?".
Забавно, люди и их взаимодействие являются узким местом в разработке, а не технологии.
С этой точки зрения конечно все зависит от продукта, но очень часто EM, может прийти к выводу, что для выполнения своих обязанностей надо сначала команду построить из кучи людей (то бишь быть TL). Отсюда кстати как по мне и путаница.
А вот когда TL сделал свою работу, или у тебя есть команда, которая поддается изменением уже можно и начать задачи EM выполнять.
Если у тебя нет команды, сначала построй её. Это частый путь для разработчика через team lead. Кому-то повезёт: всё готово, и можно сразу переходить в ЕМ.
"Код" — это продукт для разработчиков, а разработчики — его пользователи. Их работа (coder story 🤣) — менять его. Значит, тут должен быть product owner. Эта метасистема — больше, чем архитектура, она про скорость изменений и про то, насколько более сложные задачи команда может решать на базе существующего кода. Вот EM и развивает этот метапродукт
Это очень важно. Часто люди на этом спотыкаются. Когда разбираешь это с ними, они удивляются: "О, это так просто! Я вообще не так думал, всё усложнял и спорил."
У C-level всегда проблема найти человека, готового взять на себя хоть маллую часть ответственности. Как только ты начнёшь это делать, система сама будет тебя продвигать. Такие кадры в дефиците, и всегда найдётся, чем их занять. Иногда достаточно просто помочь коллеге из другого отдела настроить Google Sheets, когда в фичу не делали год для него, сэкономив время и проявив неравнодушие.
Спасибо за статью!
Тут кстати есть спасение - PlantUML, можно диаграмму хранить тексом, а потом рисовать, мы использовали это, удобно в целом, например когда дока в git + Docsify
да и Сonfluence то же поддерживает и прочие wiki-системы