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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Виталий Хахмович

Добрый день.

Прочитал массивный кусок этого треда и ваших комментариев в частности.

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

Каким образом вы видите развитие навыков проектирования у бывших студентов, которые становятся программистами (и нужно ли им это вообще)? Ну и как собственно развивать эти навыки у себя?  Существует ли какой-то системный подход для этого?

Было бы круто, если бы вы написали статью на эту тему, потому что видно по крайней мере по тому, что вы пишите, что у вас довольно большой опыт.

Ответить
Развернуть ветку
Илитный Иксперт
Каким образом вы видите развитие навыков проектирования у бывших студентов, которые становятся программистами

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

Ну и как собственно развивать эти навыки

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

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

Поэтому стоит выбирать проекты, где еще нет готовых решений. Игры (Хотя сейчас есть unity где тоже все готовенькое), библиотеки, фреймворки. Помню раньше был бум писателей своих CMS с которых многие угарали, но это наверное один из лучших примеров для обучения. Пользоваться этими говноcms конечно никто не будет, но чтобы навыки прокачать - лучше не придумаешь.

По опыту чтобы начать понимать как проектировать - надо 2-3 проекта. До этого количества ты тупо не понимаешь что и как. Нужно хотябы один проект похоронить под тяжестью архитектуры, чтобы отбить тягу к оверинжинирингу.

Существует ли какой-то системный подход для этого?

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

И избегайте чтения хайповой литературы: чистая архитектура, банда четырех, TDD и т.п. Читать такое не имея опыта - верный путь стать дурачком.

Ответить
Развернуть ветку
Виталий Хахмович

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

А какую-то профессиональную литературу имеет смысл читать в начале пути или это скорее всего принесет только вред?

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

Если сможете отличить профессиональную литературу от вредного мусора, то не помешает. Другое дело, что не имея опыта невозможно отличить.

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

Хайповую литературу читать не стоит, потому что это не проф литература вовсе. Человек с опытом понимает что там написана хуйня, а человек без опыта начинает учиться этой хуйне, а потом уже очень сложно переучить.

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