2014-03-25
Вы наняли нового разработчика в проект, и он прекрасно вписался. Всего за первые три дня работы он уже предложил обновить пять ваших библиотек, занялся реорганизацией задач в JIRA, нашёл восемь критичных багов, которые — вот ещё чуть-чуть — и привели бы к непоправимым последствиям…
«Боже, — думаете вы, — Каким же ужасным был предыдущий разработчик! Как он допустил всё это?». Почему он использовал Postgres, а не CouchDB, ведь это гораздо удобней? До чего же вы были слепы, раз не видели этого раньше!
Проклятие текущего момента
Не переживайте, вы не уникальны. Каждый разработчик приходит на новое рабочее место и, кажется, собиратся поменять к лучшему всё и сразу. Он предлагает новые инструменты, новые процессы, новые языки, новое абсолютно всё. Я был по обе стороны этой увлекательной пьесы. Я был тем самым «предыдущим разработчиком», который, казалось, ни черта не смыслил. Я был новым разработчиком, который исправлял косяки предыдущих. Я нанимал разработчиков, и наблюдал за тем, как «новые» превращаются в старых.
Пора бы понять: такая хрень происходит со всеми и постоянно.
Это я называю «проклятием текущего момента». Стоит только оглянуться назад, и оценить свежим взглядом те решения, которые принимались в прошлом, осознание ущербности этих решений вас уже не покинет. «Ну почему же я построил это на Rails, когда Node.js был бы гораздо удобней?». Однако, вы как-то забываете, что вы смотрите на прошлую проблему с высоты сегодняшнего дня. В то время, когда велась разработка, могло и не быть тех инструментов, которые известны сегодня. Многое могло делаться наугад и интуитивно. А вы поддаётесь влиянию текущего момента и отрицаете все предыдущие достижения.
Обвинять — не воду носить
Ну, это же так просто: обвинить во всех грехах разработчика, который в своё оправдание уже ничего и сказать не может. И новый разработчик запросто может попасть в западню лени: если на решение проблемы должно уйти много времени и усилий, он с гораздо большей вероятностью начнёт говорить, что задача требует около двух недель на выполнение, но в связи со старой версией [любой библиотеки] понадобится больше месяца. Удобно ведь.
Ведь я этого достоин
Вы искали этого разработчика. Заставили его пройти через серию собеседований, технических тестов и прочих проверок, и, наконец, наняли его. Конечно, теперь этот человек будет доказывать, что вы не ошиблись в своём решении. Самый очевидный способ это сделать — начать пушить многочисленные изменения с самого первого дня работы. Сколько раз я видел новеньких, с пеной у рта доказывающих, что нужно немедленно перейти на JIRA и перестать использовать этот несносный Pivotal, и как нам не стыдно юзать Subversion вместо Git. Всё это делается для того, чтобы произвести первое впечатление.
Хватит, правда
Мне действительно кажется, что это дурной тон — в чём-либо обвинять предыдущего разработчика или команду. Гораздо правильней по умолчанию считать, что эти ребята сделали всё что могли в предлагаемых обстоятельствах. Не стоит ради пускания пыли в глаза очернять других людей. В конце концов, каждый из нас когда-либо был или будет в шкуре того самого программиста, который «занимался чёрт знает чем». Не нужно портить себе карму безосновательными утверждениями о некомпетентности своих коллег.
Да, бывают случаи, когда тот, кто был на вашем месте, действительно особенно не старался. Но даже это не повод прикрываться некомпетентностью прежнего работника, иначе есть риск скатиться в такую же бездну некомпетентности. И следующий работник будет использовать уже вашу мифическую фигуру в качестве прикрытия.
Не расслабляемся, ребята.
По материалам поста на Medium.com.
