Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят
Всю свою карьеру я работал программистом в ИТ-корпорациях и вносил мизерный вклад в гигантские системы, которые никому не нужны. Но везде меня считали крутым.
Один раз я написал статью о том, как увлечение новым языком программирования спасло меня от выгорания. Её прочитало много людей, и меня позвали работать в стартап. Предложение было заманчивым, ребята звали меня делать реальные вещи, а не абстрактное дерьмо. Я согласился.
Собес был странным. Я привык, что обычные интервью хуже экзамена, а эти парни почти не проверяли мои технические скиллы. Они только и говорили, что за продукт хотят сделать, — я же привык обсуждать, как делать, а не что.
Мы уже тогда говорили на разных языках, но похоже, они приняли положительное решение ещё до собеса — статья внушила им, что я подхожу команде как человек. Мои скиллы их не особо интересовали. Наверное, ребята думали, что все хорошие программисты пишут код одинаково.
Когда я приступил к работе, я охренел. У них всё было сделано неправильно. Они буквально в тупую брали и решали проблемы продукта, подпирая один костыль двумя другими. Они не выстраивали хорошую архитектуру, не работали по практикам, их кодом можно было выжигать разработчикам глаза.
Я сразу сказал прямо — это не код, это дырявый пакет с мусором, мы всё здесь к чертям перепишем.
Когда много работаешь в большой корпорации, учишься убеждать людей, потому что каждый день отстаиваешь решения перед десятками крутейших инженеров. Вот есть ты — истинный технарь, настоящий мессия, человек, который один тут знает, как надо правильно вести разработку.
Эти парни такими не были — и легко купили мои аргументы, потому что и наняли меня разбираться в вещах, которые они не понимают. Не отвлекаться же от бизнеса. Я был только рад — вот у нас есть модуль, который прямо сейчас работает и решает настоящую проблему, вот у нас есть ведро, в которое мы его выкинем, и вот у нас есть план, как сделать то же самое, но нормально.
Как у любого стартапа, у этого был ограниченный бюджет. И я убедил всех, что его надо тратить на правильный код, продуманную архитектуру и глубокое тестирование. «Это самая правильная инвестиция, — настаивал я. — Знаете, почему 90% стартапов схлопываются? Потому что у них все начинает валиться из-за ранних ошибок, и весь бюджет уходит на латание дыр в прототипе, из которого они решили растить продукт, не переписывая. А могли бы разрабатывать новые фичи».
Я принес это мышление из больших компаний — там не существует никакого бюджета. Там делаем, сколько хотим, менеджеры поворчат, но ИТ-гигант все равно оплатит любой чек.
Каждый день у нас были созвоны, и каждый день парни пытались убедить меня подзабить на качество — но я каждый раз легко их переубеждал. Потому что только тот, кто сечет в качестве, может об этом убедительно спорить. Но их нытье, что вот к этому дню они планировали добавить вот эти пять фич, а вместо этого мы просто переделали то, что уже работало, начинало меня доставать.
«Эй, вы меня наняли, чтобы повысить качество разработки — мы его повышаем». Но это моя логика. Кроме логики есть ещё эмоции, и я начал сопереживать. На самом деле я понимал, что им не нужно качество. Если вы любите работать на результат — попробуйте меня понять. Представьте, что вы попали в компанию вечного процесса, где релиз вечно откладывается все дальше и дальше, и вы начинаете понимать, что никто к нему особо и не стремится. Как быстро вы сбежите?
Примерно так же я не представляю, как можно позволить себе собранный на коленке продукт.
Парни в этом стартапе, может, и хотели писать код, над которым никто не будет смеяться, но для их бизнеса такие вещи — чисто косметические. Им ведь действительно тупо нужно зафигачить, чтобы оно работало. Но признаться в этом самим себе они не могут.
Когда я это прочувствовал, я поймал себя на том, что уже третью неделю покрывал тестами модуль, который хорошо работал и не нуждался в модификациях в обозримом будущем.
Я сел, хорошенько подумал и осознал — из-за меня этот бизнес просто выкинул четыре месяца. Буквально никакого профита от того, что мы тут делали, для них нет. И никогда не будет. Я взял яйца в кулак, извинился и ушёл. В гигантскую компанию, которая всегда рада оплатить мои идеалистические порывы делать никому не нужное максимально правильным способом.
Наверное, я огромный мудак. Может и правда то, что я делаю, — это плохо, и мне нужно стать другим разрабом. Но это не так. Дело в том, что есть разрабы, которые занимаются индустрией, и есть те, кто фигачит вам продукт. Главное уметь отличать их друг от друга и ни в коем случае не ждать от индустрийщиков, что они сделают вам ваш продукт. Потому что они плевать на него хотели. На ваш продукт, на ваших пользователей, на ваш бизнес и на вас самих.
Они легко убедят вас на собесе, что ваши разрабы — говно собачье, а то, что вы уже сделали, — игрушечный прототип, который прямо сейчас надо сесть и написать нормально. Они не мудаки, их учили решать другие проблемы.
Если бы вам как-нибудь довелось саппортить проект, которому десять лет, вы бы поняли, откуда тут растут ноги. Но конкретно для вас сейчас вот что важно — если у стартапа возникают проблемы с поддержкой старого кода, значит, у вас все просто отлично. Значит, вы уже запустились, зарабатываете бабки, пришло время становиться большой корпорацией и нанимать хороших программистов, которые будут месяцами копаться в каждом модуле.
А до тех пор — гоните этих умников в шею. Они пришли к вам не ваши проблемы решать. Они пришли вести исследования, качать свой скилл и уходить на более жирное место.
Если ваш кандидат на должность СТО рассказывает про программирование с горящими глазами, часто говорит об архитектуре, фреймворках и прочем — это тот самый парень. И от него будут одни чертовы проблемы.
Моя история со стартапом была два года назад, и я даже не помню, что там был за проект. Вообще ничего не помню. Все мои друзья — такие же разрабы, как я, — работают точно таким же образом. Мы живем ради развития индустрии и разработки, а не ради говноприложений для людей, которые не отличают джаву от джаваскрипта.
А вот кто действительно нужен для разработки приложений — это ребятки, которые услышали про зарплаты в ИТ и научились программировать за полгода ради денег. Такие, кому плевать на элегантность подходов функционального программирования. Тех, кто на досуге читает книжки про бизнес, а не про домейн драйвен девелопмент. И они работают вот так — тупо делают в срок, что им сказано. И это именно то, что тебе нужно, пока над твоим проектом работает меньше сотни человек.
О, вот уже и Фил с хабры ушел. Велкам. Статья хорошая, сам часто ловлю себя на том, что делаю правильно, а не то, что хотят.
Значит вы, как и Фил, делаете именно НЕПРАВИЛЬНО.
Суть программиста и инженера - выдать конечное решение, соответствующее требованиям( сроки, бюджет, приемлемая работа на конкретных устройствах или их типах ), а то, как конкретно оно выглядит "под капотом" и сколько по этому поводу можно сделать ссылочек на умные книжки и статейки( притом, "умные" они не объективно, а по мнению энного неизвестного круга лиц ) сторонним людям глубоко наплевать.
И если человек называет себя крутым программистом, но не может исполнить проект в сроки и бюджет, т.е исполнить его ПРАВИЛЬНО - он не крутой и, даже, не хороший программист - он черти кто, незаслуженно получающий зарплату.
Не могу сказать, что сам нереально крутой разработчик, да и на всяких хабрах-хренабрах меня толком тоже нет..
НО я, тем не менее, почему-то хорошо понимаю, что если дело касается стартапа, то речь о конторе с ограниченным бюджетом и сроками и им нередко, для начала, надо выпустить первый релиз - типо MVP и уже потом его допиливать согласно реакции аудитории.
Для них КРИТИЧЕСКИ важны время и бюджет при, нередко, не самых конкретных требованиях итп. И быть тем, кто убивает экономику проекта только ради абстрактного "качества кода" итп - быть тем, кто именно проваливает даже вполне удачный проект и нифига не умеет применять инструментарий( т.к те же тесты итп не всегда и не везде одинаково важны - у каждого проекта свои приоритеты ).
п.с: ну а чувак из статьи и им подобные - профессиональные, но не программисты и не разработчики, а, "заработчики", которые и не такую чушь придумают, лишь бы еще больше денег и времени стрясти с проекта ради делания никому реально не нужных вещей.
Разница лишь в том, что в крупной конторе это будут ошибочно воспринимать как профессионализм, а ее ресурсы позволят без проблем прокормить еще одного паразита, тогда как мелкие конторы таковых не потянут, т.к то, сколько они получают, несоразмерно тому, что они делают( практически, ничего, а то еще и в минус уходят ).
Но ведь делать "как правильно" прогеры начинают после того, как пару раз сделают быстро и на коленке, а через год выясняется, что масштабировать написанное невозможно - нужно переписывать с нуля.
Лично я "как правильно" так и не научился. Вон, недавно захотел использовать свой крутой компонент в другом своём проекте и знаете что? - так и не распутал клубок зависимостей, который запутанно корнями уходили в другие компоненты уже никак с ним не связанные.
В тот момент я очень пожалел, что делал быстро и без оглядки на "правильность".
"Правильность" - кнчн штука весьма условная, но когда речь о том, что надо сделать максимально быстро и никого особо не интересует как конкретно оно сделано и что под капотом, "правильно" - будет быстро, с костылями и хз какой масштабируемостью.
Т.к нередко сами конторы не совсем понимают, что конкретно требуется и сам процесс предполагает дальнейшее ленивое допиливание на основе обратной связи.
Т.е по сути это не даже не приложение/программа, а просто ее рабочий прототип( и никто в здравом уме не будет через год это как-то серьезно масштабировать, если идея "выстрелит", а если не выстрел - то тем более плевать ).
А сама программа/приложение - будут пилиться уже через 6-12-.. месяцев( и будет именоваться уже v2 ), когда будет конкретно ясно, что именно требуется и в каком направлении будет развитие... и если сама идея "выстрелит" - тогда будут и деньги и время на сделать_все_с_толком_и_расстановкой, т.к рабочая версия, пусть и кривоватая, но уже есть и работает.
У самого нередко подобным образом получается.
Хотя, в последнее время, примерно в 2-х случаях из 3-х компоненты и модули обычно удается запросто переносить в другие проекты.
Но это связано с тем, что стараюсь минимально использовать сторонние компоненты, модули и зависимости и, порой, откровенно экономлю на спичках( т.е скорее всего, мои модули и компоненты будут зависеть лишь от базовых частей, которые идут из коробки ).
"и никто в здравом уме не будет через год это как-то серьезно масштабировать, если идея "выстрелит"" - увы, но в реальности именно так и происходит :( бизнес считает, что зачем тратить деньги на переписывание, если можно вбить очередной костыль