Юрий Ветров (бывший директор по дизайну Mail.ru Group) опубликовал очень интересный пост о поиске работы. Очень было интересно посмотреть на системный ход мыслей. Полезно почитать даже если не планируете менять работу)

https://m.facebook.com/notes/%D1%8E%D1%80%D0%B8%D0%B9-%D0%B2%D0%B5%D1%82%D1%80%D0%BE%D0%B2/%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%B8%D0%BA%D0%B0-%D0%BF%D0%BE%D0%B8%D1%81%D0%BA%D0%B0-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B/10157768943057229/

Оказывается вышло продолжение книги "The Phoenix Project" .
The Unicorn Project от одного из авторов Gene Kim. Отзывы и рейтинг на amazon вдохновляют.

Есть вдруг кто не читал "Проект феникс" это художественный роман о том, как DevOps меняет бизнес к лучшему. Да да именно художественный, т.е. рекомендуется для широкой аудитории.

А еще оказывается Gene Kim основал в 2013 г. издательство, назвал его скромно "IT Revolution". Посмотрел что издали, с удивлением нашел либо то, что уже читал либо то, что планирую. Вообщем можно заходить и смело брать любую книгу из списка.

https://itrevolution.com/devops-books/

Financial Times выбрала человеком года - CEO Microsoft Сатью Наделлу
Сатья Наделла на посту CEO с 2014 года. Именно с его приходом были связаны крупные приобретения. Linkedin, Github, Mojang (игровая студия которая владеет Minecraft). Ну и вообще с его приходом многие связывают почти перерождение компании.
У него есть хорошая автобиографическая книга - "Обновить страницу" (Автор говорил, что вся прибыль от книги уйдет на благотворительность). Интересно рассказывает про свой ранний опыт в MS. Он успел поработать в подразделении онлайн-сервисов. Неплохо приложил руку к развитию Azure.

https://www.ft.com/content/0e8c3002-20c7-11ea-92da-f0c92e957a96?fbclid=IwAR3SJ987e9zfGxaOD5rRv75IhfeZBlEmYxGVzFsuuC6gbW8tJbjt80inuA4

На Reddit прошла AMA (Ask me anything) сессия с инфраструктурной командой Reddit.

https://www.reddit.com/r/kubernetes/comments/ebxrkp/we_are_the_reddit_infrastructure_team_ama_about/

Кампания запуска Windows 95 обошлась Microsoft в $250 миллионов. Из них группе Rolling Stones заплатили $12 миллионов за песню "Start Me Up".

https://youtu.be/s7g1XuZdyKg

Крутая история от человека который 15 (!) лет проработал в Atlassian. Пришел туда разработчиком и поменял кучу ролей. История компании, как все разивалось и т.д.

На картинке сайт Atlassian в 2004 году.

https://blog.usejournal.com/leaving-atlassian-after-15-years-7f6609fa3ca7

ИТ сектор имеет самые большие показатели текучки персонала по сравнению с другими сферами.
Данные для US рынка, интересно было бы посмотреть на данные по СНГ.
(данные на Март 2018)

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

https://www.payscale.com/data-packages/top-tech-companies-compared

Итоги 2019 года у облачных провайдеров.
1. AWS
2. Microsoft Azure
3. Google Cloud

p.s. Данные на Q3, но сильно картина не поменялась.
https://www.theregister.co.uk/2020/01/02/amazon_google_microsoft_who_had_the_best_year_in_cloud_in_2019

Сколько себя помню, ветка Python 2.7 и 3 жили одновременно, казалось это никогда не кончится) Оказывается с нового года ветка Python 2.x больше не развивается (https://pythonclock.org/). По опросам JetBrains в 2019 было еще порядка 13% пользователей на этой версии.

В блоге SO есть хорошая статья рассказывающая почему переход на Python 3 так затянулся. Там же ссылки по переходу на новую версию от мировых компаний.

Instagram - переход занял 10 месяцев. Закончили в 2017.
Dropbox - переходили очень неторопливо с 2015 по 2018.
Facebook - обновляли сервисы тоже неторопливо в течении трех лет закончили в 2018.

https://stackoverflow.blog/2019/11/14/why-is-the-migration-to-python-3-taking-so-long/

Что происходит когда работы становится вашей личностью.

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

Попробуйте ответить на эти вопросы:

1. Как часто вы думаете о работа вне офиса? Ваш ум часто занимают рабочие мысли? Сложно ли вам поддерживать беседы если они не касаются вашей работы?
2. Как бы вы описали себя? Сколько из этого описания завязано на вашей работе, должности или компании? Есть ли какие-то пути описать себя по другому? Как быстро вы рассказываете о своей работе людям с которыми вы только что познакомились?
3. Где вы проводите больше всего времени? Кто-нибудь жаловался вам на то, что вы слишком много находитесь в офисе?
4. У вас есть хобби вне работы которое напрямую не связано с рабочими знаниями или умениями?
5. Как вы будете себя чувствовать если вы не сможете больше заниматься вашей профессией? Насколько это вас расстроит?

Если хотя бы в паре вопросов вы нашли себя прожженным трудоголиком, возможно имеет смысл качнуть весы Work-life balance в сторону Life. Это вам сильно поможет когда вы начнете к примеру выгорать или просто устанете от текущей деятельности и вам понадобится перерыв. И в этот момент важно чтобы у вас было еще что-то кроме работы. Иначе депрессия обеспечена.

https://hbr.org/2019/12/what-happens-when-your-career-becomes-your-whole-identity

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

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

Думаешь, Не, ну это просто. Что тут писать то.
Берешь ту же самую мысль и пытаешься ее сформулировать. И.. дальше одного предложения не идет дело.
Пыхтишь, кряхтишь, никак. Возвращаешься к исходному тексту. Долго думаешь.

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

Эй, что за булщит ты тут пишешь, скажете вы? Как это имеет отношение к разработке или ИТ? Имеет и еще как. Умение выражать свои мысли письменно или устно, в корпоративной переписке или на встрече важно и уверен коррелирует с отношением к работе и получением удовлетворения от нее.

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

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

Kubernetes при поддержке CNCF открыл свою bugbounty программу на hackerone.

https://hackerone.com/kubernetes

Анонс: https://kubernetes.io/blog/2020/01/14/kubernetes-bug-bounty-announcement/

Задумался, а есть ли еще опенсорсные системы/продукты которые запускали вот так bugbounty? Если знаете, расскажите в личку.

Хорошая подборка культурных ценностей ИТ компаний, со ссылками на официальные странички. Google, Netflix, Uber, Atlassian.

На картинке расписана, одна из ценностей компании Stripe. We Haven't won yet.


https://zamesin.me/culture-codes-examples/

Термин "технический долг" обычно имеет плохой оттенок в мире разработки. Автор статьи рассуждает, что не все так плохо, некоторые допущения при разработке будут (а иногда и нужны) важно их четко понимать и видеть когда мы их создаем, ну и само собой понимать что возможно "долг" придется отдавать.

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

https://engineering.squarespace.com/blog/2019/three-kinds-of-good-tech-debt

Конечно упоминание о тех долге было бы не полным без ссылок на культовые статьи.

Martin Fowler
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

Uncle Bob
https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt

Эффект орехового острова - феномен организационного поведения.

Ореховый остров - бывший остров в Бостонской гавани, часть национальной зоны отдыха островов Бостонской гавани. На нем в 1952 году был открыт завод по очистке сточных вод. Объект был в ведении государственной организации которая в то время занималась еще кучей разных дел, созданием общественных бассейнов, хоккейных площадок, инфраструктуры для проведения воды. Так как эти объекты часто были очень удобными для политического патронажа, топ менеджмент стал сфокусирован именно на этой части работы, упуская из виду работы по очистке сточных вод. Кадровый состав завода в то время состоял по больше части из экс-военных (это было время окончания второй мировой и корейской войны). Т.е. людей которые по натуре своей склонны создавать сильные, сплоченные коллективы умеющие работать в изолированной, недружественной среде.

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

Собственно резюме, через какие этапы прошла организация и почему:
- Отвлечение внимания руководства и командная автономия. Создается климат, в котором менеджмент поглощен другими вопросами а команда представляет собой сплоченную группу высоко мотивированных и квалифицированных специалистов, которые стремятся к автономности и избегают публичности/коммуникаций.
- Предположение и недовольство. Менеджмент предполагает, что команда самодостаточна и начинает игнорировать запросы на помощь, что приводит к обиде команды.
- Де-факто разделение. Сплоченность команды и обида на менеджмент приводят к полному разделению, характеризующемуся ограниченным общением и полным отказом от посторонней помощи.
- Самоуправление. Чтобы удовлетворить внешние требования, команда переходит к саморегуляции, которая создает скрытые проблемы.
- Хронический системный сбой и коллапс. Безразличие руководства и ошибочная саморегуляция команды становятся системными, что приводит к повторным сбоям и возможному катастрофическому коллапсу.

https://hbr.org/2001/03/when-good-teams-go-wrong
https://en.wikipedia.org/wiki/Nut_Island_effect

В этом вся драма) Самый любимый и нелюбимый одновременно.

Hired подготовили свой State of Software Engineers. Портал работает в основном на Европу и Америку, поэтому при чтении результатов надо делать поправку на ментальность.

https://hired.com/page/state-of-software-engineers/

Как Twilio масштабировались с нескольких сотрудников до нескольких тысяч.

Старт проекта 2008 год несколько разработчиков обсуждали задачи проекта напрямую с тремя кофаундерами. С ростом команды до 40 сотрудников все было хорошо, все коммуникации происходили устно и в реальном времени. Но с каждым новым человеком синхронизироваться становилось все сложнее и сложнее.

Рост от 40 до сотен сотрудников. Экспериментировали с орг структурой, собирали команды по скиллам и направлениям а не по продуктам, получили падение скорости в развитии продуктов, каждый специалист мог участвовать в 10 продуктах одновременно. Ближе к IPO пришли к продуктовым командам.

От сотен до тысяч сотрудников. Каждая новая команда получает свой бюджет, ресурсы и сотрудников. И развивается как настоящий стартап. Есть уже даже успешные команды/продукты которые отработали по такой модели.

https://increment.com/teams/how-twilio-scaled-its-engineering-structure/