Тем временем, в нашей командной документации появился самый неформальный текст. Раньше мы такого себе не позволяли :)
https://www.tarantool.io/en/doc/latest/contributing/docs/markup/code/#defining-what-code-is
Пока писал пост, увидел ошибку. Пойду исправлять.
https://www.tarantool.io/en/doc/latest/contributing/docs/markup/code/#defining-what-code-is
Пока писал пост, увидел ошибку. Пойду исправлять.
I'd like to review your readme.
Тут человек предлагает ревью readme для опенсорсных проектов. В очереди уже 125 штук, разбирает по несколько в день.
https://liw.fi/readme-review/
Тут человек предлагает ревью readme для опенсорсных проектов. В очереди уже 125 штук, разбирает по несколько в день.
https://liw.fi/readme-review/
Forwarded from Уютный IT адочек
Friendly Asked Questions #2 — про документацию
Я инженер в девопс команде и каждый раз когда дают задачи на незнакомый проект — это боль. Хочу, чтобы команда начала писать документацию, но тимлид пожимает плечами, а техдир начинает открыто троллить и идти на конфликт в ответ на такие разговоры. Как быть?
Ответы дали авторы каналов Уютный Адочек, DocOps и The Know All
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
@the_know_all — Лана Новикова
Документация — один из способов организовать коммуникацию по какому-то каналу. Это решение, а давайте вернемся к проблеме. Зачем документация и какую вашу проблему и проблему бизнеса она решит?
Проблема — неосведомленность сотрудников о том, что делается в другом проекте. Эту проблему может решить не только документация, но и, например, периодические демо, сессии обмена знаниями, shadowing (когда периодически специалисты из одного проекта переключают контекст и работают в паре с коллегами из другого в формате «тени»). Техническому директору это надо «продавать» в его терминах: ускорение разработки, снижение эскалаций, снижение рисков инцидентов.
В тему организации обмена знаниями между отделами есть хороший доклад Марии Палагиной
@docops — Ник Волынкин
Давай тут разделим проблему на три части.
1. Команда не пишет. Стань первым, кто начнёт это делать. Когда будешь в чем-то разбираться — делай заметки. Так у команды будет хороший пример. Постарайся рассказывать команде о том почему и как это делаешь, и замечать, как твоя работа реально будет помогать коллегам.
2. Тимлид не поддерживает идею документирования. Вы, наверное, сейчас теряете время на погружение в задачу и на изобретение велосипедов, теряете мотивацию людей, плохо учитесь на ошибках (и будете их повторять). Всё это напрямую мешает работе тимлида и ставит его задницу под удар начальства. Не предлагай тимлиду писать доки — предлагай ему помощь в его работе.
3. Техдир идёт на конфликт. Лучше приходить к техдиру с тем, что уже работает хоть на небольшом масштабе. И ещё, техдиру нужен запрос, который можно решить только на его уровне. Плохо: "Сделай так чтобы мой тимлид заставил нас писать доки". Хорошо: "Мы начали писать анализ инцидентов, это помогает, давай это распространим на всю компанию".
@lovely_it_hell — Цупко Игорь
Можете ли вы писать документацию самостоятельно, подавая пример коллегам? Если в компании не выделяют время на изменения и инициативы — возможно пора поменять компанию.
Описанные реакции — странные. Троллинг и агрессия руководителя в ответ на инициативу подчинённого — звучит не здорово.
Если я правильно понимаю, вы хотите вдохновить коллег, побудить их к действиям. Попробуйте покидать им хороших примеров (возможно вы просто сейчас более "насмотрены" на хорошую доку, чем они), докладов, пописать короткие посты в чатики команды — но без нажима и требований. Вода камень точит и со временем какие-то идеи осядут в головах.
Я инженер в девопс команде и каждый раз когда дают задачи на незнакомый проект — это боль. Хочу, чтобы команда начала писать документацию, но тимлид пожимает плечами, а техдир начинает открыто троллить и идти на конфликт в ответ на такие разговоры. Как быть?
Ответы дали авторы каналов Уютный Адочек, DocOps и The Know All
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
@the_know_all — Лана Новикова
Документация — один из способов организовать коммуникацию по какому-то каналу. Это решение, а давайте вернемся к проблеме. Зачем документация и какую вашу проблему и проблему бизнеса она решит?
Проблема — неосведомленность сотрудников о том, что делается в другом проекте. Эту проблему может решить не только документация, но и, например, периодические демо, сессии обмена знаниями, shadowing (когда периодически специалисты из одного проекта переключают контекст и работают в паре с коллегами из другого в формате «тени»). Техническому директору это надо «продавать» в его терминах: ускорение разработки, снижение эскалаций, снижение рисков инцидентов.
В тему организации обмена знаниями между отделами есть хороший доклад Марии Палагиной
@docops — Ник Волынкин
Давай тут разделим проблему на три части.
1. Команда не пишет. Стань первым, кто начнёт это делать. Когда будешь в чем-то разбираться — делай заметки. Так у команды будет хороший пример. Постарайся рассказывать команде о том почему и как это делаешь, и замечать, как твоя работа реально будет помогать коллегам.
2. Тимлид не поддерживает идею документирования. Вы, наверное, сейчас теряете время на погружение в задачу и на изобретение велосипедов, теряете мотивацию людей, плохо учитесь на ошибках (и будете их повторять). Всё это напрямую мешает работе тимлида и ставит его задницу под удар начальства. Не предлагай тимлиду писать доки — предлагай ему помощь в его работе.
3. Техдир идёт на конфликт. Лучше приходить к техдиру с тем, что уже работает хоть на небольшом масштабе. И ещё, техдиру нужен запрос, который можно решить только на его уровне. Плохо: "Сделай так чтобы мой тимлид заставил нас писать доки". Хорошо: "Мы начали писать анализ инцидентов, это помогает, давай это распространим на всю компанию".
@lovely_it_hell — Цупко Игорь
Можете ли вы писать документацию самостоятельно, подавая пример коллегам? Если в компании не выделяют время на изменения и инициативы — возможно пора поменять компанию.
Описанные реакции — странные. Троллинг и агрессия руководителя в ответ на инициативу подчинённого — звучит не здорово.
Если я правильно понимаю, вы хотите вдохновить коллег, побудить их к действиям. Попробуйте покидать им хороших примеров (возможно вы просто сейчас более "насмотрены" на хорошую доку, чем они), докладов, пописать короткие посты в чатики команды — но без нажима и требований. Вода камень точит и со временем какие-то идеи осядут в головах.
Поймал себя на интересной штуке.
Когда-то, только начиная работать в айтишечке, я относился к фичам продукта как к конфетам в мешке. Сыпьте разных и побольше!
Потом я поработал тестировщиком и выработал совершенно обратную реакцию. Фича — это ж надо разрабатывать, тестировать, документировать, поддерживать её потом. Выбирая делать эту фичу, мы выбираем не делать какую то другую. Новая фича? Падажжи, а может не надо? Если есть возможность не делать, давай не будем делать.
Ещё у меня раньше похожее отношение было к найму людей. Вот казалось бы, большая команда делает больше работы, а тимлиду почёт и слава, что справляется с такой толпой.
Теперь я совсем немного проработал тимлидом и уже ловлю себя на обратной реакции. Когда говорят о найме, я сразу начинаю думать, а можно ли без этого? Это ж надо искать, онбордить (адаптировать-обучать нового сотрудника), организовывать, развивать и менторить. Делая всё это я выбираю не делать что-то другое. Например, не помогать текущей команде делать больше меньшими усилиями.
Не поймите неправильно. Онбордить и развивать людей мне очень нравится. И фичи делать тоже нравится. Просто раньше я был жадный, а теперь какая-то осторожность появляется. Лучше меньше, да лучше.
Когда-то, только начиная работать в айтишечке, я относился к фичам продукта как к конфетам в мешке. Сыпьте разных и побольше!
Потом я поработал тестировщиком и выработал совершенно обратную реакцию. Фича — это ж надо разрабатывать, тестировать, документировать, поддерживать её потом. Выбирая делать эту фичу, мы выбираем не делать какую то другую. Новая фича? Падажжи, а может не надо? Если есть возможность не делать, давай не будем делать.
Ещё у меня раньше похожее отношение было к найму людей. Вот казалось бы, большая команда делает больше работы, а тимлиду почёт и слава, что справляется с такой толпой.
Теперь я совсем немного проработал тимлидом и уже ловлю себя на обратной реакции. Когда говорят о найме, я сразу начинаю думать, а можно ли без этого? Это ж надо искать, онбордить (адаптировать-обучать нового сотрудника), организовывать, развивать и менторить. Делая всё это я выбираю не делать что-то другое. Например, не помогать текущей команде делать больше меньшими усилиями.
Не поймите неправильно. Онбордить и развивать людей мне очень нравится. И фичи делать тоже нравится. Просто раньше я был жадный, а теперь какая-то осторожность появляется. Лучше меньше, да лучше.
Forwarded from Уютный IT адочек
Friendly Asked Questions #3 — про уровень зарплат
Почему мы платим разные зарплаты сотрудникам на удаленке? У них одинаковые должности и обязанности, но один находится дома в Москве, а другой дома в Саратове.
Ответы дали авторы каналов Уютный Адочек, DocOps, Человек и Машина, Евгений Потапов
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
Евгений Потапов (канал @eapotapov_channel)
Платить на удалёнке разные зарплаты для разных регионов выглядит странной затеей в 2021 году. Такой тренд был давно (и не только в РФ), когда можно было в регионах с более низкими зарплатами нанимать дешёвые кадры, но, имхо, сейчас ситуация уже сильно изменилась и рынок сформирован компаниями, которые платят универсальную зарплату без привязки к региону.
Карен Товмасян (канал @manandthemachine)
Очень хороший вопрос! Тема скользкая и несправедливая, но зарплата чаще всего строится не на базе выполняемой работы, но по средней зарплате по городу/региону.
Поэтому даже приехав из уездного города N, где зарплата была 30к, в Первопрестольную, то ценник сразу обретает нолик с конца, что работает и в обратную сторону. Не вы первый задаетесь этим вопросом, кстати. 😉
Ник Волынкин (канал @docops)
Не вижу хорошего ответа на этот вопрос, работодатель имеет возможность так делать, потому что информация о зарплатах закрыта. Нет принципа общей справедливости, и в итоге всё сводится к тому, как люди сами себя продали.
Однако, может быть дело не в удалёнке, а у сотрудников разные скиллы и полезность.
Цупко Игорь (канал @lovely_it_hell)
Я видел, как люди, которых одинаково оценивают по скиллам, получают з/п отличающуюся в полтора-два раза. Просто за счёт региона, степени наглости самого сотрудника и того, в какой команде он оказался.
Владелец компании не был заинтересован отдавать его деньги. Вслух он говорил, что будет повышать зарплаты и поможет стать людям миллионерами, но реальные поступки говорили красноречивее 🙂
Я думаю, что разные зарплаты платят потому, что могут и потому, что это выгодно. Поступать так или нет — на совести тех, кто распоряжается деньгами.
Почему мы платим разные зарплаты сотрудникам на удаленке? У них одинаковые должности и обязанности, но один находится дома в Москве, а другой дома в Саратове.
Ответы дали авторы каналов Уютный Адочек, DocOps, Человек и Машина, Евгений Потапов
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8
Евгений Потапов (канал @eapotapov_channel)
Платить на удалёнке разные зарплаты для разных регионов выглядит странной затеей в 2021 году. Такой тренд был давно (и не только в РФ), когда можно было в регионах с более низкими зарплатами нанимать дешёвые кадры, но, имхо, сейчас ситуация уже сильно изменилась и рынок сформирован компаниями, которые платят универсальную зарплату без привязки к региону.
Карен Товмасян (канал @manandthemachine)
Очень хороший вопрос! Тема скользкая и несправедливая, но зарплата чаще всего строится не на базе выполняемой работы, но по средней зарплате по городу/региону.
Поэтому даже приехав из уездного города N, где зарплата была 30к, в Первопрестольную, то ценник сразу обретает нолик с конца, что работает и в обратную сторону. Не вы первый задаетесь этим вопросом, кстати. 😉
Ник Волынкин (канал @docops)
Не вижу хорошего ответа на этот вопрос, работодатель имеет возможность так делать, потому что информация о зарплатах закрыта. Нет принципа общей справедливости, и в итоге всё сводится к тому, как люди сами себя продали.
Однако, может быть дело не в удалёнке, а у сотрудников разные скиллы и полезность.
Цупко Игорь (канал @lovely_it_hell)
Я видел, как люди, которых одинаково оценивают по скиллам, получают з/п отличающуюся в полтора-два раза. Просто за счёт региона, степени наглости самого сотрудника и того, в какой команде он оказался.
Владелец компании не был заинтересован отдавать его деньги. Вслух он говорил, что будет повышать зарплаты и поможет стать людям миллионерами, но реальные поступки говорили красноречивее 🙂
Я думаю, что разные зарплаты платят потому, что могут и потому, что это выгодно. Поступать так или нет — на совести тех, кто распоряжается деньгами.
Очередной вопрос ^^^ от @lovely_it_hell — про деньги, а не про управление знаниями. Отетил, как смог. Чтобы ответ был полезнее, вопрос хочется переформулировать, чтобы он был не о всеобщей справедливости, а о зарплате конкретного человека. Вот так: «что мне сделать, чтобы получать больше?»
Получаются два основных ответа:
— Субъективно: поменять работу на компанию в Москве или за границей, научиться лучше договариваться о деньгах. В этом нет всеобщей справедливости, но это может сработать. Однако, ничего советовать тут я не могу, с этим помогают карьерные консультанты.
— Объективно: научиться приносить больше пользы, прокачать для этого хард- и софт-скиллы. Тут можно поговорить о том, какие конкретно навыки помогают писателю быть полезнее и зарабатывать больше.
Получаются два основных ответа:
— Субъективно: поменять работу на компанию в Москве или за границей, научиться лучше договариваться о деньгах. В этом нет всеобщей справедливости, но это может сработать. Однако, ничего советовать тут я не могу, с этим помогают карьерные консультанты.
— Объективно: научиться приносить больше пользы, прокачать для этого хард- и софт-скиллы. Тут можно поговорить о том, какие конкретно навыки помогают писателю быть полезнее и зарабатывать больше.
Отличная иллюстрация когнитивного искажения, называемого «проклятием знания».
https://m.xkcd.com/2501/
https://m.xkcd.com/2501/
xkcd
Average Familiarity
А где можно публиковать статьи на английском? Хотим рассказывать про Тарантул международному сообществу. Накидайте площадок, пожалуйста )
Привет, я сегодня в Питере на TeamLeadConf. Давайте знакомиться, обсуждать доки, управление знаниями и вообще всё что угодно.
Законспектировал доклад Филиппа Дельгядо про то, как процессы могут попахивать, подобно коду. То есть про конкретные признаки того, что в рабочих процессах есть проблемы, которые пора решать.
Самая большая грусть в том, что к некоторым запахам принюхиваешься. Вот так к скраму все привыкли...
https://docops-hq.github.io/conf/teamleadconf/21/process-smell/
Это всё на #SaintTeamLeadConf происходит :)
Самая большая грусть в том, что к некоторым запахам принюхиваешься. Вот так к скраму все привыкли...
https://docops-hq.github.io/conf/teamleadconf/21/process-smell/
Это всё на #SaintTeamLeadConf происходит :)
В докладе Алексея Пименова про визуализацию рабочих процессов внезапно появляется управление знаниями.
Если мы показываем этап работы как процесс накопления знаний от 0 к 100%, то увидим, как на разных этапах доминируют разные активности. Визуализировать на доске нужно не то, как люди передают работу, а как сменяются доминантные активности.
Кажется, у меня уйдет полгода-год на то, чтобы понять всю глубину этой идеи. Хотя бы я теперь об этом знаю. :)
И это все ещё #SaintTeamLeadConf
Если мы показываем этап работы как процесс накопления знаний от 0 к 100%, то увидим, как на разных этапах доминируют разные активности. Визуализировать на доске нужно не то, как люди передают работу, а как сменяются доминантные активности.
Кажется, у меня уйдет полгода-год на то, чтобы понять всю глубину этой идеи. Хотя бы я теперь об этом знаю. :)
И это все ещё #SaintTeamLeadConf
Сегодня на #SaintHighLoad2021, на стенде Tarantool. Приходите знакомиться и общаться!
Только что постил ссылку на проект с документацией по вебу. Спасибо читателям, что напомнили: есть документация Mozilla Developer Network, которая лучше и полнее. https://developer.mozilla.org/en-US/
MDN Web Docs
The MDN Web Docs site provides information about Open Web technologies including HTML, CSS, and APIs for both Web sites and progressive web apps.
В чате «Я шарю» сегодня спрашивали, как лучше начать использовать теги для документов в базе знаний. Сохраню здесь мой ответ. Всё это субъективно и основано на моем опыте использования и модерации StackOverflow, где есть очень четкие правила использования тегов.
1. Тегирование — это живой процесс, вы не сделаете его за один раз и навсегда. Просто начните размечать документы тегами. Смотрите, как люди ими пользуются. Делайте выводы, исправляйте ошибки, добавляйте новые теги, удаляйте ненужные.
2. Отдайте людям возможность добавлять новые теги, удалять ненужные, размечать статьи. Если это будет делать один назначенный менеджер знаний, то результат будет никому не нужен. Чтобы управлять общим процессом, вырабатывайте и доносите людям общие принципы.
3. Категорически не рекомендую сначала заниматься построением полной таксономии/онтологии и картированием знаний. Это очень удобный повод не делать настоящую работу, а вместо неё заниматься бесконечной подготовкой к работе.
4. Не используйте мета-теги: проблема, вопрос, статья, справка, инструкция и тому подобных. Тег описывает тему документа, а не его форму.
5. Не используйте слишком частные теги. Если тег похож на заголовок документа и применим только к нему одному — этот тег идёт в мусорку. Тег должен быть применим хотя бы к 5% документов. (Конкретный уровень вы сами можете установить).
1. Тегирование — это живой процесс, вы не сделаете его за один раз и навсегда. Просто начните размечать документы тегами. Смотрите, как люди ими пользуются. Делайте выводы, исправляйте ошибки, добавляйте новые теги, удаляйте ненужные.
2. Отдайте людям возможность добавлять новые теги, удалять ненужные, размечать статьи. Если это будет делать один назначенный менеджер знаний, то результат будет никому не нужен. Чтобы управлять общим процессом, вырабатывайте и доносите людям общие принципы.
3. Категорически не рекомендую сначала заниматься построением полной таксономии/онтологии и картированием знаний. Это очень удобный повод не делать настоящую работу, а вместо неё заниматься бесконечной подготовкой к работе.
4. Не используйте мета-теги: проблема, вопрос, статья, справка, инструкция и тому подобных. Тег описывает тему документа, а не его форму.
5. Не используйте слишком частные теги. Если тег похож на заголовок документа и применим только к нему одному — этот тег идёт в мусорку. Тег должен быть применим хотя бы к 5% документов. (Конкретный уровень вы сами можете установить).
В чате спрашивают, а бывают ли курсы по DocOps. Курсов нет, но есть кое-что получше, давайте расскажу.
Обычно курс по DocOps ищут в такой ситуации: в компании вообще ещё ничего нет и нужно с нуля сделать хорошо, либо есть что-то другое и нужно переделать и переучить людей. И есть один человек, которому больше всех надо и который будет заниматься DocOps-трансформацией.
Этот человек будет внедрять новый подход в своей компании на всех уровнях: в инструментах, в процессах, в людях и в принципах работы. Такой человек должен разбираться в документации, локализации, основах разработки и девопса, обучении, управлении проектами и людьми. В идеале ещё публично выступать хоть немного.
Исходно никто не умеет сразу вот это всё. И реальность в компаниях на старте очень разная. Поэтому здесь нужен не общий курс, а индивидуальная программа обучения, которая на ходу составляется и меняется под конкретные задачи. В неё войдут разные курсы, книги и практика. А с тем, чтобы собрать всё это вместе, хорошо помогает консультирование и менторство, возможно даже с несколькими менторами по разным направлениям. В этом году я так менторил нескольких человек. Знаю, что у них отличные результаты — ребята, горжусь вами.
Так что ответ такой: задача сложная, поэтому курс не поможет — ищите ментора и составляйте индивидуальный план развития. Найти хорошего ментора можно на сайте GetMentor — это такой некоммерческий проект по поиску менторов, там много ребят из IT. И всегда можно просто взять и написать человеку, у которого вы хотели бы поучиться. Я регулярно так делаю :)
Обычно курс по DocOps ищут в такой ситуации: в компании вообще ещё ничего нет и нужно с нуля сделать хорошо, либо есть что-то другое и нужно переделать и переучить людей. И есть один человек, которому больше всех надо и который будет заниматься DocOps-трансформацией.
Этот человек будет внедрять новый подход в своей компании на всех уровнях: в инструментах, в процессах, в людях и в принципах работы. Такой человек должен разбираться в документации, локализации, основах разработки и девопса, обучении, управлении проектами и людьми. В идеале ещё публично выступать хоть немного.
Исходно никто не умеет сразу вот это всё. И реальность в компаниях на старте очень разная. Поэтому здесь нужен не общий курс, а индивидуальная программа обучения, которая на ходу составляется и меняется под конкретные задачи. В неё войдут разные курсы, книги и практика. А с тем, чтобы собрать всё это вместе, хорошо помогает консультирование и менторство, возможно даже с несколькими менторами по разным направлениям. В этом году я так менторил нескольких человек. Знаю, что у них отличные результаты — ребята, горжусь вами.
Так что ответ такой: задача сложная, поэтому курс не поможет — ищите ментора и составляйте индивидуальный план развития. Найти хорошего ментора можно на сайте GetMentor — это такой некоммерческий проект по поиску менторов, там много ребят из IT. И всегда можно просто взять и написать человеку, у которого вы хотели бы поучиться. Я регулярно так делаю :)
https://getmentor.dev
GetMentor – открытое сообщество IT-наставников
GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе в разговоре 1-на-1.
Читаю книжку про DevOps, там буквально с первых страниц объясняется, зачем всё это. Для бизнеса понятно зачем — чтобы быстро и надёжно разрабатывать и внедрять новые фичи. Кто быстро меняется — лидирует на рынке, кто не может — закрывает бизнес.
Но сразу же после этого там пишут про человеческий смысл DevOps. Он в том, чтобы уйти от рабочей системы, которая навязывает людям чувство беспомощности и бессмысленности их работы, принуждает их к конфликту между разными ролями, заставляет их перерабатывать и постоянно тушить пожары. А прийти к системе, которая построена на сотрудничестве, в которой можно спокойно и комфортно работать, постоянно совершенствуя себя, рабочий процесс и продукт.
Вот этот человеческий смысл меня очень вдохновляет. По моим наблюдениям, когда люди говорят о DevOps, они часто забывают про этот смысл и редуцируют весь подход до инструментов. «Нам нужен девопс, давайте наймем девопс-инженеров и навнедряем кубернетесов». Ага, а ещё давайте купим дрели и чего-нибудь насверлим. Смысл-то не в инструментах.
Но сразу же после этого там пишут про человеческий смысл DevOps. Он в том, чтобы уйти от рабочей системы, которая навязывает людям чувство беспомощности и бессмысленности их работы, принуждает их к конфликту между разными ролями, заставляет их перерабатывать и постоянно тушить пожары. А прийти к системе, которая построена на сотрудничестве, в которой можно спокойно и комфортно работать, постоянно совершенствуя себя, рабочий процесс и продукт.
Вот этот человеческий смысл меня очень вдохновляет. По моим наблюдениям, когда люди говорят о DevOps, они часто забывают про этот смысл и редуцируют весь подход до инструментов. «Нам нужен девопс, давайте наймем девопс-инженеров и навнедряем кубернетесов». Ага, а ещё давайте купим дрели и чего-нибудь насверлим. Смысл-то не в инструментах.
Пора уже рассказать вам всю правду. :)
С января 2022 я перешёл в команду под названием Developer Experience. Мы делаем инструменты для разработки Тарантула: тестовый фреймворк, инфраструктуру и CI/CD, штуки для исследования производительности, сайт и несколько экосистемных сервисов. Наши пользователи — разработчики, которые делают сам Тарантул, приложения на его основе, экосистемные продукты и документацию. Всё это чертовски интересно.
Ещё в прошлом году, когда я стал тимлидом команды документации, у меня появилась куча новых интересных тем, но большинство из них как будто не подходило к тематике этого канала, так что я писал очень мало. Я мог бы совсем забросить этот канал и завести новый, но не буду. Вместо этого буду устранять бессмысленные ограничения.
Теперь канал будет не только про документацию и инструменты для неё. Канал будет про всё, что мне интересно в работе. Наконец-то можно будет писать про управление человеками и разработкой, DevOps, Developer Experience, конференции и что угодно ещё.
Кайф :)
С января 2022 я перешёл в команду под названием Developer Experience. Мы делаем инструменты для разработки Тарантула: тестовый фреймворк, инфраструктуру и CI/CD, штуки для исследования производительности, сайт и несколько экосистемных сервисов. Наши пользователи — разработчики, которые делают сам Тарантул, приложения на его основе, экосистемные продукты и документацию. Всё это чертовски интересно.
Ещё в прошлом году, когда я стал тимлидом команды документации, у меня появилась куча новых интересных тем, но большинство из них как будто не подходило к тематике этого канала, так что я писал очень мало. Я мог бы совсем забросить этот канал и завести новый, но не буду. Вместо этого буду устранять бессмысленные ограничения.
Теперь канал будет не только про документацию и инструменты для неё. Канал будет про всё, что мне интересно в работе. Наконец-то можно будет писать про управление человеками и разработкой, DevOps, Developer Experience, конференции и что угодно ещё.
Кайф :)
Прекрасные ребята из подкаста @newpodcast2 зовут меня сегодня пообщаться в эфире. Начало в 18:00 Мск, трансляция будет на ютубе.
Пока что собираемся обсуждать такие темы:
1. Конференцию KnowledgeConf, которую мы в этом году проводим вместе с TeamLead Conf. Расскажу про свой опыт работы в программном комитете и про доклад, с которым сам буду выступать.
2. Работу в tarantool.io, новую команду Developer Experience, прежнюю команду документации.
3. Можем в целом обсудить мою странную карьеру, путь из разработки в документацию и обратно.
Задавайте вопросы здесь, постараюсь на них ответить :)
Пока что собираемся обсуждать такие темы:
1. Конференцию KnowledgeConf, которую мы в этом году проводим вместе с TeamLead Conf. Расскажу про свой опыт работы в программном комитете и про доклад, с которым сам буду выступать.
2. Работу в tarantool.io, новую команду Developer Experience, прежнюю команду документации.
3. Можем в целом обсудить мою странную карьеру, путь из разработки в документацию и обратно.
Задавайте вопросы здесь, постараюсь на них ответить :)
YouTube
Выпуск 62. Ник Волынкин и передача знаний
Сегодня у нас в гостях Ник Волынкин, с которым мы говорим про
- Knowledge Conf
- Обмен знаниями
- Проблемы обмена знаниями, о которых можно говорить вечно
- Классическую менеджериальную литературу
- И многое другое
- Knowledge Conf
- Обмен знаниями
- Проблемы обмена знаниями, о которых можно говорить вечно
- Классическую менеджериальную литературу
- И многое другое
Моя бывшая коллега Катя Говердовская написала хорошую статью про тексты в интерфейсах:
https://habr.com/ru/company/plesk/blog/650779/
https://habr.com/ru/company/plesk/blog/650779/
Хабр
UX-текст на языке Шекспира: заповеди, грехи и табу
Изменив одно местоимение , можно на 90% увеличить показатель кликабельности ( CTR ) кнопки, которая приведет новых пользователей. Дописав одно предложение , можно увеличить количество оплаченных...