Ну да. До такой ситуации когда половина сотрудников делают больше и получают столько же сколько те, кто делают меньше легко доводится когда зарплаты сотрудников не оглашаются. Бывают и дикие перекосы, бывают массовые итп.
Как из этого положения можно попасть в то, что бы Иван узнал о том сколько получает Василий и наоборот — это другая история, хотя тоже вполне вероятная )
Как из этого перейти к массовому раскрытию зарплат и истерии по этому поводу — тоже легко понять, когда иван и василий начнут громкие разборки по этому поводу и возмущения. (особенно если начальство не решит этой проблемы).
Логика в этом есть? )
ЗЫ: но, опять же, вопрос был в том как довести до ситуации 50/50. я привёл простейший пример)
Я и не спорю, вы говорите повышай эффективность, я отвечаю повышение эффективности не дается даром и всё, нет больше мотивации.
Конечно не даётся даром. Для этого и нужна мотивация — цель к которой стремиться и профиты которые это приносит. Это и заставляет выкладываться и развиваться. Если не можешь или не хочешь — ну тогда делай что делаешь и всё.
А если человека демотивирует что он получает меньше за меньшую работу — то вот это как раз очень странно.
5 человек — не 100. Многие и без NDA вам не скажут, сколько они получают.
и? Не скажут — никто не узнает. Скажут — все узнают.
Изначально обсуждался случай когда зарплаты известны, поэтому из него и исходили. Если зарплаты не известны — то и сути обсуждения не будет, очевидно.
В любом случае, не надо знать зарплаты всех, достаточно знать зарплату того, кто получает больше за меньший труд )
Это субъективная оценка, вот и всё. Она не обязана быть ни объективной, ни обоснованной.
Как, в прочем, и вообще говорить о чём то тем кто её видит. =)
Человеку не понравилось мнение другого человека, поэтому он поставил минус к комментарию, а если очень сильно не понравилось, то и в карму минус. Абсурд же?
Почему же? Если вы приходите в, допустим, неблагополучный район весь блестящий, в модных шмотках и топ гаджетами то естестенно вам буду не очень рады. (или наоборот очень) и вам навешают минусов. Это — отражение их субъективного отношения и то что они её выражают — не абсурдно.
Ну, мы говорим не о том, как не писать говнокод, а о том, что неявные преобразования в виде отсутствия строгой типизации могут приносить проблемы. С большей вероятностью, чем их отсутствие.
Более ярко это выражено в проектах с так себе кодом, менее ярко — где код хороший.
Это то небольшое удобство, которое приносит и небольшие риски. =)
Парное программирование в моём опыте это не совместное решение общей проблемы программистами одного уровня, а метод обучения.
Эффективность спорная, конечно. Ну да — методы каждый выбирает сам ) Как и то — работать ли вообще с новичками которых надо обучать.
Не много, но проблема в том что с той стороны сидят люди из Бангалора и если раз десять им одно и тоже не покажешь, то толку не будет. Хотя и после десяти раз постоянно косячат на ровном месте, где казалось бы уже негде.
Ну, тугим людям, мне кажется, намного эффективнее персонально возвращать задачу с пояснениями, чем смотреть на отсутствие мысли в их глазах на общих собраниях (обычно, на них всё пролетает мимо ушей). Но господам из Бангалора я ничего не обяснял, может есть кейсы в которых это и эффективно. У меня не получалось такого (
Мотивация — это возможность уходить пораньше. А то что я перечислил это демотивирующие факторы.
Ну. Повышай эффективность и будешь уходить пораньше как вася (или получать побольше). Я и говорю — мотивация.
При таком NDA, вообще не приходятся говорить ни о каких 50/50 или 30/70. Каждого обрабатывают по отдельности.
Пока они не пойдут в курилку и не обсудят зарплаты.
Или не пройдёт индексация зарплаты и все дружно оставят свои переподписанные договора на столах.
Итп-итп.
т.е. проверку чёткости работы с типизацией вы хотите решать изменением процесса разработки и найму лишних людей? )
интересный подход.
Но тем не менее, это классический пример скрытой логики, которая может приводить к ошибкам, созданной для удобства. Да, это удобно и да у этого есть некоторые очевидные минусы.
Собственно — это не спор, что лучше, а просто было высказанное мнение ) я знаю за и против.
Ну вот и не надо заменять. Можно просто Иванов отпускать пораньше или платить побольше.
А ситуацию легко довести до такого просто не раскрывая продуктивность каждого сотрудника и их зарплаты друг-другу. Последнее сейчас особенно актуально и при вскрытии информации очень часто бывают драммы из разряда что какой то рядовой разработчик получает больше своего же синьора хотя делает неизвестно что. =)
Если общий стиль уже выработан — вырабатывать его повторно нет большого смысла. А тем более отвлекать всю команду на то, что бы просмотреть изменения по всем задачам.
Ну и да — если у вас изменений за релиз можно разобрать за один час, то это очень немного изменений )
Для каждого конкретного человека, которого ревьюят это так же полезно как нормальный ответ ревьюэра в задаче.
А парное программирование — это вообще очень специфическое занятие никак сюда не относящееся… и вообще сомнительное. =)
Конечно дело в том кто им пользуется. И большинство тех кто им пользуется — пишут так себе код. Поэтому надеяться на читабельность доставшегося куска кода, адекватность того кто это писал, отсутствие других факторов (надо было костыль для конкретного случая нафигачить) как то… наивно.
В таком случае лучше иметь строгий язык, не позволяющий стрелять себе в ногу и скрывать эту боль до момента, когда не будет поздно ) Да и не так уж и много это требует действий на самом деле.
Ну вот Василий и пришёл к руководству с предложением — давайте я буду работать на 2 часа меньше и выполнять план. Или получать чуть больше за перевыполнение плана.
Потому что делая больше получать столько же — это как то странно.
Вот пример. Без разбирательства что в переменных и в каком виде храниться даже зная правила неявных преобразований типов сложно гарантировать что получим на выходе.
Когда это твой код или маленький фрагмент — возможно.
Если это чужой код и большой фрагмент кода то SomeVar1 + SomeVar2 может выдать… всё что угодно.
И неявные правила — это всегда риски багов. =)
Как из этого положения можно попасть в то, что бы Иван узнал о том сколько получает Василий и наоборот — это другая история, хотя тоже вполне вероятная )
Как из этого перейти к массовому раскрытию зарплат и истерии по этому поводу — тоже легко понять, когда иван и василий начнут громкие разборки по этому поводу и возмущения. (особенно если начальство не решит этой проблемы).
Логика в этом есть? )
ЗЫ: но, опять же, вопрос был в том как довести до ситуации 50/50. я привёл простейший пример)
Если человек не адекватен — значит он не адекватен.
Мы же говорим, вроде бы, о разумных людях, нет?
А если человека демотивирует что он получает меньше за меньшую работу — то вот это как раз очень странно.
и? Не скажут — никто не узнает. Скажут — все узнают.
Изначально обсуждался случай когда зарплаты известны, поэтому из него и исходили. Если зарплаты не известны — то и сути обсуждения не будет, очевидно.
В любом случае, не надо знать зарплаты всех, достаточно знать зарплату того, кто получает больше за меньший труд )
Как, в прочем, и вообще говорить о чём то тем кто её видит. =)
Почему же? Если вы приходите в, допустим, неблагополучный район весь блестящий, в модных шмотках и топ гаджетами то естестенно вам буду не очень рады. (или наоборот очень) и вам навешают минусов. Это — отражение их субъективного отношения и то что они её выражают — не абсурдно.
Более ярко это выражено в проектах с так себе кодом, менее ярко — где код хороший.
Это то небольшое удобство, которое приносит и небольшие риски. =)
Ну, тугим людям, мне кажется, намного эффективнее персонально возвращать задачу с пояснениями, чем смотреть на отсутствие мысли в их глазах на общих собраниях (обычно, на них всё пролетает мимо ушей). Но господам из Бангалора я ничего не обяснял, может есть кейсы в которых это и эффективно. У меня не получалось такого (
Пока они не пойдут в курилку и не обсудят зарплаты.
Или не пройдёт индексация зарплаты и все дружно оставят свои переподписанные договора на столах.
Итп-итп.
Человеку понравилась лаконичность с которой был сделан комментарий или ему тоже хотелось его написать.
интересный подход.
Но тем не менее, это классический пример скрытой логики, которая может приводить к ошибкам, созданной для удобства. Да, это удобно и да у этого есть некоторые очевидные минусы.
Собственно — это не спор, что лучше, а просто было высказанное мнение ) я знаю за и против.
Ну вот и не надо заменять. Можно просто Иванов отпускать пораньше или платить побольше.
А ситуацию легко довести до такого просто не раскрывая продуктивность каждого сотрудника и их зарплаты друг-другу. Последнее сейчас особенно актуально и при вскрытии информации очень часто бывают драммы из разряда что какой то рядовой разработчик получает больше своего же синьора хотя делает неизвестно что. =)
Ну и да — если у вас изменений за релиз можно разобрать за один час, то это очень немного изменений )
Для каждого конкретного человека, которого ревьюят это так же полезно как нормальный ответ ревьюэра в задаче.
А парное программирование — это вообще очень специфическое занятие никак сюда не относящееся… и вообще сомнительное. =)
В таком случае лучше иметь строгий язык, не позволяющий стрелять себе в ногу и скрывать эту боль до момента, когда не будет поздно ) Да и не так уж и много это требует действий на самом деле.
Так же это мотивирует и остальных работников повышать эффективность работы )
Потому что делая больше получать столько же — это как то странно.
Вот пример. Без разбирательства что в переменных и в каком виде храниться даже зная правила неявных преобразований типов сложно гарантировать что получим на выходе.
Если это чужой код и большой фрагмент кода то SomeVar1 + SomeVar2 может выдать… всё что угодно.
И неявные правила — это всегда риски багов. =)