TechLead Good Reads

leadgr Нравится 0
Это ваш канал? Подтвердите владение для дополнительных возможностей

Коллективный канал техлидов. Каждую неделю – новый ведущий, который делится своим опытом и интересными материалами.
Автор проекта: @etolstoy
Гео и язык канала
Россия, Русский
Категория
Технологии


Гео канала
Россия
Язык канала
Русский
Категория
Технологии
Добавлен в индекс
17.12.2017 12:09
Последнее обновление
20.11.2018 21:32
Telegram Analytics
Самые свежие новости сервиса TGStat. Подписаться →
Searchee Bot
Поисковик по самой большой базе Telegram-каналов.
@TGStat_Bot
Бот для получения статистики каналов не выходя из Telegram
1 408
подписчиков
~1.4k
охват 1 публикации
~1.8k
дневной охват
~2
постов / день
99%
ERR %
0.47
индекс цитирования
Последние публикации
Удалённые
С упоминаниями
Репосты
TechLead Good Reads 20 Nov, 12:30
Сегодня хочется поговорить про инженерную культуру Google, компании, которая подарила миру невероятное количество инструментов, практик, подходов и продуктов.

Начнём, пожалуй, с такой важной темы как инцидент-менеджмент. А если конкретнее, то про анализ инцидентов и предупреждение их в будущем.

Рано или поздно, любая компания переходит на стадию, когда подход «быстро поднятое, упавшим не считается» перестаёт работать, потому что каждая минута простоя сервисов выливается в крупные финансовые потери. И бизнес не хочет, чтобы такие количество таких инцидентов в будущем было минимальным. Google, как очень крупной компании, это было сверхактуально и они разработали свой подход к сбору и анализу ошибок - написание postmortem’ов.

Что это такое: это детальный документ, в котором описываются все подробности случившегося инцидента: статус, impact, как решели проблему, как развивался инцидент с подробным таймлайном, конкретные action items и уроки, которые вынесли из него. Многие компании подхватили эту практику и используют у себя. Хорошим тоном считается публикация postmortem’ов в открытый доступ, для того, чтобы другие компании могли учиться не только на своих ошибках, но и на чужих.

Что почитать на эту тему:
https://landing.google.com/sre/sre-book/chapters/postmortem-culture/ - оригинальная статья от Google
https://landing.google.com/sre/sre-book/chapters/postmortem/ - пример конкретного Postmortem’a.
https://github.com/danluu/post-mortems - большая подборка postmortem’ов от разных компаний, собранных в одном месте и сгруппированных по типам проблем.

Автор последнего поста не очень часто обновляет подборку, но в pull request’ах можно найти свежие ссылки от сообщества.
TechLead Good Reads 19 Nov, 20:22
А вот про следующий подход, как мне кажется, знают не многие, потому что информации о нем в интернете представлено очень мало. Это то, как устроено целеполагание в небезызвестной Spotify. В определенный момент времени, они отказались от постановки целей через OKR и разработали собственный фреймворк стратегического планирования «Spotify Rhythm».

Если кратко описывать его, то можно выделить 3 основные сущности, которые используются для определения целей во всей компании:

Company beliefs - основа модели, описание видения того, каким будет мир вокруг компании через 3-5 лет.
North Star - верхнеуровневые цели компании на ближайшие 2 года.
Bets - конкретные инициативы и проекты. Они бывают разного уровня - компании, функциональные или рыночные. Для запуска нового проекта, используется фреймворк DIBB (Data-Insights-Belief-Bet).

Чуть более подробно посмотреть можно на слайде с одной из презентаций: https://blog.crisp.se/wp-content/uploads/2016/06/Spotify-Rhythm-Agila-Sverige.pdf

Небольшая статья о преимуществах работы по такому подходу: https://hackernoon.com/place-your-bets-4022b732ba4c
Attached file
TechLead Good Reads 19 Nov, 18:57
Для разминки поговорим немного про такую важную штуку, как целеполагание.

В Авито, для работы с целями, мы уже несколько лет активно используем систему OKR, которая внедрена на уровне всей организации. Про то, как это устроено у нас, очень подробно рассказал Денис Дудоров на одном из митапов: https://www.youtube.com/watch?v=49Yz59e2yfc

На тему OKR написано огромное количество статей и гайдов. Приведу несколько:
https://medium.com/@robingop/целеполагание-с-помощью-okr-7934ac3d7303 - хорошая вводная статья, объясняющая что такое OKR и зачем они нужны.
https://habr.com/company/wrike/blog/329272/ - хорошая статья с конкретными примерами.
https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/ - гайд от гугла по постановке целей используя OKR (en).

И в догонку - шаблон OKR для быстрого старта. Отлично подойдет, если захотите попробовать внедрить у себя в команде/компании:
https://docs.google.com/spreadsheets/d/1-5y32GQKyshg9GUXjIreyuzI0DXnPOmv9BHqeurY4G0/edit#gid=0
TechLead Good Reads 19 Nov, 17:21
Всем привет! На этой неделе, каналом буду рулить я, Федоров Никита, известный как @nik3r.

По традиции представлюсь и расскажу немного о себе. В IT кручусь уже больше 8 лет. Последний год работаю в Avito как техлид юнита Billing. Отвечаю, как можно понять из названия юнита, за биллинговую систему, а так же за оплату услуг и интеграции с платежными провайдерами. До Avito работал техлидом в компании RuCenter, отвечал за разработку практически всего веба.

Предыдущие ведущие, @glamcoder и @dumtest, высоко подняли планку качества постов, поэтому буду стараться не опускать её и делиться максимально полезным контентом.

Обсуждать увиденное тут призываю в чатике для тимлидов "Боль Тимлида" (https://t.me/TeamLeadTalks), я там тоже есть. Если есть желание обсудить что-то лично, пишите мне, с удовольствием отвечу тоже (@nik3r).
TechLead Good Reads 16 Nov, 15:05
Всем пятницы. https://www.youtube.com/watch?v=McCgpTONOV8 - Ролик с одного из http://codefreeze.ru/ об ещё одной важной части инжереной деятельности. Борис Вольфсон (долгое время был СТО hh.ru) об эффективных ретроспективах. Имхо процесс крайне важный для команды, даже если вы не адепт гибких метолодогий. Покопаться в сделанном и не сделанном крайне полезно. Два часа на просмотр, поэтому под выходные:)
TechLead Good Reads 15 Nov, 15:18
Привет! Просто интересная заметка о строка кода и тестах в Oracle Database 12.2 и рассуждения автора и комментаторов на эту тему. Просто оцените масштаб цифр https://news.ycombinator.com/item?id=18442941
TechLead Good Reads 14 Nov, 15:02
Привет, пока нет нового ведущего, я буду подкидывать иногда что-нить интересное, так что если что - это @dumtest:)

Для затравочки достаточно познавательная и с высокой моралью история ООП. Вы же не забыли ещё, что это такое? Автор - Эрик Эллиот - активист всяких там сооществ, автор книжки про программирование на джаваскрипте и просто дюже толковый чувак. Обязательно прочитайте каменты к статье - там тоже много интересного. https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f
TechLead Good Reads 13 Nov, 00:50
На этой неделе выделенного ведущего нет. Если чувствуете в себе силы и желание повести канал сейчас или в будущем – пишите @etolstoy, поставлю вас в план.
TechLead Good Reads 11 Nov, 11:06
Привет!

https://medium.com/@krisgage/8-things-i-learned-reading-50-books-a-year-for-7-years-cb11c4acffb1 - статья, так сказать, на ход ноги и в тему каналов и чатов, где публикуют избранные, если можно так сказать, материалы. Они экономят кучу времени и защищают от откровенного треша. Это статья от чувака, который прочитал больше !!300!! книг за 7 лет и решил поделиться с нами своими соображениями. Имхо очень по делу, слегка самокритично и с хорошими мыслями и заключениями. Понятно, что на вкус и цвет, понятно, что все мы разные, но иногда пара мнений со стороны может сэкономить кучу времени и сил. Я сам неоднократно начинал читать и бросал, не осилив и трети, потому как понимал, что не моё. По правде сказать, были случаи, когда я возвращался к отложенной книжке и дочитывал. Скорее всего я достигал нужного уровня просветления, либо понимания сути вопроса.


Всё. С вами эту неделю был я, Роман Ивлиев. Спасибо, что терпели меня! Надеюсь, что я не разочаровал:) Вести такой канал - это серьёзный и сложный, но очень полезный труд. Я честно перечитал всё, что опубликовал, прошерстил свои списки статей, которые когда-то были помечены, как крутые и интересные и …. выкинул в корзину 2/3 по причинам, которые описал коллега по ссылке выше:))))

Всего вам доброго и до новых встреч!

Фб, твитер, тг: @dumtest
почта: [email protected]
скайп: roman.ivliyev

З.Ы. важная новость для тех, кто гоняет или планирует гонять GraphQL в своих проектах.

https://techcrunch.com/2018/11/06/facebooks-graphql-gets-its-own-open-source-foundation/

GraphQL, the Facebook -incubated data query language, is moving into its own open-source foundation. Like so many other similar open-source foundations, the aptly named GraphQL Foundation will be hosted by the Linux Foundation.

Это очень круто, потому как теперь совершенно официально эта технлогия будет поддерживаться и развиваться не только ФБ, но и ещё несколькими уважаемыми организациями, что делает продукт более надёжным для игры с ним в долгую на своих проектах.
TechLead Good Reads 10 Nov, 13:57
Доброе субботнее утро:) Как и обещал - много всего про технический долг. Долго растекаться мыслью по древу не буду. Скажу лишь, что с техническим долгом можно жить и вполне себе сносно справляться, если отнестись к нему серьёзно, но лучше бы всё-таки не быть должным, потому как техдолг - это кредит, а не рассрочка, а значит будут проценты, а следом будет технический дефолт. Я помню момент, когда в одной из контор, где мне довелось работать, на одной из команд был совокупный долг по оценкам в комадогод. Т.е. по сути шансы на его устранение были почти равны нулю. Тем не менее - покривлялись, отприоритизировали, кое-что признали вечным долгом, кое-что выкинули с пометкой - это не долг, в итоге решили этот вопрос. Но больше так не запускали ситуацию.

Хотел найти видос от Бориса Вольфсона (он тогда ещё был техдиром ХХ) "
Стратегия сокращения технического долга” , но не смог:( Если подвернётся - обязательно посмотрите, но есть видос от Антона Бевзюка с аджайлдэйс 2014 - http://talks.rosalab.com/20140321-54

Также тему техдолга неплохо осветил Максим Шульга, а главное - в конце стать куча ссылок на хорошие материалы. https://www.maxshulga.ru/2014/03/technical-debt.html - не смотря на то, что все материалы написаны до 2014ого года, менее актуальными они не стали.

Ну и тем, кто совсем решит разобраться и изучить максимальное количество точек зрения на этот вопрос - обещанный лонгрид https://www.infoq.com/minibooks/emag-technical-debt. Очень много букв и разных точек зрения. Для скачивания попросят зарегистрироваться, не переживайте - Инфоку не сильно спамит рассылками и всегда можно отписаться, а материалы там попадаются периодически очень интересные.

До завтра!
TechLead Good Reads 9 Nov, 17:59
В продолжение предлагаю ознакомиться с двумя “феноменами”, которые частенько проскакивают в буржуйской литературе, русскоговорящие авторы не очень её жалуют, но тоже иногда упоминают ( если повнимательнее посмотреть на текст Артёма из утренней почты, то T-shaped стоит в тегах статьи). Важно! Я не буду говорить про фул-стек-инженеров. Я про них не забыл, и это тоже проявление кросс-функциональности. Это близко нам и примерно и так все понимают. Но сейчас речь немного не об этом.

Первый “феномен” - «T-shape person» или «Т-образная личность». Термин, введенный в начале 90-х прошлого века Дэвидом Гэстом (там ещё был математик - полный тёска в начале 20ого века, так вот это не он. Математика грохнул снайпер во время чтения газеты.). Свою популярность термин получил благодаря CEO международной дизайнерской фирмы «IDEO» – Тиму Брауну, который провозгласил «T-shape»-человека одним из ключевых аспектов любой креативной работы. Сейчас идея «T»-личности используется не только применительно к дизайну, но и везде, где речь идет о важности наличия у сотрудника не только специфических знаний и какой-то экспертизы в определенной сфере, но и знаний в кросс-функциональных областях.
А теперь подробнее…
Модель «Т», согласно Гэсту, имеет 2 составляющие.
Первая – это вертикальная линия буквы Т или «глубина», которая говорит об уровне «экспертности» специалиста в конкретной сфере.
Вторая составляющая – горизонтальная линия буквы Т или «ширина», говорит о тех областях, в которых специалист также имеет определенный опыт и знания.
Это кратко, теперь поподробнее в тексте статьи.
https://collegeinfogeek.com/become-t-shaped-person/ - если кратко передать суть статьи, то это а) стать и быть T-shaped это очень круто и полезно. Не надо быть прям Вассерманом во всех вопросах. Достаточно быть крутым в одной теме и иметь широкий кругозор в других темах. (Спасибо, Кэп?) Это тебе поможет тебе легче находить общий язык с коллегами, повысит заинтересованность во многих процессах, добавит креативности и сделает более привлекательным для работодателя. Ну и для тех, кого зацепит - приведёт простой алгоритм, как оценить свои скилы из крышки буквы Т и составить план развития, если их там нет, но есть понимание, что очень хочется. Ну и в конце фирменное Don’t give up!
И второй “феномен” это "Generalizing specialist”. Не взялся переводить, лучше после прочтения сформируете своё определение для этого. Если кратко, то с моей колокольни суть этого термина близка к T-shaped, но не так пафосно звучит:))) Поэтому в литературе и статьях всё-таки больше первого. Если читать внимательно, то можно легко найти пересечения с первым опусом. Здесь также рассмотрены плюсы быть женералайзингом, схемы, как им можно стать и измерить свою женералайзность. Важный момент - в этой статье постоянно идёт отсылка к аджайл-практикам, собственно к тому, с чего начали утром. http://www.agilemodeling.com/essays/generalizingSpecialists.htm - если лень читать, приведу цитату из заключения, которая примерно передаёт суть текста. Robert A. Heinlein said it best: "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

Рассчитывайте на свободное время - эту статью, возможно, придётся читать дважды, кое-где заумно очень.

Ну и поскольку впереди выходные, а ведь не все из вас уже бегут в кабак:), вот вам ещё два неплохих текста на эту тематику.

https://vc.ru/flood/40369-avtonomnost-motiviruyushchaya-cel-masterstvo-zachem-kompaniyam-t-shaped-specialisty-i-kak-ih-razvivat - это небезызвестный Райфайзенбанк рассуждает на тему того, что организациям очень выгодно нанимать этих самых T-shaped.
TechLead Good Reads 9 Nov, 17:59
А вот здесь
https://www.agileconnection.com/article/examining-cross-functionality-bias-software-development-teams речь идёт о том, что кросс-функциональность это хорошо и здорово, если бы не три “Но”: непонимание цели специализации, поклонение герою (круто же, когда восьмикрылый семилап всё делает) и отсутствие в организации желания культивировать культуру кросс-функциональности, т.к. специализация удобна многим, например ичарам (проще искать героев, которым потом будут поклоняться и делать из героя единую точку отказа). С этими “Но” нужно обязательно работать и по максимуму убирать их влияние.


Хороших выходных! Если меня не прогонят из канала, то завтра я подкину лонгрид про технический долг и что-нибудь очень лайтовое на воскресение.
TechLead Good Reads 9 Nov, 11:21
Привет! Четверг сегодня оказался пятницей, с чем я вас и поздравляю.

Кто не любит хайлод слушать и смотреть, тот слегка не прав:)

Как и обещал вчера - поговорим о кросс-функциональности. В лучших традициях ИТ с терминологией в этой части тоже беда. Поэтому я решил посмотреть на эту тему с двух сторон.

Первая сторона - это сторона командная, когда речь идёт о том, что в одной команде собираются разные специалисты и делают что-то клёвое. Поговаривают, что до прихода аджайла таких команд не было, и именно аджайл сделал из разрозненных узкоспециализированных команд что-то более универсальное. Честно - фиг знает, но в моей разработческой молодости моя команда на одном из оборонных предприятий делала софт под ключ, т.е. у нас была лаборатория, в ней были аналитики, тестировщики, разработчики приклада и разработчики системного софта, причём разработчики пилили задок и передок, а тестировщики тыкали мышкой и пилили автотесты одновременно. Т.е. де-факто мы были той самой кросс-функциональной командой больше 10 лет назад. Этакий такой squad по классификации Spotify. Правда мы таких слов тогда не знали, потому как аджайл в моей жизни появился чуть позже благодаря г-ну Дорофееву ещё до того, как он стал известным прокрастинатологом, бо мне посчастливилось с ним поработать в разных конторах аж с 2002 года и до 2012:)))) А Спотифай в мою жизнь проник через Кодефест, а не через наушники. Сразу скажу - материалов на эту тему вагон и сколько контор, начальников и нормальных людей - столько мнений на этот счёт. Я приведу лишь два - от Авито и ЦФТ, т.к. знаю точно, что ребята знатно поковырялись в этой теме.

Итак.

https://www.youtube.com/watch?v=bQth2oo66B8 - кино про кроссфункциональность в одной из команд Авито (я осознанно говорю “в одной из”, потому как точно за всех не знаю). Авито много сил потратило на изменение внутреннего устройства и процессов, так что даже если вы не разделяете их подходы к управлению, ознакомиться с деталями стоит однозначно. Этот доклад хорош тем, что его автор - инженер и тимлид одной из команд, т.е. непосредственный участник разработки, что в моих глазах делает его рассказ более точным и правдивым. Рассказ о том как команда Ивана пришла от монолитных функций к небольшим полнофункциональным командам, зачем это было нужно, с какими проблемами столкнулись и как их решали. И, конечно, вы узнаете, при чем здесь кроссфункциональность и как она помогает достигать лучших результатов как командам, так и самим разработчикам. 35 минут, как раз на обед:)

https://artemanin.blogspot.com/2018/04/crossfunctionalteam.html - Артём представитель ещё одной крупной конторы - ЦФТ и рулит там разработкой веба и мобилки. ЦФТ неоднократно были замечены за очень толковыми рассказами на разные темы (можно погуглить Артёма Каличкина или Ольгу Давыдову). Конкретно в этой статье Артём смотрит на кф-команды с точки зрения плюсов и минусов их организации и функционирования, ну и делает определённые выводы о том, что получилось. Очень структурировано, без лишних букв. Всё, как мы любим. Минут 5-7 займет почитать, т.к. на русском:)

О второй стороне - стороне, когда инженер развивает в себе кроссфункциональность, хорошо это или плохо, кто такие T-люди пришлю почитать ближе к вечеру. Там тоже не всё просто и с терминами, и с определениями, а главное с отсутствием единой точки зрения:)))

Хорошего дня!
TechLead Good Reads 8 Nov, 10:10
Доброе утро, вчера сачканул и не выложил вторую часть материалов по ревью. Был увлечён подготовкой докладчиков. Хайлод, кстати, стартанул и через 10 минут начнутся доклады. Напоминаю о трансляции из главного зала. Сегодня выложу сразу всё, следующая порция знаний будет завтра, поговорим о кросс-функциональности.

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

https://habr.com/company/Voximplant/blog/272469/ - инструкции о том, как делать review чужого кода и пережить review собственного. Статья переведена очень неплохо, но для любителей в начале есть ссылка на оригинал. Если в двух словах, то статья фокусируется на практических аспектах code review и содержит множество толковых рекомендаций, как и что делать, чтобы было легко и полезно.

https://medium.com/palantir/code-review-best-practices-19e02780015f - очень неплохая статья от Palantir Technologies (ребята пилят софт для анализа данных и много сотрудничают с спецслужбами и банками, в 2016 их стартап был 4-ый по капитализации, но по другим данным это был пузырь:))) c кучей полезных ссылок, если хочется погрузиться в тему ещё сильнее. В статье можно поискать ответы на вопросы: почему, зачем и когда делать код ревью? подготовка кода к ревью (а вы всё ещё отдаёте код на ревью просто так?) собственно сам процесс код ревью и примеры его проведения. 12 минут на всё про всё.

И наконец, https://medium.freecodecamp.org/unlearning-toxic-behaviors-in-a-code-review-culture-b7c295452a3c
Даже не смотря на то, что автор девушка-индус (хи-хи, вы же слышали про качество индийского кода), статья достойна внимания хотя бы потому, что это ещё одна точка зрения на этот процесс. Токсичность в поведении некоторых членов команд может очень серьёзно навредить бизнесу, а если речь идёт о ревью кода, когда один официально получает право уничтожать другого, ситуация может обернуться проблемами посильнее, чем Фауст Гёте. В статье один за одним рассматриваются 8 нехороших паттернов и аж 12 хороших. И снова 12 минут. В начале страница не очень интересного текста, не обращайте внимания, мякотка дальше.
TechLead Good Reads 7 Nov, 14:26
Завтра, как я уже писал чуть выше, стартует 12-ый Хайлод++. По доброй традиции трансляция из главного зала будет совершенно бесплатной. О том, как подключиться и что будет транслироваться можно посмотреть вот тут https://habr.com/company/oleg-bunin/blog/428852/. В главный зал попадают доклады, которые слушатели выбрали, как наиболее интересные, ПК лишь выстраивает их в цепочку. Подключайтесь, если не будете присутствовать лично.
TechLead Good Reads 7 Nov, 12:10
Среда - неделе конец.

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

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

Начну с ребят из Баду. Ребята постоянно делятся своими наработками в инженерии, не обошли они и тему ревью. Здесь отмечу, что у них есть ещё performance-review, о котором рассказывал Алексей Рыбак на одном из хайлодов, но это не то ревью:)) Итак.

https://habr.com/company/badoo/blog/354856/ - история становления код-ревью в Баду, как оно появилось, как оно видоизменялось в процессе роста числа разработчиков. Важный момент - рассказ написал Илья Агеев - директор по контролю качества. Т.е. всё, как у взрослых - ревью - часть процесса обеспечения качества продукта.

https://habr.com/company/badoo/blog/413965/ - продолжение первого поста, но теперь взгляд чуть с другой стороны - для чего ещё может применяться код-ревью (а там обучение новичков, свежий взгляд на код, снижение бас-фактора и т.д.). Но секс в том, что это на самом деле совершенно не является основным назначением этого процесса, и часто за этими псевдо-целями теряется то, ради чего это всё затевалось - правильность архитектуры, соблюдение соглашений, корректность решения и тестируемость кода. Собственно ещё одна точка зрения на эту тему от всё того же Ильи Агеева. Кстати, в статье в самом начале есть ссылка на кучу статей по этой тематике, не удивляйтесь, когда увидите, куда она приведёт. Тема реально популярная и востребованная в мировой ИТ-индустрии.

З.Ы. Кстати, если вы до сих пор не подписаны на их бложеки и видосы - рекомендую обязательно это сделать, например, здесь https://tech.badoo.com/ru/
TechLead Good Reads 7 Nov, 09:17
Доброе утро:) Воспользуюсь служебным положением. Мы уже пару недель тихонько ведём подготовку к зимней конференции для тимлидов в Москве. Первые доклады уже поступили в систему, а программный комитет рыщет по просторам интернетов в поисках интересных тем и спикеров. Осенью в Питере нам удалось собрать почти 600 человек, два полных дня, 31 доклад и круглый стол, много общения, пива и хорошего настроения. Судя по отзывам было круто! Средний балл докладов по версии слушателей надежно перевалил за 4.

В общем мы воодушевлены вашим интересом и успехом и планируем в Москве ещё более масштабную тусовку. И может быть даже технические доклады:)) Так что совершенно официально приглашаю вас подавать доклады, закупаться билетами (пока они не подорожали). Вся информация по ссылке http://teamleadconf.ru/moscow/2019. На любые вопросы отвечу в личку @dumtest или в канале Боль Тимлида t.me/TeamLeadTalks. Вливайтесь!

З.ы. это не все на сегодня, не отключайтесь:)
TechLead Good Reads 6 Nov, 18:39
Побеседовал я сегодня с одним из читателей. Он посетовал на то, что в канальчик стали попадать в большом количестве менеджерские очерки, что не добавляет ему интереса у технологической части читателей. Пожалуй, соглашусь. Поэтому ролик про успех оставлю на потом. Тем более там у спикера противный голос, ну точно не для вечера понедельника/вторника. Взамен предлагаю уделить внимание двум достаточно интересным темам - проекты по оптимизации чего-нибудь и работу с дефектами. Это поближе к технологиям и подальше от менеджмента, хоть и всё-равно этого самого менеджмента касаются.

1. https://www.infoq.com/articles/0-bugs-policy - политика разработки с нулём дефектов. Чуваки разрабатывают таким образом, что не оставляют никаких дефектов за собой. Т.е. нашёл дефект - или исправил дефект, или исправил его на следующий спринт (максимум) или запил из дефекта новую фичу и всё в таком ключе. С моей точки зрения провокационная статья, многое в ней - игра слов, да и сам подход идёт сильно в разрез с тем, как работаем мы, например, но это ещё одна точка зрения достойная внимания, как работать с дефектами. Кстати, тема работы с дефектами была освещена в одном из докладов на прошешей тимлидской конференции и вызвала очень бурные обсуждения и критику, что говорит об актуальности тематики.


2. http://www.timecockpit.com/blog/2015/03/29/Eight-Anti-Patterns-for-Optimization-Projects - в этой статье речь идёт об ещё одной сложной задаче - проекты по оптимизации (кода в первую очередь). Уверен, что многие из вас хоть раз да принимались за улучшение, рефакторинг, оптимизацию, тюнинг, ну так далее. На моей памяти не все такие проекты достигали нужного эффекта. На памяти автора судя по всему тоже:). Не смотря на внешнее капитанское повествование, многие сценарии я видел вживую со всеми вытекающими. Так что польза от прочтения будет нанесена гарантированно. Большим плюсом рассказа считаю то, что автор не только перечислил 8 анти-паттернов, но и в заключение предложил 8 (интересно, специально подгонял или нет) шагов, которые надо сделать, чтобы проект по оптимизации не вышел боком.

Приятного прочтения и до завтра!
TechLead Good Reads 6 Nov, 12:45
Привет!

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

Частенько тема тотальной занятости и нехватки времени стала проскакивать, например, в Боли тимлида https://t.me/TeamLeadTalks, трекеры, напоминалки, помидоры и прочие причендалы встали рядом с зубной щёткой и всё ради того, чтобы брать больше и кидать дальше. Вокруг нас в последние несколько лет возник культ продуктивности, эффективности и производительности. Десятки книг, сотни статей от совершенно разных специалистов и не очень специалистов, а иногда тех, кто просто хочет срубить очков на хайпе. Часть из них учит, как работать с огромными потоками входящих задач, часть из них настаивает на том, что нужно открывать в себе уникальные возможности и способности, часть из них предлагает “уникальные” методы улучшения, увеличения и достижения, фокусировки на достижении высот и вот этим всем. В своё время, обчитавшись различной литературы сам пал жертвой “сверхпродуктивности в обмен на потерю здоровья”, после чего крепко задумался и скорректировал свою жизнь. Другими словами, если бездумно брать в оборот все тезисы из книг и статей, то можно достичь совершенно обратного эффекта.

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

Пример того, что было воспринято когда-то с восторгом и не зря, как мне кажется. «Выйди из зоны комфорта. Измени свою жизнь. 21 метод повышения личной эффективности». Книга оказалась полна простых примеров, большая часть из которых сводится к выбору точки приложения усилий, а не бездумной молотьбе задач. Многие тезисы в разных вариантах фигурируют и в других источниках. По ссылке я их выписал, книга, как мне кажется достойна внимания, хотя бы в моём сверхкратком изложении:) https://clck.ru/EfB2V. Время на прочтение минуты три.

На прошлой неделе МИФ выпустил в продажу книгу Катерины Ленгольд “Просто космос. Практикум по Agile-жизни, наполненной смыслом и энергией.”. Автор в 14 лет экстерном закончила школу. В 20 основала стартап — первый в мире маркетплейс спутниковых данных. В 23 года продала его калифорнийской компании Astro Digital, перебралась в Кремниевую долину и стала самым молодым вице-президентом мировой космической индустрии. Наверное, вы подумали: «Она либо гений, либо робот. Или и то, и другое». Но нет. Достижения Катерины — результат умения ставить четкие цели, «нарезать» их на маленькие кусочки, планировать шаги и находить «мотивирующую морковку» — награду для себя за достигнутые результаты. И при этом спать, есть, ходить в кино и жить нормальной жизнью. Достаточно посмотреть на её фотки в ФБ.
Честно, я ещё не успел ознакомиться с книжкой, но про успехи Катерины слышал ещё до этого. Если кто-то прочитает пораньше https://www.mann-ivanov-ferber.ru/books/prosto-kosmos/ - поделитесь впечатлениями пжлста, по идее должно быть очень полезно.

А наконец третий пример. Кстати тоже от женщины, что немаловажно имхо в контексте тематики. Статья "7 Things to Start Being More Productive, Today” https://link.medium.com/dzuQ5FFuCR На секундочку - 113К ладошек и всего 11 минут на прочтение.

Эта статья попалась на глаза пару лет назад и зацепила тем, что автор не предлагает читателю приложить пресловутые сверхусилия, сверхконцентрацию и много других сверхслов. Наоборот, речь в статье идёт о том, что в своё время было описано одной фразой - “Работать надо не 24 часа в сутки, а головой”. Статья на английском, но очень легко читается. Если покопаться в медиуме автора, то можно найти ещё некоторое количество забавных статей на совершенно разные темы.
TechLead Good Reads 6 Nov, 12:45
Приятного прочтения! Поближе к вечеру поговорим про успех. А пока пойду выполнять свои задачи на день ;)