Мотивація себе насправді написати код після того, як ви щось розробили [закрито]

Це трапляється лише зі мною чи це теж знайоме вам?

Це так: Ви повинні щось створити; модуль, функція, ціла програма ... що завгодно. Це щось цікаве, чого ви ніколи раніше не робили, це складне завдання.

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

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

Але тепер, після того, як все вирішиться, ви повинні сісти і фактично написати код для цього. І вже не кидає виклик .... Був там, зробив це! Написання коду зараз - це лише "формальності", і це виглядає як повторне повторення того, що ви закінчили.

На своїй попередній роботі я іноді відходив від цього, тому що хтось інший робив кодування за моїми специфікаціями, але в моєму новому концерті я відповідаю за весь процес, тому я теж повинен це робити (тому що мені платять робити це).

Але у мене є проект для домашніх улюбленців, над яким я працюю вдома, після роботи, і я просто я, і ніхто мені не платить за це. Я займаюся творчою роботою, і тоді, коли настає час її записати, я просто не відчуваю цього (давайте трохи перегляньте Інтернет, подивіться, що нового в P.SE , на SO тощо).

Я просто хочу перейти до наступної складної речі, а потім до наступної, і наступної ...

Чи трапляється це і з вами? Як ти з цим справляється?

Як ви переконуєте себе зайти і написати чудовий код?

Я візьму будь-яку відповідь.

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

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

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

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

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

Вам потрібно швидке прототипування, вдома.

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

Цілком прийнятно встановлювати високий рівень особистого проекту, але ви повинні розуміти, що у вас може бути недостатньо ресурсів (годин кодування, крім ваших 8 годин щоденної роботи), щоб досягти прогресу над проектом.

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

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

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

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

Я, безумовно, розумію ваше розчарування, як я сам переживав це раніше.

Незважаючи на те, що я побоююся, що з боку громади виникне полум'я, оскільки я знаю, це не дуже підхід, я поділюсь із вами своїм підходом до побічних проектів . Зверніть увагу, що цей метод працює для мене, і я використовую його для середньо / довгострокових проектів, я б не робив це для чогось невеликого (оскільки зазвичай у мене є мотивація закінчити його за один раз).

Візьміть весь проект і розбийте його на «пакунки», кожен з яких складається з частин, які збираються часто взаємодіяти між собою. Потім розділіть кожен пакет на невеликі шматочки (подумайте максимум кілька годин), які ви зможете сконструювати та кодувати.

В ідеалі ви зможете виконати кожен твір у будь-який час, який ви виділите для свого побічного проекту на день, але це не потрібно (залежить від людини).

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

Тепер кожен невеликий шматок проходить усі етапи вашого нормального процесу розробки, проектування, тестування, впровадження та все, що вам потрібно зробити. Ідея полягає в тому, щоб дати кожному твору хороший удар, але ще не повний роздум.

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

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

Перегляньте кожен пакунок і запам’ятайте всі інші, які ви робили раніше, як новий код, який ви пишете, буде взаємодіяти з речами, які ви написали тиждень тому? Не бійтеся шукати речі, про які ви вже писали, і, можливо, забули.

Нарешті, коли у вас все поза пакетами, я зазвичай відпускаю це на кілька днів, даю собі відпочити і зосередитися на чомусь іншому.

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

Сподіваюся, що це допоможе вам у ваших починаннях.

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

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

Доставка - особливість. Якщо ви не проходите цілу відстань, ви просто архітектор.

Я думаю, що проблема полягає в неправильній цілі. Виглядає так, що ви ставите собі за мету "систему проектування". І тоді ти робиш це добре, і мета досягнута. Отже, одна пропозиція - встановити іншу мету "впровадити систему", але тоді вона більше пов'язана з мотивацією та тим, як ви це робите.

Є ще один спосіб, який добре працював для мене: встановити початкову мету як "доставити систему конкретним користувачам", а не "проектувати систему" або "зробити систему". Таким чином, ви не будете задоволені, поки користувачі не отримають щось цінне. І ви робите це добре з самого початку (включаючи тестування та інші сучасні модні речі).

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

Напр .: Якщо я створив свої основні класи, я виписую їх і виконую на ньому кілька тестів. Тоді я сконструював базу даних, що склалася, я її налаштував і випробував. Далі я маю необхідні методи та функції для отримання все в / з бази даних, я продовжую це. Тестування проводиться простіше, оскільки я вже готова до базових занять. І коли я нарешті прийшов розробити користувальницький інтерфейс, у мене вже є цілий набір коду, готовий пограти.

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

Сподіваюся, це допомагає.

Тоді просто запишіть свої ідеї дизайну, опублікуйте їх (у блозі), зробіть все можливе, щоб пояснити проблему та рішення, яке ви знайшли перед іншими.

Хитрість: напишіть своє пояснення дизайну як грамотну програму! :) Тоді ви займаєтесь цікавою частиною (своїми дизайнерськими ідеями), але насправді виправдовуєте їх реальним кодом, який ви надаєте поряд.

І опублікуйте грамотну програму як презентацію своїх нових ідей іншим!

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

Зазвичай приблизно в цей час я забув, що у мене виникли проблеми із запуском, і я в зоні.

Працює близько 80% часу. Для решти - тетріс.

Це точно не тільки ти! Я фактично відкладаю проект прямо зараз.

Ніхто не може вас мотивувати, крім вас самих.

Створіть реалістичний часовий рядок і киньте виклик собі, щоб вчасно заповнити кожен розділ. У вас немає чого показати проектам, якщо вони ніколи не пройдуть етапу проектування.

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

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

Я цілком розумію, звідки ти родом. Ця проблема вас цікавить, і як тільки ви це зрозумієте, реалізація просто працює.

Чому ви не просто архітектуєте рішення, а інші реалізуєте?

Що я роблю:

• Поставте передо мною великий таймер (можна у зворотному режимі, шматками по 1 годині)
• Змусити мене триматися, поки не досягнуто якоїсь мети (іноді за пивом я виявив, що трохи алкоголю допомагає)

Хоча це не завжди працює

PS. Я працюю з дому