Интереснейшая дискуссия о проблемах ведения доки к проектам
https://twitter.com/rothgar/status/1151730253082980353?s=19

🕔 Тайм менеджмента и обучения людей пост

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

На днях супруга составила список дел, и я, конечно же, нашёл к чему прикопаться. К примеру, в одном списке вперемешку оказались "маленькие" дела, которые делаются 10 минут и "большие" - на несколько часов — мне это усложняет ранжирование и заставляет лишний раз задумываться, за какую задачу взяться, когда появилось время.
Или, к примеру, задачи где всё зависит только от тебя (помыть посуду) в перемешку с задачами, где результат зависит в значительной мере не от тебя (получить результаты анализов в больнице). Тратить внимание на второе во время каждого прочтения списка - такое себе занятие, скорее для этих задач должна быть определена дата, когда эта задача сама напомнит о себе.
Задачи, с которыми всё понятно что делать (повесить шторку), даже если это коплексная задача, подразумевающая необходимость нескольких шагов (в приведённом примере - купить крючки в магазине у дома и только потом уже вешать шторку), я привык отделять от задач, где нужно задуматься и разобраться (починить принтер - фиг его знает, что там вообще сломалось и сколько времени на это уйдёт).

В общем - много к чему нашёл придраться. Хорошо, что хватило тактичности, не лезть со своим уставом — ушёл думать, как бы просто и наглядно объяснить свои мысли.
Прошёл буквально день, мне снова попался на глаза список дел супруги (тот самый, который "неправильно составленный" 😁) - а добрая половина дел в нём уже сделана. И "комплексные", и "непонятные", и даже "большие".

Мне кажется, что мерилом "правильности" подхода в любом случае является результат. А значит пытаться запихать в людей теорию, не разобравшись, а есть ли проблема и в чём именно она - такое себе занятие. Любите и тайм-менеджмент, и людей.

🐶 Pet project-ов пост

У многих айтишников есть pet project-ы. Бесплатные или коммерческие, втиснутые в рамки работы или забирающие время от личной жизни (или заменяющие её :trollface.jpg:). Pet project-ы помогают развиваться, учиться хорошему, и в конце-концов, это просто круто! Даже если проект не получается закончить — это всё равно опыт.

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

Поэтому мы с друзьями решили постить идеи в канальчик:
https://t.me/pet_project_ideas
Не всё там будет одинаково полезно или продуманно, но быть может кого-то он вдохновит на потратить лишний вечер (или месяц) в творческом потоке. И это будет хорошо.

Добрый человек начал писать статьи о том, почему современный JavaScript и фронтэнд разработка устроены так, как они есть
https://habr.com/ru/post/463503/
Я, как человек выпавший из фронтэнда где-то в районе JQuery и Bulletproof-вёрстки, всё время недоумеваю, ибо всё изменилось как-то слишком стремительно. Если у вас тоже это болит - потратьте 3 минуты на классную статью и следите за продолжениями.

Финансовой безопасности пост

Я уверен, что у большинства читателей всё будет ок, но пока наши исполнительные органы власти не могут справиться с проблемой - давайте попробуем хотя бы ещё раз оповестить близких.
Телефонные мошенники. Звонят, представляются сотрудниками банков, говорят про подозрительные операции. Пытаются выудить хоть какую-то информацию из вас.
Обратите внимание, что:
- Они могут подделать номер, с которого якобы звонят. У вас реально может высветится номер банка.
- Фоновые звуки и голос. Хорошо слышный голос оператора с "классическими" фоновыми звуками колл-центра.
- Вам могут начать рассказывать информацию, которую может знать только банк. Привет, утечкам данных, которые отрицаются пресс-службами банков!
- Мошенники блефуют до конца. Они скажут вам "Вы можете перезвонить на официальный номер", они готовы к шуточкам и попыткам проверить их на вшивость в диалоге. Сценарии, по которым они вас обрабатывают, постоянно улучшаются.

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

—

Лично у меня один раз в жизни была ситуация, когда реально звонил банковский сотрудник. Он не выуживал никакую информацию, кодов и номеров карт. Сотрудик банка может только проинформировать, что вам нужно самостоятельно им позвонить на официальный номер и решить какой-то вопрос. Ему должно быть запрещено вас спрашивать о чём-то.
Правильный разговор выглядит так: "Здравствуйте, я сотрудник %bankname%. По вашей карте подозрительная активность, мы заблокировали карту, перезвоните нам по номеру на нашем сайте и решите вопрос самостоятельно. Я этого сделать не могу. Спасибо и всего доброго."

Удалённой работы пост

Коллега написал большую статью про удалённую работу. Ну и я немного приложил свою руку к этому :)
Постарались сделать максимально полный практический гайд по переходу на удалённую работу, рассмотреть и вопросы общения с близкими, и организации места, и гиподинамии - как со стороны проблем, так и со стороны решений.
https://habr.com/ru/company/flant/blog/463619/
В составлении материала участвовал почти весь коллектив компании со своими практическими кейсами и жизненными историями.

злого умысла пост

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

Вот, например, Леонид. Тварь такая, сегодня прислал мне вообще не то, о чем я его просил. А ведь мы проговаривали несколько раз, к чему нужно прийти. Вечно он тупит и косячит, аж бесит! Уволить этого идиота мало!

Но всё оказалось куда проще. Леонид пока занимался задачей выяснил подробности, о которых я был не в курсе. И учёл и их, и мою изначальную цель. И всё отлично сделал, на самом деле. Да и вот это про "прошлые разы", если лезть в детали, надумано - не было никаких "прошлых разов", там были похожие ситуации, о которых я не знал.
Но почему мой мозг меня и себя так обманывает? Поведись я на эти провокации - начну сам провоцировать больше конфликтов и поводов верить в злой умысел Леонида. Этакий замкнутый круг получается.

Я видел организации, которые не могут выйти из этого замкнутого круга. И люди, считающие себя "избранными" в них, считая, что их окружают враги и идиоты, начинают создавать средства защиты, инструменты контроля и давления на окружающих. Вводить больше отчётности, разрешения и разрешения разрешений, ревью на ревью and so on - надо же защищаться от врагов!  "Хочешь мира - готовься к войне" - и всё такое.

В итоге весь пар там уходит в свисток, как в том анекдоте про паровоз, который никуда не мог поехать.

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

Года три назад я считал, кто лучшая инвестиция - это учёба. У меня был в жизни опыт, когда я смог круто изменить свою жизнь подобным образом.
Но со временем я обнаружил, что не все подходят к обучению таким же способом: некоторые считают, что можно сначала обучиться на полугодовых курсах, а потом искать работу, где ты будешь использовать полученные навыки.
Разумеется, это ошибочная стратегия. Учиться надо тому, чем ты уже начал заниматься, чтобы к моменту обучения у тебя уже были вопросы к учителям и очень мощная мотивация выбраться из тех проблем, в которые ты окунулся. Важно сформировать для себя условия, чтобы тебе было нужно учиться, чтобы ты знал, чему учишься и чтобы ты, фактически, уже учился (только методом набивания шишек).

И в этом смысле мне очень нравится то, что пишет (https://www.facebook.com/tokovinin/posts/2567466373274057) Михаил Токовинин про инвестицию в улучшение среды: кажется, это именно тот триггер, который может запустить механизм обучения и улучшения. Процитирую его сообщение из ФБ:

Лучшая инвестиция - это улучшение среды.

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

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

Если вы можете улучшить круг своего общения, среду обитания - это лучшая инвестиция.

Поиска тайных знаний о проектах пост

В IT компаниях зачастую используется куча инструментов: трекеры задач, мессенджеры, системы документооборота и многое другое. И, казалось бы, во всех них идет работа, везде что-то фиксируется. Но как только возникают вопросы вида: что это за фича, зачем это сделано?, кто работал над этим? - найти ответы может быть чудовищно трудно.
При этом самое смешное заключается в том, что информация зачастую есть в компании. Только мало кто знает - где именно. Управленцы работают в одних системах, разработчики каждой команды - в других (иногда даже каждая в своей), дизайнеры - в третьих — и обмена знаниями между ними почти не происходит.

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

23 и 24 сентября я буду на конференции Saint TeamLead Conf в Питере. Проведу там митап Поиски тайных знаний о проектах. Постараюсь по итогам выложить заметки в этом канале, но это не точно - обычно оформить разрозненные мысли сложнее всего :) Будете проходить мимо конференции - заглядывайте на огонёк.

московских митапов пост

Чуть больше чем через неделю в гостях у SkyEng хочу поговорить об управлении знаниями. Про то, как начать, если вы уже что-то попробовали, но ничего не получилось. Про то, что делать, если у вас Confluence, GitLab, Slack и/или ещё пачка других систем, вы пробовали добиваться от людей фиксации знаний, но ничего не получилось. С чего начать? Как продолжить? Что может помочь в этом нелёгком пути?
Участие бесплатное, запись обязательна:
https://rostova-events.timepad.ru/event/1069816/

Удалённой работы пост

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

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

Оформили доклад об этих проблемах и возможных решениях в виде статьи и хорошо смонтированной видеозаписи:
https://habr.com/ru/company/flant/blog/469453/

На конференции Saint TeamLeadConf удалось пообщаться об управлении знаниями.
Больше всего этой тематикой интересовались тимлиды, руководящие небольшой командой от 5 до 10 человек, в более крупной компании (до 50 человек). Они пробовали что-то документировать, вести вики, но их никто не поддержал. А больше всего их беспокоит невозможность быстро вводить новых сотрудников в курс дела и bus-factor при распределении задач. Если же говорить о платформах, чаще всего люди работают с Gitlab, Google Docs и Jira+Confluence (даже те, кто используют Atlassian стек зачастую предпочитают GitLab 😄 ).

Одним из самых занятных вопросов, который мне задали был: "У нас есть продукт с огромным количеством легаси, разрабатывающийся уже более 5 лет. Никто не знает, почему в продукте сделано то или иное, а что гораздо важее - почему что-то не сделано. Как нам это узнать?". Этот вопрос прекрасен тем, что он противоречит сам себе и здравому смыслу: ничто не поможет вам вспомнить то, чего вы не знаете.
Тем, кто попал в подобную ситуацию можно пожелать сфокусироваться не на упущенном прошлом, но на будущем: что сделать сейчас, чтобы ещё через 5 лет вы так же не страдали о решениях, которые делаются сейчас. Какие организационные решения принять сейчас, чтобы через N месяцев не было bus factor-а при распределении задач, как наиболее простым способом попросить разработчиков оставить чуть больше информации о задачах в гите и трекерах. Это действия кажутся незначительными, но именно они ведут к великой цели.

Тут идёт голосование для вручения премии Highload++ 2019.
Предполагается, что премией должны быть награждены люди, которые оказали значительное позитивное влияние на отрасль в целом, продвинули её вперёд к добру, свету и позитиву. Голосование вот тут: http://www.highload.ru/moscow/2019/award (красная кнопка "Проголосовать" справа)

И не то, чтобы я призывал голосовать за какого-то кандидата, но именно это я сейчас и попробую сделать 🙂
Мне кажется, человек, который очень достоин премии, но может быть позабыт - это Филлип Кулин, автор https://usher2.club/ и неугомонный борец с безумием в органах власти. Роскомнадзор и попытки управлять интернетом никуда не денутся, некомпетентность управленцев - останется, и мне кажется, что без работы таких людей как Фил (а он не только делает сервисы, публично вскрывает абсурд и косяки в работе гос. органов, но и пытается общаться с госами на их языке, чтобы ну хоть как-то повлиять на ситуацию), в нашей действительности - никак.
Фил достоин, голосуйте, пожалуйста, за Фила.

Митапа в SkyEng пост

На митапе была достаточно неожиданная для меня аудитория. Весьма разношёрстная, но больше всего было разработчиков и тимлидов.

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

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

На самом деле при наличии хорошего лидера в команде, нет ничего проще, чем заставить разработчиков вести папочку с документацией в проекте. И чисто теоретически этот опыт можно даже масштабировать и использовать для внедрения в уже существующей компании. Но является ли это решением исходной проблемы шаринга знаний?
На самом деле, не совсем: наличие доки не говорит о том, что дока понятна, полна и актуальна. Кроме того, есть гипотеза, что документирование, внедрённое подобной жёсткой рукой, уводит людей от фокуса на эффективных, out of the box решениях. И, самое главное, если для компании стоит вопрос о том, чтобы выжить - не факт, что дока является для неё ключевым вопросом (хотя есть бизнесы, для которых - факт, но глупо апроксимировать бездумно).

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

Пятницы пост 🙂

Перевели тут вдохновившую меня статью про оформление коммитов в Git:
https://habr.com/ru/company/flant/blog/472278/

Определения термина "легаси" пост

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

Самым популярным невысказанным было: "легаси - это когда жуткий монолит". Оооочень спорное утверждение, на мой взгляд, как бы подразумевающий, что всё надо переписать на микросервисы. Однако, практический опыт (https://www.youtube.com/watch?v=g9cgppj0gKQ) говорит, что микросервисы легко превращаются в сильносвязанную кучу грязи, чудовищно сложную в доработке. Страдающим от монолита скорее стоит учиться кодить монолит.

А ещё было: "легаси - это то, у которого бас-фактор маленький". Прекрасное определение, но беда в том, чтобы этот самый бас-фактор померить. Практика подсказывает: легаси на то и легаси, что фиг разберёшься что в проекте, зачем и как реализовано. Нельзя измерить то, не знаю что.

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

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

Самое же прекрасное определение, которое было дано, меня бесконечно вдохновило:
У каждого разрабатываемого проекта есть запас гибкости. Легаси - это проект, в котором запас гибкости исчерпан.

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

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

Легаси-боли пост

А что болит-то, когда мы сталкиваемся с легаси?

Болит то, что когда ты вносишь правки - неизвестно где отвалится. К слову, мне неизвестно, существуют ли легаси-проекты с хорошим покрытием автотестами. Интуитивно это не очень очевидно.

Болит, что в проекте обычно есть какие-то специальные "галочки", сделанные неизвестно для кого и для чего. А иногда - сделанные ради удовлетворения какого-то одного человека со странными, непонятными запросами. И хочется эти "галочки" со связанной с ними логикой выпилить, но представитель заказачика исчез с радаров, и никто не может решить что делать с его требованиями. А бывает ещё хуже: особый представитель заказчика никуда не делся, но ушёл на повышение и, хотя формально присутствует, фактически к нему уже не пробиться.

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

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

И, разумеется, проблемой становится отладка. Какие куски приложения с чем связаны, куда ходят - и в современных кластерах на Kubernetes выявить зависимости является нетривиальной задачей, а уж на устаревшем стеке технологий - и подавно.
Однако, мне всё-таки кажется, что зачастую страдающие от "невозможной отладки" просто недостаточно компетентны в инструментах отладки.
Возможно это хорошая ниша для создания обучающих курсов / докладов / статей: "инструменты отладки для адового легаси".

Ну и, конечно, болят философские вопросы в стиле:
- За что мне это?
- Когда всё это кончится?
- Если руководитель скинул на меня этот проект - он меня хочет уволить или наоборот считает, что я крутой?

Если у вас отзывается что-то из написанного выше - мужайтесь и знайте: вы не одиноки. Возможно у вас получится изменить ситуацию или своё отношение к ней. Главное - оставайтесь крутым профессионалом и хорошим человеком.

хранения паролей пост

Свои более чем 500 паролей я храню в KeePass. Он имеет множество реализаций на все платформы (удивительно, но MacPass оказался лучше всего, плюс умеет мерджить два файла) и в общем-то закрывает стандартный набор проблем (шифрование хранилища, напоминания о необходимости сменить пароли, широкие возможности по сортировке и управлению).

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

Варианты были разные, в итоге я сформулировал мини-тз (https://t.me/pet_project_ideas/9) на специальную железку, которая бы решила проблему. Очень хотелось одновременную работу с несколькими устройствами и кросплатформенность. Я перебрал кучу решений, пытался состыковать и так и так по-быстрому, чтобы не тратить месяц на написание низкоуровнего кода - без толку. Готовых кубиков нет.

А потом я наткнулся на https://www.sparkleshare.org/ и подумал: а зачем я так усложняю? Ведь для меня главное - это не продолбать ни одно изменение, а вовсе не "одновременная работа". Git для этого идеален! Штука простая как топор, вроде как даже не сложно пишется самостоятельно.

В общем, рекомендую попробовать. Учтите только, что SparkleShare не умеет использовать ssh-ключи из системы и генерирует свой, который надо вытащить и закинуть в свой гит.

Переговоров с руководством про легаси пост

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

Ответ, как правило, шаблонный: давай посчитаем окупаемость твоих правок. Мол, сколько денег уйдёт на переписывание, и какой профит мы от этого получим.

Это офигенный ответ по нескольким причинам:

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

И ещё - сюрприз! - беда может быть в чём-то фундаментальном. И приходят не за тем, чтобы бизнес с барского плеча разрешил "пару часов в неделю потратить", а за чем-то серьёзным. Либо за неделей-другой, либо за серьёзной инвестицией хороших out of the box мозгов, которых разработчику не хватает.

Бизнес легко задавливает позицию разработчиков с своей доминирующей позиции. А разработчики голосуют ногами, увольняясь, либо применяют совсем коварное враньё и манипуляции. И то и другое - деструктивные шаблоны.

Чуть менее деструктивны "программисты со сломанным духом", которые остаются в легаси жить навсегда, руководствуясь тем, что их и тут неплохо кормят. Не осуждаю, но сочувствую.


Мне кажется, что есть только один путь победы над легаси - это путь самурая. Делай то, что должно и будь, что будет. Учись на ошибках, верь в себя и коллег на всех уровнях.
Не конструктивно играть в жертву обстоятельств в ключе "я просто получаю от этого проекта деньги" или "моё дело маленькое - закрывать тикеты". Это ваша жизнь, и она всегда содержит и некоторую долю легаси, и некоторое пространство для манёвра. И у вас всегда есть возможность задавать конструктивные и прямые вопросы о проблемах.