Да, мне — не 54 года, а «всего» 36. Но, честно говоря, уже достаточно сложно работать по 20-30 часов подряд. Не потому, что «не хочется», а потому, что «тяжело». И старшая дочь уже практически взрослая, и не всегда выбор между временем с семьей и очередным проектом заканчивается в пользу кодинга.
Я бы хотел поговорить об основном «двигателе» нашей работы — мотивации. Я знаю, что отнюдь не все айтишники доверяют психологии, считая ее «бульварной наукой». Даже не наукой, а сводом анекдотических историй и статистически недостоверных догадок.
Лично у меня к психологии подход следующий: если что-то работает — не трогай, даже если ты и не знаешь лежащих в основе этой «магии» механизмов. Я стараюсь просто пробовать все, что я прочитаю по этой теме лично для себя, оставляя лишь реально эффективные лично для меня методы и принципы. А их, к слову, в психологии более, чем достаточно:
1. Для мотивации, кроме внутреннего желания и внешних дедлайнов, требуется еще и зритель
Если не хочешь «закиснуть», нужно показывать свою работу хоть кому-нибудь. Даже не важно, будет ли он оценивать ее качество. Важно, чтобы он просто заметил ее, хотя бы в формате: «да, вижу, отвали...» Подойдет абсолютно любой человек, даже не обязательно будущий пользователь продукта. Даже жена — не айтишник :)
2. Мотивация приходит с результатами и умирает без них
Чем быстрее ты релизнул что-то, тем больше у тебя мотивации продолжать этот проект. Если бесконечно затягивать релиз, мотивация исчезнет сама собой. Причем гораздо быстрее, чем ты ожидаешь.
Лучший мотиватор — прямо сейчас релизнуть хоть что-нибудь и с ужасом понять, что кто-то прямо сейчас может скачать или зайти на этот бред. Напоминает детские ощущения вида: «Блииин, бардак в комнате, а мама вернется через 15 минут...» Желание править баги и допиливать недостающий функционал возникает моментально :)
3. Мотивация редко возникает из ниоткуда, но она автоматически приходит с началом работы
Если вдохновение пришло — отлично! Нужно немедленно садиться и работать. Но, если вдохновения все еще нет, бессмысленно ждать, пока оно появится само собой. Теоретически могла бы помочь сила воли: начав что-то делать, мы автоматически втягиваемся. Но силы воли не всегда хватает, к сожалению.
Лично я в этом случае использую метод «утаптывания травы»: открываю проект, подготавливаю нужные файлы, начинаю разбираться понемногу в деталях. Чем больше я погружаюсь в задачу, хотя бы теоретически или в процессе подготовки к ее выполнению, тем больше мотивации ее продолжать. Причем «прорыв» происходит, чаще всего, неожиданно — увлекаешься какой-нибудь мелочью будущего проекта, садишься реализовывать именно ее — и втягиваешься :)
Еще помогают «размышления на бумаге»: просто создаю новую заметку, и начинаю своими словами описывать будущий проект и его детали.
4. Критик — убийца мотивации, его можно и нужно наказывать
Не позволяйте никому критиковать вашу работу, особенно если она еще далеко от совершенства. Если не получается избегать этих людей, представляйте их в виде злых монстров, чье мнение — не слова, а стрелы, от которых вы уклоняетесь.
5. Режим дня и регулярный спорт повышают мотивацию к любой работе
Проверено не раз: если я не засиживаюсь по ночам, встаю в одно и то же время, и хотя бы пару раз в неделю бегаю в ненапряжном режиме час на орбитреке параллельно с просмотром интересного фильма, у меня появляется мотивация даже к самой геморройной работе. И, наоборот: как только я ленюсь заниматься спортом или устраиваю ночные «заплывы» в интересный проект, мотивация через несколько дней падает практически в ноль.
6. Снижаем планку
Если ты будешь ругать ребенка за первые неуклюжие рисунки, он никогда не станет великим художником. Ребенок делает первые детские шаги — он и должен делать первые, именно детские, шаги. Можно и нужно позволять себе делать работу «тяп-ляп» при старте любого проекта — качество приходит с практикой, а в погоне за перфекционизмом объем практики резко снижается.
Прокрастинация — на самом деле, страх, а не лень. Страх сделать что-то не так: нам больше нравится получать мелкие текущие победы ценой большого будущего поражения (казино, форекс, курение), нежели терять понемногу каждый день, но скомпенсировать это большим будущим призом. Так вот, снижение планки — это именно мелкие «поражения» на старте проекта, которые оборачиваются в итоге победой в лице его реального развития и «полировки» в процессе, а не откладыванием его в долгий ящик.
7. Поддержание состояния потока
Программирование — один из немногих видов деятельности, позволяющий входить в состояние потока (еще есть музыка, вождение автомобиля, компьютерные игры и некоторые виды спорта). Этим стоит пользоваться, понимая принципы входа и выхода из него: для входа требуется получать немедленный фидбек от простых действий, для выхода достаточно любого внешнего дистрактора.
Соответственно, вместо часового написания кода без компиляции и запуска, стоит разделить все на короткие 5-минутки с немедленным запуском частичного готового кода и проверки хотя бы частичной его работы. Просто попробуйте, если еще не делаете этого :) Лично я вообще запускаю проект чуть ли не каждую минуту, когда пишу что-то новое и короткое.
Если ты пытаешься спроектировать свой проект с самого начала и до мельчайших деталей, ты лишаешь себя мотивации в процессе его будущей реализации: всю креативную и интересную работу ты уже выполнил, и остается лишь тупой кодинг. Так что проектировать лучше все-таки лишь в общих чертах, оставляя себе конкретные детали реализации на «практический десерт».
Ну а для избежания выхода из состояния потока нужно убрать все отвлекающие факторы: программировать «запойно», по нескольку часов подряд, пока хватает сил и желания. Лучше переработать, но сделать работу за неделю вперед, нежели выжимать ее из себя в час по чайной ложке. Отключить телефон, закрыть скайп, браузер и контактик. Сотрудников стоит приучать к тому, что несрочные вопросы должны решаться исключительно по почте. Музыка, к слову, тоже мешает — быстро утомляет.
8. Мы не любим чужой код
Это — понятно, но даже наш собственный код примерно через полгода становится «чужим». Чтобы избежать необходимости разбираться в «своем чужом коде», стоит минимизировать зависимости внутри него, оставляя простейшие «черные ящики» с минимальным функционалом, чтобы не пришлось в них снова влезать. Иногда гораздо проще выкинуть такой мелкий «черный ящик», нежели разбираться, что ты там накреативил пару лет назад :)
Мы всегда понимаем, насколько тупой и кривой код написали пару лет назад, но редко думаем о том, что наш текущий код — такой же тупой и кривой с точки зрения нас же, но из будущего.
И еще: всегда будет соблазн «освежить» старый код, переписать его. Не стоит: все равно через пару лет он снова превратится в тупой и кривой. Мотивацию лучше использовать для написания нового кода, а переписывание старого — как «стартер» в моменты, когда мотивации еще нет. Втянулись в работу? Отлично! Откладываем старый код, пишем новый.
9. Мы не любим чужие библиотеки
Любая «реюзабельная» библиотека — бомба замедленного действия. В новом проекте ты по-любому будешь расширять и изменять ее, тем самым ломая старые проекты. Причем незаметно, поскольку ты их не касался уже несколько месяцев, и не коснешься, возможно, еще очень долго. Нет ничего хуже, когда нужно срочно допилить что-то мелкое в старом проекте, а он тупо не компилируется.
Каждый новый проект должен иметь свою, отдельную копию библиотек, даже если этим ты жертвуешь перекрестным баг-фиксом. Если в старом проекте очевидный баг в либе не мешает, да ну и хрен с ним! Попытка разобраться в своих же старых либах, а уже тем более переписать их с учетом новых знаний и опыта способна сожрать любое время и любую мотивацию.
Вместо создания библиотек лучше расширять язык, в C# — extention methods. Вместо библиотеки сжатия/шифрации лучше сделать один раз extention Compress/Encrypt и использовать его с помощью подсказок среды программирования, не задумываясь о его внутренней реализации и не вспоминая каждый раз, откуда брать пресловутую библиотеку.
Постепенно копится мега-либа расширений, которая просто линкуется к любому проекту и расширяется по мере необходимости, обеспечивая реюзабельность кода на уровне простейших «кирпичиков». Тут важно лишь помнить о том, что старый код трогать не стоит, чтобы не порушить старые проекты. Вместо расширения параметров функции лучше сделать новую, а старая пусть лежит, как есть.
10. Универсальные решения сложнее конкретных
Банальность, но все-таки: в погоне за разработкой универсальных алгоритмов и фреймворков мы лишаем себя простых и очевидных решений, доступных в контексте текущей задачи. Вместо «универсального списка последних просмотренных элементов» лучше сделать конкретный список последних документов текущего проекта. На практике гораздо проще скопипастить код из прошлого проекта и модифицировать его под нужды нового, нежели поддерживать универсальную либу.
Мотивация — это как топливо. Если ее потратить на излишнюю работу по универсализации чего-либо, ее не останется на реально важную работу.
11. Мотивацию нужно ценить и пользоваться ей по-полной
Если хочется сделать что-то важное прямо сейчас — сядь и сделай. Наилучшие результаты приходят со срочным выполнением не срочной, но важной работы, а не срочной и важной (тогда ты просто «догоняешь» текущую ситуацию), и уж тем более не из-за работы над чем-нибудь не срочным и не важным. Да, ты будешь иногда опаздывать, но большая часть кажущихся нам серьезных последствий откладывания срочной работы на практике оказываются не столь уж и серьезными.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий