Да, мне — не 54 года, а «всего» 36. Но, честно говоря, уже достаточно сложно работать по 20-30 часов подряд. Не потому, что «не хочется», а потому, что «тяжело». И старшая дочь уже практически взрослая, и не всегда выбор между временем с семьей и очередным проектом заканчивается в пользу кодинга.
Я бы хотел поговорить об основном «двигателе» нашей работы — мотивации. Я знаю, что отнюдь не все айтишники доверяют психологии, считая ее «бульварной наукой». Даже не наукой, а сводом анекдотических историй и статистически недостоверных догадок.
Лично у меня к психологии подход следующий: если что-то работает — не трогай, даже если ты и не знаешь лежащих в основе этой «магии» механизмов. Я стараюсь просто пробовать все, что я прочитаю по этой теме лично для себя, оставляя лишь реально эффективные лично для меня методы и принципы. А их, к слову, в психологии более, чем достаточно:
1. Для мотивации, кроме внутреннего желания и внешних дедлайнов, требуется еще и зритель
Если не хочешь «закиснуть», нужно показывать свою работу хоть кому-нибудь. Даже не важно, будет ли он оценивать ее качество. Важно, чтобы он просто заметил ее, хотя бы в формате: «да, вижу, отвали...» Подойдет абсолютно любой человек, даже не обязательно будущий пользователь продукта. Даже жена — не айтишник.
2. Мотивация приходит с результатами и умирает без них
Чем быстрее ты релизнул что-то, тем больше у тебя мотивации продолжать этот проект. Если бесконечно затягивать релиз, мотивация исчезнет сама собой. Причем гораздо быстрее, чем ты ожидаешь.
Лучший мотиватор — прямо сейчас релизнуть хоть что-нибудь и с ужасом понять, что кто-то прямо сейчас может скачать или зайти на этот бред. Напоминает детские ощущения вида: «Блииин, бардак в комнате, а мама вернется через 15 минут...» Желание править баги и допиливать недостающий функционал возникает моментально.
3. Мотивация редко возникает из ниоткуда, но она автоматически приходит с началом работы
Если вдохновение пришло — отлично! Нужно немедленно садиться и работать. Но, если вдохновения все еще нет, бессмысленно ждать, пока оно появится само собой. Теоретически могла бы помочь сила воли: начав что-то делать, мы автоматически втягиваемся. Но силы воли не всегда хватает, к сожалению.
Лично я в этом случае использую метод «утаптывания травы»: открываю проект, подготавливаю нужные файлы, начинаю разбираться понемногу в деталях. Чем больше я погружаюсь в задачу, хотя бы теоретически или в процессе подготовки к ее выполнению, тем больше мотивации ее продолжать. Причем «прорыв» происходит, чаще всего, неожиданно — увлекаешься какой-нибудь мелочью будущего проекта, садишься реализовывать именно ее — и втягиваешься.
Еще помогают «размышления на бумаге»: просто создаю новую заметку, и начинаю своими словами описывать будущий проект и его детали.
4. Критик — убийца мотивации, его можно и нужно наказывать
Не позволяйте никому критиковать вашу работу, особенно если она еще далеко от совершенства. Если не получается избегать этих людей, представляйте их в виде злых монстров, чье мнение — не слова, а стрелы, от которых вы уклоняетесь.
5. Режим дня и регулярный спорт повышают мотивацию к любой работе
Проверено не раз: если я не засиживаюсь по ночам, встаю в одно и то же время, и хотя бы пару раз в неделю бегаю в ненапряжном режиме час на орбитреке параллельно с просмотром интересного фильма, у меня появляется мотивация даже к самой геморройной работе. И, наоборот: как только я ленюсь заниматься спортом или устраиваю ночные «заплывы» в интересный проект, мотивация через несколько дней падает практически в ноль.
6. Снижаем планку
Если ты будешь ругать ребенка за первые неуклюжие рисунки, он никогда не станет великим художником. Ребенок делает первые детские шаги — он и должен делать первые, именно детские, шаги. Можно и нужно позволять себе делать работу «тяп-ляп» при старте любого проекта — качество приходит с практикой, а в погоне за перфекционизмом объем практики резко снижается.
Прокрастинация — на самом деле, страх, а не лень. Страх сделать что-то не так: нам больше нравится получать мелкие текущие победы ценой большого будущего поражения (казино, форекс, курение), нежели терять понемногу каждый день, но скомпенсировать это большим будущим призом. Так вот, снижение планки — это именно мелкие «поражения» на старте проекта, которые оборачиваются в итоге победой в лице его реального развития и «полировки» в процессе, а не откладыванием его в долгий ящик.
7. Поддержание состояния потока
Программирование — один из немногих видов деятельности, позволяющий входить в состояние потока (еще есть музыка, вождение автомобиля, компьютерные игры и некоторые виды спорта). Этим стоит пользоваться, понимая принципы входа и выхода из него: для входа требуется получать немедленный фидбек от простых действий, для выхода достаточно любого внешнего дистрактора.
Соответственно, вместо часового написания кода без компиляции и запуска, стоит разделить все на короткие 5-минутки с немедленным запуском частичного готового кода и проверки хотя бы частичной его работы. Просто попробуйте, если еще не делаете этого. Лично я вообще запускаю проект чуть ли не каждую минуту, когда пишу что-то новое и короткое.
Если ты пытаешься спроектировать свой проект с самого начала и до мельчайших деталей, ты лишаешь себя мотивации в процессе его будущей реализации: всю креативную и интересную работу ты уже выполнил, и остается лишь тупой кодинг. Так что проектировать лучше все-таки лишь в общих чертах, оставляя себе конкретные детали реализации на «практический десерт».
Ну а для избежания выхода из состояния потока нужно убрать все отвлекающие факторы: программировать «запойно», по нескольку часов подряд, пока хватает сил и желания. Лучше переработать, но сделать работу за неделю вперед, нежели выжимать ее из себя в час по чайной ложке. Отключить телефон, закрыть скайп, браузер и контактик. Сотрудников стоит приучать к тому, что несрочные вопросы должны решаться исключительно по почте. Музыка, к слову, тоже мешает — быстро утомляет.
8. Мы не любим чужой код
Это — понятно, но даже наш собственный код примерно через полгода становится «чужим». Чтобы избежать необходимости разбираться в «своем чужом коде», стоит минимизировать зависимости внутри него, оставляя простейшие «черные ящики» с минимальным функционалом, чтобы не пришлось в них снова влезать. Иногда гораздо проще выкинуть такой мелкий «черный ящик», нежели разбираться, что ты там накреативил пару лет назад.
Мы всегда понимаем, насколько тупой и кривой код написали пару лет назад, но редко думаем о том, что наш текущий код — такой же тупой и кривой с точки зрения нас же, но из будущего.
И еще: всегда будет соблазн «освежить» старый код, переписать его. Не стоит: все равно через пару лет он снова превратится в тупой и кривой. Мотивацию лучше использовать для написания нового кода, а переписывание старого — как «стартер» в моменты, когда мотивации еще нет. Втянулись в работу? Отлично! Откладываем старый код, пишем новый.
9. Мы не любим чужие библиотеки
Любая «реюзабельная» библиотека — бомба замедленного действия. В новом проекте ты по-любому будешь расширять и изменять ее, тем самым ломая старые проекты. Причем незаметно, поскольку ты их не касался уже несколько месяцев, и не коснешься, возможно, еще очень долго. Нет ничего хуже, когда нужно срочно допилить что-то мелкое в старом проекте, а он тупо не компилируется.
Каждый новый проект должен иметь свою, отдельную копию библиотек, даже если этим ты жертвуешь перекрестным баг-фиксом. Если в старом проекте очевидный баг в либе не мешает, да ну и хрен с ним! Попытка разобраться в своих же старых либах, а уже тем более переписать их с учетом новых знаний и опыта способна сожрать любое время и любую мотивацию.
Вместо создания библиотек лучше расширять язык, в C# — extention methods. Вместо библиотеки сжатия/шифрации лучше сделать один раз extention Compress/Encrypt и использовать его с помощью подсказок среды программирования, не задумываясь о его внутренней реализации и не вспоминая каждый раз, откуда брать пресловутую библиотеку.
Постепенно копится мега-либа расширений, которая просто линкуется к любому проекту и расширяется по мере необходимости, обеспечивая реюзабельность кода на уровне простейших «кирпичиков». Тут важно лишь помнить о том, что старый код трогать не стоит, чтобы не порушить старые проекты. Вместо расширения параметров функции лучше сделать новую, а старая пусть лежит, как есть.
10. Универсальные решения сложнее конкретных
Банальность, но все-таки: в погоне за разработкой универсальных алгоритмов и фреймворков мы лишаем себя простых и очевидных решений, доступных в контексте текущей задачи. Вместо «универсального списка последних просмотренных элементов» лучше сделать конкретный список последних документов текущего проекта. На практике гораздо проще скопипастить код из прошлого проекта и модифицировать его под нужды нового, нежели поддерживать универсальную либу.
Мотивация — это как топливо. Если ее потратить на излишнюю работу по универсализации чего-либо, ее не останется на реально важную работу.
11. Мотивацию нужно ценить и пользоваться ей по-полной
Если хочется сделать что-то важное прямо сейчас — сядь и сделай. Наилучшие результаты приходят со срочным выполнением не срочной, но важной работы, а не срочной и важной (тогда ты просто «догоняешь» текущую ситуацию), и уж тем более не из-за работы над чем-нибудь не срочным и не важным. Да, ты будешь иногда опаздывать, но большая часть кажущихся нам серьезных последствий откладывания срочной работы на практике оказываются не столь уж и серьезными.
Комментарии (98)
lair
29.01.2016 14:03+8A Code of Conduct for Professional Programmers. В принципе, дальше можно не обсуждать, там все прописано. Но если очень хочется, то…
Не позволяйте никому критиковать вашу работу
А как вы будете получать фидбек?
особенно если она еще далеко от совершенства
Это состояние практически бесконечно. Но даже если оно конечно, то вы заменяете быстрый фидбек на медленный — что тоже плохо.
Можно и нужно позволять себе делать работу «тяп-ляп» при старте любого проекта
См. выше. Вы сделали работу «тяп-ляп» — вы, надеюсь, понимаете, что она далека от совершенства — вы ее никому не показываете — если это не удалось, вы избегаете слышать критику. И как развиваться?
Программирование — один из немногих видов деятельности, позволяющий входить в состояние потока
… и это — его беда. Состояние потока (оно же «зона») приносит больше вреда, чем пользы.
программировать «запойно», по нескольку часов подряд, пока хватает сил и желания. Лучше переработать, но сделать работу за неделю вперед
Нет, не лучше. Вам только кажется, что в «запое» вы принимаете элегантные решения; на самом же деле, выйдя из него, вы не будете в состоянии ни понять, что вами сделано, ни как-то это обработать.
Вместо создания библиотек лучше расширять язык [...] Постепенно копится мега-либа расширений, которая просто линкуется к любому проекту и расширяется по мере необходимости
Эта «мега-либа» имеет те же самые проблемы, что и любые другие библиотеки — только в плюс к этому вы еще и получаете все проблемы монолитных решений. А сколько зависимостей за собой потянет эта мега-либа… а как они будут конфликтовать рано или поздно…
MaxPastukhov
29.01.2016 14:15+2А как вы будете получать фидбек?
А зачем, собственно? Для фидбека, необходимого для мотивации, достаточно самого факта того, что проект работает и развивается, плюс демонстрации его абсолютно любым людям. А «продуктовый фидбек» — это уже из другой оперы, это уже больше касается не мотивации разработчика, а развития продукта, и он должен выполняться исключительно реальными пользователями продукта, а не левыми людьми.
«Особенно если она еще далеко от совершенства» — Это состояние практически бесконечно. Но даже если оно конечно, то вы заменяете быстрый фидбек на медленный — что тоже плохо.
Плохо для чего? Для мотивации? Для мотивации — критика убийственна. Любая: быстрая, или медленная, без разницы.
См. выше. Вы сделали работу «тяп-ляп» — вы, надеюсь, понимаете, что она далека от совершенства — вы ее никому не показываете — если это не удалось, вы избегаете слышать критику. И как развиваться?
Вам шашечки или ехать? Толку с того, что вас ткнули носом в какую-нибудь ошибку или идею в процессе, если из-за этого у вас исчезнет мотивация процесс продолжать? Для развития проекта нет ничего важнее мотивации разработчика. А то, вырастет или разовьется он в процессе — вопрос вторичный. Толку от того, что ты — мегаразвит, если у тебя — ни одного законченного проекта?
Состояние потока (оно же «зона») приносит больше вреда, чем пользы.
А вот тут — можно чуть подробнее? И с фактами, желательно?
Нет, не лучше. Вам только кажется, что в «запое» вы принимаете элегантные решения; на самом же деле, выйдя из него, вы не будете в состоянии ни понять, что вами сделано, ни как-то это обработать.
Стратегические решения принимаются на этапе проектирования, а от тактических качество проекта в целом не особо страдает. Гораздо эффективнее как-нибудь потом поправить очевидно узкое место, нежели растянуть разработку на несколько месяцев, вместо пары недель.
Эта «мега-либа» имеет те же самые проблемы, что и любые другие библиотеки — только в плюс к этому вы еще и получаете все проблемы монолитных решений. А сколько зависимостей за собой потянет эта мега-либа… а как они будут конфликтовать рано или поздно…
Гораздо меньше, чем в других вариантах. Да и зависимостей внутри этой либы практически нет, там — простейший функционал на уровне работы со строками, массивами и так далее. Просто набор функционала, который разработчики языка не посчитали нужны встроить в стандартные библиотеки. Вы же не жалуетесь, когда линкуете либу System?lair
29.01.2016 14:25+3А зачем, собственно?
Чтобы развиваться.
Плохо для чего?
Для развития кода.
Для мотивации — критика убийственна.
Что-то у вас не так с мотивацией, если честно. Так, как вы описываете, быть не должно.
Вам шашечки или ехать?
Мне результат, очевидно. А результатом я считаю выполненную задачу.
А вот тут — можно чуть подробнее? И с фактами, желательно?
Уже упомянутая выше книга Мартина, глава четыре, раздел «The Flow Zone».
а от тактических качество проекта в целом не особо страдает.
Ах если бы. Одно неверное тактическое решение — и какая-нибудь важная функциональность тормозит на два порядка.
Да и зависимостей внутри этой либы практически нет, там — простейший функционал на уровне работы со строками, массивами и так далее.
А что же в таком случае делать с более сложными зависимостями?
MaxPastukhov
29.01.2016 14:38«А зачем, собственно?» — Чтобы развиваться.
Если критика мешает мотивации, то и работы не будет. А не будет работы — не будет и развития. Развитие не идет в вакууме, в теории, оно идет в практическом применении полученных знаний. Те же знаний можно вполне получать постфактум, для следующей версии проекта, не теряя ее на разработке текущей. Гораздо эффективнее выпустить хоть что-нибудь, и потом выслушать объективные предложения по развитию, нежели вечно тормозить себя в процессе, рискуя так никогда и не закончить проект.
«Плохо для чего?» — Для развития кода.
Любой код — временный. Абсолютно похеру, какой у тебя в текущем проекте код, поскольку он все равно покажется тебе хреновым через пару лет. Если код решает поставленную задачу — он уже хороший.
Мне результат, очевидно. А результатом я считаю выполненную задачу.
Если мотивации нет, задача не будет выполнена.
Уже упомянутая выше книга Мартина, глава четыре, раздел «The Flow Zone».
Я привел свое мнение о том, что для меня работает на практике. Вы привели мнение другого человека, для которого это не работает. Я же просил факты.
Ах если бы. Одно неверное тактическое решение — и какая-нибудь важная функциональность тормозит на два порядка.
И? Ну переделай, делов-то. Лучше выпустить что-то сырое, и допиливать в процессе, нежели никогда не дойти до релиза.
А что же в таком случае делать с более сложными зависимостями?
Выносить в основной проект. Если что-то — реально сложное, значит оно — специфичное, и, скорее всего, именно для конкретного проекта. Цель этой мега-либы — сэкономить время на мелочах: работа со строками, файлами, потоками, и так далее. Чтобы вместо цикла и отдельной функции в проекте писать вызов очевидной и простой функции.lair
29.01.2016 14:44+6Если критика мешает мотивации, то и работы не будет.
Это самое важное «если». С моей точки зрения, если критика мешает мотивации, то нужно сначала сделать так, чтобы она перестала ей мешать.
Если код решает поставленную задачу — он уже хороший.
А решает ли? А укладывается ли во все поставленные ограничения? А что скажет человек, которому это потом читать и поддерживать?
Вы привели мнение другого человека, для которого это не работает. Я же просил факты.
Я склонен доверять продолжительному опыту этого «другого» человека. Впрочем, чего лукавить — просто его тезис совпадает с моими личными наблюдениями: в командной работе «зона» непродуктивна.
Лучше выпустить что-то сырое
Не всегда. Далеко не всегда. Когда у тебя есть обязательства перед десятком партнеров, после «сырого» релиза партнеров может и не стать. А с ними — и денег.
Выносить в основной проект
В каком виде? Реализовать самому, или же все-таки использовать стороннюю библиотеку?
Если что-то — реально сложное, значит оно — специфичное, и, скорее всего, именно для конкретного проекта.
Серьезно? Что «специфичного» в OAuth?MaxPastukhov
29.01.2016 14:53+1Это самое важное «если». С моей точки зрения, если критика мешает мотивации, то нужно сначала сделать так, чтобы она перестала ей мешать.
Опять же возвращаемся к вопросу о «должен» и «на самом деле». Мы все «должны» спортом заниматься, работу любить и проекты в срок релизить. А на практике мы можем лишь использовать то, что имеем в наличии. То есть отнюдь не совершенный экземпляр :)
А решает ли? А укладывается ли во все поставленные ограничения? А что скажет человек, которому это потом читать и поддерживать?
Я уже сказал выше, что лучше делить код на мелкие «черные ящики», в идеале не требующие последующей поддержки. И, на практике, иногда проще выкинуть такой «ящик», нежели тянуть его за собой.
Я склонен доверять продолжительному опыту этого «другого» человека. Впрочем, чего лукавить — просто его тезис совпадает с моими личными наблюдениями: в командной работе «зона» непродуктивна.
Не буду спорить, поскольку я рассуждаю лишь о самомотивации.
Не всегда. Далеко не всегда. Когда у тебя есть обязательства перед десятком партнеров, после «сырого» релиза партнеров может и не стать. А с ними — и денег.
Когда у тебя есть с десяток партнеров, у тебя уже — не сырой продукт. Он и отношения требует более бережного, понятное дело. Я говорю в основном о ситуации, когда тебе нужно запустить что-то реально новое.
В каком виде? Реализовать самому, или же все-таки использовать стороннюю библиотеку?
Зависит от контекста.
Серьезно? Что «специфичного» в OAuth?
То, что OAuth требуется отнюдь не каждому из использующих эту мега-либу проектов.lair
29.01.2016 14:58+2Опять же возвращаемся к вопросу о «должен» и «на самом деле».
Ну так надо над собой работать. А если не работать, то… в общем, не выйдет ничего.
Я уже сказал выше, что лучше делить код на мелкие «черные ящики», в идеале не требующие последующей поддержки.
В некоторых системах это принципиально невозможно.
я рассуждаю лишь о самомотивации.
Но ваши советы-то влияют на все поведение программиста, а не только на его самомотивацию.
Я говорю в основном о ситуации, когда тебе нужно запустить что-то реально новое.
А в других ситуация мотивация не нужна?
Зависит от контекста.
Тогда и ваш тезис «любая библиотека — бомба замедленного действия» «зависит от контекста».
Собственно, ваше «мы не любим библиотеки» — это «я не люблю библиотеки». Я вот, скажем, очень люблю библиотеки, потому что меня достали бесконечные повторные реализации одного и того же.
То, что OAuth требуется отнюдь не каждому из использующих эту мега-либу проектов.
Но тем не менее, он реализуется не «для конкретного проекта», а под стандарт (или, в худшем случае, под провайдера).
Wesha
29.01.2016 23:47+5Если критика мешает мотивации, то и работы не будет.
Если критика мешает мотивации, то, мне кажется, Вы не в Вашей профессии.
Критика должна вызывать эмоции вида «ух ты, вот как, оказывается, можно это сделать лучше!», а не «маааааам, он менякозломобозвал!!!»
MacIn
30.01.2016 02:18+2То критика. А когда льются тонны говн о форматировании, именовании, языке программирования проекта — это для мотивации на самом деле плохо. Если оно — говны (по форме).
Wesha
30.01.2016 02:34+3А может быть, на минуточку предположить, что Вам таки нечто дельное пытаются посоветовать?
Например, годами идёт спор о том, ставить ли в Ruby скобки или не ставить (язык позволяет и так, и так). Лично для меня, после того, как я за годы работы видел целый ряд случаев, когда интерпретатор интерпретировал код без скобок совсем не так, как ожидал человек, этот код писавший (при том, что на нахождение причин загадочного поведения кода — «тут же ошибки быть не может, всё же очевидно!!!» — у команды иногда уходило до пары дней) ответ один: скобки надо ставить всегда: два лишних нажатия клавиш стоят экономии двух дней на поиске загадочных ошибок.
А ещё не нарывавшиеся на эти граблияйцаджуниоры меня учить пытаются — «да зачем тут ставить, всё же тут ясно...».
«Инструкции пишутся кровью.» Помните это, и не требуйте, чтобы это была лично Ваша кровь.
«Все люди учатся на ошибках, только умные — на чужих, а дураки — на своих.»MacIn
30.01.2016 02:43+3Нет, нет. Вы не поняли. Я написал «если оно — говны(по форме)».
Я о недопустимой форме высказывания, а не сути критики. Так-то оно к тому и приводит «ага, так лучше», или «классно, не думал об этом». Но то если форма нормальная.Wesha
30.01.2016 02:51-2Ну, мне сложно судить о Вашей конкретной ситуации, но знаете, я иногда не удерживаюсь от, гхм, неуставной формы, когда человек пишет совершеннейший бред — например,
if self.nil? then ...MacIn
30.01.2016 02:59+7Проблема в том, что у каждого мерка «совершеннейшего бреда» своя. И это зависит не от стажа. И может относится даже к вкусовщине. Оформлению, отступам, именованию и пр. На мотивацию это влиет не хорошо. И даже «неуставная» критика по делу не так плоха. А вот неуставная по форме и пустая по сути, вроде (это не мое, просто пример наобум) «только дебилы используют венгерскую нотацию» никакого позитива в виде обучения новому, осознания своих ошибок, не привносит. Лучше никакого feedback'а, чем такой мусор.
Hokum
29.01.2016 15:11+66. Снижаем планку
Довольно спорный абзац, правильно ли я понял, что Вы предлагает разрешить себе делать тяп-ляп, но тяп-ляп с точки зрения себя в будущем. Т.е. в настоящем, делать максимально хорошо для своего текущего уровня, при этом осознавая, что ваше решение может будет «говнокодом» с точки зрения более опытного разработчика?
4. Критик — убийца мотивации, его можно и нужно наказывать
Мне кажется проблема не в критике, а в том что мы называем критикой. Все таки «ну и зачем ты это придумал, это никому не нужно», «да кто пользуется этой древней технологией, когда есть технология X!» это не критика и такое убивает мотивацию, хотя возможны исключения, что-то типа «на слабо». А вариант «ты здесь используешь аллгоритм Y, но мне кажется что здесь подойдет аллгоритм X, ты его рассматривал?» или «в этой задаче часто встречаются такие-то и такие-то проблемы» хоть и остановит рвение немедлено начать писать код, но даст бонус в развитии как программиста так и проекта. Критика должна быть диалогом, тогда она приносит пользу.
Не могу знать, что конкртено имел ввиду lairСостояние потока (оно же «зона») приносит больше вреда, чем пользы.
но мой опыт подсказывает что в состоянии потока, программист держит в голове куда более большие куски системы, чем в обычном состоянии. Соответсвенно взаимодействие между подсистемами которые в состоянии потока кажутся прозрачными, в обычном состояниии превращаются в нечто монолитное и запутанное.
Состояние потока хорошо для прототипирования, когда абсолютно не важно качество кода, но важно быстро проверить какие-то идеи. Для проекта который будет поддерживаться состояние потока может принести вред, даже если модуль был распланирован вдоль и поперек, так как есть вероятность увлечься и затронуть модули, которые не были проработаны.
9. Мы не любим чужие библиотеки
В любом проекте стоит минимизировать внешние зависимости, но и глупо копипастить одно и то же. Выделить общий код в билиотеку, с системой контроля версий, а дальше если эта библиотека не требует компиляции, то добавить скрипты которые вытягивают для каждого проекта нужную версию это бибилиотеки в рабочий каталог или собирать и хранить в каком-нибудь общем хранилище разные версии библиотеки. В любом случае должны быть тесто проверящие, что ничего не поломается от внесенных изменений. В идеале библиотека должна быть полноценным продуктом, со своим циклом жизни.
10. Универсальные решения сложнее конкретных
Полностью с Вами согласен. На мой взгляд мало того, что сложнее так еще и не всегда ясно какая «универсальность» понадобится в будущем. А главное универсальность, если она и понадобится будет более аккуратной, так как будет строится не из домыслов, а реальных задач.
А в остальном с вами согласен, хорошая статья. Напоминает о чем стоит помнить, чтобы работа была в радость. :)MaxPastukhov
29.01.2016 15:35+3Сорри, что отвечу кратко — пишу с айпеда.
6. Да, я имел в виду именно «тяп-ляп» с той точки зрения, что любой код станет хреновым со временем. Но я на практике также позволяю себе некоторые «грубости» вроде захардкоженных констант просто для того, чтобы все как можно быстрее «завелось». Главное, когда есть поток — потратить его максимально эффективно, а разные детали и потом можно допилить.
4. Да, согласен. Твой вариант гораздо ближе к тому, что я называю «помощью»: если ты не просто тыкаешь человека носом в его ошибку, а рассказываешь, учишь. Ну тут, опять же, вопрос: а стоит ли его вырывать из состояния потока в процессе работы? По своему опыту могу сказать, что гораздо приятнее переделать код на более оптимальный уже после релиза хоть чего-нибудь, нежели тормозить себя. Да, будут баги и кривости, но часто отнюдь не там, где это казалось кривым в процессе :)
9. Лично у меня не получается такого добиться :) Увлекаюсь расширением либ, потом их хочется зарефакторить… и понеслась :)
Спасибо за приятный отзыв :)
neyronius
29.01.2016 19:31+2Мне нравится идея развития дисциплины вместо мотивации. Дисциплина в работе — привычка, которая может быть выработана за несколько недель и останется с тобой навсегда, постоянно принося плоды ввиде эффективно использованного времени, качественного кода, тестов, и карьерного роста. Мотивация может внезапно пропасть, и ты опять будешь читать статью про мотивацию.
MaxPastukhov
29.01.2016 20:58+2Мое мнение: сила воли нужна, но зачем себя лишний раз насиловать, если можно работать в свое удовольствие? Я, допустим, могу заставить себя кодить, не вопрос. Просто когда я это делаю с желанием, я и работаю быстрее, и результат на выходе как-то поприятнее :)
MacIn
30.01.2016 03:31+2Все советы по поводу «как выработать силу воли» (дисциплина — производная) разбиваются о то, что человеку надо начать что-то делать, чтобы сила воли выработалась. Нужна та самая, — внезапно, — мотивация. Если он способен понять проблему, и начать ее исправлять, то ему не нужны конкретные алгоритмы, он сам запросто подберет себе метод «воспитания» (он сам-то себя лучше знает, и метод выберет наиболее подходящий). Проблема в том, что человек, у которого плохо с дисциплиной (напр. постоянная прокрастинация и т.п.) не начнет это исправлять. Если ему дадут «чудодейственный совет» вида «составляйте список дел и придерживайтесь его», это ничего не изменит. Мог бы он придерживаться плана — делал бы это и без советов. Но он не сможет. Из-за лени/несобранности (когда лень перевешивает мотивацию) либо не будет составлять план, либо не будет его придерживаться.
Мотивация и нужна для того, чтобы перевесить природную лень и начать работать правильно.
scifix
29.01.2016 19:54+5мотивация, мотивация… а интерес то есть? Если нету — никакая мотивация не поможет)
easterism
29.01.2016 23:53+7Уже столько зубов сточено о мотивацию и о способы её поиска, что обсасывать тему не хочется… Поэтому я просто на злобу дня, так сказать по горячим следам:
Самая мощная мотивация, это когда твой сервер упал от нагрузки в последний день месяца, когда кастомерам нужно срочно сдавать отчёты. И вот они все тебе звонят и каждую секунду выносят мозг. А ты не можешь на них забить, потому что они юзают твой собственный сервис и платят за него деньги.
Самая мощная мотивация, это когда электрик случайно перегнул оптику в щитовой в разгар дня и твой сервер стал недоступен. И вот ты сидишь и думаешь, куда срочно перенести 500 гигабайт данных, чтоб тебя не порвали на тряпки.
Самая мощная мотивация, это когда ты понадеялся на перспективного джуниора и залил его модуль на продакшен. А на завтра пытаешься понять, почему все вдруг стало дико тормозить и тебе снова выносят мозг кастомеры (которые еще не остыли от первого случая). И ты сидишь и исправляешь код, который на каждый запрос от клиента генерит 1500 запросов к базе. Сам виноват.
Самая мощная мотивация, это когда провайдер без предупреждения поменял DNS для твоей сети и все запросы к твоим серверам стали вдруг вести в никуда.
Вот когда это наступает, но находятся силы на 24-х часовой режим работы в независимости от возраста.MaxPastukhov
30.01.2016 08:31Как там, в «О чем говорят мужчины»?
Это — не мотивация, это — п… ц! :)MacIn
31.01.2016 22:20+1«И вот когда уже не хочется хотеть чего-нибудь хотеть — это кризис. Нет, это не кризис, это пц».
limon_spb
30.01.2016 01:43+2Забавную мысль тут встретил, что от умственного труда не устают, а устают только от сопутствующих факторов как то: скука, нервное отношение к работе, неудобная поза, чувство бесполезности того, что делаешь, перенапряжение глаз, спины и шеи, и т.п. Понимаю, что топик немного не об этом, но все же интересно узнать мнение.
lair
30.01.2016 02:41+2Если вкратце, то это совсем не так. Более того, умственная деятельность — один из самых энергозатратных процессов в организме.
Toshiro
30.01.2016 06:06+3Умственная деятельность это самый энергозатратный процесс в организме)) Мозг сжирает не менее 20% всей получаемой организмом энергии.
Также серьёзную роль в усталости от умственного труда играет банальный перегрев башки. Мозг выделяет тепло во время работы, как результат химических реакций, чем интенсивнее — тем больше. Для нас это иногда выражается как «мозги кипят», что часто ощущается под конец интенсивного рабочего дня или утром если адский недосып.
История полна примеров людей, которых интеллектуальный труд ушатал намного убойнее чем любой физический. И им не было скучно, наоборот они пахали со страстью к своему делу. Такова жизнь.limon_spb
30.01.2016 12:46+1Интересно, спасибо за мнение вам и lair.
А неужели мозг во время своей обычной активности тратит энергии меньше, чем когда человек занимается чем-то интересным, но полезным?
Я к тому, что, вроде как, мозг человека устроен так, что он не может не думать, и поэтому энергия тратится всегда. А какая разница по сути, о чем думать. Если только нам приходится заставлять себя думать о работе, но тогда это — не интересная работа. А об интересной работе почти всегда думается само, если ничего не отвлекает :-)lair
30.01.2016 12:48+2Я к тому, что, вроде как, мозг человека устроен так, что он не может не думать
Это не так. Мозг вполне может «не думать», используя уже наработанные шаблоны принятия решений.limon_spb
30.01.2016 12:57Получается, что с этой точки зрения, скучная и однообразная работа — от нее устаешь меньше — ведь ты не думаешь, а просто делаешь.
А творческая работа, обучение чему-нибудь — все это интересно, требует больших энергозатрат т.к. влючается необходимость образования новых связей и т.п.
Но на деле все наоборот. От скучной работы устаешь за 5 минут. Причем устаешь даже почти физически — поднимается давление, появляется вялость, головная боль и т.п. А творческой и интересной можно заниматься весь день и даже вечером только силой заставить себя идти спать. Ну вы знаете, наверняка.
И тут что-то не сходится :-)lair
30.01.2016 13:00+3Вы просто путаете «устаешь» и «надоедает». С точки зрения энергопотребления «творческая и интересная работа» утомительнее — она съедает больше ресурсов. Но поскольку вы получаете компенсацию в виде удовлетворения от решения задачи, вы не замечаете этой потери ресурсов — что не отменяет того, что вы их теряете.
limon_spb
30.01.2016 13:07Да, наверное с вашими доводами вынужден согласиться. Наверное, мне еще надо найти какую-то информацию уже из области биологии, где на пальцах объяснят, почему ресурсов от умственной деятельности тратится больше, чем от просмотра сериала.
MaxPastukhov
30.01.2016 08:35Да, дельная мысль.
Допустим, если работать в реально удобной позе (сидя на диване, облокотившись на здоровенный пуфик) перед монитором на уровне глаз и набитым холодильником, в тишине, я мог и сутки отработать, и пойти спать только потому, что просто спать хочется, а не от усталости :)limon_spb
30.01.2016 12:47Я тут с вами согласен, и с тех пор, как я узнал об этой мысли, она не дает мне покоя :-)
Hokum
30.01.2016 13:18и пойти спать только потому, что просто спать хочется, а не от усталости
То что хочется спать это и есть признак усталости :) В конце концов, чтобы обработать полученную информацию нужен сон, т.е. даже получение информации из вне (например фильм посмотреть) вызовет усталость. Но степень усталости будет разной. Можно провести аналогию с мышцами. Например вы идете в течение часа на легке. За этот час вы устанете, но не сильно. А попробуйте бежать в течение часа, или идти с грузом по песку — вы устанете гораздо больше, соотвествено и энергии потратите больше.
Так же и с мозгом все зависит от того на сколько активно приходится обрабатывать информацию. Чем больше новой информации, чем больше приходится что-то сравнивать, анализировать, тем больше будет усталость и затраты энергии.
Где-то попадалась статья, согласно которой, человек лучше отдыхает — быстрее засыпает, «глубже» спит, если физическая и умственная усталость согласованы. Отсюда и рекомендации о физических упражнениях при умственной работе. Насколько это правда — не могу судить, но бывали ситуации когда вечером вроде и устал, но все равно какой-то активный. И кажется, что сейчас лягу, глаза закрою и засну. А сон не приходит — то не устроится удобно, то шум мешает, то что-то почесать захочется, то еще что-то, а если попрыгать, побегать по квартире, то становится лучше :)Wesha
30.01.2016 23:32+2В конце концов, чтобы обработать полученную информацию нужен сон,
Висцеральная теория сна с Вами мягко не соглашается, и утверждает, что сон нужен в первую очередь тогда, когда в организме «клапана начали стучать» и пора бы «мотор остановить и подрегулировать».drafterleo
31.01.2016 00:05+3Я тоже очень уважаю висцеральную теорию сна, однако, мне кажется, всё не столь физиологично. Хотя бы чисто эмпирически — сколько раз такое бывало: вечером упираешься в проблему, тыкаешься в неё как муха в стекло — результат нулевой (если не отрицательный). В конце концов плюёшь, ложишься спать, а после пробуждения, бах — и головоломка сложилась. То, что вчера ускользало от внимания, не схватывалось сознанием, сегодня понимается ясно и отчётливо (и это при том, что мозг, согласно той же висцеральной теории, во время сна, вроде как, не отдыхал).
Wesha
31.01.2016 00:41+3при том, что мозг, согласно той же висцеральной теории, во время сна, вроде как, не отдыхал
Во-первых, мозг таки отдыхал — теория говорит, что то, что все называют «медленным сном» — это «обход» внутренностей, а «быстрый сон» — это когда мозг работает сам над собой («а я чё, я же тоже внутренний орган!»). Во-вторых, я могу предположить, что мешает не столько что-то внешнее, сколько зацикленность мыслей на уже отброшенных решениях, а утром — когда «кэш чистый» — тут сразу и находится ответ.
А в целом да, «синдром (таблицы) Менделеева» я сам ощущал неоднократно.
Hokum
31.01.2016 00:42+1Спасибо, не слышал о висцернальной теории сна.
Wesha
31.01.2016 00:49+3По моему личному мнению (и опыту), некоторыми (косвенными) признаками правильности теории являются: а) её [внешняя] простота, и б) тот факт, что она внезапно объясняет и/или предсказывает то, что её автор, собственно говоря, объяснять и предсказывать вовсе и не собирался. Висцеральная теория, как мне кажется, этими признаками обладает.
(Но, поскольку я не профессиональный учёный, всё вышесказанное — моё особое личное мнение, и т.д и т.п.)
Toshiro
30.01.2016 04:00+7«Вот ещё кое-что, чего я не понимаю — кассеты для повышения мотивации, книги для повышения мотивации. Че это за херня? Что, всем вдруг понадобилась дополнительная мотивация?
Ведь всё же просто — вы либо хотите [что-то делать] либо нет, в чём загвоздка? К тому же, если вам хватило мотивации, чтобы пойти в магазин и купить эту книгу, может вы уже достаточно мотивированы и вам больше не нужна книга? Положите её на место, скажите клерку — »Иди нахуй! Я мотивирован!"
(с) Джордж Карлин
IFITOWS
30.01.2016 17:01+1Для меня одна из лучших статей по прикладной психологии. Большое человеческое спасибо!
Mixim333
30.01.2016 17:25«Универсальные решения сложнее конкретных» — в прошлом году нужно было реализовать приложение, которое очень активно работает с Oracle'овой БД. Мне не хотелось писать в каждом методе «AddParameter(...)» для добавления параметров в вызываемую SQL-функцию\процедуру, я решил потратить неделю и написать свою «DatabaseLib» — в итоге получилась небольшая, но функциональная библиотека, реализующая некоторые возможности огромных ORM вроде NHibernate, которую я использую снова и снова (сейчас она без проблем работает и с SQL Server, требуется лишь в конструкторе указать соответствующий параметр), так что универсальное писать сложнее, но оно лучше
miktim
31.01.2016 09:27+1О самомотвации:
— Ты программист?
— ???
— Жрать хочешь?
— …
— Вот тебе ТЗ и сроки — иди самовыражайся.
PPCore
31.01.2016 10:01+1Отличные практические методики. Слова зрелого человека и профессионала. И по боку критиков :)
nomit
31.01.2016 10:41Для 7-го пункта «Поддержание состояния потока», очень хорошо подходят Unity тесты, ты моментально получаешь рабочий(хоть и в достаточно узких рамках) код, видишь его работу, видишь проблемные места(хоть и не все), и это очень мотивирует как вы и сказали.
MrEsp
31.01.2016 18:12Имхо, автор достаточно тонко познал наше искусство, спасибо за статью. Согласен со всеми пунктами кроме 4. Вообще, пункты 4 и 10 — они наиболее сложны и противоречивы.
Основных проблем с этими пунктами 2: 1) программирование и написание кода в частности не стандартизированная дисциплина, it can vary 2) Многие программисты — самоучки, в сильном смысле слова. собственный опыт более ограничен, чем совокупность чужого.
Tanabe
02.02.2016 11:19+2Человек не управляется «мотивацией».
Человек управляется «интересом».
Мотивация, в том смысле, как ее начали использовать — это попытка найти дорожку, связь, между тем, что человека интересует, к чему он стремится, сам по себе, и тем, что человек делает или должен делать.
Но впоследствии именно этот смысл потерялся и под мотивацией начали понимать «как бы заставить (себя или другого) делать то, что _требуется_». Вот так мотивация — не работает.
В первоначальном смысле — еще может быть. Как только человек _осознает_, что он хочет и каким образом, цепочкой каких действий он может это получать — он начинает быть мотивирован этим. Если правильнее — в этом будет заключаться _мотив_, почему он этой деятельностью занимается. Сам занимается, а не из-под палки.
Сейчас же «мотивацию» рассматривают как одну из таких палок :)
В качестве простого примера — человеку может хотеться находиться на море и теплом песочке, для чего нужны деньги, для чего он пошел работать (в то место, где получает больше денег и меньше для этого напрягается). И тогда этот человек в рамках работы мотивирован деньгами и его можно мотивировать деньгами в рамках этой работы (премии, сверхурочные и т.п.).
И в этом же есть «второй конец палки» — человек всегда будет искать самый эффективный и самый короткий путь для реализации своего интереса (желания, потребности). А значит, его мотивация может достаточно быстро и серьезно меняться. Если брать приведенный выше пример, то в какой-то момент человек вдруг поймет, что способен просто переселиться туда, к морю, насовсем. И никакой «мотивацией» тогда его на этой работе не удержать — он ее оставит и уедет.
Поэтому, если у человека возникают проблемы с «мотивацией» того, чем он занимается, то первое, с чего ему следует начать — это разобраться в себе и выяснить, чего же ему на самом деле хочется, в чем его интерес (или потребность — зависит от уровня). В этой ситуации выяснить, потому что прошлые интересы уже могут не подходить, человек уже может измениться.
Потом посмотреть каким образом можно получать это в своей жизни. И тут не только про «логический вывод», но и про «посмотреть внутрь себя».
И вот тогда определить, является ли то, чем человек занимается, достаточно эффективным путем к тому, что он хочет, к тому, к чему он стремится, в чем его реальный интерес.
Большинство из этого работает на бессознательном уровне, а его нельзя обмануть — оно просто «видит», как все обстоит на самом деле.
Если же пробовать обмануть, то пойдет сопротивление — сначала в виде «лени» и «рассеянного внимания», потом в виде «прокрастинации», а потом и соматические симптомы могут проявиться. Для программистов и близлежащих профессий это (соматические симптомы) часто «ВСД» — перенапряжение шейного и плечевого пояса, затрудняющее кровоснабжение мозга, в результате чего мозг недостаточно снабжается кислородом, в результате чего он перестает мочь _думать_. В качестве симптомов — головные боли, «ватная голова», головокружение, тошнота и т.д. вплоть до обмороков.
Что касается упомянутой выше «дисциплины» — то тут тоже самое, что и абзацем выше.
В йоге (в которой очень много этой самой дисциплины, ее наработки и т.д.) разделяют два понятия: «Усилие» и «НАсилие». Все, что человек может сделать, совершается только через Усилие. Но если вместо этого человек совершает над собой НАсилие, то никакого результата, кроме «травмы», он не сможет получить.MaxPastukhov
02.02.2016 16:23+2Абрахам Маслоу «Мотивация и личность» — рекомендую почитать на досуге.
Можно сколько угодно пытаться построить упрощенные модели поведения и мотивации человека, только на практике — все гораздо сложнее.
Именно поэтому я не пытаюсь построить очередную оторванную от жизни модель, а всего лишь пользуюсь «лайфхаками», проверенными на своей практике.Tanabe
02.02.2016 17:40+1Спасибо, но я думаю рекомендации что-то почитать в области психологии человеку, который имеет не только образование в этой области, но еще и опыт работы — в данном случае, явно излишни. Поэтому, пожалуйста, не нужно мне про «сложность на практике»: практика конкретного человека — лишь частный случай много более сложной теории.
Поэтому я просто кратко повторю основную мысль — без интереса никакой «мотивации» не будет, ни один «лайфхак» и «опыт другого» никак не это не повлияют.
То, что описываете вы, позволяет лишь структурировать и упорядочить деятельность в условиях наличия интереса. Но ключ — именно в нем, в интересе, и вы об этом никак не пишите (собственно, сейчас об этом и не пишут обычно).
Если у человека «вопрос мотивации» — то ему надо начать с прояснения своих стремлений, а с упорядочивания начинать не надо — это часто приводит к тому, что человек за деревьями перестает видеть лес.
Собственно, ничего противоречащего разделу «Цель и средство» главы 3 «Мотивация и личность» Маслоу я не написал:
«Все вышеизложенное заставляет нас сформулировать одно очень важное требование, которое необходимо учитывать при построении мотивационной теории. Поскольку базовые цели не всегда представлены в сознании, то нам придется иметь дело с очень сложной проблемой – с проблемой бессознательного. Изучение только сознательной мотивации, даже самое тщательное, оставляет за рамками рассмотрения очень многие человеческие мотивы, которые не менее, а, быть может, и более важны, чем те, что представлены в сознании. Психоанализ неоднократно демонстрировал нам, что связь между осознаваемым желанием и лежащей в его основе базовой неосознаваемой целью не обязательно прямолинейна. Эта взаимосвязь может быть даже отрицательной, как это бывает в случае реактивных образований. Таким образом, мы должны признать, что отрицание роли бессознательного делает невозможным построение теории мотивации».
Сначала — разобраться в «базовой неосознаваемой цели».MaxPastukhov
02.02.2016 17:57Спасибо, всегда интересно поговорить с практиком :)
Из той же книги: «И все же в определенных целях самоконтроль, или торможение, или определенные их моменты носят желательный и здоровый характер, не говоря уж об их необходимости, когда приходится иметь дело с внешним миром… не призывает поставить под вопрос удовлетворение потребностей: скорее, это возможность получить от их удовлетворения еще большее наслаждение...»
Я не спорю с мыслью о том, что нужен и важен внутренний интерес. Я, будучи сам увлеченным программистом, даже не задумываюсь над тем, кто кто-то выполняет эту работу из-под палки. Но, как и в любой работе, выполняемой в реальном мире, всегда будут задачи, которые «пациенту» не по душе. И цель искусственного возбуждения и поддержания мотивации — в возможности «перепрыгнуть» через эти геморройные задачи ради продолжения интересной работы.
Собственно, если кто-то занимается прямо сейчас интересной задачей, он и статью эту читать не будет.
И, действительно, если мои советы применит человек, работающий ради чужих целей, а не своих, внутренних, он не станет счастливее. С другой стороны, это может помочь ему все-таки приступить к работе и, возможно, он найдет в ней что-нибудь интересное лично для него. Я с этим регулярно сталкиваюсь, к слову. Пытаюсь, конечно, минимизировать объем геморройных задач в своей работе. Но, к сожалению, это не всегда получается в реальном мире.Tanabe
02.02.2016 18:11+1:)
Примерно про то же, про что эта цитата, был мой последний абзац — про «усилие» и «насилие». Безусловно, что без усилия мало что случается в этом мире.
Просто желательно быть внимательным к себе, чтобы разглядеть, где это начинает переходить в «насилие».
И второй момент: он как раз хорошо связан с Маслоу, а именно — с его «пирамидой потребностей». На ней хорошо видно, какие вещи на каком уровне могут мотивировать человека. И тут тоже важно быть внимательным к себе, чтобы распознать, когда «базовый мотив» уже изменился, а человек все еще действует следуя логике когда-то сделанных для себя выводов (уже действуя, по-сути, против себя).
Вы в начале статьи написали про семью, про старшую дочь — возможно, что это не «помехи мотивации», а как раз изменение вашей мотивации? :)
А как инструменты оптимизации — безусловно, много верного написали.
Ramires
Мне кажется, что стоит научиться относится к критике спокойно и со стороны логики, а не чувств. Прислушиваясь к хорошей критике можно сильно поднять свой профессиональный уровень. Если критика необоснованная ( а это уже тогда не критика, а троллинг какой-то ) — просто игнорировать её.
Тут же вы предлагаете наоборот расценивать критику как персональное нападение на вас.
MaxPastukhov
Что лучше: услышать объективную критику и потерять мотивацию к продолжению проекта, или не услышать ее, и реализовать ровно то, о чем говорит критик, только чуть позже, уже своим умом? Чаще всего критик не говорит чего-то нового, он лишь озвучивает то, что ты и так знаешь: в любом новом и сыром проекте есть тонна мелочей, к которым можно вполне себе объективно придраться.
lair
А почему объективная критика лишает вас мотивации? Так не должно быть.
А вы уверены, что вы реализуете (а) ровно то же и (б) «чуть» позже, а не через два года? А у проектов еще и конкретные сроки бывают ведь.
MaxPastukhov
Мы не говорим о том, что мы «должны», мы говорим о том, что лично для меня реально работает. Если кто-то может спокойно воспринимать критику и от этого не теряет мотивацию… ну памятник ему нужно поставить, значит. Среди моих знакомых и сотрудников я таких не видел. Даже если человек делает вид, что ему насрать на критику, обратное сразу видно по результатам его работы.
Не уверен. Но, если я не реализую что-то реально нужное, или не так, как это реально нужно, мне еще не раз об этом напомнят. Реальные пользователи продукта, а не левые люди. Я разделяю «продуктовую критику» — фидбек реального пользователя и «критику процесса», когда кто-то критикует еще не выпущенный продукт просто потому, что «знает, как правильно, а у тебя все — неправильно!!!1111»
К фидбеку реального пользователя, к слову, стоит тоже относиться скептически: если одному пользователю что-то не нравится, это еще не повод переделывать продукт. Проходил это на практике и могу с полной ответственностью сказать, что это — реально хреновая стратегия.
lair
На мой взгляд, наоборот. Если кто-то не может спокойно воспринимать (конструктивную) критику, ему не место в отрасли, в которой его критикуют. Это просто непрофессионально. Собственно, все обучение построено на критике.
… вот только уже поздно будет.
А где в этом разделении найти code review и design review?
Пока из ваших слов получается, что вы ко всему фидбеку «относитесь скептически». Впрочем, оно и по реакции на комменты к статье видно.
MaxPastukhov
На критике или на помощи? Если вы будете постоянно критиковать своих сотрудников, они будут бояться даже в туалет сходить без вашего высочайшего разрешения. Проверено, к слову. Мной, к сожалению :)
Настоящая помощь не выглядит как критика: вместо того, чтобы ткнуть носом человека в его ошибку, лучше подвести его к этой мысли менее болезненно. Так, чтобы это не выглядело как помощь, и было помощью.
Поздно для чего? Я лично продаю разработанные мной проекты уже с 2005 года. Лично общаюсь со своими пользователями, в том числе и вживую. По своему опыту могу сказать, что пользователи больше ценят сырой проект прямо сейчас, нежели отполированный — через год.
В нашей индустрии есть миф о том, что одна маленькая ошибка может убить большой бизнес. Да хер там, все были бы уже мертвы :)
Мы сейчас обсуждаем конкретные методы самомотивации конкретного программиста, а не управление проектами. Я не пытаюсь рассуждать о тех делах, в которых у меня — недостаточно опыта.
Да, повторю еще раз: любой критик — зло, даже если он уверен в обратном. И я говорю это с позиции практика, а не теоретика.
lair
На критике, конечно. Помощь включает в себя критику, кстати.
Ну во-первых, критика не обязаны выглядеть как «тыканье носом». Но, во-вторых, иногда без этого просто нельзя.
Грубо говоря, если человек в своем коде нарушает, скажем, гайдлайны по безопасности, и это ведет к дыре в безопасности продукта, мне, как ответственному за выпуск продукта, надо, чтобы он перестал это делать. И в любом случае это будет критика того, что он написал — вопрос только в том, как именно она будет сформулирована. Быть критикой она не перестанет.
И если такой программист в ответ на критику теряет мотивацию и перестает работать — зачем он мне вообще такой нужен тогда?
Проблема в том, что ваши конкретные методы не вписываются в командную работу.
Зло для вас лично. Мой — практический, что характерно — опыт говорит строго обратное.
MaxPastukhov
Просто попробуйте не критиковать девелоперов, а помогать им. Смысл спорить, если у нас — разные подходы к людям?
Скажу лишь, что я пробовал и позицию критика, и позицию помощника. И помощнику, по факту, гораздо проще донести нужную и важную информацию до слушателя, нежели критику: когда на нас нападают, мы становимся в защитную позицию. Причем не просто «донести» (тогда человек может лишь сделать вид, что он принял твою точку зрения, поскольку не захотел с тобой конфликтовать), а получить подтверждение того, что он ее понял и принял. И, более того — получить в ответ его опыт. Который, возможно, и отличается от того, что ты считаешь единственно правильным решением.
Те же гайдлайны по безопасности: сам подумай, мог бы ты донести эту информацию до человека так, чтобы это не выглядело как критика? Допустим, в виде митинга, на котором ты озвучишь ее для всех членов команды, а не для конкретного «нарушителя»? Может, тогда он и не будет воспринимать твои слова в штыки? Может, он не «виноват», а просто не знал об этом?
Не помню, у кого услышал: «Хвали всегда — конкретного человека, ругай всегда — толпу»
lair
Это требует существенно больше моего времени и не ведет к повышению уровня тех самых «девелоперов».
А не надо воспринимать критику, как нападение, от которого надо защищаться.
Угу, он и продолжит «просто не знать». Сказанное на митингах сказано всем, а значит — никому. Никто не принимает на свой счет, никто не идет переписывать свой код (особенно написанный две недели назад и, значит, успешно забытый).
Более того, митинги делятся на две категории: на одной слушают, на второй обсуждают. Если просто слушать, а не обсуждать, то это, опять-таки, сводится к авторитарному навязыванию своей позиции. А если обсуждать, то в итоге будет та же самая критика.
lair
Ну то есть от практики code review вы все-таки предлагаете отказаться?
MacIn
Судя по всему, речь о единоличной разработке, а не командной. В командной хочешь-не хочешь будешь слушать критику, это надо — с твоим кодом будут работать другие.
utkorose
+ в комманде все в теме, и понятно, почему остальные критикуют. Автор поста не о том писал. Просто у нас и критику принимать не умеют, и критиковать. Я от человека со стороны, пусть и в теме, всякое слышал. Лучше избегать всего этого. Несвязанные с делом люди пусть покритикуют результаты, но не недоделки. В комманде критику нужно и важно воспринимать.
sentyaev
Очень похоже, что вы используете слово «критика» в значении — ругать, осуждать. lair же, как мне кажется, использует в значении — провести анализ, дать оценку и т.д.
iamAnton
> А почему объективная критика лишает вас мотивации? Так не должно быть.
Так не должно быть, но так есть.
lair
Людям, у которых «так есть», я искренне и настоятельно рекомендую это менять.
bak
А у вас такого вообще нет? Приведу следующий простой пример. Вы начали пилить велосипед (изучили существующие решения, и не нашли подходящего). Вам в качестве критики (конструктивной!) дали ссылку на библиотеку, которая делает всё тоже самое и решает поставленную задачу, и полностью вам подходит. Но вы уже процентов на 75 написал свою. Вы хорошо разбираетесь в предметной области, и написали (почти написали) хорошую библиотеку (с кучей юнит тестов, потратив большое количество времени).
Неужели после данной конструктивной критики у вас абсолютно не изменится мотивация? Не начнут посещать мысли, вроде «гм, кажется я плохо подошел к выбору библиотеки и зря решил свою писать, оказывается уже такая есть»?.. И вообще — продолжите ли вы её дописывать? Если нет — то получается что мотивация у вас пропала. Если да — то тот факт, что вместо уникального и полезного людям продукта (библиотеки) вы напишете очередной велосипед, на вас абсолютно никак не повлияет? Вроде «ну подумаешь месяц пилил полезную и нужную тулзень, а теперь пилю никому не нужный велосипед, ну и что с того — как пилил так и буду, у меня всё круто», так что ли?
lair
У меня такое есть — в тех областях, где я не чувствую себя достаточно уверенно.
У меня не пропала мотивация работать или мотивация завершить конкретный проект, внутри которого мне зачем-то понадобился этот велосипед. А то, что мне расхотелось тратить свое время на объективно ненужную вещь — это же хорошо?
Более того, я с таким больше одного раза сталкивался — и каждый раз я большей частью испытываю облегчение и радость, что мне не надо больше возиться со вспомогательным кодом.
bak
И, тем не менее, это же не отменяет факта что у вас пропала мотивация писать библиотеку? Ни в коей мере не хочу сказать что это плохо, всего лишь пример того, как критика лишает мотивации.
lair
С точки зрения буквы высказывания я с вами соглашусь, у меня действительно пропала мотивация писать библиотеку. Но вот по духу высказывания все сложнее.
Во-первых, меня, как профессионала, не интересует мотивация писать библиотеку, мне интересна мотивация решить задачу — каковая задача, в худшем случае, поставлена как «предоставить код, реализующий функциональность», а в лучшем — «реализовать такую-то бизнес-задачу» (постановку задачи «написать библиотеку» мы считаем некорректной в общем случае). И эта мотивация никуда не пропала.
Во-вторых, в статье явно прослеживается логика «мотивация — хорошо > критика лишает мотивации > критика — плохо > избегайте критики». В вашем же примере видно, что критика принесла нам новое знание, которое позволило решить исходную задачу лучше. Из этого надо извлечь самоудовлетворение («я нашел наиболее эффективный способ решить задачу»), а из того — мотивацию для дальнейшей работы.
Wesha
lair
А почему вы считаете, что юнит-тесты не покрывают некорректные ситуации?
Wesha
По Третьему закон ненадёжности Джилба («Число ошибок, которое можно обнаружить, конечно. В противовес числу ошибок, которые нельзя обнаружить: оно бесконечно по определению.»)
lair
А как вы предлагаете разрабатывать под некорректную ситуацию, принимая во внимание этот закон?
Wesha
Я просто говорю, что тесты — не панацея: тот факт, что все тесты проходят, не означает, что всё 100% отлично.
А панацеи как таковой — нету её.
lair
Вы просто противопоставляете тесты и разработку под некорректную ситуацию — хотя практически все (а в большей части ситуаций — вообще все) некорректные ситуации, под которые можно разработать, можно (и нужно) и протестировать.
Wesha
В теории Вы абсолютно правы — но на практике я в большинстве случаев вижу, что люди пишут «положительные» тесты («функция должна вернуть то, что я от неё ожидаю при таких-то параметрах»), а не «отрицательные» («функция должна выбросить ошибку при левых параметрах»).
lair
Ну и что? Это как-то мешает им разрабатывать и под некорректные ситуации в том числе?
(а «люди» во многом правы — сначала надо фиксировать в тестах happy path, потом альтернативные ветки, и только потом ошибочные сценарии)
Wesha
Так я и говорю — физически ничто не мешает, но почему-то unhappy-path-тесты я практически не вижу. Наверное, лень мешает, или что-то ещё.
(Если это было не очевидно с моего первого комментария: я жалуюсь не на тесты, я жалуюсь на писателей тестов.)
lair
Еще раз: как из того факта, что вы не видите тестов на ошибочные сценарии, следует, что код их не учитывает?
Wesha
Из «того факта, что вы не видите тестов на ошибочные сценарии» это не следует. Но я ведь и код вижу тоже (как код наших компанейских проектов, так и код статысячмиллионов проектов на гитхабе).
lair
А теперь внимание, вопрос: если убрать из проекта тесты на happy path, в нем магическим образом появится обработка ошибочных сценариев?
Wesha
А кто предлагал их убрать???
Ещё раз: я жалуюсь не на тесты, я жалуюсь на писателей тестов, которые почему-то поголовно забывают про unhappy path.
lair
Просто ответьте на мой вопрос.
VolCh
Эти люди или не практикуют принцип test-first, если функция (сама) таки выкидывает ошибку при левых параметрах, или не обладают этим левым набором параметров.
sentyaev
Это же прекрасно! Вы сможете использовать стандартную библиотеку, плюс возможно добавить в нее свои наработки.
Ramires
Придраться — это всегда необъективно.
Если объективная критика представляет настолько убойные аргументы ( пример: «нельзя написать на PHP операционную систему потому, что 1)… 2)… 3) ...» ), что сразу отказываешься от проекта. Не знаю, возможно, действительно стоит отказаться.
Если же это необъективные придирки ( «да ты не осилишь — запутаешься в логике» ), то после их прослушивания вряд ли откажешься от проекта.
MaxPastukhov
Я больше имел в виду придирки к качеству кода и интерфейса: всегда можно найти кучу ляпов в процессе разработки. Что же до критики концепций, то тут, мне кажется, все определяется рынком: если кому-то захочется сделать ос на пхп… ну есть же Андроид, в конце концов :) Мощности — растут, пхп-шные библиотеки — тоже, так что не зарекаемся :) Завтра кто-нибудь релизнет, выйдет на айпо, а мы будем локти кусать :)
vikarti
Мне вот тоже казалось что нельзя же сделать ОС на C# и чисто нем — а потом пришлось узнать Singularity от MS Research где даже ядро и драйвера — на C#. Даже есть свои преимущества.