Comments 80
И направлять жалобы клиентов напрямую на разработчика тогда, чтобы он понимал что хотят клиенты. Круглосуточно. В 3 часа ночи звонок клиента "я тут нажал а оно пропало куда нажать чтобы не пропало?" очень будут мотивировать к вовлечению в проект. Когда разработчик отделен от клиентов двумя линиями техподдержки и тестировщиками это совсем не то, так скучно.
Заставь поработать на проде
Заставь уронить прод
Сделай виноватым
Выгони его
Profit!
Вот, не правда ваша. Если работник прошаренный и всё хорошо задокументировал, написал нужные служебки и получил письменные распоряжения - в течении 3 месяцев подаёт в суд, выигрывает его, восстанавливается и получает всю недоплаченную среднемесячную зарплату (ставка + премии) за всё время вынужденного простоя.
Задачи которые можно только на проде отладить не только джуна могут заставить уволиться 😂
Ох уж эта боязнь релизить в продакшен.
if it hurts, do it more often.
В нескольких компаниях где я работал было правило: любой разработчик обязан релизнуть что-то полезное в продакшен в свой первый день работы. Даже если это новичок. Точнее не так. Особенно если это новичок.
И все это за первый день работы! Я поражаюсь над продуктивностью ваших новичков!
Вы серьезно пишите интеграционные + юнит тесты на каждый коммит?
У вас локальное окружение не поднимается одной командой?
Нет CI/CD?
Ревью десяти строк занимают несколько дней/недель потому что всем некогда?
Поздравляю, вы работаете в бюрократическом болоте, да еще и, похоже, гордитесь этим.
Мой комментарий не о продуктивности новичков, а о том что вредно с первого дня прививать боязнь деплоя.
Вы по ссылке хоть сходили?
Вы просто объяснили неоднозначно. А так конечно хорошая практика, и не только для новичка. Пуская ченьж незнакомца в прод, они и для себя подтверждают, что все проверки и процессы в пайплайне работают как часы.
вы работаете в бюрократическом болоте, да еще и, похоже, гордитесь этим
Все есть и да, пишем (если они еще не написаны). Потому что ошибаются все и на самых глупых местах и при тестировании люди тоже ошибаются, а я работал в таких компаниях, где одна ошибка на проде может стоит больше чем любой разработчик заработает за всю жизнь в любой точке Земли.
Вы по ссылке хоть сходили
Только там нет ничего про боязнь деплоя, а про то что сложные и болезненные вещи нужно делать поэтапно (что правильно). Имхо, но деплой крошечными пакетами без нормального регрессионного тестирование и определенных этапов проверок — не самое лучше решение.
вредно с первого дня прививать боязнь деплоя
Но вредно и обратное — пофигиское отношение к качеству того, что ты выдаешь на прод (ну если на прод, конечно, не всем, включая клиента, не наплевать). Есть определенные этапы и проверки, без которых получается программирование фиг-фаг и в продакт. Что еще хуже.
а я работал в таких компаниях, где одна ошибка на проде может стоит больше чем любой разработчик заработает за всю жизнь в любой точке Земли.
Прям вижу как вы кулаком себя в грудь бьете.
В 99% софта оценка стоимости ошибки безмерно завышена неуверенными в себе программистами. Гораздо важнее иметь возможность быстро обнаружить и исправить ошибку, чем наивно пытаться не допускать их. Ошибки неизбежны т.к. появляются на всех этапах разработки, в том числе и тех где программисты не вовлечены вовсе.
Более того, есть проблемы которые вы никогда не исправите. Если юзер идет на ваш сервис с мобильного интернета, у него в любой момент может пропасть связь и винить он будет вас. Можете сколько угодно обмазываться юнит-тестами, но юзеру это не поможет. Если у меня есть 0.5% юзеров у которых возникают проблемы, и я могу ускорить разработку в разы заплатив за это поднятием этого показателя до 0.6%, то я не задумываюсь это сделаю.
Компании которые стоят миллиарды долларов каким-то образом умудряются деплоить десятки-сотни раз в день: Etsy, Netflix, Uber, Airbnb, Github. И, открою вам секрет, они столько стоят не вопреки их культуре деплоя, а благодаря ей.
Ваша неспособность построить эффективный процесс разработки это не повод для гордости. Все барьеры которые вы построили из-за страха нанести вред, точно также являются барьерами для принесении пользы. Представьте себе, пользователи ценят когда зарепорченый баг фиксится в течение 24 часов гораздо больше чем мифический софт без багов.
деплой крошечными пакетами без нормального регрессионного тестирование и определенных этапов проверок — не самое лучше решение.
Регрессионное тестирование вполне себе может быть автоматизировано и не требует новых тестов на каждый коммит.
К слову, отсутствие конкретики наглядно демонстрирует ваш уровень: "нормальное" тестирование и "определенные" этапы проверок.
Но вредно и обратное — пофигиское отношение к качеству того, что ты выдаешь на прод
А вот и ожидаемый strawman argument подъехал. Я ведь ни слова не сказал о пофигистском отношении, вы его сами придумали. Потому что если вы неспособны построить эффективный цикл релиза, значит его не существует, верно?
Гораздо важнее иметь возможность быстро обнаружить и исправить ошибку, чем наивно пытаться не допускать их.
Вообще, места разные бывают. Может, там писался какой-нибудь торговый биржевой робот. Где если уж он купил чего-нибудь не за ту цену и не вовремя - то "обнаружить и исправить" эту покупку уже не получится.
А если софт работает с реальным физическим миром, управляя дорогой и мощной железкой размером с небольшой дом или квартал - то угробленную железку и нанесенные убытки тем более быстро исправить не получится. (для примера, например, статья недавно была.
Если у меня есть 0.5% юзеров у которых возникают проблемы, и я могу ускорить разработку в разы заплатив за это поднятием этого показателя до 0.6%, то я не задумываюсь это сделаю.
Теперь я понимаю откуда торчат ноги у практики, когда в день релиза сервера не справляются с нагрузкой. Просто кто-то решил, вместо того, чтобы арендовать на первое время Х+1 мощностей, поднять процент негатива на пару процентов. Ну а чаво такого? Потерпят.
Опять же где тут грань и кто ее проводит? Как определить момент с которого скорость разработки перестает что-то значить на фоне недовольства клиентов? Как не упустить точку невозврата, после которой уже не вернуть клиента назад?
. Представьте себе, пользователи ценят когда зарепорченый баг фиксится в течение 24 часов гораздо больше чем мифический софт без багов.
И абсолютно не ценят, когда фикс одного бага, добавляет три новых. "Спасибо - стало -хуже" (с). В итоге вы можете хоть 100 раз успешно фиксить баги за 24-часа, но запомнят и будут припоминать вам 101-й случай, когда фикс пошел не по плану и вытащил на свет другие баги.
когда в день релиза сервера не справляются с нагрузкой.
Опять таки, "If it hurts, do it more frequently, and bring the pain forward".
Если у вас в культуре релизы десятки раз в день, вы набьете шишки на раннем этапе.
когда фикс одного бага, добавляет три новых
Очередной strawman. Но даже если я его приму, что лучше: изредка пофиксить один баг и добавить три новых, но при этом фиксить остальные баги за 24 часа. Или фиксить баги пачками раз в месяц?
Но даже если я его приму, что лучше: изредка пофиксить один баг и добавить три новых, но при этом фиксить остальные баги за 24 часа. Или фиксить баги пачками раз в месяц?
Зависит от продукта и типа бага. Если это не критикал, то разумнее собирать пакет фиксов и релизить их условно раз в месяц, когда клиенты знают, что такого-то числа релиз версии/патча и возможно что-то будет не так.
каким-то образом умудряются деплоить десятки-сотни раз в день
Я даже скажу как, когда у вас тысяча сервисов и тысяча команд (в компании где 10 тыс разработчиков это нормально, многие из них вообще почти никак не связаны с друг другом) — если каждая команда делает релиз раз в 2 недели — у вас будет десятки-сотни деплоев в день.
Я ведь ни слова не сказал о пофигистском отношении, вы его сами придумали.
Но тут же его подтвердили
и я могу ускорить разработку в разы заплатив за это поднятием этого показателя до 0.6%, то я не задумываюсь это сделаю
Причем вы не спросили бизнес во сколько им обойдется эти 0.1%. Я работал в нескольких компаниях с выручкой в миллард $ в год (например в 2017 тут), 0.1% это миллионов $ только прямых убытков.
И это не считая, что в выскоконкурентном бизнесе если пару раз сайт у пользователя не откроется или будет тормозить — он уйдет к конкуренту с друзьями и родствениками. И если у вас стабильная проблема у всего 0.1% пользователей каждый день, это не проблемы у 0.1% пользователей — вы теряете по 0.1% пользователей каждый ДЕНЬ или потеряете больше ТРЕТИ ваших пользвователей за год.
Регрессионное тестирование вполне себе может быть автоматизировано и не требует новых тестов на каждый коммит.
Может, но все равно должно оставаться ручное хотя бы самых важных сценариев. Потому что ошибка может быть и в автоматических тестах и они покажут все зеленым, а у вас вообще ничего работать не будет (такое на моей практике встречалось).
Etsy, Netflix, Uber, Airbnb, Github.
«Так чо ты меня своей шоблой пугаешь?!!»(с) из анекдотов.
Я не работал в Netflix и Airbnb, но я работал в компаниях из той же сфере и сопоставимы размерами (например, в trivago в год когда я работал была выручка 1 млд., против 2.5 млд. у Airbnb), поэтому статьи от этих компаний меня не впечатляют (открою вам небольшой секрет — обычно то, что пишется на публику и то что и как работает на самом деле в крупных публичных команиях — две очень большие разницы, на статьях-то у всех единороги и феи летают).
Представьте себе, пользователи ценят когда зарепорченый баг фиксится в течение 24 часов гораздо больше чем мифический софт без багов.
Представьте условный букинг ком, которые не дает вам никак забронировать гостиницу, которая вам нужна вот прямо сегодня (и которую вот вот кто-то другой забронирует). Будете ли их ценить больше если они пофиксят этот баг в течении 24 часов, после (утрировано) ночи на скамейке в парке?
когда у вас тысяча сервисов и тысяча команд
Зависимости сервисов друг от друга никуда не пропадают. Да, существуют изолированные кластеры, но внутри каждого полно зависимостей. И релизить каждый день все равно получается.
в выскоконкурентном бизнесе если пару раз сайт у пользователя не откроется или будет тормозить — он уйдет к конкуренту с друзьями и родствениками
Неспособность релизить быстро приводит к тому что вы не можете вовремя приспособиться к потребностями рынка, в отличие от ваших конкурентов. И в итоге конкурент купит вас за бесценок.
обычно то, что пишется на публику и то что и как работает на самом деле в крупных публичных команиях — две очень большие разницы
Мне нужно интервью с разработчиками записать чтоб вы поверили?
Или может вы все-таки поймете, что способность CTO построить процесс в котором новичок приносит пользу в первый день работы, это показатель вашего качества как CTO?
Вот вам еще пару ссылок: Asana, Intercom. Впрочем у вас мышление конспиролога, все вокруг врут. На самом деле все живут в болоте, просто вы самый честный. Что-то мне это напоминает... Ах да, "загнивающий запад".
Представьте условный букинг ком, которые не дает вам никак забронировать гостиницу, которая вам нужна вот прямо сегодня
Спасибо, посмеялся. Удивительно, что работая в Trivago вы вообще не понимаете как работает hospitality индустрия.
Booking.com - это как раз идеальный пример опровергающий вашу позицию. Ваша бронь на букинге вообще никак не гарантирует вам комнату. Она может не дойти до отеля, отель может быть overbooked, вашу комнату могут продать дважды, PMS может прилечь (как локальная так и cloud), CRS может тормозить, и т.д.. Это происходит тысячи, если не десятки тысяч раз за день. И букингу пофиг. И отелям пофиг. И вендорам пофиг. Это плохо, но это реальность.
Если бы Booking в отрыве от реальности пытался построить надежную систему без багов, он бы никогда не взлетел.
А что они там деплоят столько раз в день?
И точно верно что, то, что они деплоят по сто раз в день, означает, что те изменения которые они деплоят, не прошли релизный цикл?
Просто с автомобильного конвеер тоже по сто машин в день сходит, это не значит что, их до этого несколько дней не собирали при движении по конвееру
Видимо, он в майкрософте работал.
В нескольких компаниях где я работал было правило: любой разработчик обязан релизнуть что-то полезное в продакшен в свой первый день работы. Даже если это новичок. Точнее не так. Особенно если это новичок.
А затем самолет падает в море, потому что пересек мередиан.
Да можно советовать что угодно. Проектная работа и так ад, зачем вообще идти на такое. Хотите ощутить себя сотрудником макдональдса - идите уж тогда сразу в мак.
Да и вообще советы из статьи дискредитируют только работодателя. И хорошо если человек уйдёт молча, а не скинет гневное письмо на начальника директору компании со всеми переписками, примерами диалогов или записями на дистофон, а потом ещё и интернете оставит отзыв с указаниям фамилий тех кто его травил.
В начале прямо мой первый проект 10 лет назад в точности описан. :) Кроме пункта про ментора. Его вообще не было. :) У меня потом долго не проходил синдром самозванца.
Как выбрать для новичка такой проект, чтобы он уволился
6/12 Прямо сейчас на первом месте работы, но проект второй.
Плюс еще вот это habr.com/ru/post/681786/#comment_24619286
Ну вообще для джуна правильно. Но если нанимают скажем сеньора, когда в команде максимум ещё один есть, а то и никого нет? Тогда ожидается, что он как раз и будет разгребать хаос который образовался до того, как его наняли.
Ну и даже миддлу задачи будут давать сразу довольно заковыристые, как раз может такие, против введения которых протестовал сеньор, т.к. понимал возможности команды. А его и дадут в менторы миддлу, т.к. больше некого. И долго он менторстовать не будет, т.к. ожидает , что миддл не джуниор, и сам разберётся после пары наводящих подсказок.
Конечно, менторов не было. И рабочее место никто не готовил. У тебя нет необходимого монитора/прибора? Пиши служебку. Не знаешь как писать и какой конкретно прибор? Спроси. Не знаешь, у кого? Спроси у кого угодно, у кого спросить. Тебе что тут, детский сад?
Задач должно быть несколько, не связанных друг с другом и вообще из разных сфер: кодинг, написание документов, желательно странных, типа заключения о технологичности, сбегать на производство просто курьером, подписать чужие документы у вышестоящего начальства, поучаствовать в настройке прибора. Приоритеты задач должны меняться неожиданно и произвольно. Исполнителю об изменении приоритета сообщать так: «Какого хрена ты все еще занимаешься фигней и почему все еще не сделана мегаважная вещь?» Через день-два повторить, изменяя «фигню» и «вещь».
Вишенка на торте — когда человек почти добирается до решения задачи, надо ее отобрать и отдать другому. И когда этот другой пройдет последние шаги и «добьется» результата, надо сделать выговор: «Вот ты не смог, а он — смог!»
И по опыту командировок и неформального общения с коллегами из предприятий смежников и заказчиков складывается ощущение, что на гос и «бывших» гос (ныне АО, ПАО и т. д.) околоайтишных фабриках типа КБ это норма в принципе.
Прямо подборочка шизофреногенных паттернов :)
Оооо, это же моё текущее место работы!
Задач должно быть несколько, не связанных друг с другом и вообще из разных сфер
Вспомнил, как на первой работе в Израиле шеф выдал мне задание - позвонить и заказать несколько системных блоков, и договориться о цене пониже, т.к. мы закупаем побольше. На это я ему объяснил, что новому репатрианту, очень слабо говорящему на иврите, такие задания давать странно, а уж программисту, которого вы наняли, как программиста, а не закупщика, вдвойне страннее. Объяснение вышло очень доходчивым, больше таким меня не донимали.
О, почти 100% попадание, прям наше КБ в составе ПАО. Скажите, а работа программиста в других местах сильно отличается, или это все мифы? А то после института это пока единственное мое место работы.
Тоже работал в КБ. Из КБ, как и из другой организации, если там происходит хоть 25% описанного надо срочно уходить. Есть компании, где можно гораздо производительнее проводить рабочее время.
КБ - это что? "Красное и белое"?
Это норма в принципе на гос не только в айти и околоайти. Третий абзац это вообще классика: "универсальные солдаты" и внезапно возникающие задачи которые должны были быть решены уже завтра.
Потому и плетемся по производительности и результатам в самом конце.
У тебя нет необходимого монитора/прибора? Пиши служебку. Не знаешь как писать и какой конкретно прибор? Спроси. Не знаешь, у кого? Спроси у кого угодно, у кого спросить.
Конкретно эта часть является отличной практикой для работы с "не IT" отделами: кадровиками, бухами и прочими складами. Там работают совершенно дикие люди, у которых нет ни СУПа, ни багтрекера, ни даже четкого плана действий для ежемесячных процессов.
Впрочем, и в IT полезно, когда надо пролезть через 3 команды в 4-е дерево подчинения, что бы выбить фикс чего-либо или узнать как оно на самом деле работает.
PS. Тоже работал в подобном заведении после выпуска, правда частном.
Установите новичку на рабочую машину Linux или MacOS, если он до этого имел дело только с Windows.
Хех, на мой первой работе была тоже windows 10, как и дома. Вот только поверх нее нужно было установить кучу SDK, DDK, Visual studio определенной версии и в определенной конфигурации и убедиться, что стоит правильное обновление винды. А чтобы обязательно протестировать на Win7 нужно было в виртуалке всё это повторить + накатить пару SP. Даже когда через год я себе все переустанавливал, то всё равно на правильную установку всех этих компонентов ушло пол дня. Инструкции были, но там как всегда не было половины нужных пунктов. Но с другой стороны на легаси-ентерпрайз проекте, взаимодействующему с определенным железом ничего другого и не стоило ожидать.
И ограничить права на всё. Захотел подключить флэшку - пиши заявление на директора, СБ и на всякий случай главбуха.
И внутрение сервисы работающие только в MS IE.
Преподаватель в универе рассказывал, как он проходил практику на каком-то целлюлозно-бумажном комбинате. Он и в возрасте-то сохранил какую-то юношескую порывистость в движениях и мыслях, а тогда, - молодой инженер, только с ВУЗа, просто горел жаждой деятельности. Интересовался всем процессом, везде проявлял активность и, видать, чтобы не мешался, главный инженер поставил ему задачу:
- Вот, мол, на валах идет бумажная лента, что-то с ней там происходит, неважно, а в конце она наматывается в огромные рулоны. Все бы хорошо, но есть проблема, - бумага все-таки, могут быть небольшие разрывы, они потом расползаются, лента рвется, оборудование встает, показатели падают, всех дрючат, ужас. Ты молодой, мозги свежие, давай, придумай приблуду какую-нибудь, чтобы регистрировала факт образования разрыва, а потом бац, и автоматически аккуратно резаком кружочком его вырезала. Тогда вся лента не порвется, машина не встанет, а что в полотне дырки будут это не страшно, все равно рулон в нарезку пойдет.
Воодушевленный важностью и масштабом задачи, молодой начал рыть и конструировать. Как факт образования разрыва зарегистрировать? Механически или фотодатчиков наставить? Фотодатчики технологичней, но разрешающая способность... В три ряда что-ли ставить, а где? Резать-как? Резак штука простая, но лента-то движется, нужна синхронизация. И схема нужна, чтобы механизм адресно смещать к месту трещины. Питание еще. И место под все это.
В общем, погряз он во все это, пока какой-то старый инженер над ним не сжалился.
- Ты видел хоть раз как рвется лента, если там хоть мельчайшая трещинка образуется? На валу большое натяжение, чуть повредил, и все, в долю секунды треск и полотно пополам, и ничего ты не успеешь и зарегистрировать, а уж вырезать... Остынь, в общем, пошутили и хватит.
Даже в уже достаточно преклонном возрасте, рассказывал эту историю преподаватель, с некоторой обидой на поставившего ему эту тогда задачу. "Меня он тогда крепко подставил, да... А вы, на будущее, всегда выясняйте условия и применение, прежде чем браться за дело."
Ну, совсем чтоб сложный был и ещё чтоб сам новичок был из робкого десятка.
Автор оригинала: Amir Rachum
Взял братишку индуса на работу, а потом понял, что он неприкасаемый..
Описан типичный совок. Так работают не только новички.
Существует риск, что новичок окажется сильнее всего этого, и-таки преодолеет весь этот бардак. Бюрократия очень мощное оружие в руках дотошного зануды) Тогда проблемы могут начаться у всех, кроме него самого.
Ещё добавляйте новичка во все совещания, которые даже не относятся к его задаче, так, на будущее
Начать работу, конечно, лучше с маленьких задач, главное, чтоб это не превратилось в бесконечный конвеер правки всякой фигни на года.
Хотя постойте, кажется, это уже было. Ах, да, конечно — в «Better Call Saul»…
Придумайте просто что-то суперслеожное
Многие (обычно опытные) инженеры склонны отвечать на вопросы потоками подробной информации и длинными театральными монологами о том, как вы пришли к текущей ситуации («Это давняя история, начавшаяся ещё в те времена, когда контроль версий был причудой для богатых...»). Говорите новичку то, что он должен знать и спрашивайте, хочет ли он узнать подробности. Или позвольте ему сначала завершить мелкую задачу, потом сообщите чуть больше контекста, когда у него уже будет понимание того, что же делает компонент.
Есть у нас один опытный работник, который "стоял у истоков", участник легендарного Переезда проекта с технологии Х на Y.
Так вот, он любитель сжать ответ до трёх-пяти слов. Причём, скорее всего, это уточняющие вопросы, которые не относятся к проблеме.
-У нас полетела аналитика, после релиза Х. Мы всё проверили, можешь ещё ты глянуть?
-икнку в меню починли?
-Да, ещё в прошлом релизе
-Хорошо
И молчит...
Иногда пишет не переключив раскладку. И ладно, я сам так иногда пишу, но я, блин, редактирую сообщения, а он - нет.
Как-то, в порыве благодатного огня не из благодатных отверстий, я даже написал переводчик "ghbdtn" -> "привет" (можно как декодировать, так и кодировать, пишите во второе поле).
Бодаться с ним не имеет смысла, т. к. работаем с ним раз-два в месяц...
А статья хорошая. Есть ещё добавить:
Не ведите документацию/тесты и подавляйте инициативы по созданию
Не делайте деплой на прод до 17:50
Давая концептуально новую задачу всегда спрашивайте точные сроки и сделайте так, чтобы их сдвиг означал головную боль всей команде
Первые два месяца пусть форматирует код вручную, чтобы чётко запомнил code style, принятый в компании
Лучше если каждый использует разные форматеры кода
При отсутствии штата (нанимаете первого), обязательно не нанимайте второго, но первому говорите, что скоро наймёте. Так-же не нанимайте сеньора, джуна/мидла хватит
Измеряйте продуктивность с самого старта работы сотрудника. Чтобы он видел в графе "продуктивность" 12% (привет, битрикс)
Первые 100% задач лучше всего давать по легаси коду для которого используются модифицированные легаси говно-библиотеки с которыми никто в мире, кроме 100 левых смельчаков с npm и не работал
Обязательно ставьте под сомнения решения новичка. Если вы не имеете компетенции - отлично! Это означает, что вы можете даже давать советы по реализации и долго отстаивать своё решение.
Главное в конце, когда уже вся команда привела по 10 аргументов, вы должны сказать "ладно, я не программист - вам виднее" и на следующий день всё это можно провернуть опять. Можно даже по той-же задачеУстановите трекер, чтобы нужно было нажимать на кнопку, когда сотрудник идёт в санузел. Не доведи Господи оплачивать сральное время по тарифу коддингово
Пусть время на выполнение задач
придумываетрассчитывает проджект, а не исполнительНазначьте несколько PM`ов для сотрудника и пусть они не согласовано фигачат задачи, соревнуясь в кол-ве огоньков в трекере
Не используйте популярные среди программистов таск-трекеры для своих программистов
Не покупайте лицензионный софт, программисты умные, они сами найдут софт
Не чистите компьютер перед передачей его новому сотруднику. Не меняйте логины и доступы. Пусть в гит пушит Олег, мы же знаем, что Олег уволился, значит, пушит Саня
А если всё-таки чистите - удалите важные компоненты помимо ненужных, не забудьте почистить реестр по туторам на ютубе
Запретите использовать докер для развёртывания проекта на машине для разработки
Никогда не согласовывайте API компонентов, которые делают разные разработчики
Лучшее время проверок задач для завтрашнего релиза - после 20:00, когда все уже дома
Написать в рабочий чат в 4 утра - это нормально
Никак не поощряйте инициатив по усилению безопасности продукта. Ну нашел уязвимость, разработал эксплойт и закрыл человек RCE с компрометацией учётных данных на платном сервисе за день и что тут такого? Кстати, кнопку так и не сдвинул?
Не тратьте время на актуализацию dev сервера
Если у сотрудника ДР - это хорошо. Значит, он будет работать с хорошим настроением
Никогда не проводите ретроспективы
Не отвечайте на запросы по рефакторингу
До беклога руки дойдут сами
В бизнес-процессы новый сотрудник вникнет сам
Если HR по какому-то глупому стечению обстоятельств всё-таки отправила пдфку со всем нужными сотруднику бизнес-процессами, то вам нужно им не следовать и делать круглые глаза всякий раз, когда новый сотрудник не угадал к кому идти по пдфке, а к кому "и так понятно, в пдфке устарело"
*При составлении этого списка пострадал один программист
Описан типичный способ работы в большинстве наших компаний.
Написать в рабочий чат в 4 утра - это нормально
Написать - это нормально, сам так делаю, что бы утром мучительно не вспоминать, что же я хотел спросить или сказать. Надо требовать немедленного ответа, что бы жизнь медом не казалась.
Отличная статья, спасибо.
Статья мне понравилась, автор разложил всё по полочкам понятно и доступно. Вспомнился случай на работе, когда вместо того, чтобы что-нибудь объяснить, все члены команды начинали орать на меня, хотя я не могла знать специфику работы компании и этого подразделения. Все эти тонкости объясняются начальством и другими членами команды, в том числе начальником отдела. Увы, мне пришлось учиться самой, наблюдая за другими. Я испытывала большой стресс. Поэтому так и не смогла завязать добрые отношения ни с одним членом команды. И я ушла, потому что хватит это терпеть. Не люблю, когда в рабочие отношение примешивается личная неприязнь. И необоснованное высокомерие.
Зато с другими отделами очень даже сдружилась, с сисадминами, саппортом. До сих пор с ними общаюсь. Весьма позитивные люди.
А говорят в бухгалтерии серпентарий...
Добавлю еще один вредный совет:
Почаще меняй ему проекты
По возможности, перекидывай его между проектами, желательно, с которыми он не работал. Не давай документации и не предоставляй куратора. Не оставляй новичку времени разбираться в чужом легаси коде. Так же, почаще говори, что он не справляется.
Какая прелесть из моей жизни начала 00-х в больших конторах.
И самое смешное, что всё это было не со зла.
В одной пришлось чинить модуль который писал год назад уволившийся человек. За это время весь проект ушёл вперёд и при вызове модуля всё красиво падало. Ну равновесию я его научил, а вот рассказать как же он должен по науке работать не смогли ни коллеги, ни отдел документации. В итоге циферьки считал, графики строил, не падал и ладушки. А ведь это были чьи-то зарплаты...
В другой дизайнеры несколько переоценили возможности железки и требовали невозможного для экрана 160х100 с четырьмя градациями серого. Отдел "системных программистов" ржал с "прикладных" как мы не умеет использовать то, что они сами для себя наворотили. На просьбу давать хотя бы раз в месяц отчёты как правильно использовать их поделки они важно отвечали: "у нас постоянно много меняется, на доки нет времени".
Итог? Обе две конторы сгинули в пучине времени. А я с той поры работаю только в маленьких конторах где такого бардака не может быть в принципе.
Как выбрать для новичка такой проект, чтобы он уволился