Здравствуйте, DarkGray, Вы писали:
DG>можно какие-нибудь примеры, которые показывают — что в похожих ситуациях программист выберет простоту, а менеджер — предсказуемость
У программиста и менеджера редко бывают похожие ситуации, потому что у них разная работа.
Но, к примеру, если есть допустим некая техническая задача. И есть, допустим, сложный способ, которым её уже решали, и он стоит 200 часов.
И есть простой способ, который должен сэкономить половину, но его еще ни разу не применяли, поэтому хрен знает, сработает он вообще или нет.
Программист будет стараться выбрать способ 2, потому что он ведёт к упрощению. Менеджер будет склоняться к способу 1, потому что для него погрешность оценки ниже.
Максимум, на что он согласится — выделить ограниченный бюджет на прототипирование способа 2, и только после этого одобрит его применение (либо откат к способу 1).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
VGn>>Слон состоит из хобота ушей и бегемота (с)
DG>такое описание лучше, чем состояние — умный, но как собака — все понимает, а сказать (сформулировать) ничего не может...
DG>т.е. наивная формулировка лучше, чем отсутствие формулировки вообще, наивная аналогия — лучше чем отсутствие аналогии вообще
Сформулирую доступнее:
что делает из тестера программиста, кроме того, что он тоже сидит жопой на стуле, уставившись в монитор?
Каким аспектом отдел кадров относится к маркетингу? (вроде ещё не дошли до работорговли)
и т.д.
Создаётся впечатление что предыдущий твой пост написан в полном соответствии с шаблоном Golden Hammer.
Или просто изо всех сил хочется сопротивляться, вместо того чтобы признать ошибку.
DG>>можно какие-нибудь примеры, которые показывают — что в похожих ситуациях программист выберет простоту, а менеджер — предсказуемость S>У программиста и менеджера редко бывают похожие ситуации, потому что у них разная работа. S>Но, к примеру, если есть допустим некая техническая задача. И есть, допустим, сложный способ, которым её уже решали, и он стоит 200 часов. S>И есть простой способ, который должен сэкономить половину, но его еще ни разу не применяли, поэтому хрен знает, сработает он вообще или нет. S>Программист будет стараться выбрать способ 2, потому что он ведёт к упрощению. Менеджер будет склоняться к способу 1, потому что для него погрешность оценки ниже. S>Максимум, на что он согласится — выделить ограниченный бюджет на прототипирование способа 2, и только после этого одобрит его применение (либо откат к способу 1).
ок, чуть другой пример: самому менеджеру надо провести переговоры (переговоры происходит в какой-то заднице: жара, кондея нет, гостиница ужасная, т.е. эти 200 часов малокомфортные).
и есть два способа переговоров: один сложный — но который уже делали — и он стоит 200 часов
есть более простой и прогрессивный способ, который по прикидкам должен занять 100 часов, но этот способ еще не применяли.
причем по второму способу еще и кондей обещается.
почему именно первый способ малокомфортный, а второй — комфортнее, да — потому что у программиста такой же выбор — заниматься 200 часов неинтересной некомфортной работой (той которую он уже делал), или выбрать более интересный путь.
то менеджер будет, в массе своей, выбирать первый способ?
мне кажется, что нет — что он как и все люди будет выбирать второй способ.
и пример из первого поста показывает разницу не между менеджером и программистом, а между если делать самому или если делает другой.
если делать самому — то вся эта некомфортность, неинтересность имеет высокое значение, а если для этого привлекать другого — то то, что другому некомфортно — никого не интересует, а важен лишь результат.
VGn>что делает из тестера программиста, кроме того, что он тоже сидит жопой на стуле, уставившись в монитор?
во-первых, я это не говорил.
я говорил, что тестирование — это то, что должен уметь делать любой программист.
во-вторых, тестеры бывают двух видов
первый вид — это биокомпьютер понимающий человеческий язык, а не машинный.
ему задается программа, какие кнопочки нажимать — и он их тупо нажимает.
это вид тестера — я вообще не рассматриваю. компьютер и компьютер чего его рассматривать? надо лишь программу для него правильно составить.
второй вид тестировщика — это хороший диагност, т.е. человек, который во-первых, чувствует как программа работает, знает какие "больные" места бывает, умеет из симптомов составить реальную причину болезни.
замечу, что не все программисты умеют чувствовать программу — даже ту которую они сами написали.
чувствовать программу — понимать как поведет себя программа в той или иной ситуации
и я утверждаю, что хороший программист — должен уметь чувствовать программы, уметь быстро по симптомам сказать что именно не так сделано, в том числе и для чужой программы.
Ps VGn> что делает из тестера программиста
и еще раз повторю, что не тестер является программистом
а программист является тестировщиком(диагностом)
написали программу, запустили — а она работает как-то не так, хороший программист "пошевелив" вот это "как-то не так" может сказать не глядя в код — что именно было сделано не так и где была допущена ошибка.
VGn>Каким аспектом отдел кадров относится к маркетингу? (вроде ещё не дошли до работорговли)
мне кажется ты путаешь маркетинг с продажами.
маркетинг — это не продажи.
маркетинг — это "перевод" с языка покупателей на язык разработчиков + обратный "перевод" с языка разработчиков на язык покупателей.
при "переводе" с языка покупателя — проводится изучение что хотят покупатели, что им нужно и т.д. — и это сжато формулируется для разработчиков.
при обратном "переводе" — изучается что именно сделали разработчики и это объясняется на языке покупателя.
продавец же в магазине — это смесь маркетинга с человекоподобным роботом(компьютером)
в маркетинговой роли — продавец пытается понять что хочет покупатель, а потом предлагает решение, которое лучше для этого подойдет.
в роли человекоподобного робота — продавец подает товар, оформляет покупку, ищет на складе тоже самое, но другого цвета и т.д.
HR (или продвинутый отдел кадров) — делает тоже самое, что и маркетинг + менеджмент.
изучает "заказчика"(свою компанию) и переформулирует это в термины вакансии, дальше ищет людей — пытается понять кто они такие и почему они подойдут компании.
VGn>>что делает из тестера программиста, кроме того, что он тоже сидит жопой на стуле, уставившись в монитор?
DG>во-первых, я это не говорил. DG>я говорил, что тестирование — это то, что должен уметь делать любой программист.
VGn>> что делает из тестера программиста
DG>и еще раз повторю, что не тестер является программистом DG>а программист является тестировщиком(диагностом)
Это означает, что тестирование это не профессия и давайте на должности тестеров нанимать программистов?
DG>маркетинг — это "перевод" с языка покупателей на язык разработчиков + обратный "перевод" с языка разработчиков на язык покупателей.
Это ты путаешь:
то, что ты описал — это аналитика. Маркетинг с процессом разработки напрямую не связан.
Кстати HR и аналитика — тоже довольно странная смесь.
* «Маркетинг — это вид человеческой деятельности, направленный на удовлетворение нужд и потребностей посредством обмена.» (основатель теории маркетинга Филипп Котлер)[2]
* «Маркетинг — это искусство и наука правильно выбирать целевой рынок, привлекать, сохранять и наращивать количество потребителей посредством создания у покупателя уверенности, что он представляет собой наивысшую ценность для компании», а также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности» (Филипп Котлер)[3].
* «Маркетинг — это осуществление бизнес-процессов по направлению потока товаров и услуг от производителя к потребителю.» (Американская ассоциация маркетинга (AMA))[4]
* «Маркетинг — система планирования, ценообразования, продвижения и распространения идей, товаров и услуг для удовлетворения нужд, потребностей и желаний отдельных лиц и организаций; реклама является лишь одним из факторов процесса маркетинга.»[5]
VGn> * «Маркетинг — это ... также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности» (Филипп Котлер)[3].
и фразой
это "перевод" с языка покупателей на язык разработчиков
и между
VGn> * «Маркетинг — система планирования, ценообразования, продвижения и распространения идей, товаров и услуг для удовлетворения нужд, потребностей и желаний отдельных лиц и организаций; реклама является лишь одним из факторов процесса маркетинга.»[5]
и
обратный "перевод" с языка разработчиков на язык покупателей.
VGn>> * «Маркетинг — это ... также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности» (Филипп Котлер)[3].
DG>и фразой DG>
DG>это "перевод" с языка покупателей на язык разработчиков
DG>и между DG>
VGn>> * «Маркетинг — система планирования, ценообразования, продвижения и распространения идей, товаров и услуг для удовлетворения нужд, потребностей и желаний отдельных лиц и организаций; реклама является лишь одним из факторов процесса маркетинга.»[5]
DG>и DG>
DG>обратный "перевод" с языка разработчиков на язык покупателей.
DG>Кстати ты понимаешь что такое "сущность"?
DG>а также что такое: DG>сущность программирования? DG>сущность маркетинга? DG>сущность аналитики?
В данном контексте "естество", ряд основополагающих признаков. А не бегемот
Кстати к чему это?
Не заметил в предыдущих постах слова "сущность".
Уходим от темы?
VGn>В данном контексте "естество", ряд основополагающих признаков. А не бегемот
Сущность — то постоянное, что сохраняется в явлении при различных его вариациях, в том числе и временных.
VGn>Кстати к чему это? VGn>Не заметил в предыдущих постах слова "сущность".
к тому, что в этом треде речь идет (или по крайней мере я пытаюсь говорить) о сути/сущности вещей.
в чем суть/сущность программирования?
почему одни могут писать хороший код, а другие нет? в чем суть такой разницы?
в чем суть/сущность взаимодействия заказчик <-> исполнитель(разработчик)?
если от программирования оставить лишь только суть, и убрать все остальное — то будет ли это жизнеспособным?
и т.д.
VGn>>В данном контексте "естество", ряд основополагающих признаков. А не бегемот
DG>
DG>Сущность — то постоянное, что сохраняется в явлении при различных его вариациях, в том числе и временных.
Ни разу не сталкивался с тем, чтобы программирование называли явлением
DG>а о чем в этом треде пытаешься поговорить ты?
Как и другие твои оппоненты о разделении понятий. А ты петляешь словно заяц, то делая гипер-обобщения, то гипер-детализацию.
Все твои разглагольствования не отменяют наличия в процессах перечисленных мной ролей и связанных с ними активностей, зон ответственности и области действий. Наличие в индустрии соответствующих должностей только подтверждает мои тезисы.
Так что споришь ты не со мной, а с исторически сложившейся объективной реальностью.
VGn>>Наличие в индустрии соответствующих должностей только подтверждает мои тезисы.
DG>а что подтверждала еще лет 30 назад должность машинистки, или должность счетовода?
То, что 30 лет назад были такие роли и активности.
кстати
IT>... IT>Слишком сложно. Не надо усложнять. Усложнять — просто, упрощать — сложно. (c) закон Мейера. IT>... IT> Это очень ограниченное определение и покрывает в какой-то степени лишь количественную и алгоритмическую сложности. IT>...
вот эти две фразы противоречат друг другу.
Так мы все-таки хотим упростить понимание? или мы хотим все учесть?
При принятия решения какой вариант кода выбрать приходится сравнивать два очень разных кода: в одном применены полиморфизм, 2 стандартных паттерна и 3 if-а, а в другом 5 switch-ей, 3 for-а и 4 явных приведения.
Для того, чтобы это хоть как-то сравнить — нужна хоть какая-то количественная оценка, она не должна быть сложной — потому что все равно часто выбирают, как в том анекдоте "...выслушал всех, и выбрал с самой большой грудью".
Поэтому и предлагается простая количественная оценка сложности — кол-во вариантов которые необходимо рассмотреть.
Здравствуйте, DarkGray, Вы писали:
IT>>Слишком сложно. Не надо усложнять. Усложнять — просто, упрощать — сложно. (c) закон Мейера. IT>>... IT>> Это очень ограниченное определение и покрывает в какой-то степени лишь количественную и алгоритмическую сложности.
DG>вот эти две фразы противоречат друг другу.
Противоречить могут друг другу фразы, в которых используются антонимы сложно/просто, ограниченный/широкий. А сложное и ограниченное не противорячат друг другу никак.
DG>Так мы все-таки хотим упростить понимание? или мы хотим все учесть?
Моё определение просто и учитывает всё — сложность — это мера усилий, требуемых для решения поставленной задачи.
DG>Для того, чтобы это хоть как-то сравнить — нужна хоть какая-то количественная оценка, она не должна быть сложной — потому что все равно часто выбирают, как в том анекдоте "...выслушал всех, и выбрал с самой большой грудью".
Совершенно верно. Посчитал количество вариантов использования, и код, который по такой количественной оценке проще, взял и выкинул, потому что он безобразно оформлен и не следует соглашениям.
DG>Поэтому и предлагается простая количественная оценка сложности — кол-во вариантов которые необходимо рассмотреть.
Ты мне так и не ответил на один из вопросов — как сравнить количество ифов, безобразное оформление и минимально необходимый порог вхождения для понимания определённого кода?
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
