Пять пугающих трендов современной разработки

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

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

Егор Бугаенко знает, что нужно делать уже сейчас, чтобы и через 5–10 лет оставаться востребованным программистом. Его идеи, как и всегда, могут показаться спорными. Вам и не нужно безоговорочно с ними соглашаться, но задуматься, например, о pet project лишний раз не повредит. Да и в том, что программисту необходим английский язык, вряд ли могут быть разные мнения. А вот по остальным пунктам будет интересно узнать мнение сообщества в комментариях.



Дальше идет текстовая версия доклада Егора на AppsConf, но относится он не только и не столько к мобильной разработке, сколько к отрасли в целом. Егор Бугаенко основатель Zerocracy, разработчик Cactoos, Takes Framework, JCabi и других open source проектов. Написал серию книг «Elegant Objects», ведет провокационный блог и выступает с докладами, заставляющими задуматься, такими как этот.

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

Мне было интересно, как собрать приложение в один пакет, то есть не просто нарисовать на экране какие-то кнопки, а сделать именно цельное приложение. Очевидно, код, например, на Swift и продукт в мобильном телефоне — это две совершенно разные вещи: первая очень маленькая, а вторая очень большая и включает в себя такие вопросы:

• Unit-тесты;
• статический анализ;
• Continuous Integration;
• управление зависимостями;
• Continuous Delivery;
• Staging Environment;
• процесс approve приложения в Apple Store;
• процесс сборки дефектов с продакшена и т.д.

Как расставить на экране кнопки легко прочитать в интернете. Мне нужен был специалист, эксперт, который помог бы мне собрать весь pipeline. Для меня, как программиста, это важнее, чем расставить кнопки на экране.

Я нашел такого специалиста, но он мне сказал: «Зачем ты об этом думаешь? Нарисуй сначала приложение. Какой Continuous Integration? Подожди пока с Unit-тестами — сделай, чтобы заработало. Какой Delivery pipeline? Зачем TestFlight — используй симулятор».

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

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

Сначала деплой, потом код

Я пишу книги о программировании, и знаю по себе, что книга получится хорошо, если сначала ее красиво оформить. То есть я занимаюсь оформлением книги до того, как пишу. Сначала делаю makefile, который прямо из командной строки собирает всю книгу из файлов на LaTeX, готовлю тексты, картинки, обложку. Я трачу много времени и делаю так, чтобы одной командой собрать всю книгу в PDF-файл. Уделяю большое внимание тому, как она будет выглядеть, где какие отступы, какие текстовые блоки и расстояние между ними, как будут нумероваться страницы. Когда мне все это нравится, я вижу, что все красиво собирается и все в этом продукте цельно, пусть и написана пока только одна страница, только тогда я начинаю писать книгу, и только тогда мне это доставляет удовольствие.

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

Приведу еще один пример. Один начинающий разработчик вызвался делать с нами open source проект. Он выбрал Flutter, сделал первую итерацию, запустил, сказал, что все здорово и круто работает, и предложил посмотреть. Спрашиваем: «Как пробовать-то? Вот iPhone — куда нажимать?». На что он стал объяснять, куда зайти, что скачать— длинный процесс.

Нам это показалось неудобным, и в итоге он согласился, что действительно приложение надо выложить на TestFlight. Еще через какое-то время он показал приложение на TestFlight. Я понажимал на кнопки, и заметил некоторые дефекты. Я не работал с Flutter и не очень-то и хотел, но хотел быстро поправить то, что заметил. Я спросил, как мне это сделать, куда и как прислать pull request. Открываю репозиторий, readme-файл: «Это крутое приложение… нажми download…».

Инструкция была сложная и непонятная, я опять переспросил, как все это развернуть на своем компьютере. Я хотел простым нажатием нескольких кнопок на своем компьютере модифицировать чужой код, запустить симулятор и отправить pull request. Тот парень ушел это все описывать, и так и не вернулся.

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

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

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

Новичок должен попадать в среду, которая ему дружественна с точки зрения сборки — он должен открыть readme-файл и за несколько минут понять, как сделать так, чтобы на симуляторе все запустилось. Что нажать, чтобы проверить, все ли собирается из командной строки — не из сложных IDE, которые нужно еще несколько часов настраивать. Должна быть возможность написать в командной строке make/build/etc. После чего все соберется и напечатает зеленую строку — все готово — дальше pull request. Это первая мысль, которой я сегодня хочу поделиться.

Конечно, вы скажете, что вы работаете не одни, не как единственные основатели проектов, не как CTO. Вы работаете в командах и нельзя просто прийти и заявить, что теперь вы будете заниматься деплоем, TestFlight, и вам нужно срочно разобраться в CI. Это не ваша задача, вам не дадут на неё время и пр.

Поэтому я рекомендую, делать свои собственные pet projects — проекты, которые вы делаете в свое удовольствие, — чтобы понимать все целиком.

Всего у 20–30% программистов есть собственное опубликованное приложение, а должно быть у всех. Если вы считаете себя и хотите быть востребованным программистом, я бы рекомендовал сделать свое мобильное приложение и пройти весь цикл его выхода на рынок: проверки на Apple Store, CI, упаковки и всего остального. Сделайте его open source, чтобы люди могли контрибьютить и показать вам, как у них это не получается.

Посмотрите, как вы работаете с рынком, попробуйте и поймете, какие вы программисты. Я считаю, плох тот программист, у которого нет pet projects.

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

Второй страх, на мой взгляд, — это деньги.

Сколько кода вы напишете за 100$?

На платформе Zerocracy я работаю с массой программистов и заметил, что они очень часто боятся денег. Они привыкли к оплате в конце месяца, и достаточно болезненно относятся, когда их оценивают в деньгах. Многие не могут ответить на простой вопрос: «Знаете ли вы, сколько можете сделать кода за 100$?»

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

Время full-time разработчиков с фиксированной оплатой уходит.

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

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

Рынок становится глобальным, удаленный доступ на рынок труда все проще и проще. Компании, находящейся в Москве, будет неинтересно и невыгодно переучивать людей, например, с iOS на Android или с C++ на Java. Проще нанять новых специалистов, которые придут как фрилансеры, выполнят задачу и уйдут.

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

От программистов это новое время ожидает:

• Умения понимать, сколько вы стоите. То есть дать оценку, сколько стоит ваш рабочий час, сколько ценности вы за него создадите.
• Способности работать во временных условиях.
• Навыков себя продать, правильно преподнести. У разработчика-фрилансера на глобальном рынке должно быть «торговое преимущество» и цена.

Многие люди боятся заниматься построением резюме, боятся себя продавать. Как я уже говорил, я думаю, что в резюме обязательно должен быть пункт pet project.

Собственные проекты будут первейшим индикатором ценности на рынке, а не то, где вы 5 лет подряд дорабатывали софт, который достался вам в наследство. Pet project вы создаете с нуля, и не важно, о чем он, какой сложности и сколько у него скачиваний на Apple Store. Пусть будет 0 лайков и 2 загрузки, но это цельный проект, созданный вами самостоятельно.

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

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

Ищите альтернативы, смотрите, пытайтесь, продавайтесь. Сначала вас не будут покупать, будут проблемы — масса проблем! Но решая эти проблемы, вы станете более востребованным программистом более высокого уровня.

К сожалению, не только сами программисты не могут определить цену работы, но и заказчики. Иногда мне предлагают выполнить отдельные задачи, как эксперту. И часто заказчик, который предлагает мне работу, не понимает, как меня оценивать. Чаще всего люди просто хотят подешевле, например 50$, не 100$, в час. Я понимаю, что человек с таким подходом, все равно не понимает, сколько реально за этот час я напишу. Тогда я соглашаюсь и просто умножаю количество часов на 2. В результате получаю столько, сколько и хотел изначально.

Я знаю свою реальную стоимость и скорость работы. Заказчики не готовы к суммам 100–500$ в час, для них 20 уже много, поскольку они привыкли к формату full-time employment за время. То есть когда человек получает деньги за время, которое якобы полностью тратит на разработку.

Не знаю, как вы, но я не могу сидеть 8 часов и писать код. Уверен, каждый из вас подтвердит, что из 8 рабочих часов, которые вы находитесь в офисе или за компьютером, вы реально пишете код гораздо меньше. А платят за эти 8 часов, и заказчик думает, что это 8 часов работы. Это система двойного обмана: те рады обмануться, а мы их обманываем. Поэтому я использую коэффициент умножения. Хоть за 20 буду работать, но тогда буду делать 3 недели то, что реально сделаю за 2 часа.

Учите своих клиентов и учитесь сами считать деньги.

Хорошие программисты пишут код, лучшие — тикеты

И заказчики, и программисты привыкли к неформальному общению.

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

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

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

К сожалению, чаще всего программисты идут на поводу у заказчиков. Безусловно, в интересах клиента иметь возможность неформального общения с разработчиком. А мы оказываемся достаточно слабыми и идем у них на поводу, слушаем по телефону, что должно быть сделано, отвечаем, слушаем, отвечаем… а потом идем и делаем.

Потом проходит 2–3 недели, и мы уже не помним, о чем договорились. Заказчик говорит, что хотел не это, мы пытаемся доказать, что именно это он и просил, выискиваем какое-нибудь упоминание в чате — начинается ловля блох.

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

Людям легче сказать: «Давай поговорим! Проведем митинг, сядем вместе и все решим. За 3 часа поймем друг друга, а потом я пойду и закодирую это. Я буду помнить, о чем мы договорились, и все запрограммирую». Забудем —ничего, встретимся еще раз. И так мы от митинга к митингу как-то протянем.

Это неправильно. Мы, как программисты, должны любое неформальное общение конвертировать в тикеты. Поговорили с клиентом (заказчиком, product-owner’ом, другим программистом), узнали, что нужно поменять — любую коммуникацию конвертируем в тикет ограниченный рамками нашей системы (Jira, GitHub и т.д.), где прописываем: что не работает, как нужно исправить, почему нужно исправить, какая мотивация, и потом по этому тикету работаем.

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

• Непрерывная разработка — программирование с 9 утра до 5 вечера: пришел, компьютер включил, тут что-то сделал, там, обед, еще покодировал, конец дня — ну ладно, завтра продолжу. То есть программируем, пока есть энергия, время, силы.
• Инкрементальная разработка другая: есть задача №13, сделаю до конца, а потом посмотрю, какая задача следующая. В этом виде задача (тикет) всегда будет завершен. Зато, если тикета нет, нет сформулированной документированной задачи, проект не двигается — код не пишется, и не появляются pull request.

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

Во втором варианте каждый тикет завершается pull request’ом: вот проблема, ее описание, дискуссия в области этой проблемы, изменение в коде. Pull request отправлен, проверен, принят — тикет закрыт, можно переходить к следующему.

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

Некоторые ошибочно считают, что инкрементальная разработка обязательно означает задачу длиной в 2 недели, и что тикет должен заканчиваться pull request’ом в 5 тысяч измененных строк. Это не инкрементальная разработка. Инкрементальная — это задача на 0,5–2 часа, и в конце pull request из 50-100 строчек кода. Непрерывная наоборот — долго-долго работаете (днями, неделями) и мало что производите.

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

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

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

Какой язык программирования изучать первым? Английский!

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

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

Как я уже сказал, мир разработки становится глобальным, программистов из Москвы будет все меньше и меньше — будут просто программисты, например, на Swift, а то, что вы из Москвы, будет мало кого волновать. Программисты будут продавать себя по всему миру через интернет, а не через интервью в офисе. Так или иначе этот рынок придет, пусть через 5-10-15 лет, и вы просто можете оказаться за бортом.

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

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

Чтобы повысить свой уровень английского, я могу порекомендовать следующее.

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

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

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

Последнее и самое главное — пишите на английском. Ведите Twitter, блог, Telegram-канал на английском языке. Сначала вас никто не будет читать, потому что ваш английский будет ломаный. Но в итоге вы серьезно продвинете свой профессиональный уровень.

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

Английский язык будет определяющим на рынке через 5-10 лет. Стоимость специалиста с плохим английским в 2 раза ниже, потому что он не может встроиться в команду, ему тяжело понять существующую документацию.

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

Нет фолловеров на GitHub — ты не настоящий программист

Я думаю, что мир сейчас двигается в сторону open source кода, и что через 10–15 лет вообще останется только open source, за исключением специальных проектов (NASA или военных).

Весь остальной код будет в открытом формате, это неизбежно.

У open source разработки есть свои особенности. Написать код, запаковать и выложить — только полдела. На пути возникнут совсем не программистские проблемы: сначала ваш код не будет никого интересовать, ваши pull requests тоже, их будет сложно писать и конфигурировать, вам не будут ставить лайки и звездочки на GitHub, вашим продуктом не будут пользоваться.

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

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

Я думаю, мы станем сборщиками — ассемблерами, а не кодерами. Кодинг, как таковой, будет занимать меньшую часть времени и будет меньше нужен. Нужно будет умение собрать из open source-компонентов конечный продукт. Для этого нужно уметь контактировать с open source community: не только брать, но и давать что-то, писать тикеты, отправлять pulll request, создавать свои продукты.

Уже много лет я примерно раз в месяц создаю свою open source-библиотеку, выкладываю в открытый доступ готовый продукт: пакет, библиотеку, фреймворк или документацию — что-то реальное. Сейчас у меня 2 300 followers на GitHub — это довольно много, но это результат 6 лет работы.

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

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

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

Однако архитектор развел руками — он не знал, как это сделать. Его социальные связи, 20 подписчиков в Twitter и 2 репозитория на GitHub, не помогали решить задачу. Но если бы он был активным open source-разработчиком, вел блог и делился бы наработками в социальных сетях, то ему было бы легко найти эксперта. Достаточно было бы использовать силу своего сообщества.

Если вокруг вас маленькое сообщество — вы плохой разработчик.

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

У Егора Бугаенко широчайший кругозор, он может мотивировать развиваться в разных направлениях. Егор уже выступал у нас на DevOpsConf Russia про качество, которое якобы не главное, на QualityConf про качественную разработку в распределенных командах. В сентябре на Saint TeamLead Conf вместе с Егором обсудим заново набирающую популярность тему микроменеджмента.

Хотите быть в курсе наших грандиозных планов и новых публикаций — выберете список и подписывайтесь. Мы пишем только по делу.