Практичні методи самомотивації програміста

Навіяно habrahabr.ru/company/infopulse/blog/275951

Так, мені — не 54 роки, а «всього» 36. Але, чесно кажучи, вже досить складно працювати по 20-30 годин поспіль. Не тому, що «не хочеться», а тому, що «важко». І старша дочка вже майже доросла, і не завжди вибір між часом з сім'єю і черговим проектом закінчується на користь кодинга.

Я б хотів поговорити про основному «двигуні» нашої роботи — мотивації. Я знаю, що аж ніяк не всі айтішники довіряють психології, вважаючи її «бульварної наукою». Навіть не наукою, а склепінням анекдотичних історій і статистично недостовірних припущень.

Особисто у мене до психології підхід такий: якщо щось працює — не чіпай, навіть якщо ти і не знаєш що лежать в основі цієї «магії» механізмів. Я просто намагаюся пробувати все, що я прочитаю з цієї теми особисто для себе, залишаючи лише реально ефективні особисто для мене методи і принципи. А їх, до речі, в психології більш, ніж достатньо:

1. Для мотивації, крім внутрішнього бажання і зовнішніх дедлайнів, потрібно ще й глядач

Якщо не хочеш «закиснути», потрібно показувати свою роботу хоч кому-небудь. Навіть не важливо, чи буде він оцінювати її якість. Важливо, щоб він просто не помітив її, хоча б у форматі: «так, бачу, відвали...» Підійде абсолютно будь-яка людина, навіть не обов'язково майбутній користувач продукту. Навіть дружина — не айтішник :)

2. Мотивація приходить з результатами і вмирає без них

Чим швидше ти релизнул щось, тим більше у тебе мотивації продовжувати цей проект. Якщо нескінченно затягувати реліз, мотивація зникне сама собою. Причому набагато швидше, ніж ти очікуєш.

Найкращий мотиватор — прямо зараз релизнуть хоч що-небудь і з жахом зрозуміти, що хтось зараз може завантажити або зайти на цю маячню. Нагадує дитячі відчуття виду: «Блииин, бардак в кімнаті, а мама повернеться через 15 хвилин...» Бажання правити баги і допілівать відсутній функціонал виникає моментально :)

3. Мотивація рідко виникає з нізвідки, але вона автоматично приходить з початком роботи

Якщо натхнення прийшло — відмінно! Потрібно негайно сідати і працювати. Але, якщо натхнення немає, безглуздо чекати, поки воно з'явиться само собою. Теоретично могла б допомогти сила волі: почавши щось робити, ми автоматично втягуємося. Але сили волі не завжди вистачає, на жаль.

Особисто я в цьому випадку використовую метод «утаптывания трави»: відкриваю проект, готую потрібні файли, починаю потроху розбиратися в деталях. Чим більше я поринаю в задачу, хоча б теоретично або в процесі підготовки до її виконання, тим більше мотивації її продовжувати. Причому «прорив» відбувається, найчастіше, несподівано — захоплюєшся який-небудь дрібницею майбутнього проекту, сідаєш реалізовувати саме її — і втягуєшся :)

Ще допомагають «роздуми на папері»: просто створюю нову замітку, і починаю своїми словами описувати майбутній проект і його деталі.

4. Критик — вбивця мотивації, його можна і потрібно карати

Не дозволяйте нікому критикувати вашу роботу, особливо якщо вона ще далеко від досконалості. Якщо не виходить уникати цих людей, уявляйте їх у вигляді злих монстрів, чия думка — не слова, а стріли, від яких ви ухиляєтеся.

5. Режим дня і регулярний спорт підвищують мотивацію до будь-якої роботи

Перевірено не раз: якщо я не засиджуюся ночами, встаю в один і той же час, і хоча б пару разів на тиждень бігаю в ненапряжном режимі годину на орбітреку паралельно з переглядом цікавого фільму, у мене з'являється мотивація навіть до самої геморройной роботі. І, навпаки: як тільки я лінуюся займатися спортом або влаштовую нічні «запливи» у цікавий проект, мотивація через кілька днів падає практично в нуль.

6. Знижуємо планку

Якщо ти будеш лаяти дитину за перші незграбні малюнки, він ніколи не стане великим художником. Дитина робить перші дитячі кроки — він і повинен робити перші, саме дитячі кроки. Можна і потрібно дозволяти собі робити роботу «тяп-ляп» при старті проекту — якість приходить з практикою, а в гонитві за перфекціонізмом обсяг практики різко знижується.

Прокрастинація — насправді, страх, а не лінь. Страх зробити щось не так: нам більше подобається отримувати дрібні поточні перемоги ціною великої майбутньої поразки (казино, форекс, куріння), ніж втрачати потроху кожен день, але компенсувати це великим майбутнім призом. Так от, зниження планки — це саме дрібні поразки на старті проекту, які обертаються в результаті перемогою в особі його реального розвитку та «полірування» в процесі, а не відкладанням його у довгий ящик.

7. Підтримання стану потоку

Програмування — один з небагатьох видів діяльності, що дозволяє входити в стан потоку (ще є музика, водіння автомобіля, комп'ютерні ігри, і деякі види спорту). Цим варто користуватися, розуміючи принципи входження і виходу з нього: для входу потрібно отримувати негайний фідбек від простих дій, для виходу достатньо будь-якого зовнішнього дистрактору.

Відповідно, замість годинного написання коду без компіляції і запуску, варто поділити на короткі 5-хвилинки з негайним запуском часткового готового коду і перевірки хоча б часткової його роботи. Просто спробуйте, якщо ще не робите цього :) Особисто я взагалі запускаю проект мало не кожну хвилину, коли пишу щось нове і короткий.

Якщо ти намагаєшся спроектувати свій проект з самого початку і до найдрібніших деталей, ти позбавляєш себе мотивації в процесі його майбутньої реалізації: всю креативну і цікаву роботу ти вже виконав, і залишається лише тупий кодинг. Так що проектувати краще все-таки лише в загальних рисах, залишаючи собі конкретні деталі реалізації на «практичний десерт».

Ну а для уникнення виходу зі стану потоку потрібно прибрати всі відволікаючі фактори: програмувати «запойно», по кілька годин поспіль, поки вистачає сил і бажання. Краще переробити, але зробити роботу за тиждень вперед, ніж вичавлювати з себе в годину по чайній ложці. Відключити телефон, закрити скайп, браузер і контактик. Співробітників варто привчати до того, що нетермінові питання повинні вирішуватися виключно поштою. Музика, до речі, теж заважає — швидко стомлює.

8. Ми не любимо чужого код

Це — зрозуміло, але навіть наш власний код приблизно через півроку стає «чужим». Щоб уникнути необхідності розбиратися в «своєму чужому коді», варто мінімізувати залежності всередині нього, залишаючи найпростіші «чорні ящики» з мінімальним функціоналом, щоб не довелося в них знову влазити. Іноді набагато простіше викинути такий дрібний «чорний ящик», ніж розбиратися, що ти там накреативил пару років тому :)

Ми завжди розуміємо, наскільки тупий і кривий код написали пару років тому, але рідко думаємо про те, що наш поточний код — такий же тупий і кривої з точки зору нас же, але з майбутнього.

І ще: завжди буде спокуса «освіжити» старий код, переписати його. Не варто: все одно через пару років він знову перетвориться в тупий і кривий. Мотивацію краще використовувати для написання нового коду, а переписування старого — як «стартер» в моменти, коли мотивації ще немає. Втяглися в роботу? Відмінно! Відкладаємо старий код, пишемо новий.

9. Ми не любимо чужі бібліотеки

Будь-яка «реюзабельная» бібліотека — бомба уповільненої дії. У новому проекті ти по-любому будеш розширювати і змінювати її, тим самим ламаючи старі проекти. Причому непомітно, оскільки ти їх не торкався вже кілька місяців, і не торкнешся, можливо, ще дуже довго. Немає нічого гіршого, коли потрібно терміново допилити щось дрібне в старому проекті, а він тупо не компілюється.

Кожен новий проект повинен мати свою, окрему копію бібліотек, навіть якщо цим ти жертвуєш перехресним баг-фіксом. Якщо в старому проекті очевидний баг в лібе не заважає, та ну і хрін з ним! Спроба розібратися в своїх старих либах, а вже тим більше переписати їх з урахуванням нових знань та досвіду здатна зжерти будь-який час і будь-яку мотивацію.

Замість створення бібліотек краще розширювати мову, в C# — extention methods. Замість бібліотеки стиснення/шифрування краще зробити один раз extention Compress/Encrypt і використовувати його з допомогою підказок середовища програмування, не замислюючись про його внутрішньої реалізації і не згадуючи кожен раз, звідки брати горезвісну бібліотеку.

Поступово накопичується мега-ліба розширень, яка просто лінкуются до будь-якого проекту і розширюється по мірі необхідності, забезпечуючи реюзабельность коду на рівні найпростіших «цеглинок». Тут важливо лише пам'ятати про те, що старий код чіпати не варто, щоб не руйнувати старі проекти. Замість розширення параметрів функції краще зробити нову, а стара нехай лежить, як є.

10. Універсальні рішення складніше конкретних

Банальність, але все-таки: в гонитві за розробкою універсальних алгоритмів і фреймворків ми позбавляємо себе простих і очевидних рішень, доступних в контексті поточної задачі. Замість «універсального список останніх переглянутих елементів» краще зробити конкретний список останніх документів поточного проекту. На практиці набагато простіше скопипастить код з минулого проекту і модифікувати його під потреби нового, ніж підтримувати універсальну либу.

Мотивація — це як паливо. Якщо її витратити на зайву роботу по універсалізації чого-небудь, її не залишиться на реально важливу роботу.

11. Мотивацію потрібно цінувати і користуватися їй по-повній

Якщо хочеться зробити щось важливе прямо зараз — сядь і зроби. Найкращі результати приходять з терміновим виконанням не термінової, але важливої роботи, а не строкової і важливою (тоді ти просто «догоняешь» поточну ситуацію), і вже тим більше не з-за роботи над чим-небудь не терміновим і не важливим. Так, ти будеш іноді запізнюватися, але більша частина здаються нам серйозних наслідків відкладання термінової роботи на практиці виявляються не такими вже й серйозними.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.