Хабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pet project вы создаете с нуля, и не важно, о чем он, какой сложности и сколько у него скачиваний на Apple Store. Собственные проекты будут первейшим индикатором ценности на рынке, а не то, где вы 5 лет подряд дорабатывали софт, который достался вам в наследство. Пусть будет 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-сфере существует русскоязычное сообщество, с которым, мне кажется, надо бороться всеми силами. Хабр, как пионер этого сообщества, оказывает медвежью услугу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть