Аналитики подсчитали, что четверть от общего числа веб-страниц, которые существовали в период с 2013 года по 2023 годы, по состоянию на октябрь 2023 года уже недоступны. В большинстве случаев это связано с тем, что с течением времени страницы сайтов радикально корректируются или же попросту удаляются. Для более старого контента эта тенденция также актуальна. Около 38% веб-страниц, существовавших в 2013 году, недоступны в настоящее время. Если же рассматривать веб-страницы, существовавшие в 2023 году, то показатель недоступных в настоящее время составит 8%.

Давно заметил, что много страниц, на которые ссылался в первых статьях блога перестали открываться. Ненадежная история...
When Online Content Disappears и перевод на 3dnews

#байки

Часто обсуждают переходить ли на темную менеджерскую сторону карьерной лестницы или ну его нафиг.

Реже встречаются обсуждения "а что там дальше, на менеджерском пути?"

Прямо скажем, в топ-директора и прочие топы ведь мало кто попадет (совсем мало). И большая часть тех, кто не вернется в разработчики, подрастут на уровень выше лида и останутся "вечными майорами" middle manager-ами (менеджерами среднего звена). Это ни хорошо, ни плохо. Это жизнь.

Но даже middle-менеджеры бывают разными. Как и собственно уровень "среднего звена" будет разным в разных организациях.
Все ровно то же, что и с уровнями сеньоров и принципалов в разработке.

А что по ожиданиям от менеджеров среднего звена?

"Middle managers as *critical thinkers* are an indispensable part of today's organisations. They are responsible to create pictures of possible futures for those who report to them." (с) Dr Zahira Jaser

На этой неделе будет серия статей по этой теме. По ссылке в день, все равно больше никто не прочитает :)

"The Real Value of Middle Managers"

продолжение...

#management

Продолжаем про "средних".
"The manager’s job is less to tell them what to do, but more to inspire them."

The Middle Manager of the Future: More Coaching, Less Commanding

Прям на базе исследования (для фанатов пруфов).

продолжение...

#management

Ideal middle manager is one who understands both what happens below and what happens above

(не мое)

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

PS К сожалению (а может и к счастью), будете ли вы идеальным менеджером зависит не только от вас, но и от тех кто "снизу" и "сверху".

ЗЫ начало истории пост 1
ЗЫ2 ссылка на статью с заглавной цитатой

#management

Фиксы в прод... Изи... Погнали 🎉

Тесты? Какие такие тесты?

пятничные немного грустные #it_memes #тесты_в_проде

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

Навеяно, даже когда-то разделяемыми мною, мыслями вида "не надо боятся нанимать тех, в ком сомневаешься, ведь с ними легко можно попрощаться, пока идет ИС".

Да, но нет.
Оставим пока в стороне тему "если есть сомнения, то трактуйте их не в пользу кандидата", если интересно, то потом можно ее повертеть.
А сегодня про то, что уволить с ИС не так просто, как кажется.

Немного юридической казуистики для тех, кто думает, что это просто.
Дальше речь про РФ. Это действительно просто, если расставание происходит по взаимному согласию.
Если же сотрудник считает, что у него все хорошо и он не согласен уходить, то начинается юридическое веселье (немного подробностей про возможные сложности тут).

И только в этот момент все дружно вспоминают про отсутствующее вообще или формально незафиксированное задание на ИС.
Почему его нет? Потому что "мы все адекватные люди и сможем договориться", "нельзя/сложно придумать задания на 3 месяца испыталовки".

Часто в качестве работающего варианта предлагают "сделать выговоры и уволить". Остается неясным, за что выговоры делать :)
Уверяю вас, обычно люди, которые готовы на подобную конфронтацию строго соблюдают режим дня, фиксируя время прихода/ухода и тп.

Лично был свидетелем истории, когда человек (разработчик) месяц ходил на работу, где у него на рабочем столе был комп с выключенным сетевым доступом. Звучит как треш, да это и есть треш. Но факт :)

Еще есть вариант "никто не будет судиться с корпорациями". Ну, во-первых мало кто из нас работает в корпорациях, а во-вторых можно и без суда устроить веселье в кадровом отделе просто написав жалобу в трудовую инспекцию.

Часто ли такое происходит?
У меня за >15 лет менеджерской работы было 4 раза, когда испытуемый не был согласен с результатами ИС. Последний раз было в 2020, то есть это не ретрослучаи.

Можно ли на это забить? Можно, но осторожно. Но проще не нанимать тех, кто вызывает сомнения.

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

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

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

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

А вообще пусть у всех такое случается реже :)

#management #собеседования

Микроменеджемент
Мои наблюдения:
1. Никто (ок, мало кто) из менеджеров, которые активно влезают в жизнь команд и фактически микроменеджерят, не считает себя “микроменеджером”.
2. Менеджеры микроменеджеров часто считают последних очень эффективными менеджерами.
3. Команды, которые вынуждают использовать с ними микроменеджмент, сильнее всего “кричат” про недопустимость этого.
4. Чем сильнее используешь инструменты микроменеджмента, тем сложнее от него избавиться в дальнейшем. Более того, чем дальше, тем больше ты будешь склоняться к тому, что это единственный рабочий вариант.
5. Различие между “доверяй, но проверяй” (правильно) и “я не верю, что вы сделаете правильно и поэтому буду проверять” (неправильно) в разных ситуациях/контекстах/головах может размываться до состояния “одно и то же”.

Выводы:
1. Для команд: не любите микроменеджмент - спросите у менеджера, что ему нужно, чтобы обеспечить доверие и прозрачность между вами и им. Ну и меньше “играйте” в “дайте нам приватное пространство для общения”.
2. Для менеджеров: не давайте повода к мыслям об отсутствии доверия и подбирайте команду тщательнее. Самая сложная история - это команда в “наследство” или “приданое”. Там установка доверительных отношений - это то, с чем надо начинать.

Будьте готовы к тому, что первые же ваши обоюдные “косяки” сломают все договоренности.

Что еще посмотреть:
1. Accused of Being a Micromanager? Here’s How to Change It
2. The Anxious Micromanager

продолжение...

#management #мысли_вслух

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

"Никакой учености тут нет, сударь. У моего кума была кошка, которая, извините, огурцы ела. Недели две полосовал кнутищем, покудова выучил. Заяц, ежели его бить, спички может зажигать. Чему вы удивляетесь? Очень просто! Возьмет в рот спичку и — чирк! Животное то же, что и человек. Человек от битья умней бывает, так и тварь".

Антоша Чехонте (1883)

А вы говорите, разработчик не может тестировать…

#мысли_вслух #байки #testing #настроение_дня

Продолжаем про микроменеджмент.

People don't like to be micro-managed.

But they also don't like to to be macro-neglected.

One of the most powerful things leaders can do is to help people master their craft and raise their currency.

The best want to get better.

(с) отсюда

имхо, умение балансировать между "уверенно направлять в нужный момент" и "предоставить свободу" - это и есть управленческий талант...

#management
#мысли_вслух

Когда сеньору разрешили фиксить минорчики...

#it_memes которые напоминают про зайца со спичками...

Estimating Might Be Broken, But It’s Not Evil

Статья 2013, а ничего не поменялось (а я вам могу сказать, что и за 20 лет ничего не поменялось)...
Мы спринт то не можем оценить так, чтобы треть запланированного не перенеслось на следующий спринт.

А уж годовые планы - это вообще, какое-то упражнение с элементами садо- мазо.
——
Напомнило мне давнишнюю баечку (простите, матерную)
- Ни хера ты не менеджер, все сроки и стоимость всегда нужно умножать на Пи.
- На пиз..ц?
- Можно и на него.

И это не про то, что оценка не нужна. Это про то, что ее надо учиться делать и понимать, когда не нужно упарываться.

#management #оценка

3 стадии развития карьеры:

1. Ух ты, меня пригласили на встречу.
2. Я организовываю и провожу встречи.
3. Блин, ну нафига нужна эта встреча, все можно было в почте/месенджере обсудить. Давайте как-нибудь без встреч.

ЗЫ по мотивам тви

#мысли_вслух #байки

Рецепт успешных процессов и качественных продуктов:
1. Берете все общепринятые практики разработки и тестирования
2. Определяете набор обязательных артефактов по всем этим практиками
3. Не забываете про проверки и апрувы безопасности
4. Каждый релиз проверяете, что команды выполняют все эти пункты
5. Взболтать, но не смешивать. Внедрять лучше в середине года, даже если не было запланировано

Делаете и ждете профит в виде качественных продуктов для пользователей.

новая рубрика #IT_сказки

Measuring Engineering Velocity on a Software Team

Хмм, интересная (потому что вполне адекватная) подборка рекомендаций по работе с velocity команды, а точнее с ее оценкой.

#metrics #management

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

живые #it_memes со звуком

Unexpected Anti-Patterns for Engineering Leaders — Lessons From Stripe, Uber & Carta:
• anti-pattern #1: shying away from micromanagement (как мы уже обсуждали, иногда "микроменеджмент" - это единственный способ добиться результата)
• anti-pattern #2: pushing back on measuring flawed metrics (вот тут не согласен - если знаешь что меряешь фигню, то зачем?)
• anti-pattern #3: serving as the umbrella for your team (люто плюсую в этом месте)

#management #metrics

Про вчерашний анти-паттерн по метрикам.

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

• Don’t try to measure too much. Just because you can measure something doesn’t mean that you should.

• Understand the goals of your project before you determine what to measure.

• Once you determine the goals for your project, determine which metrics support these goals. Try to choose from existing metrics rather than defining new ones. The important point to note is that now you know why you are using each particular measurement.

• Don’t let your metrics define the behavior of your team. If the metrics you have chosen can be modified without showing an increase or decrease in quality, either change the metrics or choose a set of relative metrics that cannot be manipulated.

• Monitor the metrics throughout the project. Just as you measure the project to assess quality, you should measure the metrics program to define areas for improvement and identify trends you can use to provide better information to the team.

#management #metrics

И снова про "волшебников"

Регулярно наблюдаю истории веры в "волшебника":
- нам нужен аналитик (системный, бизнес, продуктовый)
- нам нужен архитектор (куча разных сценариев приложения его усилий)
- нам нужен "автоматизатор", который придет и скажет, как феншуировать автоматизацию тестирования

Вера в специализацию безгранична, ровно до того момента, когда выясняется, что
- мы не можем нанять, потому что сами ничего не понимаем в специлиазации "волшебника"
- мы не можем понять творит ли он волшебство, потому что изначально не было критериев "чуда"
- мы не верим в свои силы и отказываемся изучать/делать эту работу самостоятельно
- "волшебник" никого не пускает в свои чертоги репозитории, потому что "чего вы там, неучи, забыли" и он становится бутылочным горлышком, которое непонятно чем занимается

А чаще всего проблема, ради которой искали волшебника, решается просто выделением времени на изучение чего-то нового существующей командой, T-шейпингом и тому подобным расширением экспертизы самой команды или просто наймом еще одного "обычного" инженера, а не ботлнекера.

#мысли_вслух #байки

"Разработка программного обеспечения — это процесс поиска и исследований.
Следовательно, чтобы добиться успеха в этом, инженеры-разработчики должны стать экспертами в приобретении знаний или навыков посредством опыта или обучения."

"Modern Software Engineering" Dave Farley

Учитесь учиться, господа-товарищи.

#развитие #мысли_вслух

"Малыш и Карлсон проверяют код" сказка из древнего твиттера

#it_memes

Странно, я давно знаю про принцип Питера, но в первый раз за все время эта статья про него действительно показала мне, про что он :)

Потому что "традиционное" определение меня немного клинило, но я никогда глубже не смотрел:

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

А теперь чуть-чуть доворачиваем и вот "подсказка":

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

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

#management