В чем особенность формата, и почему мы ему уже рады?
• Каждая встреча клуба будет ознаменована дискуссионной темой из профессиональной жизни разработчика, на которую есть неоднозначные точки зрения в статьях и литературе.
Мы заранее подберем наиболее ключевые и интересные работы по теме для ознакомления.
Они не будут слишком большими, чтобы все участники успели подготовиться!
• Встречи будут в формате живой модерируемой дискуссии, которая поможет систематизировать знания, посмотреть на знакомые вещи под новым углом и обменяться реальным опытом.
• Все это делает формат прекрасным как для тех, кто еще ничего знает о теме, так и для погруженных:
☕️Тема первой встречи:
25 мая (воскресенье)
12:00–15:00 (по Мск, GMT +3)
онлайн
https://forms.gle/af4KWj4fQRno6v2L9
Все участники будут добавлены в Telegram-чат, где получат статьи для подготовки и вопросы для саморефлексии.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥5😱3👍1
Уже в это воскресенье в 12:00 по Мск мы проведем первую встречу читального клуба, в котором есть еще пара мест для желающих 📚
Подробнее про формат и тему описали в посте выше ⬆️
А записаться можно здесь:
https://forms.gle/af4KWj4fQRno6v2L9
До встречи!
Подробнее про формат и тему описали в посте выше ⬆️
А записаться можно здесь:
https://forms.gle/af4KWj4fQRno6v2L9
До встречи!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥3🤩3
Пол (и все-все-все) — это исполнилось 30 лет лучшему языку программирования 📱
Please open Telegram to view this post
VIEW IN TELEGRAM
🎙️ Ищем людей для короткого исследования!
Друзья, всем привет! Мы готовим исследование о том, как опытные программисты обучаются новым навыкам и хотим услышать ваши истории.
Интересны все, кто:
1. За последний год проходил платные курсы по программированию или смежным темам (не важно, онлайн/оффлайн, длинные/короткие).
2. Или использовал AI (ChatGPT, Copilot и др.) для учёбы, практики или экспериментов.
Если был опыт обеих активностей, то ещё лучше 🙌
🗣️ Исследование пройдёт в формате беседы/интервью и займёт примерно 40-45 минут.
Если вы были бы рады поучаствовать, напишите, пожалуйста в личку или оставьте сообщение в комментариях. Спасибо!
Друзья, всем привет! Мы готовим исследование о том, как опытные программисты обучаются новым навыкам и хотим услышать ваши истории.
Интересны все, кто:
1. За последний год проходил платные курсы по программированию или смежным темам (не важно, онлайн/оффлайн, длинные/короткие).
2. Или использовал AI (ChatGPT, Copilot и др.) для учёбы, практики или экспериментов.
Если был опыт обеих активностей, то ещё лучше 🙌
🗣️ Исследование пройдёт в формате беседы/интервью и займёт примерно 40-45 минут.
Если вы были бы рады поучаствовать, напишите, пожалуйста в личку или оставьте сообщение в комментариях. Спасибо!
❤5👍3
HDD без магии — как «железо» диктует индексы
👋 Привет Пол (и привет всем)
Сейчас в ридинг-группе по 'кабанчику' мы готовимся к обсуждению третьей главы, посвящённой хранению и извлечению данных.
Чтобы глубже понять причины оптимизаций, сделанных в базах данных для операций чтения и записи, я решил чуть приоткрыть «black box» под названием Hard Disk Drive (HDD). А именно -- верхнеуровнево посмотреть, как же устройство жёсткого диска повлияло на оптимизации в алгоритмах баз данных в целом и индексов в частности.
Конечно, знание устройства «железа» не является обязательным для качественной работы разработчика, но позволяет лучше усвоить причинно-следственные связи и не воспринимать оптимизации как абстрактную данность.
🎥 По теме попалось отличное видео How HDDs Work?, где наглядно объясняется устройство жёсткого диска, как данные хранятся, записываются и читаются, а также откуда берутся те самые 4 KB, которые считаются best practice для хранения фрагментов данных.
Если у вас есть общее любопытство к теме, это видео отлично закроет пару «как это устроено» вопросов.
Буду рад вашим наводкам на другие полезные материалы в комментариях😐
👋 Привет Пол (и привет всем)
Сейчас в ридинг-группе по 'кабанчику' мы готовимся к обсуждению третьей главы, посвящённой хранению и извлечению данных.
Чтобы глубже понять причины оптимизаций, сделанных в базах данных для операций чтения и записи, я решил чуть приоткрыть «black box» под названием Hard Disk Drive (HDD). А именно -- верхнеуровнево посмотреть, как же устройство жёсткого диска повлияло на оптимизации в алгоритмах баз данных в целом и индексов в частности.
Конечно, знание устройства «железа» не является обязательным для качественной работы разработчика, но позволяет лучше усвоить причинно-следственные связи и не воспринимать оптимизации как абстрактную данность.
🎥 По теме попалось отличное видео How HDDs Work?, где наглядно объясняется устройство жёсткого диска, как данные хранятся, записываются и читаются, а также откуда берутся те самые 4 KB, которые считаются best practice для хранения фрагментов данных.
Если у вас есть общее любопытство к теме, это видео отлично закроет пару «как это устроено» вопросов.
Буду рад вашим наводкам на другие полезные материалы в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥3✍2🤔1
Java 25 — новая LTS 🎉
👋 Привет, Пол (и привет всем)
На прошлой неделе вышла Java 25 — свежая LTS-версия.
Ждал я, конечно, Вальхалу… но давайте кратко пробежимся по тому, что завезли.
✍️ Букавы писать не любим
• JEP 512: Compact Source Files and Instance Main Methods — о многословности Java слагаются легенды, именно поэтому об этом JEP’е мне написало особенно много друзей, которые с Java никогда не работали :)
На первый взгляд JEP выглядит как пустяк для текущих джавистов, но для привлечения новых пользователей может являться конкурентным преимуществом.
• JEP 511: Module Import Declarations — забавный JEP, полезен скорее для прохождения собеседований. В реальной жизни вряд ли пригодится — текущие чекстайлы всё равно запрещают
🔧 Полезные улучшения
• JEP 513: Flexible Constructor Bodies — наконец можно валидировать параметры до вызова родительского конструктора.
• JEP 519: Compact Object Headers — экономия памяти.
• JEP 514 и 515: AOT Ergonomics + Method Profiling — оптимизация работы приложений прямо из коробки.
📝 Итог
Фич, которые можно «потрогать руками», не так уж много. Но меня радует, что Java продолжает развиваться.
Мне близок подход, что Java не тащит фичи из других языков «во что бы то ни стало», а тщательно отбирает опыт и адаптирует под свою культуру. А если не получается — спокойно отказывается (как это было с pattern matching).
💬 В этом разделе по канону я должен байтить вас на комменты. Но все же хочется не ради статистики услышать реальное мнение: как вы видите эти изменения со своим бэкграундом?
👋 Привет, Пол (и привет всем)
На прошлой неделе вышла Java 25 — свежая LTS-версия.
Ждал я, конечно, Вальхалу… но давайте кратко пробежимся по тому, что завезли.
✍️ Букавы писать не любим
• JEP 512: Compact Source Files and Instance Main Methods — о многословности Java слагаются легенды, именно поэтому об этом JEP’е мне написало особенно много друзей, которые с Java никогда не работали :)
На первый взгляд JEP выглядит как пустяк для текущих джавистов, но для привлечения новых пользователей может являться конкурентным преимуществом.
• JEP 511: Module Import Declarations — забавный JEP, полезен скорее для прохождения собеседований. В реальной жизни вряд ли пригодится — текущие чекстайлы всё равно запрещают
import *.🔧 Полезные улучшения
• JEP 513: Flexible Constructor Bodies — наконец можно валидировать параметры до вызова родительского конструктора.
• JEP 519: Compact Object Headers — экономия памяти.
• JEP 514 и 515: AOT Ergonomics + Method Profiling — оптимизация работы приложений прямо из коробки.
📝 Итог
Фич, которые можно «потрогать руками», не так уж много. Но меня радует, что Java продолжает развиваться.
Мне близок подход, что Java не тащит фичи из других языков «во что бы то ни стало», а тщательно отбирает опыт и адаптирует под свою культуру. А если не получается — спокойно отказывается (как это было с pattern matching).
💬 В этом разделе по канону я должен байтить вас на комменты. Но все же хочется не ради статистики услышать реальное мнение: как вы видите эти изменения со своим бэкграундом?
👍5❤3🔥2
Пол — это Java
🎙️ Ищем людей для короткого исследования! Друзья, всем привет! Мы готовим исследование о том, как опытные программисты обучаются новым навыкам и хотим услышать ваши истории. Интересны все, кто: 1. За последний год проходил платные курсы по программированию…
Огромное спасибо всем, кто уже принял участие в нашем исследовании!
Мы продолжаем, и все ещё любопытствуем, как опытные программисты обучаются новым навыкам ✍️
Напишите нам, пожалуйста, в личку или оставьте комментарий, если вы:
🔹 За последний год проходили любые платные курсы по программированию или смежным темам;
🔹 И/или использовали AI для учёбы, практики или экспериментов.
Будем очень рады с вами познакомиться и пообщаться☕
Мы продолжаем, и все ещё любопытствуем, как опытные программисты обучаются новым навыкам ✍️
Напишите нам, пожалуйста, в личку или оставьте комментарий, если вы:
🔹 За последний год проходили любые платные курсы по программированию или смежным темам;
🔹 И/или использовали AI для учёбы, практики или экспериментов.
Будем очень рады с вами познакомиться и пообщаться
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Что значит быть Staff+ инженером
👋 Привет, Пол (и всем тоже привет)
Чуть больше года назад я сменил работу и перешёл в то, что сам для себя называю «полуруководящей» позицией. Формально уже не сеньор, но ещё и не техлид. И довольно быстро я столкнулся с проблемой, которую, как оказалось, сложно даже корректно сформулировать.
С инженерными навыками всё относительно понятно: есть стек, есть зоны роста, есть способы измерять прогресс. А вот всё, что касается лидерских и менеджерских компетенций, долгое время оставалось для меня размытым. У меня не было языка, чтобы описать, что именно я должен уметь делать и какого результата от себя ожидать.
Если эта проблема знакома и вам, дальше будет чуть полезнее.
😛 Язык, которого не хватало
Цепочка разговоров с разными людьми привела меня к книге Staff Engineer Уилла Ларсона.
Уилл предлагает использовать термин Staff+ engineer как обобщение для всех ролей после сеньора, и для упрощения выделяет четыре архетипа:
1. Tech Lead
2. Architect
3. Solver
4. Right Hand
Все они находятся на одном «уровне» seniority, но отличаются типом воздействия на систему.
🎭 В чём различие ролей
Tech Lead и Architect обычно работают с одними и теми же людьми в долгую. Это роли про устойчивость, контекст и эволюцию решений со временем.
Solver и Right Hand — более ситуативные фигуры. Их часто «бросают» туда, где есть проблема.
• Solver — про сложную техническую задачу.
Ты остаёшься в команде (или собираешь её с нуля), пока проблема не решена и не передана на дальнейшую поддержку.
• Right Hand — это уже про совокупность проблем: технических, организационных, коммуникационных.
Здесь меньше кода и больше координации: договориться со стейкхолдерами, выровнять направление команд, потушить пожар и делегировать реализацию дальше (часто, например, коллегам солверам).
• Architect во многом похож на Right Hand, но работает не в режиме пожара, а в долгосрочной перспективе.
• Tech Lead же роль, где ты обычно работаешь с командой до ~8 инженеров, плотно взаимодействуешь с продуктом, формируешь бэклог и отвечаешь за то, как именно команда движется к цели.
👀 Зачем всё это
Все четыре архетипа пересекаются. У каждого есть общие задачи и уникальные зоны ответственности. Какие-то типы работы будут нравиться больше, какие-то меньше. И именно это различие, на мой взгляд, и даёт главное: возможность собрать собственное представление о том, какой Staff-роль подходит именно вам.
Например, роль Solver звучит как постоянное решение сверхсложных задач, что привлекательно. Но у Tech Lead есть возможность наблюдать, как решения живут и развиваются со временем, когда у Solver’а этого почти нет.
Роли Right Hand и Architect требуют развитого навыка влияния: умения получать ресурсы и двигать людей в одном направлении, и это тоже по-своему интересно.
Если вы сейчас где-то между «уже не сеньор» и «ещё не понимаю, кто я», возможно, книга окажется полезной и вам. Буду рад услышать, как вы сами для себя отвечаете на этот вопрос.
Чуть больше года назад я сменил работу и перешёл в то, что сам для себя называю «полуруководящей» позицией. Формально уже не сеньор, но ещё и не техлид. И довольно быстро я столкнулся с проблемой, которую, как оказалось, сложно даже корректно сформулировать.
С инженерными навыками всё относительно понятно: есть стек, есть зоны роста, есть способы измерять прогресс. А вот всё, что касается лидерских и менеджерских компетенций, долгое время оставалось для меня размытым. У меня не было языка, чтобы описать, что именно я должен уметь делать и какого результата от себя ожидать.
Если эта проблема знакома и вам, дальше будет чуть полезнее.
Цепочка разговоров с разными людьми привела меня к книге Staff Engineer Уилла Ларсона.
Уилл предлагает использовать термин Staff+ engineer как обобщение для всех ролей после сеньора, и для упрощения выделяет четыре архетипа:
1. Tech Lead
2. Architect
3. Solver
4. Right Hand
Все они находятся на одном «уровне» seniority, но отличаются типом воздействия на систему.
Tech Lead и Architect обычно работают с одними и теми же людьми в долгую. Это роли про устойчивость, контекст и эволюцию решений со временем.
Solver и Right Hand — более ситуативные фигуры. Их часто «бросают» туда, где есть проблема.
• Solver — про сложную техническую задачу.
Ты остаёшься в команде (или собираешь её с нуля), пока проблема не решена и не передана на дальнейшую поддержку.
• Right Hand — это уже про совокупность проблем: технических, организационных, коммуникационных.
Здесь меньше кода и больше координации: договориться со стейкхолдерами, выровнять направление команд, потушить пожар и делегировать реализацию дальше (часто, например, коллегам солверам).
• Architect во многом похож на Right Hand, но работает не в режиме пожара, а в долгосрочной перспективе.
• Tech Lead же роль, где ты обычно работаешь с командой до ~8 инженеров, плотно взаимодействуешь с продуктом, формируешь бэклог и отвечаешь за то, как именно команда движется к цели.
Все четыре архетипа пересекаются. У каждого есть общие задачи и уникальные зоны ответственности. Какие-то типы работы будут нравиться больше, какие-то меньше. И именно это различие, на мой взгляд, и даёт главное: возможность собрать собственное представление о том, какой Staff-роль подходит именно вам.
Например, роль Solver звучит как постоянное решение сверхсложных задач, что привлекательно. Но у Tech Lead есть возможность наблюдать, как решения живут и развиваются со временем, когда у Solver’а этого почти нет.
Роли Right Hand и Architect требуют развитого навыка влияния: умения получать ресурсы и двигать людей в одном направлении, и это тоже по-своему интересно.
Если вы сейчас где-то между «уже не сеньор» и «ещё не понимаю, кто я», возможно, книга окажется полезной и вам. Буду рад услышать, как вы сами для себя отвечаете на этот вопрос.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2✍1👎1
Какая Staff+ роль вам сейчас ближе (по интересу, не по текущей позиции)?
Anonymous Poll
25%
15%
15%
13%
25%
8%
👋 Привет, Пол. И привет всем.
Недавно на конференции я разговорился с разработчиком, которого явно раздражало, что на работе его заставляют использовать AI:
И вообще
Этот разговор натолкнул на мысль, что у меня самого отношение к AI неожиданно смешанное. Я оставлю за рамками поста вопросы вроде насколько AI эффективен, какая модель лучше и где он реально приносит пользу — меня зацепило другое. В какой-то момент я стал замечать, что при решении некоторых задач периодически появляется странное чувство, что-то между грустью и разочарованием.
После пары сеансов саморефлексии стало понятно, что меня расстраивает вообще даже не сам факт использования AI — скорее, наоборот, мне нравится, что AI может помочь быстрее найти варианты, заметить риски и в итоге принять более качественное решение. Проблема в другом: иногда вместе с этим приходит другое ощущение, будто работу сделал не я, а агент, ну а я просто стоял рядом. И вот это осознание стало для меня важнее всех споров про “заменит / не заменит”, потому что, кажется, нам важно не только получить результат, но и чувствовать, что это именно наш результат.
И тут же всплыло ещё одно наблюдение, напрямую связанное с этим ощущением — фраза "я погуглил / я поисследовал" воспринимается мной гораздо приятнее, чем "я спросил у GPT" или "GPT мне сказал". Хотя по сути во многих случаях это просто про разные интерфейсы для работы с информацией, поэтому все еще похоже, что многое упирается в то, как именно мы воспринимаем своё участие в процессе.
Если напоминать себе, что AI — это всё-таки инструмент, а не самостоятельный автор, безусловно, становится проще принять происходящее. Да, очень мощный инструмент и иногда почти пугающе полезный, но без нашего запроса, без нашего контекста, без нашего выбора и без нашей оценки ответа результат всё ещё не “возникает сам", просто форма нашего участия меняется.
P.S. Забавно, что очень похожую фрустрацию я когда-то испытывал, когда начал руководить группой инженеров. Тогда тоже появлялась мысль: "Я ничего не сделал — всё сделали без меня". Похоже, в обоих случаях неприятно не отсутствие действий, а потеря привычного ощущения прямого вклада.
Недавно на конференции я разговорился с разработчиком, которого явно раздражало, что на работе его заставляют использовать AI:
"Я не для этого учился computer science, чтобы AI писал код за меня".
И вообще
"Мне нравится писать код самому".
Этот разговор натолкнул на мысль, что у меня самого отношение к AI неожиданно смешанное. Я оставлю за рамками поста вопросы вроде насколько AI эффективен, какая модель лучше и где он реально приносит пользу — меня зацепило другое. В какой-то момент я стал замечать, что при решении некоторых задач периодически появляется странное чувство, что-то между грустью и разочарованием.
После пары сеансов саморефлексии стало понятно, что меня расстраивает вообще даже не сам факт использования AI — скорее, наоборот, мне нравится, что AI может помочь быстрее найти варианты, заметить риски и в итоге принять более качественное решение. Проблема в другом: иногда вместе с этим приходит другое ощущение, будто работу сделал не я, а агент, ну а я просто стоял рядом. И вот это осознание стало для меня важнее всех споров про “заменит / не заменит”, потому что, кажется, нам важно не только получить результат, но и чувствовать, что это именно наш результат.
И тут же всплыло ещё одно наблюдение, напрямую связанное с этим ощущением — фраза "я погуглил / я поисследовал" воспринимается мной гораздо приятнее, чем "я спросил у GPT" или "GPT мне сказал". Хотя по сути во многих случаях это просто про разные интерфейсы для работы с информацией, поэтому все еще похоже, что многое упирается в то, как именно мы воспринимаем своё участие в процессе.
Если напоминать себе, что AI — это всё-таки инструмент, а не самостоятельный автор, безусловно, становится проще принять происходящее. Да, очень мощный инструмент и иногда почти пугающе полезный, но без нашего запроса, без нашего контекста, без нашего выбора и без нашей оценки ответа результат всё ещё не “возникает сам", просто форма нашего участия меняется.
P.S. Забавно, что очень похожую фрустрацию я когда-то испытывал, когда начал руководить группой инженеров. Тогда тоже появлялась мысль: "Я ничего не сделал — всё сделали без меня". Похоже, в обоих случаях неприятно не отсутствие действий, а потеря привычного ощущения прямого вклада.
❤10🔥5🤔3
Кстати, в каком роде вы воcпринимаете gpt или любой другой Ai, которым пользуетесь?
Anonymous Poll
83%
17%
17%