Год назад я начал работать в очень гибком стартапе. Я был первым разработчиком, не являющимся стажером, который присоединился к нам, и тесно сотрудничал с техническим директором, чтобы собрать бета-версию конвейера и продукта. Из-за требуемой скорости и ранее неизведанного домена мы построили что-то неоднородное, но работающее. Многое было пропущено, в том числе тесты и часть документации (на самом деле не было времени).
Прошло несколько месяцев с тех пор, как к нам присоединилась пара других разработчиков. Они не являются разработчиками полного стека, поэтому каждый из них несет ответственность за некоторые части моего кода. Но их площади не пересекаются. Это делает их идеальными коллегами, поскольку каждый из них не может по-настоящему критиковать работу другого человека.
Вместо этого я сталкиваюсь сейчас с постоянной критикой всего, что я разработал. Не говоря уже о требуемой скорости или отсутствии знаний в предметной области.
Я пытался поговорить с техническим директором, но он просто говорит, что они учатся и становятся лучше, однако я думаю, что он просто не хочет заниматься этими вопросами.
Кто-нибудь знает, как справиться с этой ситуацией, не живя каждый день в страхе и тревоге?
Вы приняли тактическое решение взять на себя часть технического долга, чтобы предоставить готовый продукт, который был бы функциональным. Вы работали с чистого листа бумаги и сделали что-то достаточно хорошее, чтобы клиенты и инвесторы захотели его использовать. Гордитесь этим — это должно быть одной из первых строк в вашем резюме.
Сейчас система взрослеет. К вам приходят другие разработчики, которые могут объективно взглянуть на то, что было разработано, и иметь (возможно, обоснованные) идеи о том, как это улучшить.
Ваша роль сейчас не в том, чтобы быть кодовой обезьяной. Ваша позиция состоит в том, чтобы подняться выше и управлять своими кодерами. У вас есть знания в предметной области, которых нет у них — вы знаете, почему были приняты те или иные решения. Они должны свободно обсуждать с вами идеи о том, как сделать продукт лучше — быстрее, функциональнее, безопаснее, масштабируемее. Если разработчик не дает вам этих предложений, возможно, он не подходит для этой должности.
Трудно воспринимать критику, когда это «ваше детище», но если вы посмотрите на это с точки зрения того, что если система хороша, то каждый имеет работу и зарабатывает деньги, то вы увидите, что разработчики все проталкиваются в в том же направлении (если нет, убедитесь, что они толкают выходную дверь). Даже если вся ваша кодовая база будет переписана, вы все равно останетесь тем, кто написал первую версию.
Я сомневаюсь, что атмосфера улучшилась бы, если бы вы сказали, что воспринимаете эту критику на свой счет и хотели бы, чтобы она прекратилась, или если бы вы обострили ситуацию. Вы можете добиться того, чтобы они перестали открыто критиковать, но это не изменит их мнения и нанесет ущерб вашим отношениям как коллег.
Критика работы другого разработчика является неотъемлемой частью культуры разработчика, и вы должны смириться с тем фактом, что это не всегда делается конструктивно или максимально тактично. Если им не хватает понимания, вы можете рассказать им о причинах, по которым вы пошли на такие жертвы. Напоминая им о высокой смертности стартапов, вы можете помочь им осознать, что помимо качества кода существуют вещи, такие как нехватка денег, которые вполне реальны.
В качестве практического совета постарайтесь не ассоциироваться со своей работой и легкомысленно относитесь к замечаниям, если они ничего не говорят о вашем профессионализме. Если вы чувствуете, что они сбиваются с курса и становятся негативными, вы можете попытаться привести их к позитивному настроению, отвечая на замечания «ххх код пахнет» словами «у нас/у вас будет шанс исправить это в yyy дату».
Они могут преодолеть это. Код, который они критикуют, — это тот же самый код, который открыл возможности, требующие найма дополнительных разработчиков (они же — они). Без этого у них нет причин быть там.
Коротко о том, что разработчики работают над улучшением кода (такая же история везде). Если он не делает что-то, что должен делать, нужно сделать код для этого. Если сломалось, починить. Если они будут ждать достаточно долго, они вставят туда код для критики другими.
Согласен с ответом @PeteCon.
Возможно, вы переходите в защитный режим, потому что это ваш код и отчасти отражение вашего мастерства. Вы говорите, что нет никакого отношения к ограничениям, с которыми вы столкнулись во время написания, но это не имеет большого значения. Плохой код есть плохой код. Если вы создали что-то функциональное, но непригодное для сопровождения, то необходимо провести рефакторинг. Это не означает, что создание чего-то, что работает за короткий промежуток времени, не является достижением.
Как упоминалось в другом ответе, вам нужно перестать заниматься кодированием на полную ставку и перейти к управлению ресурсами. Также я категорически не согласен с тем, что вы думаете, что ваши разработчики, работающие над строго отдельными частями вашей кодовой базы, — это хорошо, но это не так! Если вы хотите эффективно внедрить такие вещи, как проверки кода, когда разработчики могут начать просматривать друг друга запросы на слияние, тогда они должны быть знакомы с просматриваемой кодовой базой. Кроме того, вы создаете островки знаний, и когда один из ваших разработчиков в конце концов уйдет, никто не будет понимать, как работают его реализации, потому что никто не работал с их частью кодовой базы и никто не гарантировал качество, читабельность и документацию их кода. через обзор.
Я хотел бы поделиться опытом, потому что это звучит очень похоже на вашу историю.
Когда-то я присоединился к технологическому стартапу. Это была моя вторая подработка в сфере ИТ, в то время я еще учился в университете. Команда была отличная, и мне нравились мои задачи, но были некоторые организационные вопросы.
Ведущий разработчик был одним из самых лучших и опытных людей, с которыми я когда-либо работал. Очень опытный, очень знающий. Их проекты также были их детищем. Я подозреваю, что они могли бы занять гораздо лучшую должность с гораздо более высокой зарплатой, но им понравился свой проект, и они остаются там по сей день, насколько мне известно. Он также был выкачан с удивительной скоростью, быстрее, чем я мог бы, но, таким образом, он был с большим техническим долгом.
Со временем в ряды разработчиков влилось больше студентов и не-студентов, но лидеры продолжали работать над кодовой базой, потому что это то, что им нравилось делать, и я это понимаю. Но со все большим количеством проектов они просто начали гореть. Все позже и позже вечером, пытаясь закончить это, пытаясь закончить это, кодирование и обслуживание серверов на выходных, в отпуске, во время отпуска по болезни и так далее.
Между тем политика компании не предусматривала протоколов проверки или тестирования. Несколько разработчиков, в том числе и я, попросили руководство меньше кодировать и больше управлять, потому что нам нужна была правильная структура управления версиями, правильная организация репозитория и так далее, но этого просто не произошло. Они искренне обещали, что мы это сделаем, но всегда были перегружены работой по DevOps.
И так, две вещи развивались. Одно дело были острова. Я поддерживал свой проект, который был большим источником дохода для компании, будучи студентом самостоятельно. Я знал все секретные пути, все хитросплетения кода, но не хватало времени сделать все, что просили. Выкачивал фичи, пытался найти какую-то организацию в репозитории, занимался поддержкой клиентов и продолжал тушить пожары. Второе — наша кодовая база испортилась. Никто не рецензировал мой код, никто не мог в какой-то момент, не было времени на документацию и постоянное лоскутное шитье.
Это касалось и других коллег.
Так что все больше и больше замедлялось с точки зрения разработки функций во всех проектах, кроме самых новых, потому что все больше и больше технического долга начинало сказываться, и мы находились под постоянным давлением со стороны руководства. Психологическое давление. Однажды я застал коллегу плачущим в ванной, немного пообщался с ним, понял, что почти год сбрасывал свой стресс на семью и партнера — и решил, что пора уходить.
По сей день мне стыдно оставлять эту кодовую базу в таком грязном состоянии, потому что я много работал над ней, многое из этого добавлял сам. , то ваш код становится неисправимым беспорядком. Когда я уволился, еще несколько человек ушли. Еще два острова. Никто никогда не был знаком с их кодовой базой, за исключением ведущей степени.
Вывод из этой сказки - эти проекты в основном мертвы. Компания по-прежнему зарабатывает на них деньги, но дальнейшего развития не было, за исключением некоторых вещей, которые могли измениться. Должности оставались вакантными, недавно нанятые разработчики, по-видимому, не могли поддерживать соответствующие кодовые базы.
Теперь я работаю в компании с надлежащими проверками кода, тестированием, автоматизированными конвейерами, процессами... это так хорошо. Конечно, у нас есть своя специализация в кодовой базе, но практически никаких островных знаний нет, кроме проверки кода, так что ни один код никогда не достигает основной ветки, если его не видел кто-то другой. Мое психическое здоровье по отношению к моему рабочему месту также улучшилось, и мои навыки теперь намного острее.
Я понимаю, с критикой вашей работы сложно эмоционально справляться, но вы должны относиться к критике как к хорошему, это означает, что ваши разработчики могут улучшить кодовую базу, потому что они видят вещи, которые могут быть другими. Не создавайте острова кодовой базы, потому что в какой-то момент вы потеряете людей, и не пытайтесь все исправить самостоятельно, вы сами попадете в реанимацию.
Чтобы двигаться дальше, я предлагаю обсудить стратегию с вами и двумя другими разработчиками. Цель должна состоять в том, чтобы спланировать следующие этапы. Есть как минимум три вещи, которые необходимо охватить:
Темы должны включать в себя то, как сбалансировать работу над этими целями, какой уровень тестирования и документации должен быть достигнут в следующем раунде разработки и как этого добиться. Если кто-то из них начнет говорить о недостатках раннего кода, верните обсуждение к планированию того, что с этим делать.
Почему тебя вообще это волнует?!
Они могут критиковать все, что хотят, при условии, что они также пиарят хорошие, действительные исправления.
Как говорили другие, код, который они исправляют, — это то, что в первую очередь принесло деньги, чтобы нанять их.
Возможно, вы захотите напомнить им об этом. Ежедневно.
А если серьезно, пусть жалуются от всего сердца, пишут длинные сообщения о коммитах и все такое.
Просто убедитесь, что в качестве технического обозревателя они хорошо справляются с вашей старой кодовой базой и улучшают ее.
Единственное исключение — если они становятся дерзкими и/или откровенно грубыми в своей критике. Одно дело думать: «О боже, этот код — отстой!», а другое дело — полностью выплеснуть это в эфир именно этими словами.
В таком случае стреляйте им в задницы на месте.
Но в остальном... чувак, ты построил прототип. Вы «воз» вашей компании.
Почему тебя вообще волнует, что они думают?!
Соберите их вместе для небольшого разговора. Скажите им, как есть: вы быстро составили этот код , чтобы довести компанию до точки, когда она будет получать финансирование, которое используется для выплаты их зарплаты. Без кода, на который они жалуются, они бы там не работали.
Скажите им: если вам это не нравится, исправьте это. Тихо. Не жалуясь мне.
PS. Если они производят «исправления» вместо исправлений, то это серьезный выговор. Если вы организуете свою работу с помощью бэклога, то если вы делаете что-либо, не попадая в бэклог, это требует порицания. ОДНАКО это вполне уместно и является лучшей практикой при выполнении одной задачи по улучшению кода, связанного с ней.
Патрисия Шанахан
Крис Стрэттон
Другой работник
очерченный
Кортик