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

Айтишная новость дня на западе сейчас — Apple и Google удалили игру Fortnite из своих маркетплейсов. Формальная причина — Epic не хотят платить 30% от транзакций и тем самым нарушают App Store guidelines.

Драма раскручивается эпичная, Fortnite входит в топ самых популярных игр на этих платформах, у них гигантская аудитория, а Epic очень технично переводит все стрелки на google и apple. Даже иск в суд составили против гугла, поскольку по их сведениям, гугол запретил OnePlus и LG предустанавливать игру на свои телефоны.

Почему-то в области документирования архитектуры совсем всё плохо с автоматизацией. Для программистов есть IDE, системы контроля версий и т.п. А для архитекторов нет ничего. Когда количество архитектурных намерений (я так перевёл термин Architectural decision, слово решение мне в этом контексте не нравится) превышает пару десятков, участники процесса теряют и забывают предпосылки, приведшие к конкретно таким намерениям. А если добавить время, то практически невозможно выяснить, почему было принято то или иное решение в отношении конкретного архитектурного намерения.

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

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

Ограничение — это фича.

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

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

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

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

Система с большим числом независимых степеней свободы скатывается в экспоненциально сложное болото возможностей.

Кто бы знал, как сильно мне не хватает русского перевода слова peer. Без него излагать сетевые/коммуникационные тексты на русском очень сложно.

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

Иллюстрации помогают исключительно автору: чтобы её нарисовать, нужно конкретно хорошо въехать в тему. А вот читатели страдают.

Давно знал, что с единицами измерения в США всё плохо, но не настолько же!

Если коротко: в США действуют два разных фута, один местный американский, другой — «международный». Этот хаос властям надоел и они решили отказаться от местного, но не в пользу метра (что было бы логично), а в пользу «международного» фута. А пока в разных штатах продолжают использовать разные футы. И хотя они отличаются очень незначительно, на больших длинах эти различия становятся заметными.

Сейчас в сети дичайше набирает популярность новая игра Fall Guys. Это очень весёлый и ненапряжный вариант battle royale, с очень простыми и при этом отмороженными правилами. Можете на ютубе посмотреть геймплей, это действительно ад.

Студия, сделавшая эту игру, оказалась совершенно не готова к такой бешеной популярности и у игры часто лагают или совсем лежат сервера — настолько все хотят в это поиграть. Механик в игре предельно мало, порог входа абсолютно низкий, никакого опыта не требуется — идеальная игра для вечеринок. И при этом она вышла только на PC (Steam) и PS4, хотя сам стиль игры идеально подходит под nintendo switch. И тут два варианта: либо студия связана эксклюзивным контрактом с Sony, либо у них физически нет сейчас ресурсов выйти на других платформах.

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

Один из самых прекрасных алгоритмов не только в криптографии, но и вообще, — Diffie-Hellman Key Exchange. Это воистину волшебная и при этом концептуально фантастически простая идея. Я когда впервые про DH прочитал, был буквально в офигении, настолько красиво и просто. И было удивительно, почему же о нём в школе не рассказывают.

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

Люди часто слово «нормальность» понимают неправильно. Нормально — это вовсе не то, что условно хорошо. Нормально — это что общепринято, это проявление реальности.

Заказчик плохо составляет ТЗ? Это нормально! Это плохо, но такова реальности, лучше не будет в принципе никогда.

Программист пишет код с багами? Это тоже нормально.

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

Главная причина, почему я не люблю РУ-википедию, — это её упоротые эстетствующие авторы. Достаточно сравнить статьи из en и ru по математике, музыке, лингвистике итп, как сразу всё становится понятно.

Вот сравните, например, Denotation vs. Означающее. Википедия адресована не упоротым экспертам в предметной области, а массовой публике, и поэтому подобные тексты только убивают интерес.

Росатом рассекретил видео об испытаниях чистой водородной бомбы в СССР в 1961 году:
https://www.youtube.com/watch?v=nbC7BxXtOlo

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

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

“Building your own personal brand is a job and it doesn’t leave much time to build either software or engineering organizations.” // source

Весь нынешний движняк с GPT-3 по духу очень напоминает аналогичную вакханалию в условных семидесятых, когда делали типа «роботов», которые, скажем, готовили еду. По заданной программе рубили ножом что-то на доске, что-то там переносили с места на место, выливали из стакана в кастрюлю итп. Короче, занимались неубедительной лажей. И вот сейчас подняли море хайпа, как GPT-3 научился писать бессодержательные тексты по саморазвитию лучше людей. Офигеть прогресс, конечно!

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

P.S. Это касается исключительно потребителей, производителям пропускать первую реализацию нельзя, так можно навсегда отстать.

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

Обесценивание

Имэджин: вы написали статью или сделали постик в Инсте. Нормальный постик. Тут в комментарии приходит человек, который говорит примерно так:

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

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

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

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

Обесценивание — это именно попытка публично принизить работу другого человека. Там всегда будет всё утрировано, едко, немного с табуреточки. Человек будет всем своим видом показывать, что он умнее и талантливее.

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

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

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

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

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

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

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

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