Pull to refresh

Comments 518

Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.

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

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

Единственно верное решение — это "2 x 2 = 4".
Все остальные решения — это компромиссы.

UFO just landed and posted this here

Далеко не факт, плюс, на 0 в некоторых языках программирования начинаются восьмеричные числа.

Компьютеры бывают не только двоичные.
UFO just landed and posted this here
По ссылке ходить не пробовали? Там написано.
UFO just landed and posted this here
Скорее не там искали. Используя динамические языки сложнее написать код, который всегда работает корректно, но проще написать код, который иногда работает корректно.

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

А иногда 100% корректность не нужна в принципе: например вспомогательные скрипты, используемые для сборки программы — если они как-то отрабатывают на ваших данных, которые у вас есть и дают правильный результат… то вам же неважно что они сделают с другими данными, которых у вас нет!
Лайфхак: зайти по ссылке и ввести в поиске по странице слово «сдвиг»)
UFO just landed and posted this here
Правильнее говорить по другому: Питон на столько медленный и длинный, что в нём даже сдвиг медленнее, чем умножение.

просто для сдвига используется два символа, а для умножения — один

Еще быстрее будет просто: 4

В некоторых системах счисления может получиться не 4, а 10 или даже 11 :)

А то и syntax error «operation 'x' is not defined» [:
Здесь человек привык принимать Единственно Верные Решения ™ — а вы со своими троичным и четверичными системами…
UFO just landed and posted this here
Предлагаете использовать «единичную» систему?

Микросервисная архитектура. По сервису для каждой задачи:
2 х 2,
2 х 3,
2 х 4...

UFO just landed and posted this here
зачем так примитивно? Система исчисления с основанием е — куда забавнее.

10 в любой системе счисления 10 ;)

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
обучение детей счету о котором упоминается: надо вспомнить что обучают на палочках счету в десятичной системе, а не единичной

что с вами не так? палочки представляют собой обозначения в унарной системе. Если вы выложите палочками цифру 5 — будет цифра пять. А если это пять палочек — это пять в унарной системе.

В перле 2 x 2 даст 22. Как и 2 . 2

найдите точное численное решение задачи X*X=2, без компромиссов пожалуйста.

public int X { get { if (!x) { x = true; return 3; } return 1; } }

UFO just landed and posted this here
Все остальные решения — это компромиссы.

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

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

Как же скучно жить в черно-белом мире…
всегда есть не нулевая вероятность получить несколько оптимумов при конечном количестве параметров.

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

С чего бы, даже в теории, стремиться к 0...? Насколько я помню, математически было показано, что вероятность нахождения нескольких оптимумов стремится к 0 только при бесконечном количестве параметров/критериев. В практике(реальной жизни) оптимумов вполне может быть несколько. Классический бытовоц пример у нас — выбор рейса Москва -Питер. Чтобы выбрать рейс, постоянно нужно увеличивать число параметров/критериев.что бы в итоге остался 1. Причём в зависимости от индивидуума, набор этих параметров разный…

Назовите любой алгоритм сортировки и вам назовут мильйон причин, в чём оно не оптимально.

Похоже на задачку буриданова осла, если честно. С сортировкой-то что не так? Если нет убедительных причин поступить иначе: берите sort из стандартной библиотеки, и не надо ничего выдумывать.

С сортировкой не так то, что сортировать можно очень разные данные и в очень разных условиях. Массив из 10 элементов эффективнее будет сортировать вставками. Из 10 миллионов элементов — квиксорт (если массив упорядочен случайно). Для 3 элементов эффективнее будет нахардкодить дерево из ифов. Если подключить сюда еще размер данных для сортировки (просто инты или 10-мегабайтные структуры?), тип структуры контейнера (массив или односвязный список?), характер данных (почти отсортированные? Случайно упорядоченные? Отсортированные в почти-обратном порядке?), то количество оптимальных для каждого отдельного случая алгоритмов растет еще больше.


sort из стандартной библиотеки — это компромисс, который good enough для самых распространенных случаев. Но даже в каждом из них — далек от оптимальности. Не говоря уже об искусственно созданных "плохих" входных данных, которые есть у любого алгоритма сортировки.

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

"Нулевая стоимость поддержки и реализации" не равно "оптимально по всем параметрам". Помимо стоимости поддержки и реализации есть и другие параметры. Часть из них я упомянул в своем комментарии.

А, у вас какое-то своё толкование задачи оптимизации. В классическом смысле это поиск минимума (или максимума) некоторой функции от этих самых параметров. Как правило, эта функция: полная стоимость решения с учетом ограничений. И в очень редких случаях sort не подходит, или не оптимален.

А, у вас какое-то своё толкование задачи оптимизации. В классическом смысле это поиск минимума (или максимума) некоторой функции от этих самых параметров.

Нет, у меня толкование вполне классическое.


Как правило, эта функция: полная стоимость решения с учетом ограничений.

Что конкретно входит в "полную стоимость решения с учетом ограничений"? И с какими весами?


И в очень редких случаях sort не подходит, или не оптимален.

И, как сказал Prototik, можно назвать мильйон таких "редких случаев", в которых библиотечный sort будет неоптимальным.

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

Найдёте хотя бы три?

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


https://github.com/git/git/blob/master/pack-revindex.c#L27
https://github.com/torvalds/linux/blob/master/lib/sort.c#L199
https://github.com/antirez/redis/blob/unstable/src/pqsort.c#L99


А мой вопрос вы решили проигнорировать? Про количественный и качественный состав "полной стоимости решения с учетом ограничений".

Спасибо за примеры. У каждого из них есть история и на фоне миллионов ссылок на стандартные функции они отлично иллюстрируют мой тезис
Если нет убедительных причин поступить иначе: берите sort из стандартной библиотеки, и не надо ничего выдумывать.

Особенно мне нравится вот этот коммит в гит. Тут и исследование, и обоснование, и видно как начали со стандартной сортировки.

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

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

Я немного утратил нить вашего тезиса.


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


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


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

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

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


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

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

Мне нужно сложить 2 целых числа.
Можете назвать оптимальное решение, оптимизированное по всем параметрам сразу?

Подумайте, откуда взялась поговорка, что «лучшее — враг хорошего».
Всегда есть несколько оптимальных и удовлетворительных решений.
Потому что оптимизировать по всем параметрам невозможно. Мы не живем в статичном мире.
Нам преподаватели в институте по рукам били за такое применение термина «оптимальный».
Не бывает абстрактно оптимальных решений. Решение может быть оптимальным только по определенному критерию оптимальности. При этом по другим критериям это решение зачастую не будет оптимальным (например, по времени решения задачи).
dic.academic.ru/dic.nsf/ruwiki/1587468

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

это весьма субъективно

Субъективно? Вы наверное забыли, что речь идёт о проблеме выбора для субъекта. Очевидно, что его выбор будет субъективным) Я говорю лишь о том, что этот выбор может и должен быть обоснованным, единственным. Всегда есть обстоятельства, которые склонят чашу весов в чью-то пользу. Невозможно существование двух разных, но равных по значениям критериев решений.
Я говорю лишь о том, что этот выбор может и должен быть обоснованным, единственным.
Извините, но вы чушь пишите. Как может быть «обоснованным и единственным» выбор, когда речь идёт о задаче, точной постановки которой мы не знаем?

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

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

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

P.S. Вообще вся эта дискуссия напомнила мне одну хорошо известную всем статью где говорится что, в сущности, от программиста требуется всего две вещи:
1. Толковый и
2. Доводит дело до конца

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

Вот ваше рассуждение про существование оптимального решения «для сферической задачи в вакууме» — оно из той же оперы. Формально — круто, чё… философы были бы довольны… а практически — совершенно бесполезно.
Так про то и речь. Если у вас куча неизвестных в задаче, и все решения кажутся на одно лицо — идите и изучайте ее подробней. Тогда выяснится, что одно решение не подходит по ограничениям, другое очень сложно реализовать, третье и вовсе не решает задачу. И у вас останется одно, то единственно лучшее, оптимальность которого вы сможете обосновать.
Нет, вы ошибаетесь, это широко известная задача многокритериального выбора.

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

Далее составляется матрица альтернатив, выставляются весовые коэффициенты критериям, выполняется свёртка, альтернативы ранжируются и выбирается лучшая.
1. Матрица альтернатив содержит в столбцах альтернативы, в строках — критерии, а в пересечениях — значения каждой альтернативы по каждому критерию.
2. Каждому критерию приписывается весовой коэффициент. Выбор весовых коэффициентов — отдельная известная задача, для которой придуманы 5-10 разных методов решения.
3. Свёртка, в общем случае, может быть разной. В нечёткой логике обычно используется минимаксная, кто-то использует сумму и т.д. В данной задаче я бы использовал сумму.
5. Ну и в качестве целевой функции выбора из ранжированного списка альтернатив я бы использовал [f(c1,c2,c3,...)=a]→min.

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

А вот что вы утверждаете, я понять не могу.

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


Взять тот же latency/throughput. Обычно они связаны обратной зависимостью и улучшая одно — неизбежно ухудшаешь другое.


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

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

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

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

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

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

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

Но определять, надо ли, и до каких пределов жертвовать параметром А в пользу параметра Б — это именно ответственность тех, кого мы тут называем «бизнес».

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

Из моего опыта, истории когда «Вася» выяснял и выяснял требования до мельчайших деталей и строго бездумно им следовал, заканчивались куда плачевнее. Правда, как правило только для «Васи».
Понятно, что нужен баланс. И высооплачиваемые специалисты за то и получают много, что в рамках своих компетенций много и хорошо «угадывают» (я бы скорее назвал это принятием решений, основанном на здравом смысле и опыте вместо строгого расчёта. Но можно и так). И чем выше должность и зарплата, тем больше свобода решений.
«Вася» выяснял и выяснял требования до мельчайших деталей и строго бездумно им следовал
Это скорее про soft skills, когда джун всех уже достал, но профита от него все равно как от джуна.

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

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

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

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

Какой цвет набирать наиболее оптимальнее?))

Единственно верное решение — это «2 x 2 = 4».

Не всегда. На поле
Галуа это не так. Да и если вычислять во float, не в каждом языке программирования 2*2 точно равно 4
Ну и про системы исчисления (двоичные, шестнадцатеричные, десятичные) выше уже написали. Так что таки спектр верных ответов, а не один ответ на все случаи жизни. Такие дела.

Можно реализовать через сложение :)

Обожаю комментарии на хабре, под комментарием "2x2=4" — пара десятков комментариев с аргументированными возражениями и контр-примерами, где ещё такое встретишь?

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

И как же здорово, что теперь есть возможность сворачивать ветки комментариев!
UFO just landed and posted this here

"Лучшее" — по каким критериям?
"Мы делаем быстро, дешево и качественно. Выберите 2 из 3".
Выберите "лучшее".

UFO just landed and posted this here
Тут нету понятия быстро и дёшево

Разве? Программирование — это активность, она занимает время. Следовательно, есть "быстро" и "медленно". Программирование так же требует ресурсов (и как активность, и как решения), и эти ресурсы могут стоить денег. Отсюда — "дорого" и "дешево".


В моем понимании лучшее, это наиболее понятное и менее ресурсоемкое.

Бывает так, что увеличение понятности приводит к увеличению потребляемых ресурсов. И как же выбирать "лучшее" в вашем понимании?

UFO just landed and posted this here
В контексте статьи, не идет речи про быстро, качественно, не дорого

Почему? В статье речь идет об образовании, а в образовании тоже есть временные (и ресурсные) ограничения.

Это самое дешевое для заказчика при условии что оно хоть как-то работает

Как вы меряете "самое дешевое для заказчика"? Самое дешевое в разработке, в работе или в поддержке? Что дешевле — сделанное за Х денег за год, или за 1.2X денег за месяц?

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


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

UFO just landed and posted this here
А тебе попадается необъяснимое поведение в ЯП

Это странно, потому что обычно все объясняется стандартом ЯП, иногда бывает необъяснимое поведение компилятора, но тогда скорее всего надо просто прочитать Errata на него.

UFO just landed and posted this here

Что именно нельзя и не работает? Пример кода, плз.

UFO just landed and posted this here
Я думаю, zagayevskiy спрашивал про Kotlin. Мне бы тоже было любопытно услышать, почему в Kotlin'е нельзя пользоваться Runnable — пользуюсь им часто и с удовольствием :)

Есть интересные случаи, на которые можно попасться, вроде описанного тут, но вообще никто не запрещает использовать Runnable так, как вздумается.
А вот в веб-разработке… честно говоря, не могу вспомнить, чтобы мне попадалась Errata на что-либо, с чем я имел дело…
UFO just landed and posted this here
«менее ресурсоемкое» оно может быть в реализации, в поддержке или с точки зрения машинных ресурсов. Это уже три разных реализации. «Наиболее понятных» решений, если утрировать, тоже может быть несколько, в зависимости от бекграунда тех, кому они «понятнее».
UFO just landed and posted this here

… ну то есть (периодически) весьма противоречащие друг другу вещи.

UFO just landed and posted this here

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

UFO just landed and posted this here
Ну так на это я и написал. Компромисс

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


Всегда можно сложную реализацию обернуть в еще одну функцию/процедуру. С соответствующим комментарием. Что сюда нельзя, тут начинается магия. И не стоит это место трогать.

Это как раз называется "сложно в поддержке".

UFO just landed and posted this here
Ну так и пишут иногда «почти такое же, но более другое», в итоге получается зоопарк «одинаковых, но разных» функций, которые не очень понятно, чем отличаются. Добавляется лишний слой, единственная задача которого — решить, в каком случае какую из этих волшебных функций вызывать. «Чтобы ничего не сломать» превращается в основной принцип разработки и добавление любой мелкой фичи на 90% состоит из изучения вопроса, может ли она что-то сломать, где она может это сломать и как проверить, сломает ли. Никто толком не понимает, что как работает и как модули зависят друг от друга. Никто точно не уверен, что можно выбросить, а что нет.
UFO just landed and posted this here
UFO just landed and posted this here

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

А в чем сложность поддержки в этом?

В том, что "сюда нельзя". Непонятно, что делать, если там проблема, или если маленькая проблема вокруг, или если надо переиспользовать с изменениями.


Заметил тенденцию, все что ранее написано, не трогают. А пишут новое.

Ну то есть ставим крест на переиспользовании.

В моем понимании лучшее, это наиболее понятное и менее ресурсоемкое.

Вы точно программизмом занимаетесь?
Или нагуглили это всё?

UFO just landed and posted this here

Ну, если когда-нибудь займетесь программированием (не только 1С), то сами выведете, что:
"Лучшим решением является то, которое оптимально удовлетворяет требования заказчика".
На минуточку — "оптимально", а не "наилучшим образом".
Потому что удовлетворить наилучшим образом все требования — невозможно как класс.

UFO just landed and posted this here

Для меня оптимально и наилучшим образом — синонимы.

В 1с это утверждение точно так же работает.
Термин «оптимальный» в технике как раз и означает «наилучший» по заданному критерию оптимальности.
dic.academic.ru/dic.nsf/ruwiki/1587468

Видимо в понятие «наилучшим образом» вы не закладываете все нужные заказчику критерии, оставшиеся в умолчаниях, такие как время и финансовые затраты.
Программирование — еще более многофакторное, чем просто быстро и дешево.
Вы, простите, ерунду написали. «Задача А реализована программистами М и Д через Ж...» — реализованное решение? Да. Работает? Да, в основном. Есть спектр лучших решений этой задачи? — Да, вагон! А вот «реализаторы через Ж» как раз «недостаточно глубоко изучили конкретную задачу». Как-то так.
и «реализаторы через Ж» уже выпустили готовый продукт, а М и Д сидят ночами накануне дэдлайна
Не выпустили они ничего, потому как их велосипед CR не проехал :) Я к тому, что посыл «то, что реализовано — правильно» — неверный в корне. Можно реализовать аутентификацию с хранением открытых паролей в базе, и прочими creds в коде. Реализовано? Конечно! А это правильное/хорошее решение?

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


Реализовано правильно, это когда по требованиям.

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

Неявные требования тоже требования. Если есть закон о персональных данных, то это тоже требование…

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

И что? У нас, например внутренняя система учёта времени, там мой пароль 1. Ну утечет он, что с этого? Данные с этой системы чисто информативные для сотрудников…
Зачем там сложная система аутентификации? 7

А зачем тогда там вообще пароль?

Чтобы случайно под другим юзером не зайти..

А раньше был 111?
Прогресс однако.

Смотря где в открыом виде. В дженкинсе есть защищённые переменные, но они отдаются приложению строкой, только в логах маскируются. Это, разве, плохая практика?

Если внутренняя система, если по ТЗ и прочим требованиям удовлетворяет.
Реализовано? Реализовано. Быстро. Дешево.
Не нужно пилить фейсбук там, где достаточно 2 html страничек.
«то, что реализовано — правильно» — неверный в корне.

Расскажите погроммистам 1С

UFO just landed and posted this here
Возможно, дело в том, что в 1С, как правило, идут программисты с заниженной планкой социальной ответственности?
Я сам (сдуру) заглядывал в исходники фреймворка от той же конторы (Битрикс) а от того, что я там увидел, меня трясет от каждого упоминания — такое впечатление, что его делали люди, которые только вчера научились включать комп, а сегодня ваяют на пхп.
UFO just landed and posted this here
А вот «реализаторы через Ж» как раз «недостаточно глубоко изучили конкретную задачу».
Ну, если задача стояла «сделать максимально быстро и забыть», то «М и Д», наоборот — молодцы. Просто, возможно, ТЗ поменялось и «забыть» было вычеркнуто.

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

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

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

UFO just landed and posted this here
Вы правы, обстоятельства действительно могу сильно измениться. Но вот насчёт личных убеждений и точек зрения не могу с вами согласиться. Решение должно быть как-то (вернее, математически и однозначно) обосновано. Чтобы другому программисту или начальнику не пришлось лично проводить исследование вопроса повторно, а он мог бы просто посмотреть на формулы/числа/ссылки.

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


Легко. У меня есть сервис (use-case) регистрации пользователя. Одна точка входа через web-морду, вторая — через CLI.

В этом и соль: есть реализация, но если ты не видишь её сильных или слабых сторон, то ты не станешь успешным программистом. Есть задача: вывести результат 2x2. Хороший программист обязан:


  1. Вывести значение сразу. Тут нефиг думать.
  2. Прогнать в голове все варианты контекста применения этой функции. Потому, что завтра заказчик скажет: ой, ну это чисто пример, там надо чтобы пользователь руками вводил формулу (любой сложности в рамках средней школы), вводил значение всех переменных и получал результат. И ты такой садишься на жопу и начинаешь писать за 1000 рублей калькулятор для алгебры и начала анализа.

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

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

Получается, не выйдет из вас хорошего программиста. Так?

Кроме №9 все тезисы могут быть применены к любой профессии.
Вообще к любой.


Всю статью можно переписать так:
"Если будешь хорошим — то будешь хорошим. А если будешь плохим — то ничего у тебя не получится."

Да и 9-й тезис, в принципе, тоже.

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

Кто так решил?
И что есть "интеллектуальная профессия"?
Илита?


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

UFO just landed and posted this here
Вы думаете, дворнику не нужно принимать никаких решений?

Я думаю что выделять илиту интеллектуальную деятельность как нечто особенного немного неверно.
Работа как работа. Ничего особенного. Дворником отнюдь не проще.

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

Точнее не махать метлой, а мести.
Махать-то сможет, мои дети в 2 года так могли. Именно махать метлой, не мести.

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

Для этого требуются какие то особенные умственные способности, что вы дворника в интеллектуальную профессию записали?

Я не записывал дворника в интеллектуальные профессии, просто не был уверен в
Я могу делать работу любого дворника

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

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

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


PS. надеюсь понятно, что это просто взгляд с другой кочки зрения, а не повод для холивара :-)

Но интелектуальной профессия "дворник" от смены точки зрения всё равно не становится.

Конечно не становится!
Чтобы быть дворником, надо кроме головы еще и прямые руки иметь.
А с прямыми руками ту же Windows написать сложно (такой, какая она есть)


Так что нет, не становится.

То есть вы согласны, что дворник — не интелектуальная профессия? Тогда с чем вы спорите?

Как только дадите четкое, явное и неоднозначное определение понятия "интеллектуальная профессия" — сразу же.
PS. насколько мой склероз подсказывает — в ОКПДТР ничего такого нет.

TL;DR;:
«Если вы несамостоятельный ленивый нелюбознательный хмыропуз, то из вас ничего не получится».
А вы попробуйте. Подобраться к такой кормушке намного сложнее, чем стать сеньором транснациональной корпорации.

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

Я бы немного перефразировал: переступить через некоторые свои принципы, подбираясь к кормушке, да, сложнее, чем стать сеньором в IT.
Но с другой стороны, дефицит специалистов во многих (во всех?) отраслях довольно велик, как и в политике тоже.
(на правах грустного юмора) Почему мне не быть хорошим программистом несмотря на 15 лет опыта:

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

Мне интересно, как написан код библиотек\фреймворков и т.д., но мне всё равно, как устроен компьютер (знаю на уровне школьника и ладно)

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

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

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

Решит коллега. Поменяю саму задачу или способ решения.

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

Нет, ведь самое трудное еще впереди. Или просто еще 10 таких же проблем (тикетов)

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

Когда мне было 20 — все давалось легко и быстро. Теперь я точно знаю, что мне не понять, например, криптографию и другую высшую математику, и просто туда не лезу.

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

Потому что, шьёрт побьери, это рутина! Это выматывает! Это бессонные ночи и литры кофе! И вообще, очевидное и изящное решение, как известно, приходит во сне неожиданно, само.

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

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

Ваше мышление негибкое, узкое и/или неорганизованное

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

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

Когда-то я доводил код до формы, устраивающей меня. Сначала писал простыню говнокода, которая просто работает, а потом рефакторил, придавая универсальность и гибкость, в попытках написать идеальный код… Теперь я останавливаюсь на простыне, которая хотя бы не плоха — идеальный код никому не нужен, да и тот код, что я нахожу красивым, врядли *всем* покажется тоже красивым.

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

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

А потому, у меня много опыта и я не был и не буду хорошим программистом :D
UFO just landed and posted this here
Я все же зря написал про «простыню», мой код все же не напоминает код школьника и я даже прошел этап «мне стыдно за код, написанный несколько лет назад» — я иногда открываю свои проекты, писаные много лет назад, чтобы что-то улучшить, добавить. Смотрю — и не нахожу возможных улучшений (все же я плохой программист, да? :) )
Однако я пишу код так, что он может быть нечитаем со стороны. Например, я инлайню сложные выражения, если они используются однажды, вместо вынесения их в отдельную переменную. Также (речь про Java) раньше я ставил final и this. везде, где только можно (сейчас я так не делаю)

Т.е. меня будут ругать за то, что я не пишу
int width = innerWidth/2; // здесь может быть выражение и посложнее этого
int height = innerHeight/2;
out(width, height, text);

а пишу
out(innerWidth/2, innerHeight/2, text);

за что меня часто и ругают «непонятно, что здесь написано!»

Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.

Зато подход «сначала пишем как пишется, потом рефакторим до годного» оправдывает себя тем, что не приходится задавать вопросы «а что, если...» на раннем этапе — сначала ставится вопрос «как решить эту задачу», и когда уже PoC-код работает, переходим к рефакторингу «сделать код универсальным, сделать код безопасным»
UFO just landed and posted this here
Смотрю — и не нахожу возможных улучшений (все же я плохой программист, да? :) )

Смотря на каком уровне. Если на уровне процедуры/метода/функции, это нормально. А если на уровне архитектуры приложения не видите, что улучшить, у меня плохие новости.

Угу, а как оно было 15 лет назад? :) Все-таки это не вопросы померить то, насколько ты опытный программист сейчас, а то, сможешь ли ты дойти с нуля до опытного. Подстажите, плиз, как стать опытным программистом если нет ни любопытства, ни желания что-то изучать и не испытываешь удовольствия от того, что получил работающее решение?
15 лет назад мне было всё интересно.
Я благодарен отцу за то, что еще раньше, когда мне было 10 лет, у него получилось заинтересовать меня программированием и обучить основам бейсика на Спектруме, поэтому вопрос «кем я буду, когда вырасту» был однозначно «программистом».
Мне было интересно все, это был сумбурный подход «все интересно, во всем разобраться, все попробовать сделать самому», кладбище мертворожденных проектов тянет на отдельный мир.

Извините, а отвечая на Ваш вопрос «как стать опытным программистом если нет ни любопытства, ни желания что-то изучать» — иметь мотивацию, которую я наблюдал у младших коллег «за это хорошо платят, поэтому идем на SO, копипастим работающий код и изменяем под свои нужды»
Эх, каюсь, но подходом «не знаю как сделать — нахожу решение на SO, понимаю принцип и пишу свой код» пользуюсь и до сих пор, а то и даже «не понимаю код, что написали на SO — копирую как есть, изменяю те места, которые понимаю, но до тех пор, пока код работает»
Категорически извиняюсь, честно говоря, у меня имеется ощущение, что вы отчасти лукавите. :)
То ли специально чрезмерно иронизируете, то ли преувеличиваете своё ощущение усталости от похожих задач, то ли еще как назвать. Например:
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы».

Противоречит упомянутому ниже вашему хорошему качеству:
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.

В любом случае, хочу отметить пару опасных допущений данной фразы:
мне не быть хорошим программистом несмотря на 15 лет опыта… А потому, у меня много опыта и я не был и не буду хорошим программистом.

1) «Хороший» программист (инженер) — не звание на всю жизнь, нельзя лишь почевать на лаврах прошлых заслуг, человек на определенном этапе развития может быть таковым, а потом может выгореть или решить немного отдохнуть и перейти в режим просто «Норм» — в среднем нормально решает знакомые задачи знакомыми методами без лишнего погружения и разбора деталей.
2) Цифра стажа — не определяет автоматически попадение в категорию «Хорошего», лишь повышая вероятность накопления определенного опыта, т.к. см. 1 первый — важно и как человек провел эти года, и каков он сейчас.

Честно говоря, первым делом полез посмотреть, сколько у вас подписчиков и не входите ли вы в Кольцо Переводов… =D

Не, это просто очередная проба пера.
Ну или зарождение нового Редактора Хабра (тьфу-тьфу).

Нет правильного или неправильного ответа. Есть работающий или неработающий вариант :)
Любознательность — это конечно хорошо, главное в скорости и любознательности не выгореть)
По опыту — выгорание происходит тогда, когда творческая натура сталкивается с рутиной исправления 100500 тупых багов.
В моём опыте бо́льшая часть выгоревших — это люди, не испытывавшие ни малейшей тяги к программированию, но пришедшие в него за деньгами или по настоянию родителей.
Возможно, к ним уже не применим термин «выгорание», т.к. они уже пришли «выгоревшими», но какое-то время отчаянно боролись между «мне это не интересно» и «но за это же платят» в постоянном компромиссе «как сделать быстро, некачественно, но чтобы мне за это ничего [плохого] не было»
Если они сумели полюбить программирование хотя бы из-за денег, то это уже какая-никакая тяга. Врождённая неотключаемая зацикленность на одной-единственной профессии встречается редко. Средний человек по умолчанию не имеет тяги вообще ни к чему, но потом собирается с силами и заставляет себя полюбить какую-то сферу деятельности.

Ну а про способы борьбы с рутиной и депрессией, они у всех разные. К сожалению, многие идут по пути наименьшего сопротивления и выбирают один из трёх вариантов: спиться, зожнуться, либо сектантствовать. Хотя как по мне, эти варианты практически бесполезны, и огонёк не возвращают. Творческую натуру надо кормить разнообразными творческими занятиями, тогда она будет периодически проявляться и в работе.
Суть программирования есть решение проблем. Это и есть причина создания компьютеров! Всякий раз, когда вы начинаете работать над программой, вы сталкиваетесь с целой «стопкой» проблем

Мне кажется, лучше рассматривать программирование как стопку задач, а не стопку проблем )))
Проблема — это ИМХО нечто внезапное и неприятное. Например, когда посреди разработки монитор сдох.
А написание кода — какая же тут проблема, если добровольно за это взялся?

Даже в такой формулировке это всё равно проблемы.

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

И при таком подходе «проблема -> задача -> анализ -> решение» не возникает противоречия, а неизбежный фрустрирующий фактор сведен до минимума.
Решение:
Скорее всего это проблемы перевода (pun unintended)
В английском слово «problem» имеет смысл «задача», в контексте решения задач. «Solve this problem» — «Решите эту задачу». Во время перевода смысл слегка потерялся :)
10 критериев — это слишком много.
Для многих достаточно одного: вам 18+ лет и вы ни разу ничего не прогали в 3 часа ночи.
Поясню. Призвание к 18 годам должно уже проявится, и что-то на каком-то языке программирования вы уже должны уметь писать. Без призвания сидеть перед монитором с буквами — это свою угробить жизнь. Чтобы сидеть и прогать в 3 часа ночи нужно 1) любопытство и я бы даже сказал страсть 2) воля к победе и бесстрашие перед множеством проблем, упорство 4) способность разгребать доки и чужой код 5) самостоятельность… короче, 1 критерий вместо 10, и в отличие от перечисленных в статье этот один легко определяется (каждый сам для себя легко на него ответит, самообман невозможен).
Согласно вашему критерию фактически ниодна девушка не может быть программистом.
UFO just landed and posted this here
Давайте внимательнее. Здесь важны соотношения. Они увлекающиеся, но если школьница не сидела прям до 3 ночи за программированием, то это не означает, что ей не быть хорошим программистом. Потому что это нормальное поведение для одаренной школьницы, которой интересно программирование.
Напротив, если парень не сидел за программированием ночами уже в школе, то его шансы стать хорошим программистом сильно падают, потому что большинство из них сидит.

Офтоп: Как-то в детстве я сказал, что не намерен плакать по поводу смерти Брежнева, потому что мы не родственники и получил кучу «минусов» от учителя и одноклассников, хотя в целом это была правда. Что изменилось с тех пор? Покажи людям красную тряпку и готовься отгребать :).

То есть вы считаете, что поведение (в отношении учебы) увлеченного школьника зависит от того, какие у этого школьника гениталии?

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

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

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

школьницы не сидят ночами экспериментируя с технологиями программирования
Вы не могли бы пометить, на основании чего такой вывод сделан? Мне действительно интересно =D

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

UFO just landed and posted this here
Объективное восприятие. Предубеждений у меня нет. Вот глупость и самообман бесит.
Предубеждений у меня нет.

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

Я не воспитан в обществе.

Гм. Мне казалось, вы упоминали одноклассников. Следовательно, вы учились в школе. Нет? У вас нет высшего образования? Вы не работали в коллективе?


У меня критический научный склад ума.

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

UFO just landed and posted this here

Критерий, несомненно, неверный: школьники не сидят ночами, экспериментируя с технологиями программирования, но некоторые все равно потом становятся программистами. Я вот, например.


Но сказали вы совсем не это.

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

Сидят. Я сидел. Все мои друзья программисты которых знаю сидели.

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


Так что нет, для мужчин этот критерий такой же негодный.

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

В точно такой же степени?

Ну да. Вы привели один контр-пример, я привел один контр-пример.


Моя статистика говорит обратное.

На какого размера выборке собрана ваша статистика, как проводились измерения, какой критерий оценки статистической достоверности использовался?


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

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

Собственно единственный тезис заслуживающий обсуждения — это тот факт, что мужчинам свойственно гораздо сильнее увлекаться техникой и в частности программированием чем женщинам. Увлечение, которое для мужчины почти как основной инстинкт, для женщины карьера, хобби, самоутверждение, одна из интересных вещей. Сидеть в подвале, набитом электроникой и компьютерами, как доктор зло — типичная мечта мальчишки конца 80, и фактически ниодной девчонки того времени (исключения конечно существуют всегда, но это исключения). Кстати, я начинал работать в отделе АСУ, полностью состоящем из женщин программистов, а потом работал в коллективе где отношение было пополам. Так что я знаю о чем говорю.
Сейчас программирование превратилось в рутину, обычную профессию, поэтому не особо знаю что твориться в головах у молодежи сейчас.
Для меня это выглядит как троллинг. Вам хочется нарисовать себе врага и переболтать его и все тут.

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


Это был довольно несерьезный критерий, высказанный не мной.

Вы однако, с ним согласились: "Критерий годный для мужчин".


В основном это верно.

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


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


Или вы хотите спорить именно насчет режиа дня, засиживания ровнго до 3 часов и так далее?

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

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

Почему?


(ну и сразу: как это доказать?)


Кого ни спроси, все нерды с детства по сути.

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

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

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

Да, глупость не уникальна для мужчин
Зачем ей это (откуда такие мотивации)?

Затем же зачем и вам
программистов мужчин больше

В восьмидесятые, в СССР, было ровно наоборот и програмирование считалось более женской професией (сужу по рассказам родителей) да и сейчас ситуация исправляется и женщин в ИТ все больше

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

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

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


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

Эээ… конечно, нет. Даже если предположить, что первое предложение верно (что не факт), второе из него никак не вытекает.

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

они точно есть и в приличном количестве.

… а откуда взялось "в приличном количестве"?


Им просто не так интересно по каким-то причинам.

… в вашей выборке?


Больше гормональным или больше культурным не знаю.

Не знаете, но говорите, что причина в поле.


Выглядит как отрицание очевидного.

Вам очевидно, что женщины в среднем должны превосходить мужчин? Или вы о каком-то другом возражении?

… а откуда взялось «в приличном количестве»?
Слово «приличном» появилось, чтобы вы не привели единичный пример из интернета. Но вы все равно нашли к чему прицепиться. Раз вы выкручиваетесь, значит у вас нет настоящих оснований для уверенности. Вам просто хочется отстаивать модное мнение, выгодное вам психологически. Если бы сейчас был СССР, то вы так же горячо убеждали бы меня в преимуществах коммунизма.
Если бы вы вместо демагогии сразу привели какие-то убедительные примеры, я бы сразу сдался. Потому что была бы ваша выборка против моей.
… в вашей выборке?
В вашей в целом тоже, если судить по примерам, которые вы приводили выше.
Не знаете, но говорите, что причина в поле.
Мотивация скорее всего связана с полом, но я не уверен, что эта связь настолько сильная, что будет иметь принципиальное значение в другой культуре воспитания женщин.
Вам очевидно, что женщины в среднем должны превосходить мужчин? Или вы о каком-то другом возражении?
Вроде того. Тезис был довольно ясный, возражений к нему я не увидел.
Чтобы вы не привели единичный пример из интернета.

Ну то есть это какое-то придуманное вами утверждение. Окей.


Раз вы выкручиваетесь, значит у вас нет оснований правоты.

Оснований какой правоты, собственно? Я пока просто задаю вопросы и привожу примеры.


В вашей в целом тоже.

О нет. В моей выборке женщинам не менее интересно, чем мужчинам.


Мотивация скорее всего связана с полом

Почему бы? Как это доказать?


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

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

Я могу повторить возражение, если вы с первого раза не увидели:
Это не возражение. Это просто отрицание. Давайте поясню.
Возьмем 100 китайцев и 100 индусов. Допустим, все индусы работают программистами, а китайцы пока не имеют такой возможности или желания по каким-то причинам. Потом китайцы открывают для себя эту возможность. При этом, работа интересная и платят дочерта. В какой-то момент 10 китайцев тоже пробились в программисты.
Теперь сравниваем средний уровень китайцев и индусов на рынке. Если даже предположить, что в программисты попали совершенно случайные китайцы, то они должны иметь тот же средний уровень что и индусы. Но на самом деле это очень мало вероятно. Первые — это всегда лучшие, потому что это те кому интереснее и у кого лучше получается. Значит средний китаец на рынке должен быть сильнее среднего индуса (пока соотношение типа 10 к 100).
И аналогично это по идее должно работать для женщин и мужчин…
Если даже предположить, что в программисты попали совершенно случайные китайцы, то они должны иметь тот же средний уровень что и индусы.

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


Первые — это всегда лучшие, потому что это те кому интереснее и у кого лучше получается.

А чем, простите, обосновывается это утверждение? Первые — это просто… первые. Те, кто первым попробовал. Может быть, они просто самые жадные. Или самые бедные. Или самые удачливые.


И особенно это относится к "лучше получается". Лучше, чем у кого? Они первые, им не с кем сравнивать.

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

Что конкретно вам не понятно в моем комментарии? Вопрос, на чем основано ваше утверждение, что первые — всегда лучшие?

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

Вот вам и наглядная демонстрация ваших предубеждений.


То, что для вас это "естественное предположение", не делает его верным — или хотя бы очевидным для других. Я вот не понимаю, почему первые люди, рванувшие в сторону "высокооплачиваемой, престижной и непыльной работы" должны быть лучше подходящими для этой работы.


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

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

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


Скорее возьмут все равно тех что выше среднего.

Выше среднего чего? Среди кого?


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

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

Эта гипотеза никак из моего сообщения не вытекает. Это ваша гипотеза, вы с ней и разбирайтесь.
Я вынужден был ее сочинить от вашего имени, потому что вы не объясняете как так получается. Вы просто пишите что не согласны и все. Типа это все равно ничего не доказывает и всегда можно найти другие объяснения. Можно всегда, но обычно работает наиболее простое и понятное объяснение (а не наиболее политкорректное, увы).

Я и говорю: сами сочинили — сами и разбирайтесь.


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

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

Я не вижу смысла (и не могу) объяснять что-то, чего я не наблюдаю. В компании, где я работаю, ситуация другая.


Что останавливает женщин, которые потенциально могут быть ведущими программистами компаний, но сегодня не работают программистами пойти в программисты

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


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

Я не вижу смысла (и не могу) объяснять что-то, чего я не наблюдаю. В компании, где я работаю, ситуация другая.
Хорошо, принимается. Но я пока такого не видел. Предполагаю, что вы рассматриваете только подмножество программистов, делающих довольно простую и рутинную работу, исключая из выборки тех кто решает действительно сложные задачи. Это подгон под желаемый результат.
О, множество вещей, вот прямо начиная с общественной позиции «это не женское дело» и распространенного мнения, что женщины худшие программисты, чем мужчины.
Не проходит. Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты. Женщин со средними способностями прокинут из за предвзятости. И затем мы должны наблюдать картину, когда средняя женщина программист намного круче среднего программиста мужчины (хотя возможно ее никуда особо не пускают). Но это не та картина, которую мы наблюдаем. Нужно другое объяснение.
Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты.

«одаренный специалист» и «умеет пробиваться через сито предрассудков» это разные скиллы.
Женщин со средними способностями прокинут из за предвзятости.

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

Какого конкретно?


Проблемы предрассудков сильно преувеличены.

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

UFO just landed and posted this here

Отнюдь. Бывает, и я регулярно с ними сталкиваюсь. Просто многие люди их не замечают (и/или не испытывают от них дискомфорта).

UFO just landed and posted this here
Скорее «не замечают».

И это лишний раз подтверждает, что проблема предрассудков не преувеличена.


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


Когда кто-то говорит про то, что надо кормить семью, то такого неодобрения нет.

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

UFO just landed and posted this here
Я лёгкий намёк на это распарсил в первой фразе из того, что я тогда процитировал

Вы распарсили неверно (что, кстати, опять показывает распространенность предрассудков). Но не суть, да.


Это (и реакция социума) реинфорсит позицию мужчины как добытчика, что мужчинадолжен (в данном случае зарабатывать бабло), не так ли?

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

UFO just landed and posted this here
Там по полу автора всё видно

Эээ… но нет же. Если мужчина пишет "мне семью кормить", это не обязательно значит, что ему кормить семью, потому что он мужчина. А какие еще выводы вы можете сделать из пола автора?


Никогда не встречались с феминистическим мнением

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

UFO just landed and posted this here
ИМХО ещё один признак предубеждений, просто уровнем выше.

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

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

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


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

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


Женщин со средними способностями прокинут из за предвзятости.

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


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

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

Необходимая оговорка — я, естественно, сравниваю в рамках сопоставимого опыта: если, грубо говоря, все девушки распределены в опыте 3-15 лет, мужчин с опытом 25-35 мы не рассматриваем.


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

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

Это не исследование.


просто потому, что слабые лучше сумели себя подать.

Вообще-то, это регулярно происходит безотносительно пола собеседуемого.


Никакие предрассудки не заставят бизнес закономерно брать слабых женщин вместо умных женщин

А я, собственно, нигде и не говорил о том, чтобы брать слабых вместо сильных. Я говорил о том, что не брать вообще. И вот это я видел своими глазами.

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

Не связан. Потому что нет никакой "природной мотивированности" к профессиям.


Но. Вы спросили "что останавливает женщин [...] пойти в программисты" — я ответил.


я и предложил сравнивать не количество женщин и мужщин в программировании а средний уровень среди имеющихся

И как вам это поможет оценить мотивированность?


Что еще веселее, как вообще вы предлагаете оценивать (не то что сравнивать) "средний уровень"? Как правильно составить выборку? По какой методике оценивать? Как усреднять?


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

Но. Вы спросили «что останавливает женщин [...] пойти в программисты» — я ответил.
Вы ответили что останавливает всех женщин, но не объяснили почему это отсеивает лучших программистов-женщин но не отсеивает худших. В целом ваш ответ был «такой аномальный отсев возможен», возможен, но это не убедительно.
И как вам это поможет оценить мотивированность?
Никак. Мотивированность — самое простое объяснение аномалии в относительном качестве специалистов мужчин и женщин, которую я наблюдаю. Учитывая насколько мало женщин идут в программисты можно ожидать, что это будут просто супер-специалисты, но они в лучшем случае не уступают. Другие объяснения для меня выглядят слишком сложными и высосанными из пальца.
К слову говоря, я не уверен даже что я прав. Поэтому и поддерживал этот спор. Слишком долго его к сожалению поддерживать не получается, потому что карма и так уже улетела слишком далеко.
Вести подобные споры, увы, то же самое что отстаивать генетику во времена Мичурина. Очень неблагодарное занятие. И кстати, этот слив кармы указывает на то, что большинство поддерживает вашу позицию. Тогда где все эти жено-ненавистники о которых вы говорите непонятно.
Вы ответили что останавливает всех женщин, но не объяснили почему это отсеивает лучших программистов-женщин но не отсеивает худших.

Ну да. Я не вижу, зачем "лучших" должно отсеивать больше, чем "худших".


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

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

Ну да. Я не вижу, зачем «лучших» должно отсеивать больше, чем «худших».
Конечно не должно, потому и не видите.
Нарисуйте картину, как вы себе это представляете. Имеется, скажем 5% потенциально гениальных и мотивированных женщин программистов. И 15% менее способных, которые тоже хотят быть программистами.
Допустим, среди общего числа программистов женщин 5%. Тогда почему это не те 5% гениев? Какой фильтр остановил эти 5% гениев и вместо этого пропустил всех понемногу?
Предрассудки не могут фильтровать только гениев. Это вы вроде согласились.
Бизнес IT всегда берет лучших из приходящих кандидатов и никогда намеренно не будет искать посредственностей, отвергая умных (потому что посредственности «удовлетворяют требованиям»). С этим почти согласились.
Возможно эти 5% просто не идут работать программистами. Тогда это подтверждает мою теорию: женщинам не интересно. Другой мой вариант — они идут, но не реализуют свой природный потенциал в полной мере потому что им не настолько интересно как мужчинам.
Ваша версия фильтра? Моя картина проста и понятна.
Вы не можете предложить никакой убедительной картины. Вместо этого вы только обвиняете мою в недоказуемости.

Могу опять предложить гипотезу от вашего имени. Допустим, одаренные женщины не ходят идти программистами, потому что тоже верят в предрассудки, что это не для женщин и что с серьезными задачами им все равно не справиться, а посредственным все равно — они просто хотят денег. Т.е. женская половина человечества просто еще не открыла для себя всю притягательность IT и не верит что может работать наравне с мужчинами. Это возможно, хотя не очень соответствует тому что я вижу.

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

Не так. Имеется 5% потенциально гениальных и, вообще говоря, независимо выбранные 5% мотивированных.

Но этот нюанс точно так же работает и для мужчин, если предполагать что у женщинам программирование само по себе вызывает такой же интерес как и у мужчин. Значит на соотношение картин не должен влиять
В Вашей теории есть сразу 2 спорных момента:
1. Утверждение, что есть некая «врождённая гениальность в программировании», которая видна работодателю сразу и бесспорно. Уже от рождения известно, что конкретно эта девочка может попасть в те самые 5% гениальных программистов.
2. Утверждение, что такая «гениальность» не всеобщая, а конкретно в программировании.
Я не вижу этому сколько-нибудь заметных подтверждений. Можно ли было в возрасте 10 лет сказать про Дональда Кнута или Линуса Торвальдса, что они станут программистами хоть чуть выше среднего? Или что они не стали бы отличными хирургами, космонавтами или водителями автобусов?
Что ещё важнее, а понимали ли они сами это, чтобы делать хоть какие-то усилия чтобы куда-то «отфильтровываться»?

Ну то есть теперь, постфактум, конечно можно найти кучу свидетелей, которые «уже тогда видели». А реально, посмотрите на группу школьников — кто из них в будущем станет гуру программирования? Да даже на собеседовании джуна попробуйте понять, кем он будет через 5 лет.

Ваша версия фильтра?

Вы правильно описали, но только с поправкой — это не сами девочки «не верят», а их окружение. Например, я изучал компьютеры с 1 класса, на кружок по программированию пошёл в 7м. Даже если у меня и был к тому интерес, то всё равно это не было 100% только моё желание, особенно в коллективе, где от мальчика уже много лет ожидается любить футбол и программирование, а от девочки шитьё и готовку. И уж тем более я в том возрасте не понимал «всю притягательность IT», а просто ходил в школу как положено.
В Вашей теории есть сразу 2 спорных момента:
Эти моменты спорные, но они симметрично влияют и на статистику для мужчин, если предполагать что мужчины и женщины одинаковы. В итоге аномалия с гениальными женщинами в IT все равно должна работать.
Если бы природные способности вкупе с природными мотивациями вообще почти ни на что не влияли, тогда да, это испортило бы картину. Но по моим наблюдениям почти только они и важны.
Да даже на собеседовании джуна попробуйте понять, кем он будет через 5 лет.
Если нужно отличить два противоположных типа людей — будущих блестящих специалистов и обузу для коллектива, то по-моему это очень легко отличить.
Вы правильно описали, но только с поправкой — это не сами девочки «не верят», а их окружение. Например, я изучал компьютеры с 1 класса, на кружок по программированию пошёл в 7м. Даже если у меня и был к тому интерес, то всё равно это не было 100% только моё желание, особенно в коллективе, где от мальчика уже много лет ожидается любить футбол и программирование, а от девочки шитьё и готовку. И уж тем более я в том возрасте не понимал «всю притягательность IT», а просто ходил в школу как положено.
У меня другой опыт из конца 80-х. Я не ходил на кружки, но все детство ждал и мечтал, пока в продаже появятся компьютеры. Когда появились всякие БК-РК (в 8-м классе), сидел безвылазно. При этом программистом я быть не планировал (IT как отрасли еще не существовало), на программирование не поступал и начал пытаться жить программированием только после института. Получалось не очень, действительно пошло только после 38 лет.
Мой одноклассник тоже мечтал «о подвале с электроникой как у доктора зло», купил комп и сидел за ним днями и ночами. После многих попыток в программисты так и не пробился. Отец моего друга работал сантехником. Он купил комп и сидел с ним ночами, не планируя менять род деятельности (его дети стали программистами). И так далее.
Я здесь не вижу каким образом «окружение» заставляло нас всем этим заниматься. Это был просто некий техно-инстинкт в чистом виде. И я не уверен, что при должном воспитании он в той же степени был бы свойственен женщинам. В какой-то да, но не уверен что в той же.
Сейчас ситуация размылась: компьютеры везде, одиночка не может сделать ничего существенного а программирование стало просто обычной профессией, поэтому та важность изначальной природной мотивации и различия в мотивациях, которые мне были видны со всей очевидностью сейчас не так заметны.
Мой одноклассник тоже мечтал «о подвале с электроникой как у доктора зло» [...] Я здесь не вижу каким образом «окружение» заставляло нас всем этим заниматься.

Какого пола Доктор Зло?


Это был просто некий техно-инстинкт в чистом виде. И я не уверен, что при должном воспитании он в той же степени был бы свойственен женщинам.

Вы слышали про Грейс Хоппер?

Какого пола Доктор Зло?
Конечно-же его привлекал подвал доктора Зло а не пример доктора Зло. Вообще, это было в СССР, «доктор зло» — это мой сегодняшний обобщенный образ, неизвестный на тот момент детям и я не помню в каком контексте в его мечте фигурировал этот подвал с компьютерами.
Вы слышали про Грейс Хоппер?
Отличный пример. Девочка родилась с стойким врожденным влечением к технологиям и в результате ни женское воспитание, ни окружение ни предрассудки (это в начала 20-го века то, когда непокорное дитя родители могли в психушку сдать или лоботомию сделать!), не смогли ее остановить. Отсюда следует, что основной фактор успеха в области технологий — природная тяга к технологиям а не то, кем ребенка видит общество, предрассудки, воспитание, социальные препоны.
О том, насколько часто с подобной тягой рождаются девочки и мальчики этот пример ничего нам не говорит.

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

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

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


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

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


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

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


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

Но на наблюдаемое мной (и особенно — моими коллегами, которые не ведут собеседования) распределение навыков это повлияет.

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

… вы так говорите.


третий не верен применительно к нашему случаю (рекрутинг изначально не случаен с обоих сторон)

А кто что-то говорил о рекрутинге? Речь шла о том, кто стал программистом, а это не рекрутинг.


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


четвертый — опять подмена начального тезиса

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


речь о всем рынке IT

А вы лично наблюдаете за всем рынком IT, чтобы делать о нем выводы? Я вот точно нет.

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

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

Уже после 3х лет говорить об инстинктах слишком сложно. С одной стороны я тоже на удивление замечаю, что в 2 года моему сыну интересны тракторы а дочери куклы. С другой — я лишь хочу себя тешить уверенностью, что я воспитывал их одинаково (включая выбор одежды, слов, интонаций). При этом абсолютно очевидно, что бабушки/дедушки, друзья, садик и т.д. не настроены так нейтрально. В какой степени это повлияло — можно только гадать, измеримых данных нет.
Сложно сказать, где тут «природная мотивация», а где влияние общества.
Тогда почему это не те 5% гениев?

А почему должны быть?


Какой фильтр остановил эти 5% гениев и вместо этого пропустил всех понемногу?

Например, случайный отбор.


Ваша версия фильтра?

… вот, например, случайный отбор. В этом случае, при ваших цифрах, на больших выборках вы будете наблюдать среди всех программистов распределение, близкое к оригинальному (т.е. ~1/4 "гениев").


Бизнес IT всегда берет лучших из приходящих кандидатов

Это, заметим не всегда так. Мы вот в прошлом году не взяли "лучшего" кандидата, потому что этот кандидат был overqualified для нашей позиции. На одного, в вашей терминологии, гения меньше в нашем распределении.


Могу опять предложить гипотезу от вашего имени.

Пожалуйста, предлагайте свои гипотезы от своего имени.


Замечание: ваш пример с любителями бабочек в другом сообщении ошибочен.

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


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

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

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

UFO just landed and posted this here
У вас есть что-то кроме anecdotical evidence?

Лично у меня — нет.


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

Есть.

UFO just landed and posted this here
Ну, тогда я только могу повторить предыдущую фразу про забавность.

Я, собственно, с ней и не спорю.


То есть, получается, что разницы-то между полами в этом плане и нет?

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


Получается, что женщинам тут лучше?

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

UFO just landed and posted this here
А по моим — ровно наоборот.

Вполне возможно.


На закон, я слышал, можно влиять.

Можно.


Однако, мы этого почему-то не наблюдаем.

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

UFO just landed and posted this here
Рациональный подход — это такая штука, которая при равных вводных приводит к равному результату.

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

UFO just landed and posted this here
Я исхожу из довольно небольшого множества предположений.

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

UFO just landed and posted this here

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

Объясните по каким причинам немногочисленные работающие женщины программисты обычно в среднем не дотягивают по уровню даже до среднестатистического


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

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

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

Это отличный пример, отлично подходящий для женщин тоже. Рассмотрим случаи:
1. Вам пришло 5 резюме, случайным образом все от индусов.
2. Индусы имеют систему образования, комьюнити, наставников у которых можно учиться. 10 пробившихся китайцев всего этого не имели и строят с нуля.
3. Допустим 5% популяции гениальны. А чем заняты остальные 90 китайцев? Есть немалый шанс, что 5 гениальных тоже будут там, а вот те 10 — это самые слабые. А вот 5 гениальных индусов будут программистами.
4. Как сейчас популярно, Вам поставили задачу нанять 22 программиста, и строго 50/50 китайцев и индусов. Вы прособеседовали и выбрали 11 хороших индусов, всех 10 китайцев пришлось взять без отбора, ещё и одного который вообще не умеет программировать.
5. Комбинация 1+2. Соседняя фирма наняла 8 индусов и 8 китайцев, причём китайцев отобрала лучших и платит им немало. Вам осталось выбирать из 92 индусов и 2 китайцев.
6. Физиологический. Представим, что китайцы, отучившись до определённого уровня, обычно на 2 года уезжают в Тибет и забывают о программировании вообще. И повторяют это ещё пару раз. Индусы же продолжают дальше работать и набираться опыта.

Попробуйте оценить видимый средний уровень во всех вариантах.
UFO just landed and posted this here
Тут я потерялся, кто из них — женщины, так как всякие буткампы только для женщин есть, курсы только для женщин есть, и так далее, а аналогичных вещей только для мужчин нет.

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


(это не считая того, что аналогии врут)

UFO just landed and posted this here

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

UFO just landed and posted this here

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

Поэтому случайно он не был нердом.

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


Те кому доверяют отвечать за архитектуру чего-то не совсем ординарного или ее часть как минимум.

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


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

Начните хотя бы с одного примера. Пока что вы приводите примеры, в которых собственно мотивации никак не обозначены.


Можете представить, чтобы подобную глупость сделала женщина

Могу. Более того, я пару подобных случаев знаю.


Зачем ей это (откуда такие мотивации)?

А зачем это вам? Я с равным успехом ничего не знаю ни про их, ни про вашу мотивации.


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


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

… это, однако, не помешало вам уверенно сказать, что мотивации зависят от пола (а не от воспитания).

UFO just landed and posted this here
ссылается на гипотезу о том, что люди разного пола обладают разными особенностями концентрации внимания.

Это та гипотеза, согласно которой девочки усидчивее и прилежнее?


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

Ой, нет, все наоборот.

та гипотеза, согласно которой девочки усидчивее и прилежнее?
А разве второе — не факт? Академический успех, по-моему, и есть оборотная сторона прилежания (при условии равных способностей).
А разве второе — не факт?

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

Так, я же написал в своем критерии про 18+. Для <18 мой критерий неприменим, для <18 все гораздо сложнее.

Знаете, не обязательно что-то делать в три часа ночи, чтобы это любить.


А у некоторых людей больше одного интереса.

Не обязательно. Но ни разу не засидеться за любимым делом забыв о времени — это странно...

Для тех одаренных и умных людей, которые с огорчением поняли, что им не быть программистами:

Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Критерий правильный, но многие сейчас частично без этого обходятся. Особенно если программист женского пола.
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом…
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Это справедливо для большей части профессий. Без этого вообще стать кем-то сложно.
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Некоторым радость решенной проблемы заменяет радость получения зарплаты. Это конечно не лучший вариант но тоже работает.
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Многие люди ненавидят учебу (если говорить о формальном учебном процессе, то у меня это просто фобия). Ничего фатального, можно всему научиться по мере поступления проблем на работе. Непонимание сначала накапливается, потом оно начинает мешать, потом можно почитать книгу на досуге и все недостающее осознать.
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом…
Если вы ждете, что кто-то будет думать за вас, и не хотите всматриваться в детали своего положения, вам ни за что не стать успешным программистом…
Если вы не очень гибки в своем мышлении и у вас сложности с организацией вашего кода, а также ваших мыслей, вам ни за что не стать успешным программистом.
В целом верно, но в реальности не все так категорично. Среди программистов, как и в других областях, людей, которые предпочитают кодить вместо того чтобы думать хватает. Работа иногда находится и для них.
Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.
Однозначно это проблема в образе мышления, от которой надо просто избавиться. Здесь дело даже не в программировании. Мне кажется этот образ мышления прививается системой образования, в которой для любой задачи всегда заложен правильный ответ. В реальной жизни наоборот, его никогда нет.
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.
Это ерунда. Множество отличных программистов ненавидят детали и делают по 10 ошибок в каждой функции. Для этого есть тесты и дебаггер. Если в код изначально заложена работоспособная концепция, то так или иначе его можно заставить работать при любой ненависти к деталям. Если мозгов на работоспособную концепцию не хватило, внимания к деталям может быть недостаточно.

В целом, чтобы быть программистом нужно иметь мозг, который был бы неплох хотя-бы в одной из сходных с программированием области (математике, технике, естественных науках) и иметь мотивации тренировать этот мозг в направлении программирования.
Задача, которую решает мозг программиста по сути сводится к планированию и описанию того, что должно происходить с детерминированной системой, состоящей из байтов, для достижения заданной цели :). У одних людей мозг лучше приспособлен к этой задаче, у других хуже. И эта способность тренируется в определенных пределах.
UFO just landed and posted this here
Можно еще проще. «Задача программиста сводится к выборочному намагничиванию быстро вращающихся пластин». С уходом жеских дисков определение, конечно, устаревает, но суть не меняется.
Так можно обозвать программистом любого сколь угодно простого агента. Суть моего определения на самом деле гораздо глубже.
На первый взгляд программирование кажется высоко-интеллектуальной областью, вроде высшей математики или научных исследований. Но с годами начинаешь понимать, что решаешь довольно простую задачу: представить что нужно получить в итоге и найти поведение для компьютера (машины Тьюринга по сути), которое приведет к нужному результату.
Особенно если программист женского пола.

Почему у всех проблемы с этим то????))))
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.

Вот прям вижу, как JS-разраб, пилящий на реакте, должен лезть в архитектуру ЭВМ…

А вот именно в этом и кроется проблема прожорливости современного софта: «программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно

А вот именно в этом и кроется проблема прожорливости современного софта: «программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно

Всё дело только в деньгах.

Бизнесу нужно быстро.

Если мне заплатят в 10 раз больше — я буду сидеть и оптимизировать. Я это люблю.
Но если я буду этим заниматься прямо сейчас — я просто протяну ноги от голода.

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

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

проблема прожорливости современного софта: «программисты» не знают как устроен компьютер
Условно 99% проблем производительности ПО решаются на уровнях сильно выше hardware. В обычных ЯП этот уровень почти недоступен, а хаки платформы могут привести к деградации в будущем.
Ресурсы, доступные ПО, вроде памяти и вычислительные, не очень связаны с устройством компьютеров и интуитивно известны всем. Их ограниченность просто игнорируют до какого-то момента.
«программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно

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

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

С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.

Когда я вижу, что программа добавляет к часовому ролику субтитры за 3 минуты, к двухчасовому — за 12 минут, а к трёхчасовому — почти за полчаса… мне даже не нужно знать сколько там абстракций использовалось в этих фреймворках… я точно знаю, что программист их использовавший некомпетентен — и где-то там внутри сидит очередной «маляр Шлемиэль»…
Ну например знание того, что операции со строками занимают время, грубо говоря, пропорциональное длине этих строк — а для целых чисел это не так может помочь и «программисту на условном реакте».

Это любимые всеми алгоритмы. O(n) где n длина строки. И пусть оно хоть на машине тьюринга исполняется. От железа не зависим никак.

С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.

И это тоже обычные аглоритмы. Напиши нормальный алгоритм, и он нормально работать будет. На любой машине.

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

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

начиная с 4-го пункта всё про меня.
20 лет назад я понял, что не смогу стать программистом хотя и мечтал об этом. Ну, а после этой статьи даже сомнения отбросил )))

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


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

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


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

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


Как понять, когда пора сдаться потому, что игра не стоит свеч, а когда ты просто рано сдался?

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


Если я ошущаю приятное чувство, но это не тот восторг, который был 10 лет назад, то что теперь?

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


Как понять, что такое легко и быстро? Быстро насколько? Если я жду, что разберусь в Питоне за полгода достаточно хорошо для старта — это слишком быстро или нет?

И так далее все пункты.

Проблема же здесь в том, что никто в новой деятельности не чувствует уверенности во всех этих пунктах.
Если мне интересно, как работает компьютер и технологии, но больше меня интересует общение с моей женой и семьёй — это не очень любопытно или уже норм?
Тут все понятно. Вы не программист. (шутка)
Никто из нас не может решать все проблемы самостоятельно. Лучшие умы говорят, что они пришли к чему-то потому, что основное до них придумали другие.
Поверьте, эти умы всегда лгут. Подобные вещи говорят чтобы показать скромность, коллективизм и чтобы не замочили раньше времени как безумного одиночку. В наше время кругом интернет и это не так заметно, но в 90-е когда я начинал программировать совершенно нормально было сначала изобрести концепцию (вплоть до ООП), а потом про нее прочитать. Не говоря уже о банальном решении любой мыслимой задачи самостоятельно (решения конечно были страшными временами). Те у кого нет такого свойства могут быть программистами конечно тоже, но это однозначно минус.
Все упомянутые автором признаки можно для инженерной профессии (да и не только инженерной) приложить.

И вывод будет тот же — «если вам не интересна ваша профессия, то вы будете в профессии весьма посредственным специалистом».
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here

При смене архитектуры модульные тесты не всегда спасают. Часто даже мешают. Так что расширяемость архитектуры тоже важна.

Есть лакмусовая бумажка: если вам нужно будет «расширять архитектуру» (скажем добавить поддержку Windows или PostgreSQL) — поговорите с тем, кто будет это реально делать. Если такого человека ещё нет — забейте. YAGNI: пока у вас нет пользователей понять — правильно ли вы что-то спроектировали всё равно невозможно. А вот когда пользователи появятся — тогда и начинайте думать.

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

Я говорю не про оставление "заделов", а про неоставление "граблей".

Ну грабли тоже разные бывает. У меня, скажем, в коде есть место, где используется алгоритм сложностью аж в целых O(N⁵) — притом, что, если дописать ещё тыщёнку строк кода можно обойтись O(N).

Почему нет «задела» и «оставлены грабли»? Потому что N, в данном случае — это количество регистровых аргументов у инструкции. И оно как бы равно 3 у 80386, а у процессоров с FMA4 — оно равно 5… думаю что процессоров с N == 6 мы не увидим никогда.

Это «задел» или «грабли»? Вот как вы оцениваете?

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

Он довольно-таки много с чем «перемешан». И если, вдруг, в x86 появятся 7-аргументные инструкции, то всё придётся переделывать (6-аргументные потребуют десятков гигабайт памяти при компиляции, но «со скрипом» должны пролезть).

Однако мой опыт подсказывает, что шансов на то, что нам придётся переделывать потому что, скажем, индустрия перейдёт на какой-нибудь RISC-V — гораздо больше.
Не понимаю откуда у всех такое патологическая увлечённость «покрытием тестами» и «рефакторингу».

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

Я вообще скептически отношусь к юниттестам (хотя уважаю функциюнальные, проверяющие что достаточно большой компонент в целом работоспособен) — по моему опыту затраты на их поддержание себя не окупают.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
не бывает бизнесов работающих на коде который не развивается.
Бывает. У какой-нибудь dmallocа последний commit — был несколько лет назад. Что не мешает миллиардам людей и кучей бизнесов его использовать.

неужели к ICQ с миллиардами прибылей нельзя было их приделать?
«Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет). Кстати современный Skype тоже так не умеет.

можно, но в свой код они не могли оперативно вносить изменения и… потому проиграли
Вы, наверное, из какой-то другой, параллельной, вселенной. Потому что как раз в нашей — ICQ постоянно вносила в свой клиент какие-то идиотские изменения. Боролась со сторонними клиентами. А вот сделать что-то фундаментально новое — нет, не могли. Для этого ведь одних unit-тестов недостаточно.

потому что выдали мобильного клиента. неужели Skype с его миллиардными бюджетами не мог оперативно сделать мобильного клиента?
Не мог. Потому что фишка WhatsApp была в том, что он использовал очень простой и лёгкий протокол — а у Skype всё было совсем не так… а платили тогда за каждый байт.

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

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

А чего они не могли делать — так это вносить изменения, затрагивающие всю инфраструктуру. И не могли они этого сделать, в частности, потому что от этого посыпались бы все их юниттесты, где были «зашиты» все эти ожидания.
UFO just landed and posted this here
я о коде который пишет программист на работе
А dmalloc и quicksort кто пишет? Не программист? Эльфы?

И не надо говорить, что malloc написан раз и навсегда: мы свой собственный аллокатор писали как раз месяц назад (почему и зачем — отдельный вопрос… но от malloc'а нам пришлось отказаться).

> «Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет).

вот в чем причина этого «нет»
В том, что у них были договора с разными компаниями, которые не позволяли этого сделать. Вплоть до того, что одно время GMail позволял общаться в чате с пользователями ICQ. И это им казалось более важным, чем обеспечение качественных голосовых звонков.

только в том что кодовая база пребывала в таком состоянии что «нет»
Да не в кодовой базе там было дело.

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

Создаётся ощущение что и программировании и о бизнесе у вас очень поверхностное понятие…

а так ICQ были лидерами рынка, им надо было всего-то навсего побарахтать руками и остаться на плаву.
Уууу… как всё запущено. Барахтать руками — за чей счёт, извините? Вы не в курсе, что с 1998го года ICQ принадлежала AOL? И что задачей программистов была не борьба со Skype, а интеграция с AIM и популяризация сервисов собственно AOL?

В том-то и дело, что проблема ICQ — была не в коде (его можно было переписать несколько раз легко… что, на самом деле, и было проделано), а в неверных бизнес-решениях. Никакого отношения к качеству кода не имевших.

здесь требовались изменения в dataflow и протокол.
Здесь требовались изменения в бизнес-модель, прежде всего. А как раз протокол ICQ меняла и не раз и не два.

ватсапп победил потому что у него был мобильный клиент, а у скайпа мобильного клиента не было.
Вот только не нужно сказок, а? Был у Skype мобильный клиент. И на iOS был. И на Android был. И на Symbian был. И даже на PSP был и на всякой экзотике типа N9. И даже специальные телефоны «под Skype» делали.

Однако проблема была в том, что для того, чтобы общаться через Skype вам нужно было знать как выглядит аккаунт вашего собеседника… а в WhatsApp — нет. Потому появившийся позже WhatsApp рос гораздо быстрее Skype. Но поскольку Microsoft хотел использовать Skype как способ убедить всех использовать Microsoft-аккаунт… идея использовать просто номер телефона — ему не понравилась. Та же самая история была у Google и Google Hangouts…

Опять-таки: проблема не в коде, проблема в бизнес-модели.

а тесты — это способ работы с этой вероятностью.
Вот только для внесения изменений нужны мозги в первую очередь, а тесты — это уже «рюшечки».
UFO just landed and posted this here
UFO just landed and posted this here
Это скорее вопрос опыта. Мне не один год потребовался, чтобы научиться «переписывать с нуля, изменяя по 100 строк кода за раз».

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

Дело в том, что переписывание с нуля вы не можете остановить и «быстренько закрыть issue» — потому бизнес и ненавидит подобные идеи.

А вот «переписывание с нуля по 100 строк за раз» — остановить можно. Да, это немного снизит темп (и сделает переписывание ещё дороже), но зато ваш заказчик не будет «сосать лапу» пока вы всё переписываете, а вам не придётся сидеть ночами, чтобы успеть всё закончить до тех пор, пока всю вашу деятельность не решат выкинуть нафиг…
Мне не один год потребовался, чтобы научиться «переписывать с нуля, изменяя по 100 строк кода за раз».

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

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

Никто из менеджеров почему-то не верит в эффективный и полный рефакторинг за год, но почему-то многие верят в переписывание с нуля за тот же период.
Ну дык тут как раз всё логично. Эффективность манагера ведь не то же самое, что эффективность фирмы. Он ведь своими деньгами не рискует. Соответственно подход, который с вероятностью 90% приведёт к краху, но с вероятностью 10% приведёт к гигантским бонусам — для него предпочтительнее, чем подход, который с вероятностью 90% принесёт небольшой доход, а с вероятностью 10% — не сделает ничего.
UFO just landed and posted this here
UFO just landed and posted this here

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

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here

Критерии приемки как минимум.
Если стоит таска "сделать программу что принимает на вход 2+2 и выдает на выходе 4", то так и писать "assert call ('2+2') == '4'". Тем самым гарантируя что и после сотни рефакторингов эта программа все ещё будет представлять заявленную функциональность.

Скажем так, это у вас в распоряжении дав программиста: академический и говнокодер. Первый конечно будет по началу ко всему подходить с размахом. Но преимущество в том, что он многое знает, просто применяет не все к месту. Этому можно научить достаточно легко. Второй же, скорее всего знает очень мало и его доучить будет стоить титанических усилий! Как пример, первый умеет работать и молотком, и дрелью, и пилой, и отверткой. Второй только молотком. Так вот, второй и шуруп вам забъет, и и дырку под дюбель выдолбит (немно эпокситки и будет все в порядке). А вот стул он вам сделает… я бы на него не садился…
UFO just landed and posted this here
Ну во первых вы так быстро оцениваете людей… Собеседования проводите? Когда я начинал 28 лет назад, не было концептов тестов, фреймворков, юниттестов, моков и прочего. Мы тогда просто «тестили». Тестами покрывать хорошо атомарные действия и функции. Я писал не так давно систему визуального тестирования полного процесса. Готовая не подошла по многим причинам. Это такое, что врагу не пожелаешь. Вам там говнокодер так все покроет, что только держись. На ее поддержание уходит куча времени! И в конечном итоге процентов 10 все равно нельзя однозначно протестировать. Как говорил мой учитель (по жизни): надо сначала подумать, потом написать, а потом протестировать. Писать и тестровать, не думая, займет куда больше времени.
Писать и тестровать, не думая, займет куда больше времени.
Золотые слова. Но судя по реакции собеседника на предложение писать код так, чтобы неправильных код просто не скомпилировался… вы с ним вообще с разных планет, а то и из разных миров.
Если вы имеете ввиду его: 0xd34df00d, то это единственный пользователь на которого я подписан. И умение писать им код на с++ может вызывать только «уважуху»! Хотя во многих других вопросах я с ним не согласен ;)
Нет, я про реакцию на это предложение от rsync.

Который, похоже, не понимает ни как использовать типы для замены unittest'ов (что, на самом деле, всегда возможно, однако не всегда желательно), ни почему люди пытаются добавить типы в скриптовые языки… такая себе проекция карго-культа, которым он овладел «в совершенстве» на весь мир…
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
что-то мешало внедрить эту одну фичу в проект?

вы уверенны что одну?
бюджеты миллиардные.

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

Это вы зря. Вы только что привели примеры из строительства и бухгалтерии.

Такая же ситуация и с программными продуктами.

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

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

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

Так что все же не всегда, если что-то не было сделано, это потому что «оказалось не по плечу.»
UFO just landed and posted this here

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

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

Вы там работали?
В AOL я не работал, но когда я был «молодым и зелёным» мы были одним из парнёров AOL. И потому примерно представляю что и как они могли требовать от программистов.

Да даже и не нужно никакого «инсайда». Вспомните, что они сделали с Netscape! Они совершенно искренне считали, что для них — куда полезнее использовать Netscape и Mozilla только как рычаг для давления на Microsoft, продвигали AOL Browser вместо чего-то на движке Mozilla и так далее.

Это были «нормальные бизнесмены» со своими «нормальным подходами», занимавшиеся «консолидацией» (в частности пытавшихся объединить AIM и ICQ), продажами диалап-доступа и о какой-то блажи типа голосового чата — они просто не думали. Они думали о том, как подписчиков себе вернуть.

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

Да, при взгляде назад — это кажется безумием и бредом… но вот так AOL себя видела в те годы.

А как раз наличие тестов и возможность менять код — это всё было вторично, по сравнению с этим.
так же как с sum выше: взять и набрать достаточно большую (уверенность!) таблицу вход-выход
Я никогда не мог понять, что значит «достаточно». В тепле, сухости и безопасности я чувствую себя только после написания доказательства.

Компромисс, когда на починку багов уходит приемлемо небольшое количество времени а учиться писать на Идрисе не нужно.
Я, кстати, по вашей ссылке, заглянул в предисловие TAPL, и мне очень понравилась цитата оттуда:
«Formal methods will never have a significant impact until they can be used by people that don’t understand them.»
UFO just landed and posted this here

Уносить часть тестов в тайпчекер — тоже вполне себе вариант… Плюсы у него есть. Но от этого они не перестают быть тестами, кстати.

Нуу… Мне нужно будет написать две функции с типами

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


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

UFO just landed and posted this here
Вы можете их так назвать, но только тогда получается, что любой механизм проверки и верификации кода — тесты. Как-то дискриминирующая сила понятия теряется.

Любой внешний механизм.


Тут мне надо придумывать заведомо меньше.

А вот не факт. Теста sum 2 3 == 5 достаточно, чтобы исключить ошибки вида "глупая опечатка".


Более умные ошибки исключаются методом внимательного взгляда: в такой простой функции им просто неоткуда взяться.

UFO just landed and posted this here
Любой внешний механизм.

Если есть внешний, то подразумевается и внутренний. Что вы понимаете под внутренним механизмом проверки и верификации кода?

Ну, собственно, типизация в обычном её понимании и есть такой внутренний механизм.

UFO just landed and posted this here
По-момему дискуссия соврешила очередной оборот и пошла на второй (третий, четвёртый?) круг. Напомню, с чего всё началось: как использовать типы для замены unittest'ов (что, на самом деле, всегда возможно, однако не всегда желательно).

Вот, собственно, в замечания в скобках всё и упирается. Если у вас достаточно «сильная» система типов (C++, в принципе, уже достаточен) — то вы любой unittest, в принципе, можете выразить в типах… но далеко не всегда это имеет смысл. Ну просто потому что если вы добъётесь того, что у вас всё-всё-всё прописано в типах, но однократная компиляция вашей программы занимает два дня… то толку от этого будет немного.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Зачем отказываться? В unit-test'ах mock bd (если у вас тест ходит в прод, то это уже совсем не unit-test), то же самое можно сделать и с типами.
UFO just landed and posted this here
Ваши юнит тесты все сильнее начинают напоминать интеграционные. Медленные, сложные, инфрастуктуру требуют. Их не то что при каждой сборке, а даже при каждом коммите не прогнать.

А в интеграционных тестах уже не надо тестировать сохранение и чтение из БД User. Достаточно протестировать интерфейсы системы. Если на них все правильно, то какая разница как там что в БД сохраняется и читается? Может и БД уже нет, все порефакторили на инмемори хранение.
UFO just landed and posted this here
Вы отвечаете на комент начинающийся словами «я не люблю термин 'юнит-тест'»

Так все равно скатываемся до определений. То что тестирование as code это хорошо и правильно все в курсе и никто не спорит. Вопрос только в том что и как тестировать.

отлично прогоняются. при каждом коммите.
вот проект — 600 тыс строк кода. 450 тыс строк тестового кода.
тесты идут 25 минут.

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

Комит должен быть моментальным. Единицы минут край. Закомитить в ветку любой кусок кода который с виду работает это нормально и правильно.

рабочий воркфлоу такой:

Воркфлоу хороший. Только при долгих тестах его гонять по много раз не выйдет. Долго. Надо большую часть ошибок находить до тестов. Тесты скорее для самопроверки. Мол я все правильно написал.
Закомитить в ветку любой кусок кода который с виду работает это нормально и правильно.
На эту тему существуют разные мнения. Разработчки Хрома, скажем, требуют, чтобы все тесты проходили и коммит был отревьюен… что запросто неделю может занять.

P.S. Разумеется в своём личном репозитории вы можете что угодно творить — хоть без тестов заливать, речь идёт про публичный репозиторий…
Я про личную ветку. В терминах гитхаба форк. Разработка обычно в таких ветках идет.
Тесты гоняем до зеленых когда пулл реквест в мастер делаем.

У тех кто терял данные на локальном диске мнение всегда одно: Комить при любом удобном случае.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
у меня в MVC парадигме есть сущность такая — User.
эта сущность может быть сохранена в БД, может быть восстановлена из БД, может производиться поиск итемов этой сущности, может производиться показ списка. Могут проводиться иные манипуляции.

все эти манипуляции написаны в сущности User и используют работу с БД внутри себя.
изоляция User от БД в парадигме MVC — это дефакто отказ от парадигмы MVC.

Ну здравствуйте. А откуда такие требования в MVC?
1. Если вдруг мы говорим про Веб, то напомню что MVC был создан для десктопных приложений, и описан Трюгве тут в 1979 году. В вебе испольуется лишь MVA(он же mediating controller MVC).
2. В MVC нет ничего про БД. То что у вас получилось в моделях по сути называется Active Record, и там действительно сложно отделить логику от взаимодействия с БД. Потому, собственно, AR и считается антипаттерном.

какую парадигму взамен MVC Вы предложите?

Писать адекватный код и думать о coupling/cohesion а не на аббревиатурки любоваться.
Про оригинальный MVC уже и вспоминают то не часто, чего к нему цепляться то.

но возьмем реальный мир. Например после сохранения записи в БД требуется отправить уведомления какие-то каким-то сервисам.

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

проблему mock'ов знаете главную?

консистентность с реальным миром

Поэтому интеграционные тесты всё-равно нужны, да.
Только вот взаимодействие с реальным миром можно изолировать, чтобы логику системы спокойно покрывать юнитами.
UFO just landed and posted this here
зачем нужен этот исторический экскурс? допустим MVC придуман изначально для десктопа. Что-то это меняет?
сейчас он успешно применяется в вебе

Если немного разобраться, будет понятно что всё что по вашей ссылке на самом деле MVC не является.
Как минимум потому что в вебе и всяких там ASP.NET контроллер является связующим звеном между View и Model, что паттерну MVC противоречит.

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

Отличие в том что взаимодействие идёт через request/response. Просто так забиндить select на вьюхе к полю в модели не получится.

если мы говорим об особенностях реализации M в MVC, то можно говорить и о AR, почему бы и нет.
но в общем это просто составляющая MVC

Можно, но не обязательно. Модель в MVC не обязана быть AR.

V выродился до примитивной сериализации в JSON/XML/итп

Это и противоречит MVC. View должен быть объектом подписанным на обновления в модели.

кем считается? теми 14 человеками (больше там нет) которые пытаются заменить тесты типами и пишут на маргинальных языках программирования?

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

MVC — самый распространённый в вебе паттерн.

и проблемы со скоростью разработки именно тогда и начинаются когда программисты ломают этот паттерн.

Так это баззворд распространённый, а как определение спросишь, у 10 разных программистов будет 5 разных «MVC».

Проблемы со скоростью разработки от сломанного MVC? Давайте статистику(и определение MVC, желательно).

гораздо дешевле не изолироваться от внешнего мира, а построить виртуальный внешний мир.
присутствует в проекте БД? отлично, перед запуском тестов — поднимаем БД. Имеется очередь? отлично — поднимаем и её. Хранилище S3? Mongo? Postgresql? подымаем все их!

затем запускаем тест. Тест в этом случае простой (мало кода) и полный (не функциональность с отрезанными частями проверяет а полную).

Integrated tests are a scam — советую.
UFO just landed and posted this here
допустим MVC придуман изначально для десктопа. Что-то это меняет?
сейчас он успешно применяется в вебе

На самом деле, это распространенное заблуждение. То. что применяется в вебе — это не то, что было придумано изначально, это другой паттерн, который назывался, чтобы всех запутать, Model 2. Но поскольку в нем использовались же те термины, его тоже начали называть MVC (сначала — MVC Model 2), что и привело нас туда, где мы сейчас.


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


в MVC про хранение (вообще работу с данными) данных отвечает M

… в некоторых MVC-фреймворках (например, asp.net MVC и все, что из него выросло) за работу с данными фактически отвечает контроллер (или, правильнее, находящийся за контроллером доменный слой), а то, что в Model 2 называется Model, отвечает только за транспорт между контроллером и представлением (и поэтому появляются рекомендации называть это ViewModel, чтобы, опять же, избежать непонимания).


кем считается?

Ну вот мной, например. А Фаулер в PoEAA пишет, что это простой паттерн, который перестает справляться по мере роста сложности домена.


не смешите мои тапочки. MVC — самый распространённый в вебе паттерн.

Да, но при чем здесь AR? Я много лет пишу для MVC, но ни разу не использовал AR.


изоляция (моки и тому подобные технологии) может очень дорого стоить

Угу. Особенно в сравнении с


меется очередь? отлично — поднимаем и её. Хранилище S3? Mongo? Postgresql? подымаем все их!

У меня вот проект, в котором активно используется AWS (вы вот помянули S3). Так вот, поднять все нужные сервисы — это, во-первых, долго, а, во-вторых, стоит денег (а учитывая, что тесты хочется гонять часто, это становится дорого). Плюс немедленно возникает проблема изоляции теств друг от друга — вы же не будете поднимать окружение заново для каждого из тысячи тестов?

UFO just landed and posted this here
докер для этого придумали

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


(это не считая того, что если на проекте нет докера, то это дополнительная нагрузка на инфраструктуру, и особенно веселой она становится, когда инфраструктура на винде)


И, кстати, в этот момент этот контейнер с S3 и становится моком. Разве нет?


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


PS… а потом мы добавили в этот проект Azure.

UFO just landed and posted this here
над ними очень сложно настроить процесс тестирования.

С чего бы вдруг?


и Вы сможете тестировать.

Я уже сейчас могу это тестировать. И, собственно, тестирую.


лучше от неё дистанцироваться.

… и на что вы предлагаете заменить лямбды в событиях Cognito?


докер можно держать только в тестовой инфраструктуре

Об этом и речь: нам придется поднять докер только ради тестов. Это дополнительные накладные расходы.


эм. нет.
он полноценное S3 хранилище.

Он от этого моком быть не перестал.


"Classification between mocks, fakes, and stubs is highly inconsistent across the literature. Consistent among the literature, though, is that they all represent a production object in a testing environment by exposing the same interface."


Вы испольуете не тот же (по имплементации!) сервис, что в продакшне — вот и вам и мок (ну или test dummy, или stub, если хотите, смысл не меняется).


тут же нет имитации

Как это нет? S3 — это конкретный сервис развернутый Амазоном. А то, что вы видите в докере — это что-то, что поддерживает тот же API и ту же функциональность (и, вполне возможно, с определенными ограничениями).

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
консистентность Вашего понимания внешнего мира и внешнего мира!

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


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


и кстати именно из за этой второй задачи мы предпочитаем тестировать подымая копию внешнего мира

Дорого это, держать копию внешнего мира.

UFO just landed and posted this here
эпоха docker'а на дворе. давно уже это недорого

Это если весь ваш внешний мир существует в контейнерах. А если нет?

UFO just landed and posted this here
собирать контейнеры самому?

И как вы мне предлагаете самому собрать контейнер, содержащий облачный сервис с закрытым кодом?


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


И это не говоря о том, что самостоятельная сборка — это дорого.

UFO just landed and posted this here
невозможность собрать контейнер говорит обычно что не нужно выбирать эту зависимость

Иногда это невозможно. Иногда — неразумно дорого с точки зрения разработки.


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


самостоятельная сборка контейнера это недорого.
соизмеримо по стоимости с простой инсталляцией

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

UFO just landed and posted this here
можно использовать сам сторонний сервис внутри автоматических тестов.

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


Во-вторых, это не бесплатно.


В-третьих, это усложняет сетап тестов.


заодно и ошибки недоступности того гугла/амазона можно пописать.

Угу, непредсказуемым образом.

UFO just landed and posted this here
какая разница? внешний мир или его копия? никакой.

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


просто делаете тестовую учётку (или их набор) в этом реальном мире.

См. выше: дорого и усложняет сетап.


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

… а потом выясняется, что у zendesk — канарейки, и вы в них попали, а ваши польователи — нет, а канарейка-то в продакшн и не пошла.


недорого

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


докер. сегодня эпоха докеров.

Напомню, что речь идет о внешнем сервисе, который в докер не завернуть.


как раз предсказуемым

Откуда же предсказуемым, если это внешний сервис, и вы никогда не знаете, как он упадет?

UFO just landed and posted this here
и маловероятно что тесты попадут в канарейку а пользователи нет

Что маловероятного, если там просто выбираются случайные 10%?


я ж говорю — некоторые технологии просто тупо не стоит применять. голосуйте ногами/рублём против них.

Я ж говорю: не всегда есть возможность.


если тестовый прогон на реальном мире стоит полторы штуки баксов,

Не тестовый прогон, а неделя тестовых прогонов.


то во сколько обходится продакшен работа?

А какая разница? За продакшн-работу не мы платим.


тут повод задуматься, может Вы тесты как-то криво сделали?

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


внешний сервис может упасть ошибками протокола к нему + ошибками сети к нему.

… вернуть любой ответ, который вы не ожидаете. В любой момент.

UFO just landed and posted this here
включайте тестовые прогоны в стоимость работ, чего проще-то?

Нельзя.


в этом гипотетическом случае с кучей странных допущений

Это не гипотетический, а вполне реальный случай. И не единственный.


или вы на основании того что у Вас был однажды такой случай — готовы раз и навсегда от тестов отказаться?

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


я не понимаю пока что Вы хотите доказать/рассказать

… что тестировать на копии внешнего мира — сложнее и дороже, чем вы пытаетесь рассказать.


как только это произойдёт, Ваш тест сломается, в ответ Вы добавите в код реакцию на подобное событие.

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


Это и называется "непредсказуемое поведение внешнего сервиса".

соответственно код, который осуществляет сохранение записи в БД должен всё это учитывать, а соответственно тестировать.

Как протестировать, что код обрабатывает все ошибки, которые могут возникнуть в БД?


(знали бы вы, как меня утомило угадывать, какие именно ошибки вернет boto)

UFO just landed and posted this here
UFO just landed and posted this here

Это гарантирует только то, что мы обрабатываем те ошибки, для которых мы написали тесты. Но как гарантировать, что мы написали тесты для всех ошибок, которые могут возникнуть в БД?


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

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

Но в результате вы, фактически, породите себе compile-time базу данных, compile-time mock GUI и массу всего в том же роде.

А я сравнивал на простейших алгоритмах — и в clang и в gcc compile-time исполнение программы примерно на три-четыре порядка медленнее, чем у скомпилированной программы.
UFO just landed and posted this here
UFO just landed and posted this here
C++ для этого слабоват, боюсь.
Для Mock'ов достаточен. Засовываете данные в constexpr char[], параметризуете этой переменной свой тип — и добавляете туда все свойства, какие вам нужны.

Дальше static_assert'ами можно любые unit test'ы описать.

Практического смысла в этом, впрочем, нет: во-первых у вас весь-весь-весь код должен будет стать параметризуемым, чтобы этот подход можно было применить, во-вторых сообщения об ошибках будут такими, что понять из них — где ошибка это ещё два дня потребуется, на этот раз уже человеческих…

Это как с доказательством Теоремы Бёма — Якопини: да, любой алгоритм может быть, чисто механически, превращён в структурный вид — но это не значит, что его станет легче понять… так и любой unit-test можно «перегнать в типы»… но не факт, что после этого что-то станет кому-то понятнее… скорее наоборот.
UFO just landed and posted this here
Я позабыл, как там в уже готовых версиях C++ с компилтайм-выделением памяти
Аллокаторы уже есть, вроде. Но их можно и симулировать.

компилтайм-векторами-хешмапами
А вот это — ушло в C++23. Но это стандартная библиотека, её можно «у себя» сделать какую угодно, язык для этого менять не нужно.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Я отношу к юнит-тестам всё, что нельзя проверить через «официальный» интерфейс разрабатываемого модуля.

То есть если разбить задачу на много-много мелких модулей, описать что каждый из них делает и зафиксировать это в документации — то у вас все тесты станут интеграционными… только возможность что-то рефакторить окажется дико затруднена, так как вам, после этого, нужно будет править и тесты и документацию… и только потом — код.
Я до сих пор не очень понимаю, чем юнит-тесты от интеграционных отличаются (разные люди говорят разное)

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

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

Это тесты которые в первую очередь близки к коду и интересны исключительно разработчикам.

Их используют вместо интеграционных и пр. так как они:
— Быстро выполняются
— Позволяют покрыть все пути выполнения кода(потому что методы с ветвлениями if/case etc.) тестятся изолированно друг от друга.
— Позволяют представить удобство пользования новым модулем с точки зрения клиентского кода, и влияют на качество кода если следить за сложностью тестов/количеством моков и т.п. Если юзать TDD то удобство интерфейса вообще ставится во главу угла.

То есть хорошо покрытый unit-тестами метод, это в идеале метод у которого ими покрыты все ветвления, все ожидаемые исходы.

Всякие практики проектирования действительно могут окупиться если проект развивается и масштабируется(масштабируется разработка, нужно вводить людей, ограничивать количество связей, коммуникаций и зависимостей), и эти практики применяются вдумчиво и по назначению.
А многие любят просто всё усложнять, и получаются все эти лозунги мол «дизайн/тесты etc. не нужны / не окупаются» или натягивания совы на глобус.

Самое интересное что можно глянуть, наверное, вот — www.youtube.com/watch?v=VDfX44fZoMc
А многие любят просто всё усложнять, и получаются все эти лозунги мол «дизайн/тесты etc. не нужны / не окупаются» или натягивания совы на глобус.
Вот только у разных людей понятия над тем, что такое просто и что такое сложно — разные.

Пример из жизни. Жил-был модуль, в нём было порядка 100'000 строк кода и порядка 1000 тестов. Я его переписал и создать один ragel-файл на 5'000 строк кода и один тест (перебирающий все возможные случаи на основании файла-спеки от вендора).

Это усложнение или упрощение? Мне казалось что всё стало проще (и статистика это подтвердила: после переписывания единственная ошибка, в этом модуле найденая, оказалась связана с тем, что железяка не соответствовала спеке), однако у адептов TDD было ровно противоположное мнение (даже несмотря на то, что ошибок в этом модуле до моего вмешательства было найдено и исправлено… в количестве).
Вот только у разных людей понятия над тем, что такое просто и что такое сложно — разные.

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

Пример из жизни. Жил-был модуль, в нём было порядка 100'000 строк кода и порядка 1000 тестов. Я его переписал и создать один ragel-файл на 5'000 строк кода и один тест (перебирающий все возможные случаи на основании файла-спеки от вендора).

Это усложнение или упрощение?

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

однако у адептов TDD было ровно противоположное мнение (даже несмотря на то, что ошибок в этом модуле до моего вмешательства было найдено и исправлено… в количестве).

Адепты, такие адепты. Тесты не самоцель, вот и всё.

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

Вобщем, то дойти до мидлварь, по аналогии с докладом Марко — www.youtube.com/watch?v=MjpiHy_e8kQ&list=LLd6OFj5xQf9ZhwBb4EVbdSw, а не распилить всё на микросервисы и т.п., как делают некоторые(или многие, статистики нет).
Более сложные решения — по мере надобности.
Если в нём было легко разобраться и легко вносить нужны изменения — вопрос зачем вы его переписывали.
Это был ключевой элемент безопасности системы и, соответственно, любая ошибка в нём была потенциальной дырой в безопасности.

Тогда вопрос лишь в том помогло ли переписывание от этих проблем избавиться.
Как показали дальнейшие несколько лет — помогло.

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

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

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

Предположу, что стабильность релизов и спокойствие важнее скорости )

Адепты, такие адепты. Тесты не самоцель, вот и всё.

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

Так шум он вокруг того что модно.

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

В целом юнит тесты как средство хороши, и с темой проектирования находятся рядом, просто юнит тесты это следующий этап после определения чего нам вообще нужно.
UFO just landed and posted this here
А у вас не было такого, что ragel пытался построить DFA с экспоненциальным взрывом числа состояний (для NFA известного вида)?
Нет. Построенный автомат был большим (тысячи состояний), но не настолько большим, чтобы это стало проблемой.

Там можно как-то попросить его оставить NFA?
Вряд ли. Гораздо хуже что у него комбинация машин не работает как комбинация в математическом смысле.

Потому все тесты пришлось перенести на уже полностью построенную машину.
UFO just landed and posted this here
По сути основное момент в том что за счёт тестирования маленьких изолированных кусков кода мы всегда можем сказать где ошибка если тест упал.

Неочевидно. А если ошибка на границе двух маленьких изолированных кусков?

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

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

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

А если вы про возможность доказать типами — мне нравится, да. Я начал ради интереса Хаскель тыкать, но в продакшн то всё равно пишу на пхп не на нём, приходится стат. анализом обмазываться.
UFO just landed and posted this here
Ну так проблема в том, что метод ожидает положительное число (квадратный корень из него считает, например, где-то в процессе), а ему передали отрицательное. На что тут юнит-тест писать?

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

UFO just landed and posted this here
А можно просто выразить в типах неотрицательность входного числа, и плохой код не соберётся :]

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

Какое хорошее определение. Надо запомнить.

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

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

«Написать ерунду и если тест упадет перепишем» и так до всех работающих тестов уже не выйдет.
А надо? Сколько раз видел применение этого подхода — кончалось всё всегда одинаково: получается «всё ещё ерунда… но теперь с тестами».

Это, конечно, отличная вещь для «эффективных манагеров», которые могут на этом демонстрировать разнообразные красивые графики с разными KPI… но бизнесу это не нужно.

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

А если конкурентов нет — то можно вот вообще всех этих «эффективных манагеров» с «дешёвыми разработчиками» убрать — и здорово увеличить прибыль.

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

Который, соотвественно, уже и протестировать.
А разве это не плюс?

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

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

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

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

У меня нет этих признаков, и всё равно — я плохой программист.
Бодо Шифер считает, что всему основа — самодисциплина. Без неё не работает ничего.

Список вообще универсальный. Если изменить расшифровку каждого пункта — применимо к любой профессии.
Внезапно статья по делу (среди моря статей про N признаков чего-либо). На самом деле мало быть умным/одарённым и т. д. — для достижения любого результата нужно упорно трудиться. Каждый пункт имеет смысл. Конечно, можно научиться что-то кодить и не имея вышеописанных признаков, стать грамотным разработчиком — вряд ли.
Пролистывая тезисы, увидел
2 | Вам не хватает самостоятельности и находчивости

7 | Вы не способны думать самостоятельно

Скажите, стоит читать или снова вода на киселе?

Как обычно — комментарии стоит читать, статью — по желанию :)

Что есть — хороший программист?
Программист которого увольняют в последнюю очередь. (С)
Так себе критерий.
При наличии начальника дурака, первыми на увольнение как раз будут хорошие программисты не умеющие лизать зад и имеющие отличную от начальника точку зрения.
Список признаков выглядит очень субъективным и категоричным. Как известно без труда ничего не получится, но для того, чтобы стать хорошим программистом не обязательно иметь несколько маниакальный подход к работе (после 10 пунктов создается образ киборга-программиста, в жизни которого есть только работа). Например, можно сравнить Теслу и Эдисона. Один был более одержим наукой, другой пытался свою работу, скажем так, монетизировать. Но нельзя же сказать, что один хороший инженер, а другой плохой
Но нельзя же сказать, что один хороший инженер, а другой плохой
Можно. Тесла — гениальный изобретатель, но плохой инженер. Эдиссон — менее прозорливый изобретатель, но куда лучший инженер. Что позволяло ему доводить до ума даже не самые лучшие идеи. Посмотрите на результат войны токов: объективно не самый лучший вариант, использованный Эдиссоном, тем не менее, прожил десятилетия и дожил до наших дней.

В то же время Тесла, несмотря на всю гениальность, так и не смог разработать «всемирную систему».

Один был более одержим наукой, другой пытался свою работу, скажем так, монетизировать.
Он не был «одержим наукой», к сожалению — иначе от него бы научные труды остались. Он был одержим конкретной задачей, которая, похоже, в те годы не могла быть решена (если она может быть решена в принципе). Тут он очень похож на Эйнштейна, который вложил в попытки объединить теорию гравитации и квантовую механику многие годы… но не добился, в результате, ничего. Но для науки это нормально… а для инженерии — нет. Умение сказать «это, в настоящее время, невозможно» и начать делать что-то,
что, в настоящее время, таки можно сделать — важное умение для инженера…
Я оценивала по пунктам выше и они оба подходили под все (8й с натяжкой, тут сложно оценить вообще подходит ли человек под него или нет). И получалось странно, подходят оба, а хороший один. Опять же вопрос: а хороший, это какой?
Умение сказать «это, в настоящее время, невозможно» и начать делать что-то,
что, в настоящее время, таки можно сделать — важное умение для инженера…

Довести до конца… Играясь с гипотезами, можно до конца и не довести. Если он примет, что «это невозможно» — можно говорить об узости мышления. А может он выдвинул гипотезу, довел до конца, а любознательности не проявлял, тогда он тоже плохой?
Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.
Может я чего-то не понимаю, но мне всегда казалось, что «изучая что-то новое» — это просто по определению обозначает, что у вас недостаточно знаний для обоснованного мнения.
Как же в Бейсике было просто и понятно все, казалось все так логично, а сейчас даже в синтаксис тяжело вникать, особенно когда только только начинаешь.
Многое справедливо, но почему-то нет ни слова о математически-логическом складе ума. Конечно, что-то развивается, но есть и предрасположенность. Считаю, идеальный тест на способность к абстрактной логике это тест про «летающих начальников». Можно так и найти по фразе «хорошие начальники не летают». Там есть пара вопросов с небольшой неоднозначностью — зависит от формулировок и связано с неоднозначностями самого языка. Но в целом очень хорошая проверка.
почему-то нет ни слова о математически-логическом складе ума

А что это такое?

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


Без этой привычки очень многое в программировании делать тяжело.

Чем это отличается от абстрактного мышления?

Я не говорю, что должно отличаться, я пытаюсь понять, о чем речь идет.

программирование, имхо, — это не какая-то особенная профессия, и 10 признаков, перечисленных в статье, подходят ко всем остальным профессиям, не связанных с монотонным трудом, да и к монотонному труду это тоже в общем-то можно отнести: конвейерная сборка, мойщик посуды, уборщик — результаты разные получаются как раз по многим из 10 признаков. В любом случае, по крайней мере, в России в всех профессиях подавляющее большинство людей — это случайные люди, мало соответствующие своей профессии, своим должностным обязанностям. Увы и ах.
Правильнее назвать:«10 признаков того, что хороший специалист в выбранной вами области из вас не получится».
Локальный конкурс вопрос-ответ (победитель по лайкам).
Вопрос:
Что делать, когда вроде все признаки имеются много лет, а хорошим программистом себя не ощущаешь?
UFO just landed and posted this here
Понять, что вы подразумеваете лично для себя под словом «хороший программист», скорее всего вы очень сильно задрали планку для этого «звания».
О каких деталях речь, чему надо уделять внимание, если сейчас большая часть кода скрыта в фреймворках.

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

Из вас не получится хороший железнодорожник…
Постойте. Какой именно железнодорожник? Машинист? Проводник? Составитель поездов? Диспетчер? Билетный кассир? Ревизор? Для этих профессий нужны очень разные качества.
Разработка ПО не менее разнообразная отрасль, а всех нас чехом называют программистами. И каждый считает НАСТОЯЩИМ ПРОГРАММИСТОМ именно себя и с этой точки зрения рассуждает о необходимых качествах и навыках.
Уточню (обращу внимание) пункт «Бонус» — автор подразумевает именно тех, кто в первую очередь ориентирован на создании бизнеса — очень быстро такому человеку надоест копаться в техническом утройстве инструмента. Здесь соглашусь.

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

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

Как по мне, есть 2 ограничения:
1. Олигофрения.
2. Слепота и повреждение рук.
Впрочем, некоторые физические ограничения тоже можно обойти, если прям очень сильно хочется. На счет легких и пограничных форм умственной отсталости — писать код можно, как конструктор собирать, но вряд ли получится глубоко вникнуть в сложные абстрактные концепции.
Все остальное — преодолимо.
Вот же ж…
Злая какая то анкета получилась, на все вопросы — отрицательно…
Теперь 52-летний, программирующий сисадмин…

Articles