У вас почему-то только два варианта — либо человек идеален и не косячит (или косячит по незначительным мелочам), либо человек сразу списывается в утиль и ему как кирпич на голову сваливается угроза об увольнении.
Ну не надо мне приписывает чужие идеи. Я даже прямым текстом писал, что некосячащих людей не бывает.
Я похоже сильно сложно пошел выражать свою мысль. В результате чего получился какой-то спор ниочем и полный оффтоп.
Суть моих мыслей такова: Метод наказания работает только в случае если наказующий имеет значительную власть над наказуемым. В отношениях работодатель-работник такое возможно разве что в ситуации, когда работник финаносово зависим от работодателя (например на работнике висят кредиты/ипотеки, и выплатить их он способен работая только на текущем месте рабты). Если же вы попытаетесь наказать работника, над которым ваша власть незначительна, то он вас пошлет и просто свалит в другую контору (и будет прав).
Задумайтесь, почему вы решили, что имеете право наказывать взрослого, постороннего вам человека? И что вас на самом деле интересует — наказть сотрудника или как-то его изменить?
Обратимся к реальной жизни — если человек украл пачку сигарет, это не значит, что его нужно сразу сажать в тюрьму на 10 лет, но и не значит, что нужно говорить «бери на здоровье» и отпускать просто так.
Вот кстати действительно отличный пример. В реальной жизни тюрьмы могут выступать в двух качествах. Как исправительное учереждение и как наказательное (более удачного слова придумать не смог). Практика показывает, что если тюрьма — это наказание, то из неё выходят преступники (что логично, приходят туда преступники и предпосылок для исправления нет). Поэтому в таком качестве она работает только в случае пожизненных сроков, когда преступник уже не вовращается в социум. В нашей аналогии пожизненный срок — это и есть увольнение.
Другими словами если человек не исправляется, то его наказывают — увольняют. Любые другие наказания порождают появление сотрудника, который в лучшем случае просто от вас уйдет, в худщем будет действовать по принципу «косячить можно, а вот попадаться — нет».
Да, есть хорошие программисты, но с отвратительным характером\привычками, которые иногда надо немного корректировать дисциплинарно
Вот представьте, что он не ваш сотрудник, а, например, сосед. Вы бы стали наказывать соседа за его характер/привычки?
Более бесполезного способа, чем грозить увольнением сложно даже придумать в применении к хорошим программистам.
Зачем наказывать хорошего программиста?
Тут простая логика — если сотрудник иногда косячит по мелочи, то какой вообще смысл его наказывать? Косячат все, без исключений.
Увольнение это крайняя мера, и очень глупо грозить им при каждом случае. Точно так же, как с пистолетом — лучше не вытаскивать, если не решился стрелять.
Я и не говорил обратного :)
Если вы грозите сотруднику увольнением, значит вы готовы его уволить и никак иначе. Сотрудник, который хочет работать у вас в компании не будет доводить до такой ситуации.
Если сотрудник не устраивает работодателя, то его увольняют. Или предлагают измениться. И в этом нет ничего плохого.
Да, такая логика не работает со звездными сотрудниками, но прекрасно работает с рядовыми, просто потому что они заменяемые. И большинство разработчиков и позиций как раз рядовые. Просто зачастую компания хочет и платить человеку по минималке и чтобы к ним очередь нормальных разработчиков стояла. Но так не бывает.
То-то я замечаю как толпами бегут разработчики из мест где хорошо платят. :)
Насчет бюджета — ну в том же США зарплаты побольше наших, но разработчики есть. ЗП разработчиков — это обычно далеко не первый пункт в топе расходов проекта.
Если сотруднику хорошо платят, нормально относятся, не парят мозг ненужными ему корпоративными игрищами, дают нормальные задачи и т.д., то он будет держаться за такое место работы. Как результат будет стремится хорошо работать.
Если же компания предпочитает быть «средней по рынку», то нет ничего удивительно, что её сотрудники не будут ценить такое место работы, ведь на рынке полно таких же. А если человек не ценит свое место работы, то и 100% отдачи от него не дождаться.
Слухи о невозможности опротестовать транзакцию подтвержденную pin'ом слышу очень часто. А не засветить pin в наших магазинах — это практически нереальная задача.
Оспорить-то можно, вопрос в том, удовлетворят ли.
Вот сперли у вас карточку, купили что-то и расписались левой подписью. Вы транзакцию оспариваете. По идее нужно проводить анализ подписи. А он, по слухам, очень часто выдает что-то в стиле «подлинность подписи определить нельзя».
Или я не прав и оспаривание в такой ситуации происходит по какой-то другой процедуре?
Ну если разработчик одновременно хороший и адекватный, и если речь идет о городе с большим выбором работодателей, то он прекрасно понимает, что может покинуть компанию, как только она перестанет выполнять договоренности. Так что, в худшем случае, он рискует 90% от одной зп. При этом если зп получается значительно больше чем в других местах работы, то это вполне компенсирует риски.
Да, при таком подходе наверное покатит. Правда, насколько я понимаю, чтобы незнание пароля считалось нарушением трудовой дисциплины нужно, чтобы требование знание пароля наизусть было зафиксировано в трудовых обязанностях работника. Что вроде реализуемо.
С другой стороны все это — тонна бюрократии, отчетности и времени непонятно для чего. Проще уж реально внедрить какие-нибудь rsa токены.
Мало кто желает в совокупности рассмотреть проблему безопасности.
Истинно так.
Все эти регулярные смены паролей и абсурдные требования подчас напоминают крепостные ворота в деревянном заборчике в метр высотой. Эдакая непоколебимая уверенность в том, что злоумышленник будет ломиться исключительно в самую защищенную точку системы.
По закону нельзя просто так взять и уменьшить/не выплатить премию. Впрочем увеличить/выплатить просто так тоже нельзя. Согласно 129 ст. ТК РФ премия — это часть заработной платы.
Выплата премий регламентируется либо трудовым договором, либо положением о премировании. И вот в таком документе должно быть отражено за какие заслуги премия платится и в каких количествах. Соответственно, чтобы порезать человеку премию на том основании, что он не помнит свой пароль, нужно как-то фиксировать это требование. И вот как такое требование нормально закрепить в том же положении о премировании или трудовом договоре я хз. Т.е. зафиксировать-то просто, но вот зафиксировать так чтобы суд, в случае тяжбы, не признал такое требование ничтожным — это уже задачка сложнее.
С другой стороны работник, скорее всего, не будет париться и идти в суд (и ждать пару лет решения, ага) чтобы ему выплатили премию.
Мне как-то попалась система, которая требовала пароль с буквами в обоих регистрах, цифрами и спецсимволами длинной от 7 и до 10 символов. В тот раз подход, подобный вашему, впервые дал для меня сбой, так как пароля удовлетворяющего таким требованиям у меня не было.
Мне несколько раз попадались сайты, которые на попытку восстановить пароль ругались, что мой новый пароль отличается от старого всего одним символом. Вот такие вот сумрачные гении попадаются.
Про «великое чудо» — вы меня с кем-то путаете :), я такого не писал. Я лишь указал на статистическую незначимость вашего рассуждения про античных философов.
Насчет лопарей, у вас уже значимый аргумент, тут правда еще можно сыграть на не репрезентативности выборки. Впрочем, в том же источнике чуть ниже дано еще более сильное утверждение — среди всего РСФСР умершие в возрасте 70 лет и старше составили 8% от всех умерших в 1925 году. Вот это уже перекрыть сложно.
Если бы шестидесятилетний старик считался (цитирую) «великим чудом», девяностолетних помнили бы в том числе, если не в первую очередь, за долголетие.
Люди прожившие больше 110 лет даже сейчас невероятная редкость, но они есть. Много вы таких людей поименно знаете? Без гугла пожалуйста.
Поэтому статистически значимых величин вам в этой дискуссии приведут вряд ли
Ну раз значимых данных за данный период у нас нет, то зачем же к нему апеллировать? Если вы хотите кому-то что-то доказать, то обращайтесь к фактам, их, в отличие от домыслов, сложно опровергнуть.
А можно подробнее? А то я что-то такое уже не в первый раз слышу, но реальных примеров за 6 лет не наблюдал. Да и быстрое гугление не выдает чего-то вразумительного.
Практически любой документ со сложной структурой, который есть необходимость править руками. Например конфиги или дескрипторы развертывания. За счет наличия XSD схемы XML легко проверить на валидность. За счет той же XSD во многих IDE работает автодополнение. По XSD можно даже автоматом сгенерить объектную модель.
Если требуется обработка больших объемов XML, то на помощь приходит XSLT и XQuery.
А еще в json нет неймспейсов.
Если же работать с документом как с DOM деревом или мапить его на объекты, то разницы между форматами по сути и нет — все равно всё спрятано за библиотеками.
А насчет HTML:
А вы взгляните на reactjs — там есть virtual dom, который как раз представляет html в виде json. Просто сравните:
<p class="lead">
<span>A JavaScript library for building user interfaces </span>
<a href="http://facebook.github.io/react/">React</a>
</p>
и
{
tag: 'p',
attrs: {className: {'lead': true}},
children: [
{
tag: 'span',
children: 'A JavaScript library for building user interfaces '
},
{
tag: 'a',
attrs: {href: 'http://facebook.github.io/react/'},
children: 'React'
}
]
}
Я похоже сильно сложно пошел выражать свою мысль. В результате чего получился какой-то спор ниочем и полный оффтоп.
Суть моих мыслей такова: Метод наказания работает только в случае если наказующий имеет значительную власть над наказуемым. В отношениях работодатель-работник такое возможно разве что в ситуации, когда работник финаносово зависим от работодателя (например на работнике висят кредиты/ипотеки, и выплатить их он способен работая только на текущем месте рабты). Если же вы попытаетесь наказать работника, над которым ваша власть незначительна, то он вас пошлет и просто свалит в другую контору (и будет прав).
Задумайтесь, почему вы решили, что имеете право наказывать взрослого, постороннего вам человека? И что вас на самом деле интересует — наказть сотрудника или как-то его изменить?
Вот кстати действительно отличный пример. В реальной жизни тюрьмы могут выступать в двух качествах. Как исправительное учереждение и как наказательное (более удачного слова придумать не смог). Практика показывает, что если тюрьма — это наказание, то из неё выходят преступники (что логично, приходят туда преступники и предпосылок для исправления нет). Поэтому в таком качестве она работает только в случае пожизненных сроков, когда преступник уже не вовращается в социум. В нашей аналогии пожизненный срок — это и есть увольнение.
Другими словами если человек не исправляется, то его наказывают — увольняют. Любые другие наказания порождают появление сотрудника, который в лучшем случае просто от вас уйдет, в худщем будет действовать по принципу «косячить можно, а вот попадаться — нет».
Вот представьте, что он не ваш сотрудник, а, например, сосед. Вы бы стали наказывать соседа за его характер/привычки?
Тут простая логика — если сотрудник иногда косячит по мелочи, то какой вообще смысл его наказывать? Косячат все, без исключений.
Я и не говорил обратного :)
Если вы грозите сотруднику увольнением, значит вы готовы его уволить и никак иначе. Сотрудник, который хочет работать у вас в компании не будет доводить до такой ситуации.
Если сотрудник не устраивает работодателя, то его увольняют. Или предлагают измениться. И в этом нет ничего плохого.
Да, такая логика не работает со звездными сотрудниками, но прекрасно работает с рядовыми, просто потому что они заменяемые. И большинство разработчиков и позиций как раз рядовые. Просто зачастую компания хочет и платить человеку по минималке и чтобы к ним очередь нормальных разработчиков стояла. Но так не бывает.
Насчет бюджета — ну в том же США зарплаты побольше наших, но разработчики есть. ЗП разработчиков — это обычно далеко не первый пункт в топе расходов проекта.
Если сотруднику хорошо платят, нормально относятся, не парят мозг ненужными ему корпоративными игрищами, дают нормальные задачи и т.д., то он будет держаться за такое место работы. Как результат будет стремится хорошо работать.
Если же компания предпочитает быть «средней по рынку», то нет ничего удивительно, что её сотрудники не будут ценить такое место работы, ведь на рынке полно таких же. А если человек не ценит свое место работы, то и 100% отдачи от него не дождаться.
Слухи о невозможности опротестовать транзакцию подтвержденную pin'ом слышу очень часто. А не засветить pin в наших магазинах — это практически нереальная задача.
Вот сперли у вас карточку, купили что-то и расписались левой подписью. Вы транзакцию оспариваете. По идее нужно проводить анализ подписи. А он, по слухам, очень часто выдает что-то в стиле «подлинность подписи определить нельзя».
Или я не прав и оспаривание в такой ситуации происходит по какой-то другой процедуре?
С другой стороны все это — тонна бюрократии, отчетности и времени непонятно для чего. Проще уж реально внедрить какие-нибудь rsa токены.
Все эти регулярные смены паролей и абсурдные требования подчас напоминают крепостные ворота в деревянном заборчике в метр высотой. Эдакая непоколебимая уверенность в том, что злоумышленник будет ломиться исключительно в самую защищенную точку системы.
Выплата премий регламентируется либо трудовым договором, либо положением о премировании. И вот в таком документе должно быть отражено за какие заслуги премия платится и в каких количествах. Соответственно, чтобы порезать человеку премию на том основании, что он не помнит свой пароль, нужно как-то фиксировать это требование. И вот как такое требование нормально закрепить в том же положении о премировании или трудовом договоре я хз. Т.е. зафиксировать-то просто, но вот зафиксировать так чтобы суд, в случае тяжбы, не признал такое требование ничтожным — это уже задачка сложнее.
С другой стороны работник, скорее всего, не будет париться и идти в суд (и ждать пару лет решения, ага) чтобы ему выплатили премию.
А почему работника должны волновать риски работодателя?
Насчет лопарей, у вас уже значимый аргумент, тут правда еще можно сыграть на не репрезентативности выборки. Впрочем, в том же источнике чуть ниже дано еще более сильное утверждение — среди всего РСФСР умершие в возрасте 70 лет и старше составили 8% от всех умерших в 1925 году. Вот это уже перекрыть сложно.
Люди прожившие больше 110 лет даже сейчас невероятная редкость, но они есть. Много вы таких людей поименно знаете? Без гугла пожалуйста.
Ну раз значимых данных за данный период у нас нет, то зачем же к нему апеллировать? Если вы хотите кому-то что-то доказать, то обращайтесь к фактам, их, в отличие от домыслов, сложно опровергнуть.
Я могу так же привести 3 примера людей, которые жили 116 лет, но из этого не следует, что это что-то обычное.
Если требуется обработка больших объемов XML, то на помощь приходит XSLT и XQuery.
А еще в json нет неймспейсов.
Если же работать с документом как с DOM деревом или мапить его на объекты, то разницы между форматами по сути и нет — все равно всё спрятано за библиотеками.
А насчет HTML:
А вы взгляните на reactjs — там есть virtual dom, который как раз представляет html в виде json. Просто сравните:
и