Вот такой JEDI-манифест. Принципы работы с новичками по работе с джунами выкатили Глеб Михеев, Серёжа Попов и другие классные ребята

Советую ознакомиться и обсудить

JEDI-манифест. Принципы работы с новичками

Я давно сокрушаюсь, что на нашем рынке недостаточно работают с джунами, и как следствие мы испытываем проблемы с мидлами и синьорами. И всю дорогу предлагал это изменить, брать больше джунов. Одна команда - один джун. Крайне понятный и простой прием, один управленческий принцип, имплементировав который, мы получим устойчивый приток новых кадров в нашу сферу

Но, потом начинаются справедливая критика: а "как их отбирать?", "как их растить?", "это же мне придется для них искать отдельные джуновские задачи?", и так далее. И вот тут и кроется проблема

Без понимания как с этим жить, естественно, никто не будет набирать джунов, либо, будет сильно страдать, делая какие-то отдельные лягушатники, огораживать их отдельной оградкой, не звать на «взрослые» планирования/стратегии/гильдии (нужное подчеркнуть), а потом будут удивляться, а чо это они у нас не растут?

Короче, к чему я все? Собрались мы с моими уважаемыми коллегами по цеху, которые, как и я, видят в этом проблему, знают как растить и топят за джунов, и задали себе вопрос: а какими принципами мы руководствуемся, организуя работу с джунами?

Так вот, мы собрали 15 принципов работы с джунами и назвали их JEDI-манифест (Junior Engagement and Development Initiative), который выложили на github. Далее мы будем писать гайды, как делать те или иные вещи и развивать методологическую составляющую. Мы очень надеемся, что этим сможем помочь разработчикам, командам и компаниям справится с непониманием и преодолеть этот барьер

Делитесь, ругайте, хвалите, мы очень будем рады любой обратной связи, а если вы разделяете ценности с нами и хотите поучаствовать - присоединяйтесь на правах опенсорса, мы будем рады)

Ну и конечно, я не мог не сделать по этому поводу доклад! В нем я рассказываю о проблеме, как я вижу и о всех принципах выстраивания работы с джунами

https://www.youtube.com/watch?v=zp6wQn1L3sc

Классный доклад в редакции Онтико вместе со спикером преобразовали в полезную статью.

Это история про то, что такое CI/CD. Про то, что это не просто написать пачку YAML'ов или собрать код при создании pull request и деплой по кнопке, а много чего ещё.

Тема, казалось бы, сильно заезжена, но дьявол, как известно, кроется в деталях. Поэтому поговорим про то, что остаётся за бортом, превращая ценный набор практик в карго-культ.

Head of Infrastructure and Security в Uzum Market Владимир Утратенко провёл антинаучное исследование на нерелевантной выборке, но вывод интересный: 25 из 30 DevOps-инженеров на собеседовании путают CI и CD.

✅ Подробности в статье: https://habr.com/ru/companies/oleg-bunin/articles/821867/

Скоро опубликую крутое интервью с известным спикером Аней Жарковой - как раз про вход, требования и коммуникации в IT

От айтишников требуют софт-скиллы.

41% руководителей в сфере ИТ стали чаще обращать внимание на софт-скиллы кандидатов, сообщается в исследовании компании ITQuick и Зарплаты.ру. В компаниях их считают очень важными, но в большей степени это касается опытных специалистов, которые не только кодят – так что для джунов это пока второстепенный вопрос.

Самым важным софт-скиллом респонденты выбрали «гибкость и умение адаптироваться к изменениям» – за него отдали голос 64% опрошенных. Всего на один процент ему уступает «умение эффективно решать проблемы и принимать решения», а далее следуют умение работать в команде (43%), коммуникативные навыки (37%) и лидерские качества (33%).

Также отмечается, что в этом году работодатели ужесточили требования к кандидатам в целом (к опыту, хард-скиллам и т.д.) – это сообщили в 30% компаний. И почти столько же отмечают снижение числа вакансий и увеличение конкуренции между кандидатами, что по сути и провоцирует рост требований.

По дальнейшим перспективам в компаниях ожидают рост спроса на специалистов в области машинного обучения, искусственного интеллекта и кибербезопасности, а также 40% опрошенных считают, что в будущем софт-скиллы станут важнее, чем технические навыки.

Что-то я как-то в шоке от таких приколов, маразм крепчал

Брекинг ньюз

Какие-то уважаемые странные люди из Treadstone 71 пытаются наложить персональные санкции США на всех спикерам PHDays

Естественно я был одним из спикеров (привет Антон, Сережа, Синицын). Что ж, потихоньку мы приходим к теме, как с значком Parental Advisory, которым помечали музыку, не рекомендуемую для детей в США и который очень быстро стал знаком отличия качественной музыки

Приму подобный знак отличия с гордостью! Главное чтобы ютуб не удалили придется на рутьюбе выходить

Ничего себе
Куберу 10ка
Как быстро время летит

Празднуем 10 лет Kubernetes на Saint HighLoad++ 2024

На связи Александр Белоцерковский, член ПК HighLoad++, директор по технологическому евангелизму, СберТех.

10 лет назад, в июне 2014 года, на GitHub был отправлен первый коммит в Kubernetes – 250 файлов, 47 тысяч строчек разнообразного кода. Kubernetes тогда отвечал на вопрос: а как же управлять всем тем богатством контейнеров, которое увеличивалось вслед за мощностью железа и требовательностью в производительности от пользователей сервисов?

Сегодня Kubernetes называют новой операционной системой. Я вижу в этом аккуратную метафору к пользовательскому опыту. Десять лет назад, чтобы собрать и запустить проект, нужно было основательно подготовиться. Пять лет назад – немного постараться. Сегодня же можно зайти на CNCF Tech Radar и собрать Cloud Native экосистему, компоненты которой будут так или иначе поддерживать друг друга. Бери, что нужно, собирай, как нужно, подключай куда нужно.

Как же операционная система под названием Kubernetes повлияла на индустрию и HighLoad++?

Я полюбопытствовал и изучил программы за прошлые годы:

HighLoad++ 2014 – как скрестить Docker & Puppet?

HighLoad++ 2015 – уже два доклада с фокусом на Docker и высокопроизводительные системы, опыт разработки.

HighLoad++ 2016 – пять докладов. Становится больше продакшена, больше миграций, нить мысли – «как мы это пережили и сделали эффективнее»

HighLoad++ 2017 – Docker как тема уходит с радаров, переходя на плато продуктивности, вместо него – продакшен на Kubernetes.

... прыжок во времени ...

Saint HighLoad++ 2022 – мультитенантный Kubernetes (запись доклада, посмотрите)

Saint HighLoad++ 2023 – перенос легаси-приложений в Kubernetes (и здесь запись доклада)

Kubernetes значительно повлиял на то, как в индустрии решают задачи и породил собственные тренды. Мы на HighLoad++ любим тренды и будем много говорить о них в Санкт-Петербурге:

1. Open Source: Kubernetes был внутренним проектом Google, который они разработали и решили выложить в Open Source. Осмелюсь сделать вывод, что Kubernetes вместе с Tensorflow стали одним из мощнейших стимулов развития Open Source, открыв путь к новым бизнес-моделям, а вместе с этим – новым проблемам. Об этом в подробностях в докладе от Николая Никитина (ИТМО) «Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source?»

2. Оркестрация контейнеров: Kubernetes стал стандартом для управления контейнеризированными приложениями. В 2014 на HighLoad++ рассказывали о том, как скрестить Docker с Puppet, в 2024 Максим Чудновский из СберТех с солидным докладом «Как мигрировать тысячи сервисов между любыми дистрибутивами Kubernetes без единой правки чего-либо». 

3. Эволюция экосистемы и платформы: За 10 лет экосистема Kubernetes значительно выросла. Стало доступно множество инструментов для мониторинга, управления конфигурациями, автоматизации CI/CD и обеспечения безопасности. Компании разрабатывают на основе или с помощью Kubernetes платформы. Kubernetes дал стимул этой теме и говорят, что 70% платформ будет Cloud Native. И платформы вышли за пределы темы Kubernetes — и об этом нам расскажет Данил Валгушев из Яндекса «Как платформа A/B-тестов Яндекса превратилась в решение для всего Интернета — Varioqub».

4. Облачные сервисы и Kubernetes: Практически все крупные облачные провайдеры предлагают управляемые сервисы Kubernetes (Kubernetes as a Service), делая его ещё более доступным и привлекательным для разработчиков. Но, если Kubernetes изначально cloud native, что делать, если хочется сделать managed сервис из того, что не было разработано или адаптировано для облака? Об этом Дмитрий Некрылов из Яндекс360, как они Jitsi под большие нагрузки в облаке готовили.

5. Эксперименты: Куда без экспериментов! В самом начале пути Kubernetes и базы данных никто не ставил в одном предложении, сегодня обсуждают паттерны эффективности. ML? Пожалуйста. Возможно, и квантовые вычисления подоспеют. В облаке же уже есть симуляторы, например, от Cloud. ru. 

Приходите праздновать день рождения Kubernetes в Санкт-Петербурге 😎

Оптимизация она такая: привезла малого на тренировку по теннису и пока он тренил пошла в местный не очень удачный зал на полчасика базу сделать - присед, жим ногами, становую, выпады в Смите. Уже хлеб - хоть время не пропало
Еще ноут со мной ездит работать регулярно на такие мероприятия
Ну а че: тупить в запрещеннограмм что-ли

когда со спикером одновременно заржали над словом усугублять – это метч я считаю🙈😂

наткнулась на шикарную опечатку G-point вместо J-point
Действительно, зачем нам какая-то скучная Java если можно о более интересных вещах потрещать 😏

По работе зашла на сайт ФСТЭК
в поисках официальной методички по уязвимостям

Почему так смешно

Смотрим с сыном «мэри поппинс»
- Мери поппинс, куда делась ваша раскладушка? Где вы спали этой ночью?
- Леди на подобные вопросы не отвечают, потому что джентельмены их не задают

Ну шикарно же

Наблюдала как на тренировке шмель пару минут бился в окно
А потом сел на подоконник и по ходу умер.
Задумалась

Предвестники беды

На полном серьезе, на мердже в программе доклады с шизотерикой. Это форменный пиздец. Когда в техническую тематику приходит нумерология жди беды. Ладно, что есть такие люди, хрен бы с ними, фантазерами мир полнится, но на айтишной конфе на полном серьезе заявлять такие доклады 🤡. Это как скверна, сначала один докладик, потом второй, а потом у тебя планирование релизов и бюджета идет по звездам, и появляется ставка главного звездочета (хотя чем аджайл-коучи лучше? Но, это уже отдельная история)

- "...затронем важные Астрологические нюансы/факты (ретроградный Меркурий, коридоры затмений, соединение планет) и как эти факты могут повлиять на сферу IT и в целом на ваш бизнес."
- Как-как, НИКАК (фьють-ха)

Что дальше? Начнете приворотные зелью на выручку и кроличьи лапки на CSI продавать?

Увидела у Глеба Михеева и мой шок тоже в шоке 😮

Что вы знаете о самопрезентации? Умеете ли ее строить? Вот такая авторская модель самопрезентации «мартешка» родилась у эксперта комьюнити экспертов Скиллбокс Дмитрия Зверева. Концепция правда любопытная. А что вам помогает выстраивать свой образ в коммуникации? Задумывались ли об этом?

https://vc.ru/life/1256155-model-samoprezentacii-razbiraem-na-matreshkah

Избегаем брошенных невпопад реплик

Продолжаем читать книгу «Неудобные разговоры», скоро будем обсуждать всем комьюнити экспертов Skillbox.

Попалась интересная мысль про брошенные невпопад реплики.

Когда нам нужно сказать что-то важное, мы говорим это сразу же, потому что именно в данный момент эта мысль вызывает у нас неприятные чувства. Большинству не хватает рассудительности, чтобы правильно выбрать время и избежать ошибок. Но когда человек говорит, что был у доктора и тот сказал, что ему всё же нужна операция, мало кому придёт в голову напоминать про долг в 500 долларов.

Но есть ещё одна частая ошибка — реплики, брошенные невпопад. Например, сотрудник постоянно опаздывает на работу и вы давно хотите это обсудить, поэтому говорите: «Опять опаздываем» и оставляете всё как есть. Или сами внезапно приезжаете к сыну, видите пустые пивные бутылки в мусорном ведре и говорите «Вижу, ты до сих пор пьянствуешь».

Такие комментарии используются вроде бы с целью помочь: вы надеетесь, что ваш сотрудник или сын прислушаются к голосу разума. А ещё вы сами почувствуете себя лучше — ведь хоть что-то сказали. Но эти реплики заставляют собеседника принять защитную позицию и расстраивают его, а это вряд ли приведёт к положительным изменениям.

Есть одно хорошее правило: если вы хотите поговорить, сделайте это. Но не на ходу. Запланируйте время для разговора и четко заявите, что вам нужно обсудить что-то важное. Вы не сможете уместить настоящий разговор в 30 секунд. А ничто меньшее, чем настоящий разговор вам не поможет.

ChatGPT прошел «тест Тьюринга», который проверяет наличие интеллекта, эквивалентного человеческому. @banksta