По-моему, вы как-то перевернули всё с ног на голову.
Вот вы попали в компанию, которая свято верит во что-то, а вы знаете, что это неправильно. При этом вы также знаете, что если начнете рассказывать им про ошибку, то огребете. Будет у вас стимул высказывать различные мнения и вписываться в дискуссии в такой ситуации?
Про показатели смотрите предпоследнее предложение поста:
И нет, это всё не про карму. Это всё про отношение. Не очень приятно пребывать в сообществе, которое вместо открытых дискуссий предпочитает по-тихому насрать и смыться.
Вот пришел новый человек. С трудом получил немного кармы и написал пост — интересный, но спорный. Потратил несколько часов. Его вогнали в жесткий минус. Всё. Писать он больше не может, да и наверно не очень хочет. Что в этом хорошего?
Про ПХП это типичный мусорный коммент. Его, конечно, можно минусовать, если это не шутка привязанная к чему-то. Но есть и хорошие комменты/посты и минусовать их (и тем более человека) только потому что не согласен, имхо, неправильно.
Собственно и о карме речь тоже шла. Раздражает, если хорошие комментарии минусуют, но это ничто по сравнению с тем, что люди, которые могут писать что-то интересное (но необычное) не могут этого сделать или уже просто не хотят.
Это, кстати, очень хорошее нововведение, имхо. Я так для себя превратил даже во что-то типа игры «а совпадет ли мое мнение с мэйнстримовым». Плюсуешь пост, а там какой-нибудь жесткий минус — ой, не совпало.
Думаю, что для организаций с конвейерным подходом этот подход как раз очень хорош — можно автоматизировать всё по максимуму и один человек сможет приглядывать за большим количеством проектов.
Этот подход не подходит скорее совсем маленьким компаниям и отделам, где такого человека после создания методологии и самих тестов будет не выгодно держать. Ну тут уж как раз придется сочетать роли.
Не минусовать. Где гарантия, что я прав? Если я даже сильно уверен в том, что я прав (такое бывает, да :)), то все свидетели дискуссии аргументам вняли, выводы сделали, а человек может изменит мнение в будущем или я сам изменю.
Да, можно конечно разбежаться по сообществам, но как раз в таком случае обмена знаниями-то и не происходит.
Вот бывает я предлагаю какую-то штуку, а заказчик начинает свой взгляд на эти вещи излагать. Зачастую вначале они мне кажутся глупыми, потому что я такой вариант уже рассматривал, но начинаешь вникать в то, что он говорит и понимаешь, что некую мелочь упустил, которая радикально меняет все. Как результат — объединяешь две идеи и получается классная штука.
Тут тоже самое. Сила сообществ с людьми разной специализации именно в этом.
Нужно научиться сдерживать вот эти первые позывы поставить минус и пытаться извлечь из чужого мнения пользу.
Так ты изменишь меру и сохранишь возможность писать посты людям мыслящим за пределами мэйнстрима, но саму гнетущую атмосферу только усугубишь. Вместо минусов будут писать всякие гадости в комментах. Ну и плохого контента тоже станет больше, потому что народ будет жалеть 100 рублей, чтобы всякую фигню фильтровать.
А может наоборот, только социальное? Ограничения могут помочь частично, но то что у людей в головах ведь не изменится от этого.
С другой стороны, сообщества с определенным взглядами известны. Другое дело, что они, как правило, ограничены от свободного притока людей, но и Хабр тоже сейчас ограничен.
Да, хотел упомянуть в посте и про то что очень часто то что люди сначала не понимают потом становится великим, но решил, что и так слишком много букв получается.
А на счет системы… Не знаю, это всё-таки всё в головах, не факт что система изменит само отношение.
Если я достучусь хотя бы до двух из сотни это уже будет успехом. Они в свою очередь достучатся еще до двух из сотни и так далее. Не считаю, что это бесполезно. В итоге даже если появится возможность высказываться хоть чуть-чуть свободнее, это уже будет успехом.
Сейчас если зайти в топик по MySQL и рассказать, как такая же фича реализована в Postgree и какое преимущество у такого подхода — сразу заминусуют. Я считаю, что это неприемлемо.
Я считаю, что тестировщики, (как, кстати, и верстальщики) недооценены в современных подходах к разработке. Может быть потому что само понимание хорошего тестировщика у меня отличается от общепринятого.
Как правило под тестировщиком понимают этакого человека, который сидит и миллион раз проверяет одно и то же на каждом билде. Я же считаю, что такую работу нужно в принципе исключать при современном развитии технологий, а вместо них создавать неких гуру тестирования.
Требования у меня к нему такие:
Он должен быть перфекционистом.
Его перфекционизм должен быть направлен не только на поиск косяков в софте, но и на автоматизацию самого тестирования. Он должен неустанно стремиться автоматизировать всё.
И он действительно способен автоматизировать практически всё.
Он не должен бояться рутины — какая-то часть ручной проверки всё равно останется.
Он должен испытывать страсть к своему делу. Почти кончать при нахождении очередного существенного труднообнаружимого косяка.
Он должен иметь значительный опыт программирования. Чтобы понимать что вообще можно сломать и как. Например проверить софт на проблемы при параллельном выполнении без понимания этих механизмов невозможно. К тому же эти навыки помогут ему общаться с разработчиками.
Он должен быть еще и немного дизайнером. Тестирование в современном мире это не просто стремление вызвать некий эксепшен, а еще и проверка того, как все это выглядит и работает. Человек должен понимать, когда что-то съехало, когда что-то пошло не так на логическом уровне и т. д.
Думаю, что такой человек может родиться например из программиста, выбравшего тестирование своей специализацией. Так что он по определению не может стоить дешевле тестировщиков, зато его производительность тестирования может быть ошеломляющей.
Я также убежден, что такой человек должен быть ответственен за тестирование в целом — от юнит-тестов до функциональных. Юнит-тесты он, конечно, сам не пишет, но учит разработчиков делать это правильно и следит за этим. Зачем? Чтобы ни один фрагмент не оказался упущенным обоими сторонами.
А идею нанять обученных обезьянок я не одобряю. Имхо, не эффективно и не естественно.
Кстати, я думал насчет работы именно с атакой, послезвучиями, касаниями и т. д.
Если бы у меня стояла задача сделать алгоритм репитча, который звучит натурально, то я бы как раз уделил основное внимание именно этим вещам, ведь именно их модификация и приводит к ненатуральности. Sustain и Decay-стадии более-менее равномерны и их растяжение/сжатие не столь заметно.
Как минимум, я бы, пожалуй, попытался растягивать attack и release в меньшей степени и разделить их на шумовую и тоническую составляющую, чтобы шумовую не питчить. Думаю в какой-то мере это все реально и возможно этим путем и идут разработчики (или уже ушли далеко вперед).
Вот вы попали в компанию, которая свято верит во что-то, а вы знаете, что это неправильно. При этом вы также знаете, что если начнете рассказывать им про ошибку, то огребете. Будет у вас стимул высказывать различные мнения и вписываться в дискуссии в такой ситуации?
Про показатели смотрите предпоследнее предложение поста:
И нет, это всё не про карму. Это всё про отношение. Не очень приятно пребывать в сообществе, которое вместо открытых дискуссий предпочитает по-тихому насрать и смыться.
Этот подход не подходит скорее совсем маленьким компаниям и отделам, где такого человека после создания методологии и самих тестов будет не выгодно держать. Ну тут уж как раз придется сочетать роли.
Вот бывает я предлагаю какую-то штуку, а заказчик начинает свой взгляд на эти вещи излагать. Зачастую вначале они мне кажутся глупыми, потому что я такой вариант уже рассматривал, но начинаешь вникать в то, что он говорит и понимаешь, что некую мелочь упустил, которая радикально меняет все. Как результат — объединяешь две идеи и получается классная штука.
Тут тоже самое. Сила сообществ с людьми разной специализации именно в этом.
Нужно научиться сдерживать вот эти первые позывы поставить минус и пытаться извлечь из чужого мнения пользу.
С другой стороны, сообщества с определенным взглядами известны. Другое дело, что они, как правило, ограничены от свободного притока людей, но и Хабр тоже сейчас ограничен.
А на счет системы… Не знаю, это всё-таки всё в головах, не факт что система изменит само отношение.
Сейчас если зайти в топик по MySQL и рассказать, как такая же фича реализована в Postgree и какое преимущество у такого подхода — сразу заминусуют. Я считаю, что это неприемлемо.
Как правило под тестировщиком понимают этакого человека, который сидит и миллион раз проверяет одно и то же на каждом билде. Я же считаю, что такую работу нужно в принципе исключать при современном развитии технологий, а вместо них создавать неких гуру тестирования.
Требования у меня к нему такие:
Он должен быть перфекционистом.
Его перфекционизм должен быть направлен не только на поиск косяков в софте, но и на автоматизацию самого тестирования. Он должен неустанно стремиться автоматизировать всё.
И он действительно способен автоматизировать практически всё.
Он не должен бояться рутины — какая-то часть ручной проверки всё равно останется.
Он должен испытывать страсть к своему делу. Почти кончать при нахождении очередного существенного труднообнаружимого косяка.
Он должен иметь значительный опыт программирования. Чтобы понимать что вообще можно сломать и как. Например проверить софт на проблемы при параллельном выполнении без понимания этих механизмов невозможно. К тому же эти навыки помогут ему общаться с разработчиками.
Он должен быть еще и немного дизайнером. Тестирование в современном мире это не просто стремление вызвать некий эксепшен, а еще и проверка того, как все это выглядит и работает. Человек должен понимать, когда что-то съехало, когда что-то пошло не так на логическом уровне и т. д.
Думаю, что такой человек может родиться например из программиста, выбравшего тестирование своей специализацией. Так что он по определению не может стоить дешевле тестировщиков, зато его производительность тестирования может быть ошеломляющей.
Я также убежден, что такой человек должен быть ответственен за тестирование в целом — от юнит-тестов до функциональных. Юнит-тесты он, конечно, сам не пишет, но учит разработчиков делать это правильно и следит за этим. Зачем? Чтобы ни один фрагмент не оказался упущенным обоими сторонами.
А идею нанять обученных обезьянок я не одобряю. Имхо, не эффективно и не естественно.
Если бы у меня стояла задача сделать алгоритм репитча, который звучит натурально, то я бы как раз уделил основное внимание именно этим вещам, ведь именно их модификация и приводит к ненатуральности. Sustain и Decay-стадии более-менее равномерны и их растяжение/сжатие не столь заметно.
Как минимум, я бы, пожалуй, попытался растягивать attack и release в меньшей степени и разделить их на шумовую и тоническую составляющую, чтобы шумовую не питчить. Думаю в какой-то мере это все реально и возможно этим путем и идут разработчики (или уже ушли далеко вперед).