Комментарии 518
Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.
…
Видеть полную картину, представлять себе различные возможности и доверять своей интуиции полезно для нахождения лучших решений, полностью удовлетворяющих вашей задаче.
Интересное мнение. Однако, нельзя написать две точки входа в одной программе. Всегда есть реализованное решение и остальные. Если вам кажется, что существует целый спектр «хороших» решений, значит вы недостаточно глубоко изучили вашу конкретную задачу. Всегда есть обстоятельства, иногда даже не связанные с программированием, которые выделяют из хороших то самое единственно верное решение.
Единственно верное решение — это "2 x 2 = 4".
Все остальные решения — это компромиссы.
Далеко не факт, плюс, на 0 в некоторых языках программирования начинаются восьмеричные числа.
Соответственно быстрее закрываются таски, проще получать премии и так далее.
А иногда 100% корректность не нужна в принципе: например вспомогательные скрипты, используемые для сборки программы — если они как-то отрабатывают на ваших данных, которые у вас есть и дают правильный результат… то вам же неважно что они сделают с другими данными, которых у вас нет!
В некоторых системах счисления может получиться не 4, а 10 или даже 11 :)
10 в любой системе счисления 10 ;)
0: _
1: 1
2: 11
3: 111
4: 1111
5: 11111
и т.д.
вот что вики знает: Унарная система счисления
обучение детей счету о котором упоминается: надо вспомнить что обучают на палочках счету в десятичной системе, а не единичной
что с вами не так? палочки представляют собой обозначения в унарной системе. Если вы выложите палочками цифру 5 — будет цифра пять. А если это пять палочек — это пять в унарной системе.
В любой системе счисления, имеющей основание и цифры 1 и 0, так точнее.
В перле 2 x 2
даст 22. Как и 2 . 2
Все остальные решения — это компромиссы.
Вы не поняли смысл моего сообщения. Я об этом и написал, что из множества решений, удовлетворяющих требованиям, всегда можно выделить одно, наиболее оптимальное в данной ситуации.
А если кто-то из этого множества выбирает рандомное решение (они все кажутся одинаковыми), значит он просто не достаточно детально изучил данную ситуацию.
Как же скучно жить в черно-белом мире…
всегда есть не нулевая вероятность получить несколько оптимумов при конечном количестве параметров.
С чего бы, даже в теории, стремиться к 0...? Насколько я помню, математически было показано, что вероятность нахождения нескольких оптимумов стремится к 0 только при бесконечном количестве параметров/критериев. В практике(реальной жизни) оптимумов вполне может быть несколько. Классический бытовоц пример у нас — выбор рейса Москва -Питер. Чтобы выбрать рейс, постоянно нужно увеличивать число параметров/критериев.что бы в итоге остался 1. Причём в зависимости от индивидуума, набор этих параметров разный…
Назовите любой алгоритм сортировки и вам назовут мильйон причин, в чём оно не оптимально.
С сортировкой не так то, что сортировать можно очень разные данные и в очень разных условиях. Массив из 10 элементов эффективнее будет сортировать вставками. Из 10 миллионов элементов — квиксорт (если массив упорядочен случайно). Для 3 элементов эффективнее будет нахардкодить дерево из ифов. Если подключить сюда еще размер данных для сортировки (просто инты или 10-мегабайтные структуры?), тип структуры контейнера (массив или односвязный список?), характер данных (почти отсортированные? Случайно упорядоченные? Отсортированные в почти-обратном порядке?), то количество оптимальных для каждого отдельного случая алгоритмов растет еще больше.
sort из стандартной библиотеки — это компромисс, который 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 и все будет хорошо? Ну да. Только с этим никто и не спорил и речь вообще о другом была.
Конкретно про сортировки. Я не спорю, что есть разные алгоритмы с разными характеристиками. Но считаю, что в среднем программист скорее выиграет сто миллионов в лотерею и перестанет программировать вообще нежели ему придётся решать задачу где встроенная сортировка не подойдёт. И считаю неправильным употреблять для описания таких случаев эпитеты: «множество», «зачастую», «мильены».
Не говоря уже об искусственно созданных «плохих» входных данных, которые есть у любого алгоритма сортировки.
Это скорее для квиксорта характерно, там от способа выбора опорного элемента много зависит. Хипсорт и мержсорт к такому устойчивы вроде.
Мне нужно сложить 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" — пара десятков комментариев с аргументированными возражениями и контр-примерами, где ещё такое встретишь?
"Лучшее" — по каким критериям?
"Мы делаем быстро, дешево и качественно. Выберите 2 из 3".
Выберите "лучшее".
Тут нету понятия быстро и дёшево
Разве? Программирование — это активность, она занимает время. Следовательно, есть "быстро" и "медленно". Программирование так же требует ресурсов (и как активность, и как решения), и эти ресурсы могут стоить денег. Отсюда — "дорого" и "дешево".
В моем понимании лучшее, это наиболее понятное и менее ресурсоемкое.
Бывает так, что увеличение понятности приводит к увеличению потребляемых ресурсов. И как же выбирать "лучшее" в вашем понимании?
Вы про просто хобби программирование? Хотя даже тут, можно вечно искать наиболее понятное и менее ресурсоемкое решение.
Я вот свой код 3 летней давности считал тогда простым и оптимальным. А сейчас смотрю и удивляюсь, как такая лажа в продукт шла? Но если бы я 3 года назад продолжил бы искать более оптимальное и понятное решение, то возможно, уже программистом и не был бы — уволили бы меня.
А тебе попадается необъяснимое поведение в ЯП
Это странно, потому что обычно все объясняется стандартом ЯП, иногда бывает необъяснимое поведение компилятора, но тогда скорее всего надо просто прочитать Errata на него.
Что именно нельзя и не работает? Пример кода, плз.
Есть интересные случаи, на которые можно попасться, вроде описанного тут, но вообще никто не запрещает использовать Runnable так, как вздумается.
… ну то есть (периодически) весьма противоречащие друг другу вещи.
Во-первых, не всегда красивая реализация легка в поддержке.
Во-вторых, далеко не всегда красивая или легкая в поддержке реализация потребляет меньше или хотя бы столько же ресурсов, чем некрасивая и сложная в поддержке.
Ну так на это я и написал. Компромисс
Ну так компромис — это как раз когда вы балансируете между противоречащими друг другу вещами. Странно, что вы продолжаете спрашивать, "в чем противоречие".
Всегда можно сложную реализацию обернуть в еще одну функцию/процедуру. С соответствующим комментарием. Что сюда нельзя, тут начинается магия. И не стоит это место трогать.
Это как раз называется "сложно в поддержке".
Значит это сложно в поддержке: вместо того, чтобы поменять одно место в коде, тебе надо разобраться в логике его работы и написать всё заново, но уже с новыми свойствами. На это может уйти много времнни
А в чем сложность поддержки в этом?
В том, что "сюда нельзя". Непонятно, что делать, если там проблема, или если маленькая проблема вокруг, или если надо переиспользовать с изменениями.
Заметил тенденцию, все что ранее написано, не трогают. А пишут новое.
Ну то есть ставим крест на переиспользовании.
В моем понимании лучшее, это наиболее понятное и менее ресурсоемкое.
Вы точно программизмом занимаетесь?
Или нагуглили это всё?
Ну, если когда-нибудь займетесь программированием (не только 1С), то сами выведете, что:
"Лучшим решением является то, которое оптимально удовлетворяет требования заказчика".
На минуточку — "оптимально", а не "наилучшим образом".
Потому что удовлетворить наилучшим образом все требования — невозможно как класс.
Для меня оптимально и наилучшим образом — синонимы.
dic.academic.ru/dic.nsf/ruwiki/1587468
Видимо в понятие «наилучшим образом» вы не закладываете все нужные заказчику критерии, оставшиеся в умолчаниях, такие как время и финансовые затраты.
Если в требованиях не было про то, как должны храниться пароли, то вполне себе нормальное решение. Может там защита не нужна… Например, какой-нить внутрикорпоративный сервис, для поиска общедоступной информации… Зачем городить огород, где он не нужен?
Реализовано правильно, это когда по требованиям.
Кроме явных требований заказчика есть неявные у него же, есть требования регуляторов разных юрисдикций, есть лучшие практики (юридически я бы их отнёс к обычаям делового оборота). И может иск о ненадлежащем исполнении договора или служебных обязанностей и не выиграет в суде, но репутацию вам подмочит, если будете хранить пароли в открытом виде, когда даже на сайте ЯП указано, что так делать нельзя
И что? У нас, например внутренняя система учёта времени, там мой пароль 1. Ну утечет он, что с этого? Данные с этой системы чисто информативные для сотрудников…
Зачем там сложная система аутентификации? 7
Смотря где в открыом виде. В дженкинсе есть защищённые переменные, но они отдаются приложению строкой, только в логах маскируются. Это, разве, плохая практика?
Реализовано? Реализовано. Быстро. Дешево.
Не нужно пилить фейсбук там, где достаточно 2 html страничек.
«то, что реализовано — правильно» — неверный в корне.
Расскажите погроммистам 1С
Я сам (сдуру) заглядывал в исходники фреймворка от той же конторы (Битрикс) а от того, что я там увидел, меня трясет от каждого упоминания — такое впечатление, что его делали люди, которые только вчера научились включать комп, а сегодня ваяют на пхп.
А вот «реализаторы через Ж» как раз «недостаточно глубоко изучили конкретную задачу».Ну, если задача стояла «сделать максимально быстро и забыть», то «М и Д», наоборот — молодцы. Просто, возможно, ТЗ поменялось и «забыть» было вычеркнуто.
Речь скорее всего о том, что программных реализаций решений, позволяющих получить искомый результат — более одного. Кроме того, сам результат может быть гибкой функцией, если нет железобетонного ТЗ с эскизами форм, отчетов и т. п. Заказчик не всегда может внятно представлять автоматизацию глубже понятия "должно что-то стать быстрее и удобней".
Тут главное не забывать, что от смены обстоятельств этим самым "единственно верным решением" может оказаться какое-то другое из спектра "хороших".
А риски и перспективы развития следует, конечно же, учитывать. Может программист знает не всё, но предусмотреть банальное масштабирование желательно.
Мне часто помогает представить как бы какая-то штука была реализована в идеальном мире. Типа, решение, повторяющее или моделирующее логику того, что нужно сделать как оно есть. А уже потом компромиссами превратить его в то, что можно сделать в конкретных условиях. А иногда, если костылей «вынужденных решений» накопилось еще не много, получается и без компромиссов.
Однако, нельзя написать две точки входа в одной программе
Легко. У меня есть сервис (use-case) регистрации пользователя. Одна точка входа через web-морду, вторая — через CLI.
В этом и соль: есть реализация, но если ты не видишь её сильных или слабых сторон, то ты не станешь успешным программистом. Есть задача: вывести результат 2x2. Хороший программист обязан:
- Вывести значение сразу. Тут нефиг думать.
- Прогнать в голове все варианты контекста применения этой функции. Потому, что завтра заказчик скажет: ой, ну это чисто пример, там надо чтобы пользователь руками вводил формулу (любой сложности в рамках средней школы), вводил значение всех переменных и получал результат. И ты такой садишься на жопу и начинаешь писать за 1000 рублей калькулятор для алгебры и начала анализа.
Поэтому, ты обязан знать паттерны решения твоего вопроса. Полюбому, есть набор решений, которые подскажут тебе, что контекст использования может отличаться от ТЗ. Или было бы разумно реализовать паттерн, который отвечал бы ожиданиям большинства вариантов юзкейсов.
Но можно написать две точки входа для компиляции, если тебе нужен вариативный результат
Получается, не выйдет из вас хорошего программиста. Так?
Кроме №9 все тезисы могут быть применены к любой профессии.
Вообще к любой.
Всю статью можно переписать так:
"Если будешь хорошим — то будешь хорошим. А если будешь плохим — то ничего у тебя не получится."
Подставьте "дворник".
«Дворник», вроде, к интеллектуальным профессиям не относится…
Кто так решил?
И что есть "интеллектуальная профессия"?
Илита?
PS. ну разве что под "интеллектуальной профессией" понимать вид деятельности, при котором больше работают головой меньше работают руками, и основная физическая нагрузка приходится на пятую точку.
Я думаю что выделять илиту интеллектуальную деятельность как нечто особенного немного неверно.
Работа как работа. Ничего особенного. Дворником отнюдь не проще.
Точнее не махать метлой, а мести.
Махать-то сможет, мои дети в 2 года так могли. Именно махать метлой, не мести.
Для этого требуются какие то особенные умственные способности, что вы дворника в интеллектуальную профессию записали?
Я могу делать работу любого дворника
Я бы развалился через полчаса подметания улиц. То, что господин Hivemaster может подметать улицы и не умирать от этого — хвала ему во всех смыслах
Но, например, любознательность или там терпение в учёбе явно не являются важным профессиональным качеством дворника. А для программиста — являются. Значит, совершенно одинаковыми эти две профессии не являются...
Конечно не являются!
Чтобы быть нормальным дворником, надо чтобы руки нормально отросли.
А вот людям с проблемными руками альтернативной моторкой приходится идти в погроммисты и выкручиваться как получится.
PS. надеюсь понятно, что это просто взгляд с другой кочки зрения, а не повод для холивара :-)
Но интелектуальной профессия "дворник" от смены точки зрения всё равно не становится.
Конечно не становится!
Чтобы быть дворником, надо кроме головы еще и прямые руки иметь.
А с прямыми руками ту же Windows написать сложно (такой, какая она есть)
Так что нет, не становится.
«Если вы несамостоятельный ленивый нелюбознательный хмыропуз, то из вас ничего не получится».
Тут дело в наборе навыков и характере, кому-то проще стать сеньором, кому-то депутатом. От человека зависит.
Но с другой стороны, дефицит специалистов во многих (во всех?) отраслях довольно велик, как и в политике тоже.
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Мне интересно, как написан код библиотек\фреймворков и т.д., но мне всё равно, как устроен компьютер (знаю на уровне школьника и ладно)
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом.
Я не хочу потерять день на решение проблемы мучаясь дебагом, которое способен мгновенно выдать интернет\коллега\мануал.
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Решит коллега. Поменяю саму задачу или способ решения.
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Нет, ведь самое трудное еще впереди. Или просто еще 10 таких же проблем (тикетов)
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Когда мне было 20 — все давалось легко и быстро. Теперь я точно знаю, что мне не понять, например, криптографию и другую высшую математику, и просто туда не лезу.
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом.
Потому что, шьёрт побьери, это рутина! Это выматывает! Это бессонные ночи и литры кофе! И вообще, очевидное и изящное решение, как известно, приходит
Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.
От нас требуется писать быстро и без ошибок, у нас нет времени на рефакторинг и глобальные переделки, нет мотивации среди нескольких неплохих решений долго выбирать наилучшее. ***к ***к и в продакшн!
Ваше мышление негибкое, узкое и/или неорганизованное
Поэтому важно работать в команде. За годы работы на почти каждую проблему сразу всплывает собственный типичный подход «я всегда так делал», и уже не видно альтернатив.
Если воспринимать конечную цель программирования как нахождение верного решения, а не спектра возможных решений, вам ни за что не стать успешным программистом.
Когда-то я доводил код до формы, устраивающей меня. Сначала писал простыню говнокода, которая просто работает, а потом рефакторил, придавая универсальность и гибкость, в попытках написать идеальный код… Теперь я останавливаюсь на простыне, которая хотя бы не плоха — идеальный код никому не нужен, да и тот код, что я нахожу красивым, врядли *всем* покажется тоже красивым.
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы». Я это знаю, а потому не проверяю, как учитель орфографию учеников, а пишу юнит-тесты. Только тесты могут выявить эти глупые ошибки из невнимательности. Я не стараюсь.
А потому, у меня много опыта и я не был и не буду хорошим программистом :D
Однако я пишу код так, что он может быть нечитаем со стороны. Например, я инлайню сложные выражения, если они используются однажды, вместо вынесения их в отдельную переменную. Также (речь про Java) раньше я ставил final и this. везде, где только можно (сейчас я так не делаю)
Т.е. меня будут ругать за то, что я не пишу
int width = innerWidth/2; // здесь может быть выражение и посложнее этого
int height = innerHeight/2;
out(width, height, text);
а пишу
out(innerWidth/2, innerHeight/2, text);
за что меня часто и ругают «непонятно, что здесь написано!»
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
Зато подход «сначала пишем как пишется, потом рефакторим до годного» оправдывает себя тем, что не приходится задавать вопросы «а что, если...» на раннем этапе — сначала ставится вопрос «как решить эту задачу», и когда уже PoC-код работает, переходим к рефакторингу «сделать код универсальным, сделать код безопасным»
Я благодарен отцу за то, что еще раньше, когда мне было 10 лет, у него получилось заинтересовать меня программированием и обучить основам бейсика на Спектруме, поэтому вопрос «кем я буду, когда вырасту» был однозначно «программистом».
Мне было интересно все, это был сумбурный подход «все интересно, во всем разобраться, все попробовать сделать самому», кладбище мертворожденных проектов тянет на отдельный мир.
Извините, а отвечая на Ваш вопрос «как стать опытным программистом если нет ни любопытства, ни желания что-то изучать» — иметь мотивацию, которую я наблюдал у младших коллег «за это хорошо платят, поэтому идем на SO, копипастим работающий код и изменяем под свои нужды»
Эх, каюсь, но подходом «не знаю как сделать — нахожу решение на SO, понимаю принцип и пишу свой код» пользуюсь и до сих пор, а то и даже «не понимаю код, что написали на SO — копирую как есть, изменяю те места, которые понимаю, но до тех пор, пока код работает»
Прямо про себя прочитал.))
То ли специально чрезмерно иронизируете, то ли преувеличиваете своё ощущение усталости от похожих задач, то ли еще как назвать. Например:
Я крайне нетерпелив и невнимателен. Тот код, который еще мной же не пересматривался и не правился, набит ошибками «нулевого указателя» и «лишней единицы».
Противоречит упомянутому ниже вашему хорошему качеству:
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
В любом случае, хочу отметить пару опасных допущений данной фразы:
мне не быть хорошим программистом несмотря на 15 лет опыта… А потому, у меня много опыта и я не был и не буду хорошим программистом.
1) «Хороший» программист (инженер) — не звание на всю жизнь, нельзя лишь почевать на лаврах прошлых заслуг, человек на определенном этапе развития может быть таковым, а потом может выгореть или решить немного отдохнуть и перейти в режим просто «Норм» — в среднем нормально решает знакомые задачи знакомыми методами без лишнего погружения и разбора деталей.
2) Цифра стажа — не определяет автоматически попадение в категорию «Хорошего», лишь повышая вероятность накопления определенного опыта, т.к. см. 1 первый — важно и как человек провел эти года, и каков он сейчас.
Честно говоря, первым делом полез посмотреть, сколько у вас подписчиков и не входите ли вы в Кольцо Переводов… =D
Ну а про способы борьбы с рутиной и депрессией, они у всех разные. К сожалению, многие идут по пути наименьшего сопротивления и выбирают один из трёх вариантов: спиться, зожнуться, либо сектантствовать. Хотя как по мне, эти варианты практически бесполезны, и огонёк не возвращают. Творческую натуру надо кормить разнообразными творческими занятиями, тогда она будет периодически проявляться и в работе.
Суть программирования есть решение проблем. Это и есть причина создания компьютеров! Всякий раз, когда вы начинаете работать над программой, вы сталкиваетесь с целой «стопкой» проблем
Мне кажется, лучше рассматривать программирование как стопку задач, а не стопку проблем )))
Проблема — это ИМХО нечто внезапное и неприятное. Например, когда посреди разработки монитор сдох.
А написание кода — какая же тут проблема, если добровольно за это взялся?
Проблема: аргх, у нас в системе опять что-то сломалось, пользователи злы и не могут работать, репутация тает
Задача: выяснить, что сломалось, почему сломалось и как быстро это исправить
Анализ: возник непредвиденный кейс, невыявленный ранее из-за сложности системы
Сопутствующая проблема: Исправить сходу не получится из-за ограничений платформы и отсутствия нужных инструментов
Сопутствующая задача: выяснить способы обхода проблемы
Сопутствующий анализ: определить наилучшее в данной ситуации обходное решение
Сопутствующее решение: реализовать решение
Решение: выкатить сопутствующее решение, устранить возможность похожих проблем в будущем.
И при таком подходе «проблема -> задача -> анализ -> решение» не возникает противоречия, а неизбежный фрустрирующий фактор сведен до минимума.
Решение:
В английском слово «problem» имеет смысл «задача», в контексте решения задач. «Solve this problem» — «Решите эту задачу». Во время перевода смысл слегка потерялся :)
Для многих достаточно одного: вам 18+ лет и вы ни разу ничего не прогали в 3 часа ночи.
Поясню. Призвание к 18 годам должно уже проявится, и что-то на каком-то языке программирования вы уже должны уметь писать. Без призвания сидеть перед монитором с буквами — это свою угробить жизнь. Чтобы сидеть и прогать в 3 часа ночи нужно 1) любопытство и я бы даже сказал страсть 2) воля к победе и бесстрашие перед множеством проблем, упорство 4) способность разгребать доки и чужой код 5) самостоятельность… короче, 1 критерий вместо 10, и в отличие от перечисленных в статье этот один легко определяется (каждый сам для себя легко на него ответит, самообман невозможен).
Напротив, если парень не сидел за программированием ночами уже в школе, то его шансы стать хорошим программистом сильно падают, потому что большинство из них сидит.
Офтоп: Как-то в детстве я сказал, что не намерен плакать по поводу смерти Брежнева, потому что мы не родственники и получил кучу «минусов» от учителя и одноклассников, хотя в целом это была правда. Что изменилось с тех пор? Покажи людям красную тряпку и готовься отгребать :).
То есть вы считаете, что поведение (в отношении учебы) увлеченного школьника зависит от того, какие у этого школьника гениталии?
Считается, что представителям мужского пола легче войти в состояние потока, в то время как женщины более способны к многозадачности.
О справедливости судить не возьмусь.
Все проще. Я просто заметил что критерий неверный. Потому что школьницы не сидят ночами экспериментируя с технологиями программирования. Но все равно некоторые потом становятся программистами.
Но борцы с предрассудками читают между строк то что им хочется.
школьницы не сидят ночами экспериментируя с технологиями программированияВы не могли бы пометить, на основании чего такой вывод сделан? Мне действительно интересно =D
Друзья, знакомые, коллеги, искал персонал, люди рассказывали о себе.
Предубеждений у меня нет.
Так не бывает, прямо скажем. Предубеждения есть у любого человека, воспитанного в обществе.
Я не воспитан в обществе.
Гм. Мне казалось, вы упоминали одноклассников. Следовательно, вы учились в школе. Нет? У вас нет высшего образования? Вы не работали в коллективе?
У меня критический научный склад ума.
Это очень легко сказать, но очень сложно доказать. На мой личный вкус для научного склада ума вы слишком легко обходитесь с наблюдениями.
Критерий, несомненно, неверный: школьники не сидят ночами, экспериментируя с технологиями программирования, но некоторые все равно потом становятся программистами. Я вот, например.
Но сказали вы совсем не это.
Сидят. Я сидел. Все мои друзья программисты которых знаю сидели. Моя жена программист но у нее даже компьютера не было. Критерий годный для мужчин но сильно недостоверный для женщин.
Сидят. Я сидел. Все мои друзья программисты которых знаю сидели.
Я же вам уже сказал, что я вот не сидел. Почему-то этот пример — в отличие от примера вашей жены — вы отвергаете.
Так что нет, для мужчин этот критерий такой же негодный.
Настолько же не годный? В точно такой же степени? Т.е. если навскидку спросить среднюю жену на должности программиста программировала ли она по ночам до 18 то вероятность положительного ответа та же что для парня? Моя статистика говорит обратное. Возможно ваша выборка предвзята?
В точно такой же степени?
Ну да. Вы привели один контр-пример, я привел один контр-пример.
Моя статистика говорит обратное.
На какого размера выборке собрана ваша статистика, как проводились измерения, какой критерий оценки статистической достоверности использовался?
Мне, впрочем, вообще интересно, как вы собираетесь подтверждать критерий "если не засиживался — хорошим программистом не станет", безотносительно пола.
На какого размера выборке собрана ваша статистика, как проводились измерения, какой критерий оценки статистической достоверности использовался?Для меня это выглядит как троллинг. Вам хочется нарисовать себе врага и переболтать его и все тут.
Мне, впрочем, вообще интересно, как вы собираетесь подтверждать критерий «если не засиживался — хорошим программистом не станет», безотносительно пола.Это был довольно несерьезный критерий, высказанный не мной. Заключался он в том, что те кто не заболел с самого начала в последствии не будут слишком хороши. В основном это верно. Не считая, того факта, что женщинам психологически в гораздо меньшей степени свойственно «болеть» технологиями. Или вы хотите спорить именно насчет фактов нарушения режима дня, засиживания ровно до 3 часов и так далее?
Собственно единственный тезис заслуживающий обсуждения — это тот факт, что мужчинам свойственно гораздо сильнее увлекаться техникой и в частности программированием чем женщинам. Увлечение, которое для мужчины почти как основной инстинкт, для женщины карьера, хобби, самоутверждение, одна из интересных вещей. Сидеть в подвале, набитом электроникой и компьютерами, как доктор зло — типичная мечта мальчишки конца 80, и фактически ниодной девчонки того времени (исключения конечно существуют всегда, но это исключения). Кстати, я начинал работать в отделе АСУ, полностью состоящем из женщин программистов, а потом работал в коллективе где отношение было пополам. Так что я знаю о чем говорю.
Сейчас программирование превратилось в рутину, обычную профессию, поэтому не особо знаю что твориться в головах у молодежи сейчас.
Для меня это выглядит как троллинг. Вам хочется нарисовать себе врага и переболтать его и все тут.
Неа, мне хочется обойтись без голословных утверждений.
Это был довольно несерьезный критерий, высказанный не мной.
Вы однако, с ним согласились: "Критерий годный для мужчин".
В основном это верно.
В основном это верно ровно настолько, насколько верно, что чем раньше начнешь заниматься чем-то, тем больше у тебя времени на освоение навыка. И, одновременно с этим, чем сильнее ты увлечен тем, чем занимаешься, тем больше ресурсов ты в это можешь вложить. И, внезапно, это одинаково верно вне зависимости от пола.
Но вот насчет "заболеть" вопрос сильно отдельный, и как раз с ним я и спорю в первоначальном критерии. Не надо "болеть" программированием, чтобы быть хорошим программистом.
Или вы хотите спорить именно насчет режиа дня, засиживания ровнго до 3 часов и так далее?
… а если не спорить, то может внезапно выясниться, что все-таки нет никакой разницы между применимостью этого критерия в зависимости от пола.
В основном это верно ровно настолько, насколько верно, что чем раньше начнешь заниматься чем-то, тем больше у тебя времени на освоение навыка. И, одновременно с этим, чем сильнее ты увлечен тем, чем занимаешься, тем больше ресурсов ты в это можешь вложить. И, внезапно, это одинаково верно вне зависимости от пола.Стать программистом можно исходя из разных мотиваций и эти мотивации зависят от пола. Поэтому это работает по разному. В общем это уже стало слишком сложно. Я сам запутался что мы тут друг другу доказываем.
Но вот насчет «заболеть» вопрос сильно отдельный, и как раз с ним я и спорю в первоначальном критерии. Не надо «болеть» программированием, чтобы быть хорошим программистом.А, вы об этом. Совершенно верно. Можно быть хорошим программистом не болея программированием. В 90-е годы правда таких почти не было. Сейчас есть, потому что это уже просто работа за деньги а не увлечение.
Холодный профессионал почти всегда может не уступать горячему энтузиасту в практических задачах. Энтузиаст, но плохой профессионал понапишет или понапихает фреймворков, на-изобретает сложных алгоритмов. Профессионал, но не энтузиаст просто найдет хорошее решение задачи. В итоге реальный эффект будет примерно одинаковым.
Хотя, если брать средне-статистически, таки энтузиастов среди сильных программистов пока еще большинство. Кого ни спроси, все нерды с детства по сути.
эти мотивации зависят от пола.
Почему?
(ну и сразу: как это доказать?)
Кого ни спроси, все нерды с детства по сути.
Я не знаю, кого вы считаете сильным программистом, но я знаю достаточно хороших программистов, которые не были нердами в детстве.
Я не знаю, кого вы считаете сильным программистом, но я знаю достаточно хороших программистов, которые не были нердами в детстве.Вспомнил одного такого. Написал буквально пару программ для себя после школы, а потом после первого же проекта попал в тимлиды и ведущие разработчики без особых усилий. По-моему фишка была в том, что у него был старший брат, который перехватывал инициативу и ему было уже просто не интересно идти по следам. Поэтому случайно он не был нердом. Больше особо не вспоминается. Возможно поколение 2000-х оно другое, не знаю.
Сильные — это конечно не те которые могут написать код или UI по спецификации. Те кому доверяют отвечать за архитектуру чего-то не совсем ординарного или ее часть как минимум.
Насчет зависимости мотиваций от пола, тут можно приводить тысячу примеров, даже не знаю с чего начать. Внешняя сторона очевидна: программистов мужчин больше, увлекающихся техникой мальчишек больше и так далее. Конкретно, я в детстве писал игры на ассемблере и пара моих одноклассников увлекались чем-то подобным, а мои одноклассницы вообще не интересовались что такое компьютер. Однажды я написал «мега-фреймворк» чисто из программистского зуда и подсадил на него свою компанию, хотя мне это фактически запрещали. Можете представить, чтобы подобную глупость сделала женщина, и которая при том была бы довольно средним программистом вроде меня? Зачем ей это (откуда такие мотивации)? И так далее. В чем причина — в гормонах или в воспитании, это более сложный вопрос, который мы тут явно не решим.
Можете представить, чтобы подобную глупость сделала женщина
Да, глупость не уникальна для мужчин
Зачем ей это (откуда такие мотивации)?
Затем же зачем и вам
программистов мужчин больше
В восьмидесятые, в СССР, было ровно наоборот и програмирование считалось более женской професией (сужу по рассказам родителей) да и сейчас ситуация исправляется и женщин в ИТ все больше
Я говорю о той действительности которую вижу. В вашем круге знакомств есть женшина-крутой программист, которая и фреймворк напишет если надо и архитектуру спроектирует и проект вытянет? В моем нет никого даже близко похожего. С одной стороны в программировании в целом пока женщ н мало. Но с другой стороны раз их мало, значит туда должны попадать самые лучшие и самые мотивированные. Значит в среднем они должны превосходить мужчин. Но ведь нет такого. В общем извините, платон мне друг но истина дороже. Может я что-то упускаю, время покажет.
В вашем круге знакомств есть женшина-крутой программист, которая и фреймворк напишет если надо и архитектуру спроектирует и проект вытянет?
В моем круге знакомств и мужчин таких крайне мало. Если посчитать их долю от доли всех виденных мной мужчин-программистов, а потом взять ту же долю от всех виденных мной женщин-программистов, получится сильно меньше единицы.
Но с другой стороны раз их мало, значит туда должны попадать самые лучшие и самые мотивированные. Значит в среднем они должны превосходить мужчин.
Эээ… конечно, нет. Даже если предположить, что первое предложение верно (что не факт), второе из него никак не вытекает.
Т.е. вы их не видели, я их не видел, но они точно есть и в приличном количестве. Понимаете же что это не убедительно. Заметте, я не говорю что женщины менее способны. По моей выборке в способностях разницы нет. Им просто не так интересно по каким-то причинам. Больше гормональным или больше культурным не знаю.
По последнему вашему возражению не понял. Выглядит как отрицание очевидного.
они точно есть и в приличном количестве.
… а откуда взялось "в приличном количестве"?
Им просто не так интересно по каким-то причинам.
… в вашей выборке?
Больше гормональным или больше культурным не знаю.
Не знаете, но говорите, что причина в поле.
Выглядит как отрицание очевидного.
Вам очевидно, что женщины в среднем должны превосходить мужчин? Или вы о каком-то другом возражении?
… а откуда взялось «в приличном количестве»?Слово «приличном» появилось, чтобы вы не привели единичный пример из интернета. Но вы все равно нашли к чему прицепиться. Раз вы выкручиваетесь, значит у вас нет настоящих оснований для уверенности. Вам просто хочется отстаивать модное мнение, выгодное вам психологически. Если бы сейчас был СССР, то вы так же горячо убеждали бы меня в преимуществах коммунизма.
Если бы вы вместо демагогии сразу привели какие-то убедительные примеры, я бы сразу сдался. Потому что была бы ваша выборка против моей.
… в вашей выборке?В вашей в целом тоже, если судить по примерам, которые вы приводили выше.
Не знаете, но говорите, что причина в поле.Мотивация скорее всего связана с полом, но я не уверен, что эта связь настолько сильная, что будет иметь принципиальное значение в другой культуре воспитания женщин.
Вам очевидно, что женщины в среднем должны превосходить мужчин? Или вы о каком-то другом возражении?Вроде того. Тезис был довольно ясный, возражений к нему я не увидел.
Чтобы вы не привели единичный пример из интернета.
Ну то есть это какое-то придуманное вами утверждение. Окей.
Раз вы выкручиваетесь, значит у вас нет оснований правоты.
Оснований какой правоты, собственно? Я пока просто задаю вопросы и привожу примеры.
В вашей в целом тоже.
О нет. В моей выборке женщинам не менее интересно, чем мужчинам.
Мотивация скорее всего связана с полом
Почему бы? Как это доказать?
Тезис был довольно ясный, возражений к нему я не увидел.
Я могу повторить возражение, если вы с первого раза не увидели: высказывание "в среднем они [женщины] должны превосходить мужчин" никак не вытекает из утверждения "раз их [женщин] мало, значит туда [в программирование] должны попадать самые лучшие и самые мотивированные". Впрочем, и высказывание "должны попадать" не вытекает из "раз их мало", но это уже нюансы. Оба ваших "значит" ничем не обоснованы.
Я могу повторить возражение, если вы с первого раза не увидели:Это не возражение. Это просто отрицание. Давайте поясню.
Возьмем 100 китайцев и 100 индусов. Допустим, все индусы работают программистами, а китайцы пока не имеют такой возможности или желания по каким-то причинам. Потом китайцы открывают для себя эту возможность. При этом, работа интересная и платят дочерта. В какой-то момент 10 китайцев тоже пробились в программисты.
Теперь сравниваем средний уровень китайцев и индусов на рынке. Если даже предположить, что в программисты попали совершенно случайные китайцы, то они должны иметь тот же средний уровень что и индусы. Но на самом деле это очень мало вероятно. Первые — это всегда лучшие, потому что это те кому интереснее и у кого лучше получается. Значит средний китаец на рынке должен быть сильнее среднего индуса (пока соотношение типа 10 к 100).
И аналогично это по идее должно работать для женщин и мужчин…
Если даже предположить, что в программисты попали совершенно случайные китайцы, то они должны иметь тот же средний уровень что и индусы.
Совершенно не обязательно, потому что вы исходите из равных возможностей, которые в вашем примере отсутствуют. Но не суть. Дальнейшего это не меняет.
Первые — это всегда лучшие, потому что это те кому интереснее и у кого лучше получается.
А чем, простите, обосновывается это утверждение? Первые — это просто… первые. Те, кто первым попробовал. Может быть, они просто самые жадные. Или самые бедные. Или самые удачливые.
И особенно это относится к "лучше получается". Лучше, чем у кого? Они первые, им не с кем сравнивать.
Что конкретно вам не понятно в моем комментарии? Вопрос, на чем основано ваше утверждение, что первые — всегда лучшие?
Такой фактор конечно же есть, и это именно он: изначально более низкая мотивация к подобного рода работе. Другого не видно.
это естественное предположение для высокооплачиваемой, престижной и не пыльной работы
Вот вам и наглядная демонстрация ваших предубеждений.
То, что для вас это "естественное предположение", не делает его верным — или хотя бы очевидным для других. Я вот не понимаю, почему первые люди, рванувшие в сторону "высокооплачиваемой, престижной и непыльной работы" должны быть лучше подходящими для этой работы.
Проще говоря, вот у вас есть сто человек. Проходит слух, что где-то есть какая-то хорошая работа. Какие десять человек первыми пойдут на этот слух?
Вытекающая из вашего сообщения гипотеза, что по настоящему потенциально одаренные в области программирования женщины пока не пошли в программирование мне кажется крайне неубедительной. Как минимум она противоречит тому что вы выше сами же утверждали: что для них все работает так же как для мужчин. Опровергнуть что-то подобное конечно нереально, но я работал с женщинами, ставил им задачи, брал их на работу. В этом смысле у них все работает в точности как у мужчин, только в меньшем масштабе (из за менее прямой мотивированности по моим оценкам).
Не важно кто пойдет. Важно кого в итоге возьмут на работу.
… а возьмут на работу тех, кто удовлетворяет условиям. Не лучших из лучших в популяции, а тех, кто удовлетворяет условиям. Пришло десять человек, все десять выше минимальной границы — взяли. При наличии конкурса — взяли тех, кто лучше других конкурсантов (а не, опять же, всей популяции).
Скорее возьмут все равно тех что выше среднего.
Выше среднего чего? Среди кого?
Вытекающая из вашего сообщения гипотеза, что по настоящему потенциально одаренные в области программирования женщины пока не пошли в программирование
Эта гипотеза никак из моего сообщения не вытекает. Это ваша гипотеза, вы с ней и разбирайтесь.
Эта гипотеза никак из моего сообщения не вытекает. Это ваша гипотеза, вы с ней и разбирайтесь.Я вынужден был ее сочинить от вашего имени, потому что вы не объясняете как так получается. Вы просто пишите что не согласны и все. Типа это все равно ничего не доказывает и всегда можно найти другие объяснения. Можно всегда, но обычно работает наиболее простое и понятное объяснение (а не наиболее политкорректное, увы).
Я и говорю: сами сочинили — сами и разбирайтесь.
А я пока даже не понимаю, что именно вы ожидаете, что я объясню. В основном меня интересуют основания для ваших утверждений и доказательства для ваших выводов, и пока что с ними весьма скудно.
Объясните по каким причинам немногочисленные работающие женщины программисты обычно в среднем не дотягивают по уровню даже до среднестатистического случайно взятого программиста-мужчины на этом же предприятии.
Я не вижу смысла (и не могу) объяснять что-то, чего я не наблюдаю. В компании, где я работаю, ситуация другая.
Что останавливает женщин, которые потенциально могут быть ведущими программистами компаний, но сегодня не работают программистами пойти в программисты
О, множество вещей, вот прямо начиная с общественной позиции "это не женское дело" и распространенного мнения, что женщины худшие программисты, чем мужчины. На следующем месте будут наниматели, которые принципиально не берут женщин на работу, потому что, в числе прочего, женщина может в любой момент уйти в декрет, а зачем им это надо. На этом список не заканчивается, но уже достаточно, в принципе.
(Что характерно, примеры этих позиций сравнительно регулярно встречаются в комментариях на хабре)
Я не вижу смысла (и не могу) объяснять что-то, чего я не наблюдаю. В компании, где я работаю, ситуация другая.Хорошо, принимается. Но я пока такого не видел. Предполагаю, что вы рассматриваете только подмножество программистов, делающих довольно простую и рутинную работу, исключая из выборки тех кто решает действительно сложные задачи. Это подгон под желаемый результат.
О, множество вещей, вот прямо начиная с общественной позиции «это не женское дело» и распространенного мнения, что женщины худшие программисты, чем мужчины.Не проходит. Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты. Женщин со средними способностями прокинут из за предвзятости. И затем мы должны наблюдать картину, когда средняя женщина программист намного круче среднего программиста мужчины (хотя возможно ее никуда особо не пускают). Но это не та картина, которую мы наблюдаем. Нужно другое объяснение.
Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты.
«одаренный специалист» и «умеет пробиваться через сито предрассудков» это разные скиллы.
Женщин со средними способностями прокинут из за предвзятости.
«Способности» это нечто трудно измеримое, на работу принимают по измеряемой опыту и квалификации. А они не бывает врождёнными, и те кого откинут на нижнем уровне просто не имеют шанса дорасти до верхнего.
«одаренный специалист» и «умеет пробиваться через сито предрассудков» это разные скиллы...«Способности» это нечто трудно измеримое, на работу принимают по измеряемой опыту и квалификации.Не видел такого. Нпример, я после как-то после 3 слов взял на работу программистку без опыта и она до сих пор лучший специалист во отделе (парни приходили и покруче, но больше чем на пол-года не задерживались). Потому что если человек говорит с тобой на одном языке, это сразу понятно независимо от пола и даже опыта. Проблемы предрассудков сильно преувеличены.
Не видел такого.
Какого конкретно?
Проблемы предрассудков сильно преувеличены.
Это так кажется, пока эти предрассудки не направлены на вас. А когда ты каждый день слышишь какую-нибудь фразу, которую ничем, кроме предрассудка, объяснить нельзя (и регулярно сталкиваешься с последствиями этих фраз) — так уже не кажется.
Отнюдь. Бывает, и я регулярно с ними сталкиваюсь. Просто многие люди их не замечают (и/или не испытывают от них дискомфорта).
Скорее «не замечают».
И это лишний раз подтверждает, что проблема предрассудков не преувеличена.
Собственно, ни в оригинальной фразе, ни в моем ответе не было ничего про предрассудки в сторону женщин (или вообще по гендерному признаку).
Когда кто-то говорит про то, что надо кормить семью, то такого неодобрения нет.
Я подозреваю, что от формулировки зависит. Лично меня позиция "давайте платить мужчине больше, ему семью кормить" раздражает не меньше, чем соседняя гендерно-ориентированная. Позиция "давайте платить семейному больше, у него семья" — тоже, как и позиция "людям после X лет надо больше денег, им надо семью кормить". При этом позиция "я хочу больше денег, мне семью кормить" меня лично ничем не раздражает (до тех пор, пока человек не считает, что у него большее право на деньги, чем у конкурента, которому надо кормить не семью, а хобби), потому что каждый сам для себя выбирает свои расходы.
Я лёгкий намёк на это распарсил в первой фразе из того, что я тогда процитировал
Вы распарсили неверно (что, кстати, опять показывает распространенность предрассудков). Но не суть, да.
Это (и реакция социума) реинфорсит позицию мужчины как добытчика, что мужчинадолжен (в данном случае зарабатывать бабло), не так ли?
Если в формулировке упоминается гендер, то да. Но из приведенных мной примеров это есть только в первом, и я сразу явно говорю, что это меня раздражает не меньше любого другого гендерного стереотипа.
Там по полу автора всё видно
Эээ… но нет же. Если мужчина пишет "мне семью кормить", это не обязательно значит, что ему кормить семью, потому что он мужчина. А какие еще выводы вы можете сделать из пола автора?
Никогда не встречались с феминистическим мнением
Встречался. Я с каким-то невообразимым количеством мнений встречался, и далеко не со всеми из них согласен, безотносительно привязанного ярлыка.
Предполагаю, что вы рассматриваете только подмножество программистов, делающих довольно простую и рутинную работу, исключая из выборки тех кто решает действительно сложные задачи. Это подгон под желаемый результат.
Ровно наоборот, ваше предположение — это подгонка под тот результат, который вам бы хотелось. И оно неверно: все девушки-программисты, с которыми я контактирую в компании, работают в команде, отвечающей за ядро системы, и там предостаточно "действительно сложных задач".
Через это сито предрассудков первыми на работу должны пробиться одаренные женщины-прирожденные программисты.
Снова нет: мне неизвестно о какой-либо корреляции между способностью к программированию и способности преодолевать общественное сопротивление. Вам известно? Можете показать хорошее исследование?
Женщин со средними способностями прокинут из за предвзятости.
Опять-таки, люди, которые не берут женщин на работу, потому что это женщины, в моем опыте, не смотрят на их квалификацию. Поэтому я нахожу это ваше утверждение безосновательным.
И затем мы должны наблюдать картину, когда средняя женщина программист намного круче среднего программиста мужчины
Я, прямо скажем, не понимаю, как вы оцениваете "средних", и как вы их вообще берете. Зато я могу поделиться тем наблюдением, что в конкретно моей выборке (в конкретных компаниях, опять-таки), худшая женщина-программист была лучше худшего мужчины программиста, причем с хорошим отрывом.
Необходимая оговорка — я, естественно, сравниваю в рамках сопоставимого опыта: если, грубо говоря, все девушки распределены в опыте 3-15 лет, мужчин с опытом 25-35 мы не рассматриваем.
Почему (в моей нынешней зоне наблюдения) среди разработчиков нет женщин старше — вопрос отдельно интересный, конечно.
И оно неверно: все девушки-программисты, с которыми я контактирую в компании, работают в команде, отвечающей за ядро системы, и там предостаточно «действительно сложных задач».Если так, это круто и необычно для меня. Возможно я что-то не учитываю в своих выводах.
Снова нет: мне неизвестно о какой-либо корреляции между способностью к программированию и способности преодолевать общественное сопротивление. Вам известно? Можете показать хорошее исследование?Конечно. Называется «Капитал» К. Маркса. Никакие предрассудки не заставят бизнес закономерно брать слабых женщин вместо умных женщин просто потому, что слабые лучше сумели себя подать.
Называется «Капитал» К. Маркса.
Это не исследование.
просто потому, что слабые лучше сумели себя подать.
Вообще-то, это регулярно происходит безотносительно пола собеседуемого.
Никакие предрассудки не заставят бизнес закономерно брать слабых женщин вместо умных женщин
А я, собственно, нигде и не говорил о том, чтобы брать слабых вместо сильных. Я говорил о том, что не брать вообще. И вот это я видел своими глазами.
А я, собственно, нигде и не говорил о том, чтобы брать слабых вместо сильных. Я говорил о том, что не брать вообще. И вот это я видел своими глазами.Но этот факт не связан с природной мотивированностью женщин к программированию. Т.е. предрассудки могут существовать как на пустом месте, так и на реальной почве. Для того, чтобы рассматривать природу отдельно а предрассудки отдельно я и предложил сравнивать не количество женщин и мужщин в программировании а средний уровень среди имеющихся. И дальше смотрите про китайцев-индусов и все покругу…
Но этот факт не связан с природной мотивированностью женщин к программированию.
Не связан. Потому что нет никакой "природной мотивированности" к профессиям.
Но. Вы спросили "что останавливает женщин [...] пойти в программисты" — я ответил.
я и предложил сравнивать не количество женщин и мужщин в программировании а средний уровень среди имеющихся
И как вам это поможет оценить мотивированность?
Что еще веселее, как вообще вы предлагаете оценивать (не то что сравнивать) "средний уровень"? Как правильно составить выборку? По какой методике оценивать? Как усреднять?
Если же говорить об обычных человеческих наблюдениях, то мы уже выяснили, что они у нас с вами радикально отличаются, а потому обсуждать их весьма бесполезно.
Но. Вы спросили «что останавливает женщин [...] пойти в программисты» — я ответил.Вы ответили что останавливает всех женщин, но не объяснили почему это отсеивает лучших программистов-женщин но не отсеивает худших. В целом ваш ответ был «такой аномальный отсев возможен», возможен, но это не убедительно.
И как вам это поможет оценить мотивированность?Никак. Мотивированность — самое простое объяснение аномалии в относительном качестве специалистов мужчин и женщин, которую я наблюдаю. Учитывая насколько мало женщин идут в программисты можно ожидать, что это будут просто супер-специалисты, но они в лучшем случае не уступают. Другие объяснения для меня выглядят слишком сложными и высосанными из пальца.
К слову говоря, я не уверен даже что я прав. Поэтому и поддерживал этот спор. Слишком долго его к сожалению поддерживать не получается, потому что карма и так уже улетела слишком далеко.
Вести подобные споры, увы, то же самое что отстаивать генетику во времена Мичурина. Очень неблагодарное занятие. И кстати, этот слив кармы указывает на то, что большинство поддерживает вашу позицию. Тогда где все эти жено-ненавистники о которых вы говорите непонятно.
Вы ответили что останавливает всех женщин, но не объяснили почему это отсеивает лучших программистов-женщин но не отсеивает худших.
Ну да. Я не вижу, зачем "лучших" должно отсеивать больше, чем "худших".
Учитывая насколько мало женщин идут в программисты можно ожидать, что это будут просто супер-специалисты, но они в лучшем случае не уступают. Другие объяснения для меня выглядят слишком сложными и высосанными из пальца.
Для меня высосанным из пальца выглядит утверждение "учитывая, насколько мало Х идет в У, можно ожидать, что это будут супер-специалисты".
Ну да. Я не вижу, зачем «лучших» должно отсеивать больше, чем «худших».Конечно не должно, потому и не видите.
Нарисуйте картину, как вы себе это представляете. Имеется, скажем 5% потенциально гениальных и мотивированных женщин программистов. И 15% менее способных, которые тоже хотят быть программистами.
Допустим, среди общего числа программистов женщин 5%. Тогда почему это не те 5% гениев? Какой фильтр остановил эти 5% гениев и вместо этого пропустил всех понемногу?
Предрассудки не могут фильтровать только гениев. Это вы вроде согласились.
Бизнес IT всегда берет лучших из приходящих кандидатов и никогда намеренно не будет искать посредственностей, отвергая умных (потому что посредственности «удовлетворяют требованиям»). С этим почти согласились.
Возможно эти 5% просто не идут работать программистами. Тогда это подтверждает мою теорию: женщинам не интересно. Другой мой вариант — они идут, но не реализуют свой природный потенциал в полной мере потому что им не настолько интересно как мужчинам.
Ваша версия фильтра? Моя картина проста и понятна.
Вы не можете предложить никакой убедительной картины. Вместо этого вы только обвиняете мою в недоказуемости.
Могу опять предложить гипотезу от вашего имени. Допустим, одаренные женщины не ходят идти программистами, потому что тоже верят в предрассудки, что это не для женщин и что с серьезными задачами им все равно не справиться, а посредственным все равно — они просто хотят денег. Т.е. женская половина человечества просто еще не открыла для себя всю притягательность IT и не верит что может работать наравне с мужчинами. Это возможно, хотя не очень соответствует тому что я вижу.
Замечание: ваш пример с любителями бабочек в другом сообщении ошибочен. Если бы любители бабочек подвергались необоснованной дискриминации при приеме на работу программистами, то средний любитель бабочек тоже был бы лучше среднего не-любителя по тем же причинам: бизнес предубежденный против любителей бабочек принимал бы их только если они действительно блестящие специалисты.
Имеется, скажем 5% потенциально гениальных и мотивированных женщин программистов.
Не так. Имеется 5% потенциально гениальных и, вообще говоря, независимо выбранные 5% мотивированных.
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, чтобы делать о нем выводы? Я вот точно нет.
Если бы природные способности вкупе с природными мотивациями вообще почти ни на что не влияли, тогда да, это испортило бы картину. Но по моим наблюдениям почти только они и важны.
Проблема в том, что эти «наблюдения» регистрируют неизмеримо слабый шум на фоне огромного сигнала ошибки выжившего. Никто не пробловал провести эксперимент строго одинакового воспитания мальчиков и девочек с замерами что из этого вышло.
Я здесь не вижу каким образом «окружение» заставляло нас всем этим заниматься. Это был просто некий техно-инстинкт в чистом виде.
Уже после 3х лет говорить об инстинктах слишком сложно. С одной стороны я тоже на удивление замечаю, что в 2 года моему сыну интересны тракторы а дочери куклы. С другой — я лишь хочу себя тешить уверенностью, что я воспитывал их одинаково (включая выбор одежды, слов, интонаций). При этом абсолютно очевидно, что бабушки/дедушки, друзья, садик и т.д. не настроены так нейтрально. В какой степени это повлияло — можно только гадать, измеримых данных нет.
Сложно сказать, где тут «природная мотивация», а где влияние общества.
Тогда почему это не те 5% гениев?
А почему должны быть?
Какой фильтр остановил эти 5% гениев и вместо этого пропустил всех понемногу?
Например, случайный отбор.
Ваша версия фильтра?
… вот, например, случайный отбор. В этом случае, при ваших цифрах, на больших выборках вы будете наблюдать среди всех программистов распределение, близкое к оригинальному (т.е. ~1/4 "гениев").
Бизнес IT всегда берет лучших из приходящих кандидатов
Это, заметим не всегда так. Мы вот в прошлом году не взяли "лучшего" кандидата, потому что этот кандидат был overqualified для нашей позиции. На одного, в вашей терминологии, гения меньше в нашем распределении.
Могу опять предложить гипотезу от вашего имени.
Пожалуйста, предлагайте свои гипотезы от своего имени.
Замечание: ваш пример с любителями бабочек в другом сообщении ошибочен.
Отнюдь, я достаточно аккуратно его переписал из вашего текста.
бизнес предубежденный против любителей бабочек принимал бы их только если они действительно блестящие специалисты.
… и вы только что это подтвердили, приведя ту же самую аргументацию.
К слову, отказать overqualified человеку, если он сам на позицию стремится — это адский ад. Правильным здесь должно быть расписать позицию максимально достоверно, чтоб он сам отказался, если не готов. А если готов, то на это должны быть причины. Например, жрать нечего, потому что все ему на основании этого overqualified отказывают!
У вас есть что-то кроме anecdotical evidence?
Лично у меня — нет.
Есть работодатели, которые не берут мужчин без военного билета, потому что они могут уйти в армию.
Есть.
Ну, тогда я только могу повторить предыдущую фразу про забавность.
Я, собственно, с ней и не спорю.
То есть, получается, что разницы-то между полами в этом плане и нет?
Нет, не получается. В моих наблюдениях работодатели, которые не берут мужчин из-за армии, встречаются намного реже чем те, которые не берут женщин из-за декрета.
Получается, что женщинам тут лучше?
Не, не получается. Именно потому, что (в России в этой области) закон смещен в сторону защиты женщин, женщины оказываются менее привлекательными кандидатами для работодателей.
А по моим — ровно наоборот.
Вполне возможно.
На закон, я слышал, можно влиять.
Можно.
Однако, мы этого почему-то не наблюдаем.
Что, в частности, может означать, что ваш рациональный подход к проблеме отличается от рационального подхода других людей.
Рациональный подход — это такая штука, которая при равных вводных приводит к равному результату.
Но почему вы думаете, что у вас равные вводные? Одна из проблем общественных начинаний именно в том, что вводные слишком обширны и разнообразны, чтобы различные рациональные агенты опирались на гарантированно один и тот же их набор.
Я исхожу из довольно небольшого множества предположений.
А другие рациональные агенты, возможно, из большего. Поэтому и выработанная стратегия оказывается другой.
Объясните по каким причинам немногочисленные работающие женщины программисты обычно в среднем не дотягивают по уровню даже до среднестатистического
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 года уезжают в Тибет и забывают о программировании вообще. И повторяют это ещё пару раз. Индусы же продолжают дальше работать и набираться опыта.
Попробуйте оценить видимый средний уровень во всех вариантах.
Тут я потерялся, кто из них — женщины, так как всякие буткампы только для женщин есть, курсы только для женщин есть, и так далее, а аналогичных вещей только для мужчин нет.
Я подозреваю, что потерялись вы потому, что здесь речь не о том, какое сообщество более ущемлено, а о том, как выборки из разных сообществ по-разному отражают их потенциальные способности.
(это не считая того, что аналогии врут)
Давайте я вам просто напомню исходную формулировку: "Раз людей, любящих бабочек, в программировании мало, значит туда должны попадать самые лучшие и самые мотивированные. Значит в среднем они должны превосходить людей, которые бабочек не любят."
Поэтому случайно он не был нердом.
Случайно. Очень занятно, как наблюдения, которые не вписываются в вашу картину мира, объявляются случайными.
Те кому доверяют отвечать за архитектуру чего-то не совсем ординарного или ее часть как минимум.
Таких, которые при этом не были бы нердами, я знаю больше одного.
Насчет зависимости мотиваций от пола, тут можно приводить тысячу примеров, даже не знаю с чего начать.
Начните хотя бы с одного примера. Пока что вы приводите примеры, в которых собственно мотивации никак не обозначены.
Можете представить, чтобы подобную глупость сделала женщина
Могу. Более того, я пару подобных случаев знаю.
Зачем ей это (откуда такие мотивации)?
А зачем это вам? Я с равным успехом ничего не знаю ни про их, ни про вашу мотивации.
Я вот, скажем, знаю, из каких мотиваций я делаю крупные рефакторинги (наполовину любовь к чистоте, наполовину — понимание, что это упростит дальнейшую работу), и, удивительным образом, коллега, сидящая неподалеку, недавно делала рефакторинг доверенной ей подсистемы из тех же мотиваций.
В чем причина — в гормонах или в воспитании, это более сложный вопрос, который мы тут явно не решим.
… это, однако, не помешало вам уверенно сказать, что мотивации зависят от пола (а не от воспитания).
ссылается на гипотезу о том, что люди разного пола обладают разными особенностями концентрации внимания.
Это та гипотеза, согласно которой девочки усидчивее и прилежнее?
Считается, что представителям мужского пола легче войти в состояние потока, в то время как женщины более способны к многозадачности.
Ой, нет, все наоборот.
та гипотеза, согласно которой девочки усидчивее и прилежнее?А разве второе — не факт? Академический успех, по-моему, и есть оборотная сторона прилежания (при условии равных способностей).
Так, я же написал в своем критерии про 18+. Для <18 мой критерий неприменим, для <18 все гораздо сложнее.
Почему?
Знаете, не обязательно что-то делать в три часа ночи, чтобы это любить.
А у некоторых людей больше одного интереса.
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.Критерий правильный, но многие сейчас частично без этого обходятся. Особенно если программист женского пола.
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом…Это справедливо для большей части профессий. Без этого вообще стать кем-то сложно.
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.Некоторым радость решенной проблемы заменяет радость получения зарплаты. Это конечно не лучший вариант но тоже работает.
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.Многие люди ненавидят учебу (если говорить о формальном учебном процессе, то у меня это просто фобия). Ничего фатального, можно всему научиться по мере поступления проблем на работе. Непонимание сначала накапливается, потом оно начинает мешать, потом можно почитать книгу на досуге и все недостающее осознать.
Если вы ленитесь думать и вы считаете сконцентрированное размышление скучной рутинной обязанностью, вам не стать успешным программистом…В целом верно, но в реальности не все так категорично. Среди программистов, как и в других областях, людей, которые предпочитают кодить вместо того чтобы думать хватает. Работа иногда находится и для них.
Если вы ждете, что кто-то будет думать за вас, и не хотите всматриваться в детали своего положения, вам ни за что не стать успешным программистом…
Если вы не очень гибки в своем мышлении и у вас сложности с организацией вашего кода, а также ваших мыслей, вам ни за что не стать успешным программистом.
Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.Однозначно это проблема в образе мышления, от которой надо просто избавиться. Здесь дело даже не в программировании. Мне кажется этот образ мышления прививается системой образования, в которой для любой задачи всегда заложен правильный ответ. В реальной жизни наоборот, его никогда нет.
Если вы пренебрегаете деталями и упускаете из вида мелочи, вам ни за что не стать успешным программистом.Это ерунда. Множество отличных программистов ненавидят детали и делают по 10 ошибок в каждой функции. Для этого есть тесты и дебаггер. Если в код изначально заложена работоспособная концепция, то так или иначе его можно заставить работать при любой ненависти к деталям. Если мозгов на работоспособную концепцию не хватило, внимания к деталям может быть недостаточно.
В целом, чтобы быть программистом нужно иметь мозг, который был бы неплох хотя-бы в одной из сходных с программированием области (математике, технике, естественных науках) и иметь мотивации тренировать этот мозг в направлении программирования.
Задача, которую решает мозг программиста по сути сводится к планированию и описанию того, что должно происходить с детерминированной системой, состоящей из байтов, для достижения заданной цели :). У одних людей мозг лучше приспособлен к этой задаче, у других хуже. И эта способность тренируется в определенных пределах.
Можно еще проще. «Задача программиста сводится к выборочному намагничиванию быстро вращающихся пластин». С уходом жеских дисков определение, конечно, устаревает, но суть не меняется.Так можно обозвать программистом любого сколь угодно простого агента. Суть моего определения на самом деле гораздо глубже.
На первый взгляд программирование кажется высоко-интеллектуальной областью, вроде высшей математики или научных исследований. Но с годами начинаешь понимать, что решаешь довольно простую задачу: представить что нужно получить в итоге и найти поведение для компьютера (машины Тьюринга по сути), которое приведет к нужному результату.
Особенно если программист женского пола.
Почему у всех проблемы с этим то????))))
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Вот прям вижу, как JS-разраб, пилящий на реакте, должен лезть в архитектуру ЭВМ…
А вот именно в этом и кроется проблема прожорливости современного софта: «программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
А вот именно в этом и кроется проблема прожорливости современного софта: «программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
Всё дело только в деньгах.
Бизнесу нужно быстро.
Если мне заплатят в 10 раз больше — я буду сидеть и оптимизировать. Я это люблю.
Но если я буду этим заниматься прямо сейчас — я просто протяну ноги от голода.
Бизнесу нужно быстро.Бизнесу — нет. «Эффективным манагерам» — да.
По моим наблюдениям в те места, где реа т не нужен его тащат «программисты». Более того, бывают случаи, когда все эти фреймворка не нужны, но их тащат. И здесь сказываете именно некомпетентность.
проблема прожорливости современного софта: «программисты» не знают как устроен компьютерУсловно 99% проблем производительности ПО решаются на уровнях сильно выше hardware. В обычных ЯП этот уровень почти недоступен, а хаки платформы могут привести к деградации в будущем.
Ресурсы, доступные ПО, вроде памяти и вычислительные, не очень связаны с устройством компьютеров и интуитивно известны всем. Их ограниченность просто игнорируют до какого-то момента.
«программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
Возник вопрос: а как программисту на условном реакте поможет знание архитектуры ЭВМ? Ибо от реакта до железа нагорожена такая туева хуча абстракций, так что, чтобы понять, какой машинный код отдастся на сьедение железу, придется очень хорошо разбираться в устройстве всех этих слоев, а не только нижайшего. А следовательно, почти невозможно, учитывая ограниченность человеческих ресурсов и огромное количество альтернатив…
Откуда я делаю вывод, что такому программисту необходимо лишь среднее понимание принципов устройства того же реакта и знание хороших практик, а с остальным разберется машина (за что спасибо умным и талантливым разработчикам хороших фреймворков, умных компиляторов и т.д.)
Возник вопрос: а как программисту на условном реакте поможет знание архитектуры ЭВМ?Ну например знание того, что операции со строками занимают время, грубо говоря, пропорциональное длине этих строк — а для целых чисел это не так может помочь и «программисту на условном реакте».
Откуда я делаю вывод, что такому программисту необходимо лишь среднее понимание принципов устройства того же реакта и знание хороших практик, а с остальным разберется машина (за что спасибо умным и талантливым разработчикам хороших фреймворков, умных компиляторов и т.д.)Никакие, сколь угодно умные и талантливые, разработчики компиляторов и фреймворков не могут изменить законов физики и математики.
С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.
Когда я вижу, что программа добавляет к часовому ролику субтитры за 3 минуты, к двухчасовому — за 12 минут, а к трёхчасовому — почти за полчаса… мне даже не нужно знать сколько там абстракций использовалось в этих фреймворках… я точно знаю, что программист их использовавший некомпетентен — и где-то там внутри сидит очередной «маляр Шлемиэль»…
Ну например знание того, что операции со строками занимают время, грубо говоря, пропорциональное длине этих строк — а для целых чисел это не так может помочь и «программисту на условном реакте».
Это любимые всеми алгоритмы. O(n) где n длина строки. И пусть оно хоть на машине тьюринга исполняется. От железа не зависим никак.
С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.
И это тоже обычные аглоритмы. Напиши нормальный алгоритм, и он нормально работать будет. На любой машине.
В итоге пришли к тому что у фронтов тоже надо спрашивать на собеседованиях как развернуть список. Иначе они такого понапишут.
20 лет назад я понял, что не смогу стать программистом хотя и мечтал об этом. Ну, а после этой статьи даже сомнения отбросил )))
Если вам не очень любопытно как работает компьютер и технологии в целом, вам ни за что не стать успешным программистом.
Если мне интересно, как работает компьютер и технологии, но больше меня интересует общение с моей женой и семьёй — это не очень любопытно или уже норм? Если меня интересует больше дизайн или подводное плаванье, но я не хочу этим зарабатывать, то это тоже сразу крест? Что значит «очень любопытно», а что значит «не очень любопытно»?
Если вы не разовьете в себе умение решать проблемы самостоятельно, вам ни за что не стать успешным программистом.
Никто из нас не может решать все проблемы самостоятельно. Лучшие умы говорят, что они пришли к чему-то потому, что основное до них придумали другие. Если я погуглил, прочитал книжку, спросил у коллеги, делегировал задачу и в итоге она решена — считается ли всё это, что я могу решать проблемы самостоятельно?
Если вы сдаетесь, едва столкнувшись с проблемой, вам ни за что не стать успешным программистом.
Как понять, когда пора сдаться потому, что игра не стоит свеч, а когда ты просто рано сдался?
Если вы не испытываете чувство восторга и выполненного достижения, когда решили проблему, вам ни за что не стать успешным программистом.
Если я ошущаю приятное чувство, но это не тот восторг, который был 10 лет назад, то что теперь?
Если вы ощущаете нехватку терпения в учебе и ждете, что вы сможете все освоить легко и быстро, вам ни за что не стать успешным программистом.
Как понять, что такое легко и быстро? Быстро насколько? Если я жду, что разберусь в Питоне за полгода достаточно хорошо для старта — это слишком быстро или нет?
И так далее все пункты.
Проблема же здесь в том, что никто в новой деятельности не чувствует уверенности во всех этих пунктах.
Если мне интересно, как работает компьютер и технологии, но больше меня интересует общение с моей женой и семьёй — это не очень любопытно или уже норм?Тут все понятно. Вы не программист. (шутка)
Никто из нас не может решать все проблемы самостоятельно. Лучшие умы говорят, что они пришли к чему-то потому, что основное до них придумали другие.Поверьте, эти умы всегда лгут. Подобные вещи говорят чтобы показать скромность, коллективизм и чтобы не замочили раньше времени как безумного одиночку. В наше время кругом интернет и это не так заметно, но в 90-е когда я начинал программировать совершенно нормально было сначала изобрести концепцию (вплоть до ООП), а потом про нее прочитать. Не говоря уже о банальном решении любой мыслимой задачи самостоятельно (решения конечно были страшными временами). Те у кого нет такого свойства могут быть программистами конечно тоже, но это однозначно минус.
И вывод будет тот же — «если вам не интересна ваша профессия, то вы будете в профессии весьма посредственным специалистом».
При смене архитектуры модульные тесты не всегда спасают. Часто даже мешают. Так что расширяемость архитектуры тоже важна.
Единственный случай когда расширение происходит «без сучка и задоринки» — это когда вы делаете «базовую версию» и вы же её потом «расширяете». Если «расширяет» кто-то другой — уже нужно говорить с ним и приходить к компромиссам, а если «расширять» будет неизвестно кто — то с вероятностью 90% ваш «задел» придётся сначала «извести под корень», а уже потом всё сделать «правильно» — так, чтобы не было протягивания силовых проводов через канализацию…
Я говорю не про оставление "заделов", а про неоставление "граблей".
Почему нет «задела» и «оставлены грабли»? Потому что N, в данном случае — это количество регистровых аргументов у инструкции. И оно как бы равно 3 у 80386, а у процессоров с FMA4 — оно равно 5… думаю что процессоров с N == 6 мы не увидим никогда.
Это «задел» или «грабли»? Вот как вы оцениваете?
Я это оцениваю как изолированный кусок кода, который в случае чего можно без проблем заменить. Граблями он станет если перестанет быть куском кода, а будет перемешан с другими алгоритмами и размазан по всей программе.
Однако мой опыт подсказывает, что шансов на то, что нам придётся переделывать потому что, скажем, индустрия перейдёт на какой-нибудь RISC-V — гораздо больше.
В конечном итоге вам же платят не за то, чтобы двигать сущности по кругу из одного класса в другой, а за то, чтобы написать работающий код!
Я вообще скептически отношусь к юниттестам (хотя уважаю функциюнальные, проверяющие что достаточно большой компонент в целом работоспособен) — по моему опыту затраты на их поддержание себя не окупают.
не бывает бизнесов работающих на коде который не развивается.Бывает. У какой-нибудь dmallocа последний commit — был несколько лет назад. Что не мешает миллиардам людей и кучей бизнесов его использовать.
неужели к ICQ с миллиардами прибылей нельзя было их приделать?«Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет). Кстати современный Skype тоже так не умеет.
можно, но в свой код они не могли оперативно вносить изменения и… потому проигралиВы, наверное, из какой-то другой, параллельной, вселенной. Потому что как раз в нашей — ICQ постоянно вносила в свой клиент какие-то идиотские изменения. Боролась со сторонними клиентами. А вот сделать что-то фундаментально новое — нет, не могли. Для этого ведь одних unit-тестов недостаточно.
потому что выдали мобильного клиента. неужели Skype с его миллиардными бюджетами не мог оперативно сделать мобильного клиента?Не мог. Потому что фишка WhatsApp была в том, что он использовал очень простой и лёгкий протокол — а у Skype всё было совсем не так… а платили тогда за каждый байт.
Ну и главное — WhatApp был завязан на телефонные номера, а Skype нужно было что-то делать с пользователями, у которых телефонных номеров не было.
они в свой код не могли оперативно вносить изменения… и потому проиграли.Вот как раз бессмысленные изменения, типа тех, которые позволяет делать постоянный бессмысленный рефакторинг с юнит-тестами, они могли делать — и делали.
А чего они не могли делать — так это вносить изменения, затрагивающие всю инфраструктуру. И не могли они этого сделать, в частности, потому что от этого посыпались бы все их юниттесты, где были «зашиты» все эти ожидания.
я о коде который пишет программист на работеА dmalloc и quicksort кто пишет? Не программист? Эльфы?
И не надо говорить, что malloc написан раз и навсегда: мы свой собственный аллокатор писали как раз месяц назад (почему и зачем — отдельный вопрос… но от malloc'а нам пришлось отказаться).
В том, что у них были договора с разными компаниями, которые не позволяли этого сделать. Вплоть до того, что одно время GMail позволял общаться в чате с пользователями ICQ. И это им казалось более важным, чем обеспечение качественных голосовых звонков.> «Приделать» можно было. Сделать так как в Skype (который мог «через машину соседа» в Internet выходить — нет).
вот в чем причина этого «нет»
только в том что кодовая база пребывала в таком состоянии что «нет»Да не в кодовой базе там было дело.
Я вообще на вас удивляюсь — вы, с одной стороны, рассказываете сказки про потребности бизнеса, а с другой — делаете вид, что модификация кода может быть ограничена только кодовой базой, а не чем-то ещё.
Создаётся ощущение что и программировании и о бизнесе у вас очень поверхностное понятие…
а так 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…
Опять-таки: проблема не в коде, проблема в бизнес-модели.
а тесты — это способ работы с этой вероятностью.Вот только для внесения изменений нужны мозги в первую очередь, а тесты — это уже «рюшечки».
Это, как ни удивительно, почти всегда возможно (если не учитывать того, что иногда, на завершающих этапах получается так, что вы добавляете 100 строк, а удаляете 5000), но требует зачастую ещё больше усилий, чем переписывание всего с нуля… но оно того стоит.
Дело в том, что переписывание с нуля вы не можете остановить и «быстренько закрыть issue» — потому бизнес и ненавидит подобные идеи.
А вот «переписывание с нуля по 100 строк за раз» — остановить можно. Да, это немного снизит темп (и сделает переписывание ещё дороже), но зато ваш заказчик не будет «сосать лапу» пока вы всё переписываете, а вам не придётся сидеть ночами, чтобы успеть всё закончить до тех пор, пока всю вашу деятельность не решат выкинуть нафиг…
Мне не один год потребовался, чтобы научиться «переписывать с нуля, изменяя по 100 строк кода за раз».
То что вы описываете это не переписывание с нуля. Это правильный процесс регулярного рефакторинга и переход на новые рельсы. Это действительно возможно и эффективно и доступно классным спецам.
Но бизнес почему-то больше любит обещателей «мы перепишем все полностью с нуля». Никто из менеджеров почему-то не верит в эффективный и полный рефакторинг за год, но почему-то многие верят в переписывание с нуля за тот же период.
Но бизнес почему-то больше любит обещателей «мы перепишем все полностью с нуля».Бизнес? Нормальный бизнес их ненавидит всеми фибрами души. Ну вот как тут.
Никто из менеджеров почему-то не верит в эффективный и полный рефакторинг за год, но почему-то многие верят в переписывание с нуля за тот же период.Ну дык тут как раз всё логично. Эффективность манагера ведь не то же самое, что эффективность фирмы. Он ведь своими деньгами не рискует. Соответственно подход, который с вероятностью 90% приведёт к краху, но с вероятностью 10% приведёт к гигантским бонусам — для него предпочтительнее, чем подход, который с вероятностью 90% принесёт небольшой доход, а с вероятностью 10% — не сделает ничего.
Если "покрыто тестами" означает не "говнотесты для coverage на отвяжись", а нормальные функциональные тесты, покрывающие требования заказчика, то покрытый ими говнокод таки да — имеет большую maintainability и business value. Его всегда можно будет переписать, если клиент того пожелает. В отличии от гениального кода без тестов.
Писать и тестровать, не думая, займет куда больше времени.Золотые слова. Но судя по реакции собеседника на предложение писать код так, чтобы неправильных код просто не скомпилировался… вы с ним вообще с разных планет, а то и из разных миров.
Который, похоже, не понимает ни как использовать типы для замены unittest'ов (что, на самом деле, всегда возможно, однако не всегда желательно), ни почему люди пытаются добавить типы в скриптовые языки… такая себе проекция карго-культа, которым он овладел «в совершенстве» на весь мир…
что-то мешало внедрить эту одну фичу в проект?
вы уверенны что одну?
бюджеты миллиардные.
В тыньге? бюджеты никогда не резиновые.
Почему? Задача оказалось не по плечу. Все другие объяснения нахожу менее разумными.
Это вы зря. Вы только что привели примеры из строительства и бухгалтерии.
Такая же ситуация и с программными продуктами.
Программный продукт это не только и не столько функционал. Это еще люди, деньги и бизнес. Если у продукта есть конкурент (конкурент — это не техническое, а бизнес понятие), и у конкурирующего продукта есть какие-то фичи, которых нет у нас и нет каких-то фишек, которые у нас есть, то это не значит что мы должны все чужих фишки к себе тянуть и избавляться от всего лишнего что есть у нас. Потому как это надо еще понять кто у кого копирует, какие фишки нужные, а какие мусорные. Насколько совпадает целевая аудитория и прочее и прочее.
Предположим что мы все же выяснили что конкурент растет за счет какой-то фичи. Мы (руководство) можем решить что нам не нужен тот клиент который нужен нашим конкурентам и что мы доминируем в какой-то своей нише. Это обычное бизнес-решение, это никак не связано с «оказалось не по плечу». Просто любой менеджер понимает что нельзя быть лучшим всегда и во всем. (Всех денег не заработать; на двух стульях не усидеть; за двумя зайцами погонишься ни одного не поймаешь)
Даже если руководство видит что какую-то фичу таки надо бы перенять у конкурентов, это совсем не значит что у компании на это будут ресурсы. Текущий бюджет далеко не всегда мега-профитабельный, а выбивание инвестиций требует экономического обоснования и бизнес-плана, а это задача со многими неизвестными.
Так что все же не всегда, если что-то не было сделано, это потому что «оказалось не по плечу.»
Так прямо из ваших предпосылок напрашивается вывод, что разорились из-за неудачных организационных решений. А не потому что не могли "написать фичу". С их деньгами они могли этих фич по две в неделю делать, тупо переписывая все с нуля каждый раз.
Вы так часто и с такой уверенностью поминаете 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.»
Уносить часть тестов в тайпчекер — тоже вполне себе вариант… Плюсы у него есть. Но от этого они не перестают быть тестами, кстати.
Нуу… Мне нужно будет написать две функции с типами
У вас получились тесты, только более мощные. Но главный недостаток тестов никуда не делся — вам всё ещё надо их придумывать.
К примеру, ваших sum_left_0 и sum_right_0 всё ещё недостаточно для полного доказательства, что эта функция и правда выполняет суммирование. Это может быть и побитовое исключающее "ИЛИ".
Вы можете их так назвать, но только тогда получается, что любой механизм проверки и верификации кода — тесты. Как-то дискриминирующая сила понятия теряется.
Любой внешний механизм.
Тут мне надо придумывать заведомо меньше.
А вот не факт. Теста sum 2 3 == 5
достаточно, чтобы исключить ошибки вида "глупая опечатка".
Более умные ошибки исключаются методом внимательного взгляда: в такой простой функции им просто неоткуда взяться.
Любой внешний механизм.
Если есть внешний, то подразумевается и внутренний. Что вы понимаете под внутренним механизмом проверки и верификации кода?
Ну, собственно, типизация в обычном её понимании и есть такой внутренний механизм.
Вот, собственно, в замечания в скобках всё и упирается. Если у вас достаточно «сильная» система типов (C++, в принципе, уже достаточен) — то вы любой unittest, в принципе, можете выразить в типах… но далеко не всегда это имеет смысл. Ну просто потому что если вы добъётесь того, что у вас всё-всё-всё прописано в типах, но однократная компиляция вашей программы занимает два дня… то толку от этого будет немного.
А в интеграционных тестах уже не надо тестировать сохранение и чтение из БД User. Достаточно протестировать интерфейсы системы. Если на них все правильно, то какая разница как там что в БД сохраняется и читается? Может и БД уже нет, все порефакторили на инмемори хранение.
Вы отвечаете на комент начинающийся словами «я не люблю термин 'юнит-тест'»
Так все равно скатываемся до определений. То что тестирование as code это хорошо и правильно все в курсе и никто не спорит. Вопрос только в том что и как тестировать.
отлично прогоняются. при каждом коммите.
вот проект — 600 тыс строк кода. 450 тыс строк тестового кода.
тесты идут 25 минут.
С одной стороны завидую вашему железу (у нас они часы идут) с другой для коммита 25 минут это тоже долго. За 25 минут можно найти ошибку глазами, поправить и потом еще раз найти.
Комит должен быть моментальным. Единицы минут край. Закомитить в ветку любой кусок кода который с виду работает это нормально и правильно.
рабочий воркфлоу такой:
Воркфлоу хороший. Только при долгих тестах его гонять по много раз не выйдет. Долго. Надо большую часть ошибок находить до тестов. Тесты скорее для самопроверки. Мол я все правильно написал.
Закомитить в ветку любой кусок кода который с виду работает это нормально и правильно.На эту тему существуют разные мнения. Разработчки Хрома, скажем, требуют, чтобы все тесты проходили и коммит был отревьюен… что запросто неделю может занять.
P.S. Разумеется в своём личном репозитории вы можете что угодно творить — хоть без тестов заливать, речь идёт про публичный репозиторий…
у меня в MVC парадигме есть сущность такая — User.
эта сущность может быть сохранена в БД, может быть восстановлена из БД, может производиться поиск итемов этой сущности, может производиться показ списка. Могут проводиться иные манипуляции.
все эти манипуляции написаны в сущности User и используют работу с БД внутри себя.
изоляция User от БД в парадигме MVC — это дефакто отказ от парадигмы MVC.
Ну здравствуйте. А откуда такие требования в MVC?
1. Если вдруг мы говорим про Веб, то напомню что MVC был создан для десктопных приложений, и описан Трюгве тут в 1979 году. В вебе испольуется лишь MVA(он же mediating controller MVC).
2. В MVC нет ничего про БД. То что у вас получилось в моделях по сути называется Active Record, и там действительно сложно отделить логику от взаимодействия с БД. Потому, собственно, AR и считается антипаттерном.
какую парадигму взамен MVC Вы предложите?
Писать адекватный код и думать о coupling/cohesion а не на аббревиатурки любоваться.
Про оригинальный MVC уже и вспоминают то не часто, чего к нему цепляться то.
но возьмем реальный мир. Например после сохранения записи в БД требуется отправить уведомления какие-то каким-то сервисам.
Возьмём реальный мир — бизнесу нет дела до хранилища и записей.
Уведомления отправляются не о записи в БД, а о том что совершилось какое-то известное бизнесу действие.
Вобщем, привет доменные ивенты, либо просто дёргать сервис напрямую после коммита транзакции, если проще хочется.
проблему mock'ов знаете главную?
консистентность с реальным миром
Поэтому интеграционные тесты всё-равно нужны, да.
Только вот взаимодействие с реальным миром можно изолировать, чтобы логику системы спокойно покрывать юнитами.
зачем нужен этот исторический экскурс? допустим 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 — советую.
допустим 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). Так вот, поднять все нужные сервисы — это, во-первых, долго, а, во-вторых, стоит денег (а учитывая, что тесты хочется гонять часто, это становится дорого). Плюс немедленно возникает проблема изоляции теств друг от друга — вы же не будете поднимать окружение заново для каждого из тысячи тестов?
докер для этого придумали
Расскажите мне, как поднять в докере Amazon Textract или Amazon Cognito. Особенно когда в Cognito сконфигурены обработчики событий на лямбдах.
(это не считая того, что если на проекте нет докера, то это дополнительная нагрузка на инфраструктуру, и особенно веселой она становится, когда инфраструктура на винде)
И, кстати, в этот момент этот контейнер с S3 и становится моком. Разве нет?
А отсюда, кстати, вытекает следующий занятный факт: мне теперь надо (как минимум) два ряда интеграционных тестов — первый использует контейнеры, а второй использует реальные продакшн-сервисы (с реальным механизмом развертывания). Я не очень понимаю, почему это дешевле, чем просто сделать все те же самые моки в коде (и это будет подниматься и работать в десятки раз быстрее).
PS… а потом мы добавили в этот проект Azure.
над ними очень сложно настроить процесс тестирования.
С чего бы вдруг?
и Вы сможете тестировать.
Я уже сейчас могу это тестировать. И, собственно, тестирую.
лучше от неё дистанцироваться.
… и на что вы предлагаете заменить лямбды в событиях 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 и ту же функциональность (и, вполне возможно, с определенными ограничениями).
консистентность Вашего понимания внешнего мира и внешнего мира!
Для этого надо тестировать внешний мир, как ни странно. В том смысле, что выражать свое понимание этого мира в тестах, а потом эти тесты гонять. Сам код тут никак не участвует.
И да, я писал такие тесты, когда мне надо было быть уверенным что внешний мир именно таков, как мы ожидаем. Но в общем случае это настолько же странно, как и тестировать ошибки "у БД отказал диск".
и кстати именно из за этой второй задачи мы предпочитаем тестировать подымая копию внешнего мира
Дорого это, держать копию внешнего мира.
эпоха docker'а на дворе. давно уже это недорого
Это если весь ваш внешний мир существует в контейнерах. А если нет?
собирать контейнеры самому?
И как вы мне предлагаете самому собрать контейнер, содержащий облачный сервис с закрытым кодом?
Это не говоря о том, что собранный самостоятельно контейнер будет не копией внешнего мира, а приближением к ней, содержащей ошибки нашего понимания того, как надо собирать этот контейнер. Проще говоря, поведение самостоятельно собраного контейнера может отличаться от поведения внешнего мира.
И это не говоря о том, что самостоятельная сборка — это дорого.
невозможность собрать контейнер говорит обычно что не нужно выбирать эту зависимость
Иногда это невозможно. Иногда — неразумно дорого с точки зрения разработки.
Ну и да, с моей точки зрения эта фраза подтверждает, что ваш подход, мягко скажем, не универсален.
самостоятельная сборка контейнера это недорого.
соизмеримо по стоимости с простой инсталляцией
Если нужный сервис доступен для инсталляции (а не надо собирать его руками из исходников).
можно использовать сам сторонний сервис внутри автоматических тестов.
Во-первых, это уже не копия внешнего мира (что и требовалось доказать).
Во-вторых, это не бесплатно.
В-третьих, это усложняет сетап тестов.
заодно и ошибки недоступности того гугла/амазона можно пописать.
Угу, непредсказуемым образом.
какая разница? внешний мир или его копия? никакой.
Фундаментальная. С копией вы можете делать все, что вам заблагорассудится, а внешний мир от вас не зависит.
просто делаете тестовую учётку (или их набор) в этом реальном мире.
См. выше: дорого и усложняет сетап.
Ваши тесты ломаются. вы разбираться с этим начинаете не тогда, когда Вам пользователи сообщили, а сразу как тесты не прошли и Вы получили отчёт.
… а потом выясняется, что у zendesk — канарейки, и вы в них попали, а ваши польователи — нет, а канарейка-то в продакшн и не пошла.
недорого
Вы все сервисы в мире попробовали, что знаете, сколько они стоят? Мы вот как-то на недельном тесте одним разработчиком влетели на полторы штуки баксов. В масштабе продукта это недорого. В масштабе расходов на тестирование — на два порядка больше, чем обычно.
докер. сегодня эпоха докеров.
Напомню, что речь идет о внешнем сервисе, который в докер не завернуть.
как раз предсказуемым
Откуда же предсказуемым, если это внешний сервис, и вы никогда не знаете, как он упадет?
и маловероятно что тесты попадут в канарейку а пользователи нет
Что маловероятного, если там просто выбираются случайные 10%?
я ж говорю — некоторые технологии просто тупо не стоит применять. голосуйте ногами/рублём против них.
Я ж говорю: не всегда есть возможность.
если тестовый прогон на реальном мире стоит полторы штуки баксов,
Не тестовый прогон, а неделя тестовых прогонов.
то во сколько обходится продакшен работа?
А какая разница? За продакшн-работу не мы платим.
тут повод задуматься, может Вы тесты как-то криво сделали?
Для начала, тут повод задуматься, можно ли обойтись без использования внешнего сервиса для тестирования.
внешний сервис может упасть ошибками протокола к нему + ошибками сети к нему.
… вернуть любой ответ, который вы не ожидаете. В любой момент.
включайте тестовые прогоны в стоимость работ, чего проще-то?
Нельзя.
в этом гипотетическом случае с кучей странных допущений
Это не гипотетический, а вполне реальный случай. И не единственный.
или вы на основании того что у Вас был однажды такой случай — готовы раз и навсегда от тестов отказаться?
Почему же. Я на основании того, что у меня был такой (и другие) случаи, готов сильно подумать, не проще ли тестировать на моках внешних сервисов.
я не понимаю пока что Вы хотите доказать/рассказать
… что тестировать на копии внешнего мира — сложнее и дороже, чем вы пытаетесь рассказать.
как только это произойдёт, Ваш тест сломается, в ответ Вы добавите в код реакцию на подобное событие.
И не сможете протестировать, что добавленная реакция правильная, потому что это событие больше никогда во время вашего теста не случится. Зато случится у вашего клиента, и выяснится, что ваш код был написан неправильно, и все равно все сломал.
Это и называется "непредсказуемое поведение внешнего сервиса".
соответственно код, который осуществляет сохранение записи в БД должен всё это учитывать, а соответственно тестировать.
Как протестировать, что код обрабатывает все ошибки, которые могут возникнуть в БД?
(знали бы вы, как меня утомило угадывать, какие именно ошибки вернет boto
)
Это гарантирует только то, что мы обрабатываем те ошибки, для которых мы написали тесты. Но как гарантировать, что мы написали тесты для всех ошибок, которые могут возникнуть в БД?
(И, заметим, для некоторых ошибок написать тесты будет черезвычайно сложно)
в типах нельзя например выразить стейт, хранимый в БДВ настоящей БД — нет. Но можно сделать тип, который будет до вызова функции
perform
будет удовлетворять одному набору условий, а после вызова — другому. Для того, чтобы превратить тесты в типы — этого будет достаточно.Но в результате вы, фактически, породите себе compile-time базу данных, compile-time mock GUI и массу всего в том же роде.
А я сравнивал на простейших алгоритмах — и в clang и в gcc compile-time исполнение программы примерно на три-четыре порядка медленнее, чем у скомпилированной программы.
C++ для этого слабоват, боюсь.Для Mock'ов достаточен. Засовываете данные в
constexpr char[]
, параметризуете этой переменной свой тип — и добавляете туда все свойства, какие вам нужны.Дальше
static_assert
'ами можно любые unit test'ы описать.Практического смысла в этом, впрочем, нет: во-первых у вас весь-весь-весь код должен будет стать параметризуемым, чтобы этот подход можно было применить, во-вторых сообщения об ошибках будут такими, что понять из них — где ошибка это ещё два дня потребуется, на этот раз уже человеческих…
Это как с доказательством Теоремы Бёма — Якопини: да, любой алгоритм может быть, чисто механически, превращён в структурный вид — но это не значит, что его станет легче понять… так и любой unit-test можно «перегнать в типы»… но не факт, что после этого что-то станет кому-то понятнее… скорее наоборот.
То есть если разбить задачу на много-много мелких модулей, описать что каждый из них делает и зафиксировать это в документации — то у вас все тесты станут интеграционными… только возможность что-то рефакторить окажется дико затруднена, так как вам, после этого, нужно будет править и тесты и документацию… и только потом — код.
Я до сих пор не очень понимаю, чем юнит-тесты от интеграционных отличаются (разные люди говорят разное)
Чёткого определения и нет, так ведь не только с юнит тестами.
По сути основное момент в том что за счёт тестирования маленьких изолированных кусков кода мы всегда можем сказать где ошибка если тест упал.
Это тесты которые в первую очередь близки к коду и интересны исключительно разработчикам.
Их используют вместо интеграционных и пр. так как они:
— Быстро выполняются
— Позволяют покрыть все пути выполнения кода(потому что методы с ветвлениями 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, а не распилить всё на микросервисы и т.п., как делают некоторые(или многие, статистики нет).
Более сложные решения — по мере надобности.
Если в нём было легко разобраться и легко вносить нужны изменения — вопрос зачем вы его переписывали.Это был ключевой элемент безопасности системы и, соответственно, любая ошибка в нём была потенциальной дырой в безопасности.
Тогда вопрос лишь в том помогло ли переписывание от этих проблем избавиться.Как показали дальнейшие несколько лет — помогло.
Если обучить нового человека работать с новым инструментом несложно, и поддерживать систему стало проще то всё отлично.Ну… скажем так: что-либо изменить и надеяться что оно будет работать — стало сложнее. Потому как «ручек» для управления стало меньше и любое изменение требовало не написания простенького теста, а изменений в спеке (одной из двух: одной — пришедшей от безопасников, другой — от «железячников»). Но все нобходимые за последующие несколько лет изменения были, в конечном итоге, сделаны.
Вопрос «стало бы поддерживать систему проще» — я бы отнёс к разряду философских: изменения стали даваться куда большей кровью, зато авралы и срочное выкатывание апдейтов при обнаружении очередной дыры — исчезли совсем.
Адепты, такие адепты. Тесты не самоцель, вот и всё.Если тесты не самоцель — тогда почему вокруг них, «покрытия» и прочего столько шума?
Вопрос «стало бы поддерживать систему проще» — я бы отнёс к разряду философских: изменения стали даваться куда большей кровью, зато авралы и срочное выкатывание апдейтов при обнаружении очередной дыры — исчезли совсем.
Предположу, что стабильность релизов и спокойствие важнее скорости )
Адепты, такие адепты. Тесты не самоцель, вот и всё.
Если тесты не самоцель — тогда почему вокруг них, «покрытия» и прочего столько шума?
Так шум он вокруг того что модно.
Я, если что, ни сколько не имею ввиду что тесты не нужны. Просто в среднестатистическом проекте узкое место, ну, не они.
А некачественные тесты не сильно лучше их отсутствия(или вообще хуже).
В целом юнит тесты как средство хороши, и с темой проектирования находятся рядом, просто юнит тесты это следующий этап после определения чего нам вообще нужно.
А у вас не было такого, что ragel пытался построить DFA с экспоненциальным взрывом числа состояний (для NFA известного вида)?Нет. Построенный автомат был большим (тысячи состояний), но не настолько большим, чтобы это стало проблемой.
Там можно как-то попросить его оставить NFA?Вряд ли. Гораздо хуже что у него комбинация машин не работает как комбинация в математическом смысле.
Потому все тесты пришлось перенести на уже полностью построенную машину.
По сути основное момент в том что за счёт тестирования маленьких изолированных кусков кода мы всегда можем сказать где ошибка если тест упал.
Неочевидно. А если ошибка на границе двух маленьких изолированных кусков?
Ну вот один кусок кода ожидает положительное число, а другой кусок кода иногда возвращает отрицательное число. Их писали два разных программиста, и они оба свои маленькие кусочки протестировали хорошо, но иногда, на некоторых данных получается так, что ну вот не состыковываются эти кусочки.
Ну,
если прям запариваться, можно при вызове метода с конкретными аргументами известными при написании кода пойти написать юнит тест с таким значением.
Если значение не известно, понятно что гарантий нет, но если покрыты тестами ветвления и граничные условия шансы словить такой баг не очень велики.
А если вы про возможность доказать типами — мне нравится, да. Я начал ради интереса Хаскель тыкать, но в продакшн то всё равно пишу
Ну так проблема в том, что метод ожидает положительное число (квадратный корень из него считает, например, где-то в процессе), а ему передали отрицательное. На что тут юнит-тест писать?
На клиентский код. Либо требовать модуль с расчетом как зависимость и мокать в тестах, проверяя что он вызывается с корректными данными (я бы скорее всего не стал, кстати, тут получается неоднозначно, есть некоторый порог ожидаемой стабильности вызываемого кода), либо просто надееяться что на одном из тестов покрывающих клиентский код эта ситуация произойдет и тест на него упадёт.
Юнит тесты реально нужны для сложных или неочевидных кусков кода. Понятно что таких лучше избегать, но как-то не всегда получается. Все остальное отлично покрывается интеграционными тестами.
У интеграционных есть один минус. Они сильно повышают требования к разработчикам. «Написать ерунду и если тест упадет перепишем» и так до всех работающих тестов уже не выйдет. Интеграционные тесты часто работают по много часов и место ошибки показывают очень примерно. Искать ими ошибки накладно по времени.
У интеграционных есть один минус. Они сильно повышают требования к разработчикам.А разве это не плюс?
«Написать ерунду и если тест упадет перепишем» и так до всех работающих тестов уже не выйдет.А надо? Сколько раз видел применение этого подхода — кончалось всё всегда одинаково: получается «всё ещё ерунда… но теперь с тестами».
Это, конечно, отличная вещь для «эффективных манагеров», которые могут на этом демонстрировать разнообразные красивые графики с разными KPI… но бизнесу это не нужно.
Если у вас есть конкуренты, к которым реально можно уйти — то с кучи… добра, сыплющего во все стороны сообщениями об ошибках при малейшем отходе пользователя от «магистрально-протестированной линии» люди таки рано или поздно уйдут.
А если конкурентов нет — то можно вот вообще всех этих «эффективных манагеров» с «дешёвыми разработчиками» убрать — и здорово увеличить прибыль.
Юнит тесты реально нужны для сложных или неочевидных кусков кода. Понятно что таких лучше избегать, но как-то не всегда получается.Там где не получается — лучше подумать как разбить задачу на несколько отдельных компонент и описать реальный интерфейс между ними.
Который, соотвественно, уже и протестировать.
А разве это не плюс?
Ну для кого как. Нанимать кого подешевле и прикрываться тестами это вполне рабочая и часто встречающая стратегия.
Нанимать кого получше во первых дорого, а во вторых еще найти надо.
На рынке нет достаточного числа хороших безработных разработчиков.
Там где не получается — лучше подумать как разбить задачу на несколько отдельных компонент и описать реальный интерфейс между ними.
Который, соотвественно, уже и протестировать.
Да да. Но ситуации разные бывают. И сроки горят, и на рефакторинг времени нет и вообще делать некому. Писать сложно и непрозрачно и прикрываться тестами иногда приходится. Главное чтобы это правилом не становилось.
Странный пост, если честно. Без данных навыков нельзя стать хорошим специалистом вообще (врач, ученый, журналист...).
У меня нет этих признаков, и всё равно — я плохой программист.
Бодо Шифер считает, что всему основа — самодисциплина. Без неё не работает ничего.
2 | Вам не хватает самостоятельности и находчивости
7 | Вы не способны думать самостоятельно
Скажите, стоит читать или снова вода на киселе?
Но нельзя же сказать, что один хороший инженер, а другой плохойМожно. Тесла — гениальный изобретатель, но плохой инженер. Эдиссон — менее прозорливый изобретатель, но куда лучший инженер. Что позволяло ему доводить до ума даже не самые лучшие идеи. Посмотрите на результат войны токов: объективно не самый лучший вариант, использованный Эдиссоном, тем не менее, прожил десятилетия и дожил до наших дней.
В то же время Тесла, несмотря на всю гениальность, так и не смог разработать «всемирную систему».
Один был более одержим наукой, другой пытался свою работу, скажем так, монетизировать.Он не был «одержим наукой», к сожалению — иначе от него бы научные труды остались. Он был одержим конкретной задачей, которая, похоже, в те годы не могла быть решена (если она может быть решена в принципе). Тут он очень похож на Эйнштейна, который вложил в попытки объединить теорию гравитации и квантовую механику многие годы… но не добился, в результате, ничего. Но для науки это нормально… а для инженерии — нет. Умение сказать «это, в настоящее время, невозможно» и начать делать что-то,
что, в настоящее время, таки можно сделать — важное умение для инженера…
Умение сказать «это, в настоящее время, невозможно» и начать делать что-то,
что, в настоящее время, таки можно сделать — важное умение для инженера…
Довести до конца… Играясь с гипотезами, можно до конца и не довести. Если он примет, что «это невозможно» — можно говорить об узости мышления. А может он выдвинул гипотезу, довел до конца, а любознательности не проявлял, тогда он тоже плохой?
Изучая что-то новое, очень часто мы чувствуем что наших знаний и опыта недостаточно для того, чтобы иметь собственное мнение. Выступить с инициативой, сделать или сказать что-то неправильно кажется очень рискованным.Может я чего-то не понимаю, но мне всегда казалось, что «изучая что-то новое» — это просто по определению обозначает, что у вас недостаточно знаний для обоснованного мнения.
Вопрос:
Что делать, когда вроде все признаки имеются много лет, а хорошим программистом себя не ощущаешь?
Постойте. Какой именно железнодорожник? Машинист? Проводник? Составитель поездов? Диспетчер? Билетный кассир? Ревизор? Для этих профессий нужны очень разные качества.
Разработка ПО не менее разнообразная отрасль, а всех нас чехом называют программистами. И каждый считает НАСТОЯЩИМ ПРОГРАММИСТОМ именно себя и с этой точки зрения рассуждает о необходимых качествах и навыках.
Однако, как и говорится в 3м пункте: «Суть программирования есть решение проблем». Опять же соглашусь, на мой взгляд, программист-практик обязан держать в голове решаемую проблему бизнеса из реального мира, а не фокусироваться на абстрактном творческом процессе.
Иногда мне плевать, как и что работает, главное — чтобы работало. Иногда я теряю ход времени, копаясь в исходниках.
В некоторые моменты, я искренне считаю, что программирование не для меня. В другие — наоборот.
Не все проблемы я могу решить самостоятельно. И т.д.
Сейчас, в профориентации (и психологии, и философии также) доминируют гуманистические взгляды, суть которых в том, что успех в чем-либо зависит не от предпосылок (исходных характеристик, предрасположенности, задатков, таланта и т.д.), а от мотивации и волевой сферы.
Кратко: если очень хочется, то получится.
Думать так — это конструктивно. Но совершенно не учитывать возможности и ограничения исходных данных — губительно.
Как по мне, есть 2 ограничения:
1. Олигофрения.
2. Слепота и повреждение рук.
Впрочем, некоторые физические ограничения тоже можно обойти, если прям очень сильно хочется. На счет легких и пограничных форм умственной отсталости — писать код можно, как конструктор собирать, но вряд ли получится глубоко вникнуть в сложные абстрактные концепции.
Все остальное — преодолимо.
Злая какая то анкета получилась, на все вопросы — отрицательно…
Теперь 52-летний, программирующий сисадмин…
10 признаков того, что хороший программист из вас не получится