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

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

Не такую робототехнику мы себе видели, наверное.

"Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them"

- Frank Herbert, Dune

*Об обучение разработке*

Вопрос обучения инженеров на работе всегда подразумевается. Конференции, воркшопы, какие-то публичные мероприятия всегда подаются как возможность не терять квалификацию. Очень многие компании презентуют свою hr-политику как терпимую к обучению сотрудников (тут шутка про то, что Яндекс -- одна из самых крупных компаний, напрограммированных джунами)

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

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

Считаете ли вы, что это нечестно по отношению к людям и другим игрокам рынка? Может быть, и да, ну и что? Мы будем так делать, пока мы можем так делать.

Я редко репощу, но в этот раз оно того стоит, почитайте. И по ссылкам сходите тоже

Почему IT-шники в России лишены возможности зарабатывать по-настоящему большие деньги?

Эта мысль является логическим продолжением моих постов о венчурном рынке в России. В одном я объяснял, что главная причина спада в секторе стартапов - это падение реального спроса в экономике 6 лет подряд.

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

Вся эта система в итоге лишает российских разработчиков реальных сверхприбылей. Дело в том, что специалисты с 8-10-летним опытом, те самые сеньоры, к примерно 30 годам сталкиваются со стеклянным потолком. Зарплата не растет, поскольку уже особо некуда повышать производительность труда, а значит и оправдать очередное повышение зарплаты не получится.

В этой точке карьеры у сеньора есть 3 пути, если хочет продолжать повышать свой доход:
— стать менеджером и перестать развивать технические навыки;
— стать стартапером и опять же, по большей части, перестать развивать свои технические навыки;
— уехать из страны и устроиться в стартапы с потенциально большим опционом.

Как видите, все 3 варианта приводят к потере технического специалиста для  экономики страны.

Но на растущих рынках из этой ситуации есть простой выход: опционы. Ключевые специалисты могут получать долю в компании, которая со временем, если компания растет, становится очень дорогой.

Допустим, сеньор присоединился к молодой IT-компании и стал ее 20-ым сотрудником. Он может претендовать на 0.1% от доли ее акций. Его средняя зарплата будет 6 тысяч долларов в месяц. При этом спустя 5 лет его доля от компании может стоить 5-10 миллионов долларов (при оценке компании в 5-10 млрд. долларов), что не идет ни в какое сравнение с зарплатой.

Конечно, не каждый специалист сходу получает опцион и не каждая молодая компания становится единорогом. Тем не менее, на Западе живут десятки тысяч высококлассных технических специалистов, которые смогли «окешить» свой опцион.
То есть, опционная программа сама по себе является ответом на вопросы: что делать после 30? Как поднять свой доход и продолжать развивать свои технологические навыки?
И она прекрасно работает. Есть тысячи историй разработчиков, которые стали мультимиллионерами и не меняли рода своей деятельности (не становились менеджерами или стартаперами).

В России же опционная программа существует в крайне ограниченной форме. Реально перспективных стартапов почти нет, крупные компании по типу Mail, Яндекс, Сбер откровенно зажимают возможности для получения акций сотрудниками.

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

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

Молодой Senior либо выбирает эмиграцию, либо становится менеджером, либо открывает аутсорс-агентство с расчетом на Запад.

В любом случае, экономика теряет потенциально очень дорогого технического специалиста.
А сами эти специалисты, в свою очередь, сталкиваются со стеклянным потолком. Когда вроде зарплаты высокие (относительно остального населения страны), но без потенциала стать мультимиллионером, который есть на Западе.

@tgldoc

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

Если не встроили, или не повлияло на воспроизводство, или это не инновации (изобретение, доведенное до обеспечения новых потребительских свойств) -- значит, это не цифровизация в полном смысле.

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

Если бы заказчику было интересно мнение разработчика о том, ЗАЧЕМ и какую проблему надо решать на самом деле, он бы не нанял CPO, проект-менеджера, продукт-оунера, скрам-мастера, тим- и тех-лида и UX-дизайнера

За последний десяток лет под лозунгом кроссплатформенного нативного UI этот самый нативный UI похоронили, и притащили веб и Электрон, и непонятно, очнётся ли native или нет. На десктопе он пока даже не делает попыток, на мобильных устройствах как-то еще трепыхается, то Native Script вылезет, то Flutter, то Kotlin.

Между тем, такой кроссплатформенный native UI давно существует, и называется X Window System

*Про ответственность*

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

Это так не работает.

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

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

А вверенную снежинку можно мотивировать, а можно и с локтя, или коленом под зад, если это пойдет на пользу делу. Никакой ТАКОЙ ответственности перед снежинкой у руководителя нет.

Мне пеняют, мол, я совсем не люблю разработчиков. Нет,я их совсем люблю! Что касается разработки и инженеров, то это -- самые вовлечённые, честолюбивые и профессиональные юниты. А вот какая на самом деле есть проблема, пишу.

Я за свою недолгую профессиональную жизнь успел поработать с некоторыми смежными областями –логистикой, здравоохранением, ГИСами, учётом МТР – и нигде я не видел управленческого упадка такой степени, как в этом нашем ИТ.

Начиная от тимлидов, которые "а теперь ты ещё и менеджер, бро!", заканчивая "менеджерами" по "продукту", которые вообще не могут выразить словами, зачем их взяли. Какие претензии могут быть к программистам, делающим "не то", если "то" никто не может даже сформулировать?

Все это сверху щедро присыпается инвесторскими деньгами: цветет даже палка, если ее воткнуть в эту землю. Может, в этом и проблема?

https://cloud.gov/ Разработка и хостинг для госов США работают не на Кубернетесе, а на CloudFoundry. Удивлены?

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

В Уставе первой главой должно быть обучение текстовому мышлению (или хотя бы инструкции или ссылки на). Куча программистов не умеет связно выражать смысл в тексте. Речь не про чатовые помойки, конечно, а про внутреннюю переписку и документацию. И ведь программистов нигде этому не учат!  И не путайте этот навык с гуманитарным словоблудием, это дело нехитрое, уже роботы освоили генерацию малоосмысленного многословного бреда в промышленных масштабах. Кто-то считает, что тут врождённый талант нужен, но я считаю, что самым базовым основам связного изложения мыслей можно любого программиста научить.

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

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

А ещё нужно программистам объяснять, что помимо них есть и другие подразделения, с которыми нужно эффективно работать. И ещё непонятно, кто важнее для компании: DEV или QA. Отдельно каждый айтишник должен понимать, как компания занимается продажами и как работает с клиентами на уровне технической поддержки. Всех деталей знать не нужно, но общие понятия — обязательно.

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

Об исполнителей и руководителей

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

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

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

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

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

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

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

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

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

Фулл-стек матрос
(https://www.facebook.com/michael.doroshenko1/posts/10220299405253911)

— Почему вы хотите работать палубным матросом именно на "Мести рекрутера Веры"?
Я вытянулся в струнку и заученно (в каждом порту работодатель обязательно задаёт этот вопрос) ответил:
— У вас прекрасная команда и корабль собран по последнему слову техники, это возможность получить полезный опыт и навыки, и я хочу быть частью вашей миссии своевременной доставки пассажиров по всему миру.
— Кем вы видите себя через пять лет?
"Кормом для рыб", хотелось ответить мне на второй набивший оскомину вопрос, но, увы, пришлось сказать, что я прежде всего хочу стать очень профессиональным палубным матросом, и уже потом смотреть, куда приведёт меня карьера — может, вперёдсмотрящим, а, может, и боцманом.
— Что ж, кажется, мы можем взять вас с испытательным сроком в качестве фулл-стек разработчика.
— Кого? — переспросил непонятное слово я.
— Палубного матроса. Вы же на эту должность обращались? Что за странная потеря слуха?
— Извините, послышалось что-то другое.
***
Корабль был... монументален. Борт вздымался над причалом на три десятка человеческих ростов. Поднявшись на него, я увидел боцмана, который пробурчав что-то непонятное, кивнул на доску, закреплённую на одном из бортов, сказал:
— Я там кинул тебе в спринт пробные задачи, осваивайся. Если что-то непонятно, спрашивай.
"Спринт?"
Непонятного было много. Почему задачи написаны на доске, а не выкрикиваются боцманом, почему на такой огромный корабль только одна мачта, почему я продолжаю слышать какие-то непонятные слова...
***
Постепенно я разбирался. Научился самостоятельно отмечать на доске, что я взялся делать задачу. Понял, что это не корабль, а целая система кораблей, закреплённых концами в одно целое, несущих часть парусов на себе. Это, кстати, было очень странно поначалу, но я научился быстро и непринуждённо прыгать с борта на борт, выполняя разные задачи, менять схему соединения вспомогательных корабликов, а однажды вообще собрав из досок нечто неприглядное, спустил его на воду, сделал на нём высокую мачту и оборудовал там пост вперёдсмотрящего, и тот гордо перешёл с мачты главного корабля туда.
— А как мы будем держаться в шторм? — спросил я у боцмана как-то. — Ведь кораблики будут стукаться друг об друга, если там гибкое соединение, а жёсткое соединение вообще сломается. Схема, когда каждый гребец сидит в своей вынесенной за борт капсуле тоже не кажется мня такой уж надёжной.
— Не трусь, матрос! Мы постоянно проводим нагрузочное тестирование, и результаты обнадёживают.
Я уже привык к тому, что постоянно слышу какие-то непонятные слова, и не стал переспрашивать, догадываясь, что услышу, что они время от времени заводят наш корабль в специальный водоём, где за деньги тысяча индусов бьют по воде палками, имитируя шторм.
— Как там твоя задача по замене тросиков на двойные с автоматической проверкой, что трос привязан к нужному кораблю? Мы тут в следующем порту берём на борт первую группу пассажиров, пора бы доделать.
— Работаем!
— Обнови оценку в Джире, пожалуйста.
Это непонятное слово я уже точно ассоциировал с доской, где боцман и капитан записывали задачи.
***
Это была катастрофа.
Пользователи (тьфу, сам заговариваться начал, пассажиры) изменили осадку кораблей, и те совсем не так держались на воде. К тому же прыгать с корабля на корабль, когда палуба постоянно уходит из-под ног, оказалось очень сложно, а это приходилось делать постоянно, потому что столовая была вынесена на отдельную лодку, то же самое с туалетом, библиотекой (без которой многие пассажиры не мыслили дальнейшее плавание), и много ещё чем. А пассажиров было много...
Ветер дул беспощадно, море разыгралось не на шутку, многие жёсткие соединения треснули, а тросы угрожали разорваться. Вперёдсмотрящий не всегда мог докричаться до рулевого. Впервые за всю карьеру мне было страшно. Вместе с остальными джуниорами я затыкал пробоины в трюме. Капсулы с гребцами постоянно смывало за борт, капитан с криком "перезапустить сайдкик" дёргал рычаг, выпускались новые капсулы, гребцы прямо из воды забирались в них и начинали грести дальше.

Раздался страшный треск и выворотив пару досок на главном корабле упала мачта. С непонятной руганью про "настройки ДНС в Кубернетес" капитан поставил несколько механиков на плечи друг другу и сказал что-то вроде "девопсы, прописывайте айпи вручную, пока не разобрались", убежал в трюм грести лично. Мы полезли натягивать импровизированный парус из своих тельняшек на эту импровизированную мачту. Механики, которых капитан почему-то назвал "девопсами", старательно держались друг за друга и удерживали парус.
***
— Матрос, можешь откатить свою фичу с прода? — услышал я голос капитана из трюма.
Ситуация не располагала переспрашивать, и надо было соображать.
— Исполняю, капитан!
К тому моменту рядом с девопсами уже был поставлен вертикально выломанный борт, парус перенатянули на него, а девопсы-механики разбежались чинить рулевые плоскости.
На этот бортик я и закрепил место для вперёдсмотрящего, и попрыгал с корабля на корабль, разыскивая место, куда я вынес его два спринта назад. Там его почему-то не оказалось, и пришлось лезть по вантам на первую попавшуюся мачту, в надежде увидеть его. К счастью, он был всего лишь за два корабля отсюда, и мне удалось докричаться. Кивнув, он полез на старое место самостоятельно.
***
Над головой был белый потолок, вокруг — белые стенки, я был привязан, а за стеной кто-то обсуждал меня.
— Курс азалептина даёт неплохие результаты, и он уже начинает видеть реальный мир, — незнакомый голос продожил, — но всё же забирать его отсюда еще нельзя.
— Но он очень нужен в проекте! У нас не хватает рук, можно ли как-то ускорить выздоровление? — а вот этот голос я знал. Это был боцман.

*** #вакансии ***

Открыты вакансии фронтенд-разработчиков (разного уровня) в компанию-разработчик финтех- и платежных решений (не аутсорс).

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

Требования — рады разработчикам разного уровня, от "только-еще-вчера-джун" до "22-летний сеньор":
- хорошее знание TypeScript, HTML5, CSS3
- кроссбраузерная верстка (научим)
- понимает, как работает сеть и браузер (прикладной уровень): DNS, вебсокеты, server-side event, кеширование
- не любит REST, но умеет им пользоваться
Знание Angular или Vue, опыт работы c JWS, JOSE, OAuth2.0 -- плюс.

Вакансия для тех, кто засиделся дома: команды сидят в просторном офисе в 7-10 минутах от м. Тульская, Москва (но это не категорично), вокруг _всё_.

За сработавшую рекомендацию — бонус.

Для связи писать @meowthsli с кратким резюме.

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

Так вот, в СССР набрали нешуточную скорость в освоении космоса, все для фронта, все для победы, каждый день был на счету.

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

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

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

Это решение определило отставание в космической сфере на многие годы: первая нетермостатированная платформа российской разработки появилась только в конце 90х-начале 200х. Рефакторили легаси больше 40 лет, вот так-то.

Остальной мир было уже не догнать...

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

Об Котлин

Я как всегда, со своим непопулярным мнением. Мы разрабатываем на Java, ну и периодически к нам заносит веяние, а почему бы не попробовать писать на Котлине?

Мое мнение -- решение ужасное в перспективе нескольких лет и стабильной компании. Реально, просто стрёмно:

- Одна не очень большая контора делает компилятор. Спецификации языка нет. Компилятор как будто в паблик домене, но коммитит туда только ДжиБи, больше никто. Если внезапно ей что-то надоест, все пойдут лесом.
- Контора эта не JSC, а llc (Sro), делает, что хочет, 100% частного владения.
- У господина Бреслава, главного инженера, фляга булькает, через что понесло его в психотерапию и предпринимательство, к которым наблюдаемый интерес даже больше, чем к Котлину.
- (Лень приводить ссылки, их можно отыскать) Компилятор Котлина заметно медленнее javac, ejc, graal, и местами генерирует код хуже в два-три раза по аллокациям и размеру байткода. Это не так чтобы критично, но имхо является некоторым говорящим показателем.
- К сожалению, резюме и вакансий так-то раз в сто меньше, чем по java, особенно если не в столице.
- Если у вас есть аттестация по безопасности, с серьезным обследованием, то могут возникнуть справедливые вопросики.

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