В каждой IT-компании стараются повысить технический уровень сотрудников, создать хорошую обстановку для профессионального роста и обмена знаниями. Казалось бы, что здесь всё давно придумано: от конференций и планов индивидуального развития до совместных обедов и пятничных посиделок. Но у каждого из этих форматов есть свои минусы. Например, конференции проходят не так часто, как хотелось бы, и отнимают довольно много времени, а неформальные посиделки часто проигрывают в приоритетах планам роадмапа. Мы в 2ГИС придумали собственное решение — и уже четыре года проводим инженерные литературные клубы. Расскажу, что это такое и что мы получаем в итоге. Мы хотели организовать такое пространство, которое позволит шарить знания среди инженеров лаборатории тестирования, расширять кругозор, глубже изучать технологии, с которыми работаем, делиться мнениями и рефлексировать на профессиональные темы. В общем, не только думать о проблемах наших проектов, но и смотреть на профессию и мир в целом. В 2018 году мы придумали инженерные литературные клубы, которые устраиваем регулярно — три–четыре раза в неделю. Они как раз отвечают нашим потребностям, а ещё вносят разнообразие в наши будни.  Сначала мы планировали читать только техническую литературу. Но со временем пришли к выводу, что наши профессиональные навыки не ограничиваются техническими знаниями. Чтобы работать эффективно, важно и понимание процессов, и умение организовать собственное время, и практика других компаний, и критическое мышление — даже знание когнитивных ловушек. В общем, специалисту помогают развиваться не только профессиональные навыки, но и личностные. А ещё широкий кругозор. Так со временем у нашего клуба появились базовые принципы. Литклуб — это встреча, где каждый может задать вопросы, поделиться мнением, услышать мнение других инженеров. Обычно на встречи приходят от четырёх до десяти человек. Книгами не ограничиваемся — можем обсудить видосик на ютубе, набор статей из разных ресурсов, выступления с конференций. Главное при выборе формата — учитывать мнение всех ребят. И чтобы тему можно было применить в нашей работе: разработка, технологии, тайм-менеджмент, математика, психология и множество других. Готовимся ко встрече в свободное время, а саму встречу проводим в рабочее. Мы учитываем её в роадмапе. Обычно она занимает два часа — за это время все успевают поделиться собственным мнением.  Можно приходить без подготовки. Если по какой-то причине участник не подготовился, он может поучаствовать в дискуссии и, например, решить, хочет ли он глубже познакомиться с той или иной темой в будущем. Каждый работает в комфортном ему формате: например, подготовиться частично. Иногда ребята читают только интересующие главы книг или находят краткое изложение. Для нас это тоже норм. Формат встречи может быть разным. Главное, чтобы в конце каждый участник поделился мнением о прочитанном. Актуальность и ценность новой информации помогают сформулировать два простых вопроса: «Одобряешь или осуждаешь?» и «Кому и в каком случае мог бы порекомендовать эту книгу/статью/доклад?». К каждому следующему клубу мы готовимся по простому алгоритму.  Генерируем идеи. Каждый участник накидывает источники информации, которые хотел бы изучить. Голосуем. Каждый участник смотрит список тем, которые предложили другие, и голосует за то, что откликается. Объявляем победителя. Ведущий выбирает тему, которая набрала больше всего голосов, и закидывает встречу участникам в календарь. Обычно встреча проходит через две недели после объявления победителя, чтобы у всех было время подготовиться. С инструментами мы прошли некоторую эволюцию. Сначала придумывали идеи и голосовали прямо в Slack, потом переехали в гуглдок. А в итоге мы пришли к доске в Trello — наша выглядит примерно так. С форматами много экспериментировали и, думаю, ещё продолжим эксперименты. Расскажу о нескольких, которые мы успели попробовать. Все начиналось с энтузиазма нашего руководителя, поэтому поначалу именно он исследовал тему, готовил план встречи, делал краткий обзор на материал и выделял наиболее интересные мысли. Конечно, все остальные тоже готовились и высказывались, но, как нетрудно догадаться, большая часть ответственности ложилась на одного человека. Кроме того, страдала вовлечённость менее опытных и менее активных ребят.  Плюсы такого формата: возможность делиться мыслями и получить экспертное мнение от сильного инженера. При таком подходе удобно читать хардкорные статьи и книги. Даже если кто-то ничего не понял, есть возможность послушать про то, что там было, и задать вопросы. В любом случае, все участники литклуба заранее в курсе, о чём пойдет речь, есть материалы для подготовки — и в этом преимущество перед митапом. На мой взгляд, это один из самых удачных форматов. Выбираем одну основную тему, несколько докладчиков читают разные статьи, каждый рассказывает свой материал, а все остальные обсуждают. Такие встречи проходят живо и непринуждённо, а ведущий выполняет только направляющую роль и в основном следит за таймингом. Из плюсов — высокая вовлечённость всех участников, сниженная нагрузка по подготовке, высокий уровень шаринга. Получается, что читаешь одну статью, а после встречи знаешь о нескольких. Это лёгкий и весёлый формат, но в нём есть и минус — он не подходит для чтения книг, главы которых связаны между собой (а таких 99%). А ещё не подходит для сложной литературы, которая требует вдумчивого и глубокого анализа. Пересказать такое трудно, впитать в себя несколько сложных тем за два часа от разных людей — тяжело. Ещё один лёгкий формат, главная фишка которого — найти холиварную тему и разделиться на два лагеря: за и против. В этом формате есть общие источники, которые читают все, и источники за и против, которые готовят заранее выбранные спикеры. Так, например, мы обсуждали тему парного программирования — и на встрече каждый из ребят мог аргументированно выступить с собственной точкой зрения. За таймингом также следит ведущий.  Холивары — это всегда весело, минусы — те же, что и в предыдущем формате. Из особенностей: не все темы, которые хочется обсудить, можно привести к формату холивара. Такая концепция подходит для таких тем, где IT-сообщество ещё не пришло к единому мнению. А ещё такой формат требует организатора, так как тему надо разделить участников по разным лагерям до самой встречи. Такой формат у нас закрепился в последнее время. Мы все изучаем один и тот же источник, на встрече в рандомной последовательности делимся мыслями о прочитанном. Ведущий следит за таймингом и подкидывает вопросы. Из плюсов — можно брать литературу любой сложности. Из минусов — в обсуждениях принимают участие в основном самые активные. Можно ли считать это минусом — вопрос спорный. Возможно, и неправильно ожидать 100% вовлечённости всей группы, но мой опрос показал, что многие ребята считают это недостатком. Добавлю, что разные форматы позволяют более гибко подходить к раскрытию разных тем, так что выбирать один формат на всю жизнь будет неправильно. Каждой теме — свой формат, тем более что их легко чередовать. Чтобы не быть голословной, я провела опрос среди участников литклуба. Все ребята считают эту активность полезной и видят эту пользу в возможности узнать что-то новое, услышать мысли коллег или перенять их опыт, а ещё обсудить интересные темы, связанные c книгой или близкие к ней. Занятное наблюдение: интересные и полезные темы — не одно и то же. «Про чистый код для себя я вынесла рекомендации. Например, что функции должны быть компактными, что функция должна выполнять одно действие, про именование переменных — нужно использовать содержательные имена и другие подобные. Вроде бы там советы были простые и логичные, но когда прочитываешь, они лучше закрепляются в голове». «Внутренности БД (из «кабанчика»), круто было про CRDT. Обычно не вчитываешься глубоко, а для клуба надо разбирать, структурировать понимание и слушать, о чём тебе говорят». «Узнала больше про когнитивный диссонанс и самооправдание, подходы к интерпретации нагрузки, про gRPC и GraphQL». «Многие книги вряд ли бы прочёл вне литклуба, например: "Не рычите на собаку!" и Gödel, Escher, Bach». «Много тем оказались для меня полезными. «Джедайские техники» — очень применимы в организации своего времени. «Чистая архитектура» — понравились цифры и мысль, что продуманная архитектура на старте экономит время в будущем при развитии и поддержке сервиса, а ответственность инженера — донести это до менеджера. «Высоконагруженные приложения» — часть про базы данных очень структурировала знания. Обсуждение gRPC, REST и GraphQL дало представление о том, какие особенности есть у приложений с интерфейсом GraphQL, понятнее сама парадигма и где стоит и не стоит применять».  Раньше 75% опрошенных ребят не могли выделять время на то, чтобы регулярно читать техническую литературу. А половина из них призналась, что с регулярными литклубами начали читать больше. Абсолютно все считают, что литклуб помогает расширять кругозор, и могут привести конкретные примеры тем, которые открыли на этих встречах. Книжки: «Site Reliability Engineering. Надежность и безотказность как в Google», Бейер Бетси, Джоунс Кри; «Вы, конечно, шутите, мистер Фейнман!», Ричард Фейнман; «Чёрная риторика. Власть и магия слова», Бредемайер Карстен; «Не заставляйте меня думать. Веб-юзабилити и здравый смысл», Круг Стив; «Не рычите на собаку! Книга о дрессировке людей, животных и самого себя!», Прайор Карен; «Джедайские техники», Максим Дорофеев; «Высоконагруженные приложения. Программирование, масштабирование, поддержка», Мартин Клеппман; The Pragmatic Programmer: From Journeyman to Master; «Чистый код: создание, анализ и рефакторинг», Роберт Мартин; Gödel, Escher, Bach: An Eternal Golden Braid, Douglas R. Hofstadter; «Психбольница в руках пациентов», Алан Купер; «Чистая архитектура. Искусство разработки программного обеспечения», Роберт Мартин; «Удовольствие от x: Увлекательная экскурсия в мир математики от одного из лучших преподавателей в мире», Строгац Стивен; «Факты и заблуждения профессионального программирования». Роберт Гласс; «Ошибки, которые были допущены (но не мной). Почему мы оправдываем глупые убеждения, плохие решения и пагубные действия», Теврис Кэрол, Аронсон Эллиот. Статьи: The Influence of Organizational Structure on Software Quality: An Empirical Case Study; Software Testing Anti-patterns; Things I Wished More Developers Knew About Databases; Monorepos; Distributed Systems for fun and profit; Testing in Production; статьи на тему GRPC vs REST vs GraphQL; «Мемуары PhD студента» (The Ph.D. Grind); Patterns for Generation, Handling and Management of Errors; статьи на тему: Are We Really Engineers? статьи на тему: AI в сфере разработки ПО. А ещё: доклад «Анализируем перформанс с пользой для себя и окружающих»; курс по геймификации на Coursera; холивар Pair Programming; холивар No Code; холивар Alternative organizational paradigms.  Возможно, этот список поможет найти вдохновение для собственных литературных активностей. Для нас практика совместных обсуждений оказалась невероятно полезна: она помогает не только расширять кругозор, но и повышать доверие в коллективе, создавать атмосферу, которая поощряет желание развиваться и создаёт пространство для обмена корпоративными и профессиональными ценностями.  Проводите ли вы в вашей компании литклубы или какие-то другие подобные встречи? Поделитесь опытом.