Естественно — иначе ж мы слона не продадим. К кому пойдёт клиент — к Васе Пупкину, который нарисует красивую диаграмму Ганта, или к вам, кто скажет правду — дорогой клиент, хер знает сколько твой проект будет стоить, и хер знает когда мы его закончим? Коммерческий выбор очевиден.

Объясняю для тех, кто не понял.

Планирование (вообще чего угодно) базируется на двух аксиомах:
1) мы откуда-то знаем, сколько займёт каждый этап
2) каждый этап в реальности займёт столько, сколько мы предположили.

Это прекрасно работает в производстве, например в конвейерном машиностроении, или в строительстве.
Благодаря чему это работает?
Благодаря тому, что все операции — нормированы. Вы провели ряд измерений и знаете, что сделать болт из заготовки занимает N секунд. А прикрутить этим болтом один кусок металла к другому — занимает M секунд.

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

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

Уютная IT-шечка устроена так, что люди не выполняют одинаковый проект более одного раза — они всегда идут на повышение или переходят в другую компанию, чтобы там было интересно пощупать что-то новенькое. За исключением откровенных задротов платформы 1С и прочих галер на битриксе, где из года в год мусолят одно и то же под каждого очередного заказчика, любой нормальный человек в нормальном проекте в вашей команде будет делать своё дело ВПЕРВЫЕ.

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

Поэтому бл*ть какое в жопу планирование. Вы айтишники в 99% случаев встаёте перед лицом вопроса, который вы не решали никогда в жизни. Ну, может быть, кто-то в команде и решал — но на десятикратно меньшем масштабе, совсем на других данных, другом фреймворке и в другой индустрии. Как вам это поможет? Ну советы какие-то даст, а потом вы пойдёте и всё равно будете копать от забора до обеда.

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

FB Grigoriy Dobryakov

www.techspot.com

Can GenAI Actually Improve Developer Productivity?
Uplevel Data Labs analyzed the difference in key engineering metrics across a sample of 800 developers before and after GitHub Copilot access. The findings tell a different story from what devs report in surveys.

uplevelteam.com

Wikipedia, 0.2 MB
Zoom, 6 MB
Gitlab, 13 MB
YouTube — 12 MB
Pornhub – 1.4 MB
SoundCloud – 12 MB
Google Mail – 20 MB
Dropbox – 10 MB
Trello – 13.5 MB
Google Docs – 13.5 MB
Twitter – 11 MB
Jira – almost 50 MB
Slack – 55 MB
… jQuery.com – 0.1 MB

How fast are we degrading?

Look how cute! In 2015 average web page size was approaching shareware version of Doom 1 (2.5 MB)
Well, in 2024, Slack pulls up 55 MB, the size of the original Quake 1 with all the resources. But now it’s just in JavaScript alone.
For a chat app!

Инстинктивные страхи что числовой инкрементный ID закончится не редки среди программистов.

Ну ок
serial 4 bytes autoincrementing integer 1 to 2_147_483_647
bigserial 8 bytes large autoincrementing integer 1 to 9_223_372_036_854_775_807

Восходящая разработка

На самом деле, восходящий способ еще древнее нисходящего. В 1950-х уже существовали и Фортран, и Кобол, но не было ясных представлений, как строить софт. Поэтому поступали самым естественным образом: сегодня сделаем одно, завтра другое, потом когда-нибудь склеим в третье. Если нужно реализовать несколько задач, то выбираем наиболее важные.
…
Иногда способ также называют инкрементальным, видимо, по аналогии с i++. Добавили функцию — инкремент.
…
Способ также любят изображать в виде цикла, хотя для i++ не определены конечные значения, поэтому “копать” придется “отсюда и до обеда”. Продолжая тему русских пословиц, есть у нас поговорка “крутится, как белка в колесе” — вот это как раз про восходящий способ.

Методика была и остается наиболее характерной для домашних (in-house) разработок. Свои программисты должны делать то, что нужно для бизнеса еще вчера. Чтобы думать о более глобальном, в 1960-х появились “софтверхаузы” — крупные проектные конторы по разработке заказных систем, включая таких монстров, как IBM.

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

В 1990-х годах пошел мощный тренд замены “домашних” программистов на внешних консультантов. Одна из причин — усложнение технологий и специализация, труднодостижимая внутри фирмы для которой софтостроение — непрофильная деятельность. Домашний софт теперь разрабатывается временными командами шабашников контрактников.
Изменились отношения, а заказчик — не спец во всех этих методологиях, анализах, архитектурах. Заказчик в лучшем случае знает, в чем отдельные проблемы и может расставить над ними приоритеты.
Команда контрактников в свою очередь, не знает о бизнесе заказчика достаточно, чтобы cпланировать всю реализацию.

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

Спрос рождает предложение, к концу 1990-х появились так называемые проворные agile методы, худо-бедно позволявшие заказчику держать руку на пульсе, а подрядчику постепенно понять, что, собственно, они реализуют.

Что улучшилось:

• планирование по-прежнему короткое, но охватывает не одну функцию, а их группу при этом срок этапа жестко ограничен;
• ведется протокол сделанного;
• теоретически, должно выделяться время на упрощение и чистку кода (рефакторинг);
• теоретически, риски регрессии должны парироваться всеобъемлющими тестами.

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

Дублирование кода, ненужные усложнения, отложенные “на потом” неэффективные реализации — если вовремя не разгребать сделанное ранее, то растет технический долг. Чем позже долг возвращается, тем больше в итоге приходится платить: временем, человеко-днями, ошибками, сбоями, медленной работой и т.п.

Спустя каких-то 10-15 лет авторы “Манифеста аджайла” начали бить в набат: “Ребята, что вы делаете, мы имели в виду другое”. Они в чем-то правы, восходящая разработка так проста и тем притягательна, что все эти дополнительные процедуры кажутся необязательными.

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

Проблемы, как и в случае с “водопадами”, принципиальные.
Проще управлять процессом, но практически невозможно — конечным результатом, так как он нигде четко не фиксируется.
Риски перекладываются на заказчика: пускай владелец продукта думает, у него башка большая.
Если с технической архитектурой при наличии опыта, тестов и рефакторинга команда справляется (до определенного порога сложности), то с архитектурой функциональной дело плохо.
Упрощение постановки задачи, тот самый “рефакторинг”, теперь уже модели предметной области, помог бы избавиться от навороченного и дорогого в сопровождении кода, но сделать его некому.
Да и модели-то нет, если честно, вся семантика в головах и в коде.

В виду, опять же, истории вокруг Альтмана и его кибермарксистких друзей, которые оказались не очень друзьями, я смотрю многие начали проявлять экспертизу про “руКовоДСтвО и ЛидЕРСтво”.
И судя из читаемого, выглядит так, что в большинстве голов, условный руководитель С-уровня, это такая смесь спортивного тренера, шамана и человека, обладающего определенного уровня риторикой (пиздабола, да).

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

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

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

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

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

Зачем я это пишу? Несмотря на ворчание, мне несколько прискорбно наблюдать все эти четыре дня за грустными событиями в ОпенАИ и желаю там всем все ж собраться с мыслями.
Людям, рассуждающим про то, как бы они поступили работая в большом С-левеле и будь я Сэмом или его бордом, желаю в этом самом большом С-левеле сначала поработать, а для полноты опыта сравнения с текущими событиями – также попробовать открыть и раскачать 1-2 компании, ну хотя бы до ста человек, желательно их потом продав.

После такого экспириенса, все становится несколько более ну, понятнее что ли 🙂

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

Вот в этом определении архитектуры…
*Архитектура* – это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.

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

Архитектор несет непосредственную личную ответственность не “за систему”, а за продуктивность всех членов команды в их повседневной работе. Его обязанность – усиливать людей, снабжая их необходимыми технологиями для выполнения повседневных задач по проектированию системы. И оказывать им всестороннюю поддержку, если у них будут с этими технологиями какие-либо сложности.

Именно так, и никак иначе. Не придумывать как делать систему под конкретные требования. А давать людям методику (набор правил), руководствуясь которым конкретные эти люди (а не какие-то там абстрактные) смогут проектировать эффективнее.

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

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

Штука в том, что если он мудак – вы к нему просто не придете.

ЗЫ: А мудак – благодаря Стенфордскому профессору Бобу Саттону – теперь вполне научное понятие. Я лично считаю, вся наука организационного поведения давно к этому шла:
wikipedia.org The_No_Asshole_Rule

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

Результатники отлично перформят на фазе MVP (или RnD, называйте как хотите). Короче когда быстро-быстро на пустом месте нужно что-то слепить. И перевылепить, если не взлетело.

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

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

— Каких ещё табуреток?
— Ну ты забыл что ли? Два месяца назад, как раз между лестницами эшера и бутылками клейна было.

И это крах. Как это, табуретки? Как это, 500 синих табуреток к концу спринта? Каждого спринта?

Какое ещё сокращение издержек и оптимизация костов?

Да я вам звёздную команду собрал, вы чё? Они же почти космолёт достроили (ну и пусть что для доставки отходов, но ведь на солнце!), они же после первой партии табуреток поувольняются все?..

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

— Слушай, хорошие табуретки! Для Нижневартовска так просто отличные. Надо идти в другие города.

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

Как ЭТО теперь отмасштабировать?

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

Через год мы имеем 20 филиалов в 20 разных городах, каждый из которых держится на личном героизме участников случайно собранных 20 команд. Которые тоже верят, что строят космолёт, но уже догадываются что на самом деле красят табуретки.

На этом моменте HR головной компании уже давно сидит на седативных.

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

Скорее всего, инвесторам всего этого благолепия какие-то подозрения закрадутся в голову года через два, так что некоторое время всё будет выглядеть нормально.

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

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

Так получилось, что за последние годы я провел собеседования около сотни IT-менеджеров. Естественно, мне самому столько не нужно, я отбираю их в том числе и для других команд. При таких вводных невозможно было бы не выработать какую-то систему. Я научился задавать такие вопросы и в таком порядке, чтобы за час понять максимум о том, к каким процессам привык кандидат, что он о них думает, как изменил бы, будь его на то воля, чем он любит и не любит заниматься, как он общается с людьми, насколько хорошо умеет обращаться с информацией, и, в конечном итоге, сумеет он работать так, как нужно нам, или не сумеет. Если бы я был инфобизнескоучем, я обязательно продавал бы этот способ за деньги на семинарах, но я не бизнесинфокоуч.
…
Последнее, что меня действительно потрясло, это рассказ одного из кандидатов, занимавшегося в организации, которую мы здесь назовём Б, некоторой деятельностью, наполовину продуктовой, наполовину инфраструктурной. Я не хочу выдавать чужие секреты, поэтому давайте ее анонимизируем и, следуя Паркинсону, назовём “адмиралтейской работой”. Представьте себе, например, систему отсылки push-уведомлений; речь шла не о ней, но аналогия достаточно хорошая. Тут в целом есть чем заняться. И тебе база данных, в которой будем хранить, что и кому мы уже отправляли, чтобы избежать дублей, и кто из пользователей отказался их получать в интерфейсе. Причем это чувствительные данные, поэтому структура и доступы должны быть хорошо спроектированы. И тебе realtime-админка, и всякая аналитика и дашборды. И немного продуктово-организационной возни на тему “кто из внутренних подразделений кому из пользователей что имеет право отправлять, чтобы ретивые маркетологи всех немедленно не заспамили”. И чисто продуктовая вида “как бы так дать пользователям возможность что-то тут регулировать, чтобы они понимали, что происходит, и случайно не отключили себе что-то действительно важное”. Всё это довольно скучно, но в общем, понятно, чем тут можно занять команду. В организации, где работаю я, которую мы здесь назовём А, этим (не пушами, а вот этой похожей адмиралтейской работой) занимается команда из 20 с чем-то человек. Я им иногда завидовал: этого количества хватает, они могут позволить себе закрыть весь периметр, тратить время на вещи вроде трехдневных тимбилдингов и хакатонов по рефакторингу, “мыслить стратегически”, в общем. Большими языковыми модельками в организации А долгое время занималось примерно столько же, если не меньше, а, при всем уважении, сложность задач все-таки несопоставима.

Оказалось, что в организации Б адмиралтейской работой занимается 300 человек.

В организации Б триста человек, как оказалось, заняты адмиралтейской работой.

Оказывается, на каждого человека, занимающегося адмиралтейской работой в организации А, приходится 10-15 человек в организации Б.

Понимаете, проводя собеседование, я вдруг узнал, что каждый человек, который занимается адмиралтейской работой в организации А, и, как мне казалось, честно говоря, довольно расслабленно, работает в 10-15 раз эффективней своих коллег из организации Б. Я офигел и с трудом сохранил покерфейс.

Я думал, что обладаю довольно широким кругозором насчет того, как всё устроено в разных организациях (см.выше), но именно этот факт меня потряс. Сотни неглупых, в общем, людей, прошешдих профессиональный отбор, каждый день едут на работу (в среднем 50 минут в один конец), чтобы много часов заниматься чем-то, что доказуемо не имеет смысла. Они проводят собрания, что-то обсуждают, планируют спринты, массажируют бэклоги, собираются на стендапы и ретро. Наверняка у них есть интриги, офисная политика, свои “звёзды”, взлёты и крахи карьер (их же 300 человек, не может быть иначе). Они регулярно защищают бюджеты своего подразделения, и их начальство, руководители многотысячных команд, наверняка неглупые люди, кивают, да, 300 человек вам в самый раз, но вот до 330 мы вас все-таки расширять не будем.

Давайте для простоты примем как аксиому, что работа адмиралтейства в компаниях А и Б не омонимичная, а действительно одна и та же, с очень похожим количеством “фичей” и сопутствующих требований, со схожими масштабами числа пользователей. Я не буду раскрывать детали, но могу сказать, что отличия во всем этом в пределах погрешности, точно не в 15 раз.

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

Но почему? Не оставляет ощущение, что тут должна быть простая отгадка, в одно-два предложения.

Хорошим примером такой мысленной конструкции был бы первый закон Паркинсона: “Работа заполняет время, отпущенное на неё” (полностью – А.П.). К сожалению, он не объясняет феномен полностью, потому что ничего не говорит об отличиях между организациями. А вдруг существует такое же изящное объяснение того, почему в организации Б на эту самую работу отпущено время, эквивалентное сотням человеко-лет (звучит ужасно, если вдуматься: много жизней), а в другой только десяткам (тоже, конечно, такое себе, но уже лучше). Что является первопричиной?

Про большие нагрузки: Не надо следовать за мейнстримом.

Главный вопрос – почему, с какой целью мы это делаем.
Без этого нет понимания DoD.

In some ways, learning to program a computer is similar to learning a new language.

In spite of those similarities, MIT neuroscientists have found that reading computer code does not activate the regions of the brain that are involved in language processing. Instead, it activates a distributed network called the multiple demand network, which is also recruited for complex cognitive tasks such as solving math problems or crossword puzzles.

“Understanding computer code seems to be its own thing. It’s not the same as language, and it’s not the same as math and logic,” says Anna Ivanova, an MIT graduate student and the lead author of the study.

There are two schools of thought regarding how the brain learns to code, she says. One holds that in order to be good at programming, you must be good at math. The other suggests that because of the parallels between coding and language, language skills might be more relevant. To shed light on this issue, the researchers set out to study whether brain activity patterns while reading computer code would overlap with language-related brain activity.

The two programming languages that the researchers focused on in this study are known for their readability — Python and ScratchJr, a visual programming language designed for children age 5 and older. The subjects in the study were all young adults proficient in the language they were being tested on. While the programmers lay in a functional magnetic resonance (fMRI) scanner, the researchers showed them snippets of code and asked them to predict what action the code would produce.

The researchers saw little to no response to code in the language regions of the brain. Instead, they found that the coding task mainly activated the so-called multiple demand network. This network, whose activity is spread throughout the frontal and parietal lobes of the brain, is typically recruited for tasks that require holding many pieces of information in mind at once, and is responsible for our ability to perform a wide variety of mental tasks.

Previous studies have shown that math and logic problems seem to rely mainly on the multiple demand regions in the left hemisphere, while tasks that involve spatial navigation activate the right hemisphere more than the left. Working with Marina Bers, a professor of child study and human development at Tufts University, the MIT team found that reading computer code appears to activate both the left and right sides of the multiple demand network, and ScratchJr activated the right side slightly more than the left.

…a team of researchers from Johns Hopkins University also reported that solving code problems activates the multiple demand network rather than the language regions.

The findings suggest there isn’t a definitive answer to whether coding should be taught as a math-based skill or a language-based skill. In part, that’s because learning to program may draw on both language and multiple demand systems, even if — once learned — programming doesn’t rely on the language regions, the researchers say.

ОК. Википедия, глубже незачем…

Вычеркивается при таком подходе:

Подпроцессы
Процесс разработки состоит из множества подпроцессов, или дисциплин, некоторые из которых:

• Анализ требований → Спецификация программного обеспечения – нафиг оба пункта
• Проектирование программного обеспечения – по ходу слепим
• Программирование – главное таску закрыть и чтобы юнит тесты к ней не падали
• Тестирование программного обеспечения – QA отдел фиксирует баги: отсутствующего кода, который в плане работ через спринт-два
• Системная интеграция (System integration) – девопсы пришли и уже ушли. При этом – на старте их не было, и в конце тоже – придется выбивать, девопс отдел так просто уже их не даст
• Сопровождение программного обеспечения – заключается в прилепливании нового функционала, другими программистами, которые работают по тем же правилам

Еще с википедии:
Барри Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:

• Дефицит специалистов. – не так страшен как отсутствие согласованной работы. Специальные библиотеки, инструменты, написанные специалистами уже обычно есть
• Нереалистичные сроки и бюджет. – потому что эстимейты ставятся от фонаря. По аналогии, которая просто по памяти – потому что программист помнит сколько он подобную таску закрывал – но не помнит сколько времени ушло на заталкивание этого кода в систему.
• Реализация несоответствующей функциональности. – без ТЗ и результат ХЗ: анализ выкинут как немодный
• Разработка неправильного пользовательского интерфейса. – без ТЗ и результат ХЗ: анализ и проектирвоание выкинуты как немодные. А сам UI рисовался веб дизайнером, далеким от разработки (*), со слов представителя заказчика, который самый неосведомленный у заказчика в UX
• Перфекционизм, ненужная оптимизация и оттачивание деталей. – зато на код ревью будет пристально рассматриваться насколько код соответствует “бест практикам”, а QA завернет UI код за 2 пикселя вместо 3ех
• Непрекращающийся поток изменений. – вызван тем что придется постоянно переделывать то что было написано наобум. Напомню: анализ требований →  спецификации → проектирование – пропущены как немодные
• Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. – программисту под видом таски выдается юзер сторя в которой пара предложений. Дальше он додумывает себе в одиночку.
• Недостаточная производительность получаемой системы. – анализа и проектирования не было – соответственно никто и близко не думал об этих проблемах. Которые обычно вызваны получившиейся архитектурой, потоком управления и трансформаций данных
• Разрыв в квалификации специалистов разных областей. – случайно собранные свободные программисты – не команда. Их квалификация становится не важной, потому что писанное ими наобум, без проектирования общей системы – приведет к сборке пазла с неизвестной заранее картинкой и с разных комплектов. И какого качества отдельная пазлинка – неважно

* промышленный дизайн – дизайн учитывающий возможности оборудования, технологий, стоимость ресурсов при серийном выпуске.
в этом главное отличие от просто дизайна как вида изобразительного искусства.
Пример:
Первые цветные ткацкие станки умели работать с 4мя нитями = 4 цвета. Дизайнер узора ткани обязан был учитывать что:
у него есть только 4ре цвета. И такие и таких их оттенков – нити которых распространены и дешевы, если ткань планируется для массового выпуска.
А также должен учитывать разную скорость выцветания цветов, если краска нитей сделана по разным технологиям, чтобы со временем ткань не теряла товарного вида, особенно если данная ткань будет использоваться для выпуска одежды.

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

Идеальный промышленный дизайн для Web UI – не должен требовать переверстки, а тем более переделки логики работы UI или борьбы с выбранным CSS фреймворком.
“Для смены скина – программу не нужно переписывать”

хм, а стоило ли избавляться от:

export class Counter {
    count = 0
    increment() { this.count ++ }
    decrement() { this.count -- }
    reset() { this.count = 0 }

}

Текст найден в LinkedIn вот здесь: цинк.

Автор процитированного ниже Константин Владимиров:

The effects of remote work on collaboration among information workers

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

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

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

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

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

в текущем заказном проекте (в котором мы также работаем по схеме time-and-material) недавно возникла ситуация, с которой мы пока еще не сталкивались. Потребовалось именно что родить идею.

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

На практике это выглядело так: садился с блокнотиком и начинал записывать какие-то мысли по поводу задачи. Первые минут 15 это более-менее получалось. Затем мысли начинали разбегаться кто-куда и еще минут 15-20 я с этим хоть как-то справлялся, возвращая их в нужное русло. Но в последующие полчаса все неизбежно скатывалось в состояние, когда в голове образуется неконтролируемая каша из разрозненных кусочков и обрывков, после чего наступало понимание что все, финиш. Блокнотик откладывался в сторону, а я тратил время на не имеющую отношения к задаче ерунду.

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

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

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

В итоге, на рождение идеи было затрачено чуть больше недели календарного времени. Фактического времени было залогировано 12 часов. На то, чтобы зафиксировать получившееся в тексте и затем дать заказчику необходимые разъяснения ушло 5 часов (все это в течении одного рабочего дня).

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

Фиксировать только время, которое было затрачено на сидение с блокнотиком — это явная работа себе в убыток. С другой стороны, логировать по 7 или 8 часов в такие дни совесть не позволяет, ведь большую часть этого времени я, фактически, бил баклуши и гонял своих собственных тараканов. Да и не хочется провоцировать вопросы со стороны заказчика о том, неужели несколько страничек сумбурного текста потребовали 40 рабочих часов подготовки…

Вот впервые оказались в такой ситуации. Есть о чем подумать.

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

PS. Раз уж пошла такая пьянка, поделюсь еще одним наблюдением. По нашему опыту выходит, что даже когда по заказному проекту идет плотная работа с минимумом задержек и отвлечений, все равно выходит где-то по 110-120 часов на человека в месяц. Максимум. Остальное время либо мы на что-то вынуждены отвлекаться, либо заказчик что-то не предоставил, либо ждем какого-то подтверждения/согласования или доступности чего-то/кого-то, либо еще что-то (типа болезни, мелких форсмажоров и т.п.). Из этого следует то, что нельзя подходить к расчету предполагаемой выручки по формуле Rh*160 (где Rh — это почасовой рейт), в реальности выйдет, в лучшем случае, Rh*120.

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

И речь даже не про ватерфол. В этом контексте итеративность не поможет, так как проблема глубже.

Проблема лежит в том, что у команд разработки «старого» образа мышления всё заканчивается на выходе в продакшен. Ну вы знаете, называется ОПЭ или Прохождение ПиМИ, в общем you name it. Вывод в продакшен — это такой волшебный единорог, который наступает единомоментно, и за ним дальше жизни нет.

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

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

Разработка продукта НАЧИНАЕТСЯ с выхода в продакшен.

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

Всё, что надо сделать до выхода в продакшен — это сцука подготовить самый минимальный бойлерплейт для БЫСТРОЙ проверки гипотез. Настроить процессы CI/CD, подготовить мониторинг, тикетницу, хранилку метрик, движок для A/B-тестов.

Всё! Никакого, сцуко, MVP продукта на 300 лямов и три года человеко-часов. Никакого! Это должен быть настолько low budget, что его вообще не стоит даже указывать в смете. Вся разработка начинается только СЕЙЧАС. Вся разработка — это моделирование и проверка гипотез на ходу, непосредственно в продакшене.

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

Хотите раскрою секрет, как делать нормальные продукты без косяков и в срок даже с небольшой и не супер профессиональной командой разработки? Готовьте попкорн, сейчас в очередной раз наброшу на вентилятор.

Обычная продуктовая разработка (особенно силами подрядчиков) выглядит как стрельба из лука по мишени, которая висит в тумане в километре от стрелка.
Мишени не видно. Аналитики лезут из кожи вон, рассказывая какая она красивая и какие в ней круги все такие концентрические. Продакт менеджер отправился в туман ещё неделю назад, и пока не вернулся. HR-департамент разыскивает стрелка с самым зорким глазом – приходят, правда, бывшие метатели копья, но какая разница, нас устроит знание любого фреймворка. Главный Программист слюнявит палец и приглаживает пёрышки на стреле, живо представляя себе маленький кружок с цифрой “10” в середине.

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

Спустя пару дней из тумана возвращается Продакт менеджер, и слегка изменившимся лицом докладывает, что продакт-маркет фит таки произошёл, но не совсем корректно, а именно стрела попала в задницу главному инвестору. Тот слегка опечален, но по-прежнему выражает надежду на успех проекта.
Аналитики подкрашивают и без того идеально ровные концентрические круги на макетах. HR-департамент уволил всех ниже средней зп по команде, потому что вторую половину страшно трогать. Главный Программист вздыхает и вновь натягивает тетиву…

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

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

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

Невозможно не знать, что она квадратная с десяткой в углу, когда она висит у тебя в метре от носа. Если ты всё равно за*ерачил стрелу в центр, ты же это б*дь увидишь сразу. Сразу!

Принцип критически важного сокращения time2market прекрасно освоили в бизнесе, но почему-то на принцип fast feedback в разработке по-прежнему кладут болт.
Долгая петля обратной связи для программиста – это один из *главных* расходников в вашем бюджете! Почему? Да потому что он уже забыл, чё он там кодил, за то время пока ему фидбэк приехал. 15 минут максимум. Если программер узнаёт, работает ли его фича, позднее чем 15 минут – можете сразу спускать ваши деньги на благотворительность. Вы их туда УЖЕ спускаете.

Во-вторых, сама по себе мишень. Чтобы повесить её перед носом, она должна быть во всех смыслах well-defined. Ха-ха, скажете вы, как же можно define well результат, если его не представляет не то чтобы Продакт менеджер, но и сам Заказчик? Это ты брат покушаешься на основные столпы эджаил-простигосподи-разработки, которые гласят что мы работаем строго по хз пока у Заказчика не кончатся деньги!

Так это бл*ть и есть основная проблема! Проблема не в том, что у вас программисты х*ровые. Проблема в том, что вы НЕ УМЕЕТЕ дефайнить результат по-правильному. Вы фокусируетесь на том, чтобы разрабатывать систему, которая БУДЕТ делать нечто в будущем. Нечто туманное, гипотезу, галюцинацию аналитиков, you name it.

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

Проблема в том, что вы пытаетесь делать продукт, который когда-то в отдалённом времени и пространстве теоретически попадёт в мишень. А надо сначала повесить перед собой мишень, а потом подогнать под неё продукт.

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

Невозможно ошибиться, когда мишень у тебя перед носом. Невозможно написать код, который на вопрос “А” будет выдавать ответ “Х”, если ваш чёрный ящик будет бить программиста электрошокером каждый раз, когда ответ не “Б”. Для этого не нужно брать супердорогих программистов. Да и супердорогих аналитиков, честно говоря, тоже. И супердорогих тестировщиков, внезапно.

Ваша задача, как руководителя всего этого цирка, – сфокусироваться на физическом воплощении результата. Вы должны as soon as possible сделать чёрный ящик – ОТДЕЛЬНЫЙ продукт, который ВЕДЁТ СЕБЯ как целевой продукт. Притворяется им. Да, в продакшене. Не ссыте.
Внутри – кармическая пустота. И затем поручите вашему программисту заполнить эту пустоту.

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

Вот что значит well-defined. Вот на этом должны быть сфокусированы ваши аналитики и вся команда в целом. Вы должны выявить, распознать, и самое главное – ЗАПРОГРАММИРОВАТЬ в вашем чёрном ящике ВСЕ ожидаемые реакции. Пришло “А” – ответить “Б”, пришло “N” – ответить “M”, и так далее.

Вы их нароете, скорее всего, очень много. И в процессе выявления этих реакций вам естественным образом захочется их классифицировать, сократить и упорядочить. Это б*дь и есть работа аналитика! А вы думали, тридцатистраничные ТЗ писать?

Тестировщиков тоже подтяните. Они хоть раз в жизни применят свои классы эквивалентности, о которых все спрашивают на собесах, но никто не видел на практике.

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

Ну а дальше – очевидно. Потратьте полдня, запрограммируйте эти имитации в чёрном ящике, и суньте его в прод. Всем нравится? Работает в соответствии с ожиданиями? Окей, теперь поставьте его перед носом у программиста, и не выпускайте из комнаты, пока его не перестанет херачить электрошокером каждый failed test. Когда перестанет – ваш продукт в точности стал meet requirements. Буквально.

Поменялись требования? Окей, за 5 минут переделайте имитацию в чёрном ящике, суньте в прод, повторите всю процедуру. Meet requirements? Бронируйте столик в баре.

Это называется fast prototyping. И это и есть тру способ изготовления MVP. А вовсе не художественная резьба ножницами по бюджету и скоупу.
Хотя, конечно, годами ковырять продукт в дев-контуре, вечно догоняя невыявленные или изменяющиеся требования, гораздо веселее. Вся команда уже как родные становится. Дружат семьями. А ты, автор, ваще кто такой, чтобы это изменить?

Сегодня хочу поделиться саммари одного из самых интересных подкастов за всю историю подкастов. Йоша Бах (когнитивист, исследователь) + Лекс Фиридман. 2 части (в сумме более 6 часов).
Я, наверное, раз 5 пересушивал первую часть и каждый раз находил в ней инсайты, новые грани и оттенки смысла. Вторую часть я пока прошел наполовину и она не уступает первой. Йоша умеет максимально емко и точно использовать слова и метафоры для описания крайне сложных и контр-интуитивных концепций.
🔗 Интеллект
Интеллект — это способность видеть паттерны.
Чем сложнее паттерны мы можем видеть, тем “выше” у нас интеллект.
Чтобы видеть паттерны, нужно уметь строить модели мира.
Мы строим модели нашего дома, поведенческие модели людей вокруг, модели биологических и экономических взаимодействий. В конечном итоге: всей вселенной.
В отличие от других живых существ, модель мира человека включает его самого. В моей модели мира присутствую Я как субъект, все остальные модели выстраиваются относительно этого Я. Когда AI научится делать так же, возможно он обретет некую форму сознания. Но это не точно…
👾 Реверсивный тест Тьюринга
Формулируется так: достаточно ли мы интеллектуальны, чтобы понять как мы устроены и воссоздать себя (сознание) на другом носителе.
🎱 Сознание
Сознание — модель содержания внимания. Функция сознания: оно дает нам возможность учиться. Люди учатся через направление внимания и взаимодействие с индексной памятью. Сознание — это возможность и способ управлять своим вниманием, фокусировать его на чем то. Сознание — это мета-внимание: направление внимания на внимание к чему-то (в мире или в памяти).
Можно дополнить: сознание — это в некотором роде механизм коррекции ошибок. Пример здесь — оптические иллюзии. Когда мы видим иллюзию — наш мозг как бы обманывает вас. Но сознание помогает нам детектировать этот обман, ошибку и скорректировать ее, например, путем несложных измерений.
Еще один фрейм: сознание — это история, которую наш мозг рассказывает сам себе.
👁 Симуляция
Мы не взаимодействуем с физической реальностью. Физическая реальность — странный квантовый граф. Мы взаимодействуем с “виртуальной реальностью” симуляцией, созданной нашим мозгом. Мы видим цвета, слышим звуки, чувствуем запахи. Все это наш мозг создает для нас по мотивам той “мистической” реальной реальности.
🥚 Идентичность
Я — это софт, который работает на харде биологического существа, довольно похожего на обезьяну.
Идентичность — виртуальный концепт. Мы конструируем нашу идентичность. При этом есть множество способов конструирования. Здесь интересен кейс Далай Ламы. Далай Лама — идентифицируется как форма управления. Далай Лама — не человек, это по сути политический софт, который запускается на человеческом харде. Поэтому Далай Лама способен к перерождению. Каждое перерождение — новый “инстанс” того же самого софта. В каком-то смысле, если вы отпечатываетесь в сознании других людей — вы не умираете. Умирает только конкретный “инстанс”, на котором вы сейчас запущены.
🌍 Frame of reference
Скорее всего в нашей вселенной есть “сущности”, которые гораздо более совершенны и “интеллектуальны”, чем мы. Только эти сущности оперируют на других масштабах: масштабах планеты, масштабах вселенной. Здесь можно вспомнить гипотезу Гайи (ссылка в комментах, про нее будет отдельный пост в TG канале) или гипотезу Автодидактической вселенной (ссылка там же и будет пост😉). По сути люди тоже создают такие сущности. Социальные сети — это “глобальный разум”, подсаженный на дофамин. Если нам удастся уменьшить компонент “дофамина” мы сможем создать нечто качественно новое.
🔘 Свобода воли
Проблему свободной воли можно представить так: обезьяна сидит верхом на слоне. У обезьяны есть иллюзия, что она управляет слоном. Возможно некоторые ее действия действительно влияют на слона. Возможно вообще никакие. Обезьяна настолько мелкая, что возможно слон ее даже не ощущает. При этом у обезьяны есть уверенность в том, что слон иногда подчиняется ее командам.
🍪 Счастье — это печенька, которую наш мозг выпекает для себя
В это саммари вошло лишь несколько идей и моделей, которые мне показались наиболее резонирующими. В тексте мысли Йоши замешаны в один коктейль с моими идеями и рефлексией, так что иногда они могут немного отклоняться от оригинала.

Ссылки на подкасты и материалы↓

https://www.youtube.com/watch?v=P-2P3MSZrBM
https://www.youtube.com/watch?v=rIpUf-Vy2JA
https://sergey-57776.medium.com/инновационный-апгрейт-операционной-системы-земли-1620d3575d4
https://medium.com/the-infinite-universe/the-universe-may-have-learned-the-laws-of-physics-fe2d22946432

Дело было так. В университете, я взял эту тему для доклада на семинаре по социологии – за то, как красиво она звучит. Разумеется, я не нашел материалов и проебал все сроки подготовки, и в ночь перед докладом должен был как-то выкрутиться. Все, что у меня было – это “краткий философский словарь”.

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

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

Примерно через один час скоростного чтения статей словаря по кругу, я заметил, что что-то изменилось. Я вдруг, внезапно, понял смысл одного предложения. Будучи искренне изумлен и воодушевлен, я продолжил чтение статей по кругу.
Хоп! Еще одно. И еще! Это не пиздец! Оно работает! Продолжаем!

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

Я сделал блестящий доклад, в котором коснулся не только современного состояния системной социологии, но и предпосылок, которые привели к ее созданию, и поворота в философии социологии, который сделал все это возможным (“теории среднего уровня” – ня, Мертон – гений). К моему изумлению – мне не хватило времени. Я готов был рассказывать больше, и сожалел, что не успел. Преподаватель был в глубоком шоке. Он спросил, откуда я брал материал – чтобы это понимание достать, надо вообще дохера читать, чуть ли не по немецки, тема редкая, литературы нет…

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

мое:
Хорошая история.
Я так свой первый яп учил, по “Язык программирования С” Бочкова и Субботина. Натурально зачитал до дыр.
И в тетрадке код писал, доступ к ЕС 1841 был ограничен.
До этого программировал только на калькуляторе, а на первом курсе давали какую-то тогда не понятную муть на Паскале. Это чуть позже, прочел Вирта – и стало понятно 🙂

Так и происходит, в действительности – настоящее самообучение:
Начинаем читать, а там все вот такое:
“Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка” – явно на родном языке, но – мало что понятно.

А многократное вчитывание-перечитывание приводит к тому что мы изучаем главное, суть – правила связи между частностями, иерархию, строим “карту местности”, систематизируем и т.п.
А когда карта построена – навешивать на нее детали, конкретику – то уже дело техники: памяти и времени. “дзен то постигнут”!

Они все были написаны птичьим языком. И не понятно было ровным счетом нихуя

Недавно на одном форуме программист молодой так писал о
Млять, решил подкачать математику, полез в википедию – они что, специально так пишут непонятно? аристократами себя мнят, тайное знание из математики сделали? Посоветуйте что почитать по математике написанное – человеческим языком!

единственный источник. Краткий философский словарь

Все пути ведут в философию

P.S.
Я почти 40 лет в айти, и вот что я понял за это время: откровения 60-летнего программиста
Помню, когда я пришел на работу и впервые читал свою задачу: буквы понимал, слова тоже, предложения — нет. Меня с ног сшибали фразы типа «пространство адресов». Но я все записывал в блокнот, а через месяц-два доставал его и не видел ничего непонятного. Я это называю «щелчок»: когда идет накопление информации, а потом происходит понимание.

There’s no objective way in which OCaml is better than Haskell, but I can tell you why I like it more. In short, Haskell is too perfect. OCaml is better because of its imperfection.

What language can match the elegance of Haskell’s level of abstraction, where the machine seems to disappear, and computation is modeled in purely mathematical terms? Not OCaml, and not any other language I’ve ever used.

Both OCaml and Haskell were created in academic contexts, but for different purposes. Haskell was created primarily as a platform from programming language research, and it has been wildly successful in that capacity. Haskell also has the goal of being usable for industrial application, which it is, but that is not the main purpose. OCaml and its predecessor, ML, were created as utility languages for implementing other programming languages (specifically, proof assistants).

Both OCaml and Haskell care about getting the job done right, but the emphasis in Haskell is more on “done right” part, and the emphasis in OCaml is slightly more to the “getting the job done” part—though OCaml’s semantics and culture do emphasize correctness more than any mainstream language (with the possible exception of Rust, now, if it can be considered mainstream).

When Haskell’s abstractions fit the problem you’re trying to solve, there’s no other language like it. It feels like programming in zero gravity or something. However, there are a few problems with this.

For the sake of purity, Haskell puts some red tape around interactions with the outside world. If you’re writing a program that needs to interact with the OS and the network a lot, this can be quite inconvenient. For I/O subsystems in large programs, I think the inconvenience is worth it, but for smaller programs that basically do nothing but I/O, it’s a bit annoying. OCaml, on the other hand, is designed for writing programs that work closely with the OS and makes it very easy to do so.
It’s a similar story with mutation. Both OCaml and Haskell make it easy to program without mutation, which is wonderful, and what you should strive to do most of the time, but only OCaml makes it easy to program with mutation, if you want that. As an example, OCaml is a major language for writing parsers. If you write parsers, you want a great regex engine. If you want your regex stuff to be fast, you’re going to want to use a lot of mutable buffers instead of constantly allocating new strings. OCaml comes out-of-the-box with libraries for working with exactly these kinds of buffers. You can do this stuff in Haskell as well, but it’s going to be a lot more work than it would be in OCaml in the name of purity. Again, sometimes purity is worth that extra cost, but sometimes, it ain’t. Nothing prevents you from using monadic effects in OCaml, but the language gives you the flexibility to decide when that is a fit for your problem or not.
Lazy evaluation is extremely cool and is responsible for the kind of weightless feeling you get when programming in Haskell, but it makes some programs much more difficult to reason about. In a lot of the cases that OCaml is used for (like virtualization), you want to know exactly what the program is doing, in what order, and how much memory is in play. OCaml has an extremely simple execution model that makes this easy, and Haskell has a very complex execution model that makes this difficult.

In summary, Haskell is very focused on an idealized vision of programming, and OCaml is more focused on the messy needs of real programs, while still offering all the benefits of functional programming where you can afford to use them.

There are a few other things that I find nicer in OCaml, but they don’t really go with this theme:

I like module functors more than type classes. The give you the same amount of code reuse, but they force you to be more explicit about the specific types in play at the call-site. This doesn’t look as pretty on the page, but it ends up being a lot easier to read. type classes can get you into this inheritance-spaghetti thing where you’re not sure where the code you’re calling is defined. This happens very seldom with module functors, since you have to explicitly create a new module where all the type-specific functionality lives. (this is perhaps slightly more verbose, but it usually only amounts to one extra line of code). This is pretty subjective, however. Most people prefer type classes because they look prettier.
OCaml’s ecosystem is smaller than Haskell’s, but I still like it more. Most OCaml packages have more of a “professional” or “industrial” feeling about them, where Haskell packages lean more in the academic direction.

А по поводу парадигм — прошу внимательнее присмотреться к процессу написания адаптера на ФП:
1) У нас есть база, она на выделенном сервере или в облаке.
2) Мы пишем к ней адаптер. Если у нас хоть какая-то нагруженность, то адаптер будет держать пул открытых сессий, чтобы не устанавливать сессию и соединение на каждый запрос.
Вывод: у адаптера появилось состояние
3) Если мы хотим иметь возможность подключать разные базы — то нам надо написать несколько адаптеров, по одному на базу. И они должны предоставлять одинаковые функции.
Вывод: появился полиморфизм между адаптерами
4) Начинаем писать адаптеры для разных баз, и обнаруживаем, что у MySQL и у MariaDB очень много общего, даже установка сессии. А вот с PostrgeSQL уже меньше, но функции по созданию и разрыву сокетов и шифрования — одинаковые. Мы же не хотим код дуплицировать? В результате у разных адаптеров появляются общие функции.
Вывод: у адаптеров теперь иерархия с наследованием

Итого: как только мы затянули архитектурный паттерн (Ports and Adapters aka Hexagonal Architecture) из ООП мира, он нам отравил наш ФП проект.
В результате мы на ФП языке заимплементили ООП ручками (для иерархии адаптеров выполняются все 3 принципа ООП, и у адаптера есть состояние) вместо того, чтобы положиться на поддержку в компиляторе.
Вывод: применение старых паттернов натягивает сову ФП на глобус ООП.

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

расход ойти курсов – это оплата часов преподавателю. что означает, в рамках уменьшения расходной части – уменьшать это количество часов
доход – это стоимость курса*количество оплативших
что означает увеличение количества учащихся на одного преподавателя, если стоимость курса нельзя повысить ввиду какого-то психологического порога платежеспособности целевой аудитории. можно уменьшить, “почти задаром”, чтобы 100 человек на 1 преподавателя

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

2. набираем преподавателей подешевле – “берем джунов а продаем как мидлов” – как на галерах. Что означает неопытность преподавателя
а) как в предмете преподавания (опытный программист будет преподавать – для души, а не ради этого смешного заработка),
б) так еще часто и педагогически

конечно давление “уравнения бизнеса” – не означает что все курсы такие, и все преподаватели такие.

но что точно означает для учащегося – учитьСЯ нужно самому. и тем больше, чем меньше тебе времени уделяет преподаватель, потому что ты будешь тратить свое время менее эффективно, чем под руководством ответственного преподавателя.

слышу эту байку с студенчества.
правда тогда имелся ввиду Basic, и звучала она примерно так:
“Пусть первым ЯП будет хоть лисп, хоть смалталк, паскаль, да хоть PL/1 или С, только не Basic и COBOL!”
Прошли “столетия”, контекст этого табу канул в лету, а об основе смысла мало кто задумывался и остался – миф.

который наверняка подпитывается эпиграфом к предисловию книги “Язык программирования С++” Страуструпа
“Язык образует среду мышления и формирует представление о том, о чем мы думаем”.
это Гипотеза лингвистической относительности (Сепира — Уорфа)

Гумбольдт настаивал, что языки инфлекционного типа, такие как немецкий, английский и другие индоевропейские языки являются наиболее совершенными, что и объясняет доминирующее положение их носителей по отношению к носителям менее совершенных языков.
…
Идея того, что некоторые языки по природе своей превосходят другие, и того, что использование примитивных языков означает интеллектуальную бедность их носителей, была широко распространена в начале XX века. Американский лингвист Уильям Дуайт, например, активно боролся за уничтожение языков коренных народов Америки, настаивая на том, что их носители были дикарями и было бы лучше запретить им использовать родные наречия и обучить их английскому, чтобы они восприняли цивилизованный образ жизни

Спросите хаскелистов даже не о пхп и джс, а о джаве и джавистах

“Awesome” interview experience.

The company said that I have low Node.js knowledge because when they asked how many threads Node.js has, I’ve answered main thread + 4 UV threads by default and a few V8 threads and can be more spawned from native modules or via worker threads.

They said that it’s the wrong answer because Node.js has only 1 thread, and I should consider joining them because I could learn from them about Node.js.

It’s really frustrating when people who don’t know the thing evaluate others and do not even consider that their knowledge maybe not be the best.

В программировании типичная мечта об уменьшении сложности это обычно:
Давайте сделаем систему проще чем то что она описывает и чем управляет!

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

Весь доклад

Мы тут решали задачу прогнозирования сроков создания платёжек для клиентов. У нас были данные за несколько месяцев, напустили на них ML, получили точность под 60% в первом подходе. Потом я вспомнил, что в универе нам на тервере говорили, что распределение Пуассона это число людей в очереди, взяли формулы оттуда, выкинули ML, сходу получили точность под 90%.
Забавно, что максимально тупой классификатор типа «если поставлено в первой половине дня, то будет сделано через 3 часа, а если во второй, то завтра» (немного утрирую), давал такую же точность 😂 Мы там, конечно, людей поднавалили, чтобы платёжки делались побыстрее, но в целом это учит тому, что многие вещи решаются просто.

Помню я только закончил универ и делал проект, где нужно было отрисовать диаграмму Ганта в вебе, это год 2001 был, из доступных средств рисования – можно было картинку размером в пиксель бахнуть. Ну я сразу конечно понял, что точками можно любую линию нарисовать, для этого есть специальный алгоритм – алгоритм Брезенхема и реализовал его. На больших диаграммах это тормозило. Мой коллега, выпускник технического вуза, с мозгом не замутнённым алгоритмами, заметил, что все линии, которые надо рисовать, строго горизонтальные или вертикальные. И можно этого добиться бахнув прямоугольный пустой блок, у которого 2 нужные границы включены. Всё сразу залетало, моего Брезенхема оставили для рисования заострённого конца у стрелочки 😂

Потом мы начали проверять, что диаграмма не содержит циклов. Хранилось всё в базе данных и мы средствами базы реализовали поиск циклов, просто поиск в глубину через рекурсию, который вызывался при каждом изменении базы в триггере. Однажды клиент сделал в диаграмме более 32 связей и ms sql написал ему: я не буду поддерживать рекурсию глубиной вложенности больше 32. Я тогда придумал как переписать это через поиск в ширину на sql, хранить во временной таблице волновой фронт и строить в другой временной таблице следующий фронт. Очень этим гордился))) А потом коллега из технического вуза опять заметил, что если предыдущий шаг в диаграмме Ганта всегда заканчивается раньше, чем начинается следующий, то циклов возникнуть не может. И нужно просто всё выкинуть и делать вот такую простую и понятную проверку дат шагов. Мы, люди, склонны усложнять, а «многознание уму не научает» 😂

Недавно меня спрашивали какой из продвинутых алгоритмов, которые я в универе изучал, пригодился мне в реальной работе. Так вот – я Брезенхемом птичку в конце стрелочки рисовал!))

S: Эмпирические решения частенько лучше обобщенных, математических
По крайней мере мне не раз приходилось выкидывать что напридумали “добиваясь гладкости функции”, и заменять на тупые алгоритмы с переборами и коэфициентами.
Потому что – борются за гладкость долго, бизнесу результат все равно не нравится.
Единственное из математики что выручало много раз это – логарифмы. Очень классно поджимают, подстраховывают “от переполнения”.

Джек(программист): у нас опять была задача, в которой требования за недельный спринт поменялись
Боб(менеджер): мы делаем планнинги для качественной постановки задач

Джек: и раньше у нас такая задачи была
Боб: а еще мы делаем рефайнменты чтобы актуализировать задачи

Джек: и вот тут была задача где выяснилось что нужен не SFTP а API
Боб: и ретро мы тоже делаем
<еще 15 минут таких итераций я пропускаю. Это не первый их диалог, и я решаю вмешаться. В общем-то, это даже не диалог а два монолога, только из их позиций этого не заметно. Для меня ситуация усложнена тем, что я в роли программиста а не менеджера>

VZ: Стоп. Джек, ты хочешь сказать, что у нас бывают тикеты, в которых требования меняются уже после начала спринта?
Джек: нет, я хочу сказать что объем работ может разростаться по ходу

VZ: ок, ты хочешь сказать, что объем работы за спринт может разростаться?
Джек: да
<Главный шаг для завершения монолога - это дать понять, что услышали. Не "я понял", а перефразировать/суммаризировать близко к оригиналу, ничего не добавляя. Если что-то не так, человек поправит, и это даже лучше так как даст ему еще 30 секунд эфирного времени и много удовлетворения. Начать лучше с того, кто в более слабой позиции, т.е. подчиненного>

VZ: Боб, правильно ли я понял, что у нас есть процедуры, которые должны предотвратить изменение скоупа?
Боб: не совсем. Я хочу сказать, что полное предотвращение невозможно, это про частоту и вероятности.

VZ: ок, ты хочешь сказать, что такие случаи неизбежны, вопрос только в том, как часто?
Боб: да
<Делаю то же самое для Боба. В общем и целом тут даже понимать тему не так важно, я однажды видел как психолог модерировал разговор про кубер, без малейшего понимания что это такое. Если честно, я за время их общения успел перезапустить билд и проверить почту в двух ящиках. А теперь нужно вернуться к Джеку, потому что он молчал уже две минуты, а мне нужно дать ему уверенность, что его слышат и с ним разговаривают>

VZ: Джек, вот если в числах, то наверное один случай на тысячу тикетов – это точно нормально, а один случай на три тикета – наверное нет. Так?
Джек: да, наверное

VZ: тогда это вопрос баланса, какой процент мы можем себе позволить. И это вопрос скорее к менеджерам. Боб, правильно ли я понимаю, что когда меняется скоуп, программистов в затягивании сроков никто не обвиняет?
Боб: да, особенно если это задокументированно в джире хоть парой слов
<Работаю с их страхами и даю уверенность. Программист может боятся, что в срыве сроков обвинят его. Или, другими словами, что ему скажут "ты плохой программист". Менеджер может боятся что его обвинят в плохом планировании, а еще - борьбы за власть. Или, другими словами, что ему скажут "ты плохой менеджер">

VZ: Джек, есть ли еще что-то, что бы ты хотел добавить?
Джек: та не, пустите меня кодить

VZ: Боб, а ты?
Боб: у меня через две минуты следующий митинг будет, мне пора

VZ: тогда всем хорошего дня
<Убедился, что все уже удовлетворены>

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

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

в описании русской озвучки есть ссылка на оригинал, английский там совсем не сложен, особенно речь главного героя
как было бы в типичной аннотации:
“В центре сюжета простой, искренний, бескорыстный парень, которому случайно выпало выполнить важную миссию, … Пройдя сложный Путь, он открыл в себе …, …. бла-бла-бла”

лучше посмотрите сами

* фильм для семейного просмотра тоже, отлично зайдет, дети от 6ти – вполне все поймут. девочкам тоже понравится, героиня в исполнении Phoenix Cross обаятельная получилась.

** главное отличие романа от повести – в романе главные герои становятся другими в процессе. в повести – остаются теми же.

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

Так вот: алгоритмическое мышление, то есть умение составлять алгоритм решения задачи – это вообще самое простое и интуитивно понятное большинству людей. Делай раз, делай два, делай три. Делай вот эти три шага N раз подряд, или пока верно условие. Если мы не берем, конечно, какие-то хитрые алгоритмы, требующие суровой оптимизации и понимания вычислительной сложности – но это уже та самая computer science, наука, в отличие от прикладного программирования, как профессии. Так вот для обычного программиста гораздо важнее не понимание “алгоритма”, а понимание структур данных. Не зря одна из основополагающих книг и почти все университетские курсы именно так называются: “Структуры данных и алгоритмы”. Алгоритм всегда опирается на структуру данных, одно без другого невозможно. Изменение структуры данных может очень сильно влиять на алгоритм (и его сложность).

И вот с пониманием структур данных как раз и возникает самая большая сложность. Видели недавнюю статьи про студентов, которые не пользуются папками для организации хранения файлов? Вот это про то самое. Понять, что такое переменная – гораздо сложнее, чем понять, что такое алгоритм. А понять более сложные конструкции типа массива, списка, стека, словаря или дерева – это вообще кошмар. Хороший программист как раз умеет правильно подобрать структуру данных под задачу, а там уже и алгоритм подтянется. Кстати, автоматное программирование – представление задачи в виде конечного автомата – долго было “секретным оружием” российской команды на чемпионатах по программированию. Типичный пример подбора структуры под задачу. И это гораздо более сложно понимаемая концепция, чем просто последовательность шагов. Говорят, тот, кто понял указатели в C/C++, справится с любым языком программирования (следующая по сложности концепция, наверное – области видимости переменных и замыкания).
И вот тут человеку особо не на что опереться, т.к. это чистая абстракция, да ещё и абстракция формальная. Нет в реальности прямого аналога, знакомого из опыта. Для алгоритма – есть, ну, всегда приводят в пример шаги рецепта по приготовлению блюд. Для данных – нет, мы не используем в быту двоичные деревья и не представляем слово в виде списка букв. (Кстати, я тут заодно понял, чем отличаются математики и программисты от гуманитариев. Первые хорошо справляются в уме с формальными абстракциями, типа красно-черных деревьев, вторые – с неформальными, типа государства и языка).

Дальше – больше. Мало нам структур данных, есть ещё типы данных. Сколько (и чего) получится, если к трем яблокам прибавить две груши? Чему равно “abc”+12? Для школьной математики эти вопросы не имеют смысла, а для программиста – вполне. Хуже того, встречаются в ежедневной практике и вызывают значимую долю ошибок в программах. А когда данные упаковываются в единый объект вместе с алгоритмами работы с этим данными, вот тут туши свет. Следующий уровень понимания.
Сюрприз – практически все программы сейчас именно из таких взаимодействующих объектов и состоят. То есть, работа современного программиста – правильно “нарезать” часть мира на такие абстрактные объекты (ну или взять готовую нарезку, например – кнопочки и картиночки на веб-странице) и научить их правильно взаимодействовать друг с другом, обмениваться данными, реагировать на изменения параметров друг друга. То есть, это не просто алгоритм, это – распределенный алгоритм общения между собой разных объектов со своими данными и поведением. Это то, что создает современный программист.

Что для этого критично? Уметь удерживать в голове эти цепочки связей между объектами, понимать, как объекты друг от друга отличаются, как из одного можно сделать другой, как работать с объектом, если ты не знаешь, что это за объект, какому объекту какая информация нужна для его работы.
Как понять склонность у детей к такому виду деятельности? На самом деле, довольно есть довольно характерные признаки, которые видны уже у совсем маленьких детей. Любовь к классификации и упорядочиванию: ребенок расставляет машинки в ряд и по цветам? Или по размеру? Или по назначению – тут гоночные, а тут джипы, тут военная техника, а тут строительная? Хорошие задатки для программиста. Ребенок следит, чтобы всё соответствовало? Эта чашка для чая, а эта – для сока, и не дай бог вам перепутать? Это оно. Соблюдает правила и последовательности действий? И ещё за вами следит, чтобы вы тоже соблюдали? Ага. Программирование – это постоянный анализ и синтез. Хороший признак, если ученик на русском без ошибок раскладывает слова на части и может составлять новые из отдельных частей. Разные задачи на то, у чего есть общие признаки. В математике – состав числа, разложения чисел, правила проверки делимости. Это про анализ и про формализацию. Шифры.

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

Как всё это диагностировать у взрослых – непонятно. По моей практике, нужно начинать с азов организации информации. Студенты и правда не понимают, что такое папки. Самая сложная тема для понимания в веб-программировании – путь к файлу или ресурсу. Ну вот просто путь к картинке прописать – это в 90% нерешаемая задача. Git – это уровень магии. Возможно, на входе у людей стоит спрашивать – есть ли у них папки в почтовом ящике, и по каким принципам они раскладывают в них почту. И дальше говорить с теми, у кого есть (шутка). Дает ли опыт в другой профессии бонус к освоению программированию – не знаю. Бухгалтерия, возможно? С планом счетов и LIFO/FIFO? Не знаю, интересно, если у кого-то есть примеры. Работа с текстами?

Не написал тут про матлогику, хотя тоже очень важная тема и тоже не про алгоритмы. Итого: структуры данных, умение разделить мир на объекты и спроектировать связи между ними, матлогика, придумывание правил и алгоритмов. И базовые принципы хранения и представления информации в компьютерах.
А может, я не прав, и современным программистам это уже и не нужно, а достаточно знать адрес stackoverflow и сочетания клавиш для копирования и вставки?..

P.S.
О, ещё вспомнил важное: понимание самой природы информации и особенности её копирования. Что скопированный объект не сохраняет связь с исходным. Что это вообще другой объект. Что файл, который вы скачали к себе на комп, не исчез с сервера. И что изменения, которые вы внесли в локальный файл – не передались автоматически в файл на сервер. Это довольно сложно понять, тем более что сейчас часто синхронизация выполняется в фоне, и как бы сама.

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

Ну, и как там говорилось: если ваш курс по программированию не начинается со слов “напишем тест” – выкидывайте и ищите другой. Но это уже высший пилотаж :))

По моему опыту, проблемы low-code/no-code решений стоят на четырёх китах, которые в свою очередь стоят на черепахе.

Черепаха называется «все-таки, как его не назови, это программирование».

А киты соответственно получаются такие :

Кит первый : composability. С ним обычно все где-то между «нет вообще» и «плохо». Либо нет возможности вынести кусок функциональности в отдельную переиспользуемую сущность. Либо reusable components можно писать исключительно на каком-то «настоящем» языке.

Или какая-то беда с параметрами: параметры «нельзя», либо максимум один, либо передавать только константы, или ещё что-то в этом роде.

Отсюда мы плавно переходим к Киту номер два: беда с моделирование данных. Могут быть проблемы с тем, чтобы в рамках процесса что-то посчитать и сохранить результат (чтобы использовать его два раза). Либо такой возможности нет вообще. Либо из типов данных у тебя только строки. Может быть так, что все данные представлены в виде global или local key-value map, и это единственная структура данных, и начинаются пляски с магическим именами ключей, которые ожидаются в той или иной точке процесса.

Отсюда переходим к Киту номер три: discoverability and namespaces. Имена, создаваемых пользователем(имена процессов, переменных, ключей в key value map) , могут жить в одном глобальном плоском неймспейсе, который со временем превращается в помойку. Если вам дают поиск, то он может быть только по имени (которое вы уже должны знать). Если и есть поиск по телу/атрибутам/чему-то подобному, то он может быть странным, так показать контекст, в котором нашлось искомое, тяжело — это ж не текст, из которого можно вырезать сниппет

Отсюда переходим к Киту номер четыре: редактирование. Если нет нормального поиска — не будет и поиска с заменой. Если нет поиска с заменой — плохо придуманные имена сущностей рискую быть с вами навсегда. Контроль версий может быть, а вот сравнение разных версий или что-то типа diff-а — уже нет. Два человека, которые правят одно и то же, либо ограничены каким-то глобальным mutex-ом, либо рискуют затирать правки друг друга.

Я, честно признаться, уже давненько не брал в руки шашки, но вот я открываю упомянутый в комментариях corezoid и вижу там в tutorial вещи, Киту намекаю, что «все как всегда». Передаём json/kv map, можно интерполировать значения оттуда в строки (если я правильно понял), есть галочка «отослать все наши данные в вызываемый процесс» (привет, магические имена keys?)…

Скажите мне, что я застрял в прошлом, прогресс шагнул далеко вперёд, и state of the art выглядит совсем не так

Программирование без программистов и что мешает ему развиваться

youtu.be/Sj-WSWr-n7U

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

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

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

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

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

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

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

Желание получить «правильный» ответ, когда есть «хорошие» и «плохие» ответы
Если вы ставите целью программирования нахождение единого правильного решения, а не спектра решений — вы не добьетесь успеха.

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

Автор: Джонатан Блюкс
Вся статья
10 Signs You Will Suck at Programming, Jonathan Bluks

Хорошие новости: мне редко попадались ученики, которые не могли научиться программированию.

Я рассматриваю это как базовый человеческий навык: как чтение, письмо и арифметику. Это может делать любой, это часть того, что в принципе может человек. Но этому действительно нужно учиться.

При менторстве 99% — это самостоятельная работа. Другими словами, ментор бросает в воду и смотрит, как выплывает человек. Но плывут немногие. Большинство людей тонет после первого задания — особенно новички. Просто получают задачу и перестают отвечать на сообщения.
«После этого случая я понял, что программирование — не для всех»: разработчик о том, как он стал ментором и почему не берет за это деньги

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

Layered Architecture
Microkernel
Event-Driven
Pipeline
Space-Based
Microservice
Service-Oriented
Service-Based

Источник

🍀 Юдзиро

Обучение по принципу «смотри сюда и повторяй за мной» заканчивается со школьным выпускным.
Дальнейшее образование – в любой форме, будь то вуз, обучающий курс или менторство – подразумевает по большей части самостоятельное освоение материала.
Роль преподавателя сводится к следующему:
· систематизация учебной программы – от простого к сложному «учи сначала это, потом это»;
· моральная поддержка и подпитывание мотивации;
· указание на ошибки;
· помощь при затруднениях.
Всю остальную работу учащийся выполняет сам.
В отличие от школы, которая «вбивает» знания в каждого независимо от его желания, дальнейшее обучение не будет эффективным без главного условия:
вы должны принимать самое активное участие в получении знаний.
…
Те, кто приобретает онлайн-курсы по обучению IT-профессиям, часто сталкиваются с тем, что их ожидания не оправдываются.
Заплатив немалую сумму денег, студенты решают, что на этом их часть сделки выполнена.
Мол, далее действовать должна школа, выполняя рекламные обещания.
Сделать из новичков профессионалов, «вживить» в их мозг нужные знания и опыт, а потом ещё и найти им высокооплачиваемую работу.
Это как прийти на урок танцев и сесть в уголке, ожидая, что к концу занятия вы получите скилл «танцевать танго». «Я же заплатил!»
…
Начинаете учиться IT с такими ожиданиями? Значит, в скором времени пополните ряды тех, кто пишет отрицательные отзывы об инфобизнесменах-обманщиках.
Кому же верить?
В первую очередь себе. Вы действительно хотите изучить IT?

Вся статья: “Никакой курс не сделает из вас программиста без самообразования. Обманчивые офферы, и как правильно учиться”

Ну — что фичи в софте становятся дороже с каждой следующей. А 80% юзеров надо 20% фичей.

jakobz написал

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

Это невозможно по многим причинам, можно только уменьшить кривизну

И одна из причин, многие ПМ уверены что правильный процесс приведет к прямой Затраты, а если прямой нет – то это криворукие программисты.
Они не понимают, что экспонента Затраты – это естественно, а вот прямая Затраты – это
или усилия=дополнительное время на разработку.
или программисты высокой квалификации
И чем более сжатые сроки – тем круче будет экспонента.

Инженерия стремится ее выровнять в прямую, сроки и бюджеты ее закручивают

А кривая профита – под давлением закона убывающей предельной полезности

Явление объясняют тем, что, согласно правилам написания статей в «Википедии», в самом начале нужно точно указать, что обозначает предмет публикации, и как правило, это широкое понятие.

Вся статья

Когнитивная сложность современного devops, с моей точки зрения, перекрывает когнитивную сложность почти любой разработки или СУБД
Язык программирования, даже сложный, даже C++ можно выучить
Есть стандарт и компиляторы
Это штука меняется медленно
Выучить golang и освоить основные либы можно за конечное время, меньше года.
В целом, все гошные либы одинаковые – go.pkg.dev/ и погнал
Архитектуру СУБД и баз данных вообще можно изучить
Есть стандарты, документация, есть papers

Но вот devops… Документация по базовому сервису AWS – IAM – 700 страниц плотного текста
– не освоил – работаешь “от рута” – админского доступа аккаунта
– освоить один только IAM – это примерно 4-6 месяцев достаточно плотного вычитывания этого документа и ещё больше экспериментов
– огромные количество недокументированных фич и особенностей поведения. Они логичные, когда освоил, но нелогичные, когда изучаешь. Вот, например, простая штука – снёс-создал роль, и кросс-аккаунтный доступ отвалился. Почему? Из соображений безопасности, и они в целом одном месте среди этих 700 страниц пишут, что при создании кросс-аккаунтного доступа он запоминает не имя роли, а её внутренний id, который уникальный при каждом создании. Даже с одинаковым именем! Логично? Да. Очевидно? Нет. Можно это освоить заочно? Невозможно. Как про это узнать? Столкнуться и потратить несколько часов с матерными криками “да что не так-то, почему permissions denied”
– огромное количество вопросов в manual НЕ ОХВАЧЕНО.

И, ребята, это ОДИН базовый сервис из ЧЕТЫРЁХ (EC2, S3, VPC, IAM)

А в AWS мы, например, используем 20 с лишним сервисов. По каждому – портянка доки. У каждого – свои погремушки в интеграции с IAM (кто-то умеет resource policy, кто-то нет. Кто-то поддерживает tag-based access control, кто-то нет. У отдельных сервисов – свои исключения). У некоторых сервисов вещи означают вообще не то, что вы думали. Одна из самых больных для меня тем (три рабочих дня не понимал, что не так) – это tag в случае ECR. Не путайте AWS tags на ECR репосы и docker tags – это разные вещи (но вот ImageTagMutability – это про docker tags. Смотри не перепутай, %devops%!)

Другие AWS сервисы… Особенные. Вот, например, Cognito.
Есть у меня шикарная переписка с support AWS.
“Ребята”, говорю я им, “а как так получается, что при логине через external identity provider я могу задавать sesions tags на Identity Pool, а при логине через ваш родной Cognito User Pool – не могу? У вас там lambda триггер не позволяет в токен докинуть нужную структуру claims, которую вы ждёте для сессионых тегов. Выглядит как баг и недоработка”
“Отличный вопрос” – отвечает мне support. “Подумаем что сделать”

Прошло два года…
Я тут задался вопросом, а как так выходит, что сторонний сервис работает с AWS лучше, чем родной?
Я нашел ответ. Никто и нигде не использует Cognito как Identity Provider. Его используют как bridge между “login by google” или “login by facebook” и cognito identity pool, чтобы end-user выписать уникальную aws сессию
Это ответ на вопрос, почему стандартный Hosted UI там выглядит как пример из студенческой лабы нулевых, и почему без бутылки и пары месяцев разработки ты нормальный UI не сделаешь (кому надо – могу проконсультировать. Ответ называется “AWS Amplify”, а чтобы его настроить как надо, вам придётся очень внимательно прочитать документацию по Cognito и OpenID Connect RFC).

И это, ребята, я ещё даже не коснулся kubernetes. По kubernetes у меня отдельная и большая боль и история
И это, ребята, я совсем-совсем не касался инструментов IaC – infrastructure as code.
Там такой зоопарк, просто тушите свет, и есть типа terraform, но, ребята, я ни за какие деньги не готов на terraform писать, вообще ни за какие.
Он просто должен умереть
Есть AWS CDK, есть pulumi, берите их и не трогайте Terraform.
Почему – отдельная тема на пару часов, у меня нервний тик образовался после трёх лет его использования, и прошел только при переезде на AWS CDK.

========================================
Промежуточный вывод-вопрос: как вы думаете, сколько нужно времени, чтобы это всё освоить?

За четыре года, которые я занимаюсь почти только devops, я, нет-нет, что вы, не освоил всю эту историю, но я ПРИМЕРНО начал понимать, как это всё готовить так, чтобы не было мучительно больно потом
Ну и то, как освоил – kubernetes лишь основы, у меня другой инженер в команде мастер kubernetes, я сам скорей power user.
Я освоил AWS – но не на уровне master, что вы, но вот базовые сервисы и безопасность я там потом и кровью освоил
Квалифицированный devops – это примерно 3-4 года обучения и ещё 3-4 года практики.
Я практически уверен, что это должен быть разработчик в прошлом, скорей всего – очень сильный (потому что, например, AWS – это не “готовые сервисы”, это “готовые полуфабрикаты”. Очень мощные и крутые, настраиваются как угодно, но без написания lambda функций вам никуда, программировать нужно уметь, причём на хорошем уровне)
Никогда при разработке движка СУБД или на С++ я даже близко не встречал ТАКОГО объема материала, сложности, и мощности когнитивной модели.
Вот щас бегают дурные вакансии на 500k рублей – да понятно, почему это столько стоит, просто нет людей, кто умеет это готовить
Я смог эту науку освоить, я смог научить инженера под это дело, я готов переобучать у себя в команде разработчиков в devops, но совершенно точно рядовая компания на рынке не может себе позволить таких компетенций

========================================
…может сложиться впечатление, что я ругаю DevOps и облака
Это не так.
Как вдвоём админить под сотню активных релизов десятка проектов?
Без облаков – никак
Вот берём AWS Transfer – managed SFTP сервер. За три дня худо-бедно разобрался с ним и смог засеттапить
Для этого нужно
– создать S3 бакет
– написать lambda функцию аутентификации (я писал на golang), которая читает AWS Secrets и на основе его содержимого проверяет пароль и генерирует политику доступа
– воткнуть lambda фунцию в API Gateway
– подключить route53 DNS зону в AWS
– сгенерировать AWS ACM сертификат
– создать AWS Transfer сервер, приземлить в него AWS ACM сертификат и AWS API Gateway для аутентификации
– приземлить CNAME запись в Route53 на этот сервер
– создать AWS secrets под юзеров
– создать AWS IAM Roles под юзером с нужными политикам доступа в S3 бакет.
… вопрос в зал: вы ещё не охренели? А это, между прочим, ШТАТНЫЙ и ОФФИЦИАЛЬНЫЙ способ как поднять managed SFTP server.
И, разумеется, вы его заколебётесь накликивать, вы сломаетесь на AWS API Gateway, инфа 100%
Зато на AWS CDK это собирается достаточно легко

Можно спросить: нафига козе боян?
Да легко, ребята. Я проинвестировал три дня, и у меня есть распределенный на три датацентра пуленепробиваемый отказоустойчивый SFTP сервер с безразмерным storage под ногами
Я его настроил три года назад, я про него не вспоминал, он просто работает – причём стоит очень адекватных денег, и я его легко могу перешатать под любые права доступа и квоты
Облака – награждают
Давайте я не буду касаться AWS EKS? Это, с моей точки зрения, вообще лучшее на рынке решение для kubernetes, но абсолютно безнадежная задача думать, что вы его освоите за неделю или за месяц
Это задача на примерно год.
Зато – он пуленепробиваемый, автомасштабируемый, автообновляемый, безопасный, и так далее. Просто работает.

Или, например, zalando postgres-operator
Сижу на совещании, разгар бизнес дня. Вижу в мониторинге, что долбанулись два postgres мастера.
Я даже не чешусь, мне пофигу. За три секунды на их место встанут slave’ы
Старые мастеры будут убиты, пересозданы, подключены как slave’ы назад в кластер. Автоматически.
Это так работает у меня в проде, уже несколько лет
Были всего две странные проблемы, когда slave в очень специфичных ситуациях зависали.
Разобрался за пару часов один раз, написал incident report, как починить
Зависли второй раз – открыл его – запустил одну команду – и всё поехало дальше само.
Сколько этих postgresql у меня в кластере – да я не считал. Несколько десятков. Какая нахрен разница, они все сами масштабируются, бекапятся и лечатся. Если что – просто передёргиваю одну строчку в YAML и восставливаюсь из бекапа
Нужны разобраться разрабам? Ну, это задача минут на 15, чтобы им полный клон для экспериментов поднять
Ломайте, мне не жалко, делайте что угодно, мне эти копии ничего не стоит поднять

========================================
Какой тут вывод и мораль… DevOps современный – это не просто отдельная профессия, это самые настоящие врата ада и чёрная дыра, куда нужно инвестировать массу времени и денег.
Что это даёт? Ну вот я и мой сотрудник щас вдвоём тащим администрирование нескольких юрлиц, пары десятков проектов и под сотню релизов (опять же, как их считать, по штукам – сотни, по логической компоновке – ну, наверно, несколько десятков будет)
Время downtime? Ноль
Время downtime при обновлении? Ноль
Проект не меняют? Он работает сам, ты вообще забываешь, что он существует. В билинге просто видишь его, когда туда заходишь
Сколько админов нужно, если не devops? Ну, по моим прикидкам, десятка два людей
Будут они работать лучше?
Нет, конечно, у нас щас всё само катится из CI/CD, а эти два десятка человек работать будут через тикеты, с ошибками, выходными и временем реакции – часы в лучшем случае, а не единицы или пару десятков минут
Как с этим всем взлететь – понятия не имею. Мы этот путь прошли, но это действительно hard way.

 Сергей Соловьев, Редактор, Москва

Методологии управления создают иллюзию контроля, которого на самом деле не существует. Почему?

Мир менеджмента как Зазеркалье. Там все похоже на настоящее, но наполнено магией и волшебством. Сценарий успеха всегда сводится к тому, что главное – выучить правильные заклинания. И тогда можно отважно спускаться по каскадам водопада, сверяясь с диаграммой Ганта. Или отплясывать канбан, азартно срывая сроки по независящим от себя причинам.

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

Проект сдан вовремя, но с таким качеством, что заказчик недоумевает — почему вообще «вот это» (брезгливо) называют результатом. О, мы сейчас объясним. Давайте позовем Product Owner, и он зачитает речь про MVP с остроумными цитатами из бэклога продукта. Можем даже собрать ускоренное видео со всех скрамов проекта, чтобы вы заметили, как его первоначальный смысл выдавливался за рамки спринтов. И вот мы здесь. Продлевать будете?

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

Тактическая цель достигнута, а стратегическая… Ну это же Agile. Все понимающе переглядываются и усмехаются. У самурая нет цели, только путь к регулярной денежке за внимание к проекту.

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

Выражение «отлаженные процессы» вообще звучит как начало анекдота про выход из операционки. Есть только две реальные возможности выйти из операционки. Когда пациент спасен, и усталый хирург идет переодеваться. Или когда самозванец наплел с три короба обещаний, а потом позорно сбежал, оставив все в ужасном виде для оперативной съемки и описи улик.

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

Найдите отличия между процессами и проектами

Проекты уникальны, говорили они. А процессы, типа, нет. Ну-ну. Изолированные процессы возможно. Хотя и то вряд ли – слишком долго, с учетом того, что закон Мура давно уже не про микропроцессоры, а вообще про что угодно. Весь бизнес оценивают по росту показателей. То есть по изменениям.

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

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

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

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

Добавим к этому другую жидкость – текучесть кадров. Точнее, если бы сотрудники просто разбегались по какому-то предсказуемому алгоритму – можно включить в формулы, учесть, приготовиться. Но нет же. Это скорее неньютоновская жидкость, которая по всем признакам похожа на опору. Можно наступить, проверить. Да, держит, отлично! А потом бульк! и привет, социальный дайвинг для владельца компании.

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

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

Хорошо, значит в наступившем прекрасном будущем нет ничего, ни театра, ни кино, один сплошной PMO (Project Management Office, прим. ред.)? Ах, если бы.

Почему проект без процессов обречен

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

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

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

А какой кстати смысл в проектах вообще, если не поставлено нормирование. С такого ракурса становится очевидным, что проекты вообще просто расходный материал для поддержки процессов. Внутри каждой проектной задачи можно грезить об уникальности, обклеиться стикерами, надевать 6 шляп подряд и что угодно другое. Но выгляни чуть дальше — там тот же самый коридор.

Просто руководители проектов пытаются решить бесконечный парадокс «третий лишний», перебирая как четки треугольник Сроки/Цена/Качество. Но решения не существует. Точнее, математическое как раз есть, только это для презентаций и отчетов. А настоящего, рабочего решения — нет.

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

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

Что делать

Пожалуй, стоит признать что процессное и проектное управление реально заключаются не в том, каким именно образом описать нежизнеспособные, заведомо нереализуемые пожелания. А в том, чтобы выяснить действительно важные граничные значения, и постараться в них вписаться. Жертвуя чем угодно. А в первую очередь – чистотой методологией, всей этой ересью «смотрите, здесь же было написано». Написано — вытри, пока никто не увидел. Здесь нечем хвастаться, это стыдно.

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

Все участники коммерческой деятельности делятся на две неравные категории:

• Недоговороспособные, от которых ничего реально не зависит. Это те, кого надо «пройти» по дороге к ЛПР. Вы же не будете спорить о методологиях с турникетом. Эдак и до дурки недалеко.
• ЛПР, лица принимающие решения. Только как они их принимают? В неудобной позе, со всеми чувствительными частями тела, зажатыми в разнообразных струбцинах и плохо чищенных зубах. Как и все. Как и вы.

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

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

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

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

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

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

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

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

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

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

Но жертвой стал не UML сам по себе. Если откровенно, UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories.

В модели, куда на входе засовывают user stories, а на выходе получают демо (или feature production release), больше нет места для содержательного структурного анализа задач.

В современном дивном новом мире понимание напрямую кристаллизуется в код, готовый к продакшену. Даже моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на «команды на две пиццы». …

Современная парадигма заключается в том, что нам всё равно не удастся понять задачу.

… мы просто отказались от инженерного проектирования ПО. Теперь это просто авантюра с кодом. Я не говорю, что те, кто пишет ПО, сами не являются инженерами; чаще всего, это не так. Смысл в том, что на организационном уровне ПО больше не проектируется, как это делается в других сферах, например, в машиностроении.

Аналогично!
И о-о-о, как бьют 🙂
И разделяю c flipstables “вселенскую несправедливость”:

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

Я знаю примерно 5% наполнения тех фреймворков и особенностей языка, с которыми работаю прямо сейчас или работал совсем недавно. Те, с которыми давно — 1% достаточно объективная оценка.

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

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

ЛИБО, если код короткий, делается строго обратное: выбрасываются лишние сущности, а кусочки кода тупо копипастятся. С целью сделать его читабельным и снизить требования к памяти при чтении. Но опять же, если это требует общения с редко встречаемыми конструкциями, я стараюсь обернуть это во внутренний класс, или же в анонимку, стараясь дать сущности имя через создание (или использование общепринятого) интерфейса.

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

По той же причине в недописанном коде комментов куда больше, чем в готовом. Они лучше тестов обеспечивают целостность. Потому как в написании тестов легко ошибиться, когда код ещё не готов. А вот в описании идеи, что ХОТЕЛОСЬ сделать, ошибёшься ты сильно вряд ли (в силу избыточности естественных языков, дающей устойчивость к ошибкам). Когда же код написан, комменты лучше перенести в тесты. Ибо когда тест какой-то завалится, всегда полезно знать, как на самом деле должен работать код, и соответственно что надо править — сам код, тестовый набор данных, или же тесты.

А по поводу работы с людьми — это хард скиллы, а не софт. Как раз софт это то что приходится постоянно апгрейдить, а вот если с людьми какие-то нестыковки, тут уж никакие знания не помогут. Потому что это фактор, влияющий на скорость выполнения работы в 10…100 раз и выше. По той же причине джунов не хотят брать. Не потому что знают мало. А потому что синдром Даннинга-Крюгера одного тормозит всю работу всем.

Как только увидел про idempotency_key, так сразу и улыбнулся, ну-ну, Вася, смотрим на твои муки дальше…

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

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