Поделюсь первым опытом работы в англоязычной команде из Европы. Три месяца - полет нормальный. Что подметил:

- Темп, в целом, более размеренный. Меньше встреч, меньше звонков. Если кто-то кого-то блокирует - это часто ок. Можно и подождать). Самому страшно это произносить, но work & life balance к тебе приходит сам, даже если ты его не искал. Приходится тратить оставшуюся энергию на свои проекты: блоги, подкасты, flutter и т.п)

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

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

- По технической части, наверно, не показатель, так как компания и продукты специфичные. В целом, все прагматично: github, облака, REST API и т.п.

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

#blog

🎬 Начинаем выкладывать записи подкаста

Первый сезон тестовый. Осваиваем азы видео-продакшна и привыкаем говорить на камеру. Пока немного подтупливаем)

Пишите фидбек, интересно ваше мнение. Лайк / шэр / подписка на ютубе - в обязательном порядке)

https://www.youtube.com/watch?v=bDdB10EAOPI&ab_channel=BroScience

#podcast #bro_science #youtube

Когда стартап только разогнался и кончились деньги

🎬 Время офигительных историй

Вышел второй выпуск подкаста. Обсуждаем нелегкую долю CTO в IT-компаниях)

https://www.youtube.com/watch?v=88oz7fk7T2s&t=16s&ab_channel=BroScience

#podcast #bro_science #youtube

🎬 Новый выпуск подкаста

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

#podcast #bro_science #youtube

https://www.youtube.com/watch?v=kVD2nn85uCw&ab_channel=BroScience

Продуктовая разработка vs проектная разработка

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

Я больше 10 лет проработал в продуктовых компаниях, и параллельно успел поработать над десятками проектов в качестве фрилансера/консультанта. Главное отличие в том, что из проектов я не получил никакой экспертизы об их предметной области. Не узнал специфику ниши, потребности аудитории, юнит-экономику или какие еще есть решения на рынке. Все, что там надо делать - писать код. E-commerce маркетплейсы, вилы на Кипре, бинарные опционы, строительство домов из SIP-панелей, инфо-бизнес, покупка долей в покерных турнирах - я ничего не знаю про эти бизнесы, несмотря на то, что делал проекты для них.

С другой стороны, благодаря продуктовому опыту, я кое-что знаю про видео-стриминг, big data, vip-беттинг и теперь начинаю активно погружаться в мир online-платежей. Для меня намного интересней разобраться в новой нише, чем написать еще пару тысяч строк кода. Получить новую техническую экспертизу (не меняя кардинально стек) с каждым годом все сложнее, зато продуктовую экспертизу можно развивать бесконечно. Чем шире кругозор - тем больше будет идей для создания своего собственного продукта.

#development #career

🎬 Вышла крутая документалка про TypeScript

Интересно показали как Miscosoft впервые начал делать опенсорс. В частности, как было сложно продать эту идею внутри консерватиной на тот момент IT-компании, которая привыкла продавать лицензии на свой софт.

Прикольно, что они сотрудничали с командами IT-гигантов-конкурентов Microsoft: Google, Facebook и т.д. Команда Angular (Google) поддержала TypeScript на старте и, по сути, убила будущее своего же языка Dart в вебе.

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

#typescript #frontend #development

Вернулся в Дубай пару недель назад. Если кто тут или будет проездом - пишите)

Adobe захватывает рынок AI-инструментов

Adobe на своей конференции анонсировали огромную пачку обновлений и новых AI-инстументов. Это просто бомба 🔥

Я последнее время активно изучаю рынок AI-тулов для копирайтинга и креатива. Сейчас уже очень много крутых решений, но чтобы создать какой-то процесс производства контента нужно скрещивать по 5-10 разных сервисов с большим объемом ручных телодвижений. Adobe решила закрыть все основные кейсы профессиональных контент-мейкеров и креативщиков внутри своей экосистемы с интеграцией AI во все инструменты и экспортом/импортом ресурсов между ними.

Впечатляет не только набор фичей, но и качество нейронок. Кажется, что Midjourney, Runaway, Canva, Invideo и другие скоро будут повержены все разом. Как, например, вам генерация векторных картинок? Дизайнеры точно оценят)

Перечислять все новые AI-фичи будет слишком долго, очень их много. Просто посмотрите видео:

- Краткий обзор на русском (18 мин) - https://www.youtube.com/watch?v=Hj7tntKTWxA&t=925s&ab_channel=Web3nity

- Полная версия конференции на английском (2 часа) - https://www.youtube.com/watch?v=1tbrJNP5Cjk&t=1689s&ab_channel=AdobeCreativeCloud

#ai #creative #content

Качество IT-вакансий

Продолжаю наблюдать за глобальным рынком разработки. Есть много общего с тем, что мы привыкли видеть в российском сегменте, но кое-что отличается довольно сильно. Например, это оформление вакансий и процесс создания первоначальной воронки кандидатов.

Как у нас:
- Короткое описание вакансии на один экран текста
- Стек/базворды/требуемый опыт
- Вилка зп через раз
- Чтобы зааплаиться - отправьте CV и контакты. Часто даже без поля для сопроводительного письма. Дальше HR и команда разработки будет просеивать весь этот безликий поток на интервью
- Тестовые задания - табу. Разработчики в агрессивной манере убедили всех в том, что делать тестовые задания - себя не уважать. Только компании с мощным брендом себе могут это позволить. К остальным никто не будет аплаиться

Как в мире:
- Никого не пугает написать длинный текст вакансии и подробно описать: Кто мы? Почему мы нанимаем на эту позицию? За что вы будете отвечать? Какой опыт и навыки необходимы для этой роли? Подробное описание всех этапов процесса найма от отклика, до финального интервью с CEO
- У компании часто есть блог, сайт или notion, где описано все, что надо знать сотрудникам и кандидатам про компанию, ее структуру, внутренние процессы, систему мотивации и т.д. Ссылки прикладываются в вакансии. Иногда под вакансию hiring manager (например тимлид) записывает короткое видео, где рассказывает о команде, вакансии и проекте
- ЗП вилка почти всегда указана
- Обычно при отклике нужно написать какой-то сопроводительный текст в определенном формате. Про свой опыт и лучшие проекты, почему вы и данная компания perfect match и т.д
- Активно просят ссылки на готовые проекты, приложения, демки, гитхаб. Иногда даже в обязательном порядке просят прислать короткое видео с обзором и пояснениями какого-то технического решения, которым вы гордитесь
- Тестовое задания в порядке вещей. Обычно оно качественно подготовлено, с описанием, заготовленным API, креденшлами или даже с видео-инструкцией

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

#development #hiring

Загадка

Почему я всегда использую разные блины по краям (10кг с одной стороны, 2 по 5кг с другой)?

Минимальные вводные: рабочий вес, третий подход, вес с обеих сторон равный, радиус всех блинов одинаковый

Если сходу не догадаетесь - дам подсказку

#quiz

База

#development #system_design #basics

Никогда не говорите Senior'у КАК решать задачу

Распространенная проблема, когда продакты, фаундеры или CTO ставят Senior+ ребятам задачи в стиле "нужно добавить поле ввода и кнопку для поиска над списком вот тут справа в углу" или "нужно запилить две новые ручки в API". С виду может показаться, что такая формулировка четко отвечает на вопрос "ЧТО" сделать. На самом деле она отвечает на вопрос "КАК", и за этим кроется ряд проблем: 

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

2) Мы не можем провалидировать корректность бизнес-требований задачи, их целостность и непротиворечивость. Может у нас уже есть альтернативный способ найти информацию из данного списка в другом разделе приложения? Но, так как мы не понимаем реальный use-case задачи, найти эти пересечения мы не сможем.

3) Формируется неверный definition of done. При приемке задачи мы проверим, что поле и кнопка поиска есть и как-то работают. Мы не проверяем решилась ли хоть одна настоящая проблема пользователя и насколько качественно.

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

В долгосрочной перспективе проблема еще глобальней. Говоря "КАК" сделать, вы не используете в полной мере экспертизу сотрудников и сужаете их ответственность до технической реализации. Нет смысла нанимать UX-дизайнера и просить нарисовать кнопку с всплывающим попапом, не объясняя суть проблемы и какой use-case хотим покрыть. Нет смысла нанимать бэкенд-архитектора и просить запилить ручку в определенном формате. Нет смысла нанимать фронтенд-лида и говорить ему, что нам обязательно нужны микрофронтенды или module federation.

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

⚡ Senior'ы, когда в следующий раз вам придет задача, в которой кто-то за вас принял решение, касающееся напрямую вашей экспертизы - вспомните этот пост. Переведите требования с языка "КАК" на язык "ЧТО" и подумайте над проблемой хотя бы пару минут перед тем как брать и делать. ⚡⚡⚡

#management #development

База по Latency

🔹Кэш L1 и L2: 1 ns, 10 ns
Например: Обычно они встроены в микропроцессорный чип. Если вы не работаете напрямую с аппаратным обеспечением, вам, вероятно, не о чем беспокоиться.

🔹Доступ к RAM (ОЗУ): 100 ns
Например: На чтение данных из памяти уходит около 100 ns. Redis — это хранилище данных в оперативной памяти, поэтому чтение данных из Redis занимает около 100 ns.

🔹Отправка 1К байт по сети 1 Гбит/с: 10 μs
Например: На отправку 1КБ данных из Memcached через сеть уходит около 10 μs.

🔹Чтение с SSD: 100 μs
Например: RocksDB — это дисковое хранилище ключ/значение, так что задержка чтения составляет около 100 μs на SSD.

🔹Операция вставки в базу данных: 1 ms.
Например: Коммит в Postgresql может занять 1 ms. Базе данных необходимо сохранить данные, создать индекс и сбросить журналы. Все эти действия занимают время.

🔹Отправка пакета Калифорния->Нидерланды->Калифорния: 100 ms
Например: Если у нас долгий Zoom-звонок на большое расстояние, задержка может составлять около 100 ms.

🔹Повторное обновление/обновление интервала: 1-10 s
Например: В системе мониторинга интервал обновления обычно устанавливается от 5 до 10 секунд (значение по умолчанию в Grafana).

Примечания
1 ns = 10^-9 секунд
1 μs = 10^-6 секунд = 1,000 ns
1 ms = 10^-3 секунд = 1,000 μs = 1,000,000 ns

#development #system_design #basics

Мало встреч в agile-команде - хорошо?

Предлагаю всем в голове ответить на этот вопрос перед тем как читать пост. Мой ответ - НЕТ.

На своем опыте я видел разные процессы в командах. От 1 встречи в неделю, до 3-4 встреч в день. Видел даже команды, в которых вообще нет регулярных встреч, а только по необходимости. Кто-то даже этим гордится в стиле - "Нормальной команде встречи не нужны. Мы работу работаем, а не бюрократию разводим. У нас все в Джире, Слаке, Вики и т.д. Мы нанимаем профессионалов, которых не надо контролировать!"

На мой взгляд, обычно главная причина малого количества регулярных встреч в команде совсем не такая благородная, а попросту - всем в команде наплевать. Поезд куда-то идет, мы подкладываем дров в печь. Если пути внезапно заканчиваются - проложим еще рельс и поедем дальше. Кочегары и проводники при деле, машинистам маршрут понятен - всегда вперед. Пассажирам давно разъяснили, чтобы не задавали лишних вопросов про время прибытия и конечную остановку. У нас такой спец-рейс ☝️ Если нужна промежуточная остановка - передадим записку машинисту с другого конца поезда. Если не успеете до 16:45, то он ее прочитает уже завтра.

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

Так сколько нужно обязательных встреч, и что если уже пробовали Scrum, но результат был не лучше? Об этом в следующих постах...

#development #agile #management #team #processes

Chat GPT не виноват, что вы потеряете работу

Очень много специалистов из IT, digital и дизайна все еще находятся в стадии отрицания революции генеративного AI. Другой лагерь наоборот паникует, что все пропало и все останутся без работы в течение 5 лет. Обе позиции, на мой взгляд, проигрышные.

Для отрицальщиков у меня плохие новости:

- Джин уже вылетел из бутылки и обратно его не загнать. В 2023 году произошел квантовый скачок в технологии Generative AI, благодаря Open AI, Midjourney и другим менее известным компаниям. Новые модели знают и умеют практически все. Главное правильно сформулировать запрос

- В прикладных задачах: программирование, копирайтинг, перевод, рисование/обработка картинок - AI не просто догнал, а превзошел 99% людей

- Как бы мы себя не убеждали в своей исключительной уникальности и бесценности своего опыта - это самообман. Даже если AI научится выполнять вашу работу на 70% - этого будет достаточно. В довесок к вашим 100% идет административная и менеджерская нагрузка. Вас надо нанимать, координировать, напоминать про сроки, платить высокую з/п, даже если в данный момент задач для вас нет. В вашей компании позицию, скорее всего не сократят, но в новой компании этой позиции уже просто не будет изначально

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

Для всепропальщиков новости скорей хорошие:

- Не держитесь за свои хард-скилы. Верстать, кодить, рисовать, писать посты - это далеко не все, что вы знаете. Особенно если вы Middle/Senior+. Внедряйте AI первыми в свой рабочий процесс и посмотрите какую новую зону ответственности вы можете закрыть как специалист, имея такой мощный инструмент на руках

- Умение задавать сложные вопросы в Chat GPT все еще требует знание вашей предметной области. Это такой же хард-скил и он будет востребован. Автоматизация и интеграция разных AI инструментов в цепочку под конкретные бизнес-задачи - еще более перспективное направление

- Инерция в любой сфере присутствует. В ближайшие несколько лет будет окно, когда вы как фрилансер/аутсорсер/мини-студия сможете все еще работать на рынке, где большинство конкурентов решают задачи руками и получать огромное преимущество от использования AI инструментов. Заказчики не будут видеть разницы

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

#ai #gpt #career

Новости про банки в ОАЭ

У меня есть статья-гайд про релокацию в Дубай, где я рассказывал, что единственная боль во всем процессе это банки и непрозрачная система compliance для обладателей красного паспорта. Похоже, сейчас эта проблема решена с появлением необанка здорового человека, который быстро открывает карты и счета по Emirates ID из приложения.

Гайд обновил. Кому релевантно - пользуйтесь.

Из интересного, wio предлагает interest rate на депозиты - 6% в AED. Что равносильно 6% в USD. Выглядит неплохо, учитывая, что средний ROI в недвижимости по Дубаю около 5-7%.

#uae #dubai #blog