У вас содержится неявная предпосылка "если Нотч свалил, то значит Нотч говнокодил специально". Иначе пример Нотча бессмысленнен в контексте разговора.
А то, о чем вы говорите похоже на киберсквоттинг. "Вот видишь сколько посещений у домена, прикупить не хочешь?". Но это передергивание. Реальный косяк примера со стартапом заключается в том, что у вас появилось хоть какое-то обоснование кроме "пох, что будет завтра и не у меня"
Я только сейчас понял, что рассказывать не даёт гарантии.
Босс пытается поступать неэтично по отношению к будущему покупателю. Программист может обоснованно посчитать босса гондоном. Тем более, что при продаже компании сотрудники останутся.
Ну, что ж. Наверное в список проблем стоит добавить "босс — гондон". Честно, я совсем не имею понятия, что советовать гондонам. Я абсолютно некомптентен в вашем вопросе
Мне очень странно читать статьи со спекулятивными выводами
Парадокс Эрроу, за который он получил нобелевскую премию в 1971, говорит, что за пределами выбора большинством голосов из двух кандидатов, не существует метода для точного определения выбора большинства
Этот отрывок ссылается на википедию. Заходим в вики и видим:
В рамках кардиналистского подхода, предполагающего количественную измеримость предпочтений, теорема Эрроу в общем случае не работает
Внезапно, да? Теорема применима, только если мы четко решили, что можно голосовать только одним конкретным определенным образом. Другими словами: теорема Эрроу утверждает, что некоторые системы голосования — хрень, и их применять не стоит.
Но давайте посмотрим, что именно утверждает теорема Эрроу.
Смысл этой теоремы состоит в том, что в рамках ординалистского подхода не существует метода объединения индивидуальных предпочтений для трёх и более альтернатив, который удовлетворял бы некоторым вполне справедливым условиям и всегда давал бы логически непротиворечивый результат.
Буквально это значит: в рамках определенного подхода существует ряд ситуаций, когда получается ерунда. Ничего о том, насколько часто это происходит.
Что вообще значат все эти парадоксы выборов: иногда волю избирателей нельзя определить математическими методами. Искать решение в таких ситуациях стоит вне математики.
Дальше, странная вещь. Я не нашёл примера парадокса, при котором побеждает откровенно трешовый кандидат. Возможно, что система выбора просто отображает тот факт, что в ряде случаев кандидаты идут в притирку. И манипуляциями можно вывести любого кандидата в победители.
А вот чего стоит знать о парадоксах. На самом деле реальность страшнее. Математические теоремы парадоксов выбора основываются на том, что отдельный выборщик может четко выбрать между двумя альтернативами. Но это не так. Люди постоянно сомневаются. Люди чего-то не знают. А это усиливает парадоксы. Вероятно, инженеры понимают, что в ситуациях минимального перевеса люди изменят свое мнение после понимания реальных дел.
Так стоит ли так волноваться о парадоксах? Или может лучше думать о том, как дать людям возможность сделать выбор, о котором они не пожалеют?
Эта проблема называется "недостаток коммуникации" и "микроменджмент".
Вместо того, чтобы объяснить суть поставленных задач босс пытается выполнять работу программиста.
Естественно, что:
1) босс будет принимать технические решения хуже, чем программист
2) програмист будет считать босса некомпетным самоуверенным дебилом, потому что не знает обстоятельств
3) даже если программист будет выполнять требования, то это будут не те требования, которые изначально нужны
В 2018 году писать заумнообразные простыни, надеясь что их никто не прочтет? Серьезно?
Проблема вашей позиции в том, что старые знания бывают двух видов: чушь и знания интегрированные в современную науку. Нет нужды привлекать древнегреческих балаболов
Сборщики мусора и автоматическое управление памятью действительно таки усложняют жизнь в ряде случаев. Просто в области применения C# таких случаев действительно очень мало
Пункт 3 не объясняет, как мы приходим к выбору «или Линус ругается как чёрт, или линукс не является нужным». Можно ревьюить код незнакомых людей, не ругаясь при этом как чёрт.
Нет, ваше «можно» можно рассыпать дополнительными условиями, чтобы тактика «материться как строитель» была самой рациональной.
Я попытаюсь проиллюстрировать примерами:
1) Если вы ревьювите одного-трех человек, то вы можете подстраиваться под каждого и даже лизать им. Если вы ревьювите код сотни человек, то у вас тупо не хватит времени в сутках подстраиваться под каждого. Даже в чистом ревью есть пределы того, насколько вы можете быть хорошим и замечательным.
2) Но обычно ревью это не единственная обязанность. Нужно еще продумывать дальнейшее развитие продукта, программировать. Еще говорят, что есть личная жизнь и тому подобное. Это тоже снижает количество кода и людей, которые можно ревьювить корректно.
3) Представьте, что вам приходится ревьювить людей, которые случайно попали в профессию, не понимают банальных вещей и работают спустя рукава. Какие эмоции у вас это будет вызывать? Как долго вы продержитесь, если не будете выпускать пар?
Теперь вернемся к Линусу и линуксу. Очень похоже, что:
1) Линус занимается линуксом не для того, чтобы обучать программистов;
2) В линукс пытается зайти дохрена кода;
3) У Линуса есть строгие требования качества к продукту, которые он ставит выше чувств говнопрограммистов. Был бы популярен линукс, если бы он был бы гавном?
4) Трудно предсказать, каким был бы линукс если бы не вклад других хороших программистов. Очень возможно, что продукт был бы недоразвитым. И кому он был бы нужен?
Линусу нужно привлекать хороших программистов (код которых не вызывает эмоции «блять, ты что дебил?») и отсекать плохих программистов. Его подход вполне работает.
Заметьте, я не говорю, что такой подход работает всегда и должен использоваться как пример для подражания в любой команде. Линукс определенно уникальный продукт и большинство компаний не имеет схожих условий разработки.
Простите, но ваше «сменить работу несложно» — это огромное заблуждение.
1) Начнем с того, сколько технических скиллов может понадобиться человеку. Возьмем какого-нибудь программиста js/php с зп 500-800$ и попытаемся его устроить в компанию занимающейся разработкой на Java/whatever. Это потребует от полугода до года обучения. А еще долгих муторных попыток трудоустройства.
2) Дальше полутехнические скиллы. Есть компании, в которых не налажена даже система контроля версий. Есть компании, в которых есть code review, continious integration, tdd и т.д. Разрыв между культурой разработки может быть адски большой. И это все тоже требует обучения.
3) Я уже не говорю о софт-скиллах. Хотя бы о банальном разговорном английском.
4) Может случиться такая ситуация, что для того, чтобы перейти из ядовитой компании в хорошую нужно затратить очень дофига времени. Просто потому что они работают по другому и имеют более высокие требования к кадрам.
5) У вас (возможно) есть неявное предположение, что разработчик понимает, что есть нетоксичные компании. После пары смен токсичных компаний попытка рассказать о хороших компаниях будет восприниматься человеком как сказки о единорогах
6) У вас (возможно) есть неявное предположение, что невозможность смены работы не может происходить из сложной финансовой ситуации или какой-нибудь такой объективной хуни.
7) У вас (возможно) есть неявное предположение, что невозможность дообучения не может происходить из проблемы с физическим здоровьем (физическая усталость), с психическим здоровьем (апатия, депрессия, стрессы, выгорание), с недостатком времени (человеку нужно ухаживать за ребенком).
Вы удивитесь как много людей не имеют возможности "не принять" и не имеют возможности "перейти в команду, где такого быть не может" (потому что таких команд мало).
К слову. Если развивать вашу позицию, то мы придем к выбору: или Линус ругается как черт, или линукс не является нужным.
Для того, чтобы разрушить команду CircleCi достаточно запустить в команду двоих: начальника склонного к кумовству или жополизству; и одного дауна с подвешенным языком или родственными связями. Т.е просто дауна, которого уволить нельзя.
Интеграционными он называет компонентные тесты, что является довольно распространённой ошибкой. Интеграционный тест проверяет взаимодействие модулей
В защиту автора хочу сказать, что есть разница между академическим определением и тем как термины понимают в жизни. То, что описывает автор ближе к людям. Хотя такие ремарки конечно стоит делать.
Ну а пресловутая «бизнес-логика» — это вообще не понятно что. Что это за мифическое приложение такое без «бизнесс-логики»?
Есть довольно широкий класс малопродуманных полуполезных говноприложений.
Систему можно разбивать более чем одним способом. А еще разный способ подходит под разные задачи.
Но. Когда систему бьют, чтобы бить; когда абстракции выделяют бездумно и в огромном количестве; когда количество смысла на строку текста приближается к нулю. Вот тогда мы получаем ООП головного мозга.
У разных языков и их фанатов разные интерпретации понимания термина ООП. Реализации реально очень разные. И как правило программисты в рамках одного языка пересекаются чаще, чем в рамках разных. И это формирует общий стиль мышления и кодирования.
ACID может обеспечиваться и без СУБД, но нужно обеспечивать. В ACID системах есть механизмы восстановления после креша. Git этим не заморачивается вообще. Буквально — если убить процесс СУБД, то после перезапуска она будет работать, а не прикидываться ветошью. Если убить процесс git, то следующая операция может тупо не пройти, потому что он не может восстановиться от промежуточного состояния. Никаких повреждений данных не нужно — нужно только прервать процесс в нужный момент.
У вас содержится неявная предпосылка "если Нотч свалил, то значит Нотч говнокодил специально". Иначе пример Нотча бессмысленнен в контексте разговора.
А то, о чем вы говорите похоже на киберсквоттинг. "Вот видишь сколько посещений у домена, прикупить не хочешь?". Но это передергивание. Реальный косяк примера со стартапом заключается в том, что у вас появилось хоть какое-то обоснование кроме "пох, что будет завтра и не у меня"
Я только сейчас понял, что рассказывать не даёт гарантии.
Босс пытается поступать неэтично по отношению к будущему покупателю. Программист может обоснованно посчитать босса гондоном. Тем более, что при продаже компании сотрудники останутся.
Ну, что ж. Наверное в список проблем стоит добавить "босс — гондон". Честно, я совсем не имею понятия, что советовать гондонам. Я абсолютно некомптентен в вашем вопросе
Мне очень странно читать статьи со спекулятивными выводами
Этот отрывок ссылается на википедию. Заходим в вики и видим:
Внезапно, да? Теорема применима, только если мы четко решили, что можно голосовать только одним конкретным определенным образом. Другими словами: теорема Эрроу утверждает, что некоторые системы голосования — хрень, и их применять не стоит.
Но давайте посмотрим, что именно утверждает теорема Эрроу.
Буквально это значит: в рамках определенного подхода существует ряд ситуаций, когда получается ерунда. Ничего о том, насколько часто это происходит.
Что вообще значат все эти парадоксы выборов: иногда волю избирателей нельзя определить математическими методами. Искать решение в таких ситуациях стоит вне математики.
Дальше, странная вещь. Я не нашёл примера парадокса, при котором побеждает откровенно трешовый кандидат. Возможно, что система выбора просто отображает тот факт, что в ряде случаев кандидаты идут в притирку. И манипуляциями можно вывести любого кандидата в победители.
А вот чего стоит знать о парадоксах. На самом деле реальность страшнее. Математические теоремы парадоксов выбора основываются на том, что отдельный выборщик может четко выбрать между двумя альтернативами. Но это не так. Люди постоянно сомневаются. Люди чего-то не знают. А это усиливает парадоксы. Вероятно, инженеры понимают, что в ситуациях минимального перевеса люди изменят свое мнение после понимания реальных дел.
Так стоит ли так волноваться о парадоксах? Или может лучше думать о том, как дать людям возможность сделать выбор, о котором они не пожалеют?
Эта проблема называется "недостаток коммуникации" и "микроменджмент".
Вместо того, чтобы объяснить суть поставленных задач босс пытается выполнять работу программиста.
Естественно, что:
1) босс будет принимать технические решения хуже, чем программист
2) програмист будет считать босса некомпетным самоуверенным дебилом, потому что не знает обстоятельств
3) даже если программист будет выполнять требования, то это будут не те требования, которые изначально нужны
В 2018 году писать заумнообразные простыни, надеясь что их никто не прочтет? Серьезно?
Проблема вашей позиции в том, что старые знания бывают двух видов: чушь и знания интегрированные в современную науку. Нет нужды привлекать древнегреческих балаболов
В дополнение к статье. В отличии от конструкции using тип shared_ptr меньше подвержен проблемам протечки абстракции.
Если у вас есть достаточно сложный код, то весьма вероятно, что Dispose вызовется позже, чем мог бы быть вызван при оптимальном использовании.
А shared_ptr убивает объект моментально при отсутствии ссылок.
Сборщики мусора и автоматическое управление памятью действительно таки усложняют жизнь в ряде случаев. Просто в области применения C# таких случаев действительно очень мало
Нет, ваше «можно» можно рассыпать дополнительными условиями, чтобы тактика «материться как строитель» была самой рациональной.
Я попытаюсь проиллюстрировать примерами:
1) Если вы ревьювите одного-трех человек, то вы можете подстраиваться под каждого и даже лизать им. Если вы ревьювите код сотни человек, то у вас тупо не хватит времени в сутках подстраиваться под каждого. Даже в чистом ревью есть пределы того, насколько вы можете быть хорошим и замечательным.
2) Но обычно ревью это не единственная обязанность. Нужно еще продумывать дальнейшее развитие продукта, программировать. Еще говорят, что есть личная жизнь и тому подобное. Это тоже снижает количество кода и людей, которые можно ревьювить корректно.
3) Представьте, что вам приходится ревьювить людей, которые случайно попали в профессию, не понимают банальных вещей и работают спустя рукава. Какие эмоции у вас это будет вызывать? Как долго вы продержитесь, если не будете выпускать пар?
Теперь вернемся к Линусу и линуксу. Очень похоже, что:
1) Линус занимается линуксом не для того, чтобы обучать программистов;
2) В линукс пытается зайти дохрена кода;
3) У Линуса есть строгие требования качества к продукту, которые он ставит выше чувств говнопрограммистов. Был бы популярен линукс, если бы он был бы гавном?
4) Трудно предсказать, каким был бы линукс если бы не вклад других хороших программистов. Очень возможно, что продукт был бы недоразвитым. И кому он был бы нужен?
Линусу нужно привлекать хороших программистов (код которых не вызывает эмоции «блять, ты что дебил?») и отсекать плохих программистов. Его подход вполне работает.
Заметьте, я не говорю, что такой подход работает всегда и должен использоваться как пример для подражания в любой команде. Линукс определенно уникальный продукт и большинство компаний не имеет схожих условий разработки.
1) Начнем с того, сколько технических скиллов может понадобиться человеку. Возьмем какого-нибудь программиста js/php с зп 500-800$ и попытаемся его устроить в компанию занимающейся разработкой на Java/whatever. Это потребует от полугода до года обучения. А еще долгих муторных попыток трудоустройства.
2) Дальше полутехнические скиллы. Есть компании, в которых не налажена даже система контроля версий. Есть компании, в которых есть code review, continious integration, tdd и т.д. Разрыв между культурой разработки может быть адски большой. И это все тоже требует обучения.
3) Я уже не говорю о софт-скиллах. Хотя бы о банальном разговорном английском.
4) Может случиться такая ситуация, что для того, чтобы перейти из ядовитой компании в хорошую нужно затратить очень дофига времени. Просто потому что они работают по другому и имеют более высокие требования к кадрам.
5) У вас (возможно) есть неявное предположение, что разработчик понимает, что есть нетоксичные компании. После пары смен токсичных компаний попытка рассказать о хороших компаниях будет восприниматься человеком как сказки о единорогах
6) У вас (возможно) есть неявное предположение, что невозможность смены работы не может происходить из сложной финансовой ситуации или какой-нибудь такой объективной хуни.
7) У вас (возможно) есть неявное предположение, что невозможность дообучения не может происходить из проблемы с физическим здоровьем (физическая усталость), с психическим здоровьем (апатия, депрессия, стрессы, выгорание), с недостатком времени (человеку нужно ухаживать за ребенком).
Послушайте, вы нанимаете дебила и требуете, чтобы с ним обращались лучше, чем с белым человеком.
То, что вы описали — не доброжелательность, а социальные игры.
1) Мир разработки шире, чем вы думаете. Не всякий программист крут и высокоплачиваем.
2) Человеку вне разработки трудно понять кто прав.
3) Линусу приходится смотреть на код абсолютно левых ему людей. Один из залогов популярности линукса — open source
Вы удивитесь как много людей не имеют возможности "не принять" и не имеют возможности "перейти в команду, где такого быть не может" (потому что таких команд мало).
К слову. Если развивать вашу позицию, то мы придем к выбору: или Линус ругается как черт, или линукс не является нужным.
Для того, чтобы разрушить команду CircleCi достаточно запустить в команду двоих: начальника склонного к кумовству или жополизству; и одного дауна с подвешенным языком или родственными связями. Т.е просто дауна, которого уволить нельзя.
Есть довольно широкий класс малопродуманных полуполезных говноприложений.
Систему можно разбивать более чем одним способом. А еще разный способ подходит под разные задачи.
Но. Когда систему бьют, чтобы бить; когда абстракции выделяют бездумно и в огромном количестве; когда количество смысла на строку текста приближается к нулю. Вот тогда мы получаем ООП головного мозга.