Forwarded from C# Short Posts 🔞
В прошлых постах мы довольно тщательно разобрали структуру индексов, и нам осталось разобраться, откуда происходит чтение как данных, так и индексов: из диска, или из оперативки, или «зависит»?
📚 Несколько кэшей
Представь, что ищешь нужную книгу: она может быть на твоём рабочем столе — прям под рукой, очень близко; или на полке рядом — на шаг дальше; или вообще в книжном шкафу в другой комнате — туда топать дольше всего. Память под страницы у СУБД устроена такими же уровнями, и за страницей она идёт по ним сверху вниз:
1️⃣ shared_buffers — рабочий стол. Собственный кэш СУБД, она сама им рулит. В Postgres по умолчанию всего 128 MB.
2️⃣ кэш ОС (page cache) — полка рядом. Операционка сама держит в RAM файлы, которые недавно читала; СУБД им не управляет, но пользуется.
3️⃣ диск — шкаф в другой комнате.
Глянула 1️⃣ shared_buffers → нет → 2️⃣ спросила ОС, та смотрит, что есть в RAM → нет → идем на 3️⃣ диск Найденную страницу обычно кладём обратно в shared_buffers, чтобы следующий запрос взял её уже оттуда.
🧩 Данные и индексы — в одном кэше
Тут есть контр-интуитивный момент: и куча с данными (heap — страницы, где лежат сами строки таблицы), и индексы (страницы с элементами дерева) лежат в одном shared_buffers, конкурируя за место. Отдельной «памяти под индексы» нет 🤯
🌳 Почему индекс будто всегда в RAM
Верхушка B-дерева (корень и внутренние узлы) — набор страниц, который дёргает каждый поиск. Из-за частых переходов по дереву верхние уровни почти всегда в кэше, так как с них начинается почти любой поиск, поэтому дочитывать чаще приходится только лист и/или саму страницу кучи.
🔬 Пощупаем (дикпик 1)
EXPLAIN (ANALYZE, BUFFERS): секция BUFFERS показывает, сколько страниц нашли в shared_buffers (hit), а сколько пришлось дочитывать (read).
Холодный поиск по PK на таблице в 1 млн строк, у меня в эксперименте: shared read=4 — три страницы индекса плюс одна кучи, всё мимо кэша.
Повтор: shared hit=4 — всё в shared_buffers диск не трогали, время заметно меньше.
Ищем другой далёкий id: hit=1 read=3 — корень уже в кэше с прошлого раза, поэтому он был переиспользован.
⚠️ Тонкость: read ≠ обязательно диск
«read» здесь значит лишь «не было в shared_buffers». Но страница могла прилететь мгновенно от ОС, а не из диска.
Отсюда неочевидное: два запроса с одинаковым read могут идти с разной скоростью — в одном случае страница пришла с диска, в другом уже лежала в кэше ОС.
🧑💻 Как это использовать в работе
1. Первый запрос после рестарта PostgreSQL (или сервера) обычно медленнее: кэш пустой, он наполняется заново. Это так называемый «холодный старт».
2. Index Only Scan (когда всё нужное есть в самом индексе и в кучу за строкой идти не надо) экономит не только чтения, но и кэш: чем меньше heap-страниц тащим в shared_buffers — тем больше места остаётся другим.
Команды из дикпика — в 👉 гисте 👈
Дальше разберём, куда девается оперативка, когда её внезапно «съели» под 99%, и как это диагностировать 👉
🧑💻dp 🥁
#бд #postgresql #инженерныештучки #heavywednesday
📚 Несколько кэшей
Представь, что ищешь нужную книгу: она может быть на твоём рабочем столе — прям под рукой, очень близко; или на полке рядом — на шаг дальше; или вообще в книжном шкафу в другой комнате — туда топать дольше всего. Память под страницы у СУБД устроена такими же уровнями, и за страницей она идёт по ним сверху вниз:
1️⃣ shared_buffers — рабочий стол. Собственный кэш СУБД, она сама им рулит. В Postgres по умолчанию всего 128 MB.
2️⃣ кэш ОС (page cache) — полка рядом. Операционка сама держит в RAM файлы, которые недавно читала; СУБД им не управляет, но пользуется.
3️⃣ диск — шкаф в другой комнате.
Глянула 1️⃣ shared_buffers → нет → 2️⃣ спросила ОС, та смотрит, что есть в RAM → нет → идем на 3️⃣ диск Найденную страницу обычно кладём обратно в shared_buffers, чтобы следующий запрос взял её уже оттуда.
🧩 Данные и индексы — в одном кэше
Тут есть контр-интуитивный момент: и куча с данными (heap — страницы, где лежат сами строки таблицы), и индексы (страницы с элементами дерева) лежат в одном shared_buffers, конкурируя за место. Отдельной «памяти под индексы» нет 🤯
🌳 Почему индекс будто всегда в RAM
Верхушка B-дерева (корень и внутренние узлы) — набор страниц, который дёргает каждый поиск. Из-за частых переходов по дереву верхние уровни почти всегда в кэше, так как с них начинается почти любой поиск, поэтому дочитывать чаще приходится только лист и/или саму страницу кучи.
🔬 Пощупаем (дикпик 1)
EXPLAIN (ANALYZE, BUFFERS): секция BUFFERS показывает, сколько страниц нашли в shared_buffers (hit), а сколько пришлось дочитывать (read).
Холодный поиск по PK на таблице в 1 млн строк, у меня в эксперименте: shared read=4 — три страницы индекса плюс одна кучи, всё мимо кэша.
Повтор: shared hit=4 — всё в shared_buffers диск не трогали, время заметно меньше.
Ищем другой далёкий id: hit=1 read=3 — корень уже в кэше с прошлого раза, поэтому он был переиспользован.
⚠️ Тонкость: read ≠ обязательно диск
«read» здесь значит лишь «не было в shared_buffers». Но страница могла прилететь мгновенно от ОС, а не из диска.
Отсюда неочевидное: два запроса с одинаковым read могут идти с разной скоростью — в одном случае страница пришла с диска, в другом уже лежала в кэше ОС.
🧑💻 Как это использовать в работе
1. Первый запрос после рестарта PostgreSQL (или сервера) обычно медленнее: кэш пустой, он наполняется заново. Это так называемый «холодный старт».
2. Index Only Scan (когда всё нужное есть в самом индексе и в кучу за строкой идти не надо) экономит не только чтения, но и кэш: чем меньше heap-страниц тащим в shared_buffers — тем больше места остаётся другим.
Команды из дикпика — в 👉 гисте 👈
Дальше разберём, куда девается оперативка, когда её внезапно «съели» под 99%, и как это диагностировать 👉
🧑💻dp 🥁
#бд #postgresql #инженерныештучки #heavywednesday
#занимательныеистории пополнились новой историей✨
Напомню: скажи Алисе💜 "Запусти навык занимательные истории", а дальше там понятно))
Напомню: скажи Алисе
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
"Картинка дня"
Чувствуется, что без дополнительных запросов #ИИшница крутится вокруг какой-то одной темы: в прошлый раз за окном тоже был закат над рекой, букет, чашка, и блокнот, но городок был не такой большой
Чувствуется, что без дополнительных запросов #ИИшница крутится вокруг какой-то одной темы: в прошлый раз за окном тоже был закат над рекой, букет, чашка, и блокнот, но городок был не такой большой
🔥4
Media is too big
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Вспомнить всё 🧠
В айтишке для прохождения собеса на высокий грейд надо уметь, помимо прочего, рассказать про множество технических подробностей. В моём случае была сложность в том, что даже если ты их и знаешь, одно дело - рассуждать о решении задачи, глядя через призму этих знаний, другое - словами через рот выдать что-то внятное, структурированное, и понятное. В общем, тяжело, если регулярно в этом не практикуешься. Ещё сложнее, когда что-то изучал, но так редко применяешь это в работе, что эти знания в твоём shared_buffers замещаются более горячими данными (прямо как при чтении данных из БД)🧠
Как быстро освежить знания?
Мне на помощь в этом случае пришла, конечно же, #ИИшница🧠
Ты можешь сказать: "Она же галлюцинирует! Она тебе нагенерирует какой-нибудь ерунды, а ты опростоволосишься на собесе, пересказав эту чушь!". Я немедленно отвечу: да, такое возможно, и, как со всяким инструментом, с ней тоже надо уметь обращаться 🔧
Говорят, что генеративные модели обучены на всём интернете. В том числе, получается, на информации из Stack overflow и хабре, безграничных кладезях знаний, наполняемых людьми.
А люди склонны ошибаться.
То есть, когда я читаю статью, я рискую нарваться на неточную или неполную информацию. В этом случае я могу подумать "WTF, что-то тут не сходится" и... остаться наедине с этой мыслью. С нейронкой, в случае сомнений, я могу задать уточняющий вопрос. Ассистент либо признает неточность, либо разложит по полочкам ещё подробнее.
Ещё информацию из статьи или видоса можно неправильно интерпретировать. В случае с ИИ, я могу уточнить, и получить ответ.
В общем, нейросеть может предстать этаким интерактивным учебником, или очень терпеливым экспертом, который ответит на все твои уточняющие вопросы. И который ещё быстро погуглит, если что-то не знает, сопоставит информацию, и выдаст ровно то, что тебя интересует.
🧐Конечно, всё ещё стоит относиться к информации от ИИ (как и любой информации в интернете, к этому посту тоже) с разумной долей скепсиса, и выявить неточности поможет в том числе практический опыт. То есть, важно не просто всё зубрить и принимать на веру, а пытаться спроцеровать (смаппить, по-нашему) свежие знания на былой опыт. Так и полученная информация лучше закрепится, и на собесе сможешь привести пару интересных примеров про конкурентный доступ к файлу на блобе
#поиск_работы
В айтишке для прохождения собеса на высокий грейд надо уметь, помимо прочего, рассказать про множество технических подробностей. В моём случае была сложность в том, что даже если ты их и знаешь, одно дело - рассуждать о решении задачи, глядя через призму этих знаний, другое - словами через рот выдать что-то внятное, структурированное, и понятное. В общем, тяжело, если регулярно в этом не практикуешься. Ещё сложнее, когда что-то изучал, но так редко применяешь это в работе, что эти знания в твоём shared_buffers замещаются более горячими данными (прямо как при чтении данных из БД)
Как быстро освежить знания?
Мне на помощь в этом случае пришла, конечно же, #ИИшница
Ты можешь сказать: "Она же галлюцинирует! Она тебе нагенерирует какой-нибудь ерунды, а ты опростоволосишься на собесе, пересказав эту чушь!". Я немедленно отвечу: да, такое возможно, и, как со всяким инструментом, с ней тоже надо уметь обращаться 🔧
Говорят, что генеративные модели обучены на всём интернете. В том числе, получается, на информации из Stack overflow и хабре, безграничных кладезях знаний, наполняемых людьми.
А люди склонны ошибаться.
То есть, когда я читаю статью, я рискую нарваться на неточную или неполную информацию. В этом случае я могу подумать "WTF, что-то тут не сходится" и... остаться наедине с этой мыслью. С нейронкой, в случае сомнений, я могу задать уточняющий вопрос. Ассистент либо признает неточность, либо разложит по полочкам ещё подробнее.
Ещё информацию из статьи или видоса можно неправильно интерпретировать. В случае с ИИ, я могу уточнить, и получить ответ.
В общем, нейросеть может предстать этаким интерактивным учебником, или очень терпеливым экспертом, который ответит на все твои уточняющие вопросы. И который ещё быстро погуглит, если что-то не знает, сопоставит информацию, и выдаст ровно то, что тебя интересует.
🧐Конечно, всё ещё стоит относиться к информации от ИИ (как и любой информации в интернете, к этому посту тоже) с разумной долей скепсиса, и выявить неточности поможет в том числе практический опыт. То есть, важно не просто всё зубрить и принимать на веру, а пытаться спроцеровать (смаппить, по-нашему) свежие знания на былой опыт. Так и полученная информация лучше закрепится, и на собесе сможешь привести пару интересных примеров про конкурентный доступ к файлу на блобе
#поиск_работы
Please open Telegram to view this post
VIEW IN TELEGRAM
Казалось бы, ещё вчера #занимательныеистории тестировали на хакатоне, а сегодня им уже 6 лет 🥲
Если интересно, исходники 👉здесь👈
Если интересно, исходники 👉здесь👈
🔥2
Рассказать всё 📢 (
от автора "вспомнить всё" и "записать всё")
Как говорил ранее, один из факторов успешного собеседования заключается в умении рассказать о своём опыте и знаниях. Именно рассказать. Вслух!
Помимо освежевания знаний, надо практиковаться в устном ответе на вопросы. Прям вслух проговаривать свой ответ под запись🔴
На первых порах можешь очень сильно удивиться, как много в твоей речи лишних звуков. А ещё во время рассуждений "про себя" мозг работает немного по-другому, и в этом режиме может выдать нужную информацию, а вот "вслух" куда-то вдруг всё пропадает🤔
Тут можно подмечать свои ошибки во время рассказа или при прослушивании записи, а еще её можно транскрибировать и передать полученный текст, конечно же, нейронке, чтобы получить от неё фидбек по твоему ответу. У ChatGPT😺 вообще есть режим созвона, в котором прям в реальном времени она может устроить тебе тех-скрининг, но у меня она в этом режиме как будто чаще ошибалась.
Ну а дальше, уже получив желанный оффер, не останавливайся, продолжай практиковаться в пересказе своих знаний и регулярно освежай их: пиши статьи и посты в канальчик, выступай на внутренних митапах и внешних конференциях, ментори кого-нибудь. Поддерживай этот навык тёплым 🔥, он тебе во многом пригодится и после собеседований.
И записывай это всё в достижения, конечно же🧠
#поиск_работы
от автора "вспомнить всё" и "записать всё")
Как говорил ранее, один из факторов успешного собеседования заключается в умении рассказать о своём опыте и знаниях. Именно рассказать. Вслух!
Помимо освежевания знаний, надо практиковаться в устном ответе на вопросы. Прям вслух проговаривать свой ответ под запись
На первых порах можешь очень сильно удивиться, как много в твоей речи лишних звуков. А ещё во время рассуждений "про себя" мозг работает немного по-другому, и в этом режиме может выдать нужную информацию, а вот "вслух" куда-то вдруг всё пропадает
Тут можно подмечать свои ошибки во время рассказа или при прослушивании записи, а еще её можно транскрибировать и передать полученный текст, конечно же, нейронке, чтобы получить от неё фидбек по твоему ответу. У ChatGPT
Ну а дальше, уже получив желанный оффер, не останавливайся, продолжай практиковаться в пересказе своих знаний и регулярно освежай их: пиши статьи и посты в канальчик, выступай на внутренних митапах и внешних конференциях, ментори кого-нибудь. Поддерживай этот навык тёплым 🔥, он тебе во многом пригодится и после собеседований.
И записывай это всё в достижения, конечно же
#поиск_работы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Forwarded from C# Short Posts 🔞
🗄 Оперативное 1: shared_buffers — личный кэш Postgres
В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.
😂 Что это вообще
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.
Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет.(Напомню, что даже на самых мощных SSD разница скорость чтения 10-20 микросекунд, тогда как из оперативки это 50-60 НАНОсекунд, то есть капец как дешево)
📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;
⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце😰 : память заранее отведена под кэш и работает на тебя.
🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).
На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:
🟢 сама таблица заняла 47 MB
🟢 индекс по email — 39 MB
🟢 индекс первичного ключа — 21 MB.
Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.
🅰️ Что унести с собой
🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.
#бд #postgresql #инженерныештучки #heavywednesday
В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.
Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет.
📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;
⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце
🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).
На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:
Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.
🅰️ Что унести с собой
🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.
#бд #postgresql #инженерныештучки #heavywednesday
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Кажется, #ИИшница постепенно убирает естественные барьеры между работой и отдыхом 🚧
Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики🟥 , кайфуешь. Пока ешь — не пишешь код. Чтобы программировать, нужно сесть за компьютер и сосредоточиться.
Теперь можно есть и одновременно смотреть, как Клавдий😒 пишет код. Иногда что-то ему подсказать, написать пару строк самому, дать следующее задание — и снова вернуться к обеду. Вроде бы отдыхаешь, но одновременно работаешь.
Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.
То же самое происходит и с другими паузами в течение дня. Раньше они были настоящими перерывами. Сейчас почти любой из них можно превратить в ещё несколько минут работы.
В результате появляется странный эффект😳
Кодить ты действительно начинаешь больше. Но полноценно отдыхать — меньше. Работа всегда находится на расстоянии одного сообщения. Даже сидя в кресле-коконе, ловишь себя на мысли, что думаешь не о том, как отвлечься и перезагрузиться, а о следующей задаче.
Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.
Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения⚡️
Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики
Теперь можно есть и одновременно смотреть, как Клавдий
Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.
То же самое происходит и с другими паузами в течение дня. Раньше они были настоящими перерывами. Сейчас почти любой из них можно превратить в ещё несколько минут работы.
В результате появляется странный эффект😳
Кодить ты действительно начинаешь больше. Но полноценно отдыхать — меньше. Работа всегда находится на расстоянии одного сообщения. Даже сидя в кресле-коконе, ловишь себя на мысли, что думаешь не о том, как отвлечься и перезагрузиться, а о следующей задаче.
Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.
Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения
Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Please open Telegram to view this post
VIEW IN TELEGRAM
Последние три дня был в Самаре, приехал по делам.
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑💻
Какие методы должны быть у такого интерфейса?
🔹
🔹
🔹 Ну и базовые методы вроде
Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома🏠
Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений✨
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑💻
Какие методы должны быть у такого интерфейса?
🔹
RehearsalBase() — должна быть репетиционная база, чтобы можно было подготовиться к выступлению.🔹
Workspace() — место, где можно спокойно поработать: удобный стол, стабильный интернет (Wi-Fi или хороший мобильный): коворкинг или просто удачный номер в отеле.🔹 Ну и базовые методы вроде
Sleep() и Eat(). Без них тоже никуда.Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома
Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4🫡1
❤2
Декомпозировать всё 🧩
Это уже не столько про #поиск_работы, сколько в целом про полезный навык💪
Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам🖥
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками📈
Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)
Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом👣
Точно так же, кстати, учу новые песни на барабанах🥁
Сначала разбираю основные ритмы, потом прорабатываю сложные места. Дальше размечаю структуру песни, и после этого собираю всё вместе. По сути, песня - это тоже набор небольших блоков: ритмы, сбивки, переходы, повторяющиеся паттерны. Когда каждый кусочек уже освоен, остаётся соединить их и отточить исполнение✨
Ещё декомпозиция зачастую является тем самым первым шагом, который надо сделать, чтобы подступиться к сложной задаче, после которой она уже не кажется такой большой и страшной😱
Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Это уже не столько про #поиск_работы, сколько в целом про полезный навык
Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками
Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)
Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом
Точно так же, кстати, учу новые песни на барабанах🥁
Сначала разбираю основные ритмы, потом прорабатываю сложные места. Дальше размечаю структуру песни, и после этого собираю всё вместе. По сути, песня - это тоже набор небольших блоков: ритмы, сбивки, переходы, повторяющиеся паттерны. Когда каждый кусочек уже освоен, остаётся соединить их и отточить исполнение
Ещё декомпозиция зачастую является тем самым первым шагом, который надо сделать, чтобы подступиться к сложной задаче, после которой она уже не кажется такой большой и страшной
Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1