Важная для меня тема.
За всё время, что я программирую, я «изучил» весьма внушительное количество разнообразных языков. На некоторых я по итогу не написал ничего больше 100 строк кода, но ещё ни разу не пожалел о потраченном времени. Почему?

Для меня изучение языка программирования покрывает два основных топика: 1) поглядеть «а как ещё бывает» и 2) изучение новых концептуальных штук, расширяющих сознание. Первое чаще про синтаксис, и от него пользы мало, если не пишешь свой идеальный язык программирования, которым никто не будет пользоваться. Разве что похоливарить можно.

А вот на втором остановимся подробнее. Я люблю приводить пример, что я стал лучше понимать шаблоны в С++ после изучения Haskell, ведь оказалось, что шаблоны — это всего лишь функции над типами 🙂 Ну и STL стал лучше понимать, ведь он не сказать что очень уж в ООП-стиле. Хаскелем всё не ограничилось, конечно. У меня таких примеров — вагон и маленькая тележка.

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

По-настоящему же я понял, зачем я трачу время на языки с тремя с половиной пользователями после прочтения книги «Seven Languages in Seven Weeks». Например, благодаря изучению Ruby я увидел, как можно делать красивые, как мне тогда казалось, eDSL, и разобрался в метапрограммировании (которое сейчас в основном костыляю в Python). Благодаря io я отошёл от С++-версии ООП и приблизился к оригинальной с месседж-пассингом. Это впоследствии помогло с Objective-C, кстати. Ещё я увидел, что синтаксис может быть суперпростой, но при этом мощный. Благодаря ему же я раздуплился в прототипном наследовании в JavaScript. Лисп мне как-то не зашёл тогда, но не так давно я открыл для себя Red (наследник REBOL) и понял фишечку гомоиконичности. Erlang дал понимание модели акторов. Ну и т.д.

Важный момент: «а зачем учить столько языков, если всё это можно сделать в C++?» — спросите вы. Метапрограммирование/монады/акторы/eDSL/you name it… Я считаю, что это не эффективно. Вместо того чтобы бороться со сложностью и неприспособленностью языка и распылять своё внимание на нерелевантные вещи, я предпочитаю знакомиться с новыми концепциями в их нативной рафинированной среде. Языки приходят и уходят, а ваше понимание концептуальных вещей остаётся. И каждое такое знание значительно расширяет диапазон возможных решений той или иной задачи.

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

Вот бы теперь ещё с менеджментом так же 🙂

Глядите, кстати, чё Страуструп говорит на тему https://youtu.be/NvWTnIoQZj4

Есть стойкое ощущение, что некоторые коллеги на работе регулярно пользуются этим сервисом на митингах 🙄 https://zoomescaper.com/

Небольшой вводный пост по теме, на которую мне есть и ещё будет, что сказать.

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

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

Большинство программистов не могут друг с другом договориться, как класс назвать, не то что каким-либо образом самоорганизоваться и принести тот самый мифический велью. К счастью, не все такие. Есть и те, кто умеет коммуницировать с людьми и знает, куда приложить свою инициативность и как организовать работу. Такие инженеры часто, сюрприз-сюрприз, становятся менеджерами! И по итогу только коллаборация обоих лагерей повышает шанс лодки добраться до берега. Обе роли важны.

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

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

(Сча бы в комменты насрать что-то типа «все вы, менеджеры, так говорите», да? 🙂)

Из всех языков программирования, что я пытался учить, хуже всего мне поддаётся Prolog.

Это очень интересный язык логического программирования, оказавший немалое влияние на индустрию в своё время (вплоть до того, что синтаксис Erlang очень похож на синтаксис Prolog, так как первый интерпретатор был написан на нём).

Основных проблем в его изучении две: 1) я никогда не уделял ему достаточно времени, потому что редко мог придумать практическое применение; 2) источников информации не так-то и много. Я предпочитаю учить по книгам, и с ними как-то вообще тухло. А все статьи по прологу начинаются и заканчиваются определением того, чей там кому батя Сократ.

Осознанных подходов к его использованию у меня было три, и все они связаны с попытками решить головоломки в компьютерных играх, над которыми мне было западло думать самостоятельно. Первая была давным давно в какой-то из частей «Нэнси Дрю» и чем-то напоминала судоку. Вторая была в прошлом году в «We Were Here Together» — там мне просто не хватило мозгов описать концептуальную модель задачи синтаксисом языка. Третья была буквально на днях в «Dishonored 2» и являлась вариацией т.н. «задачи Эйнштейна». Я потратил полтора часа, чтобы вспомнить синтаксис, все эти темы с унификацией и т.п., описать факты и предикаты для задачи и получить на выходе false вместо списка, кто там где живёт и чем бухает 😂 Не хватило знаний/опыта, чтобы правильно увязать эти предикаты воедино. Стоит ли говорить, что во всех трёх случаях жена находила правильный ответ на листочке бумаги гораздо быстрее и безо всякого программирования.

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

Если вы шарите Prolog и можете подсказать, с чего и как лучше начинать, напишите мне плз.

Наткнулся на yet another ФП язык, компилящийся в JavaScript — Clio. Сам по себе он не примечательный, и если сегодня о нём узнают, то завтра забудут. Интересно тут другое.

Можно сколько угодно стебать хипстеров-миллениалов, которые ежедневно переизобретают давно существующие вещи и суют свой JS везде, но есть у них одно преимущество: в отличие от «дедов» они умеют сделать красиво и зачастую удобно. То и дело цепляю какие-то микроидеи.

Посмотрите на скрин: у бинаря, которым представлен язык, есть отдельная команда highlight, которая выводит код в терминал с подсветкой синтаксиса! How cool is that‽ Вроде такая мелочь, а приятно 🙂

Как там у вас, сишники, код без ньюлайна в конце файла уже компилится?)

Зацените. BMW продемонстрировала свою новую инфотейнмент-систему iDrive 8. Из промо-ролика наверняка понятно только одно: по ходу Microsoft поделилась с ними контактами студии 3D-шников и моушн-дизайнеров 🙂

Вот ещё из презентации (красным дописал начало фразы).

so informational much density wow

Окунаясь в управленческие темы, я обнаружил забавный и вроде как очевидный эффект, который ранее мне таковым не представлялся:

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

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

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

Моих знаний мало, опыта у меня мало — и всё же это в разы лучше, чем было! Если вы инженер, но ещё не начали интересоваться подобными вопросами, то самое время озаботиться и потенциально получить нехеровый буст в карьере (даже без смены роли).

Слава Microsoft Excel никому не даёт покоя вот уже 35 лет, так что постоянно ведутся попытки сделать что-то похожее, но лучше или хотя бы по-другому. Всяких разных табличных процессоров я видел немало, но вот лучше — всё ещё ни одного.

Держите тем не менее очередной вариант на Haskell. Надеюсь, там можно делать полиморфизм на уровне таблиц, иначе комьюнити не оценит 😁 Вот сайт: https://inflex.io/

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

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

Одной из таких моделей является 8-шаговая модель Коттера по ускорению изменений. Вот официальный сайт: https://www.kotterinc.com/

Я узнал о ней в районе 2018–2019 годов на тренинге и с тех пор время от времени вспоминаю и рефрешу знания. Многие люди, когда пытаются что-то изменить (в процессах на проекте, в архитектуре в коде, где-либо ещё), начинают с формирования и попытки донести свой вижн другим. Да, в каких-то случаях это работает, но модель Коттера расценивает это как аж третий шаг! И надо сказать, с прохождением первых двух у меня стало получаться и впрямь лучше.

В общем, ознакомьтесь. Пригодится, ей-богу.

Держите PDF-ку заодно

На прошлой неделе по твиттеру пролетел скрин с башорга (да, башорга! господи, он ещё живой…). Люди ломали голову, как же так, зачем и почему в РЖД такой API, пока не появилось объяснение на хабре.

Прежде чем в следующий раз ныть, какая ужасная у вас кодбаза, которой два года, и как срочно нужно всё переписать с нуля, прочитайте этот занимательный экскурс в историю и оцените глубину легаси 🙂

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

Схороню себе сюда ещё одну ссылку, которую, возможно, никогда больше не открою: https://dataflowr.github.io/website/

Тут тем временем язык Crystal 1.0 зарелизился. Выглядит как такой себе статически типизированный компилируемый Ruby, а последний мне всегда нравился в первую очередь приятным синтаксисом.

Я на Crystal не писал и, пожалуй, не буду. Там вон по ходу даже поддержка винды не полная. Не то чтобы это было каким-то шоу-стоппером для меня, так как у меня в ходу девайсы со всеми популярными десктопными операционками (с обеими то есть 🙃), но закладываться на язык без кроссплатформенности в наше время я бы не стал.

Тем не менее, релиз 1.0 — это всегда важный майлстоун для любого языка. Помню, синтаксис Rust до 1.0 менялся чуть ли не каждый месяц; а пока я ждал 1.0 для Nim, успел на него забить. Наверное, и стабильного релиза Red не дождусь 🙁

Девелоперы постоянно ноют про митинги (совещания по-нашему), мол, их настолько много, что работать-то некогда, и они настолько бесполезные, что время уходит попусту.

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

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

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

Вторая проблема побольше: отсутствие доверия и какой-либо обратной связи. Если я не доверяю подчинённому девелоперу или менеджеру, то так или иначе мне придётся его дёргать и спрашивать, как продвигаются дела. Многие даже если уже видят проблему, то ссыкуются сказать, рассчитывая, что ближе к концу оно как-то рассосётся. Не рассосётся! А даже если и да, то можно вообще это выставить как ачивмент 😉 Но чем раньше я узнаю, что что-то пошло не по плану, тем больше у меня пространства для манёвра. И тем раньше я смогу сказать своему руководителю, чтобы и у него оно было.

Короче, рецепт прост: хотите меньше митингов — сделайте так, чтобы на вас можно было положиться.

-----------------------------------------
Ну и чисто из моего опыта.

Был у меня в подчинении чувак: очень умный и скилловый девелопер, но любил уйти в астрал в поисках идеальной архитектуры, покрывающей 100,1% кейсов. Зная о его склонности оверинжинирить, мы с нашим архитектором и этим типочком проработали дизайн модуля системы без излишеств, но с прицелом на возможное расширение в будущем, и взяли с чела обещание, что именно в таком виде оно и будет заимплеменчено. Работы недели на две и 500 строк кода от силы, ей-богу. Договорились синкаться несколько раз в неделю. Вроде всё поначалу неплохо шло, но в какой-то момент WIP-коммит чел вылить на ревью отказался, мол, чуть надо причесать. В конце концов он его ещё пару месяцев «причёсывал», время релиза наступило, пришлось регрессии гнать — куча ресурсов просрана. До конца этот модуль до сих пор небось никто не понимает. Отличный урок мне вышел. Жаль, что через какое-то время чувак ушёл из конторы; поспешил — мы как раз через неделю собирались его сами выпиздить на мороз.

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

Кажется, появился потенциальный конкурент LaMetric — Tidbyt. Не могу объяснить, почему мне нравится такое дерьмо. Вроде я не большой любитель ретро, но иногда прям любопытные штуки попадаются. Придётся брать™. (Ну, не за двести баксов конечно. За полтинник я б подумал. А пока, как говорится, «скажи мне, кто твой конкурент, и оба идите нахуй»).

Помню, кстати, лет двадцать назад играл в квест под названием «Ядерный титбит». Трэш тот ещё был.

Гифонька

Отдельная ачивка за всратый дизайн гению, который решил что торчащий из задней стенки под прямым углом провод — это хорошая идея