Пересмотр зарплат раз в пол года по результатам теста и практического задания по новой "технологии" должен мотивировать.
Иначе нахрен такие работники?
Вы не боитесь, что ваши работники обучатся и уйдут?
Я боюсь, что они не обучатся и остануться.
Копирайт: кто-то
Полная Версия: Как привить человеку понимание ООП
На счет денег как мотивации
Я например воспринимаю ЗП как критерий значимости своего труда. Если требуют много и ЗП соответствует, я понимаю, что то чем я занимаюсь, продается и за этого готовы платить. Если же мне платят мало, а требует много, то возникает ощущение, того что мой труд ничего не стоит (ну или продается за сущие копейки) и я не очень то полезен.
Премия - для меня звучит как "псс, пацанчик, не хочешь пару неделек разорванной жопы".
Я не отрицаю, что есть программисты у которых мотиватором являются деньги, но судя по моим наблюдениям (такие программисты у нас работали), мотивация деньгами порождает говнокод и копипаст, после чего этот код нужно или переписывать, или тратить моральные сила на работу с ним.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Я например воспринимаю ЗП как критерий значимости своего труда. Если требуют много и ЗП соответствует, я понимаю, что то чем я занимаюсь, продается и за этого готовы платить. Если же мне платят мало, а требует много, то возникает ощущение, того что мой труд ничего не стоит (ну или продается за сущие копейки) и я не очень то полезен.
Премия - для меня звучит как "псс, пацанчик, не хочешь пару неделек разорванной жопы".
Я не отрицаю, что есть программисты у которых мотиватором являются деньги, но судя по моим наблюдениям (такие программисты у нас работали), мотивация деньгами порождает говнокод и копипаст, после чего этот код нужно или переписывать, или тратить моральные сила на работу с ним.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Как привить человеку ООП? Давать задачи, которые без ООП превращаются в сущий ад. Когда чувак отсидит пару дней в своём спагетти-коде, а потом ему расскажешь, что с ООП он бы потратил максимум пару часов - вот это будет мотивация!
Натравить на них общество, потому что мнение коллег гораздо объективнее воспринимается, чем мнение начальника. Он по определению гад и тиран, его мнение воспринимается слишком критически.
Натравить на них общество, потому что мнение коллег гораздо объективнее воспринимается, чем мнение начальника. Он по определению гад и тиран, его мнение воспринимается слишком критически.
Ron
Дай мне задачу, которую без ООП нельзя реализовать
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Дай мне задачу, которую без ООП нельзя реализовать
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
| Цитата (twin @ 7.03.2016 - 14:48) |
| Пусть Сергей это назовет манипуляцией, как угодно. Это все равно все открыто и честно. И в итоге все довольны. |
Ну дык... Еще раз повторю
Манипуляция - это не плохо. И не хорошо. Это просто существует. Это просто управление другим человеком, явное или не явное.А та же "мотивация" - это, по сути, синоним "открытой манипуляции с положительной обратной связью". (во как завернул, самому аж страшно стало
)chee, у меня вот такая мысль дурная появилась... Дать человеку задание подготовить доклад на часок на тему "чем процедурный код лучше ООП"
Который он потом расскажет коллективу. С реализацией одного и того же действия/процесса/алгоритма разными средствами. В процессе он будет обязан изучить много чего, иначе у него сравнения не получится.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата (inpost @ 7.03.2016 - 21:49) |
| Дай мне задачу, которую без ООП нельзя реализовать |
Любую можно. Вопрос какого качества код получится, насколько пригодный для поддержки. Предлагаю подсунуть такой код автору и попросить исправить какую-нибудь фишку. Пусть посидит денек другой, а в это время ходить и активно интересоваться о готовности задания.
Ron
Учесть, что без ООП код качественнее получится, то "любая" вовсе не подходит. Давай конкретную.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Учесть, что без ООП код качественнее получится, то "любая" вовсе не подходит. Давай конкретную.
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
| Цитата (sergeiss @ 7.03.2016 - 21:57) |
| Который он потом расскажет коллективу |
Думаю не подействует, потому что это докладчику абсолютно неинтересно. А коллективу, кто уже искушен в вопросах ООП интересно еще меньше. Все только будут злиться за отнятое просто так время. В итоге начальник усугубит негативное к себе отношение, а значит и к своему мнению.
Господин twin на этом же форуме ярко демонстрирует факт, что человека теоретическими выкладками переубедить невозможно. Причем ни в одну ни в другую сторону.
Тут надо заставить человека распробовать свой код на собственной же шкуре. Если задача адекватно решается с помощью императива, то не вижу смысла что-то менять.
| Цитата (inpost @ 7.03.2016 - 22:04) |
| Учесть, что без ООП код качественнее получится, то "любая" вовсе не подходит. Давай конкретную. |
Что вкладывать в понятие "качественнее"? Качество кода оценивается его читабельностью раз, и сложностью модификации два. Все остальные характеристики качества кода, извини, от лукавого.
Скорости выполнения нужно добиваться алгоритмически, а не экономией микросекунд на коде в ущерб читаемости и модификации.
Ron
| Цитата |
| Натравить на них общество, потому что мнение коллег гораздо объективнее воспринимается, чем мнение начальника. Он по определению гад и тиран, его мнение воспринимается слишком критически. |
Тварь ты
| ! |
waldicom |
| Цитата |
| Забухал, чтоли? Проследуйте в читатели. |
Налицо же юмор. Разве что без закадрового смеха.
| Цитата (sergeiss @ 7.03.2016 - 21:57) |
chee, у меня вот такая мысль дурная появилась... Дать человеку задание подготовить доклад на часок на тему "чем процедурный код лучше ООП" |
Это попахивает форумными холиварами. У них нет мысли что процедурка лучше чем ООП, они просто, как мне кажется, не видят почему, то что они делают не является ООП. Мне нужно им привить понимание ООП, не потому что я хочу что бы вокруг меня было везде ООП, а потому что этот навык очень сильно влияет на поддерживаемость кода.
| Цитата (Ron @ 7.03.2016 - 22:14) |
| Тут надо заставить человека распробовать свой код на собственной же шкуре |
Как показывает практика, такой подход слишком дорог для всей команды. Пока программист будет лить говно в общие репы, страдать будут все, но не он.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
| Цитата (BBX @ 8.03.2016 - 01:14) |
| Товарищи ООП-гуру, ТС, а вы как ООП изучали, каков ваш метод? |
Вяло и тяжко я его изучал, наставников то не было. Много раз переписывал код своих pet-проектов, внедрял что-то новое, следствии чего пришел к необходимости использования ООП. Потом когда начал в своих проектах использовать внедрение зависимостей пришло понимания сути большинства концепции ООП. Мне не повезло у меня не было такого наставника, который бы хотел прокачать мои навыки.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Пускай начинают с UML, потом объяснишь им паттерны с примерами из жизни (лучше всего из вашего проекта). Потом расскажешь как делать не надо, антипаттерны. Заставь их выучить наизусть, тогда при решении задачи у них появятся все шансы заюзать человеческое решение. Ну а дальше уже пойдет само по себе, когда распробуют ООП, будут достаточно замотивированы в дальнейшем самостоятельном развитии.
| Цитата (chee @ 7.03.2016 - 20:00) |
| они просто, как мне кажется, не видят почему, то что они делают не является ООП |
Проблема оказывается серьёзнее. Тут не стоит вопрос что использовать. Тут вопрос стоит "как". Другими словами нет взаимопонимания, корпоративного стиля разработки.
Девушке больше нравится модель stateless, у парня свое видение ответственностей. К сожалению в ООП это часто бывает, я писал об этом. Сколько разработчиков, столько и "правильных ООП". Обычно программисты в команде со временем ассимилируются, но для этого тоже должны быть соблюдены некоторые условия и мотивации. Главное - корпоративный дух и доверие между членами команды.
Я не зря давал ссылку еще в самом начале. Наверняка она была проигнорирована. А зря. В таких ситуациях очень могут помочь принципы экстремального программирования. Такие как эволюционное проектирование, парное программирование, коллективная ответственность за код и некоторые другие. Вообще XP очень способствует выработке командного духа, общего стиля. Особенно в условиях непрерывного рефакторинга действующего проекта. Испытано на практике лично мной. И кстати, вообще не важно, какая методология применяется. ООП или нет.
Не пожадничаю, покажу немного из "устава" нашей команды:
| Цитата |
Корпоративная методология. Это упрощенная XP методология. Организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований. Обозначу основные моменты: 1. Этот пункт прямо как для нас придуман "Заказчик всегда рядом": «Заказчик» в XP — это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов. 2. Самый важный на мой взгляд: Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому: — члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом; — обеспечивается эффективное выполнение остальных практик. Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг, продвижение проекта затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, вся команда работает унифицированно, как один человек. 3. Отсюда плавно вытекает коллективное владение кодом: Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист. 4. Очень подходит под текущие требования эксплуатации проекта рефакторинг:: XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Попытка детально спроектировать систему в самом начале работы является напрасной тратой времени. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Рефакторинг, это оптимизация существующего кода с целью его упрощения. Такая работа должна вестись постоянно. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. 5. Тестирование, или то, чего никак не получается заставить делать. В отличие от большинства остальных методологий тестирование в XP – одно из важнейших составляющих. Экстремальный подход предполагает, что тесты пишутся до написания кода. Тесты пишут сами программисты, любой из них имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается. 6. Простота и эффективность кода. Часто предоставленный сам себе разработчик решает использовать новую технологию или инструмент, который, по его мнению, обещает дополнительную производительность или выгоду. На самом деле это редко оправдывается, а в атмосфере, когда ваш код завтра будет прочитан и использован партнерами по команде, у вас просто не остается возможностей для экспериментов за чужой счет. Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды. Использование редких технологий и инструментов может вызвать не только проблемы понимания, но и впоследствии проблемы поддержки. Учитывайте, что освоение сложного инструмента может занять больше времени, чем вся разработка проекта. Основная прелесть экстремального программирования - прогнозируемость и сведение к минимуму затрат на разработку; предоставление заказчику того продукта, который он желает получить на момент выпуска; и конечно же общение и обучение разработчиков без отрыва от производства. |
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Здесь расположена полная версия этой страницы.