Плоскость культуры и ощущений самая сложная часть работы. Самая сложная техническая задача меркнет перед самым простым процессом с нуля. Перед включением инициативности обязательно нужно узнать предыдущий генезис процессов в фирме. Перед добавление документации нужно поискать предыдущие кладбища документации, продумать самый комплексный вопрос - поддержка и внедрение на всех уровнях системы. С код ревью, да, с любым ритуалом та же ситуация.
Взгляните с другой стороны, возможно там культура чила, и вы, с вашей инициативной группой только вносят раздор, душить коллег просто потому, что вы хотите вырасти? Даже если всё хорошо и ваша группа является большинство, готовы ли вы идти до конца и увольнять людей, которым не подошла ваша новая культура или процесс? Ещё хуже те, кто будет при менеждменте со всем соглашаться, но делать всё на тот процент, чтобы не быть уволенными.
Если оставаться инженером, то я бы порекомендовал дотягивать уже начатый процесс, культурную особенность или не выходить за уровень команды. Если не получается, то менять работу, обязательно найдётся та самая фирма\команда. И обязательно держать в голове поговорку про монастырь и устав. Лично для меня перый критерий профнепригодности когда человек сходу заявляет, что что-то надо поменять и хочет просто натянуть свой предыдущий опыт.
Имею синдром "белого халата", как-то даже простой цикл на смог написать на листике, волнуюсь, трясусь. Заморачивался с мок интервью, STAR, писал сценарий возможного развития диалога. Выношу за скобки эшелон фирм, где существуют открытый гайд и если надо зубрить 16 принципов и следовать протоколу, то даже думать не надо. Так вот даже с системой заметил, что долбоемизм обгоняет щит, были и билеты, и резкий скрининг блиц с примитивыными вопросами, тесты с вариантами ответов. Такое сложно предугадать.
В конце концов выкинул стары, моки, сценарии и любую глубокую подготовку: графы не повторяю, если выпадет, значит не повезло. Обновляю общие знания по языку, фреймворку, проектированию. Первые 3-5 собеседований в фирмы, куда не очень-то и хочу, всё равно обделаюсь, беру плотный темп, по 9-12 собеседований в неделю и не загоняюсь.
Как результат, где нет дурки, то всё и так хорошо, вопросы в целом повторяются, поэтому веду список на которые не ответил. При таком темпе уже не хватет стресса, слошная апатия. В конце обязательно иметь заготовленный список вопросов к компании.
PS. Последний раз проходил интервью 5 лет назад на рынке кандидатов. До этого 9 фирм, в среднем больше чем на 2 года не задерживался.
Как при таком подходе дела обстоят с более комплексной валидацией? Например между полями, одна дата меньше другой, запрет будущих дат, порог сумм и т.д. Существуют расширения, но их реализация полностью кастомная. К тому же не понятно какой именно слой валидации покрывает это решение, я бы условно разделил их на валидацию запроса (типы и пороги), сервисная/доменная (бизнес логика), впрочем домен всё равно должен всё перепроверить. В мечтах хотелось бы изоморфно описать всё в одном формате.
Кажется, что в текущем положении страдает бизнес в равной степени. Лайфкодинг - рак не имеющий ничего общего с работой. Входные фильтры год\технология ещё хуже. Это заставляет читерить даже тогда, когда не хочется. И раз всё равно всё сводится к совокупности того, как человек вписывается в компанию и команду, можно сразу переходить к этому этапу. По поводу ТК, кажется, что он не работает. Кандидатов как-то же набирают в пул без реальных мест, маринуют по несколько недель между каждым этапом, спокойно пишут в офере не оговоренную вилку. Тоже самое касается и Европы.
Считаю, что это прекрасно, надеюсь, что кто-нибудь выпустит хардварный вариант для прохождения интервью или что-то программное незаметное. Сам проводил лайвкодинги, вяло читая задачу за день до собеседования и, когда кандидат предлагал вариант, в котором я был не уверен, говорил “ну попробуй”. Имея под 500 задач на литкоде, вообще не понимаю, для чего это нужно. Сколько обсуждали, что спрашивают либо то, с чем недавно работали, либо с листочка. Современное интервью — это позор: лайвкодинг, системный дизайн, всякие STAR-системы для ответа на бытовые вопросы — это пиздец, и надеюсь, что языковые модели разъебут эту систему. Говорить, что “а вот наши лайвкодинги даже приятные для соискателя! Мы помогаем, включены, даём даже свою IDE!” Спрашивать C4 на системном дизайне, а потом увидеть, что в реальности даже документации нет. И сами же потом говорят, что пересечений крайне мало, даже давать реально встреченную задачу — сделка с совестью, не более.
Я понимаю для чего всё это было сделано, нужен постоянный пул кандидатов, тестовый период это дорого, формальные критерии, количество кандидатов слишком большое. Но вы не Амазон, вы не будете писать книги как пройти ваше интервью и скидывать их кандидатам с ремаркой "встретимся через пол года".
Подбирать надо по культуре: отношению к технологиям, процессам, командам. Пытаться мягко определить мотивацию человека. Для этого достаточно простого словесного интервью. Найдите общее, прочитанную книгу, доклад, тему, обсудите вглубь. Вкладывайтесь в процессы, в которых распиздяй не выдержит — документация, формальности или наоборот. Ищите инженеров. Потом испытательный срок — насколько человек “тянет”, и даже тут: в одной команде может быть хорошо, в другой — плохо. Для работающих людей можно хоть на пару часов в неделю.
Продолжать работать. В Калифорнии уже 10 лет назад хватало людей за 50 спокойно работающих на сеньёрских позициях в таких же командах, как и молодые. На оркл канале иногда седой дед представляется разработчиком. Кажется, что такие упаднические настроения в наших краях обусловлены ранней сеньёрификацией и позициями архитектора в 25 (сам такое видел). Куда стремиться, когда после 3 лет опыта ты уже старший разработчик, в 35 уже старость и пора выгорать. С 40+ лет опыта можно пойти настоящим архитетором и учить молодых писать. В 60 можно и начальником отдела заделаться. Когда наступает старость, кровавый ентерпрайз примет всех, даже если эта старость пришла в 30.
Как разработчик вижу падение своей производительности удалённо, мало того, вижу такое же поведение у коллег. Перестроить процессы под удалёнку, да у нас их и до не особо было. Среди команд коммуникация теперь печальнее некуда, всё-таки собраться у доски лично было куда продуктивнее. Завидую тем, у кого и коллеги активные и расстояние им не помеха, в офисе у нас обеды и время прихода было синхронизированно, как-то само получалось. Сам в офис не хочу, но и выставлять разработчиков в белых одеждах ну такое, как всегда правда где-то посередине всего, я бы сказал в новой культуре, которую ну очень сложно выстраивать.
Как инструмент саморегуляции карма работает, да охлократия, но такие вот люди в русскоговорящем сегменте, как компенсация сделан строгий, по сравнению с другими ресурсами отбор. Вполне нормальный способ показать, что то, что ты делаешь не нравится сообществу. И всё бы было хорошо если бы не категории блогов, которые продолжают писать корпоративный сгенерированный бред, и сколько бы я не фильтровал ленту всё равно попадаешь на очередную статью ради ТГ, визы талантов или крипто скам. Хотелось бы вернуться во времена хабра и мегамозга или найти альтернативы на английском.
Снача усомнился в цифрах, но статистика стима https://store.steampowered.com/hwsurvey/videocard/ по картам отрезвляет. В топ-5 1060 и 1560. Интресно получается, у консолей надо поддерживать 2 поколения, а это +-10 лет, так и на ПК не мало карт восьмилетней давности.
А какие прогнозы по другим прозводителям? Ведь антимонопольщики не позволят доминировать только Nvidia, получается, что придётся, либо делиться технологиями, либо выравнивать мощности видеокарт.
Есть ощущение, что игровая индустрия уже второе поколение предлагает сплошное враньё (маркетинг). Play station 4 позиционировалось, как 4k гейминг, Xbox S - 120 FPS, DLSS, как избавление от проблем с производительность. Но в реальности на консолях надо выбирать между мылом плавающих 60 или "быстрые", но жалкие 30, хотя само по себе настраивать графику, по мне, лишает смысл консоли, а на ПК надо пол года ждать патчей.
Что касается создания, то я уже давно не видел разрушаемости red faction и старого батлфилда, лицевых анимаций, реалистичной физики жидкостей, крови например, проработанных персонажей не в сеттинге калифорнийкого фентези напичканного бездаными, но за-то инклюзивными персонажами. В тоже время игры дорожают, разработка занимает 5+ лет, включает тысячи людей, а на выходе ну такое.
В такой ситуации слабо верется, что будет революция, особенно из уст человека, которому буквально кроме абстрактного "ИИ" в продуктах продавать нечего. По-моему я лет 15 назад видел презентации продуктов от nvidia с физикой, уточками и проприетарными движками, которые должны были всё перевернуть.
В конце концов код и тесты должны быть написаны, последовательность тут не важна, это правда. Главное понимать, что тесты не менее важны чем код:
В вебе, энтерпрайзах чаще всего тесты важнее кода. Цельность фичи, интеграция разработчиков, бизнес инварианты это про тесты, а не про реализацию.
Если код тяжело тестировать = плохой код. Не всегда наоборот.
Тесты это тоже код, его надо уметь писать, изолировать тест кейсы, декомпозировать части логики.
TDD отлично помогает против таких разработчиков "я могу потратить несколько дней на эксперименты, написание MVP, пока не начну немного понимать, какими должны быть части моей системы и чего я от них ожидаю", а может экспериментировать и неделю, и может никогда не понять, чего ожидает от своего же кода. Если есть задача и в ней есть инварианты, то уже можно писать интерфейсы, абстрактные классы и тесты. Если человек может в ТДД, то он способен сперва понять, что надо делать, а не писать по-приборам. В таком случае тесты можно ревьювить до реализации.
Если резюмировать, то TDD для меня имеет скорее образовательный потенциал:
Научить, что разработка быстрее через тесты, чем проверку работоспособность того-же веба через страницу и мануальный ввод.
Заставить заработчика продумать систему, а не экспериментировать и переписывать MVP.
Когда не уверен в команде\разработчике и хочешь посмотреть правильно ли он понимает задачу.
Научить писать тесты, понимать баланс между интеграционными, юнит и функциональными. И что тесты это не про один метод execute вызывает другой execute .
Для разработчиков, которые умеют в понимание задачи, код и в тесты, заставлять точно не нужно.
Если есть возможно поменять бизнес исходя из технической необходимости, то я бы усомнился в необходимости DDD. Сложную логику можно и в сервисах писать. Из своей практики я настаиваю на DDD только в случае решения проблем реального мира. Меньше думать над контекстами\сервисами и сразу есть авторитет, реальный мир вместо мнения разработчиков (сложно делать, сервисы привычней), дизайнеров (многостраничные формы фу, должно быть красиво, не получить всех ошибок домена за один запрос) и аналитиков (несогласованность систем, недостаточные знания по сравнению с владельцами бизнеса).
Например нужно заполнить большой договор, он и в реальности на много страниц, с приложениями, и должен быть сохранён\принят атомарно. Агрегат получается очень большой, многостраничные формы, проверка сторонними сервисами. Из-за избыточного маршалинга, который неизбежность DDD, получается долго в любом случает. По мне если тут хоть у кого-нибудь возникает желание поделить агрегат, или обънить самые тяжёле или важные вещи в один контекст из-за скорости, то цель DDD провалена.
Я не вижу большой разницы с проблемой согласованности в микросервисах, просто попробуйте в большой ЦРМ удалить пользователя. И если микросервисы выбрали ради скорости, то все понимают, что без саги никуда, а вот если из-за DDD и контекстов, то надо смириться с неизбежностью сложных агрегатов и ограниченных инструментов улучшения производительности.
Плоскость культуры и ощущений самая сложная часть работы. Самая сложная техническая задача меркнет перед самым простым процессом с нуля. Перед включением инициативности обязательно нужно узнать предыдущий генезис процессов в фирме. Перед добавление документации нужно поискать предыдущие кладбища документации, продумать самый комплексный вопрос - поддержка и внедрение на всех уровнях системы. С код ревью, да, с любым ритуалом та же ситуация.
Взгляните с другой стороны, возможно там культура чила, и вы, с вашей инициативной группой только вносят раздор, душить коллег просто потому, что вы хотите вырасти? Даже если всё хорошо и ваша группа является большинство, готовы ли вы идти до конца и увольнять людей, которым не подошла ваша новая культура или процесс? Ещё хуже те, кто будет при менеждменте со всем соглашаться, но делать всё на тот процент, чтобы не быть уволенными.
Если оставаться инженером, то я бы порекомендовал дотягивать уже начатый процесс, культурную особенность или не выходить за уровень команды. Если не получается, то менять работу, обязательно найдётся та самая фирма\команда. И обязательно держать в голове поговорку про монастырь и устав. Лично для меня перый критерий профнепригодности когда человек сходу заявляет, что что-то надо поменять и хочет просто натянуть свой предыдущий опыт.
Имею синдром "белого халата", как-то даже простой цикл на смог написать на листике, волнуюсь, трясусь. Заморачивался с мок интервью, STAR, писал сценарий возможного развития диалога. Выношу за скобки эшелон фирм, где существуют открытый гайд и если надо зубрить 16 принципов и следовать протоколу, то даже думать не надо. Так вот даже с системой заметил, что долбоемизм обгоняет щит, были и билеты, и резкий скрининг блиц с примитивыными вопросами, тесты с вариантами ответов. Такое сложно предугадать.
В конце концов выкинул стары, моки, сценарии и любую глубокую подготовку: графы не повторяю, если выпадет, значит не повезло. Обновляю общие знания по языку, фреймворку, проектированию. Первые 3-5 собеседований в фирмы, куда не очень-то и хочу, всё равно обделаюсь, беру плотный темп, по 9-12 собеседований в неделю и не загоняюсь.
Как результат, где нет дурки, то всё и так хорошо, вопросы в целом повторяются, поэтому веду список на которые не ответил. При таком темпе уже не хватет стресса, слошная апатия. В конце обязательно иметь заготовленный список вопросов к компании.
PS. Последний раз проходил интервью 5 лет назад на рынке кандидатов. До этого 9 фирм, в среднем больше чем на 2 года не задерживался.
Как при таком подходе дела обстоят с более комплексной валидацией? Например между полями, одна дата меньше другой, запрет будущих дат, порог сумм и т.д. Существуют расширения, но их реализация полностью кастомная. К тому же не понятно какой именно слой валидации покрывает это решение, я бы условно разделил их на валидацию запроса (типы и пороги), сервисная/доменная (бизнес логика), впрочем домен всё равно должен всё перепроверить. В мечтах хотелось бы изоморфно описать всё в одном формате.
Только в стартапе на 7 человек. Работало отлично, потом проект вырос и у руля, к сожалению, встали люди с привычным видением процесса.
Кажется, что в текущем положении страдает бизнес в равной степени. Лайфкодинг - рак не имеющий ничего общего с работой. Входные фильтры год\технология ещё хуже. Это заставляет читерить даже тогда, когда не хочется. И раз всё равно всё сводится к совокупности того, как человек вписывается в компанию и команду, можно сразу переходить к этому этапу. По поводу ТК, кажется, что он не работает. Кандидатов как-то же набирают в пул без реальных мест, маринуют по несколько недель между каждым этапом, спокойно пишут в офере не оговоренную вилку. Тоже самое касается и Европы.
Считаю, что это прекрасно, надеюсь, что кто-нибудь выпустит хардварный вариант для прохождения интервью или что-то программное незаметное. Сам проводил лайвкодинги, вяло читая задачу за день до собеседования и, когда кандидат предлагал вариант, в котором я был не уверен, говорил “ну попробуй”. Имея под 500 задач на литкоде, вообще не понимаю, для чего это нужно. Сколько обсуждали, что спрашивают либо то, с чем недавно работали, либо с листочка. Современное интервью — это позор: лайвкодинг, системный дизайн, всякие STAR-системы для ответа на бытовые вопросы — это пиздец, и надеюсь, что языковые модели разъебут эту систему. Говорить, что “а вот наши лайвкодинги даже приятные для соискателя! Мы помогаем, включены, даём даже свою IDE!” Спрашивать C4 на системном дизайне, а потом увидеть, что в реальности даже документации нет. И сами же потом говорят, что пересечений крайне мало, даже давать реально встреченную задачу — сделка с совестью, не более.
Я понимаю для чего всё это было сделано, нужен постоянный пул кандидатов, тестовый период это дорого, формальные критерии, количество кандидатов слишком большое. Но вы не Амазон, вы не будете писать книги как пройти ваше интервью и скидывать их кандидатам с ремаркой "встретимся через пол года".
Подбирать надо по культуре: отношению к технологиям, процессам, командам. Пытаться мягко определить мотивацию человека. Для этого достаточно простого словесного интервью. Найдите общее, прочитанную книгу, доклад, тему, обсудите вглубь. Вкладывайтесь в процессы, в которых распиздяй не выдержит — документация, формальности или наоборот. Ищите инженеров. Потом испытательный срок — насколько человек “тянет”, и даже тут: в одной команде может быть хорошо, в другой — плохо. Для работающих людей можно хоть на пару часов в неделю.
Продолжать работать. В Калифорнии уже 10 лет назад хватало людей за 50 спокойно работающих на сеньёрских позициях в таких же командах, как и молодые. На оркл канале иногда седой дед представляется разработчиком. Кажется, что такие упаднические настроения в наших краях обусловлены ранней сеньёрификацией и позициями архитектора в 25 (сам такое видел). Куда стремиться, когда после 3 лет опыта ты уже старший разработчик, в 35 уже старость и пора выгорать.
С 40+ лет опыта можно пойти настоящим архитетором и учить молодых писать. В 60 можно и начальником отдела заделаться. Когда наступает старость, кровавый ентерпрайз примет всех, даже если эта старость пришла в 30.
Как разработчик вижу падение своей производительности удалённо, мало того, вижу такое же поведение у коллег. Перестроить процессы под удалёнку, да у нас их и до не особо было. Среди команд коммуникация теперь печальнее некуда, всё-таки собраться у доски лично было куда продуктивнее. Завидую тем, у кого и коллеги активные и расстояние им не помеха, в офисе у нас обеды и время прихода было синхронизированно, как-то само получалось. Сам в офис не хочу, но и выставлять разработчиков в белых одеждах ну такое, как всегда правда где-то посередине всего, я бы сказал в новой культуре, которую ну очень сложно выстраивать.
Как инструмент саморегуляции карма работает, да охлократия, но такие вот люди в русскоговорящем сегменте, как компенсация сделан строгий, по сравнению с другими ресурсами отбор. Вполне нормальный способ показать, что то, что ты делаешь не нравится сообществу. И всё бы было хорошо если бы не категории блогов, которые продолжают писать корпоративный сгенерированный бред, и сколько бы я не фильтровал ленту всё равно попадаешь на очередную статью ради ТГ, визы талантов или крипто скам.
Хотелось бы вернуться во времена хабра и мегамозга или найти альтернативы на английском.
Снача усомнился в цифрах, но статистика стима https://store.steampowered.com/hwsurvey/videocard/ по картам отрезвляет. В топ-5 1060 и 1560. Интресно получается, у консолей надо поддерживать 2 поколения, а это +-10 лет, так и на ПК не мало карт восьмилетней давности.
А какие прогнозы по другим прозводителям? Ведь антимонопольщики не позволят доминировать только Nvidia, получается, что придётся, либо делиться технологиями, либо выравнивать мощности видеокарт.
Есть ощущение, что игровая индустрия уже второе поколение предлагает сплошное враньё (маркетинг). Play station 4 позиционировалось, как 4k гейминг, Xbox S - 120 FPS, DLSS, как избавление от проблем с производительность. Но в реальности на консолях надо выбирать между мылом плавающих 60 или "быстрые", но жалкие 30, хотя само по себе настраивать графику, по мне, лишает смысл консоли, а на ПК надо пол года ждать патчей.
Что касается создания, то я уже давно не видел разрушаемости red faction и старого батлфилда, лицевых анимаций, реалистичной физики жидкостей, крови например, проработанных персонажей не в сеттинге калифорнийкого фентези напичканного бездаными, но за-то инклюзивными персонажами. В тоже время игры дорожают, разработка занимает 5+ лет, включает тысячи людей, а на выходе ну такое.
В такой ситуации слабо верется, что будет революция, особенно из уст человека, которому буквально кроме абстрактного "ИИ" в продуктах продавать нечего. По-моему я лет 15 назад видел презентации продуктов от nvidia с физикой, уточками и проприетарными движками, которые должны были всё перевернуть.
В конце концов код и тесты должны быть написаны, последовательность тут не важна, это правда. Главное понимать, что тесты не менее важны чем код:
В вебе, энтерпрайзах чаще всего тесты важнее кода. Цельность фичи, интеграция разработчиков, бизнес инварианты это про тесты, а не про реализацию.
Если код тяжело тестировать = плохой код. Не всегда наоборот.
Тесты это тоже код, его надо уметь писать, изолировать тест кейсы, декомпозировать части логики.
TDD отлично помогает против таких разработчиков "я могу потратить несколько дней на эксперименты, написание MVP, пока не начну немного понимать, какими должны быть части моей системы и чего я от них ожидаю", а может экспериментировать и неделю, и может никогда не понять, чего ожидает от своего же кода. Если есть задача и в ней есть инварианты, то уже можно писать интерфейсы, абстрактные классы и тесты. Если человек может в ТДД, то он способен сперва понять, что надо делать, а не писать по-приборам. В таком случае тесты можно ревьювить до реализации.
Если резюмировать, то TDD для меня имеет скорее образовательный потенциал:
Научить, что разработка быстрее через тесты, чем проверку работоспособность того-же веба через страницу и мануальный ввод.
Заставить заработчика продумать систему, а не экспериментировать и переписывать MVP.
Когда не уверен в команде\разработчике и хочешь посмотреть правильно ли он понимает задачу.
Научить писать тесты, понимать баланс между интеграционными, юнит и функциональными. И что тесты это не про один метод execute вызывает другой execute .
Для разработчиков, которые умеют в понимание задачи, код и в тесты, заставлять точно не нужно.
Если есть возможно поменять бизнес исходя из технической необходимости, то я бы усомнился в необходимости DDD. Сложную логику можно и в сервисах писать. Из своей практики я настаиваю на DDD только в случае решения проблем реального мира. Меньше думать над контекстами\сервисами и сразу есть авторитет, реальный мир вместо мнения разработчиков (сложно делать, сервисы привычней), дизайнеров (многостраничные формы фу, должно быть красиво, не получить всех ошибок домена за один запрос) и аналитиков (несогласованность систем, недостаточные знания по сравнению с владельцами бизнеса).
Например нужно заполнить большой договор, он и в реальности на много страниц, с приложениями, и должен быть сохранён\принят атомарно. Агрегат получается очень большой, многостраничные формы, проверка сторонними сервисами. Из-за избыточного маршалинга, который неизбежность DDD, получается долго в любом случает. По мне если тут хоть у кого-нибудь возникает желание поделить агрегат, или обънить самые тяжёле или важные вещи в один контекст из-за скорости, то цель DDD провалена.
Я не вижу большой разницы с проблемой согласованности в микросервисах, просто попробуйте в большой ЦРМ удалить пользователя. И если микросервисы выбрали ради скорости, то все понимают, что без саги никуда, а вот если из-за DDD и контекстов, то надо смириться с неизбежностью сложных агрегатов и ограниченных инструментов улучшения производительности.