Я снова не смог написать кратко, но уж как вышло.

Существует мнение будто менеджеры, которые выросли из инженеров, управляют людьми плохо. И ведь на самом деле так и есть! У меня десятки примеров в личном опыте, включая меня самого.

Наиболее частый путь следующий: проект растёт, людей быстро набирают, кого-то назначают их менторить, в какой-то момент менеджеров перестаёт хватать. И тогда один из последних подходит к самому адекватному из команды в лучшем случае, а то и просто к самому способному инженеру в худшем и грит: «Слу, ты ж этих людей уже обучал всё равно. Теперь надо ещё немного помониторить их работу, раскидать задачки. Хуле там сложного, м?» — И на этом всё в общем-то. Человек соглашается на лычку тимлида и думает, что это и есть менеджмент, а его руководитель тем временем часть задач делегировал и больше не парится. Многие в таком состоянии прям и остаются на годы. И это ок, наверное.

Проблемы начинаются, если рост продолжается. Тут вроде два основных варианта (помимо редкого «как должно быть на самом деле» — мне по крайней мере с этим не повезло).

1. Новоиспечённый тимлид начинает зашиваться, времени на всё не хватает, а код писать ещё хочется, поэтому он сам уже ищет, кому б чё делегировать. Подходит к кому-то из команды и грит: «Слу, там надо вот это и это промониторить, хуле там. Сможешь?» — И круг замыкается. Никаких объяснений, в чём состоит работа, никаких особых напутствий.

2. Ещё хуже, если тимлид идёт на уровень выше, заводит себе своих подчинённых менеджеров и управляет в духе: «Так блэд, я теперь тут босс нахуй». По ощущениям этим часто грешат выходцы из СНГ, но у меня выборка не оч разнообразная так-то.

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

Но есть вариант, который бесит меня больше всего! Это когда бывший инженер настолько ударяется в менеджерскую стезю, что игнорирует свой предыдущий опыт. С этими людьми каши не сваришь. Они возможно ещё способны общаться с теми же программистами на одном языке благодаря своим остаточным знаниям, но они не помнят, каково это — быть программистом. Они не могут встать на место рядового инженера, прочувствовать его боль и нужды. «Так а чо, тут просто процесс новый введём и обяжем всех ему следовать». К сожалению, таких руководителей в моей практике больше, чем хотелось бы.

И вот буквально на прошлой неделе кто-то на HN раскопал старую статью с Harvard Business Review, говорящую о том, что согласно исследованиям люди в среднем счастливее на работе, если их руководитель способен при необходимости выполнять их обязанности. Другими словами, если он технически подкован 🙂 Причём оказалось, что это чуть ли не самый влиятельный фактор.

К чему я это… Если вы «рядовой» сотрудник и внезапно стали тимлидом, техлидом, engineering manager'ом и т.п., то высока вероятность, что управленческая часть — ваша слабая сторона. Безусловно имеет смысл инвестировать время в образование по теме. Но и корни свои забывать тоже не стоит!

Разгребаю залежи непрочитанных статей. Наткнулся на интересное.

Не секрет, что MBUX написан на C++ и QML. Если с первым всё ясно, то последний известен в меньшей мере и представляет собой декларативный язык для UI в составе фреймворка Qt. Он позволяет нам и быстродействия добиться, и шейдеров всяких для эффектов поверх навернуть, и модельку машины в 3D покрутить, и при этом достаточно быстро весь этот полностью кастомный интерфейс разрабатывать.

Собсно, даже сама Qt Company сильно к автомотив-отрасли и прочим embedded-системам нынче тяготеет. В отличие от Nokia — предыдущего владельца Qt — им не так интересны мобильные приложения, а про десктоп и говорить нечего — веб-приложения всё вытесняют.

И тут в конце прошлого года оказалось, что Epic Games, не нуждающаяся в представлении, запартнёрилась с General Motors, и следующий Hummer последних выйдет с HMI на основе Unreal Engine.

Оно и понятно. Unreal Engine — это игровой движок, а кто, как не гейм-девелоперы, шарит в создании кастомных UI и выжимании фпс-ов даже на слабом железе? С последним, кстати, ситуация тоже упростилась. Даже первое поколение MBUX, выпущенное вместе с «бюджетным» A-class, работало на вполне себе не слабой Tegra.

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

Вдвойне забавно, что с одним из типцов из видео мы раньше вместе работали 🙂

Тут Sublime Text тизернул недавно четвёртую версию. В принципе выглядит ок, но не подкупает. Ничего такого, чего бы мы уже не видели в VS Code. С другой стороны, последний как-то потихоньку обрастает фичами и уже не такой резвый, а саблайм наверняка всё ещё стартует со скоростью дабл-клика.

Когда-то давно Sublime Text 2 стал для меня триггером перехода с использования IDE на редакторы кода именно потому, что [я в нём] работал супербыстро. (С тех пор, кстати, не видел Notepad++ — лет 8–9 уже). Оказалось, что всякие там go to definition и прочие extract method’ы — это, конечно, прикольно, но не необходимо. Это тема для отдельного поста впрочем.

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

Прочитал я когда-то книгу «Хороший интерфейс — невидимый интерфейс» Голдена Кришны. Перевод на русский местами мне не понравился, так что вот сайт оригинала, а если уж совсем хочется, вот русскоязычное издание. Подробный обзор я написать уже не смогу, но чисто в рамках краткой рекомендации в двух словах опишу.

Вся книга — это какая-то квинтэссенция нытья. Автор весьма эмоционально и заёбно ноет, ноет, ноет и ноет по поводу того, какие говнячие сейчас интерфейсы, как его заебали тачскрины, необходимость доставать из кармана телефон, пялиться в экран и т.д. И знаете что? Он прав! Меня тоже это заебало.

Вместо впихивания экрана и создания приложения для любого говна он рекомендует фокусироваться на типичных процессах, изучать привычки, воплощать их в аппаратном/программном виде и автоматизировать. Примеров тоже хватает: начиная от налобного фонарика, автоматически регулирующего свою яркость, багажника авто, открывающегося при проведении ногой под бампером, подушек безопасности, и заканчивая автоматическими дверьми в супермаркетах, термостатом Nest или, например, самоохлаждающейся Mazda 929 аж 1991-го года выпуска (привет, Тесла).

Автор, кстати, в Гугле работает. Отсюда у меня вопрос: когдааааа же, блядь, у вас в Гугле кто-то эту книгу наконец прочитает?

Ну и пример чисто от меня. Делал я тут себе «умный дом» на основе Home Assistant. Первым делом, конечно, законнектил в него всё, что смог, начиная от датчиков температуры и заканчивая твитчом и стимом. Законнектил и сел думать, а чё теперь с этим делать.

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

Настроил дашборд, чтоб всю инфу выводить. Даже Grafana насетапил.

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

Всё остальное — нахер не нужно. Я web-ui Home Assistant месяцами не вижу.

Короче, это тот самый случай, когда меньше — это больше.

Сдыбал тут ещё одно никому не нужное известное посягательство на лавры Excel — CubeWeaver. Особенно упорото на сайте смотрится видос, озвученный с помощью синтеза голоса 😅 Зато по видео сразу ясно, насколько не интуитивный там интерфейс.

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

Заметил, что нынче при описании каждого нового сервиса, инструмента и т.п. приписка «written in Rust» встречается уж крайне часто. Причём, я так понимаю, это должно добавлять сразу +100 к доверию.

Не, я понимаю, что «стильно, модно, молодёжно», но почему мне как пользователю не должно быть похеру на чём там оно написано?

Ах, да, мемори сейфти же? Типа по умолчанию более безопасно. Так давайте вспомним, как автора экстремально популярного actix-web затравили за то, что он в блоке unsafe чё-то написал. Не по канону типа. Язык — лишь инструмент и сам по себе гарантий никаких не даёт.

Вы видели, чтоб где-то гордо указывали, мол, написано на C++ или Delphi, или Java, или VB? Вот и я не припоминаю. Зато знаете, что ещё раньше гордо писали? Что смогли заимплементить что-то на JS. Забавно поначалу было, да, только теперь чат на компе полтора гигабайта ОЗУ хавает. Уже не так забавно.

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

Все, кто хоть раз использовал электронное устройство, знают такое словосочетание как «сообщение об ошибке» (error message). Даже мой МК-61 умел выводить слово ЕГГОГ семисегментными индикаторами.

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

«Введён неверный адрес», «пароль не подходит по критериям», «задайте дату в формате MM/DD/YY», «файл с таким именем уже существует⚠️», «ты пропустил ; в коде, и я, компилятор, знаю это, но дальше работать отказываюсь» и т.д. Встречаю подобное ежедневно.

И намедни прочитал тут статью, где чел пишет про т.н. предписывающие (prescriptive) и описывающие (descriptive) инструменты.

Последние — те, что описывают происходящее (в логах, нотификейшнах, окнах статуса, месседж-боксах и т.д.). Большинство тулов именно такие, мы все к этому привыкли, но как же бесит сначала диагностировать проблему, нередко прибегая к помощи гугла и SO, а потом ещё и думать, как именно её резолвить. Больше бесит только ситуация, когда инструмент наверняка знает, в чём проблема, знает, как её решить, но всё равно заставляет выполнять какие-то специальные действия.

«Ах, ты пытаешься закоммитить что-то в репу с чистым git-конфигом? На, сука! Напиши вот эти две команды в терминал, чтобы сообщить своё имя и имейл. Я мог бы и сам сразу спросить, но я всего лишь инструмент, а ты человек, делающий работу».

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

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

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

Задача быстро поделиться расположением чего-либо толком не решена. По крайней мере была. Есть такая к сожалению не сильно известная тема как what3words. Идея до безобразия простая: чуваки взяли нашу планету, поделили на клетки 3×3 метра и каждой такой клетке дали уникальный идентификатор из трёх рандомных слов. Теперь достаточно просто сказать кому-то три слова — и вуаля. Поддерживаются разные языки, но, похоже, слова в них никак не связаны. Например, вот адрес середины дамбы (излюбленное место мотоциклистов) в Шварцвальде: ///кооперативный.удобно.текстильный (на немецком: ///eure.bekleideten.wellung).

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

Во-вторых, конечно, недостаточная распространённость. На тренинге в Красном Кресте мне говорили, что в Великобритании прям по телеку эту тему рекламируют как средство быстро сообщить локацию службам спасения. Очень круто! Но у нас, боюсь, могут и не шарить, что это.

Кстати, MBUX — наша бортовая система для Mercedes-Benz — тоже поддерживает. Но это скорее исключение из правил — большинство остальных продуктов всё же британские.

А вы что думаете? Приживётся? А, ну да, комментов же в канале нет 😊

На коллаборацию Epic Games и GM прилетела ответочка от Unity и HERE. Пока по ходу никаких конкретных анонсов моделей автомобилей, но ясно одно: игровые движки в HMI автомобилей — это даже не будущее, а почти настоящее.

Ну всё, теперь точно пора ливать с Qt 🙂 Их тулинг и рядом не валялся канеш.

Кстати, мне как менеджеру тема интересна ещё и по другой причине.

Геймдев славится своими кранчами. И далеко не все люди, там работающие, фанатеют от создания игр настолько, чтобы с этим мириться. При этом сфера настолько специфичная и глубокая, что заскочить в неё с улицы без релевантного опыта порой непросто. Обратное тоже верно: не каждый гейм-девелопер пойдёт пилить CRUD в энтерпрайзе — чаще просто переходят из одной игровой студии в другую.

Автомотив даёт альтернативу. Он в плане переработок, конечно, не сильно лучше порой и точно не панацея, но весьма неплохой способ сменить обстановочку и атмосферу. Посмотрим, как это отразится в будущем на хедхантинге.

Произошло ровно то, что рано или поздно должно было: телега меня наломала с запланированными сообщениями, отправив их в обратном порядке 🤦🏻 Сссучьи технологии — никогда нельзя положиться!

У меня в дескрипшне канала написано, что я «нерегулярно» пишу; при этом с момента создания посты были минимум раз в сутки. Думали небось, я в натуре их каждый день строчу? ) Пхах 🙂

Скоро в каждом автомобиле

Как можно было заметить, помимо мало известных языков программирования я люблю всякие инструменты и особенно мутные (читайте — исследовательские) UX-решения в них. Расскажу вам сегодня про Code Bubbles.

Всё началось с этого видео.
Типок по имени Andrew Bragdon, будучи аспирантом в Брауновском университете, сделал в 2010-м PoC среды разработки для Java на базе Eclipse. Мне сразу понравилась идея, ведь в процессе разработки я мысленно группирую куски кода похожим образом в зависимости от контекста, а тут всё то же, но ещё и наглядно. Никакой ебанины с миллионом открытых вкладок, сплитом окна и пр.

Чел обещал выпустить паблик бету, но идея понравилась не мне одному. Microsoft схантила чувака, и буквально через год в Visual Studio появился Debugger Canvas — тот же самый подход, применённый по большей части только для отладки. Джаву, конечно, поменяли на C#, а обещанная бета оригинальной тулзы так и не вышла. Зато пейпер написали, поставив типца на второе место в списке авторов.

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

Надеюсь в будущем увидеть какое-то развитие идеи!

TIL в Python есть встроенная константа Ellipsis и эквивалентный литерал ... (дока). Используется, например, в NumPy для слайсинга, но также можно использовать в функциях вместо pass:

def foo():
... # 👈 прям валидно

При касте в bool даёт True. Хз, что это вам даёт. Живите теперь с этим.

После выходных в самый раз написать про отдых.

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

Но с годами понимаешь, что уж в work-life balance немцы знают толк. Из-за того, что всё закрыто, ты не можешь ничего особо планировать на воскресенье. И поэтому остаётся только… отдыхать. Люди из СНГ в среднем отдыхать не очень умеют: они сначала ебашат на работе, а потом в оставшиеся крупицы времени пытаются уместить шоппинг, танцы, клубы, спорт и всё-всё-всё. «Лучший отдых — это смена деятельности», — слышали наверное? Чушь, конечно, особенно если погуглить, откуда это выражение пошло. Энергия не резиновая.

С субботой ситуация немного иная. Так или иначе в этот «выходной» приходится решать бытовые вопросы, на которые не было времени и сил в течение недели. Доколе‽ Как пофиксить это?

Я в сообщении, на которое реплайнул, упоминал кранчи в геймдеве. И на DTF как раз была длинная и немного однообразная статья на эту тему со ссылками на кучу исследований. Если кратко, то 40-часовая рабочая неделя — отнюдь не оптимальный вариант, а овертаймы — просто пиздец.

Я вот какое-то время работал четыре дня в неделю в виде исключения (не выюзал отпуск и раскидал остаток дней) и могу сказать, что работа перестала ощущаться таким дном и даже как-то прям начала приносить удовольствие. По ощущениям я даже успевать стал больше! Сча, правда, вернулся в «нормальный» режим, и снова подкатывает.

Интересно, сколько ещё времени пройдёт, прежде чем «стандарт» 5 дней × 8 часов эволюционирует во что-то новое?

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

Писал не так давно, что Qt Company по моему мнению сливает полимеры, в том числе в плане тулсета, который они предоставляют разработчикам продуктов.

Сама Qt, похоже, сдаваться так просто не собирается, поэтому вчера купила компанию froglogic GmbH. Последняя делает по ходу единственный кое-как рабочий продукт для автоматического тестирования UI, способный работать с Qt-приложениями — Squish. Чтоб вы понимали, это среда разработки на базе Eclipse, где в качестве дефолтного движка для скриптов используется Python 2. Оч свежо. Годовая лицензия на это дело — почти 3000$.