[Управление разработкой, Управление продуктом] 3 самых больших факапа разработчика (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В оригинальной статье на сайте Medium, хотя и написанной от лица мужского пола, можно сказать от библейского первого человека Адама, в пример топового разработчика приводится девушка, которая в 11 лет сделала свой сайт, а к 23-м годам стала миллиардером. Судя по тому, что у нас в компании девушки-разработчики – большая редкость (их всего две), а мы типичная IT-компания, для адаптации к местным реалиям пришлось превратить ее в парня. Получилось почти как у Киплинга. Помните, пантера Багира в оригинальных книгах был мачо-мальчиком, а в советском мульте превратился в супердевочку с голосом актрисы Касаткиной.
Все программисты знают истории топ-разработчиков, которые начинали программировать с юных лет, а в двадцать входили в списки богатых и знаменитых. Мы все любим эти истории, этих героев; их достижения в программировании нас вдохновляют и задают тренды. И когда дело касается решения проблемных задач по сложным алгоритмам и привлечения миллионов инвестиций на раунде A, такие специалисты, кажется, никогда не ошибаются.
Но реальность такова, что каждый разработчик, даже топовый, иногда ошибается, но исправляется. Разница – в цене ошибки; если облажается программист, под угрозой оказываются базы данных, такие потери могут стоить компаниям миллиардов долларов. Почему мы все так боимся косяков? Они как клеймо: никто не говорит о своих ошибках, никто не хочет, чтобы его считали дураком среди гениев. Страх факапов может навредить. Когда разработчики ошибаются, они воспринимают это как личный провал, что контрпродуктивно. А если поменять отношение к ошибкам? Ведь они помогают выявить и исправить уже существующие проблемы. Нет лучшего учителя, чем ошибка, не нужно бояться говорить о них. Тысячи URL-адресов были потеряны Работая в крупном финансовом учреждении, я разработал систему для очистки неиспользуемых маршрутов на сетевом уровне F5. Пул маршрутов F5 мог поддерживать примерно 5000 URL-адресов. Затем он засорялся. Моя система автоматизировала процесс мониторинга трафика по этим URL-адресам, уведомляла владельцев о неиспользуемых ресурсах и в конечном итоге очищала их. Она не давала системе F5 выйти из строя и освобождала от ручной обработки операций.Система работала хорошо и успешно использовалась для удаления нескольких десятков маршрутов в более низких средах. Но однажды в воскресенье я проснулся и обнаружил, что накануне вечером было удалено 1000 маршрутов, а пользователи жаловались на то, что это активные, действующие ссылки.Наша команда испортила всем выходные. Оказалось, что старый файл конфигурации .YAML был развернут с контейнером, удаляющим маршруты, которые были неактивны в течение недели вместо месяца. К счастью, я продумал отказоустойчивость, чтобы предотвратить удаление производственных ресурсов. Но проблема по-прежнему существовала и была серьезной. В работе приложений, часто используемых в масштабах всей компании, были бы вероятны сбои, если бы моя программа действительно удаляла активные ресурсы.Выяснилось, что большинство ресурсов, неактивных в течение недели, остаются такими целый месяц. Другими словами, важные приложения не бездействуют в течение недели. Так что в конечном итоге ущерб был управляемым; из 1000 удаленных URL лишь несколько команд пожаловались на проблему. Однако негативная обратная связь и стресс от проблемы сильно повлияли на меня и моих менеджеров. Особенно, когда мы только узнали о проблеме и не осознавали масштабов ущерба. В результате мы развернули военный штаб: вооруженная до зубов команда была готова в любой момент вручную воссоздать потерянные ресурсы или удаленные URL'ы.Как это могло случиться?!
Сначала мне казалось, что в случившемся виноват только я. Масла в огонь подливало и то, что тимлиды были с этим согласны. Но, оглядываясь назад, могу сказать, что это был закономерный провал. Существующая система управления маршрутами F5 не могла удовлетворить потребности бизнеса и не имела четкой стратегии резервного копирования или отката. Старый конфигурационный файл зависал из-за сложного процесса развертывания, поскольку был чрезмерно перегруженным и допускал такие ошибки. В конце концов, эта важная задача, поставленная мне одному (то есть без проверки кода и участия команды) вкупе с очень оптимистичным дедлайном, привела к неприятным последствиям. Мы никогда не относились к этой задаче как к первоочередной, поэтому провал был неизбежен.Что я вынес из этой ситуации? Я был благодарен коллегам, которые вмешались и вытащили нас из хаоса. В то же время я никогда не чувствовал такого выгорания. Мой тимлид и старший разработчик заявили, что потеряли веру в меня как в инженера и не могут позволить мне продолжить работу над важным проектом. Другими словами, они не смогли понять, как можно было так сглупить, потеряли ко мне доверие, а потом и вовсе отказались со мной сотрудничать. Стыдно признаться, но я на самом деле расплакался из-за всего этого. Случилось это потом, когда коллега пригласил меня на пиво. Когда я рассказал ему всю историю от и до, он ответил, что это было несправедливо и не круто, и рассказал, насколько он и другие члены команды меня ценили. Неделю я ходил подавленный, стал крайне нервным, слышать что-то об этой проблеме было просто невыносимо. Мой тимлид также пригласил меня на обед и попытался помочь разобраться в ситуации. Оба этих случая запомнились мне надолго. Эта история научила меня тому, что, хотя код можно хорошо контролировать, инфраструктуру и данные часто – нет. Критически важно использовать инструменты миграции базы данных (например, DBMate и Terraform) для управления этими компонентами системы. На них нужно обращать столько же внимания, сколько на сам код приложения, если не больше.Также крайне важно ограничить доступ к производственной среде. Например, я даже не храню фрагменты основной ветки кода в собственной среде разработки. Также я ограничиваю все прямые отправки в ветки, не являющиеся основными в рамках всей команды. База данных и учетные записи должны быть доступны по умолчанию только для чтения, должны иметь четкие стратегии резервного копирования и восстановления. Например, на моей следующей работе разработчик случайно удалил файлы из корзины prod S3. Если бы у нас не было стратегии управления версиями S3, которую я установил всего за неделю до этого (она отключена по умолчанию, черт возьми, Amazon!), мы могли потерять ее навсегда.
Самый важный урок, который я усвоил, – эмпатия необходима каждой команде. Ошибаться неприятно, поэтому, когда руководство лезет со своими комментариями, это еще сильнее усугубляет и без того проблемную ситуацию. Нечто подобное недавно случилось с моим коллегой: он отправил в продакшен код, содержащий ошибки, и нам пришлось вручную исправлять некоторые данные. Он чувствовал себя виноватым, когда говорил об этом.
Я воспользовался случаем и объяснил, что это произошло потому, что наши процессы миграции данных развертывания были некачественными. Это был провал всей нашей команды, а не лично его. Я также напомнил ему о клевых фичах, над которыми он работал, и о том, насколько они важны для нас и нашего дела. Его ошибка была для нас сигналом пересмотреть выбранные инструменты и процессы и побудила его помочь в решении проблемы. Ошибки – это возможности.Отправил письмо с кодом не сотруднику компании Перед увольнением с работы я скинул себе код на электронную почту. Я почти год работал над библиотеками Spring и в процессе создал несколько действительно хороших шаблонов тестирования. Я не хотел потерять отличные идеи и планировал использовать их для серии постов в блоге. Примерно через месяц, в первый день на новом рабочем месте, я получил сообщение, от которого побледнел: «Чувак, у нашей команды большие проблемы. Кто-то отправил код по электронной почте за пределы компании, к этому делу уже привлекли юристов. Ты не знаешь, кто бы это мог быть?»Я сразу позвонил своему бывшему тимлиду. Он не поднял трубку. Позвонил коллегам – без ответа. Оказалось, юрист проинструктировал их не выходить со мной на связь. Мне было не по себе. Мой новый тимлид поинтересовался в чем дело и как бывший адвокат посоветовал мне обратиться к юристам. Я срочно позвонил знакомому адвокату, и мы обсудили различные варианты развития событий. Поскольку это был служебный код, вероятность того, что «за мной придут», была маловероятна, но все же это было возможно.Жена забрала меня в тот день с работы и была в отличном настроении. Она спросила, как прошел мой первый день, на что я ответил: «Думаю, я нас подвел». Улыбка с ее лица исчезла. Когда я рассказал, что произошло, она абсолютно спокойно отреагировала и сказала, что хотя это действительно глупый поступок, мы справимся. Всю неделю голова была как в тумане, пока юристы из моей бывшей компании не связались со мной и не сказали, что не будут выдвигать обвинения, если я подпишу соглашение об удалении этого кода немедленно.Как это могло случиться!? Просто у меня было туннельное зрение. Я действительно гордился своими шаблонами и утилитами и думал, что лишусь профессиональных знаний, если потеряю их. Я планировал написать несколько интересных статей в блог, и каким-то образом в моем однополярном уме выгода перевесила риск.Я до сих пор ужасно переживаю, что эта ситуация затронула бывших товарищей по команде. Ответственность за эту ошибку целиком и полностью лежала на мне, но им наверняка пришлось разбираться с последствиями. Репутация команды, вероятно, была запятнана, и проверка, скорее всего, доставила всем немало хлопот. Ошибка навредила моей профессиональной репутации и, к сожалению, подпортила отношения.Что я вынес из этой ситуации? Прежде всего, я стал осторожнее с электронной почтой компании и внутренними коммуникациями. Не прошло и недели на новом месте работы, как несколько сотрудников были уволены за неуместные разговоры в личных чатах Slack. Это было довольно грязное дело: всех их уволили, а остальным пришлось пройти обязательный тренинг о последствиях харассмента на рабочем месте. Имейте в виду, что ваши личные сообщения могут быть прочитаны на работе.
Еще один важный урок – это то, как моя жена и родители сплотились, чтобы помочь мне. Я сильно переживал из-за сложившейся ситуации и не мог ясно мыслить, а их спокойствие и понимание вернули меня к реальности. Я был на грани экзистенциального кризиса: как я мог быть кандидатом наук и работать в этой сфере, но при этом оставаться таким беспечным и глупым? Я только что разрушил свое будущее? Без поддержки, возможно, я бы слетел с катушек и только усугубил ситуацию. Советы близких людей не позволили мне еще больше испортить и без того хреновую ситуацию.
«Он вам больше не понадобится» – это не просто принцип любого программного обеспечения. Смог бы я еще раз взглянуть на этот код? Даже если это привело к появлению нескольких статей в блоге, оправдан ли такой риск? Конечно, нет. Когда вы увольняетесь с работы или закрываете любую другую главу своей жизни, просто идите дальше. Ничего с собой не берите, не смотрите назад – просто двигайтесь дальше.Потерял работу во время пандемии В 2019 году я работал в сравнительно успешном стартапе по модернизации расчистки тротуаров. Нас поддерживали местные органы власти и инвестиции сторонних компаний. Оба источника доходов внезапно исчезли в марте 2020 года. Наша компания успешно преодолела первую волну ковида за несколько месяцев, резко поменяв стратегию, чтобы учесть меняющиеся приоритеты клиентов и получить часть финансирования из фондов помощи малому бизнесу.Однако к июлю стало ясно, что нам нужно или сокращать команду, или наш корабль пойдет ко дну. В 11:30 генеральный директор лично отправил мне сообщение в Slack со зловещей просьбой позвонить ему в 12:00. В 12:15 меня уволили. Цитирую: «Адам, мы вынуждены немедленно отпустить вас. Мы считаем, что вы хорошо поработали, однако из-за сложных условий мы сокращаем персонал». Я был одним из 15 человек, бесцеремонно уволенных в тот день, – без предупреждения, выходного пособия, даже без пяти минут, чтобы попрощаться с командой (учетная запись Slack была отключена во время разговора).
Мы с женой переехали в наш собственный дом шесть месяцев назад, и у нас не было достаточно средств на счету, чтобы жить долго без стабильного дохода.Следующие несколько месяцев были жесткими. Я не мог найти работу. Рынок был перенасыщен квалифицированными разработчиками, оказавшимися в той же лодке. Я не мог даже получить пособие по безработице, и это меня так расстраивало, что я написал об этом в блоге.Как это могло случиться!? Ковид нанес сокрушительный удар по бизнесу, что привело к сокращениям и трудностям на рынке труда. Но за этим стоит тяжелый урок – меня уволили, потому что я был не нужен. Бизнес мог обойтись без меня. Инженеры, которых они наняли, были технически сильными, но, что более важно, они работали над основными системами предприятия. Их увольнение могло полностью подорвать работу бизнеса, а мое – нет, и в этом мой основной недостаток.Я был новым сотрудником и мне дали вести крутые проекты – с нуля. Я работал над конвейерами машинного обучения и анализировал данные в Jupyter. Однако наши основные системы были довольно посредственными приложениями Flask. Меня никто особо не подталкивал разбираться с этими системами, поэтому я и не лез. Когда в них обнаруживались баги, я их не устранял. Когда они тормозили работу, я ничего не предпринимал; меня никто не просил, и я не проявлял инициативу. Я делал много новых крутых вещей – по сути создавал будущее компании! Оказалось, что основные системы и инженеры, которые их разрабатывали и поддерживали, были для компании более ценны, чем я. Размышляя о сложном выборе генерального директора, понимаю, что он сделал правильно, «избавившись» от меня.Что я извлек из этой ситуации? Меня никуда не брали. Особенно обидно было, когда я почти получил работу мечты в компании, которая занимается AV-технологиями, но мне отказали на последнем этапе собеседования (второй год подряд). В конце концов я устроился java-разработчиком в посредственную компанию. Я быстро понял, что скучное ПО – это круто: у него простые требования и давно сформировавшийся пул пользователей. Такие вещи, как «эта кнопка не работает», легко исправить, и для этого не требуется докторская степень или годы планирования. На самом деле очень приятно пользоваться простыми и максимально доступным инструментарием и получать за это благодарности от реальных людей.
Скучное занятие также учит критическому мышлению. Я взялся за массу дополнительной работы: от настройки инфраструктуры до работы над сложными функциями. И хотя моя цель не состояла в том, чтобы стать частью самой системы (я по-прежнему хочу автоматизировать свои рабочие процессы), это должно повысить мою важность и ценность для компании.Кроме того, я больше не беспокоюсь о собеседованиях или потере работы. Мы можем сделать все, что в наших силах, тогда как остальное находится вне нашего контроля. Возможно, вы не получили эту работу, потому что другой кандидат имел больше опыта работы с каким-либо инструментом. Возможно, они уже сделали оффер кому-то. Или, может быть, ты просто не так хорош, как тот другой кандидат. Избавьтесь от своего эго, постарайтесь привыкнуть к окружающим условиям, и страх исчезнет. Поймите, что вы, вероятно, не являетесь и никогда не будете рок-звездой от разработки – и это нормально.
Наконец последнее, чему я научился, – это постоянно давать самому себе обратную связь. Как я себя чувствую? Почему я работаю над проектом X? Важен ли проект X для успеха компании? Если нет, то что важно? Не привязывайтесь сильно к своей работе. Часто мы боимся обратной связи, потому что она может задеть наше эго, но ее принятие – это единственный способ движения вперед. P.S. Позор тем компаниям, которые оставляют соискателей без обратной связи. Основной вывод из прошлых ошибок заключается в том, что вы всегда будете сталкиваться с препятствиями и неудачами. Они не только неизбежны, но и необходимы. Редко когда неудачи являются следствием провала отдельного взятого человека. Факапы – это возможность лучше понять себя и окружающих. Начальник сравнял вас с землей или вознес до небес? Семья и друзья не бросили в трудную минуту? В любом случае у вас есть отличная возможность перевести дыхание и подумать о планах.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Adam Hughes
===========Похожие новости:
- [Разработка веб-сайтов, PHP, Программирование, Будущее здесь] Мир изменился — CQRS и ES встречаются в PHP чаще, чем кажется
- [Веб-дизайн, Разработка веб-сайтов, CSS, HTML] Примеры применения переменных CSS на практике (перевод)
- [Data Mining, Big Data, Аналитика мобильных приложений, Управление продуктом] Как внедрение Amplitude помогло Лиге Ставок настроить продуктовую аналитику и усилить data-driven культуру в компании
- [Высокая производительность, Тестирование IT-систем] 30 тысяч пользователей одновременно: как мы тестировали корпоративный портал «1С-Битрикс24: Enterprise»
- [Биллинговые системы, Производство и разработка электроники, Сотовая связь, IT-компании] История о том, как мы разработали собственную БС
- [Программирование, Конференции] Как решить нестандартные задачи в Backend и не проиграть. Расскажут спикеры конференции DUMP
- [Тестирование IT-систем, Анализ и проектирование систем, ERP-системы, Agile] Масштабный проект по внедрению SAP S/4HANA в удаленном режиме: уроки, которые мы усвоили
- [Управление разработкой, Agile, Управление продуктом, Управление персоналом] SCRUM: Разработка и поставка продукта
- [Программирование, Java, Проектирование и рефакторинг, Управление разработкой] Инструменты для разработчиков могут быть волшебными. Вместо этого они пылятся на полке (перевод)
- [Алгоритмы, Управление проектами, Agile] ДНК (Деление на команды) – визуализация взаимосвязей людей и команд
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_produktom (Управление продуктом), #_produkt (продукт), #_kod (код), #_razrabotka (разработка), #_upravlenie_proektami (управление проектами), #_project_management, #_testirovanie (тестирование), #_prototipy (прототипы), #_produktovaja_razrabotka (продуктовая разработка), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 09:39
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
В оригинальной статье на сайте Medium, хотя и написанной от лица мужского пола, можно сказать от библейского первого человека Адама, в пример топового разработчика приводится девушка, которая в 11 лет сделала свой сайт, а к 23-м годам стала миллиардером. Судя по тому, что у нас в компании девушки-разработчики – большая редкость (их всего две), а мы типичная IT-компания, для адаптации к местным реалиям пришлось превратить ее в парня. Получилось почти как у Киплинга. Помните, пантера Багира в оригинальных книгах был мачо-мальчиком, а в советском мульте превратился в супердевочку с голосом актрисы Касаткиной.
Но реальность такова, что каждый разработчик, даже топовый, иногда ошибается, но исправляется. Разница – в цене ошибки; если облажается программист, под угрозой оказываются базы данных, такие потери могут стоить компаниям миллиардов долларов. Почему мы все так боимся косяков? Они как клеймо: никто не говорит о своих ошибках, никто не хочет, чтобы его считали дураком среди гениев. Страх факапов может навредить. Когда разработчики ошибаются, они воспринимают это как личный провал, что контрпродуктивно. А если поменять отношение к ошибкам? Ведь они помогают выявить и исправить уже существующие проблемы. Нет лучшего учителя, чем ошибка, не нужно бояться говорить о них. Тысячи URL-адресов были потеряны Работая в крупном финансовом учреждении, я разработал систему для очистки неиспользуемых маршрутов на сетевом уровне F5. Пул маршрутов F5 мог поддерживать примерно 5000 URL-адресов. Затем он засорялся. Моя система автоматизировала процесс мониторинга трафика по этим URL-адресам, уведомляла владельцев о неиспользуемых ресурсах и в конечном итоге очищала их. Она не давала системе F5 выйти из строя и освобождала от ручной обработки операций.Система работала хорошо и успешно использовалась для удаления нескольких десятков маршрутов в более низких средах. Но однажды в воскресенье я проснулся и обнаружил, что накануне вечером было удалено 1000 маршрутов, а пользователи жаловались на то, что это активные, действующие ссылки.Наша команда испортила всем выходные. Оказалось, что старый файл конфигурации .YAML был развернут с контейнером, удаляющим маршруты, которые были неактивны в течение недели вместо месяца. К счастью, я продумал отказоустойчивость, чтобы предотвратить удаление производственных ресурсов. Но проблема по-прежнему существовала и была серьезной. В работе приложений, часто используемых в масштабах всей компании, были бы вероятны сбои, если бы моя программа действительно удаляла активные ресурсы.Выяснилось, что большинство ресурсов, неактивных в течение недели, остаются такими целый месяц. Другими словами, важные приложения не бездействуют в течение недели. Так что в конечном итоге ущерб был управляемым; из 1000 удаленных URL лишь несколько команд пожаловались на проблему. Однако негативная обратная связь и стресс от проблемы сильно повлияли на меня и моих менеджеров. Особенно, когда мы только узнали о проблеме и не осознавали масштабов ущерба. В результате мы развернули военный штаб: вооруженная до зубов команда была готова в любой момент вручную воссоздать потерянные ресурсы или удаленные URL'ы.Как это могло случиться?! Сначала мне казалось, что в случившемся виноват только я. Масла в огонь подливало и то, что тимлиды были с этим согласны. Но, оглядываясь назад, могу сказать, что это был закономерный провал. Существующая система управления маршрутами F5 не могла удовлетворить потребности бизнеса и не имела четкой стратегии резервного копирования или отката. Старый конфигурационный файл зависал из-за сложного процесса развертывания, поскольку был чрезмерно перегруженным и допускал такие ошибки. В конце концов, эта важная задача, поставленная мне одному (то есть без проверки кода и участия команды) вкупе с очень оптимистичным дедлайном, привела к неприятным последствиям. Мы никогда не относились к этой задаче как к первоочередной, поэтому провал был неизбежен.Что я вынес из этой ситуации? Я был благодарен коллегам, которые вмешались и вытащили нас из хаоса. В то же время я никогда не чувствовал такого выгорания. Мой тимлид и старший разработчик заявили, что потеряли веру в меня как в инженера и не могут позволить мне продолжить работу над важным проектом. Другими словами, они не смогли понять, как можно было так сглупить, потеряли ко мне доверие, а потом и вовсе отказались со мной сотрудничать. Стыдно признаться, но я на самом деле расплакался из-за всего этого. Случилось это потом, когда коллега пригласил меня на пиво. Когда я рассказал ему всю историю от и до, он ответил, что это было несправедливо и не круто, и рассказал, насколько он и другие члены команды меня ценили. Неделю я ходил подавленный, стал крайне нервным, слышать что-то об этой проблеме было просто невыносимо. Мой тимлид также пригласил меня на обед и попытался помочь разобраться в ситуации. Оба этих случая запомнились мне надолго. Эта история научила меня тому, что, хотя код можно хорошо контролировать, инфраструктуру и данные часто – нет. Критически важно использовать инструменты миграции базы данных (например, DBMate и Terraform) для управления этими компонентами системы. На них нужно обращать столько же внимания, сколько на сам код приложения, если не больше.Также крайне важно ограничить доступ к производственной среде. Например, я даже не храню фрагменты основной ветки кода в собственной среде разработки. Также я ограничиваю все прямые отправки в ветки, не являющиеся основными в рамках всей команды. База данных и учетные записи должны быть доступны по умолчанию только для чтения, должны иметь четкие стратегии резервного копирования и восстановления. Например, на моей следующей работе разработчик случайно удалил файлы из корзины prod S3. Если бы у нас не было стратегии управления версиями S3, которую я установил всего за неделю до этого (она отключена по умолчанию, черт возьми, Amazon!), мы могли потерять ее навсегда. Самый важный урок, который я усвоил, – эмпатия необходима каждой команде. Ошибаться неприятно, поэтому, когда руководство лезет со своими комментариями, это еще сильнее усугубляет и без того проблемную ситуацию. Нечто подобное недавно случилось с моим коллегой: он отправил в продакшен код, содержащий ошибки, и нам пришлось вручную исправлять некоторые данные. Он чувствовал себя виноватым, когда говорил об этом.
Еще один важный урок – это то, как моя жена и родители сплотились, чтобы помочь мне. Я сильно переживал из-за сложившейся ситуации и не мог ясно мыслить, а их спокойствие и понимание вернули меня к реальности. Я был на грани экзистенциального кризиса: как я мог быть кандидатом наук и работать в этой сфере, но при этом оставаться таким беспечным и глупым? Я только что разрушил свое будущее? Без поддержки, возможно, я бы слетел с катушек и только усугубил ситуацию. Советы близких людей не позволили мне еще больше испортить и без того хреновую ситуацию.
Мы с женой переехали в наш собственный дом шесть месяцев назад, и у нас не было достаточно средств на счету, чтобы жить долго без стабильного дохода.Следующие несколько месяцев были жесткими. Я не мог найти работу. Рынок был перенасыщен квалифицированными разработчиками, оказавшимися в той же лодке. Я не мог даже получить пособие по безработице, и это меня так расстраивало, что я написал об этом в блоге.Как это могло случиться!? Ковид нанес сокрушительный удар по бизнесу, что привело к сокращениям и трудностям на рынке труда. Но за этим стоит тяжелый урок – меня уволили, потому что я был не нужен. Бизнес мог обойтись без меня. Инженеры, которых они наняли, были технически сильными, но, что более важно, они работали над основными системами предприятия. Их увольнение могло полностью подорвать работу бизнеса, а мое – нет, и в этом мой основной недостаток.Я был новым сотрудником и мне дали вести крутые проекты – с нуля. Я работал над конвейерами машинного обучения и анализировал данные в Jupyter. Однако наши основные системы были довольно посредственными приложениями Flask. Меня никто особо не подталкивал разбираться с этими системами, поэтому я и не лез. Когда в них обнаруживались баги, я их не устранял. Когда они тормозили работу, я ничего не предпринимал; меня никто не просил, и я не проявлял инициативу. Я делал много новых крутых вещей – по сути создавал будущее компании! Оказалось, что основные системы и инженеры, которые их разрабатывали и поддерживали, были для компании более ценны, чем я. Размышляя о сложном выборе генерального директора, понимаю, что он сделал правильно, «избавившись» от меня.Что я извлек из этой ситуации? Меня никуда не брали. Особенно обидно было, когда я почти получил работу мечты в компании, которая занимается AV-технологиями, но мне отказали на последнем этапе собеседования (второй год подряд). В конце концов я устроился java-разработчиком в посредственную компанию. Я быстро понял, что скучное ПО – это круто: у него простые требования и давно сформировавшийся пул пользователей. Такие вещи, как «эта кнопка не работает», легко исправить, и для этого не требуется докторская степень или годы планирования. На самом деле очень приятно пользоваться простыми и максимально доступным инструментарием и получать за это благодарности от реальных людей. Скучное занятие также учит критическому мышлению. Я взялся за массу дополнительной работы: от настройки инфраструктуры до работы над сложными функциями. И хотя моя цель не состояла в том, чтобы стать частью самой системы (я по-прежнему хочу автоматизировать свои рабочие процессы), это должно повысить мою важность и ценность для компании.Кроме того, я больше не беспокоюсь о собеседованиях или потере работы. Мы можем сделать все, что в наших силах, тогда как остальное находится вне нашего контроля. Возможно, вы не получили эту работу, потому что другой кандидат имел больше опыта работы с каким-либо инструментом. Возможно, они уже сделали оффер кому-то. Или, может быть, ты просто не так хорош, как тот другой кандидат. Избавьтесь от своего эго, постарайтесь привыкнуть к окружающим условиям, и страх исчезнет. Поймите, что вы, вероятно, не являетесь и никогда не будете рок-звездой от разработки – и это нормально.
=========== Источник: habr.com =========== =========== Автор оригинала: Adam Hughes ===========Похожие новости:
Управление разработкой ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 09:39
Часовой пояс: UTC + 5