Так решил ревьюер, человеческий фактор здесь тоже влияет.
Закидывать такую иконку на ревью в App Store мы не стали, уже научены кейсом с кальмаром.
Если вы считаете, что отказ был из-за человеческого фактора, почему бы не попробовать с человеком-пауком? Вдруг его ревьювить будет другой человек, и вам повезет?
Или есть какие-то штрафы за то, что ваше изменение не пропустят?
Я думаю, вы и сами не хотели бы получить мобилизационное по той причине, что в минобороны от минцифры данные ушли в cp1251, которая думает, что она utf-8, например
Не хотел бы. Но увы, это более чем реально. Наши hr, например, сломали кодировку, когда решили в эксельке заполнить данные о ЮЛ.
Я не утверждаю, что фигак-фигак и в продакшен - правльно. Я привел крайний, редкий, пограничный пример, когда скорость важнее всего, и когда это оправдано.
Если вы разрабатываете софт для марсохода стоимостью 10млрд , который должен еще уметь дистанционно самообновляться - там, вероятно, будут другие приоритеты.
Я утверждаю, что нет догм.
Разумеется, нарушать "общепринятые" нормы можно только тогда, когда у вас есть достаточный опыт в разработке и архитектуре. Когда вы точно знаете, что делаете, и зачем. И ответить на эти вопросы можно только выяснив потребности бизнеса.
Сначала моя задача - собрать функциональные и не функциональные требования (да, хорошо бы этим занимались специально обученные люди, но они есть не везде)
А потом уже предложить варианты решений. Не наоборот.
Потому что помимо надежности и сопровождаемости есть и другие аспекты.
И я пытался сказать, что корреляция других атрибутов качества с реальными потребностями часто не учитываются при разработке, и либо продалбываются, либо наоборот, бизнес платит за то, чтот не нужно.
Прямо сейчас ребята из Мин Цифры слепили на коленке поделку в виде csv файликов, куда кое-кто из нас сможет внести свои паспортные данные и отправить через Госуслуги.
Как считаете, в текущей обстановке им лучше наг...кодить обмен данными через csv, или же пару недель рожать "достаточно хорошее" решение, а потом еще пару недель его обкатывать? Ну там, с тестами, удобством развертывания и конфигурации?
Рабочий код сам по себе не является ценностью. Не может быть абстрактно "достаточно хорошего" кода. Как и "плохого". Он важен как инструмент для решения бизнес-задач. Что нормально, а что нет, диктуется целом рядом нефункциональных требований и ограничений.
Разработчики постоянно попадают в ловушку своего прошлого опыта, в ловушку своего "знания" как на самом деле надо разрабатывать. Кто-то стремится к идеалу, кто-то к золотой середине качества. Но даже такие, казалось бы, важные атрибуты качества, как эффективность, надежность, сопровождаемость не являются безусловно важными.
Потребности бизнеса диктуют, какой должна быть система. А не наоборот.
Я бы добавил еще пункт про то, что в разработке нет догм. И бизнес платит, чтобы его проблему решили наиболее эффективным способом. Не "правильным", а эффективным.
Если вам хочется написать микросервисное распределенное докер-кубер-чудо - бейте себя по рукам линейкой. Если хочется многопоточный монолит - тоже бейте. Тоже линейкой. И за код с душком бейте. А за идеальный, структурированный, понятный, легко поддерживаемый, покрытый тестами, документированный код бейте молотком.
Потому что идеальный он только в вашей голове и только по вашему мнению. А за эту виртуальную идеальность бизнес заплатил реальными деньгами. Реальным временем. И не факт, что вот это все было действительно нужно. Особенно, когда вы перейдете на другой проект или в другую компанию.
Сначала сходите к бизнесу, и поймите его боль. Вы работаете, чтобы эту боль облегчить.
Зачастую проблема не в том, что слишком рано или поздно или еще как-то.
Проблема в том, что идея и реализация - разные вещи. Даже, если идея на 146% стоящая, ей тяжело дожить даже до стадии прототипа. А уж перенести идею в производство - это из разряда фантастики.
У меня тоже есть история красивой идеи.
Лет так 20 назад, когда появились относительно доступные китайские светодиоды, я подумал, а почему бы не совместить мобильник и фонарик? С лампой накаливания, идея, понятно, глупая. А вот с нормальным светодиодом должно взлететь!
Пообщался с отделом закупок на работе (а наша фирма паяла и программировала всякое из китайских запчастей), я выделил из своей студенческой зарплаты 16 баксов за два светодиода и пару месяцев спустя получил чудо техники. При зарплате 60 баксов это было болезненно, но чего не сделаешь ради идеи!
Немного работы сверлом и паяльником, и я присобачил светодиод к плате своего Alcatel. Увы, это был глючный Alcatel, на Nokia денег не было. Далее сделал в корпусе две дырочки, через одну вывел кнопку выключателя, черед другую торчал светодиод.
Вуаля!
У меня оказался гаджет, опередивший время. Телефон с фонариком!
Но дальше вау-эффекта среди друзей дело не пошло.
А теперь, как всем известно, практически невозможно найти телефон без фонарика.
Вы привели пример, когда в туалете хорошо, а в целом все плохо. Да такое бывает.
Но смотреть туалеты (а также кухню) все же надо. Мне еще не встречались случаи, когда в клозетах была бы разруха, а во всем остальном царил бы порядок.
Если Вы увидели проблему, надо о ней заявить сразу. Например - «оказывается на этом проекте всё плохо, критичные проблемы 3 раза в день. Поставим цель - дойти до 1 раза в неделю».
Приблизительно так я и сделал. Пробежался по всем (разрабы, аналитики, тестеры, эксплуатация), собрал их наболевшие места, изучил документацию, ознакомился с кодом, и преподнес начальству список наиболее критичных проблем.
Составили с начальством план.
Даже договорились с бизнесом 30% времени уделять техдолгу.
И у вас появляется нормальный сон
Наоборот, рефакторинг (неважно, кода или процессов) приводит к некой временной нестабильности. Если мы угадали с рефакторингом - ок, потом станет лучше. Но в моменте нормальный сон исчезает)
8-часовой рабочий день и время для спокойного выравнивания ситуации
А по поводу переработок... задачи бизнеса никто не отменял. Так что приходится одновременно и технически развивать проект, и бизнес удовлетворять. Теми же ресурсами. И теперь надо попасть не только в бизнес-цели, но и в технические цели. То есть вместо одной морковки сзади появилось две.
Да, через несколько месяцев работы спать я стал больше. И успевал заниматься техническим развитием. Но к тому моменту уже понял, что больше не могу и не хочу быть локомотивом. Которому больше всех надо, и который всегда крайний.
Пришел к начальству за деньгами. Предложили дать денег, но с роли тимлида без команды, который в одиночку пилит не сильно нужный бизнесу проект, перейти на роль тимлида с нормальной командой, которая пилит критичный проект. Там как раз тимлид увольнялся.
Challenge и все такое, подкрепленный 40% ростом зп. А у меня большая семья, деньги нужны.
А проект оказался совсем не таким, как в рассказах начальства. Но я думал, что "втянусь", что все разрулю, что смогу все изменить. Тимлид я или не тимлид? Это ведь моя работа. Мне за это платят. Чтобы я решал проблемы.
Через год и правда, многое изменилось. Меня стали будить в 3 раза реже. Но я уже выгорел.
По итогу, "бенефит" вижу в том, что нехило так прокачался как тимлид.
Что помогло устроиться на нынешнюю работу, еще раз на 40% повысив доход (это с учетом ежегодных премий)
Прокачался настолько, что через 3 месяца на новой работе увольняющийся техлид предложил занять свое место.
Хотел сначала сменить проект, на 1on1 недвусмысленно сказал, что в этом аду выдержу не больше месяца. Услышали, вызвали к вышестоящему, наобещали светлое будущее.
Через месяц все осталось, как прежде. И я пришел с оффером.
Тут сразу появилась возможность перевестись на другой проект с завтрашнего дня, но было уже поздно.
А по моим наблюдениям все ровно наоборот. На прошлом месте работы за год увеличили штат на 30%, набрав стажеров и джунов.
Потому что мидлов, а уж тем паче синьоров, искать доооолго, и они дорогиииие.
На текущей работе, когда я пишел к начальству с пожеланиями увеличить команду, мне настоятельно советуют взять джуна-разраба, которого буду натаскивать. И взять джуна тестера, который в тандеме с синьором погрузится в проект, а синьора через 3 месяца заберут.
Так что потребность в джунах и даже стажерах велика. Что, конечно, не отменяет серьезного отбора при трудоустройстве.
Пол-года назад я был грустным тимлидом. Отвечал за business-critical проект, который падал, как сосульки по весне. Меня будили по ночам. Меня вспоминали на каждом разборе инцидентов с CTO. Диалог с бизнесом напоминал картинки с совой. Разработчики достались от предыдущего тимлида, скажем так, не сильно мотивированные и каждый со своими тараканами. Проект сменил трех тимлидов за 4 года. Я кодил по ночам, потому что днем бегал в мыле и разруливал проблемы, ничего не успевая. Я боялся своего телефона. Я просыпался от кошмаров, и не мог понять, это мне приснилось, или сервер по-настоящему лежит.
Один раз видел, как человека за умение сказать нет назвали неадекватом
Что скорее всего говорит о необходимости прокачивать это умение. Отказывать так, чтобы и отношения сохранить, и свои интересы отстоять.
Я - тимлид, и товарищи из команды, бывает, говорят "нет" таким образом, что майка заворачивается. Если они говорят обоснованно, я "прикрываю" их от бизнеса. Говорю, что я понял. Нет - значит нет. Но бизнес не поймет. Давай сядем, обсудим, как нам это до них донести. А потом иду доносить, апеллируя к тому, что "да" принесет денежные/репутационные потери, а "нет" откывает возможность других решений. И предлагаю компромисс, или альтернативу, как нанести компанти максимальную прибыль.
Да, прокатывает не всегда. Но чаще, чем у чистых технарей, когда они пытаются сказать "нет" напрямую.
В одной компании было два тех собеса по часу - осталось ощущение, что не хватает времени.
Вы конечно извините, но если интервьюер через час технического собеседования не знает, подходит ли кандидат - то он никудышний интервьюер. Более того: если не подходит (а таких большинство), это в 80% случаев понятно уже минут чрез 15.
Другое дело, что требуется соблюдать правила игры. Если культ найма требует религиозных ритуалов - "behavioral interview", "coding interview", "system design interview", никуда интервьюер не денется. Будет сидеть, раздувая щеки, уже зная, прошел кандидат или нет.
Перспективы каждый раз при перекладывании жсонов или байтиков думать, что идти в Физтех для этого было не обязательно, и я просто разбазариваю свалившееся на меня богатство.
Счастливчик! Жсоны - это роскошь. Я вот после Физтеха эксельки перекладываю. И это имея за плечами 20 лет разработки.
А если серьезно, у Физтеха есть один серьезный изъян: вам внушают, что вы особенный. Если демонстрируете успеваемость, или, не дай Бог, призовые места на олимпиадах, вас всячески пестуют и поддерживают миф о вашей уникальности.
А после выпуска вас накрывает когнитивный диссонанс и фрустрация, потому что жизнь устроена по-другому.
Не поймите меня неправильно, вышка лично мой мозг прокачала до максимума. Сделала меня - мной. Высококвалифицированным хорошо оплачиваемым специалистом.
Не хотел бы набрасывать по поводу тестовых заданий... Но мое сугубо личное мнение: тестовых кандидатам не давать.
Полноценное код-ревью занимает много времени, интервьюерам просто не дадут его тратить. А время кандидата никто не считает. Свинство, ага.
Сам я тестовые не стану делать за тем редким исключением, когда просто интересно сделать "для себя". При этом не всегда отсылаю сделанное результаты. Именно потому, что добиться внятной обратной связи почти невозможно.
А по поводу обратной связи именно на интервью, мне кажется, что надо ее спрашивать определенном ключе.
Попробуйте спрашивать "а какие книги вы бы порекомендовали", или "как вы бы мне посоветовали развиваться" без привязки к результату.
К примеру, интервьюеру гораздо легче будет дать вам ссылку на Марка Симана с его "Внедрением зависимостей", чем сказать, "вы нам не подходите потому что нет знаний IoC/DI"
Если вы считаете, что отказ был из-за человеческого фактора, почему бы не попробовать с человеком-пауком? Вдруг его ревьювить будет другой человек, и вам повезет?
Или есть какие-то штрафы за то, что ваше изменение не пропустят?
PS. а вообще иконки - огонь!
Лично я все минусы (которые заметил) получил за комментарии. Корректные, не нарушающие правил приличия. Но - отличающиеся от мнения минусующих.
Я понимаю, что наказание за комментарии должно вызывать реакцию вида "семь раз отмерь - один напиши".
Но по факту получаем "семь раз отмерь и... пройди мимо".
Не хотел бы. Но увы, это более чем реально. Наши hr, например, сломали кодировку, когда решили в эксельке заполнить данные о ЮЛ.
Я не утверждаю, что фигак-фигак и в продакшен - правльно. Я привел крайний, редкий, пограничный пример, когда скорость важнее всего, и когда это оправдано.
Если вы разрабатываете софт для марсохода стоимостью 10млрд , который должен еще уметь дистанционно самообновляться - там, вероятно, будут другие приоритеты.
Я утверждаю, что нет догм.
Разумеется, нарушать "общепринятые" нормы можно только тогда, когда у вас есть достаточный опыт в разработке и архитектуре. Когда вы точно знаете, что делаете, и зачем. И ответить на эти вопросы можно только выяснив потребности бизнеса.
Сначала моя задача - собрать функциональные и не функциональные требования (да, хорошо бы этим занимались специально обученные люди, но они есть не везде)
А потом уже предложить варианты решений. Не наоборот.
Потому что помимо надежности и сопровождаемости есть и другие аспекты.
И я пытался сказать, что корреляция других атрибутов качества с реальными потребностями часто не учитываются при разработке, и либо продалбываются, либо наоборот, бизнес платит за то, чтот не нужно.
Чую, вопрос с подвохом, но отвечу.
41 годик, тимлид.
Эх, боюсь, не донес я мысль.
Хотите пример из жизни?
Прямо сейчас ребята из Мин Цифры слепили на коленке поделку в виде csv файликов, куда кое-кто из нас сможет внести свои паспортные данные и отправить через Госуслуги.
Как считаете, в текущей обстановке им лучше наг...кодить обмен данными через csv, или же пару недель рожать "достаточно хорошее" решение, а потом еще пару недель его обкатывать? Ну там, с тестами, удобством развертывания и конфигурации?
Рабочий код сам по себе не является ценностью. Не может быть абстрактно "достаточно хорошего" кода. Как и "плохого". Он важен как инструмент для решения бизнес-задач. Что нормально, а что нет, диктуется целом рядом нефункциональных требований и ограничений.
Разработчики постоянно попадают в ловушку своего прошлого опыта, в ловушку своего "знания" как на самом деле надо разрабатывать. Кто-то стремится к идеалу, кто-то к золотой середине качества. Но даже такие, казалось бы, важные атрибуты качества, как эффективность, надежность, сопровождаемость не являются безусловно важными.
Потребности бизнеса диктуют, какой должна быть система. А не наоборот.
Я бы добавил еще пункт про то, что в разработке нет догм. И бизнес платит, чтобы его проблему решили наиболее эффективным способом. Не "правильным", а эффективным.
Если вам хочется написать микросервисное распределенное докер-кубер-чудо - бейте себя по рукам линейкой. Если хочется многопоточный монолит - тоже бейте. Тоже линейкой. И за код с душком бейте. А за идеальный, структурированный, понятный, легко поддерживаемый, покрытый тестами, документированный код бейте молотком.
Потому что идеальный он только в вашей голове и только по вашему мнению. А за эту виртуальную идеальность бизнес заплатил реальными деньгами. Реальным временем. И не факт, что вот это все было действительно нужно. Особенно, когда вы перейдете на другой проект или в другую компанию.
Сначала сходите к бизнесу, и поймите его боль. Вы работаете, чтобы эту боль облегчить.
Не возьму смелость говорить за общество, но я радикально отрицательно отношусь к самой операции.
А к пациентам, ее проводящим, отношусь по-разному в зависимости от их мотивов. Если усреднить, то из всех чувств преобладает жалость.
Зачастую проблема не в том, что слишком рано или поздно или еще как-то.
Проблема в том, что идея и реализация - разные вещи. Даже, если идея на 146% стоящая, ей тяжело дожить даже до стадии прототипа. А уж перенести идею в производство - это из разряда фантастики.
У меня тоже есть история красивой идеи.
Лет так 20 назад, когда появились относительно доступные китайские светодиоды, я подумал, а почему бы не совместить мобильник и фонарик? С лампой накаливания, идея, понятно, глупая. А вот с нормальным светодиодом должно взлететь!
Пообщался с отделом закупок на работе (а наша фирма паяла и программировала всякое из китайских запчастей), я выделил из своей студенческой зарплаты 16 баксов за два светодиода и пару месяцев спустя получил чудо техники. При зарплате 60 баксов это было болезненно, но чего не сделаешь ради идеи!
Немного работы сверлом и паяльником, и я присобачил светодиод к плате своего Alcatel. Увы, это был глючный Alcatel, на Nokia денег не было. Далее сделал в корпусе две дырочки, через одну вывел кнопку выключателя, черед другую торчал светодиод.
Вуаля!
У меня оказался гаджет, опередивший время. Телефон с фонариком!
Но дальше вау-эффекта среди друзей дело не пошло.
А теперь, как всем известно, практически невозможно найти телефон без фонарика.
Вы привели пример, когда в туалете хорошо, а в целом все плохо. Да такое бывает.
Но смотреть туалеты (а также кухню) все же надо. Мне еще не встречались случаи, когда в клозетах была бы разруха, а во всем остальном царил бы порядок.
Приблизительно так я и сделал. Пробежался по всем (разрабы, аналитики, тестеры, эксплуатация), собрал их наболевшие места, изучил документацию, ознакомился с кодом, и преподнес начальству список наиболее критичных проблем.
Составили с начальством план.
Даже договорились с бизнесом 30% времени уделять техдолгу.
Наоборот, рефакторинг (неважно, кода или процессов) приводит к некой временной нестабильности. Если мы угадали с рефакторингом - ок, потом станет лучше. Но в моменте нормальный сон исчезает)
А по поводу переработок... задачи бизнеса никто не отменял. Так что приходится одновременно и технически развивать проект, и бизнес удовлетворять. Теми же ресурсами. И теперь надо попасть не только в бизнес-цели, но и в технические цели. То есть вместо одной морковки сзади появилось две.
Да, через несколько месяцев работы спать я стал больше. И успевал заниматься техническим развитием. Но к тому моменту уже понял, что больше не могу и не хочу быть локомотивом. Которому больше всех надо, и который всегда крайний.
Изначально это виделось как повышение.
Пришел к начальству за деньгами. Предложили дать денег, но с роли тимлида без команды, который в одиночку пилит не сильно нужный бизнесу проект, перейти на роль тимлида с нормальной командой, которая пилит критичный проект. Там как раз тимлид увольнялся.
Challenge и все такое, подкрепленный 40% ростом зп. А у меня большая семья, деньги нужны.
А проект оказался совсем не таким, как в рассказах начальства. Но я думал, что "втянусь", что все разрулю, что смогу все изменить. Тимлид я или не тимлид? Это ведь моя работа. Мне за это платят. Чтобы я решал проблемы.
Через год и правда, многое изменилось. Меня стали будить в 3 раза реже. Но я уже выгорел.
По итогу, "бенефит" вижу в том, что нехило так прокачался как тимлид.
Что помогло устроиться на нынешнюю работу, еще раз на 40% повысив доход (это с учетом ежегодных премий)
Прокачался настолько, что через 3 месяца на новой работе увольняющийся техлид предложил занять свое место.
Хотя я и отказался, но было приятно.
Именно так.
Этот тимлид сломался, несите следующего.
Но моя совесто чиста.
Хотел сначала сменить проект, на 1on1 недвусмысленно сказал, что в этом аду выдержу не больше месяца. Услышали, вызвали к вышестоящему, наобещали светлое будущее.
Через месяц все осталось, как прежде. И я пришел с оффером.
Тут сразу появилась возможность перевестись на другой проект с завтрашнего дня, но было уже поздно.
А по моим наблюдениям все ровно наоборот. На прошлом месте работы за год увеличили штат на 30%, набрав стажеров и джунов.
Потому что мидлов, а уж тем паче синьоров, искать доооолго, и они дорогиииие.
На текущей работе, когда я пишел к начальству с пожеланиями увеличить команду, мне настоятельно советуют взять джуна-разраба, которого буду натаскивать. И взять джуна тестера, который в тандеме с синьором погрузится в проект, а синьора через 3 месяца заберут.
Так что потребность в джунах и даже стажерах велика. Что, конечно, не отменяет серьезного отбора при трудоустройстве.
Все в мире относительно.
Вот я - относительно жизнерадостный тимлид.
Пол-года назад я был грустным тимлидом. Отвечал за business-critical проект, который падал, как сосульки по весне. Меня будили по ночам. Меня вспоминали на каждом разборе инцидентов с CTO. Диалог с бизнесом напоминал картинки с совой. Разработчики достались от предыдущего тимлида, скажем так, не сильно мотивированные и каждый со своими тараканами. Проект сменил трех тимлидов за 4 года. Я кодил по ночам, потому что днем бегал в мыле и разруливал проблемы, ничего не успевая. Я боялся своего телефона. Я просыпался от кошмаров, и не мог понять, это мне приснилось, или сервер по-настоящему лежит.
А сейчас у меня все как у героев этой статьи.
То есть - относительно хорошо.
А жизнь-то налаживается.
Что скорее всего говорит о необходимости прокачивать это умение. Отказывать так, чтобы и отношения сохранить, и свои интересы отстоять.
Я - тимлид, и товарищи из команды, бывает, говорят "нет" таким образом, что майка заворачивается. Если они говорят обоснованно, я "прикрываю" их от бизнеса. Говорю, что я понял. Нет - значит нет. Но бизнес не поймет. Давай сядем, обсудим, как нам это до них донести. А потом иду доносить, апеллируя к тому, что "да" принесет денежные/репутационные потери, а "нет" откывает возможность других решений. И предлагаю компромисс, или альтернативу, как нанести компанти максимальную прибыль.
Да, прокатывает не всегда. Но чаще, чем у чистых технарей, когда они пытаются сказать "нет" напрямую.
Вы конечно извините, но если интервьюер через час технического собеседования не знает, подходит ли кандидат - то он никудышний интервьюер. Более того: если не подходит (а таких большинство), это в 80% случаев понятно уже минут чрез 15.
Другое дело, что требуется соблюдать правила игры. Если культ найма требует религиозных ритуалов - "behavioral interview", "coding interview", "system design interview", никуда интервьюер не денется. Будет сидеть, раздувая щеки, уже зная, прошел кандидат или нет.
Счастливчик! Жсоны - это роскошь. Я вот после Физтеха эксельки перекладываю. И это имея за плечами 20 лет разработки.
А если серьезно, у Физтеха есть один серьезный изъян: вам внушают, что вы особенный. Если демонстрируете успеваемость, или, не дай Бог, призовые места на олимпиадах, вас всячески пестуют и поддерживают миф о вашей уникальности.
А после выпуска вас накрывает когнитивный диссонанс и фрустрация, потому что жизнь устроена по-другому.
Не поймите меня неправильно, вышка лично мой мозг прокачала до максимума. Сделала меня - мной. Высококвалифицированным хорошо оплачиваемым специалистом.
Но путь был тернистым.
Не хотел бы набрасывать по поводу тестовых заданий... Но мое сугубо личное мнение: тестовых кандидатам не давать.
Полноценное код-ревью занимает много времени, интервьюерам просто не дадут его тратить. А время кандидата никто не считает. Свинство, ага.
Сам я тестовые не стану делать за тем редким исключением, когда просто интересно сделать "для себя". При этом не всегда отсылаю сделанное результаты. Именно потому, что добиться внятной обратной связи почти невозможно.
А по поводу обратной связи именно на интервью, мне кажется, что надо ее спрашивать определенном ключе.
Попробуйте спрашивать "а какие книги вы бы порекомендовали", или "как вы бы мне посоветовали развиваться" без привязки к результату.
К примеру, интервьюеру гораздо легче будет дать вам ссылку на Марка Симана с его "Внедрением зависимостей", чем сказать, "вы нам не подходите потому что нет знаний IoC/DI"
Причин может быть много.
Например, они хотят посмотреть пул найденных кандидатов, а потом выбрать.
Или они сделали кому-то оффер, он отказался (и это заняло некоторое время), а вы были следующем в списке.
Или там начальнику было не до вас.
Или у них процесс согласования дико сложный.
Или СБ долго проверяло.
Любая из этих причин в сочетании с неопытностью HR - и вот вас держат в полном неведении.