Є стародавній жарт про те, що ревьювер отримавши пул реквест на 2 строки знайде там 3 помилки, а на 2000 строк скаже, що все ідеально)

Дякую за статтю.
Додам до піраміди пункт Performance. Між Correctness та Security.
Критично важливо бути певним, що після деплою швидкість роботи системи буде відповідати нефункціональним вимогам.

Подивіться структуру данних Vantage-point tree.

А тут я ще не встиг натиснути кнопку «зберегти», а мені вже підсвітило помилки у коді

Вже забув що таке кнопка «зберегти» у IDE. Autosave у pycharm виконує свою роботу ідеально.
Чи малося на увазі не зберегти, а додати комміт?

Додам mypy, wemake-python-styleguide, autoflake.

По момему, не компетентному в вопросе мнению нужно искать видео материалы со следущими критериями:
1. Автор видео вничале снимает сам себя на камеру хотя бы несколько секунд (привет любители селфи).
2. Четко произносит где он находится и текущую дату.
3. Показывает, что видит вокруг.
4. Рассказывает как его найти в социальный сетях.
5. Текстовая подпись к видео должна явно соответстовать тому, что на видео.

Если видео не соответствует этим критериям — его легко назовут фейком.

Если будет 100500 таких видео размещенных на разных хостингах все заблокировать будет сложно.

Добавлю про линтеры — wemake-python-stylegui.de/en/latest

от более вольных к более формальным

В моем понимании это и есть мера гуманитарных — технических наук.
В первом комментарии про это говорил, как про уровень использования математики.

Такое и в IT просчитать нельзя.

Весь блок про «ТЗ для романа» просьба воспринимать больше как юмор (тот самый, в котором есть доля и юмора и правды)

Немного про другое говорил.
Можно ли составить тех. задание на роман в цифрах?

Допустим можно :-)
— декларативно: роман должны купить > X читателей по цене > Y за время < Z
— императивно: жанр = X с примесью Y, тематика Z, сеттинг J, параметры целевой аудитории R[1...n] и т.д.

Автор получил это задание. Выполнил все императивные требования (допустим придумали как их все выражать в цифрах).

Будет ли «хит»? (на английском одно из значений hit — попадание)
Зависит от многого — от бюджета на рекламу, имени автора, предложений «на рынке» (если еще 100500 авторов получили похожее задание целевая аудитория будет «перекормлена»).

Еще можно провести эксперимент — написать 1К вариантов романа, найти 1М добровольцев, обвесить их датчиками и посадить перед видео камерой читать роман. Затем все полученное передать в machine learning pipeline и перед релизом выбрать лучшие по score варианты, склеить в один и заново валидировать.

... а на параллельной улице сидит автор, у которого личная жизненная ситуация сложилась так, что когда он ее отразил в книге — аудитории «зашло». Без особого маркетингового исследования. Вот просто зацепило. И никто не может явно пояснить почему. А даже если и сможет, то при повторении «находок» их ценность будет уменьшаться.

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

В программировании есть конечно моменты шаманские. Вот взять из Solid первую букву.
Сколько есть ее определений?
— должен делать что-то одно (самый распространенный вариант для «понимания»)
— должен иметь одну причину для изменения
— и, для эпического финала, «This principle is about people» как кульминация неопределенности от Дяди Боба.
Результат — в спорных случаях принцип сводятся к «highest paid person’s opinion» — кто начальник у того и «солидный» код.

Однако если очень сильно захотеть и натравить на условный python проект pylint, mypy и wemake-python-stylegui и задаться целью удовлетворить их все (и только в случаях прямого конфликта правил выбирать одну из сторон) — то получим, что-то похожее на числовое отражение качества кода
В частности для SRP: Лимиты на кол-во переменных, элементов модуля, импортов, когнитивную сложность строк и методов.

И еще раз повторю — классификация не бинарная. Скорее координата между 0 и 1.

Можно на книгу смотреть как на «script» (с англ. сценарий), и можно на код смотреть как на творческий процесс. Однако, если сортировать по возрастанию степени жесткости и числовой формализуемости требований — явно вначале будет программирование (более техническая работа), а затем творчество (более гуманитарная).

Можливо річ у рівні використання математики.

Технічні завдання майже завжди можна однозначно виразити у числах.
Тут не виникає сумнівів, що сортування n*log(n) краще ніж n^2 для великих n.

У гуманітарних науках це не так. Літературу, музику, філософію, релігію та образотворче мистецтво складно (якщо взагалі можливо) виразити у числах та задати критерії для пошуку оптимальних рішень. А якщо і можна, то ці показники та критерії будуть різні для різних людей у різний час.

Класифікація звичайно небінарна. Економіка, наприклад, має і технічну у гуманітарну складову.

100%

Юрий, здравствуйте!

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

Не совсем понимаю как указанная Вами формулы «ресурсы-время-качество» относится к теме максимизации эффективности. Думаю всем очевидно, что время, это также ресурс. Исходя из этого эффективность = результат (качество) / ресурсы (в том числе время). Максимизация эффективности может быть выражена в простой схеме: зафиксировав требуемый уровень качества, ищем варианты минимизации расхода ресурсов, или наоборот зафиксировав ресурсы (бюджет и время), ищем варианты максимизации качества. Кроме такой простой схемы можно еще представить вариант при котором каждый из параметров не фиксируется жестко, а описывается приемлемым диапазоном.

не сильно бажає щось змінювати

Можливо йому і не потрібно — просто для іншої роботи треба знайти іншого спеціаліста вузького профілю.

Як ви думаєте, яку оцінку дасть людина, яка не може відрізнити витрати від інвестицій?

Під економічним обґрунтування своїх технічних рішень, мав на увазі розрахунки наближені до побутових. Приклад приходить на думку такий — якщо можливо за пару годин оптимізувати 1% коду, що прискорить роботу системи у десятки разів та дасть змогу відмовитись від великої кількості додаткових дорогих серверів, то треба оптимізувати. Та навпаки — якщо очевидних проблем із кодом немає і є альтернатива між багатотижневим марафоном із профайлінгом, що за прогнозом дать приріст на кілька відсотків та можливо збільшить складність коду і варіантом ресайзнути віртуалку для збільшення ресурсів, що можно зробити швидко та доступно по ціні, то вибір теж очевидний

Наприклад, постійна комунікація з людьми, які не мають спільної думки

Постійно — мабуть ніхто не витримає, але для різноманітності думаю це теж корисно.

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

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

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

Если говорить о, Вашими словами, «шлюпке»... Используя этот термин Вы видимо имели в виду размеры компании? Не думаю что около 1000 человек в офисах Одессы, Николаева, Киева и Гомеля соответствуют размерам небольшой компании. То, что один из руководителей, по Вашим словам, кому-то грубил — мне сложно комментировать — меня там не было и я не знаю деталей ситуации. Зато логику поведения обиженных на весь мир людей, которые любят обвинять всех вокруг в причинах своих проблем я знаю. За три с половиной года в компании, даже в самых экстренных ситуациях когда мы сталкивались с эпическими техническими сложностями, лично я не слышал от своего руководства того о чем Вы говорите.

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

Перший варіант такий і був, а потім подумав — навіщо писати про очевидні та загальновідомі речі?

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

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

Спасибо, хоть кто-то, что то позитивное сказал :-)

В статье указано «эффективности программистов разного уровня может достигать 1 к 100». Это не значит, что на каждой задаче будет так, но и однозначно речь не идет про про «случайно найденную кнопку».
Также имел в виду (но к сожалению явно не указал это в статье) что Junior только пришел в проект, а Senior уже работает там пару лет.
Если говорить в целом, то пример похож на старый анекдот про «знать где ударить». Для больших проектов доля шутки тут может стремится к абсолютному нулю.