О чем наш стартап?

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

Логичное продолжение вопроса: тогда чем вы отличаетесь от маршрутки?
Мы — “умная маршрутка”. Мы постоянно улучшаем наши маршруты и подстраиваем их под тех, кто с нами регулярно ездит.

Почему мы ушли из женской развозки?

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

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

- Базовая цена. Если просто возить по одному ребенку, то так как ты ограничиваешь водителей по полу (а значит спрос на водителя выше), то поездки получаются где-то в 1.5 раза дороже Яндекса
- Конкурентное преимущество. Просто так бодаться в лоб с Яндексом — сильно не вырастишь. Поэтому мы поняли, что засчет того, что мы в точности знаем расписания детей, мы можем заранее планировать маршруты, чтобы каждая “мама за рулем” могла захватить нескольких детей. В результате мы снизили цены и стали примерно на равне с Яндексом
- Отмены. Порядка 20% поездок клиенты отменяли из-за болезней, коротких дней и переносов уроков. Если с этим ничего не делать, то придется эти 20% положить на плечи клиентов, а значит заново стать дороже Яндекса
- Умное планирование. Чтобы решить проблему выше, мы стали планировать поездки не на весь год или месяц, а на день вперед, таким образом делая клиентам возвраты, если они заранее делали отмены
- Подводные камни. Стоит отметить, что так как по цене и сервису мы были схожи с Яндексом, то к нам были примерно те же требования: например, клиенты не хотели платить на месяц вперед, или то что были очень высокие ожидания от мобильного приложения
- Проблемы скейлинга. Но еще большей проблемой были водители. Чтобы отвезти 2,000 детей, тебе нужно порядка 500 водителей, а с учетом того, что кто-то болеет, и у кого-то ломается машина, то мы говорим о порядке 700 “мам за рулем”. И даже на таких размерах сохранить качество уже невероятно сложно. Кто-то просыпает, кто-то опаздывает, постоянно новые маршруты и новые дети, в результате “мамы за рулем” долго их ищут, колл-центр начинает разрываться
- Решение. Стартап Kidsway решил подобную проблему засчет того, что они задрали цены в 2 раза выше Яндекса и сфокусировались на премиум сегменте. Мы понимали, что премиум сегмент намного меньше масс-маркета и не хотели туда идти

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

[leetcode] Решаем 3 medium задачи без подготовки

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

Должен ли стартап быть инновационным?

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

Наш стартап является маркетплейсом: с одной стороны у нас есть люди, создающие спрос — demand, с другой стороны водители, генерирующие предложение — supply. Задача маркетплейса — уравновесить рынок. Что это означает?

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

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

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

Что самое инновационное в Убере? Мобильное приложение? Нет! Самое важное — это ценообразование. Именно засчет умного ценообразования Уберу удается сделать так, что с одной стороны ты 20 минут не ждешь машину, а с другой стороны водитель не получает совершенно копейки.

P.S. Уравновесить спрос и предложение далеко не так просто, как может показаться на первый взгляд

Что я читаю (часть 1)

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

Так вот, если у кого схожие интересы, хотел бы поделиться блогом Eli Bendersky, который пишет простым языком с хорошими картинками и пояснениями. Из недавнего, что прочитал: Implementing reader-writer locks — классная статья о том, как можно под капотом реализовать R-W Mutex, в том числе в самом конце Эли приводит реализацию приближенную к тому, что находится в стандартной библиотеке Go в sync.RWMutex.

А тем, кто хочет попрактиковать свое concurrent-кунг-фу, предлагаю следующую задачку. Основными свойствами R-W Mutex’а являются: (1) отсутствие busy wait’а и (2) writer preference. Задача заключается в том, чтобы реализовать R-W Mutex с разными свойствами при помощи обычных мьютексов:
- busy wait + writer preference при помощи одного мьютекса
- no busy wait + reader preference при помощи двух мьютексов
- no busy wait + writer preference при помощи трех мьютексов

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

Про зону комфорта

«… нельзя сказать, что у него за плечами двадцать лет опыта. Его опыт — это год работы, повторенный двадцатикратно.» (Ицхак Адизес)

Просто золотые слова. Адизес очень красочно выразил мысль, которую я так долго вынашивал. Частенько вижу, как программисты входят в зону комфорта, получая зарплату $3k+. Вроде как что-то делает, вроде и пользу приносит, но развития никакого. И так он сидит годы либо на одном проекте, либо перескакивая с проекта на проект.

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

Я не знаю ни одного успешного стартапа, где фаундеры бы отсиживались в зоне комфорта.

А если вы хотите оставаться разработчиком (что тоже абсолютно нормально), то знайте, Chat GPT придет за вами, если остановитесь в развитии :)

Топ 3 ошибок в 2022

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

Мало общались с пользователями. Каждый раз, когда вы мало общаетесь с пользователями, у вас должна загораться лампочка: “что-то не то”. Если вы проходили Startup School от YC, то знаете, что первым вопросом каждую неделю у них идет: “со сколькими пользователями вы поговорили на прошлой неделе?”
Конкретно в нашем случае большая ошибка была такой: когда мы переходили с модели “мам за рулем” на микроавтобусы, мы себе сказали: да ну, чего там делать? Водитель микроавтобуса — это та же мама за рулем, только мест в машине не 4, а 14. Они будут использовать то же мобильное приложение, и все должно пойти как по-маслу. Как же мы были неправы 🤣 Начиная с того, что мамы за рулем не курят и не матерятся, заканчивая тем, что водитель, который работал на каком-то маршруте 10 лет вообще ничего не хочет менять, и на все наши приложения он плевать хотел!

Считали себя очень умными. Как сейчас помню, нас (фаундеров) преследовала идея, что мы умнее всех остальных, и если кто-то делает иначе, то это просто он не додумался, мы ведь такие гениальные! Два примера из реальной жизни:
- В модели “мам за рулем” у нас был конкурент в Штатах: Zum. Они развозили детей в школы на легковушках, микроавтобусах и шатлах. И почему-то мы считали, мол мы их сможем победить, если сконцентрируемся исключительно на легковушках. Причем активно себя в этом убеждали и пытались найти логические аргументы. В результате мы ушли от легковых авто намного позже, чем потенциально могли бы
- Когда мы начали общаться с транспортной компанией, которая до нас развозила одну из школ в Алмате, мы почему-то решили, что их опыт для нас не важен, что мы можем лучше, что сейчас мы составим супер-маршруты и т.д. В итоге облажались по полной 🙂

Очень долго разрабатывали фичи. С полной уверенностью могу сказать, что MVP практически любой продуктовой фичи можно сделать за один день. “Один день, ты с ума сошел?” При большом желании — да. Как именно уметь делать такие MVP — тема отдельного поста. Но в начале 2022 мы еще так не умели. Так вот история из реальной жизни:
В январе 2022 мы реализовали так называемый “букинг”. Не буду вдаваться в детали, но у нас ушел месяц или полтора на эту фичу. После выкатки мы поняли, что клиентам это не нравится, и спустя две недели мы ее закопали. Если бы мы умели делать быстрые MVP, то не потратили бы столько усилий

А какие у вас были самые большие ошибки в прошедшем году (не только в стартапах)?

Фейсбук закапывает Python

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

TL;DR. Python хорош для (а) прототипирования и (б) экспериментов типа ML, но очень плохо масштабируется. В стартапах использовать можно, но нужно держать руку на пульсе

Основные проблемы масштабирования:
- Ошибки. Отсутствие статической типизации влечет за собой то, что ты допускаешь ошибки, которые вылезают лишь на этапе рантайма. Чтобы их отсеивать, нужно делать особо внимательное ревью, а значит тратить больше разработческого времени. Если вы считаете, что Type Hints могут решить эту проблему, добро пожаловать в комменты к посту, рад обсудить, почему это не так
- Рефакторинг. Если вы рефакторили большой проект на питоне, то знаете о чем идет речь: всегда боишься, что что-то забыл и где-то сломается. А когда проект разрастается, рефакторинги неизбежны
- Дисциплина. В питоне можно быстро, по-хакерски, решить какие-то проблемы, сделать прототипчик или пофиксить баг. Однако, проблема в том, что это и создает нерасширяемые и нечитаемые полотна кода. Когда пишешь на питоне, ты не особо задумываешься о паттернах проектирования и архитектуре. По-началу это сильная сторона, но с увеличением проекта становится слабой
- Производительность. Питон — один из самых медленных языков программирования. Более того, в нем есть GIL, что делает все ужасным, а масштабирование засчет процессов имеет свои проблемы
- Время старта. Кажется, CLI ведь можно писать на питоне? В Фейсбуке считают, что это плохой выбор, хотя бы по тому, что время старта твоего скрипта будет 10-15 секунд, что крайне долго и раздражает разработчиков
- Интеграция с C++. Да, вы можете сделать обвязку плюсовой библиотеки, но GIL вам вставит палки в колеса

Важная оговорка: в Meta до сих пор используется Hack, который является производной PHP, который также динамически типизирован. Однако, Meta достаточно сильно прокачали этот язык и написали порядка 400,000,000 строк кода, так что соскочить с него уже не реально

Выводы, которые сделали в Meta:
- Весь старый код на питоне остается, переписывать его не будут — слишком дорого
- ML эксперименты остаются на питоне
- Instagram дальше пишется на питоне, что поделать
- Весь другой новый код должен писаться на: Hack, C++ или Rust
- Очень сильно думают о том, что поддержать Go, но пока что не приняли этого решения — поддержка нового языка программирования в IT-гиганте занимает крайне много усилий

Мои мысли по поводу стартапов:
- На размерах Фейсбука все начало “трещать по швам”, но стартапу до этого момента еще нужно дорасти, а на начальной стадии и размерах напротив важны сильные стороны питона, так что полностью исключать из рассмотрения я бы не стал
- При выборе питона стоит использовать фреймворки, которые навязывают структуру, такие как Django, иначе ваш код будет давать вам больше поводов хакать, а значит он быстрее превратится в лапшу
- Имейте опытных разработчиков, которые смогли бы поддерживать качество кода и делать все модульно. В последствии, если вы начнете упираться в проблемы выше, то всегда сможете перенести отдельные модули, без переписывания всего кода

О важности нетворкинга

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

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

Логичный вопрос: что нужно для построения нетворка? Пока что я вижу два основных фактора:
- Быть крутым специалистом — если вы так себе, к вам не потянутся
- Уметь общаться с людьми — даже если у вас появился контакт, нужно его поддержать и развить

P.S. Последнее время мало пишу, так как нетворкаюсь с партнерами в Казахстане 🙂

Совет студенту

Вчера в Назарбаев университете спросили: “что бы ты посоветовал 18-летнему себе?”

Во-первых, нужно понимать, что у каждого человека уникальные начальные условия, путь, цели и предпочтения. В 18 лет я перешел на 3-й курс Мех-Мата МГУ и поступил в ШАД, наверное, не очень репрезентативно? И тот совет, который я бы дал себе, вряд ли будет применим к вам.

Тем не менее, один глобальный совет студентам у меня все же есть: пока молодые — учитесь, не торопитесь с работой. На то есть несколько причин:
- Пока вы молоды, у вас особо нет обязанностей: вам не нужно работать, чтобы кормить семью, уделять время детям и т.д. Все это в будущем будет вас отвлекать от учебы
- Очень важно развить навык получения знаний. Если не сделаете это в молодости, то скорее всего учиться в будущем для вас будет большой тягостью. А в современно мире, особенно в IT, постоянное развитие жизненно необходимо
- Учеба — это 100% инвестиция в себя. Да, на работе вы тоже чему-то учитесь и что-то узнаете, однако, обычно это лишь на первых порах, дальше в основном вы лишь применяете полученные знания. К слову, в этом и фишка стажировок: за 3 месяца работы, ты не успеваешь выйти на плато, поэтому ими точно не пренебрегайте

Ну и напоследок, мои наиболее выдающиеся коллеги в Яндексе были реальным “задротами” 🙂

Стань экспертом

Я уж и не знаю, когда закончатся советы из разряда “очевидных”, но если люди спрашивают, то надо отвечать

Вот анонимизированный пример: “Хочу запустить аренду скейтов в Индонезии”. Один из первых вопросов, которые я задаю: “А насколько сильно ты разбираешься в рынке аренды скейтов, и насколько хорошо знаешь рынок Индонезии?”

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

Обязательно ли наращивать экспертность самостоятельно?
Нет, найдите партнера! Лично я считаю себя в первую очередь экспертом в IT, поэтому у меня всегда были ко-фаундеры с экспертностью в предметной области: в celly.ai наш СЕО, Ансар, получил PhD по медицине, понимал проблемы лабораторий и очень хорошо разбирался в их процессах. В UvU один из наших партнеров самостоятельно создал детскую развозку для своей футбольной академии.

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

Добро пожаловать в Лондон

Сегодня, в первый день в Лондоне по прилете из Казахстана, чувак на велике проезжает мимо, выхыватывает из моих рук телефон, смотрит на него и через пару метров, хвала Аллаху, скидывает на дорогу (видимо, iPhone SE — слишком дешево)

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

Что есть талант?

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

Из этого определения два вывода:
- Талант не является условием для освоения какой-то области. Просто если его нет, тебе потребуется больше времени на обучение
- Одного таланта не достаточно. Какая бы скорость развития у тебя ни была, если ты не будешь проявлять усердие и уделять время, ничего не добьешься

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

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

Как всем известно, наших братьев и сестер в Турции постигла большая беда, и наш долг — проявить человечность и помочь им

Абу Хурайра (да будет доволен им Аллах) передает, что Пророк (мир ему и благословение Аллаха) сказал: «Милостыня (садака) не уменьшает имущество, и Аллах не добавляет рабу Своему за прощение ничего, кроме величия, и того, кто принизит себя пред Аллахом, Всевышний Аллах непременно возвысит» (сахих Муслим)

Для СНГ я советую Tooba: https://m.tooba.com/b5x9
Для UK Human Appeal: https://humanappeal.org.uk/donate/projects/emergencies/turkey-emergency-fund

У стартапа должен быть большой рынок!

Если у вас есть супер-классная идея, как с помощью машинного обучения решить проблему сборки LEGO, это еще не стартап. Даже если вы придумали, как это монетизировать, и даже если вы сделали мобильное приложение, это все еще не стартап! Наличие чего-то айтишного в проекте еще автоматически не делает его стартапом

Кто-то скажет: “ну что ты пристал со своей терминологией?!” На самом деле это крайне важно. Стартапы существуют по одним правилам, а бизнесы по другим. В стартапы привлекаются венчурные инвестиции, а в бизнесы — нет. Если терминология неправильная, можно так и остаться жить в своих мечтах

Стартапы — это про кратный рост (что и привлекает венчурных инвесторов), а чтобы постоянно кратно расти, должен быть большой рынок. Помню, как в одном из акселераторов, когда трекер просматривал нашу презентацию, он сказал: “Подождите, ваш рынок меньше $1 млрд? Не, это не серьезно. Под такое инвесторов не найти”

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

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

Проблемы молодого программиста (1)

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

Основная проблема тут в медленном исполнении, а оно по моему опыту возникает из-за того, что страдает декомпозиция. Вместо того, чтобы пожать 20кг 5 раз, джун старается разом отжать 100кг и терпит неудачу. Одно из проявлений этого в том, что все пихается в один громадный PR, по нему идет 100 комментариев, внимание рассеяно, ревьюить и держать весь контекст долго и сложно, если это все же доходит до победного конца, возникает множество багов, которые потом еще нужно фиксить. В общем, мрак

Поэтому сеньорам советую делать упор на декомпозицию, а джунам, если они понимают, что увязают в болоте, не стесняться обращаться за помощью

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

Если понравилось, поделитесь мнением, было ли у вас такое, а также почитайте и старый пост про Топ 5 ошибок джунов на ревью: https://t.iss.one/cto_diary/33

🕸 Как строить нетворк (практический гайд)

Поделюсь историей, как я познакомился со своим кофаундером и CEO в UvU — Мадияром Толеугали:
- [~2014] Когда я читал quran-online.ru и подмечал опечатки и ошибки — никогда не ленился их репортить. Через какое-то время со мной на связь вышел Роман Ахмадуллин, руководитель проекта, и лично поблагодарил, мы перекинулись парой слов и на этом разошлись
- [~2015] Через какое-то время Роман запартнерился с Наилем и они совместно стали делать проект quranacademy.org
- [~2016] У Наиля возникает идея, что исправление чтения Корана нужно автоматизировать. На тот момент я работаю в Яндексе в команде по распознаванию речи. Нас сводит Роман, мы налаживаем контакт и я начинаю помогать Академии Корана
- [~2017] Наиль знакомит меня со своими друзьями из Дагестана, которые занимаются систематизацией благотворительности, говоря, “что вот какой крутой специалист у меня есть” (нормально задачу исправления ошибок мы не решили, но это уже другая история). Среди друзей Наиля был некий Назым, которого я слегка запомнил, но не более того
- [январь 2019] Мне пишет Назым, говорит, что есть такое приложение Tooba, и некий Рамазан Меджидов хочет со мной поговорить. Я даю свой контакт, Рамазан говорит, что “нужно встретиться”. На вопрос, где именно, он отвечает — в Турции (тогда я уже работаю в Фейсбуке в Лондоне). Почему-то нужен именно я. Подозрительно — ну да ладно, раз Назым знает, наверное, все ок. В Турции мы встречаемся, Рамазан мне очень красочно презентует проект Tooba, я рассказываю о своем опыте и том, чем могу помочь, Рамазан впечатлен. После недолгих раздумий я присоединяюсь к проекту на волонтерских основах
- [2020] Я начинаю активно помогать проекту Tooba. В какой-то момент хочу привлечь новых волонтеров и рассказываю о проекте во всех красках в коммьюнити ODS (Open Data Science). Получаю хорошие отклики и лиды, но самое главное, этот пост видит Мадияр Толеугали, у которого была идея создать такое же приложение в Казахстане. Он решает не делать двойной работы, а объединить силы. Через какое-то время мы с Мадияром понимаем, что у нас есть достаточно сильные расхождения в видении и стратегии развития Tooba, после чего мы покидаем проект, но до сих пор поддерживаем дружественные отношения с Рамазаном и его командой

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

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

🔥 GitHub Copilot 🔥

В отличие от ChatGPT вокруг Copilot не было такого ажиотажа, однако после пары часов работы с ним я считаю, что Copilot’ом должен пользоваться каждый программист, за исключением учебных целей. Думаю, в UvU мы будем оплачивать Copilot нашим разработчиком, потому что это просто 💣

А теперь несколько примеров, как Copilot сэкономил мне время:
- Я захотел написать простенькую функцию, как получить определенный url из объекта. Наизусть все конструкции я не помню, поэтому сначала пошел в StackOverflow и быстренько загуглил, как это делается. Когда я начал писать название функции, Copilot моментально подсказал мне правильную реализацию, которую я увидел на StackOverflow
- Для создания объектов в тестах мы используем Factory объекты. Обычно, чтобы написать Factory, я смотрю на саму модель и понимаю, что разумно можно сделать фейковым. К моему удивлению, Copilot сгенерировал мне очень качественную Factory, которую я чуть-чуть подправил и дело было сделано
- Мне нужно было зарефакторить два очень похожих куска кода. В первом Copilot предложил разумный код, но я его чуть-чуть поправил. К моему великому удивлению, при рефакторинге второго куска Copilot уже не ошибся и правильно выучил мой стиль написания кода
- К сожалению, IDE для Python не всегда умеют грамотно подсказывать, что именно и откуда импортировать. Иногда ты забываешь точное имя класса и т.п. Copilot отлично справляется с задачей и оптимизирует время в таких мелочах
- Написание тестов по обычаю у меня начинается с того, что я ищу похожие тесты, копирую и модифицирую под мой кейс. Как вы уже догадались, Copilot достаточно умный, чтобы оптимизировать и этот процесс и сильно ускорить написание тестов

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

P.S. Видение крупных трендов в AI и разработке, а также мои мысли вокруг них я опишу в отдельном посте

LeetCode Roulette with Copilot

Поигрался еще немного с GitHub Copilot'ом и порешал произвольные задачки на литкоде. Резюме мыслей:
- Пока что Copilot не панацея, все равно нужно знать, что именно и как именно он пишет
- Если ты умеешь декомпозировать задачу на более мелкие, то Copilot очень сильно ускоряет написание мелких задач
- В production коде очень много мелкой рутины, поэтому продуктивность сильно повышается

https://youtu.be/qTLFTFg8jgw
Как обычно, с меня видео, с вас лайки, если стоит продолжать такое делать :)

Вышла запись подкаста Real Qadam с моим участием: https://youtu.be/_T6y-TnSfEY

Хочется похвалить ребят за очень продуманные вопросы и интересные обсуждения, поддержите их лайками. Если есть какие-то замечания ко мне, пишите тут в комментах, рад любой конструктивной критике :)

Мысли вслух (1)

Недавно посмотрел Минаева про монголо-татрское иго. Честно сказать, ничто так не обнадеживает, как изучение истории

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

Смотрю я на разрозненные мусульманские страны и в целом MENA регион, и с одной стороны даже грустно становится, а с другой понимаешь, что пока что не все так плохо, и до 240 лет еще не дошли, а значит все у нас еще впереди, ин шаа Аллах