Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят
Всю свою карьеру я работал программистом в ИТ-корпорациях и вносил мизерный вклад в гигантские системы, которые никому не нужны. Но везде меня считали крутым.
Один раз я написал статью о том, как увлечение новым языком программирования спасло меня от выгорания. Её прочитало много людей, и меня позвали работать в стартап. Предложение было заманчивым, ребята звали меня делать реальные вещи, а не абстрактное дерьмо. Я согласился.
Собес был странным. Я привык, что обычные интервью хуже экзамена, а эти парни почти не проверяли мои технические скиллы. Они только и говорили, что за продукт хотят сделать, — я же привык обсуждать, как делать, а не что.
Мы уже тогда говорили на разных языках, но похоже, они приняли положительное решение ещё до собеса — статья внушила им, что я подхожу команде как человек. Мои скиллы их не особо интересовали. Наверное, ребята думали, что все хорошие программисты пишут код одинаково.
Когда я приступил к работе, я охренел. У них всё было сделано неправильно. Они буквально в тупую брали и решали проблемы продукта, подпирая один костыль двумя другими. Они не выстраивали хорошую архитектуру, не работали по практикам, их кодом можно было выжигать разработчикам глаза.
Я сразу сказал прямо — это не код, это дырявый пакет с мусором, мы всё здесь к чертям перепишем.
Когда много работаешь в большой корпорации, учишься убеждать людей, потому что каждый день отстаиваешь решения перед десятками крутейших инженеров. Вот есть ты — истинный технарь, настоящий мессия, человек, который один тут знает, как надо правильно вести разработку.
Эти парни такими не были — и легко купили мои аргументы, потому что и наняли меня разбираться в вещах, которые они не понимают. Не отвлекаться же от бизнеса. Я был только рад — вот у нас есть модуль, который прямо сейчас работает и решает настоящую проблему, вот у нас есть ведро, в которое мы его выкинем, и вот у нас есть план, как сделать то же самое, но нормально.
Как у любого стартапа, у этого был ограниченный бюджет. И я убедил всех, что его надо тратить на правильный код, продуманную архитектуру и глубокое тестирование. «Это самая правильная инвестиция, — настаивал я. — Знаете, почему 90% стартапов схлопываются? Потому что у них все начинает валиться из-за ранних ошибок, и весь бюджет уходит на латание дыр в прототипе, из которого они решили растить продукт, не переписывая. А могли бы разрабатывать новые фичи».
Я принес это мышление из больших компаний — там не существует никакого бюджета. Там делаем, сколько хотим, менеджеры поворчат, но ИТ-гигант все равно оплатит любой чек.
Каждый день у нас были созвоны, и каждый день парни пытались убедить меня подзабить на качество — но я каждый раз легко их переубеждал. Потому что только тот, кто сечет в качестве, может об этом убедительно спорить. Но их нытье, что вот к этому дню они планировали добавить вот эти пять фич, а вместо этого мы просто переделали то, что уже работало, начинало меня доставать.
«Эй, вы меня наняли, чтобы повысить качество разработки — мы его повышаем». Но это моя логика. Кроме логики есть ещё эмоции, и я начал сопереживать. На самом деле я понимал, что им не нужно качество. Если вы любите работать на результат — попробуйте меня понять. Представьте, что вы попали в компанию вечного процесса, где релиз вечно откладывается все дальше и дальше, и вы начинаете понимать, что никто к нему особо и не стремится. Как быстро вы сбежите?
Примерно так же я не представляю, как можно позволить себе собранный на коленке продукт.
Парни в этом стартапе, может, и хотели писать код, над которым никто не будет смеяться, но для их бизнеса такие вещи — чисто косметические. Им ведь действительно тупо нужно зафигачить, чтобы оно работало. Но признаться в этом самим себе они не могут.
Когда я это прочувствовал, я поймал себя на том, что уже третью неделю покрывал тестами модуль, который хорошо работал и не нуждался в модификациях в обозримом будущем.
Я сел, хорошенько подумал и осознал — из-за меня этот бизнес просто выкинул четыре месяца. Буквально никакого профита от того, что мы тут делали, для них нет. И никогда не будет. Я взял яйца в кулак, извинился и ушёл. В гигантскую компанию, которая всегда рада оплатить мои идеалистические порывы делать никому не нужное максимально правильным способом.
Наверное, я огромный мудак. Может и правда то, что я делаю, — это плохо, и мне нужно стать другим разрабом. Но это не так. Дело в том, что есть разрабы, которые занимаются индустрией, и есть те, кто фигачит вам продукт. Главное уметь отличать их друг от друга и ни в коем случае не ждать от индустрийщиков, что они сделают вам ваш продукт. Потому что они плевать на него хотели. На ваш продукт, на ваших пользователей, на ваш бизнес и на вас самих.
Они легко убедят вас на собесе, что ваши разрабы — говно собачье, а то, что вы уже сделали, — игрушечный прототип, который прямо сейчас надо сесть и написать нормально. Они не мудаки, их учили решать другие проблемы.
Если бы вам как-нибудь довелось саппортить проект, которому десять лет, вы бы поняли, откуда тут растут ноги. Но конкретно для вас сейчас вот что важно — если у стартапа возникают проблемы с поддержкой старого кода, значит, у вас все просто отлично. Значит, вы уже запустились, зарабатываете бабки, пришло время становиться большой корпорацией и нанимать хороших программистов, которые будут месяцами копаться в каждом модуле.
А до тех пор — гоните этих умников в шею. Они пришли к вам не ваши проблемы решать. Они пришли вести исследования, качать свой скилл и уходить на более жирное место.
Если ваш кандидат на должность СТО рассказывает про программирование с горящими глазами, часто говорит об архитектуре, фреймворках и прочем — это тот самый парень. И от него будут одни чертовы проблемы.
Моя история со стартапом была два года назад, и я даже не помню, что там был за проект. Вообще ничего не помню. Все мои друзья — такие же разрабы, как я, — работают точно таким же образом. Мы живем ради развития индустрии и разработки, а не ради говноприложений для людей, которые не отличают джаву от джаваскрипта.
А вот кто действительно нужен для разработки приложений — это ребятки, которые услышали про зарплаты в ИТ и научились программировать за полгода ради денег. Такие, кому плевать на элегантность подходов функционального программирования. Тех, кто на досуге читает книжки про бизнес, а не про домейн драйвен девелопмент. И они работают вот так — тупо делают в срок, что им сказано. И это именно то, что тебе нужно, пока над твоим проектом работает меньше сотни человек.
Начнем с того, что Фил не имеет отношения к крутым программистам. Ну может он конечно общался с ними, жал им руки. Но сам - нет.
Крутость программиста - это не написать идеальную архитектуру по книжкам теоретиков, не покрыть 100% кода тестам, не придумать идеальные названия и понятные комментария функциям и переменным. То что я сейчас перечислил - это долбоебизм.
Крутость - это сделать качественный продукт соответствующий требованиям, за адекеватное время, с приемлимым уровнем говна и костылей.
Не надо противопоставлять говно на коленке и вылизанный идеальный проект. Это две стороны задней части медали. Опытный разраб пишет быстро и на коленке нормально, не вылизано, но и не говно.
Крутая архитектура это не когда как в книжках, от профессоров, которые ничего кроме текста лаб не писали. А когда 95% фич влезает в нее без коренных переделок проекта. Это когда там где с высокой долей вероятностью будут изменения, оставлен задел. А где их скорее всего не будет - нет никаких личшний слоев или абстракций.
Хорошие тесты - это не 100% покрытие, а тесты в местах где ошибки реально критичны, и где ошибок и времени на их фикс больше чем на написание тестов. И уж тем более ни тогда, когда код или архитектура проекта специально приспосабливается под тесты - это конечная остановочка.
Качественно писать код - это не 0 костылей, это костыль вместо переписывания половины проекта, это знать где костыль лучше вместо рефакторинга.
Рефакторинг - это не переименование методов или чистка кода от легаси. Рефакторинг, это перестрока здания на живую, это знать где лучше оставить как есть, а где цена недель отлова новых багов дешевле, чем оставить как есть.
А вообще начинать технический стартап не имея скилла в этой области или доверенного человека с такими скиллами - это лотерея.
Хотел написать похожий комментарий, но даже добавить нечего. Архитектурные астронавты такие астронавты... https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
А вы видели вообще большие проекты написанные без паттернов и архитектуры? По принципу лишь бы работало?
Когда например в проекте несколько однотипных бинарников с копией оболочки, общаяющиеся между собой одновременно через локальный вебсервер по http и COM+ какому-нибудь.
Или нестареющая классика вроде Microsoft Access + интеграционная обвязка на VB.
Статья хорошая и Joel не дурак, но свою голову то тоже включать рекомендуется.
Сколько раз вам паттерноебам повторять: паттерны != архитектура, и паттерны != проектирование архитектуры. Паттерны - частный случай архитектуры, и имеют весьма слабое отношение к проектированию.
Каждый раз когда вас критикуют, вас критикуют не за то что вы используете паттерны, а за то что вы не понимаете что такое слои абстракции и зачем они нужны, не знаете когда нужно добавлять поддержку расширяемости, а когда нет, не знаете к чему нужно стремиться при создании архитектуры, а что вредно и т.п.
В той же Qt такая хорошая архитектура, не потому что там паттерны, а потому что у авторов Qt помимо паттернов в голове есть целый пласт более фундаментальных знаний, которого у вас нет. А ваша профессиональная ущербность заключается в том, что вы не в состоянии понять что этот пласт вообще существует.
Вы из кубиков в майнкрафте строить научились, и решили что мир из этих кубиков состоит. А что то эти кубики сами созданы на основе неких знаний вы уже вкурить не можете. Потому что уже думаете кубиками.
Паттерны так или иначе появляются в любой архитектуре, да у них есть названия, но пытаться строить архитектуру зная только паттерны и только из них - это изначально ущербно.
Имея знания только лишь паттернов можно наклепать архитектуру только базового уровня. Для части задач этого хватает, а для другой части - нет. Типичный паттерноеб вместо Qt изобретет типичный абстрактный энтерпрайз java фрейморк.
Эту картинку к каждому спору можно прикреплять:
https://vc.ru/hr/127122-ne-nanimayte-krutyh-programmistov-esli-vy-startap-i-tolko-nachali-delat-produkt-oni-vam-vse-isportyat?comment=1834044
Ок, вот есть задача спроектировать самолет, пассажирский.
Фюзеляж, крылья, хвост, двигатели - архитектура для самолета? Архитектура. Некий базис сущностей, основа.
Есть определенные варианты расположения двигателей, длины и углов наклона крыльев, варианты хвостового оперения - паттерны для самолета? Паттерны. Набор практик, проверенных, оттестированных и дающих в итоге результат в пределах допущений паттерна.
Что подпразумевается под отказом от таких паттернов для самолета? Оч. просто - идем полностью своим путем. Временами получается Конкорд, но чаще - полный провал.
Под таким углом не пытались на проблему смотреть? Не через амбразуру хардкорной разработки?
Ну и это - переход на личности и оскорбления вас не красят, даже если есть определенный опыт и знания.
То что вы описали это строительство панельного дома из готовых типовых кусков. Почему я опять привожу пример про дома? Потому что я не слышал о том, чтобы самолеты вообще проектировали так как вы описали
Хороший авиаконструктор в первую очередь знает почему варианты разположения двигателей и крыльев именно такие, а это условные сопромат и аэродинамика, это опыт и инженерные навыки. И он может создать новые варианты разположения. И модифицировать существующие. И использовать существующие эффективно. А хуевый знает только то что эти варианты есть и их можно скомпоновать.
Это пропасть как между верстальщиком и разработчиком браузера.
Что подпразумевается под отказом от таких паттернов для самолета? Временами получается Конкорд, но чаще - полный провал.Это возможно для вас попытка мыслить вне рамок паттернов - полный провал, а для нормального инженера - каждодневная работа.
Не через амбразуру хардкорной разработки?Я уже несколько раз написал, что паттерны для того и созданы чтобы массы неквалифицированных разрабов, сидели клепали свои формы с кнопками и не делали совсем уж откровенное говно. Только это не делает их хорошими разрабами.
переход на личности и оскорбления вас не красятВ следующий раз когда вам кто-то будет рассказывать про квадратные уравнения, не стоит безапеляционно кричать этому дурачку что в матеше нельзя буквы с цифрами смешивать, тогда может ваши слова будут вызывать что-то кроме презрения.
И еще раз, вас оскорбляют не за то что вы чегото не знаете, это нормально. А за то что вы дохуя уверенно несете полную чушь по теме, о которой вообще представления не имеете.
Ну понятно, без оскорблений значит общаться не умеем.
Это печалит. Что толку от идей и мыслей если нет умения их выражать?
Берегите себя, столь агрессивное доказывание собственной правоты в интернете - прямой путь в дурдом, обнаружите себя по итогам в палате с санитарами и сказке конец.
Оно того не стоит.
Нечего сказать - доебись до вежливости.
Access + VB видел. Переписывали такой проект на .NET на заре карьеры. Но этот Access + VB несколько лет успешно решал проблемы бизнеса, плюс из него было понятно что нужно, а что нет и это было проще чем писать с нуля.
Никто и не говорит что нужно говнокодить и архитектура не нужна. Но лепить 100500 уровней абстракции там где это не нужно и использовать паттерны к месту и не к месту только потому что начитался GoF еще хуже. Так как часто это это означает не то, что будет хороший код, но позже. А как у автора - просто выкинутые 4 месяца за которые ничего полезного не было сделано.
'несколько лет успешно решал проблемы бизнеса'
Это звучало как мантра для каждого такого проекта, ага.
И что? Кончилось ведь все равно тем что пришлось раскошеливаться на команду разработки и создание с 0.
Причем полагаю вы не столкнулись со всей проблемой такого переписывания целиком - массовое переобучение пользователей например, само внедрение.
'Никто и не говорит что нужно говнокодить и архитектура не нужна.'
Тут половина комментов ровно за такое.
'Но лепить 100500 уровней абстракции'
Если честно эта фраза кочует в виде мантры из одного технического обсуждения в другое, обычно еще приводится код из Spring Framework в виде иллюстрации.
Но вот за все время работы я такое наблюдал буквально пару раз, может проблема несколько раздута?
Да, но на это появились деньги которые они заработали с помощью этого Access. И были намного понятнее требования к проекту (так бы еще на аналитиков и подробное ТЗ раскошелиться пришлось).
Причем полагаю вы не столкнулись со всей проблемой такого переписывания целиком - массовое переобучение пользователей например, само внедрение.Если сразу делать "правильно", то до выпуска продукта компания может просто не дожить. Закончатся деньги.
Этим они уже сами занимались, но у нас с UX всегда было хорошо, так что проблем не возникло.
'Но лепить 100500 уровней абстракции'Если честно эта фраза кочует в виде мантры из одного технического обсуждения в другое, обычно еще приводится код из Spring Framework в виде иллюстрации.
Но вот за все время работы я такое наблюдал буквально пару раз, может проблема несколько раздута?
По-моему это большая часть кода, написанная enterprise программистами. В моем текущем проекте как раз сейчас висит PR где меняется код для QueryBuilder для API одной системы. Который один разработчик (любитель паттернов и красивых подходов) написал чтобы сделать пару запросов. Сделать их строкой с параметрами было бы проще, понятнее и надежнее. Но написать QueryBuilder, конечно, интереснее. Это же паттерн! А паттерны это круто. В результате он потратил в 3 раза больше времени на оригинальный вариант, а я потрачу в 3 раза больше времени на review т.к. код объемнее и сложнее для понимания. Но новых запросов в ближайшее время делать не планируется, т.е. никакого выигрыша это нам не дало.
С точки зрения теоретиков от программирования он все правильно сделал. С точки зрения прагматиков вроде меня - нет. Если бы новые запросы появились, вот тогда надо было бы сделать рефакторинг и сделать этот билдер.
Все это работает для энтерпрайза, где можно развлекаться за деньги заказчика (и потешить эго программистов вроде автора поста). Но для стартапов и небольших проектов это смертельно.
'По-моему это большая часть кода, написанная enterprise программистами'
Ну а вам самому будет интересно ваять чужой закрытый проект, который будет использоваться строго в изолированной среде ( т.е. например если есть веб-интерфейс, то все клиенты 100% используют один лишь только хром фиксированных версий ), будет решать исключительно технически скучные задачи по перекладыванию строк в базе данных, в котором нет и быть не может никакой серьезной нагрузки, никаких требований по защите ( тк опять же изолированная среда внутренней сети ) и тд и тп - и все это на каком-нибудь Haskell, просто ради того что это Haskell ?
Рискнуть репутацией, лишением премии, даже увольнением и судом - все ради того чтобы типичную и банальную задачу сделать особыми средствами?
'. В моем текущем проекте как раз сейчас висит PR где меняется код для QueryBuilder для API одной системы'
Если у вас в проекте есть PR ( pull request ) полагаю есть еще и code review, в рамках которого и будет описано - пойдет это решение или нет. Обычно code review включается для уже выросших проектов, где есть какая-то стабильная база и эксплуатация - т.е это уже никак не MVP стадия, соответственно любые крупные доработки должны согласовываться.
Если сделан прям QueryBuilder ( что-то типа такого?: https://wiki.almworks.com/download/attachments/62753622/Insert%20JQL%20Query.png ) , то наверное он сделан с одобрения лида или архитектора и делался 'на вырост', а не для немедленного использования.
Рискнуть репутацией, лишением премии, даже увольнением и судом - все ради того чтобы типичную и банальную задачу сделать особыми средствами?
Забавно читать про программиста, который боится увольнения. ) Лично я не буду использовать Haskell просто потому что это Haskell, т.к. мне важно решить задачу, а не поиграться с технологиями. Но я участвовал в проекте где также начали использовать F#, например. И поскольку там он был к месту и мы использовали его только для одного модуля я был не против. В итоге из того проекта ушел я, а не тот программист, но по другим причинам - они перестали с удаленными разработчиками работать.
Если у вас в проекте есть PR ( pull request ) полагаю есть еще и code review, в рамках которого и будет описано - пойдет это решение или нет. Обычно code review включается для уже выросших проектов, где есть какая-то стабильная база и эксплуатация - т.е это уже никак не MVP стадия, соответственно любые крупные доработки должны согласовываться.Но overengeneering это тот же Haskell - тоже получается код, который потом сложно понимать и поддерживать. Но расширять немного легче. Правда зачастую только тому кто его написал.
Проблема в том что этот билдер был написан на стадии MVP, а доработки в нем приходится делать сейчас. Я его тогда пропустил, но сейчас понимаю что это было ошибкой.
Но вопрос не в этом, а в разнице подходов. Мне бы в голову не пришло для двух запросов делать билдер.
Мне кажется, что при отсутствии этого Builder'а, каждый раз, когда появлялся бы очередной новый запрос, вы бы рассуждали так же: всего лишь еще 1 (один) запрос, на фига нужен Builder? В итоге уже не то, что на рефакторинг, уже на простое выяснение, как изменить одно выражение в запросе, у кого-то после вас будет уходить 3 месяца :-)
А вот тут уже видно чем крутой программист отличается от посредственного. Крутой программист понимает когда нужно делать рефакторинг и переходить к общему решению. В данном случае я бы сказал когда запросов становится больше трех.
Получается 3 типа программистов:
- Астронавт (как автор статьи) - который сразу делает оверинженеринг просто из любви к прекрасному, не учитывая требования к проекту, навыки команды и т.д.
- Плохой программист - который все делает копи-пастой и костылями потому что не способен увидеть общей картины (тут уже в коментах кто-то писал об этом) или не умеет.
- Крутой программист - который знает где и когда можно срезать углы, но понимает когда надо делать рефакторинг и заменить предыдущее простое решение на более сложное и общее.
С запросами ситуация как раз обратная. Когда я вижу просто запрос одной строкой, мне понятно что происходит и изменения занимают пару минут. А вот в случае билдера приходится смотреть что он там нагенерил, как он работает и т.д. И если нужно добавить какие-то операции которые в билдере не были учтены (у нас например он умел только OR, а нам понадобился AND), то приходится сам билдер менять.
То есть тут трейдофф не так прост как кажется. Простое решение - надежнее, понятнее и быстрее в реализации, но сложнее расширяется и может не учитывать какие-то требования. Универсальное решение - легче расширять и учитывает больше кейсов но сложнее для понимания и дольше в реализации. При этом время реализации окупается только в случае если эта универсальность используется.
В общем-то, автор, которого вы обозвали "астронавтом", именно об этом и говорит. Что он именно "крутому программисту" приписал поведение того, кого вы "астронавтом" называете - так во-первых, тут присутствует некоторая ирония, а во-вторых, тут главный его оппонент и вовсе не стесняется матом выражаться, так что терминология и для него явно не так уж важна :-)
Проблема в том, что я не считаю астронавтов крутыми программистами. А автор, по-моему, типичный астронавт. И как любой астронавт считает себя крутым. :)
телеграм, сколько я смотрел но паттерна я так и не нашёл, что Qt что мобилы
Чего? Там чуть ли не самая чистая кодовая база из современных плюсовых проектов. Ну и весь набор десктопных паттернов типа Observer, Consumer-Producer, Listener и тд.