Об переработки

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

Q: Мне оплатят переработку?
A: Посмотрите в свой трудовой договор. Если там указан ненормированный рабочий день (а у многих разработчиков это именно так), то - нет, в общем случае никто не обязан оплачивать вам эпизодические переработки, пока они не становятся "систематическими". К сожалению, систематичность -- очень вольная трактовка. Но обязаны компенсировать, и обычно компенсируют это дополнительным отпуском с длительностью по согласованию сторон. Все описанное выше не противоречит ТК РФ.

Q: Но из-за переработок падает производительность!
A: Про падение производительности я писал ранее, а теперь дополню небольшим забавным умозаключением:

а) Как пишут вот тут (https://habr.com/ru/news/t/523958/), разработчики в среднем крайне утомлены удаленкой (почти 70% ответили так). А тут (https://www.vedomosti.ru/opinion/columns/2020/06/15/832674-plyusi-udalennoi) пишут, что они в среднем перерабатывают заметно сильнее офисных коллег.
б) Переработки плохи тем, что падает производительность из-за утомления и снижения мотивации.
в) Многие разработчики сейчас предпочитают и выбирают "удаленку".
Из чего следует, что разработчики добровольно выбирают перерабатывать, выгорать, демонстрировать производительность заведомо более низкую в обмен на обычные, 100% деньги. Рациональный вывод из научной науки, тут не поспоришь.

Самурай идет в бой, уже умерев; разработчик идет на удаленку, уже выгорев.

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

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

Одна из сложнейших проблем цифровизации и автоматизации -- подружить реальный и виртуальный миры.

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

Как написали в ФБ, у молодежи вот какие пути по жизни после школы: в вебкам, носить закладки, курьер еды, айтишник. Ты либо часть целевой системы, либо элемент обеспечивающей. И много где тобой помыкает некоторый The Algorithm (докажи, что это не так!), который оптимально распределяет задачи. Легко предположить, что такая ситуация сложилась совсем не случайно.

Все, что надо знать о классическом проектном управлении: выход очередной редакции свода знаний PMBoK (v7) откладывается, свод не будет выпущен в изначально запланированные сроки из-за отставания от планов (начало 2021 года)

Об микроменеджмент

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

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

Если ваши поручения такого размера и такой проработки, что "да ну его, ещё почтой писать, лучше в Whatsapp чиркну или на звонке раздам" — привет, это и есть оно самое, ручное управление.

Какая реклама микрокалькулятора вам нравится больше - слева или справа?

Одна из первых серверных стоек Google. Я бы после эксплуатации такого тоже Кубернетес делать начал

Об супергероев

Почему программисты (инженеры, и вообще -- технари) так любят супергероические комиксы, саги и другое героическое творчество? Ничего сложного, на самом деле.

Кто такой Супергерой? Супергерой обычно это непонятый гений, и что важно -- СПЕЦИАЛИСТ. Он приходит, нарушает все правила и регламенты, и своими руками делает грязную работу, которую не осилили другие. Целая Система Добра не смогла предотвратить проблемы, и теперь специалист Исправляет Ошибки Менеджмента (видел такую формулировку в резюме неоднократно).

С кем же он обычно борется Супергерой, кто ему противостоит?

Обычно ему противостоит некоторая Империи Зла с Антигероем во главе. Антигерой -- это совсем другое дело. Чтобы построить настоящую Империю Зла, недостаточно просто быть Специалистом по Злу: нужно растить себе заместителей, управлять десятками и сотнями туповатых и грубых подчиненных, выдавать задачи на совершение Зла, проверять, что Зло было выполнено согласно поставленным задачам, привлекать во Зло инвестиции, распределять финансы, следить за рынком сбыта Зла, хантить перспективных кандидатов. В общем, главный Антигерой - это ТОП-МЕНЕДЖЕР.

Хорош ли он как топ-менеджер? Кажется, что да: как-никак, построил целую Империю. НО обратите внимание: раз за разом, от саги к саге, любой Антигерой говорит одну и ту же фразу: "хочешь сделать что-то хорошо, сделай это сам". А это, если вы вдруг не в курсе, самый настоящий управленческий антипаттерн слабого менеджера. Похоже, что Антигерой как менеджер все же не очень. Может быть, отсутствие сильного противника его расхолаживает.

Что же происходит дальше? Антигерой идет делать Зло в отношении Супергероя своими руками, и обычно у него почти удается. "Почти", потому что он уже плохой специалист, и забыл, как довести работу до конца. Ему бы прихлопнуть Супергероя, но нет -- Антигерой обычно сваливается в нужное и важное дело для менеджера -- рефлексию. Для менеджера, но -- не для специалиста.
Запомните, ребята! На позиции специалиста надо не рефлексировать, а работу работать.

Тут-то Супергерой и наносит ответный удар, и побеждает. Зло повержено, Империя разваливается, ура.

Так почему же комиксы про супергероев так нравятся? Потому что там Специалист:
1. Исправляет ошибки менеджмента (своего)
2. Побеждает плохого Менеджера (топ-менеджера Империи Зла).

Выводов, конечно, не будет: я же все просто нафантазировал.

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

"Для клиентов из России наш сервис продолжит работу с 10 января. Для всех остальных - со 2 января. Приятных новогодних праздников"

Во множестве рекламных треков "Обучение ИТ с нуля до про" никто не признается, что до "про" придется качаться самому, и почти всю оставшуюся жизнь, а курсы просто покажут, где находится "про" (очень неблизко)

"Просто удивительно, как часто разработчики считают, что для использования новых технологий достаточно одних предположений или сведений, полученных из прессы или телеконференций"
~~ Ed Sullivan, NuMega, примерно 1997 год.

Похоже, с тех пор мало поменялись пресса, конференции, да и разработчики тоже

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

Знаменитые решетчатые рули на первой ступени Falcon, 1974-й год

Любопытный анализ про STEM. Конечно, не хватает фактологической базы. Но в любом случае, размышления интересные https://www.vtimes.io/2021/01/11/fiziki-i-liriki-kem-bit-a2418

Атас, лох начал что-то подозревать

Об эмерджентность

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

Нам нужно более простое ИТ, пора возвращаться к истокам.

Об интеллект

В ФБ давеча замелькали курсы от "основателя компании DBrain, миллионера, эксперта по ИИ/AI Дмитрия Мацкевича". Ну читает и читает, что удивительного, а оказалось — ничего подобного, какая-то брокерская компания сделала достаточно качественные deep fake видео, и "креатив", и лендинг тоже на уровне, чтобы продвигать свой продукт на базе конешноже ИИ.

Вот так вот ИИ-шнику по жопе шлепнуть при помощи ИИ это, господа, КРАСИВО!

Об новые технологии

Если вы когда-то встречали в резюме запрос вида "хочу работать с новыми технологиями", то это надо понимать так: я хочу в свое удовольствие на работе ковырять и осваивать кафку, докер, кубернетес, чтобы через полгода-год на +50% к окладу уйти к бОльшим дуракам, чем вы. А вовсе не то, что с помощью новых технологий можно работать быстрее, эффективнее, дешевле строить системы, которые работают надежнее.

Исключения бывают, но я их видел очень редко.