Анекдот про it-директоров хорош. Кажется что каждый второй с опытом 20+ лет стал "директором" и завел telegram-канал. Один мой друг собеседовался два года назад в команду из 50 человек и на встрече было 3 человека 40+ лет: технарь руководитель всего, его зам по архитектуре и зам по разработке. Они все были на 1-2 уровня выше тимлидов. Пенсионеры с опытом.
И вот эти пенсионеры сидят настолько крепко, что других пенсионеров не пускают. Играют в царя горы. Еще один мой друг ищет работу более 9 месяцев. У него подтвержденный опыт более 20 лет и лычка cto в резюме. Есть еще история как другой друг год мыкается по компаниям и не может пройти испытательный срок на c-level роли. Естественно не все мои друзья "неудачники", есть и истории успешного успеха.
Не нужно столько "директоров" в индустрии. И многие откровенно не тянут. Клавиатура в руки и код писать их удел. Но тут не будет вкусной зарплаты и красивой должности в резюме. Каждому романтику по лопате и осваивать целину.
Я администрировал сервера и писал код. Писал инфраструктуру в бигтехе и создавал платформы для разработки. Видел много чужой инфры от разработчиков и сисадминов. Поэтому имею что сказать.
DevOps должен делать инженер, который умеет работать в команде. Если надо он разберется с администрированием. По необходимости напишет код. Но главное он решит проблему, а не будет кормить свое эго создавая никому не нужные вещи. И это будет жить после его ухода.
Например, в одной бигтех компании сократили админов и после них осталось огромное число решений одного человека. Оказалось, что есть более 10 способов прописать днс имя внутри, но часть сломано и не работает. Как сказал один из последних сисадминов - лучший админ знает максимальное число способов решения задачи, так как работает в компании давно и видел все.
Потом маятник качнулся в лругую сторону, и из разработчиков-алгоритмистов пытались сделать сисадминов. Тогда это еще не называли - имплементировать роль DevOps. Получилось также плохо, разработчики не хотели делать надежно и лепили тяп ляп. Помню как из-за смешных проблем разваливался прод. Например, ребята писали по одному байту на диск в цикле. Они сбрасывали состояние своего приложения, но не понимали ограничения железа (hdd).
Спас всех инженерный подход. Когда подошли к devops задачам как к продукту. И поставили инженеров писать решение. Все проблемы не решили, но работает. Палки и связующая субстанция помогли. Но когда было по другому?
Поисследовать рынок опенсорса и код коллег, решить что надо писать, а чтоиуже есть готовое
Понять куда эта библиотека будет внедряться и набросать примерный план
Найти тех чьми силами будет делаться внедрение, собрать их вместе и обсудить планы и дизайн
Договориться с руководством о выделении времени команд, показать в чем ценность
Сделать базовый каркас для удобного веедрения библиотек И минимальный mvp библилюотеки (логи-метрики-трейсф отличная идея, либо взять работу с mq как альтернатива), главное не распылять силы
Внедрить мвп и показать итоги руководству, для этог собрать цифры профита, получить апрув и пилить дальше
Является DevP команда неким "архитектором" платформы? Ваши ADR проходят ревью или другие процессы?
Мы являемся фасилитаторами процесса дизайн ревью и общей архитектуры. В большинстве случаев мы "архитекторы" платформы. Но это не закрытое сообщество, всегда можно принести свое общее решение.
Бывает что продуктовые команды игнорируют общее платформенное решение. Для этого надо иметь мотивацию и продать этот выбор нашему CTO. Например так происходит, когда в прод нужно вчера. А общее решене еще не готово. Но со временем мы затаскиваем их на общие инструменты.
Если вам интересно узнать подробности про одну из тем, то напишите комментарий-вопрос. А я/мы расскажем это в формате ответа или полноценного рассказа.
А вот первый пост в жж ru-java от 2003-04-28 - Тест
Sun Campus Ambassador Program
В 2008 году на Sun Tech Days я познакомился с Павлом Вотчицевым - куратором Sun Campus Ambassador в России. Свел его с Антоном Черноусовым и так началась программа Sun Campus Ambassador в Иркутске (вторая половина 2008 года).
А до этого я делал локальное иркутское java сообщество силами своей компании (2007-2008 годы). Веселое время было +)
12 лет назад я считал себя сеньором с 8 годами опыта. Сейчас я понимаю, что был в лучшем случае продвинутым мидлом. И я бы себя не взял на синьора в компанию где я работаю :)
Именно поэтому надо тратить время на подготовку интервьюверов. Буквально вчера мы внутри обсуждали как и зачем проводим архитектурную секцию у себя. По сути согласовывали майндсет интервьюверов.
Лично я считаю что подготовка к архитектурному интервью это некая форма обучения интервьюверов правильным практикам разработки-проектирования, и это полезно не только для проведения собеседований.
Некоторые компании пишут даже текст для кандидата (чтобы он понимал что будет)
Не понимаю почему вы сделали вывод что я не люблю алгоритмы. Я отношусь к ним нейтрально и воспринимаю как рабочий инструмент. Прямо сейчас я даю алгоритмические задачи в упрощенном виде. Но я не вижу смысла давать алгоритмы на обход графа или сложный поиск в тексте.
Я согласен что есть положительная корреляция между участием в "олимпиадах" и умением писать код. Но я в свою очередь видел большой число "олипиадников", которые не умели писать продакшен код. Возможно это связано с тем, что я работал в компании куда брали любителей алгоритмических задач.
Спасибо что поделились опытом и цифрами. По моей памяти мы нанимали 5% от входного потока. Очень много инженеров были не способны пройти наше собеседование.
Сейчас я строю найм инженеров на новом месте и тут у нас все сильно лучше. Мы уже не пытаемся нанимать "олимпиадников". Но все равно - много людей не понимает что они делают.
Я подготовил задачи на ревью кода и оказывается в индустрии очень слабо с пониманием что такое код ревью. Что уж говорить про написание простого прохода по массиву. В общем попробую как-нибудь про это все написать с примерами задач и решений кандидатов.
Проблема не в том что сбежит, проблема в том что придется увольнять. Обычно компания не хочет иметь плохую репутацию на рынке труда из-за постоянного увольнения людей.
Про это я писал в первом разделе - Интерлюдия. Но тут есть повышенные риски со стороны кандидата - увольнение на испытательном сроке. Не все работодатели готовы соглашаться на такой риск.
Совместная беседа двух людей по поводу вакансии и работы обычно происходит после подтверждения технических навыков. Иногда это совмещается с техническим интервью. Акцент в моей публикации был на оценке со стороны работодателя.
не совсем понятно, как поток программистов с плачевными результатами смог привести к успеху
Для начало надо понять что такое успех. По моему мнению тут можно оценивать успех как рост сервисов компании, акций компании и компенсаций сотрудников. Тут все это было в течении 3 лет.
Далее я писал что причин успеха было множество. Я обратил внимание на устранение бардака и фокусировке на правильной культуре. По сути в компании оставались-нанимались люди с похожим майндсетом, что снижало затраты на коммуникацию.
При этом плачевный результат был поначалу, в дальнейшем люди научились и нашли другие способы решения проблем. Давайте я поправлю в тексте так:
В первое время эффективность и результат их работы были плачевными.
Проблема не в легаси, а в кривой обучения. Когда пишешь сам с нуля, то постепенно понимаешь что и как. А вот с легаси надо сразу охватить кучу вещей, про которые знает только прошлый автор. Еще хуже, когда нельзя улучшать чужой легаси код, и тебя заставляют писать плохо всегда.
Обычно я офер показываю из вежливости, когда 99% уже собрался уходить. Причем не обязательно, что это будет компания из офера +) Мне кажется, что отношения построенные на шантаже, не стоят моего времени. Ведь начальство будет помнить про этот шантаж, и тут как раз «остановка карьеры» случается.
Ну а если меня отправляют за офером в другую компанию, то это точно намек на поиск другого места работы. Кстати меня не разу не посылали таким образом +)
Анекдот про it-директоров хорош. Кажется что каждый второй с опытом 20+ лет стал "директором" и завел telegram-канал. Один мой друг собеседовался два года назад в команду из 50 человек и на встрече было 3 человека 40+ лет: технарь руководитель всего, его зам по архитектуре и зам по разработке. Они все были на 1-2 уровня выше тимлидов. Пенсионеры с опытом.
И вот эти пенсионеры сидят настолько крепко, что других пенсионеров не пускают. Играют в царя горы. Еще один мой друг ищет работу более 9 месяцев. У него подтвержденный опыт более 20 лет и лычка cto в резюме. Есть еще история как другой друг год мыкается по компаниям и не может пройти испытательный срок на c-level роли. Естественно не все мои друзья "неудачники", есть и истории успешного успеха.
Не нужно столько "директоров" в индустрии. И многие откровенно не тянут. Клавиатура в руки и код писать их удел. Но тут не будет вкусной зарплаты и красивой должности в резюме. Каждому романтику по лопате и осваивать целину.
Я администрировал сервера и писал код. Писал инфраструктуру в бигтехе и создавал платформы для разработки. Видел много чужой инфры от разработчиков и сисадминов. Поэтому имею что сказать.
DevOps должен делать инженер, который умеет работать в команде. Если надо он разберется с администрированием. По необходимости напишет код. Но главное он решит проблему, а не будет кормить свое эго создавая никому не нужные вещи. И это будет жить после его ухода.
Например, в одной бигтех компании сократили админов и после них осталось огромное число решений одного человека. Оказалось, что есть более 10 способов прописать днс имя внутри, но часть сломано и не работает. Как сказал один из последних сисадминов - лучший админ знает максимальное число способов решения задачи, так как работает в компании давно и видел все.
Потом маятник качнулся в лругую сторону, и из разработчиков-алгоритмистов пытались сделать сисадминов. Тогда это еще не называли - имплементировать роль DevOps. Получилось также плохо, разработчики не хотели делать надежно и лепили тяп ляп. Помню как из-за смешных проблем разваливался прод. Например, ребята писали по одному байту на диск в цикле. Они сбрасывали состояние своего приложения, но не понимали ограничения железа (hdd).
Спас всех инженерный подход. Когда подошли к devops задачам как к продукту. И поставили инженеров писать решение. Все проблемы не решили, но работает. Палки и связующая субстанция помогли. Но когда было по другому?
Поисследовать рынок опенсорса и код коллег, решить что надо писать, а чтоиуже есть готовое
Понять куда эта библиотека будет внедряться и набросать примерный план
Найти тех чьми силами будет делаться внедрение, собрать их вместе и обсудить планы и дизайн
Договориться с руководством о выделении времени команд, показать в чем ценность
Сделать базовый каркас для удобного веедрения библиотек И минимальный mvp библилюотеки (логи-метрики-трейсф отличная идея, либо взять работу с mq как альтернатива), главное не распылять силы
Внедрить мвп и показать итоги руководству, для этог собрать цифры профита, получить апрув и пилить дальше
Мы являемся фасилитаторами процесса дизайн ревью и общей архитектуры. В большинстве случаев мы "архитекторы" платформы. Но это не закрытое сообщество, всегда можно принести свое общее решение.
Бывает что продуктовые команды игнорируют общее платформенное решение. Для этого надо иметь мотивацию и продать этот выбор нашему CTO. Например так происходит, когда в прод нужно вчера. А общее решене еще не готово. Но со временем мы затаскиваем их на общие инструменты.
Каналы с информацией о релизах (дублирование ченджлога)
Публичные обсуждения архитектуры, например в прошлом году обсуждали про сервис меш
Синки с представителями (техлидами) команд по языкам
Рабочие группы по внедрению общих решений, без привлечения менеджеров, только разработчики
Приносим MR с кодом в продуктовые команды (своими силами пишем код для других команд)
Чаты поддержки, документация и дежурство в рабочее время
Недельные демо с обсуждением (записываем на видео)
Если вам интересно узнать подробности про одну из тем, то напишите комментарий-вопрос. А я/мы расскажем это в формате ответа или полноценного рассказа.
Аня Барски — Java Life Story
https://www.youtube.com/watch?v=WG9JOL8Imns
Вы совсем забыли про jug в СПб. Его делал Яков Сироткин и заманивал топовых ребят со всего мира (Joshua Bloch).
Вот один из первых анонсов jug в спб в далеком 2024-10-04 - Питерский ответ на Java 5.0 launch party :)
В дальнейшем эстафету принял современный jugru
А вот первый пост в жж ru-java от 2003-04-28 - Тест
В 2008 году на Sun Tech Days я познакомился с Павлом Вотчицевым - куратором Sun Campus Ambassador в России. Свел его с Антоном Черноусовым и так началась программа Sun Campus Ambassador в Иркутске (вторая половина 2008 года).
А до этого я делал локальное иркутское java сообщество силами своей компании (2007-2008 годы). Веселое время было +)
12 лет назад я считал себя сеньором с 8 годами опыта. Сейчас я понимаю, что был в лучшем случае продвинутым мидлом. И я бы себя не взял на синьора в компанию где я работаю :)
Именно поэтому надо тратить время на подготовку интервьюверов. Буквально вчера мы внутри обсуждали как и зачем проводим архитектурную секцию у себя. По сути согласовывали майндсет интервьюверов.
Лично я считаю что подготовка к архитектурному интервью это некая форма обучения интервьюверов правильным практикам разработки-проектирования, и это полезно не только для проведения собеседований.
Некоторые компании пишут даже текст для кандидата (чтобы он понимал что будет)
https://www.tinkoff.ru/career/it/interview/backend/
https://yandex.ru/jobs/pages/dev_interview
Не понимаю почему вы сделали вывод что я не люблю алгоритмы. Я отношусь к ним нейтрально и воспринимаю как рабочий инструмент. Прямо сейчас я даю алгоритмические задачи в упрощенном виде. Но я не вижу смысла давать алгоритмы на обход графа или сложный поиск в тексте.
Я согласен что есть положительная корреляция между участием в "олимпиадах" и умением писать код. Но я в свою очередь видел большой число "олипиадников", которые не умели писать продакшен код. Возможно это связано с тем, что я работал в компании куда брали любителей алгоритмических задач.
Спасибо что поделились опытом и цифрами. По моей памяти мы нанимали 5% от входного потока. Очень много инженеров были не способны пройти наше собеседование.
Сейчас я строю найм инженеров на новом месте и тут у нас все сильно лучше. Мы уже не пытаемся нанимать "олимпиадников". Но все равно - много людей не понимает что они делают.
Я подготовил задачи на ревью кода и оказывается в индустрии очень слабо с пониманием что такое код ревью. Что уж говорить про написание простого прохода по массиву. В общем попробую как-нибудь про это все написать с примерами задач и решений кандидатов.
Проблема не в том что сбежит, проблема в том что придется увольнять. Обычно компания не хочет иметь плохую репутацию на рынке труда из-за постоянного увольнения людей.
Про это я писал в первом разделе - Интерлюдия. Но тут есть повышенные риски со стороны кандидата - увольнение на испытательном сроке. Не все работодатели готовы соглашаться на такой риск.
Совместная беседа двух людей по поводу вакансии и работы обычно происходит после подтверждения технических навыков. Иногда это совмещается с техническим интервью. Акцент в моей публикации был на оценке со стороны работодателя.
Для начало надо понять что такое успех. По моему мнению тут можно оценивать успех как рост сервисов компании, акций компании и компенсаций сотрудников. Тут все это было в течении 3 лет.
Далее я писал что причин успеха было множество. Я обратил внимание на устранение бардака и фокусировке на правильной культуре. По сути в компании оставались-нанимались люди с похожим майндсетом, что снижало затраты на коммуникацию.
При этом плачевный результат был поначалу, в дальнейшем люди научились и нашли другие способы решения проблем. Давайте я поправлю в тексте так:
Ну а если меня отправляют за офером в другую компанию, то это точно намек на поиск другого места работы. Кстати меня не разу не посылали таким образом +)