Технический директор (aka CTO) — это, по сути, психиатр с инженерными навыками.Разбираемся с тем, как рулить мозгами и технологиями, так, чтобы не получилась дурка.

Сюда пишет Андрей К(https://www.linkedin.com/in/a-korchak/), действующий CTO @ Monite (финтех, но не крипта!).
Посты появляются 1-2 раза в неделю.

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

Вопросы по систем дизайну могут быть весьма и весьма хитрыми, даже опытные инженеры сходу решат не каждый кейс. Взять хотя бы архитектуру сервиса типа Google Maps и реализации функции “найти в моей округе бар” с помощью СУБД. Казалось бы, все просто и есть geospatial index и все на этом заканчивается, но на больших объемах данных и при наличии шардов решать такое уже больно.

Разбор кейсов с разных систем дизайн интервью — полезное чтение. Не только для тех, кто ищет работу, но и чисто в образовательных целях (оказывается, есть технология представления координат в двумерном пространстве с помощью лишь одного числового значения, ага!).

ByteByteGo — очень крутая библиотека кейсов (в виде книги и сайта). Детальный разбор построения видеохостингов, бирж, платежных систем, карт и мессенджеров. Начинается все с тривиальных примеров (как воткнуть кэширование и скейлить СУБД) и заканчивается весьма хитрыми приемами построения архитектуры.

https://bytebytego.com/

Найм — главный вопрос в интервью

Есть кучи гайдлайнов по тому, как нанимать инженеров и что нужно спрашивать на собеседованиях. Наборы вопросов и шагов интервью на любой случай жизни — от найма в 8 технических + 2 поведенческих интервью до найма за два коротких собеседования по 30 минут.

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

Очевидно, что все кандидаты проходят через техническое интервью, на котором наша техническая команда устанавливает владение инженерными навыками и способности решать архитектурные задачи. После успешного прохождения этого этапа нужно принять решение о найме — и это самое время задать поведенческие вопросы. И внутри этого поведенческом модуля я ищу ответ на вопрос, который на 90% определяет решение о найме: “Насколько человек любит программировать?”.

Конечно, не стоит верить ответу на прямой вопрос, заданный в лоб.

— Да, очень люблю! — скажет кандидат.

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

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

Я задаю вопросы о любимых программистских книгах, рассказываю о своих, делаю несколько холиварных комментов — и наблюдаю за тем, как разворачивается дискуссия (или не разворачивается вообще). Если человек получает удовольствие от дискуссии, активно высказывается, ссылается на статьи и книги — то мы сработаемся.

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

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

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

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

Всегда узнавайте, любит ли человек свое дело — и зовите в команде тех, кому в кайф строить технологии.

Successful Negotiation: Essential Strategies and Skills — это один из самых полезных курсов на Coursera, который должен пройти любой управленец (в том числе и техдир). Успешное и аккуратное ведение переговоров — навык, которому мало кто специально учится. Обычно люди полагаются на свою интуицию, логику и вежливость.

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

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

Для успешного понимания переговорного процесса вам понадобится две самых важных концепции.

🤝 BATNA — best alternative to a negotiated agreement — ваш лучший альтернативный вариант, который вы получите, если переговоры не получатся. Допустим, вы подбираете себе новое жилье в аренду и рынок сейчас на вашей стороне — квартир много, а желающих снять — мало. Вы вступаете в переговоры с продавцом и он отказывается дать вам хорошую цену. Ваша альтернатива переговорам — развернуться и пойти снять другое жилье. Продавец в этом случае останется без денег. Если же спрос на рынке большой и скидку вам не делают, то альтернатива у вас плохая — останетесь без жилья (или получите еще более дорогой и паршивый вариант). Четкое понимание BATNA в переговорах точно скажет вам, как, когда и насколько агрессивно вы можете торговаться.

🇮🇱🇪🇬 Вторая концепция — декларируемая и реальная позиции. Поясним это на классическом примере. В ходе Шестидневной войны Израиль оккупировал территорию Египта — Синайский полуостров. После конфликта стороны сели за стол переговоров и быстро зашли в тупик. Позиция Египта — требование полностью вернуть Синайский полуостров (иначе быть не может — на носу выборы, и власть, потерявшая часть территорий, 100% проиграет выборы). Позиция Израиля – Египет должен отступить и оставить Синай Израилю (иначе и быть не может — власти только что провели опасную наступательную операцию, пожертвовали жизнями солдат и техникой — и просто так оставить Синай они могут). Декларируемые позиции полностью противоречат друг-другу.

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

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

https://www.coursera.org/learn/negotiation-skills

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

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

Хороший же ответ на вопрос о любимом стиле управления — “любимого стиля нет, а всего стилей управления примерно 6 и каждый стиль требует аккуратного применения в подходящей для него ситуации”.

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

Раскрытие талантов друг-друга — это классно, но при рухнувшем проде можно и нужно стукнуть кулаком по столу и единолично активировать все доступные ресурсы команды.

За дальнейшей инфой я отравляю вас в журнал Harward Business Review за аж 2000 год, где каждый стиль подробно разобран и проанализирован (https://hbr.org/2000/03/leadership-that-gets-results) (копия статьи в PDF во вложении этого поста)

Заметок не было довольно долго — у нас с женой родился ребенок и у меня случилось увлекательное погружение в мир грязных ползунков и детского кала 😀 💩 Теперь же процессы управления моей жизнью как-то нормализовались и появилось время что-то написать.

Обсудим сегодня важный вопрос — выбор структуры команды тестирования (они же QA инженеры).

Есть три способа расположить QA внутри вашей компании:

1️⃣ Вариант 1. Отдельные команды разработки и отдельная от них команда тестирования. Разработчики закончили работу над своим кодом, отдали фичу на проверку в другую команду. и пусть QA уже там с ней возятся. В этом случае, как правило, QA отбирает в релизы фичи, прошедшие тесты и формирует релиз-план новой версии программы.
2️⃣ Вариант 2. Специалисты тестирования являются частью продуктовой команды. Инженеры закончили разработку, передали фичи в тестирования специалистам QA внутри своей команды. После тестирования сама команда принимает решение о релизе и выпускает свой код в продакшн.
3️⃣ Вариант 3. QA нет, фичи тестируют сами же разработчики внутри команды. При описании этого способа часто звучат слова “quality assurance vs quality assistance” — вертикальные команды и сами инженеры несут непосредственную и полную ответственность за то, что они сделали.

Мое оценочное суждение — “Вариант 3” это неэффективная и опасная методология, которая приобрела популярность у некоторых менеджеров только из-за своей типа поэтичности (”мы несем ответственность за то, что делаем, у вас должен был ОВНЕРШИП 🙀”). Причин этой опасности и неэффективности две.

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

Причина вторая — финансы 💸 Разработчики и QA специалисты обладают разными квалификациями. Хорошие разработчики организуют паттерны, базы данных, шины и файловые хранилища. Хорошие QA делают фаззинг, манки тестинг, нагрузочное тестирование, автоматические и ручные проверки. Просить людей из первой группы хорошо делать работу людей второй группы — экономически бессмысленно.

Вариант 3️⃣ — дорогой, полный когнитивных искажений и эмоциональных проблем способ выпускать софт, которые потенциально содержит баги.

Поэтому при организации структуры QA отдела мы всегда выбираем между “отдельная команда” и “интегрированные QA специалисты внутри других команд” (кстати, можно выбрать сразу два варианта, когда часть тестов делается внутри продуктовой команды и часть — снаружи).

Чтобы выбрать структуру оптимально, нужно ответить на один вопрос: “Должна ли наша компания релизить фичи централизованно и одномоментно? Или можно выпускать их каждый день порциями по чуть-чуть?”. Если должна — то нужно построить отдельную QA команду, если нет — то оптимальным решением будет внедрять QA в продуктовые команды.

На сегодня все, обнял-приподнял, всех с наступающими праздниками 🎉

Твитотред — сравнение алгоритма работы Apple Pay и Google Pay. Если кратко — GPay устроен неэффективно и коряво https://mobile.twitter.com/alexxubyte/status/1572614943811440642

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

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

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

Релизиться независимо удобно, когда ваши сервисы слабо связаны между собой и выкатка новой версии не уронит зависимые сервисы. Продуктовые команды могут спокойно выкатывать свой код по своим индивидуальным графикам, используя свои привычные CI/CD и инструменты. Обычно такой стратегии придерживаются сервисы типа Netflix или Linkedin.

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

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

Оба подхода имеют плюсы и минусы, на Medium есть два эпичных срача с аргументами сторон — Monorepos please do (https://medium.com/@adamhjk/monorepo-please-do-3657e08a4b70) и Monorepos please don’t (https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b)

Наша компания Monite делает финансовые системы, поэтому нам ближе подход монорепо. Но, покрутив его в голове между собой, мы поняли, что нам этот подход нужно докрутить. Причин доработать монорепо у нас три:

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

Все это мы решили специальным репозиторием, в котором в YAML описываются сервисы, версии и датацентры.

eu:
 production:
  payments: 0.1.1
  documents: 0.2.5
 sandbox:
  payments: 0.1.2
  documents: 0.2.5
us:
 production:
  payments: 0.1.1
  documents: 0.2.5
 sandbox:
  payments: 0.2.2
  documents: 0.2.2

На верхнем уровне — название датацентра, дальше идет название окружения и на самом нижнем уровне — сервисы и версии.

Из всей истории вывода два

1️⃣ Надо привыкать к тому, что бизнес всегда неразрывно связан с IT, решения многих задач становятся очевидными, если понимать, из каких бизнес ограничений они следуют. Релизные политики и методологии можно обсуждать бесконечно, но правильный ответ на этот вопрос находится сразу же, как только мы осознаем, что именно и как надо релизить.
2️⃣ Нормально оценить все, что есть сейчас на рынке и … не взять из этого ничего, а придумать свой гибрид. Если кто-то кричит “вот, большие компании все так делают” — это не значит, что их способ будет удобен вам. Смело взвешивайте за и против — и делайте так, как будет удобно вашему бизнесу.

Tech interview that doesn’t suck (Pt. 1)

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

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

Сразу откинем вещи, которые мы на технических собеседованиях не делаем (и не будем).

1️⃣🚫 Домашнее написание кода — разработка тестового приложения дома и презентация решения интервьюеру. Маленькое тестовое не имеет смысла (собрать одну красивую функцию или класс) — не говорит о человеке ничего — собрать силы в кулак, погуглить и написать десяток красивых строчек не так сложно. Просить сделать большое тестовое — его надо оплачивать и на него нужно выделять часы-дни для работы. На такое уже не у всех есть время, кандидату проще пойти в другое место, где не попросят писать много кода. А еще за большое тестовое надо платить — а это еще задержки, бумаги инвойсы и операционка. Неоплачиваемое большое тестовое — неэтично. Поэтому писать дома код мы не просим.

2️⃣🚫 Алгоритмические вопросы. Сегодня на работе мало кому надо писать сортировки массивов, обходы графов и прочие классические штуки — это делается готовыми библиотеками. Алгоритмические задачи в большинстве случаев будут нерелевантны рабочим задачам и не покажут навыки кандидата в решении прикладных задач. Исключение — если работа кандидата все же будет связана с алгоритмами напрямую — например, нужно оптимизировать перемещение товаров в графе маршрутов — тогда проверять это надо. С большим количеством алгоритмов мы не работаем — и алгоритмы реализовывать не просим.

3️⃣🚫 Многоступенчатые интервью с разными блоками вопросов. Нужно ценить время, свое и кандидатов. Поэтому мы не делаем 12 ступеней интервью, как это было одно время принято в Яндексе. Нам жалко и своего, и чужого времени — многоступенчатые технические интервью мы не делаем.

4️⃣🚫 Лайв кодинг. У нас он не запрещен, но не рекомендован. Написание сложного кода на экране, на который кто-то смотрит, вызывает у кандидатов стресс и не дает четкой картины. Написание простого кода смысла не имеет. Поэтому лайв кодинг у нас не в ходу.

5️⃣🚫 Обилие базовых вопросов по учебнику для программистов тоже не дает четкой картинки — их можно заучить и повторять, как попугай — при этом в работе над реальными задачами они не помогут. Но некоторые базовые понятия с кандидатом все же стоит проверить. Вокруг вопросов из документции мы интервью не строим.

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

Tech interview that doesn’t suck (Pt. 2)

✅ Мы отдаем предпочтения коротким, но емким вопросам, ответ на которые требует глубокого понимания предметной области сразу на многих уровнях. И поэтому мы проводим одно техническое собеседование на полтора часа + домашнее задание на рисование диаграммы системного дизайна.

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

📈 Работа над системным дизайном требует хорошего понимания архитектуры ПО, облаков, производительности железа и сетей. На интервью, за 15-20 минут дискуссии по вопросам архитектуры можно увидеть и глубину знаний, и способность мыслить, и опыт работы, и логику. Сама форма подачи задания тоже многое говорит о кандидате. Аккуратность и точность картинки, наличие комментариев — все это дает дополнительную информацию о рабочем подходе кандидата. Мы специально вступаем в спор с кандидатом по решению и просим аргументированно защитить позицию, обосновать решение. Интенсивная дискуссия показывает то, как человек ведет себя в небольшом стрессе, как он обосновывает свою позицию, насколько корректно и неконфликто он это делает. За эти 20 минут дискуссий и обсуждений мы узнаем о кандидате больше, чем раньше узнавали за два полуторачасовых интервью. Прохождение этой части интервью практически на 100% гарантирует, что мы сработаемся в дальнейшем.

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

Tech interview that doesn’t suck (Pt. 3)

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

Несмотря на кажущуюся простоту технического интервью (архитектурная диаграмма + полтора часа общения, из которых 20-30 минут мы отводим на вопросы кандидата к нам), нашей команде на собесе удается узнать очень много и принять взвешенное решение по найму. В среднем мы нанимаем лишь около 1% людей, претендующих на работу в нашей инженерной команде, а увольнения после найма крайне редки.

✌️ Мы ценим время, уважение и изящность — поэтому топим за короткие, эффективные, элегантные интервью, построенные на взаимном уважении и обоюдных вопросах друг-другу.

Менеджеры любят разделить единый организм проекта/бизнеса на составные фрагменты и управлять ими отдельно. Особенно этим грешит C-уровень, когда бизнес оценивается исключительно состоянием разных отделов. “Так, а что у нас там с маркетингом? А с продажами? А что в этом подразделении?”.

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

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

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

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

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

https://bryanlindsley.com/greatest-systems-thinking-books/ — а вот тут вы найдете 35 полезных книжек о том, что такие системное мышление и как с ним работать. Выбирайте парочку по вкусу и приступайте к практике решения сложных системных задач 🖖

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

Забивать, урезать и перепланировать 1:1 нельзя — это единственное и очень важное окно для менеджера, чтобы понимать и влиять на ситуацию, а для ведомого сотрудника — сделать свою жизнь проще и направить свою карьеру в правильное русло. Пусть эти встречи будут редкими и относительно короткими (20-30 минут раз в 2-4 недели), но они должны быть обязательными и регулярными.

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

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

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

Часто в технологических компания встречаются две очень похожих позиции — CTO и VP of engineering (у которого в подчинении могут быть еще и некоторое количество engineering manager). Эти две позиции примерно про одно и то же, но с задачи у них принципиально разные.

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

VP of engineering стоит на носу корабля, в основном спиной вперед (иногда, правда, поворачиваясь и заглядывая по курсу движения). Его задача — смотреть, чтобы во время движения судна за борт не упал груз, надстройка с каютами не сгорела, а сошедший с ума штурман не начал бегать по палубе и трясти, кхм, некоторыми органами. Короче, VP of engineering занимается тем, что контролирует и настраивает всю работу судового оборудования и команды.

Если у вас в команде около 10(+-3) человек технического народу — две сферы управления надо разделять на двух отдельных людей. Можно называть управленческие позиции как угодно, делать их парт-тайм — но, по сути, один управленец в технической команде должен обеспечивать четкую работу команды, а второй — следить, чтобы эта команда ехала к цели и не вмазалась в стену.

Что будет, если людей на эти две функции не выделить? Либо вы приедете не туда, куда собирались, либо во время путешествия у вас что-то пойдет не так, и ваши шансы на достижение финальной точки начнут резко снижаться.

Кстати, при общении с технологическими менеджерами успешных компаний я всегда спрашиваю о вещах, которые они сделали неправильно и о которых жалеют. Пункт “не наняли engineering manager” в первый год-два роста компании — вторая по частоте упоминаний боль управленцев. (Спойлер: первым пунктом шел “отказ от формального построения инженерной культуры”, но об этом в другой раз)

Полуторачасовой фильм об истории TypeScript и предпосылках появления этой технологии. Однако, это не скучный контент для JS задротов, а история того, как Microsoft изменила стратегию развития и повернулась лицом к производству open source продуктов. Авторы разбирают не только сам TypeScript, но и другие открытые продукты и их влияние на индустрию.

Открытое ПО частенько считается убыточным развлечением для ботанов и… это именно так, если подойти к вопросу разработке такого ПО неправильно. Однако, при правильном планировании и осознании этой области, open source это способ не только нагнуть конкурентов в вашей предметной области, а еще и вывести уровень технической команды на новые высоты и принести в этот мир что-то очень хорошее и нужное.

https://www.youtube.com/watch?v=U6s2pdxebSo

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

Обычно проблема управления личными знаниями и приоритетами решается с помощью заметок и записей. Но эти инструменты также имеют свои ограничения.

Для сохранения контроля необходима четкая и строгая система управления знаниями и задачами. Существует множество таких фреймворков, например, GTD и Zettelkasten. Сегодня я расскажу вам об еще одном - Second Brain. Этот фреймворк ориентирован не только на хранение информации, но и на действия, которые эта информация требует. Second Brain разработан в эпоху продвинутого софта для ведения заметок и отличается в лучшую сторону от старого (и не совсем актуального) GTD.

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

Чтобы понять, нагнут ли в ближайшее время человечество LLM (large linguistic models) вроде Chat GPT, стоит обратиться к работам американского ученого и лингвиста Ноама Хомского. Поскольку текущие версии ИИ, которые люди разрабатывают, плотно завязаны именно на языковых моделях, в книгах и статьях Хомского можно найти много релевантной информации, которая поможет разобраться в будущем LLM-based ИИ систем.

Вот его основные идеи.

1️⃣ Теория Универсальной Грамматики: Хомский предложил, что все человеческие языки имеют общую структурную основу, которую он назвал "Универсальной Грамматикой". Эта идея основывается на предположении, что языковые способности врождены и что все языки следуют определенным общим правилам и принципам.

2️⃣ Трансформационно-генеративная грамматика: Хомский разработал теорию трансформационной грамматики, которая описывает, как из базовых структур (глубинных структур) могут быть сгенерированы различные поверхностные структуры (то, что мы видим и слышим в реальной речи) с помощью трансформационных правил.

3️⃣ Гипотеза о врожденном языковом устройстве: Хомский предложил, что человеческий мозг обладает врожденным механизмом для приобретения языка (часто называемым Языковым Приобретательным Устройством), который облегчает понимание и генерацию языка.

4️⃣ Концепция Глубинных и Поверхностных Структур: Хомский различал между "глубинными" структурами языка, которые отражают его внутренние, универсальные аспекты, и "поверхностными" структурами, которые проявляются в различных языковых формах.


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