👩‍💻 Часть 2 про выгорание — «Семейный день»

⬆️В прошлом посте я рассказал про такое опасное состояние в работе, как выгорание, и два действенных способа, как не довести себя до такого состояния.

Один из таких способов — правильно отдыхать и уметь переключаться.

Мы с женой придумали — «Семейный день». Один раз в неделю (у нас это воскресенье) мы полностью отключаемся от работы. Не переносим никаких рабочих задач на этот день, даже 30-ти минутных. С утра берём дочку и едем отдыхать.

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

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

✔️Мы ввели такую практику буквально в этом году и уже восхищены результатом. Раньше, жена могла перенести на воскресенье занятие с учеником (преподает английский у подростков) и нам приходилось подстраиваться под это. В таких случаях максимум мы могли выйти погулять по району. Но это совсем не то. Я тоже мог взять работу часа на 2 в выходной день. В итоге, в понедельник ощущение как будто работаешь без выходных. Пара-тройка месяцев в таком режиме и вот вам первая стадия выгорания.

После того как стали раз в неделю полностью переключаться, настрой на рабочую неделю стал всегда позитивным и появилось больше энергии. Вечером в воскресенье нет мысли: «блииин, завтра на работу...». Вместо этого наоборот — «Ура! Завтра на работу!» 👍

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

А вы берете работу на выходные? Какими способами пользуетесь, чтобы переключиться и набраться сил перед новой рабочей неделей? 💬👇

❗️Почему я не пошел в DevOps.
Часть 1. Кто такие инженеры DevOps, и почему это направление такое популярное.

Когда я, ещё пару лет назад, заходил на hh и вбивал фильтр по ЗП в IT направлениях, то одними из самых оплачиваемых вакансий выскакивали «DevOps-инженеры». Уровень гонорара — до 450 тысяч рублей! 💲

Увидев такие цифры, появлялось чувство досады — как это, кто-то безо всякого бизнеса зарабатывает такие деньги ‼️

✅Конечно же, первым делом я загорелся идеей стать DevOps. Но нужно было сначала подробнее разобраться с этим направлением:
➖какие задачи выполняют,
➖что нужно изучать, чтобы претендовать хотя бы на джуна,
➖и есть ли у меня шансы.

Я изучил талмуды информации в интернете, просмотрел десяток интервью с девопсами и даже пообщался с коллегами, кто выполняет функции девопс и считает себя таковыми.

Если очень коротко, то DevOps — это специалист техподдержки разработчиков и бэкенда системы.

Если подробнее, то DevOps:
➡️настраивает среду для разработки системы (поднимает виртуальные машины, настраивает необходимые компоненты и инструменты);
➡️настраивает мониторинг среды разработки и реагирует на инциденты (то есть, если что-то не так, мониторинг подает сигнал, и DevOps разбирается в чем дело и чинит);
➡️автоматизирует процессы разработки (выкатка фич на продуктивную или тестовую среду в автоматическом режиме).

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

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

👩‍💻 Раньше эти задачи выполняли разработчики, в маленьких компаниях они и сейчас этим занимаются. Но это отнимает половину рабочего времени разработчика, следовательно замедляет срок выпуска новой программы или доработки.

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

💌 Письма счастья

А вы когда-нибудь получали сообщения, где просят переслать 10, 20 или 50 своим знакомым, и тогда, в конце недели, сбудется ваша самая заветная мечта?

Уверен, что получали 😁 А рассылали ли вы их по всем друзьям и знакомым? Пусть это останется вашей маленькой тайной 🤫

🖇️ Сегодня хочу рассказать про «Письма счастья», которые приняты в крупных IT-компаниях.

В конце года от руководителя приходит письмо, где он просит в ответ написать отчет о проделанной работе и целях на будущий год.

Состав отчета примерно такого содержания:
1️⃣Задачи, которые удалось выполнить. Что получилось хорошо, а что не очень. Доволен ли своей работой. Понравились ли задачи.
2️⃣Мои цели. Что я хотел бы сделать, чтобы не повторять допущенных ошибок. Может быть нужно, что-то дополнительно изучить или перепланировать время.
3️⃣Я. Это пункт про личностный рост. В чем уже прокачались, а в чем только хотите прокачаться. Здесь могут быть планы по развитию любых навыков, не только профессиональных. Например, пройти курсы ораторского мастерства или вступить в беговой клуб в компании.
4️⃣Мое место в компании. Удовлетворен ли я коллективом. Уверен ли в своей пользе, которую приношу компании. Нужно просто рассказать свои ощущения. Вдруг у кого-то развивается синдром самозванца. Тогда руководитель подумает, как это решить.
5️⃣Финансы. Думаю, это самый понятный пункт )))

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

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

Когда-нибудь составляли подобный отчет? Считаете это полезным или наоборот пустой тратой времени? Поделитесь мнением в комментариях ⬇️

❓Почему я не пошел в DevOps? Часть 2. Обязательные навыки.

В первой части я рассказал, кто такие инженеры DevOps, и чем они занимаются. Вот этот пост, кто ещё не читал.

Сегодня расскажу, какими навыками нужно обладать, чтобы претендовать хотя бы на начальную (junior) позицию. А в третьей части поделюсь своими причинами, почему несмотря на высокую зарплату девопса и возможность им стать, я отказался от этого направления.

1️⃣Так как девопсы работают с серверной частью (бэкендом) системы, то обязательным навыком является знание сетей — стек TCP/IP и как все работает по модели OSI.

Без этих знаний вы не сможете настроить ни сервер, ни инструменты, ни мониторинг. Следовательно и собеседование не пройдете.

2️⃣Необходимо понимать, как строится микросервисная архитектура.

3️⃣Уметь работать с системой контроля версий GitHub и его платными аналогами.

4️⃣Знать инструменты мониторинга серверных систем. Например, Zabbix, Cacti, Prometheus, Grafana.

5️⃣Уметь писать несложные Bash скрипты.

7️⃣Хорошо знать Linux и уметь его администрировать (RedHat, РедОС, Centos, Solaris, Ubuntu).

8️⃣Быть знакомым с инструментами систем автосборки (Jenkins).

9️⃣Уметь работать с Docker Compose, K8S, Ansible.

1️⃣0️⃣Уметь администрировать базы данных.

1️⃣1️⃣Понимать, как работают и настраиваются CI/CD-процессы.

1️⃣2️⃣Уметь работать с веб-серверами Nginx, Apache, IIS.

1️⃣3️⃣Уметь разбираться в логах систем, быстро реагировать на инциденты, находить и устранять причину проблемы.

Нехилый такой список для позиции Junior 🤓 Это еще не все, а только основное. В зависимости от стека компании могут добавляться еще знания некоторых технологий.

Но на самом деле не все так страшно. При желании всему этому можно научиться за месяц👨‍💻 При условии, что вы уже 1-2 года работаете в IT, например, специалистом техподдержки или тестировщиком.

Следующим постом расскажу, почему у меня были все возможности пойти на девопса, и почему я этого не сделал 🤷🏼‍♂️

9️⃣ правил технического русского языка

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

Вокруг таблички есть поля темы Windows 10. Это потому что я размещал картинку у себя на рабочий стол. И чтобы текст не расплылся, увеличил картинку, добавив полей.

Держал таблицу с правилами на рабочем столе почти 6 месяцев и каждый раз повторял при включении компьютера. Сейчас, когда пишу текст, правила всплывают в голове уже на автомате 😎

Как изучать инструменты технического писателя нативно и без затрат личного времени? Один из простых способов — писать свои заметки в Markdown.

Недавно я начал использовать для заметок программу Obsidian. Раньше пользовался только Notepad++ — это по сути обычный текстовик с кучей программистских возможностей и подсветкой синтаксиса разных языков программирования. Но недавно осознал, что для технического писателя это не совсем удачный инструмент.

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

Недавно написал годовой отчет тимлиду в Markdown и сконвертил его в PDF-документ. Получилось интересно. Красиво структурировал текст со списками, заголовками, форматированием текста и даже добавил смайлики 👍

Думаю для новичков Obsidian идеальный вариант, чтобы начать осваивать Markdown разметку. Планирую дальше изучать этот инструмент:
⏺️подключить Git для хранения файлов заметок в едином хранилище;
⏺️попрактиковаться с шаблонами;
⏺️создать свою домашнюю базу знаний;
⏺️настроить Sphinx для сборки документов в PDF;
⏺️написать небольшой документ.

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

👩‍💻 Когда редактор прислал новые замечания

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

На днях получил обратную связь, а вместе с этим и ворох замечаний 🥳 Решил поделиться одним из примеров:

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

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

Замечания редактора приведены на скриншоте. Ответьте на вопрос ниже ⬇️

Пора дать свой ответ

В комментариях опроса (смотрите перыдущий пост) мне подсказали, что нужно было дать ещё один вариант «Да, частично согласен». Благодарю за обратную связь, исправлюсь 💡

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

После того, как клиент подписал документ, его статус изменяется в системе ЭДО. Далее оператор выгружает из системы ЭДО подписанный клиентом экземпляр документа. Если есть замечания, то оператор исправляет документ и отправляет корректировку или генерирует новый документ.

☀️ Синоптики рассказали, когда приморцы передохнут от жары

Статью с таким заголовком как-то раз опубликовали в СМИ. Как видим, здесь явно прослеживается двусмысленность: приморцы передОхнут или все таки передохнУт от жары? 🤔

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

Основной способ, как не попадаться на такую ошибку — регулярно пополнять свой словарный запас технического русского языка. Как мы это делаем у себя в компании:
⚪️Читаем документы коллег. Те документы, которые прошли все этапы ревью и правок и были отгружены заказчику.
⚪️Сдаем на ревью свои документы редактору. Затем прорабатываем правки. Но не так, чтобы просто исправить по рекомендациям редактора, а вникаем, почему лучше написать именно так.
⚪️Ведем свою базу знаний в Confluence, где вписываем в таблицу «как надо» и «как не надо».

Что могу посоветовать, если вы новичок и у вас нет редактора:
😍Ищите более опытных коллег и просите провести ревью ваших текстов.
😍Проверяйте по толковому словарю слова, в которых сомневаетесь.
😍Просто больше пишите. Можно не только документы, но и статьи. Тот же vc.ru или Хабр.
😍Читайте свои тексты вслух!