О блоге

Более двадцати лет я занимался разработкой ПО, в основном как программист и тим-лид, а в 2012-2014гг как руководитель департамента разработки и внедрения ПО в компании Интервэйл (подробнее на LinkedIn). В настоящее время занимаюсь развитием компании по разработке ПО stiffstream, в которой являюсь одним из соучредителей. Поэтому в моем блоге много заметок о работе, в частности о программировании и компьютерах, а так же об управлении.

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

[life.photo] Характерный портрет: вы и ваш мир моими глазами. Безвозмездно :)

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

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

[quote] В склерозник: разница между мастерством и искусностью по версии Сирила Паркинсона

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

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

И тут вы должны задать себе фундаментальный вопрос: что такое искусность и мастерство? Чем эти качества отличаются одно от другого? Как заурядный служащий подымается наверх? И есть ли у него такая возможность?

Прежде всего - чем характеризуется мастерство? Умением сделать что-нибудь достаточно сложное. А искусность - это умение сделать что-нибудь сложное чужими руками. Музыканту достаточно его мастерства, дирижеру нужна еще и искусность.

Думаю, что тем людям, которые сейчас стоят перед решением продолжать ли им совершенствоваться в своей профессии или же идти в менеджмент (а это уже подразумевает переучивание на другую профессию) стоит ответить самим себе: что для вас важнее? Совершенствование вашего мастерства? Желание стать искусным?

[prog.c++.flame] Увидел на Хабре код, от которого меня лично слегка передергивает

Заглянул на Хабре в статью "Оптимизация GUI на Qt" (сам не знаю почему, т.к. на Qt уже очень давно не программировал). Увидел там пример кода... Это как раз образчик кода, от которого меня передергивает после многих десятилетий в программизме и опыта приведения в чувство чужих копролитов.

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

[prog.management] Утащу к себе текст чужого поста из LinkedIn. Про влияние удаленки на проектные команды во времена COVID-а

Текст найден в LinkedIn вот здесь: цинк. Автор процитированного ниже Константин Владимиров:

Журнал Nature опубликовал прекрасное исследование об эффектах удалёнки. Исследовалось примерно 70000 сотрудников Microsoft.

The effects of remote work on collaboration among information workers

Там аккуратным научным языком изложено всё, о чём я кричал с 2020-го. Удалёнка имеет тактические плюсы, но за коротким подъёмом продуктивности следует спад коммуникации, дробление команд и потеря связности коллективов. После чего -- долгосрочное падение продуктивности.

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

Допустим у нас есть 60 человек разбитые на 6 команд по 10 человек (скажем три команды разной разработки, а также валидация, аналитики, инфраструктура). Тогда при переходе на удалёнку вы через год получите примерно такой эффект:

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

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

---

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

[work.open-source.anger] А давайте подсчитаем чужие деньги или почему не стоит смотреть зубы дареному коню

По случаю тяпницы позволю себе тригернуться на комментарий к последней статье о SObjectizer на Хабре. Вот этот комментарий:

Ещё б документация была б хорошая, а не вот это месиво доксигена. Ну и в туториалах на gh кросс-ссылки и вычитку английского, а то встречаются там местами штуки типа "бесплатных функций" (free functions).

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

[work.self.promotion] Опытный велосипедостроитель открыт для заказчиков из РБ/РФ

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

И постоянно строил велосипеды, которые тут же шли в работу. За счет чего приобрел специфический опыт и навыки.

Не претендую на роль терпеливо разгребающего таски из JIRA разработчика. Как и на роль архитектора, рисующего UML-диаграммы больших систем. Наверняка есть более подходящие кандидаты, которые любят, умеют и стремятся делать именно это.

А вот если вам нужен программист-камикадзе с нестандартными идеями чтобы соорудить велосипед на котором можно ехать быстрее/безопаснее/комфортнее... Таковым могу быть я.

Открыт для предложений в виде контракта между заказчиком и СтифСтрим. Варианты войти наемным сотрудником в штат клиента на данный момент не рассматриваются.

С получением денег из-за рубежа у нас в РБ сейчас все не очень гладко, поэтому наиболее интересны заказчики из РБ/РФ.

Связаться со мной можно через eao197 на gmail тчк com. Если кому-то интересен профиль на LinkedIn, то вот.

---

Дабы не быть голословным по поводу опыта создания велосипедов вот несколько примеров "из недавнего":

• timertt. С++ библиотека для поддержки таймеров. Реализует механизмы timer_wheel, timer_list и timer_heap. Позволяет поддерживать большое количество (миллионы и десятки миллионов) активных таймеров. С 2014-го года используется в SObjectizer.
• so5extra. Набор прибамбасов для SObjectizer-а, вроде дополнительных типов диспетчеров, mbox-ов и пр.
• easy_parser в составе RESTinio, который представляет из себя реализацию PEG-парсера на С++ных шаблонах и constexpr-функциях (в рамках C++14) Подробнее в основной документации или вот этих статьях: раз и два.
• MxxRu::externals. Велосипед, который мы с 2016-го года используем для управления зависимостями в собственных C++-проектах. В отличии от conan, vcpkg и пр., он не требует предварительного опакечивания зависимостей. Ознакомиться можно здесь или здесь. Кстати говоря, MxxRu -- это также мой старый собственный велосипед (документация здесь).

Упомяну также arataga. Хоть это и не инструмент для разработчика, но лисапед, сделанный практически в одиночку под специфические условия.

Кому-то я известен по проектам SObjectizer и RESTinio. Эти все создано с моим непосредственным участием и под моим руководством.

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

---

Буду признателен, если вы сможете поделиться ссылкой на этот пост в своих соцсетях и/или распространить среди своих профессиональных контактов.