Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят

Всю свою карьеру я работал программистом в ИТ-корпорациях и вносил мизерный вклад в гигантские системы, которые никому не нужны. Но везде меня считали крутым.

Один раз я написал статью о том, как увлечение новым языком программирования спасло меня от выгорания. Её прочитало много людей, и меня позвали работать в стартап. Предложение было заманчивым, ребята звали меня делать реальные вещи, а не абстрактное дерьмо. Я согласился.

Собес был странным. Я привык, что обычные интервью хуже экзамена, а эти парни почти не проверяли мои технические скиллы. Они только и говорили, что за продукт хотят сделать, — я же привык обсуждать, как делать, а не что.

Мы уже тогда говорили на разных языках, но похоже, они приняли положительное решение ещё до собеса — статья внушила им, что я подхожу команде как человек. Мои скиллы их не особо интересовали. Наверное, ребята думали, что все хорошие программисты пишут код одинаково.

Когда я приступил к работе, я охренел. У них всё было сделано неправильно. Они буквально в тупую брали и решали проблемы продукта, подпирая один костыль двумя другими. Они не выстраивали хорошую архитектуру, не работали по практикам, их кодом можно было выжигать разработчикам глаза.

Я сразу сказал прямо — это не код, это дырявый пакет с мусором, мы всё здесь к чертям перепишем.

Когда много работаешь в большой корпорации, учишься убеждать людей, потому что каждый день отстаиваешь решения перед десятками крутейших инженеров. Вот есть ты — истинный технарь, настоящий мессия, человек, который один тут знает, как надо правильно вести разработку.

Эти парни такими не были — и легко купили мои аргументы, потому что и наняли меня разбираться в вещах, которые они не понимают. Не отвлекаться же от бизнеса. Я был только рад — вот у нас есть модуль, который прямо сейчас работает и решает настоящую проблему, вот у нас есть ведро, в которое мы его выкинем, и вот у нас есть план, как сделать то же самое, но нормально.

Как у любого стартапа, у этого был ограниченный бюджет. И я убедил всех, что его надо тратить на правильный код, продуманную архитектуру и глубокое тестирование. «Это самая правильная инвестиция, — настаивал я. — Знаете, почему 90% стартапов схлопываются? Потому что у них все начинает валиться из-за ранних ошибок, и весь бюджет уходит на латание дыр в прототипе, из которого они решили растить продукт, не переписывая. А могли бы разрабатывать новые фичи».

Я принес это мышление из больших компаний — там не существует никакого бюджета. Там делаем, сколько хотим, менеджеры поворчат, но ИТ-гигант все равно оплатит любой чек.

Каждый день у нас были созвоны, и каждый день парни пытались убедить меня подзабить на качество — но я каждый раз легко их переубеждал. Потому что только тот, кто сечет в качестве, может об этом убедительно спорить. Но их нытье, что вот к этому дню они планировали добавить вот эти пять фич, а вместо этого мы просто переделали то, что уже работало, начинало меня доставать.

«Эй, вы меня наняли, чтобы повысить качество разработки — мы его повышаем». Но это моя логика. Кроме логики есть ещё эмоции, и я начал сопереживать. На самом деле я понимал, что им не нужно качество. Если вы любите работать на результат — попробуйте меня понять. Представьте, что вы попали в компанию вечного процесса, где релиз вечно откладывается все дальше и дальше, и вы начинаете понимать, что никто к нему особо и не стремится. Как быстро вы сбежите?

Примерно так же я не представляю, как можно позволить себе собранный на коленке продукт.

Парни в этом стартапе, может, и хотели писать код, над которым никто не будет смеяться, но для их бизнеса такие вещи — чисто косметические. Им ведь действительно тупо нужно зафигачить, чтобы оно работало. Но признаться в этом самим себе они не могут.

Когда я это прочувствовал, я поймал себя на том, что уже третью неделю покрывал тестами модуль, который хорошо работал и не нуждался в модификациях в обозримом будущем.

Я сел, хорошенько подумал и осознал — из-за меня этот бизнес просто выкинул четыре месяца. Буквально никакого профита от того, что мы тут делали, для них нет. И никогда не будет. Я взял яйца в кулак, извинился и ушёл. В гигантскую компанию, которая всегда рада оплатить мои идеалистические порывы делать никому не нужное максимально правильным способом.

Наверное, я огромный мудак. Может и правда то, что я делаю, — это плохо, и мне нужно стать другим разрабом. Но это не так. Дело в том, что есть разрабы, которые занимаются индустрией, и есть те, кто фигачит вам продукт. Главное уметь отличать их друг от друга и ни в коем случае не ждать от индустрийщиков, что они сделают вам ваш продукт. Потому что они плевать на него хотели. На ваш продукт, на ваших пользователей, на ваш бизнес и на вас самих.

Они легко убедят вас на собесе, что ваши разрабы — говно собачье, а то, что вы уже сделали, — игрушечный прототип, который прямо сейчас надо сесть и написать нормально. Они не мудаки, их учили решать другие проблемы.

Если бы вам как-нибудь довелось саппортить проект, которому десять лет, вы бы поняли, откуда тут растут ноги. Но конкретно для вас сейчас вот что важно — если у стартапа возникают проблемы с поддержкой старого кода, значит, у вас все просто отлично. Значит, вы уже запустились, зарабатываете бабки, пришло время становиться большой корпорацией и нанимать хороших программистов, которые будут месяцами копаться в каждом модуле.

А до тех пор — гоните этих умников в шею. Они пришли к вам не ваши проблемы решать. Они пришли вести исследования, качать свой скилл и уходить на более жирное место.

Если ваш кандидат на должность СТО рассказывает про программирование с горящими глазами, часто говорит об архитектуре, фреймворках и прочем — это тот самый парень. И от него будут одни чертовы проблемы.

Моя история со стартапом была два года назад, и я даже не помню, что там был за проект. Вообще ничего не помню. Все мои друзья — такие же разрабы, как я, — работают точно таким же образом. Мы живем ради развития индустрии и разработки, а не ради говноприложений для людей, которые не отличают джаву от джаваскрипта.

А вот кто действительно нужен для разработки приложений — это ребятки, которые услышали про зарплаты в ИТ и научились программировать за полгода ради денег. Такие, кому плевать на элегантность подходов функционального программирования. Тех, кто на досуге читает книжки про бизнес, а не про домейн драйвен девелопмент. И они работают вот так — тупо делают в срок, что им сказано. И это именно то, что тебе нужно, пока над твоим проектом работает меньше сотни человек.

0
397 комментариев
Написать комментарий...
Илитный Иксперт
Не нанимайте крутых программистов

Начнем с того, что Фил не имеет отношения к крутым программистам. Ну может он конечно общался с ними, жал им руки. Но сам - нет.

Крутость программиста - это не написать идеальную архитектуру по книжкам теоретиков, не покрыть 100% кода тестам, не придумать идеальные названия и понятные комментария функциям и переменным. То что я сейчас перечислил - это долбоебизм.

Крутость - это сделать качественный продукт соответствующий требованиям, за адекеватное время, с приемлимым уровнем говна и костылей. 

Не надо противопоставлять говно на коленке и вылизанный идеальный проект. Это две стороны задней части медали. Опытный разраб пишет быстро и на коленке нормально, не вылизано, но и не говно.

Крутая архитектура это не когда как в книжках, от профессоров, которые ничего кроме текста лаб не писали. А когда 95% фич влезает в нее без коренных переделок проекта. Это когда там где с высокой долей вероятностью будут изменения, оставлен задел. А где их скорее всего не будет - нет никаких личшний слоев или абстракций. 

Хорошие тесты - это не 100% покрытие, а тесты в местах где ошибки реально критичны, и где ошибок и времени на их фикс больше чем на написание тестов. И уж тем более ни тогда, когда код или архитектура проекта специально приспосабливается под тесты - это конечная остановочка.

Качественно писать код - это не 0 костылей, это костыль вместо переписывания половины проекта, это знать где костыль лучше вместо рефакторинга. 

Рефакторинг - это не переименование методов или чистка кода от легаси. Рефакторинг, это перестрока здания на живую, это знать где лучше оставить как есть, а где цена недель отлова новых багов дешевле, чем оставить как есть.

А вообще начинать технический стартап не имея скилла в этой области или доверенного человека с такими скиллами - это лотерея.

Ответить
Развернуть ветку
Павел Костюнин

Любой костыль - это сохранение текущего времени в ущерб будущему. При чем затраченное время нарастает по экспоненте в зависимости от наложенности костылей. Вы никогда заранее не узнаете какая часть проекта будет меняться, а какая нет.
Костыль - это затрата и времени, и ресурсов. Проект, разработанный по общепринятым правилам, может поддерживаться меньшим числом разработчиков, а вовлечение нового разработчика требует минимальных ресурсов. Названный вами «долбоебизм» сохраняет огромную кучу ресурсов при масштабировании проекта при чем в любом направлении.

По теме поста: соглашусь, что качество кода уходит на второй план у стартапов, в угоду бизнес задачам. Качество кода дает плоды в долгосрочной перспективе, а у стартапов есть необходимость получить инвестиции и охватывать рынок прямо сейчас. Но если стартап выходит на «плато», то продолжать существование на костылях все равно, что ехать на машине на ручнике - и медленно, и ресурсов уйдет в разы больше. 

Ответить
Развернуть ветку
Илитный Иксперт
Любой костыль - это сохранение текущего времени в ущерб будущему

Старо как мир, каждый джун в свое время так считает. Вот только в теории все правильно, а на практике - все вообще не так.

Проект, разработанный по общепринятым правилам, может поддерживаться меньшим числом разработчиков, а вовлечение нового разработчика требует минимальных ресурсов

Только никаких общепринятых правил не существует, только лишь иллюзия их существования. Каждый дурачок трактует эти правила по своему, в итоге если ними не следить и по рукам не давать, проект засирается в нулину. К сожалению, в реальной жизни минимальные ресурсы требуются только на вовлечение шарящих людей.

При чем затраченное время нарастает по экспоненте в зависимости от наложенности костылей

На заре своей карьеры я тоже так считал, но на практике это охуенно спорное утверждение. Зависит от базовой архитектуры проекта, вида, места и количества костылей. Если у вас несущая стена на костылях, вам пизда. А если дом выстроен грамотно, то по большому счету плевать сколько мусора у вас на балконе.

Названный вами «долбоебизм» сохраняет огромную кучу ресурсов при масштабировании проекта при чем в любом направлении.

Да, да, да. Бездумное покрытие тестами всего и вся, многочасовой срач в код ревью по теме названий методов - сохраняет кучу ресурсов. Сами то понимаете что говорите?

Отвечу за вас - не понимаете, потому что серьезного практического опыта не имеете. Любой опытный разраб по вашему коменту это выкупит. Вы приводите в качестве аргументво слова которых не понимаете.

Вот вы говорите "качество кода". А что это такое? В чем измеряется? С ходу ответите? Какой код качественный, а какой нет?

Или например

Вы никогда заранее не узнаете какая часть проекта будет меняться, а какая нет.

Это вы не знаете. А нормальный разраб может прикинуть вероятность этих изменений. Хотя это может прикинуть даже человек, который в универе теорвер прогуливал. И если вероятность околнулевая он ресурсы тратить не будет, а вы будете, а потом еще с помпой расскажете как много вы секономили.

Или еще например

Костыль - это затрата и времени, и ресурсов.

Вы бы хоть мой комент до конца прочитали. Я же там написал, иногда костыль это не тратить месяц на переделку полпроекта.

Да, костыли - это технический долг. Но в профессию разработчика входит и понимание того какие долги выгодно закрыть как можно быстрее, какие просто обслуживаить, а с какими можно обращатсья как с госдолгом США, всмысле что их никогда не придется отдавать.

Вот честно, наберитесь опыт сначала перед тем как спорить. 

Ответить
Развернуть ветку
vic buynoff

Любой костыль в проекте - это потенциальный еще костыль, и еще, и еще. Десять костылей уже архитектура, и каждая новая фича или багфикс добавляют новые костыли. Костыльность растет системно до тех пор, пока вся эта хрень не перестает работать в принципе, и тогда приходится брать и переписывать с нуля. А с нуля хрен перепишешь, потому что кода столько, что целая рота разрабов за год не справится. И тогда приходит писец.

Ответить
Развернуть ветку
Илитный Иксперт

Ну и давайте будем честны, проектов совсем без костылей не существует в природе. Если не считать таковыми - hello world

Ответить
Развернуть ветку
vic buynoff

Есть разница - проект с костылями, и проект полностью построенный на костылях. В данной статье речь о втором варианте.

Ответить
Развернуть ветку
Илитный Иксперт

Автор неспособен отличить одно от другого в виду отсутствия нужных для этого навыков, так что статья не может быть об этом.

И писать проект на коленке не значит строить его на костылях. 

Ответить
Развернуть ветку
vic buynoff

Автор ровно такой же, как 99% остальных разрабов. Лично я в скольких проектах работал, ни разу не видел ГРАМОТНОЙ архитектуры, ГРАМОТНОГО планирования разработки и т.п. Это настолько редкость, что пора в Красную книгу заносить.

Ответить
Развернуть ветку
Илитный Иксперт
Лично я в скольких проектах работал, ни разу не видел ГРАМОТНОЙ архитектуры

Ну так расскажите что такое по вашему грамотная архитектура

Автор ровно такой же, как 99% остальных разрабов.

Перебарщиваете, в индустрии все не настолько плохо

Ответить
Развернуть ветку
vic buynoff

Готовы ответить за всю индустрию? Успехов.

Ответить
Развернуть ветку
Илитный Иксперт

Вы хотябы на мой коментарий ответьте

Ответить
Развернуть ветку
vic buynoff
 Ну так расскажите что такое по вашему грамотная архитектура

Это комплексный вопрос, на который в одном посте не ответишь; на него многие пытались ответить (так что ответов достаточно), в последнее время на него подзабили - всё правда, надо фигачить продукты и фичи, жизненный цикл короток и на раскачку нет времени (с).

Ответить
Развернуть ветку
Илитный Иксперт
на него многие пытались ответить (так что ответов достаточно)

Так я ваш ответ хочу услышать, а не чужие.

Ладно, забейте, вы скучно тролите

Ответить
Развернуть ветку
394 комментария
Раскрывать всегда