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

Профессиональная литература — сложный вопрос, особенно если говорить о литературе для руководителей в сфере IT. Чтобы понять, на что потратить вечно не хватающее время, мы опросили подписчиков канала «Тимлид Леонид» и собрали подборку из полусотни книг*. А затем добавили отзывы наших тимлидов к самым популярным. Так как список ниже глубоко субъективен и основан на отзывах незнакомых вам людей, оценивать литературу мы будем в «сферических совах».

---

1. «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» / Дорофеев Максим

TL;DR

Из книги вы узнаете:

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

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

Оценка: 6,50 сферических сов.

---

Мы в «ИТ Гильдии» уделяем особое внимание вопросам управления проектами и помогаем другим компаниям внедрять инструменты, которые оптимизируют работу в IT-отделах.

Сегодня мы собрали несколько полезных книг для PM’ов. В подборку вошла литература, которую рекомендуют к прочтению в тематических тредах на Hacker News, Reddit и Quora.

Год назад я начал работать на полную ставку в Bloomberg. И тогда же задумал написать эту статью. Я думал, что буду полон идей, которые смогу выплеснуть на бумагу, когда придёт время. Но уже через месяц понял, что всё будет не так просто: я уже начал забывать то, чему научился. Либо знания настолько хорошо усвоились, что мой разум заставил меня поверить, будто я всегда это знал, либо они просто вылетели у меня из головы.¹

Это одна из причин, по которой я начал вести дневник. Каждый день, попадая в интересные ситуации, я описывал их. И всё благодаря тому, что я сидел рядом с ведущим программистом. Я мог вблизи наблюдать за его работой, и видел, насколько она отличается от того, что сделал бы я. Мы много программировали вместе, что ещё больше облегчало мои наблюдения. Более того, в нашей команде не осуждается «подглядывание» за людьми, пишущими код. Когда мне казалось, что происходит что-то интересное, я поворачивался и смотрел. Благодаря постоянным вставаниям я всегда был в курсе происходящего.

Я год просидел рядом с ведущим программистом. Вот чему я научился.

Мы уже поднимали тему коммуникации как важнейшего навыка управленца любого уровня. Эффективность коммуникаций в компании напрямую влияет на её развитие, поэтому сегодня подробно обсудим два понятия: развитие и рефлексию.

Поговорим, что такое развитие в команде, что такое развитие человека и что такое развитие управленца. Рассмотрим траектории роста разработчика от исполнителя до тимлида. Обсудим, с чем придется столкнуться, что понадобится преодолеть и кем можно стать. Выясним, какие инструменты помогут и выделим пять областей развития тимлида.


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

Привет! Меня зовут Евгения Голева, я выступила на TeamLeadConf с докладом про обратную связь и хочу поделиться с вами его вольной расшифровкой. Мне удалось под соусом совсем другого проекта научить инженеров давать обратную связь гораздо лучше, чем они делали это раньше. Для этого пришлось не только долго и тщательно объяснять «зачем и как», но и организовать множество подходов к снаряду под бдительным контролем и с мягкой поддержкой. Путь был непростым, усеян граблями и велосипедами, и я надеюсь, что некоторые неочевидные мысли и методы пригодятся тем, кто хотел бы привить культуру здорового фидбэка своей команде.

Новая команда для тимлида — стресс не меньший, чем новый тимлид для команды. «С чего начать, на кого положиться, кому помочь в первую очередь? Как всех запомнить, какие здесь традиции, регламенты, что если я не уложусь в испытательный срок и не заработаю доверие?» Этими вопросами задается любой тимлид на новом месте. Когда Алексей Петров (pifagor_mc) перешел в FunCorp, то также искал ответы. Нашел их и на TeamLead Conf рассказал, как максимально комфортно войти в новую компанию на позицию руководителя в первый или n-й раз. При этом комфортно будет не только вам, но и сотрудникам компании.


Алексей Петров — QA Head в FunCorp. В 19 лет увлекся тематикой IT благодаря интересу к компьютерным играм. Работает в сфере с 2005 года, а руководит — с 2010. Прошел путь от младшего тестировщика до директора по качеству.

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

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

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

Вышедшая в 2015 году Agar.io стала прародителем нового жанра игр .io, популярность которого с тех пор сильно возросла. Рост популярности игр .io я испытал на себе: за последние три года я создал и продал две игры этого жанра..

На случай, если вы никогда раньше не слышали о таких играх: это бесплатные многопользовательские веб-игры, в которых легко участвовать (не требуется учётная запись). Обычно они сталкивают на одной арене множество противоборствующих игроков. Другие знаменитые игры жанра .io: Slither.io и Diep.io.

В этом посте мы будем разбираться, как с нуля создать игру .io. Для этого достаточно будет только знания Javascript: вам нужно понимать такие вещи, как синтаксис ES6, ключевое слово this и Promises. Даже если вы знаете Javascript не в совершенстве, то всё равно сможете разобраться в большей части поста.

Исследования показали: получив конструктивный фидбек, сотрудники работают лучше. Если обратной связи нет, появляется стресс: трудно понять, хорошо ли ты справляешься и куда двигаться дальше. Возникает «кризис признания» – а там не за углом и выгорание.

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

Качество кода — тема, которая родилась вместе с программированием. Для оценки и контроля качества менеджмента предприятий применяется ISO 9000, для продуктов — ГОСТ и тот же ISO, а вот для оценки качества кода ГОСТа нет. Точного определения и стандарта для качества кода тоже нет.



Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.

В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.

Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.

В этой части мы решим задачи об оптимальном размещении оружия на танке, пространственном расположении телепортов в MMORPG и сбалансируем бои четырёх классов персонажей RPG.

Задачи о размещении объектов

Электронные таблицы для этой части можно скачать здесь: (SuperTank) (телепорты, часть 1) (телепорты, часть 2)

SuperTank: задача решена!

В первой статье серии мы рассказали о примере задачи для игры под названием SuperTank. Во второй её части, мы познакомились с основными концепциями моделирования решений и я рассказал о решении простого примера с помощью инструмента «Поиск решений» в Excel.

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

Команда скорости Яндекса вручную оптимизирует поисковую выдачу. Делать это вслепую трудно и зачастую просто бесполезно. Поэтому в компании построили инфраструктуру для сбора метрик, тестирования скорости и анализа полученных данных.

О том, какие метрики стоит использовать и как все оптимизировать, знает разработчик интерфейсов Яндекса Андрей Прокопюк (Andre_487).



В основе материала — выступление Андрея на конференции HolyJS. Под катом — и видеозапись, и текстовая версия доклада.

Выбор подходящей архитектуры — ключевая часть построения фронтенда сервиса. Разработчик Анна Карпелевич рассказала студентам Школы разработки интерфейсов, что такое архитектура, какие функции она выполняет и какие проблемы решает. Из лекции можно узнать о наиболее популярных архитектурных подходах во фронтенде: Model-View-* и Flux.


— Добрый вечер. Меня зовут Аня Карпелевич. Мы сегодня с вами будем говорить про архитектуру фронтенда верхнего уровня.

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

Проблемы, симптомы

Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.

Хожу по job interview. Где-то скучно, где-то весело. Где-то интересно. На одном из таких меня попросили написать функцию, которая умеет складывать два числа. Я написал:

  it ('should add two numbers', function () {
    var add = function (a,b) {
      return a + b;
    };

    assert.equal(add(2,3), 5);
  });

А если, говорят, сигнатура функции должна быть типа такой: add(num1)(num2)? Не вопрос, говорю. Думая, что хитрый буржуин хочет проверить, знаю ли я про то, что можно возвращать функции из функций, пишу вот такое:

  it ('should be called like add(num1)(num2)', function () {
    var add = function (a) {
      return function (b) {
        return a + b;
      };
    };

    assert.equal(add(2)(3), 5);
  });

Многие из нас бывали на айтишных конференциях. А если не бывали, то наверняка смотрели трансляции, записи или читали расшифровки докладов на Хабре. А вы знаете, какие доклады становятся хитами даже на самых-самых хардкорных мероприятиях? Внутренности сложных технологий? Нет. DevOps? Отнюдь. Чаще всего приз зрительских симпатий берут так называемые доклады-кейноуты — презентации людей, вовсе не обязательно связанных с IT. Дело не в красивой презентации и даже не в харизме докладчика, а в том, что эти ребята знают секрет SUCCES. Нет, мы не опечатались.

Источник: Duran

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

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

Во-вторых, вы можете использовать их для создания сообщества, при этом прилагая усилия там, где они наиболее необходимы.

• Четкая миссия – заявленная причина существования группы.
• Свободное участие – насколько легко люди могут присоединиться к группе.
• Прозрачность – насколько открыто и публично принимаются решения.
• Бесплатные участники – как много можно платить людям за участие.
• Свобода работы с материалами (ремиксабельность) – насколько свободно участники могут использовать работу друг друга.
• Четкость протокола – насколько хорошо прописаны правила.
• Компетентность власти – насколько хорошо следят за соблюдением правил.
• Нон-трайбализм – насколько далеко распространяются права группы над своими участниками.
• Самоорганизация – насколько свободно могут участники определять свои задачи.
• Толерантность – как группа разбирается с конфликтами.
• Измеримый успех – как хорошо группа может отслеживать свой прогресс.
• Высокое награждение – как группа вознаграждает своих участников.
• Децентрализация – насколько широко распределены участники группы.
• Свободная рабочая среда – насколько легко создавать новые проекты.
• Стандартная структура – насколько общая структура стабильна и предсказуема.
• Плавность обучения – насколько легко начать и продолжить учиться.
• Позитивность – насколько группа движима позитивными целями.
• Чувство юмора – насколько серьезно группа себя воспринимает.
• Минимализм – сколько лишней работы делает группа.
• Разумное финансирование – как группа борется за выживание в экономическом плане.

Спасибо Сергею Даньшину за помощь с переводом.

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

Повседневные фразы и инструкции

Тут сразу стоит отметить, что в английском довольно много фразовых глаголов, которые очень популярны, особенно в разговорной речи. Понятное дело, что sit down, stand up или come up уже никого не удивят, но есть другие интересные случаи, и не только с фразовыми глаголами.

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

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

Недавно мы запустили новый проект под названием Froala Design Blocks. Через несколько дней мы попали в список самых популярных репозиториев GitHub. Спустя неделю мы набрали 3500 звезд и в течении следующих двух стабильно собирали еще по 500 в сутки.



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

Froala Design Blocks — не первый наш продукт, мы на GitHub уже несколько лет. Но я только недавно стала осознавать ценность звезд и вникать, каких правил нужно придерживаться, чтобы люди их ставили. Так что надеюсь, и новички, и ветераны найдут здесь что-нибудь новое для себя о том, как в полной мере использовать потенциал звезд для представления и усовершенствования своего проекта.