Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят
Всю свою карьеру я работал программистом в ИТ-корпорациях и вносил мизерный вклад в гигантские системы, которые никому не нужны. Но везде меня считали крутым.
Один раз я написал статью о том, как увлечение новым языком программирования спасло меня от выгорания. Её прочитало много людей, и меня позвали работать в стартап. Предложение было заманчивым, ребята звали меня делать реальные вещи, а не абстрактное дерьмо. Я согласился.
Собес был странным. Я привык, что обычные интервью хуже экзамена, а эти парни почти не проверяли мои технические скиллы. Они только и говорили, что за продукт хотят сделать, — я же привык обсуждать, как делать, а не что.
Мы уже тогда говорили на разных языках, но похоже, они приняли положительное решение ещё до собеса — статья внушила им, что я подхожу команде как человек. Мои скиллы их не особо интересовали. Наверное, ребята думали, что все хорошие программисты пишут код одинаково.
Когда я приступил к работе, я охренел. У них всё было сделано неправильно. Они буквально в тупую брали и решали проблемы продукта, подпирая один костыль двумя другими. Они не выстраивали хорошую архитектуру, не работали по практикам, их кодом можно было выжигать разработчикам глаза.
Я сразу сказал прямо — это не код, это дырявый пакет с мусором, мы всё здесь к чертям перепишем.
Когда много работаешь в большой корпорации, учишься убеждать людей, потому что каждый день отстаиваешь решения перед десятками крутейших инженеров. Вот есть ты — истинный технарь, настоящий мессия, человек, который один тут знает, как надо правильно вести разработку.
Эти парни такими не были — и легко купили мои аргументы, потому что и наняли меня разбираться в вещах, которые они не понимают. Не отвлекаться же от бизнеса. Я был только рад — вот у нас есть модуль, который прямо сейчас работает и решает настоящую проблему, вот у нас есть ведро, в которое мы его выкинем, и вот у нас есть план, как сделать то же самое, но нормально.
Как у любого стартапа, у этого был ограниченный бюджет. И я убедил всех, что его надо тратить на правильный код, продуманную архитектуру и глубокое тестирование. «Это самая правильная инвестиция, — настаивал я. — Знаете, почему 90% стартапов схлопываются? Потому что у них все начинает валиться из-за ранних ошибок, и весь бюджет уходит на латание дыр в прототипе, из которого они решили растить продукт, не переписывая. А могли бы разрабатывать новые фичи».
Я принес это мышление из больших компаний — там не существует никакого бюджета. Там делаем, сколько хотим, менеджеры поворчат, но ИТ-гигант все равно оплатит любой чек.
Каждый день у нас были созвоны, и каждый день парни пытались убедить меня подзабить на качество — но я каждый раз легко их переубеждал. Потому что только тот, кто сечет в качестве, может об этом убедительно спорить. Но их нытье, что вот к этому дню они планировали добавить вот эти пять фич, а вместо этого мы просто переделали то, что уже работало, начинало меня доставать.
«Эй, вы меня наняли, чтобы повысить качество разработки — мы его повышаем». Но это моя логика. Кроме логики есть ещё эмоции, и я начал сопереживать. На самом деле я понимал, что им не нужно качество. Если вы любите работать на результат — попробуйте меня понять. Представьте, что вы попали в компанию вечного процесса, где релиз вечно откладывается все дальше и дальше, и вы начинаете понимать, что никто к нему особо и не стремится. Как быстро вы сбежите?
Примерно так же я не представляю, как можно позволить себе собранный на коленке продукт.
Парни в этом стартапе, может, и хотели писать код, над которым никто не будет смеяться, но для их бизнеса такие вещи — чисто косметические. Им ведь действительно тупо нужно зафигачить, чтобы оно работало. Но признаться в этом самим себе они не могут.
Когда я это прочувствовал, я поймал себя на том, что уже третью неделю покрывал тестами модуль, который хорошо работал и не нуждался в модификациях в обозримом будущем.
Я сел, хорошенько подумал и осознал — из-за меня этот бизнес просто выкинул четыре месяца. Буквально никакого профита от того, что мы тут делали, для них нет. И никогда не будет. Я взял яйца в кулак, извинился и ушёл. В гигантскую компанию, которая всегда рада оплатить мои идеалистические порывы делать никому не нужное максимально правильным способом.
Наверное, я огромный мудак. Может и правда то, что я делаю, — это плохо, и мне нужно стать другим разрабом. Но это не так. Дело в том, что есть разрабы, которые занимаются индустрией, и есть те, кто фигачит вам продукт. Главное уметь отличать их друг от друга и ни в коем случае не ждать от индустрийщиков, что они сделают вам ваш продукт. Потому что они плевать на него хотели. На ваш продукт, на ваших пользователей, на ваш бизнес и на вас самих.
Они легко убедят вас на собесе, что ваши разрабы — говно собачье, а то, что вы уже сделали, — игрушечный прототип, который прямо сейчас надо сесть и написать нормально. Они не мудаки, их учили решать другие проблемы.
Если бы вам как-нибудь довелось саппортить проект, которому десять лет, вы бы поняли, откуда тут растут ноги. Но конкретно для вас сейчас вот что важно — если у стартапа возникают проблемы с поддержкой старого кода, значит, у вас все просто отлично. Значит, вы уже запустились, зарабатываете бабки, пришло время становиться большой корпорацией и нанимать хороших программистов, которые будут месяцами копаться в каждом модуле.
А до тех пор — гоните этих умников в шею. Они пришли к вам не ваши проблемы решать. Они пришли вести исследования, качать свой скилл и уходить на более жирное место.
Если ваш кандидат на должность СТО рассказывает про программирование с горящими глазами, часто говорит об архитектуре, фреймворках и прочем — это тот самый парень. И от него будут одни чертовы проблемы.
Моя история со стартапом была два года назад, и я даже не помню, что там был за проект. Вообще ничего не помню. Все мои друзья — такие же разрабы, как я, — работают точно таким же образом. Мы живем ради развития индустрии и разработки, а не ради говноприложений для людей, которые не отличают джаву от джаваскрипта.
А вот кто действительно нужен для разработки приложений — это ребятки, которые услышали про зарплаты в ИТ и научились программировать за полгода ради денег. Такие, кому плевать на элегантность подходов функционального программирования. Тех, кто на досуге читает книжки про бизнес, а не про домейн драйвен девелопмент. И они работают вот так — тупо делают в срок, что им сказано. И это именно то, что тебе нужно, пока над твоим проектом работает меньше сотни человек.
Начнем с того, что Фил не имеет отношения к крутым программистам. Ну может он конечно общался с ними, жал им руки. Но сам - нет.
Крутость программиста - это не написать идеальную архитектуру по книжкам теоретиков, не покрыть 100% кода тестам, не придумать идеальные названия и понятные комментария функциям и переменным. То что я сейчас перечислил - это долбоебизм.
Крутость - это сделать качественный продукт соответствующий требованиям, за адекеватное время, с приемлимым уровнем говна и костылей.
Не надо противопоставлять говно на коленке и вылизанный идеальный проект. Это две стороны задней части медали. Опытный разраб пишет быстро и на коленке нормально, не вылизано, но и не говно.
Крутая архитектура это не когда как в книжках, от профессоров, которые ничего кроме текста лаб не писали. А когда 95% фич влезает в нее без коренных переделок проекта. Это когда там где с высокой долей вероятностью будут изменения, оставлен задел. А где их скорее всего не будет - нет никаких личшний слоев или абстракций.
Хорошие тесты - это не 100% покрытие, а тесты в местах где ошибки реально критичны, и где ошибок и времени на их фикс больше чем на написание тестов. И уж тем более ни тогда, когда код или архитектура проекта специально приспосабливается под тесты - это конечная остановочка.
Качественно писать код - это не 0 костылей, это костыль вместо переписывания половины проекта, это знать где костыль лучше вместо рефакторинга.
Рефакторинг - это не переименование методов или чистка кода от легаси. Рефакторинг, это перестрока здания на живую, это знать где лучше оставить как есть, а где цена недель отлова новых багов дешевле, чем оставить как есть.
А вообще начинать технический стартап не имея скилла в этой области или доверенного человека с такими скиллами - это лотерея.
Любой костыль - это сохранение текущего времени в ущерб будущему. При чем затраченное время нарастает по экспоненте в зависимости от наложенности костылей. Вы никогда заранее не узнаете какая часть проекта будет меняться, а какая нет.
Костыль - это затрата и времени, и ресурсов. Проект, разработанный по общепринятым правилам, может поддерживаться меньшим числом разработчиков, а вовлечение нового разработчика требует минимальных ресурсов. Названный вами «долбоебизм» сохраняет огромную кучу ресурсов при масштабировании проекта при чем в любом направлении.
По теме поста: соглашусь, что качество кода уходит на второй план у стартапов, в угоду бизнес задачам. Качество кода дает плоды в долгосрочной перспективе, а у стартапов есть необходимость получить инвестиции и охватывать рынок прямо сейчас. Но если стартап выходит на «плато», то продолжать существование на костылях все равно, что ехать на машине на ручнике - и медленно, и ресурсов уйдет в разы больше.
Старо как мир, каждый джун в свое время так считает. Вот только в теории все правильно, а на практике - все вообще не так.
Проект, разработанный по общепринятым правилам, может поддерживаться меньшим числом разработчиков, а вовлечение нового разработчика требует минимальных ресурсовТолько никаких общепринятых правил не существует, только лишь иллюзия их существования. Каждый дурачок трактует эти правила по своему, в итоге если ними не следить и по рукам не давать, проект засирается в нулину. К сожалению, в реальной жизни минимальные ресурсы требуются только на вовлечение шарящих людей.
При чем затраченное время нарастает по экспоненте в зависимости от наложенности костылейНа заре своей карьеры я тоже так считал, но на практике это охуенно спорное утверждение. Зависит от базовой архитектуры проекта, вида, места и количества костылей. Если у вас несущая стена на костылях, вам пизда. А если дом выстроен грамотно, то по большому счету плевать сколько мусора у вас на балконе.
Названный вами «долбоебизм» сохраняет огромную кучу ресурсов при масштабировании проекта при чем в любом направлении.Да, да, да. Бездумное покрытие тестами всего и вся, многочасовой срач в код ревью по теме названий методов - сохраняет кучу ресурсов. Сами то понимаете что говорите?
Отвечу за вас - не понимаете, потому что серьезного практического опыта не имеете. Любой опытный разраб по вашему коменту это выкупит. Вы приводите в качестве аргументво слова которых не понимаете.
Вот вы говорите "качество кода". А что это такое? В чем измеряется? С ходу ответите? Какой код качественный, а какой нет?
Или например
Вы никогда заранее не узнаете какая часть проекта будет меняться, а какая нет.Это вы не знаете. А нормальный разраб может прикинуть вероятность этих изменений. Хотя это может прикинуть даже человек, который в универе теорвер прогуливал. И если вероятность околнулевая он ресурсы тратить не будет, а вы будете, а потом еще с помпой расскажете как много вы секономили.
Или еще например
Костыль - это затрата и времени, и ресурсов.Вы бы хоть мой комент до конца прочитали. Я же там написал, иногда костыль это не тратить месяц на переделку полпроекта.
Да, костыли - это технический долг. Но в профессию разработчика входит и понимание того какие долги выгодно закрыть как можно быстрее, какие просто обслуживаить, а с какими можно обращатсья как с госдолгом США, всмысле что их никогда не придется отдавать.
Вот честно, наберитесь опыт сначала перед тем как спорить.
Любой костыль в проекте - это потенциальный еще костыль, и еще, и еще. Десять костылей уже архитектура, и каждая новая фича или багфикс добавляют новые костыли. Костыльность растет системно до тех пор, пока вся эта хрень не перестает работать в принципе, и тогда приходится брать и переписывать с нуля. А с нуля хрен перепишешь, потому что кода столько, что целая рота разрабов за год не справится. И тогда приходит писец.
Перечитайте это:
Зависит от базовой архитектуры проекта, вида, места и количества костылей. Если у вас несущая стена на костылях, вам пизда. А если дом выстроен грамотно, то по большому счету плевать сколько мусора у вас на балконе.Короче, надо знать куда костыли пихать можно, а куда вообще никак нельзя. А проекты совсем без костылей это утопия
Костыльность растет системно до тех пор, пока вся эта хрень не перестает работать в принципеА такое получается не изза костыльности, а изза отуствия навыка проектирования. С описанным вами подходом результат будет тот же и без костылей.
Ну и давайте будем честны, проектов совсем без костылей не существует в природе. Если не считать таковыми - hello world
И за hello world я не уверен, так как такую простую функцию сделать на высокоуровневом языке вместо ассемблера, считай костыль )))))
Разработчики - уникальные инвалиды, любящие костыли.
- Ты хотел сказать индивиды?
- Нет.
Есть разница - проект с костылями, и проект полностью построенный на костылях. В данной статье речь о втором варианте.
Автор неспособен отличить одно от другого в виду отсутствия нужных для этого навыков, так что статья не может быть об этом.
И писать проект на коленке не значит строить его на костылях.
Автор ровно такой же, как 99% остальных разрабов. Лично я в скольких проектах работал, ни разу не видел ГРАМОТНОЙ архитектуры, ГРАМОТНОГО планирования разработки и т.п. Это настолько редкость, что пора в Красную книгу заносить.
Ну так расскажите что такое по вашему грамотная архитектура
Автор ровно такой же, как 99% остальных разрабов.Перебарщиваете, в индустрии все не настолько плохо
Готовы ответить за всю индустрию? Успехов.
Вы хотябы на мой коментарий ответьте
Это комплексный вопрос, на который в одном посте не ответишь; на него многие пытались ответить (так что ответов достаточно), в последнее время на него подзабили - всё правда, надо фигачить продукты и фичи, жизненный цикл короток и на раскачку нет времени (с).
Так я ваш ответ хочу услышать, а не чужие.
Ладно, забейте, вы скучно тролите
у вас есть реальные ваши проекты что конкретно из за того что архитектура не была прекрасна и он загнулся?
потому что когда таким оперируют в воздух - это из разряда бизнес школ - рассказывают как строить реальный бизнес, не имея такого у себя
Я по своему опыту чаще наблюдал - когда какой-то пистюк приходит рассказывает как прально, пыжится и сливается через пару месяцев. Как вместо решения в лоб, городят кучу классов либ и тп зато по бестпрактис, где подключить нового разраба боль и страдание на несколько мес.
У меня их есть, много, некоторые с крутым финансированием, но через год разработки убитые исключительно из-за того, что система дерьмово спроектирована, на ногах не стоит и вообще практически не живет.
Поэтому не надо тут рассказывать про свой опыт с пиздюками, он комичен но не более.
Ты нормально умеешь разговаривать? Че ты как истеричная мамка всех дерьмом поливаешь. Ты думаешь, что умный, а по факту - клоун какой-то. С тобой нормально, а ты - клоун.
Лол, ты че, серьезно зарегался чтобы показать как тебя триггернуло? Мне уже даже инетресно на что конкретно ты так обижаешься
Бывают такие костыли, что век стоят - не шелохнутся. 10 раз "good practice" поменяется в индустрии, а костыль - вот он, стоит красавец, только крепче стал.
Да и вообще, хорошо документированный костыль - не костыль вовсе, а "решение проблематичного состояния программы".
А потом костыль перерастает в CVE, остаётся только гадать сколько лет им пользовались не по назначению 😄
В старом заброшенном модуле, который век не менялся, фичи туда не добавлялись и баги не фиксились - возможно, такое бывает.
Костыли они как и люди, которые которые о них говорят, слишком разные бывают. Я вот знавал одного человека, который всерьез мне рассказывал о том что jquery это костыль. Спорить трудно потому что с точки зрения удобных селекторов может и костыль, а с точки зрения кучи другого функционала вполне себе годная либа, которой пол мира еще какое то время назад активно пользовалось. Но одно знаю точно, человече этот, никогда не пользовал jquery, и на js никогда не писал...
Работаю в большой компании. Там этот принцип реализован даже в большей степени, чем маленьких. Возможно, многие проекты начинались крутыми программистами и были тщательно продуманы, но те крутые программисты давно ушли или получили повышение. Код дорабатывали многие программисты, которые не знакомы ни с основателями проекта, ни друг с другом. Естественно, ни времени, ни желания разбираться в том, какие идеи были заложены в коде, ни у кого не было. В результате проект состоит из бессвязного говнокода. Никакого тебе рефакторинга. Времени и ресурсов на него нет. Бизнес давит сроками. Нужно всё сделать через неделю, а в идеале сегодня. Притом, что аналитика будет утверждена ещё через месяц. Ибо надо получить 100500 согласований. И скорее всего, техзадание несколько раз поменяется в процессе. И возможно, задача будет отменена. В результате, качество кода - это последнее, что кого-то интересует. В большой компании основной показатель - закрыть задачу в срок.
Если стартовали нормальные программисты это здание простоит и с вашей мансардой
Стартовали нормальные программисты. Только потом никто не разбирался, как они представляли развитие проекта и представляли-ли вообще. А практика показывает, что как раз крутые программисты пытаются сделать идеальную архитектуру, а бизнесу наплевать на архитектуру, его желания меняются на ходу. И по факту ваша мансарда будет пристроена к 3 этажу 20-этажного здания, будет стоять на столбах и будет иметь вход по лестнице с 10 этажа.
Но здание же не обрушится, я видывал те здания которые рушились от таких конструкций
Не обрушится. Но ни о какой качественной архитектуре, эффективности и надёжности кода и речи не идёт.
Скорее я могу представить качественную архитектуру в маленькой фирме, где несколько программистов вылизывают код, как им нравится, знают друг друга и не стеснены бюрократией и толпой согласующих.
ну я к тому, веду что требования бизнеса всегда норовят ух.ючить проект, до невменяемого уровня. Но все эти пристройки можно снести и построить нормально если проект сделан годно. Я прекрасно понимаю ту ситуацию в которой вы находитесь.
ПОэтому я всегда когда согласую даю людям выбор типа х.ево месяц, ох.уенно 3 месяца, если согласятся на месяц, то я начну на них вешать собак с производительностью и через пол. года они начинают просить на ох.енно
Вы то может и будете пытаться делать хорошо. А десяток других программистов параллельно нафигачат кучу костылей, угробят все ваши красивые паттерны, закроют свои задачи и молодцы в глазах бизнеса. А бизнес, видя, что вы копаетесь со своим ох.енно, передаст ваши задачи им, и они недолго думая, сделают х.во, зато быстро. Бизнес всегда выбирает скорость, даже если через месяц нужно будет всё переделывать.
Плохой бизнес выбирает скорость. Это из своей практики наблюдение.
Хороший бизнес, все время в поисках поставщика качественных услуг.
С этим всегда проблема. по крайней мере сейчас.
Быстрых лидов я могу набрать по 12рублей за клик. Но от них одни проблемы они хотят за пол копейки миллион. И когда ты им говоришь, что из этого куска шерсти сделаешь 7 шапок, но они будут не по их размеру им пофиг. Поэтому работая с таким бизнесом будет fail = fail.
В случае с качественными услугами работает только сарафан. Вас будут советовать как человека, который не тот вася который сделал за пол копейки, и все развалилось.
А тот кто сделал и оно работает и один раз взял много, но потом не дописывал свои баги за ваши деньги.
Это мой опыт среднего малого, и маленький кусок крупного бизнеса. Я не претендую на 100% верность своего опыта. просто делюсь тем, что уяснил за 10 лет.
1 в 1 быстробанк, такая рыба гниет с головы. Предлагайте быстро или хорошо. Так вы хоть совесть свою успокоите. А по чесноку программист всегда будет балансировать между быстро и качество. Зависнуть в одной из этих позиций значит, не быть хорошим прогом.
"В большой компании основной показатель - закрыть задачу в срок."
В маленькой это главный показатель + чтобы включалось/было похоже на правду
"В большой компании основной показатель - закрыть задачу в срок."
Зависит от вашего непосредственного руководителя, тут уже корпоративное дерьмо начинается, от которого я сбежал.
Спорные утверждения с самого начала. Давайте я простой пример из жизни приведу: Вы делаете А/Б тест. Вообще если вы нормальная компания - вы всегда делаете А/Б тесты. Так вот, если вы будете писать на каждый тест супер крутой идеальный код без костылей - вы увеличиваете нагрузку на разработку в разы и выкидываете время (а значит - деньги) на ветер. Если вы хороший разработчик, вы понимаете, что это А/Б тест который с вероятностью 50--60-70-90% будет выкинут в корозину. И в данном случае задача номер 1 сделать чтобы оно работало. А вот после принятия результатов А/Б - код уже можно отрефакторить с делать лучше.
Это пример - самый прямой, но абсолютно четко показывающий случай когда вставление костылей однозначно означает не "это сохранение текущего времени в ущерб будущему", а как раз просто "сохранение общего времени на разработку" вообще без ущерба.
Также как и "никто не знает что будет меняться". Если вы делаете большой проект, и в нем есть, ну, грубо говоря, абстракция работы с БД - она меняться не будет (другой вопрос, что хороший разработчик редко будет писать свою, но возьмет готовую - тем не менее это тоже утрированный, но пример тех кусков, про которые можно более-менее заранее понимать, что это место меняться если и будет то только в сторону усложнения, и здесь к коду нужно подходить куда ответственнее чем при разработке тестовой функции, которая скорее не взлетит чем взлетит".
Поправлю
Вы делаете А/Б тест. Вообще если вы нормальная компания - вы всегда делаете А/Б тестыЕсли вы не сервис с большим трафиком ("большой" - от индустрии зависит), то вы даже А/Б тест не делаете. Потому что вам нужен кратный рост аудитории, а не выжать еще чуть-чуть монетизации из текущей. А кратный рост и так видно
Тут какое дело... тёртый разработчик уже усвоил, что хрен когда ему потом дадут переписать по-нормальному. Поэтому, сразу старается сделать по-нормальному, если, конечно, не променял профессиональную гордость на жвачку в пятом классе
"Любой костыль - это сохранение текущего времени в ущерб будущему". верно в теории, но на практике есть два серьезных "но". 1-ое "но" - "сохранение текущего времени" происходит 100%, а вот "ущерб в будущем" наступает примерно "50/50". и 2-ое "но". сохранение времени, а значит более быстрый запуск позволяет быстрее заработать первые деньги (утрирую). кто играл в игры типа "варкрафт/старкрафт", знает силу умелого быстрого "раша" (rush) на ранних стадиях игры. так вот тут примерно то же самое.