Да никуда мы не исчезаем! Как работали, так и работаем.
А то, что нужно вечно бежать чтобы остаться на месте - тоже некоторое преувеличение. Если просто найти нормальную работу, и просто работать на совесть (не на отвали, лишь бы не уволили, но и не сжигать себя, работая по ночам) то развиватсья будешь просто выполняя свои обязанности.
С возрастом, знаете ли, приходит осознание, что время - это не бесконечный ресурс. И если его оптималнее тратить, если научиться фокусироваться на наиболее важном, то и на работе будешь успешным, и в личной жизни ни себя, ни близких не обделишь.
Наверное, советы подходят для джунов, которым нечем наполнить резюме.
А для сформировавшихся специалистов только гитхаб может быть полезен (или хотя бы не вреден). Остальное или информационный мусор (хобби, участие в конференциях) либо факты, которые могут трактоваться как в плюс, так и в минус (сертификаты, например).
Так что я бы семь раз подумал, прежде чем тащить все это в свои достижения.
Если в команде окажутся раздолбаи, они его быстро подведут.
Да, действительно, есть такие риски. Тогда по отношению к раздолбаям придется применять меры разной степени жесткости, пока они не исправятся. Ну или пока их не удастся выдавить из команды. И хотя это деструктивно для остальной команды, но лучше это сделать, пока раздолбаи своим поведением не разрушили команду целиком.
В современном менеджменте подобный подход считается глубоко неправильным
Современные тренинги на современных менеджеров (за редким исключением) заточены под легко заменяемых линейных исполнителей. С флером ориентацией на прибыль любой ценой. Таки тренинги банально лучше продаются.
А вот в айти они, мягко скажем, применимы не всегда. С точки зрения бизнеса замена специалиста бьет как по деньгам, так и по срокам. А еще нехватка спецов в среднем по отрасли приводит к тому, что айтишники могут выбирать. Становятся более "капризными". То есть, эффективный менеджер, который решит "построить" айтишников, получит ответ в стиле "не нравится ваш зять - любите вашу дочку сами". С последующим уходом команды в закат и гарантированным срывом сроков.
PS я говорю "в среднем", что подразумевает наличие исключений типа лидеров рынка, которые могут за счет бренда и (иногда) денег заставить айтишников изображать белок в колесе. Но не всех и не очень долго.
Вы так пишите, как будто хороших начальников не существует.
Я соглашусь, что невозможно быть хорошим для всех. Но если у начальника приоритет создать свою команду, а потом беречь и заботится о своих людях, даже в ущерб сиюминутным взбрыкам бизнеса, то с ним будешь как у Христа за пазухой. Девиз таких - "воздвигаю".
За 20-и летний опыт я видел двух таких. Под одним проработал 8 лет (работал бы и дальше, да фирма закрылась), второй был тимлидом соседней команды с нулевой текучкой за 10 лет.
Так что есть начальники, хорошие для подчиненных, есть. Хотя плохих, понятно, больше.
А подскажите, что вас настолько привлекло в историческом здании с КГБ, что вы решились на снос несущих стен? Неужели абсолютно все другие варианты проигрывали этому?
Так решил ревьюер, человеческий фактор здесь тоже влияет.
Закидывать такую иконку на ревью в 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 года. Я кодил по ночам, потому что днем бегал в мыле и разруливал проблемы, ничего не успевая. Я боялся своего телефона. Я просыпался от кошмаров, и не мог понять, это мне приснилось, или сервер по-настоящему лежит.
Да никуда мы не исчезаем! Как работали, так и работаем.
А то, что нужно вечно бежать чтобы остаться на месте - тоже некоторое преувеличение. Если просто найти нормальную работу, и просто работать на совесть (не на отвали, лишь бы не уволили, но и не сжигать себя, работая по ночам) то развиватсья будешь просто выполняя свои обязанности.
С возрастом, знаете ли, приходит осознание, что время - это не бесконечный ресурс. И если его оптималнее тратить, если научиться фокусироваться на наиболее важном, то и на работе будешь успешным, и в личной жизни ни себя, ни близких не обделишь.
Наверное, советы подходят для джунов, которым нечем наполнить резюме.
А для сформировавшихся специалистов только гитхаб может быть полезен (или хотя бы не вреден). Остальное или информационный мусор (хобби, участие в конференциях) либо факты, которые могут трактоваться как в плюс, так и в минус (сертификаты, например).
Так что я бы семь раз подумал, прежде чем тащить все это в свои достижения.
Да, действительно, есть такие риски. Тогда по отношению к раздолбаям придется применять меры разной степени жесткости, пока они не исправятся. Ну или пока их не удастся выдавить из команды. И хотя это деструктивно для остальной команды, но лучше это сделать, пока раздолбаи своим поведением не разрушили команду целиком.
Современные тренинги на современных менеджеров (за редким исключением) заточены под легко заменяемых линейных исполнителей. С флером ориентацией на прибыль любой ценой. Таки тренинги банально лучше продаются.
А вот в айти они, мягко скажем, применимы не всегда.
С точки зрения бизнеса замена специалиста бьет как по деньгам, так и по срокам. А еще нехватка спецов в среднем по отрасли приводит к тому, что айтишники могут выбирать. Становятся более "капризными". То есть, эффективный менеджер, который решит "построить" айтишников, получит ответ в стиле "не нравится ваш зять - любите вашу дочку сами". С последующим уходом команды в закат и гарантированным срывом сроков.
PS я говорю "в среднем", что подразумевает наличие исключений типа лидеров рынка, которые могут за счет бренда и (иногда) денег заставить айтишников изображать белок в колесе. Но не всех и не очень долго.
Вы так пишите, как будто хороших начальников не существует.
Я соглашусь, что невозможно быть хорошим для всех. Но если у начальника приоритет создать свою команду, а потом беречь и заботится о своих людях, даже в ущерб сиюминутным взбрыкам бизнеса, то с ним будешь как у Христа за пазухой. Девиз таких - "воздвигаю".
За 20-и летний опыт я видел двух таких. Под одним проработал 8 лет (работал бы и дальше, да фирма закрылась), второй был тимлидом соседней команды с нулевой текучкой за 10 лет.
Так что есть начальники, хорошие для подчиненных, есть. Хотя плохих, понятно, больше.
Звучит как детектив!
А подскажите, что вас настолько привлекло в историческом здании с КГБ, что вы решились на снос несущих стен? Неужели абсолютно все другие варианты проигрывали этому?
Если вы считаете, что отказ был из-за человеческого фактора, почему бы не попробовать с человеком-пауком? Вдруг его ревьювить будет другой человек, и вам повезет?
Или есть какие-то штрафы за то, что ваше изменение не пропустят?
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 года. Я кодил по ночам, потому что днем бегал в мыле и разруливал проблемы, ничего не успевая. Я боялся своего телефона. Я просыпался от кошмаров, и не мог понять, это мне приснилось, или сервер по-настоящему лежит.
А сейчас у меня все как у героев этой статьи.
То есть - относительно хорошо.
А жизнь-то налаживается.