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

Ранее в постах раскрывал тему важности нетворкинга [1, 2], но многие хоть и понимают важность, все равно очень плохо это делают. Так получилось, что хотя я и интроверт, по образованию теоретический математик, а по специальности программист (короче, втройне интроверт), со временем на собственном опыте все же освоил этот навык, и вот вам мой гайд:

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

2. Научитесь первым заводить беседу. Да, всегда можно ждать с моря погоду, но для того, чтобы целенаправленно нетворкаться, это умение необходимо. С теми же самыми ребятами из Вкусвилла я первым завел разговор на BJJ

3. Говорите о том, что интересно собеседнику, а не вам. Был один парниша, который очень увлеченно рассказывал о себе, своей семье и т.п. Это было интересно послушать минуту-две, а дальше мне уже хотелось сбежать. Чтобы у вас завязались хорошие отношения, поймите, что именно человеку интересно, и именно об этом с ним и поговорите

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

Успехов в нетворкинге!

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

Почему думаете Каспи не делают такси? Боятся Яндекса? Ан-нет, просто это сейчас у них не в приоритете. А стратегия там такая: когда они берутся за новый продукт, то фокусируют все силы на нем, пока не станут там номером 1

За последний год мы много когда брали 4 большие стрима работы (не 4 гипотезы внутри одного стрима) на четырех фаундеров. В итоге каждый стрим получался ущербненьким

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

Полторы недели назад случайно пересеклись с одним фаундером вживую. Он мне говорит: "Слушай, а заходи на чай, у нас есть инфраструктурные вопросы, которые мне хотелось бы обсудить"

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

А пишу я это к тому, что если у вас есть возможность посоветоваться с более знающим (мной или кем-то другим, без разницы) — сделайте это! Не надо (1) ждать случая или же (2) советоваться пост-фактум (но это лучше, чем вообще не советоваться)

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

P.S. Хотите посоветоваться по архитектуре вашего стартапа — welcome

Database Design Series. Introduction

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

• Бывает так, что можно принять неправильное решение, которое потом будет тебя тормозить, и еще 2 недели потребуется это рефакторить
• Бывает так, что определенный дизайн сильно усложняет последующую аналитику
• Бывает так, что вы уже приняли неправильное решение: как лучше всего устранить последствия?

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

Если вас заинтересовало — поддержите лайками и репостами

Database Design Series. О чем нужно думать

Когда дизайнишь БД, в голове нужно держать следующее:
• Решение задачи бизнеса — ваш дизайн должен правильно моделировать бизнес-процесс и помогать решать поставленную проблему
• Аналитика — в последующем вы должны мочь численно замерить и проанализировать результаты
• Корректность — важно работать с БД так, чтобы данные всегда были консистентными и корректными
• Дебаггинг — нужно сохранять дополнительные метаданные, чтобы потом можно было легко задебажить какие-то проблемные вопросы
• Расширяемость — важно думать слегка наперед, чтобы все не приходилось переделывать на следующей итерации

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

Делюсь промахами, которые совершил в 2024. Сегодня поговорим про онбординг разработчиков

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

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

Вспоминая свой опыт, самый топовый онбординг был в Фейсбуке! Целых 6 недель буткампа Фейсбук вливал своих сотрудников в работу!

Так что так: как разработчика заонбордишь, так он и полетит ;)

P.S. Database Design Series продолжим попозже, очень много работы, не успеваю толком писать :(

Превосходство опыта над теорией

В Твиттере я работал в Graph Storage команде — мы развивали графовую базу данных, где хранились все связи: кто кого лайкнул, репостнул, замьютил и т.п. Так вот когда я пришел, мы были в середине миграции всей системы на новую архитектуру. Ни за что не угадаете, сколько эта миграция уже длилась: 5 лет! Только вдумайтесь в это время, пять лет! Я всегда говорю, что за это время в Фейсбуке бы уже уволили 5 команд, которые работали над этим проектом 🙂

Мне стало интересно, а что же пошло не так? И вот к чему я пришел в результате расследования. В Твиттере во главу такой сложной миграции поставили теоретика. Человек был PhD в компьютерных науках и всю карьеру работал в Твиттере, но никогда подобные миграции не делал. В итоге, вместо того, чтобы делать ее постепенно: 0 → 0.1 → 0.2 → ..., он решил все переписать с нуля и сделать миграцию 0 → 1. А в реальной жизни оно так не работает 🙂

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

Делайте выводы, дорогие подписчики

Общался вчера с новоиспеченным стартапером, а по совместительству и моим подписчиком! Своим опытом я делюсь уже почти 3 года. Не стесняйтесь листать вверх и читать старые посты! Там много всего полезного: учитесь на чужих ошибках

3 основных урока, которые мы поняли, делая стартап в 2024 году:

1. Фокус. В предпринимательстве возникает много возможностей. Хороший предприниматель — это тот, который умеет фокусироваться и экзекьютить. Лучше сделать одну вещь хорошо, чем 4 плохо
2. Кто такой фаундер. Главная метрика основателя — сделать стартап успешным. И если это означает смену роли, то значит так тому и быть. Допустим, наш CPO крайне успешно перепрофилировался в CFO, потому что стартап этого требовал. И мы ни капельки не пожалели
3. Со стороны все кажется шоколадным. Мы пережили много трудностей в 2024, однако со стороны все видят лишь успешный успех. Если у вас в стартапе какие-то проблемы, то знайте, это норма, а не исключение!

Заходя в 2025 год, прошу Аллаха, чтобы Он благословил наш стартап и помог нам сделать юникорн из Казахстана 🚀

Как решать разногласия между кофаундерами?

Последнее время несколько человек спрашивали: «а что если мы с кофаундером не можем прийти к согласию, как поступать в этом случае?»

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

1. Стратегические, т.е. долгосрочные (1+ лет). Для принятия подобных решений требуется консенсус, т.е. мы их не принимаем, пока все (4 кофаундера) не согласятся. Обычно, в стратегических решениях не требуется спешка, поэтому их можно обсуждать неделями

2. Тактические. Принятие краткосрочных решений мы делаем на основе оунершипа (ответственности). За какую-то область, например, мы ставим фаундера А ответственным, т.е. он отвечает за ее успех. Он со всеми советуется, но в конечном счете единолично принимает решение. Даже если остальные фаундеры не согласны, мы доверяем его решению. Обычно в тактических вопросах нужно уметь принимать быстрые решения, поэтому ждать консенсуса может быть непозволительно долго

Вчера 4 часа дебажил один крайне подозрительный эксепшен. Долго все копал и читал код вдоль и поперек. Как итог — нашел баг в гугловой библиотеке

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

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

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

Если кто едет сегодня на Digital Almaty, то там будут курсировать наши бесплатные шаттлы 🚀
За подробной информацией переходите по ссылке

Чем в 2025 заняться студентам?

Мое мнение, вместе с LLM открылся достаточно широкий рынок пользовательских AI ассистентов. Генерируйте идеи с ChatGPT (или DeepSeek), выбирайте что вам нравится и делайте! Для маркетинга и продаж используйте те же советы от ChatGPT

Дальше у вас может быть три исхода:
1. Продукт супер-востребован и летит. В этом случае добираете команду и летите покорять вершины
2. Вы дойдете до $2-3k MRR (дотеры, не путайте с MMR). Это очень неплохой пассивный заработок
3. Продукт совсем не полетел. Значит это строчка опыта в пет-проектах

Что реально поменялось по сравнению с предыдущими годами? Вероятность исхода номер 2 очень сильно возросла. Почему? Потому что с помощью мощного AI легко создать ценность и продать 100 людям по всему миру по 20 баксов в месяц подписку. Вот и ваш $2k MRR

Понравилось? Скинь своим друзьям студентам, которые до сих пор плюют в потолок

P.S. Сейчас тонна работы, поэтому думаю переформатироваться в более короткий и простой формат, но продолжить писать

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

100 раз повторял этот совет, но повторю и 101-й. Если делаете стартап, то:
1. Посмотрите уроки YCombinator Startup School
2. Начните общаться с другими фаундерами и черпать от них информацию
3. Пройдите акселератор (особенно, если first time founder)

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

Вчера провел некоторое время с Мурадом ЛяРиба, крайне успешным мусульманским предпринимателем из Дагестана. Он всегда был для меня примером для вдохновения: очень много всего успел к своим 38 годам

Два новых инсайта, которые я получил:
• Мурад — машина. Ему предложили: «давай поедем в горы, посмотрим виды», он ответил: не хочу, лучше проведем время во встречах и с пользой
• Мурад дал очень интересное определение зоны комфорта (он называет его «состоянием смузи»). Состояние смузи — это когда Аллах дал человеку возможности и талант на большее (сделать больше пользы, построить более крупный бизнес, стать более востребованным специалистом), однако он довольствуется меньшим

Пусть Аллах его сохранит и приумножит пользу, исходящую от него 🤲