Похоже что для выхода с удаленки понадобится еще год как минимум)
Давить опасно, сотрудники могут уйти к другим, кто предложит full remote. Сложна.

Apple employees rally against office working plan - BBC News
https://www.bbc.com/news/technology-57385999

https://status.fastly.com/

38 минут ушло чтобы починить глобальный CDN сбой на Fastly

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

https://blog.pragmaticengineer.com/uber-app-rewrite-yolo/

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

Software development is full of confident forecasters. We are a pretty new field, and yet everyone seems so sure that they have the best solution to whatever problem is at hand. I’d like to hear more people saying things like, “in this specific context, test-coverage seem like an important metric,” or “StopLang is great if you can afford the GC, but if you can’t, then you should look at IronOre.” A great tool is not a universal tool it’s a tool well suited to a specific problem.

The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them. The more specific and contingent the advice - the more someone says ‘it depends’ or ‘YourSQL works well in a read-heavy context with the following constraints’ the more likely they are to be leading you in the right direction. At least that’s what I have found.

https://earthly.dev/blog/thought-leaders/

Внезапно стало интересно а какие компании предоставляют sabbatical. Это такой оплачиваемый (полностью или частично) отдых, который обычно не входит в стандартное количество дней "по закону" и предоставляется работникам которые проработали значительное количество лет. Обычно от месяца и больше.

Вот что нашел, в топе Adobe, Intel, PayPal, остальные уже мало известные.
На примере Adobe - перечисленных за 5 лет работы вы получаете 4 оплачиваемых недели (20 рабочих дней).

https://www.glassdoor.com/blog/42136-2/

А вот список из Fortune (по состоянию на 2018 год): VmWare, FedEx
https://fortune.com/best-companies/2018/search/?sabbaticals=true

Ну и еще одна ссылка на исследование, судя по нему у Sabbatical больше американские корни и популярность его там выше.

A multinational study has revealed that Americans are the
most in need of an extended break, such as a sabbatical, with over half (52%) admitting that a ‘planned strategic work pause’ would improve their mental health. Americans rated much higher than all of the 12,0000 respondents in the eight countries surveyed (European average 39%)

https://www.edreamsodigeo.com/wp-content/uploads/sites/19/2017/09/Sabbaticals-U.S.-14SEP17.pdf

Cheat sheet: 10 Java security best practices

"А давайте сделаем сервис на 100% доступным". Хороший пост рассказывающий чего вам это будет стоит. Авторы говорят о 10x increase in development costs(!)
Спойлер, определите уровень который нужен вам, вряд-ли это именно 100%, каждая 9 после 99% стоит оочень много.

"Say a feature is estimated to take 20 days of development (including design). Add a further 10 days for testing (using the top end industry estimate of one-third time), and you have a total of 30 days cost for the good reliability feature. For the 100% reliability feature, we need much more testing, around 200 days using Colm’s talk. That means a total of 30 days for adding a feature with good reliability becomes 220 days for 100% reliability. More than seven times the cost. These are just rough estimates, but conservative and indicative of how there is a 10x increase in development costs."

https://medium.com/expedia-group-tech/the-cost-of-100-reliability-ecb2901f23a4

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

https://grafana.com/blog/2021/06/22/grafana-dashboard-showcase-visualizations-for-prometheus-home-energy-usage-github-and-more/

IT Revolution - это издательство которое подарило миру такие известные книги как - DevOps Handbook, The phoenix project, The unicorn project, Accelerate.

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

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

https://itrevolution.com/bookclub/

Тут немного писал про издательство и автора Gene Kim https://xn--r1a.website/neverendingit/113

В комментариях спросили про ИТ книжный клуб у нас в компании. Раскрою тему.

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

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

Сделал объявление в наших рабочих чатах и прокинул еженедельную встречу по пятницам для обсуждения.

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

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

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

Тема кибербезопасности конечно иногда меня манит, особенно когда читаешь все эти разборы, это настоящее расследование!
Оказывается есть целое направление Digital Forensics and Incident Response. Вдумайтесь! Цифровая криминалистика! Выйду на пенсию миграну в ИБ)
И тут конечно по большей части T-Shape люди, ну просто потому, что вам надо быть ну всех уровнях. Файловая система, память, ОС, сети, возможно оборудование. Понимать где и что может оставить следы.

Introduction to DFIR
https://sroberts.medium.com/introduction-to-dfir-d35d5de4c180

По ссылке ниже описание свежего инцидента с криптовальщиком. Компания Kaseya, которая хостит у себя ПО для управления сетями и инфраструктурой стала жертвой. Атаку начали в пятницу вечером) Прямо анти-паттерн "не деплоим по пятницам".

https://therecord.media/revil-gang-asks-70-million-to-decrypt-systems-locked-in-kaseya-attack/

Почти 3 года назад я внезапно для себя решил попробовать для себя совсем другую сферу, видео интервью. Идея была показать Казахстанские ИТ компании изнутри. Взгляд со стороны (насколько это возможно), посмотреть офисы (привет пандемия).
Быстрый поиск показал что контента по локальным ИТ компаниям все еще мало.

Меня хватило на 5 эпизодов. Это отнимало колоссальное количество времени и сил. После этого начал договариваться на сезон 2. Но все шло не так, все договоренности постоянно отваливались, потом привалило работы и мысли о продолжении отодвинулись.
Сейчас work-life balance потихоньку восстанавливается и немного появляется энергия для нового рывка, Пока просто аккуратно смотрю в эту сторону и думаю какие компании могли бы быть в новом сезоне. Благо за 3 года много всего произошло.

Youtube: https://www.youtube.com/c/notasiliconvalley/
FB: https://www.facebook.com/notasiliconvalley

Вообщем есть такой популярный сабреддит r/WallStreetBets, популярен он стал где-то месяцев 9 назад, когда его пользователи стали кооперироваться и разгонять определенные акции.

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

https://www.reddit.com/r/RedditEng/comments/o4y1yv/the_rwallstreetbets_incident_anthology/

На картинке "World’s First Computer Bug" 1947.

Скорее академический видос, в котором автор рассказала происхождение многих ИТ слов, bug (боян, но картинку c жуком приклееным скотчем к документу я увидел впервые), foobar, shell.

Короче один раз для общего развития полезно посмотреть.
https://www.youtube.com/watch?v=2KTK2qD4-gs

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

Quantify the problem and success criteria
Определите проблему и критерии успеха, да это может выглядеть как занудство, но это правда важно, даже если вы просто разработчик. Попытайтесь понять как вы измерите успех. Если вы менеджер или вид, важно вдвойне, вам потом отвечать перед бизнесом а может-быть даже и продавать эту идею.

Start with a tracer bullet
Начните с какого-то действия которе даст вас проверить самый большой риск или проверить саму концепцию идеи. Желательно чтобы задача была короткой и вы могли ее сделать от начала до конца, пусть даже и на заглушках.

Work in small, end-to-end increments
Работать малыми инкрементами, от начала до конца. Очевидно вроде, но как много мы все ошибаемся в этой части. Жадность, желание побыстрее закончить. "Эта задача не делится на части и ее нельзя сделать отдельно." - самая распространенная отмазка)

Prioritize increments by risk and value
"Fail fast" тут тоже подходит, выбирайте задачи по приоритетам, если все еще рисковые, можно взять их раньше.

Use ratcheting to prevent regressions
Подумайте как предварить регрессию в проекте. Например если вы мигрируете на новую библиотеку, вам нужен способ как исключить использование старой, но так чтобы не мешать процессу разработки в целом.

Start what you finish
Закончите наконец работу и принисите пользу)

https://leaddev.com/technical-direction-strategy/making-big-changes-successfully

Вышел State of DevOps Report 2021 от Pupet.

Больше всего зацепился за картинку сделанную по мотивам книги Team Topologies,
Легко и понятно описаны все виды команд и их область ответственности

https://puppet.com/resources/report/2020-state-of-devops-report/

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

Всю статью можно сосредоточить в замечательной фразе.

Our role as developers is to guarantee that the business can prosper through evolving software.

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

https://guifroes.com/no-such-thing/