Motywowanie się do pisania kodu po zaprojektowaniu czegoś [zamkniętego]

Czy to przytrafia się tylko mnie, czy też jest ci to znane?

To tak: musisz coś stworzyć; moduł, funkcja, cała aplikacja ... cokolwiek. Jest to coś interesującego, czego nigdy wcześniej nie robiłeś, jest wyzwaniem.

Więc zaczynasz myśleć, jak to zrobisz. Rysujesz szkice. Piszesz prototypy, aby przetestować swoje pomysły. Składasz różne elementy, aby uzyskać pełny widok.

W końcu otrzymujesz projekt, który ci się podoba, coś, co jest proste, jasne dla wszystkich, łatwe w utrzymaniu ... nazwij to. Pokryłeś każdą bazę, pomyślałeś o wszystkim. Wiesz, że będziesz miał tę klasę, ten plik i ten schemat bazy danych. Skonfiguruj to tutaj, dostosuj tam inne rzeczy itp.

Ale teraz, kiedy wszystko zostanie ustalone, musisz usiąść i napisać dla niego kod. I nie jest już wyzwaniem ... Byłem tam, zrobiłem to! Napisanie kodu jest teraz „formalnością” i sprawia, że ​​wygląda to na powtórzenie tego, co właśnie skończyłeś.

W mojej poprzedniej pracy czasami mi się to nie udawało, ponieważ ktoś inny kodował w oparciu o moje specyfikacje, ale na moim nowym koncercie jestem odpowiedzialny za cały proces, więc ja też muszę to zrobić (bo dostaję zapłatę to).

Ale mam projekt zwierzaka, nad którym pracuję w domu, po pracy i jest tylko ja i nikt mi za to nie płaci. Wykonuję pracę twórczą, a kiedy przychodzi czas, aby to zapisać, po prostu nie mam na to ochoty (przeglądajmy trochę Internet, zobacz, co nowego na P.SE , na SO itp.).

Chcę tylko przejść do następnej trudnej rzeczy, a następnie do następnej i następnej ...

Czy to również tobie się przydarza? Jak sobie z tym radzisz?

Jak przekonujesz się, żeby wejść i napisać ten dziwaczny kod?

Wezmę każdą odpowiedź.

Jeśli Twoim wyzwaniem jest projektowanie, a nie wdrażanie, być może potrzebujesz innego czynnika motywującego:

Jeśli jest to projekt dla zwierząt domowych (nie do pracy), naprawdę nie mogę się doczekać, aby ożywić, więc zaprojektowanie go nie wystarczy. Kiedy wymyślisz własne projekty dla zwierząt, jaki jest cel? Czy to coś, czego potrzebujesz? Jeśli tak, możesz to wykorzystać jako motywację do jego wdrożenia. Aby zobaczyć, jak działa. Aby zapewnić funkcjonalność, z której chciałeś skorzystać.

Czy planujesz udostępnić go innym? Czynnikiem motywującym może być ich korzyść z produktu końcowego. Nie wyciągną z tego narzędzia, jeśli będzie tylko w trybie projektowania. A jeśli planujesz go wprowadzić na rynek, skorzystaj z faktu, że nikt nie zapłaci za twój projekt zwierzaka, gdy utknął w trybie projektowania, jako czynnik motywujący.

Kiedy pracuję nad sobą, wybieram bardziej iteracyjne podejście niż w pracy - nie martwię się o wszystkie szczegóły przed wygenerowaniem czegoś. Może to potrwać dłużej, ale 1), ponieważ jest to tylko dla mnie (lub dla kogoś, kto nawet nie wie, że istnieje w jakiejkolwiek formie), więc mam swobodę eksperymentowania i nie spieszę się. 2) Spędzam mnóstwo cykli refaktoryzacji i uczę się lepszych sposobów robienia rzeczy. W moim własnym wymiarze, mówiąc w przenośni.

Ostatecznie jednak, czy nie jest prawdziwą satysfakcją, gdy coś ożywa z powietrza? To właśnie dla mnie to robi. Jeśli to ci nie pomoże, chyba że twoją motywacją jest produkt końcowy, to nie jestem pewien, czy rozumiem, dlaczego w ogóle chcesz pracować nad projektem zwierzaka. Jeśli projektowanie jest tym, co Cię inspiruje i robisz to w pracy, wydaje się, że już osiągasz satysfakcję, której szukasz.

Potrzebujesz szybkiego prototypowania w domu.

Gdy zastosujesz ten sam poziom profesjonalnej dyscypliny w prywatnym osobistym projekcie, łatwo doprowadzi to do nadmiernej inżynierii.

Całkowicie dopuszczalne jest ustanowienie wysokiego standardu dla osobistego projektu, ale musisz zrozumieć, że możesz nie mieć wystarczających zasobów (godzin kodowania, oprócz 8 godzin codziennej pracy), aby poczynić postępy w projekcie.

Jaki jest najistotniejszy cel twojego projektu dla zwierząt domowych? Aby udowodnić przydatność jednego ze swoich spostrzeżeń? W takim przypadku przycinaj projekt, aż stanie się projektem sprawdzającym koncepcję . Następnie użyj szybkiego prototypowania, aby osiągnąć więcej przy krótszym czasie kodowania.

Chyba to tylko ja, ale mam odwrotny problem. Zwykle mam problemy z myśleniem o wszystkich szczegółach, zanim zacznę pisać kod i napotkam odpowiednie problemy. Realistycznie, kiedy zaczynam coś kodować, zwykle mam w głowie tylko niejasny wzór. Moje wielkie wyzwanie polega na tym, aby pomyśleć o wszystkich szczegółach i mieć projekt z góry.

Z całą pewnością mogę się do tego odnieść. Uwielbiam podejmować wyzwania, których nie spotkałem, ale ciężko mi zacząć pracować nad wszystkim, co już rozwiązałem. Najważniejsze, co robię, to po prostu zmusić się, by usiąść z celem, jakim jest wykonanie X i funkcjonowanie. Zwykle, kiedy zaczynam, to dobrze się bawię i robię więcej, niż zamierzam, ale jeśli nie wymuszę celu, źle się czuję przez wiele godzin.

Jestem również z tobą, ponieważ dzieje się to bardziej w domu na pracach bocznych niż w biurze. Nie wiem, czy to bardziej rozprasza, jest spalony w pracy czy co ...

Z pewnością rozumiem twoją frustrację, ponieważ sam ją przeżyłem.

Pomimo obawy przed jakimś płomieniem ze strony społeczności, ponieważ wiem, że to nie jest świetne podejście, podzielę się z Wami moim podejściem do projektów pobocznych . Należy pamiętać, że ta metoda działa dla mnie i używam jej w projektach średnio- / długoterminowych, nie zrobiłbym tego dla czegoś małego (ponieważ zazwyczaj mam motywację, aby ukończyć ją za jednym razem).

Złap cały projekt i podziel go na „pakiety”, z których każdy składa się z części, które często będą ze sobą współdziałać. Następnie podziel każdą paczkę na małe części (maksymalnie kilka godzin), które możesz zaprojektować i zakodować.

Najlepiej byłoby ukończyć każdy element w dowolnym czasie przeznaczonym na projekt poboczny na jeden dzień, ale nie jest to wymagane (zależy od osoby).

Osobiście nie ustalam szacunkowych ram czasowych dla każdego utworu, ponieważ po prostu zawiodłem się i zdemotywowałem, gdy mi się nie uda, dlatego nie polecam tego. Nie spiesz się, ale też nie trwa zbyt długo.

Teraz każdy mały kawałek przechodzi wszystkie etapy normalnego procesu programowania, projektowania, testowania, wdrażania i wszystkiego, co musisz zrobić. Chodzi o to, aby dać każdemu kawałkowi dobry start, ale jeszcze nie pełny efekt końcowy.

To podtrzymuje moją motywację, ponieważ wiem, że po kilku godzinach faktycznego kodowania nudne rzeczy będę miał więcej do zrobienia (pyszne). Nie pozwól sobie odejść od swoich celów, po prostu wykonuj to okropne zadanie, a wkrótce się skończy.

Po przejrzeniu wszystkich elementów spójrz na paczkę. Zobacz, jak to działa, co robi, ponownie przejrzyj cały pakiet. Jestem pewien, że będą zmiany i poprawki, zrób to teraz. Pamiętaj o najważniejszych informacjach, ponieważ będą one potrzebne podczas pracy nad wszystkimi innymi pakietami. Notuj też, bardzo pomagają.

Przejrzyj każdą paczkę i zapamiętaj wszystkie inne, które zrobiłeś wcześniej. Jak nowy kod, który piszesz, będzie wchodził w interakcje z materiałami napisanymi tydzień temu? Nie bój się szukać rzeczy, które już napisałeś i być może zapomniałeś.

Wreszcie, kiedy nie masz już paczek, zwykle odpuszczam je na kilka dni, odpoczywam i skupiam się na czymś innym.

Zwykle mam ochotę wrócić i zacząć przeplatać pakiety i przeprowadzić zabawne testy, nie ma więcej kodu do napisania, a cel jest bliski, to dla mnie wystarczająca motywacja.

Mam nadzieję, że to pomoże ci w twoich staraniach.

Zawsze uważałem, że pierwotne założenia nie zachowały się całkowicie i mniej więcej pierwotny projekt musiał zostać zmieniony na podstawie doświadczenia zebranego podczas rzeczywistej implementacji.

Jeśli uważasz, że twój projekt jest absolutnie nieomylny i idealny po narysowaniu kilku ramek, ale zanim faktycznie go wypróbujesz, uważam cię za idealnego kandydata do niektórych realizacji projektu.

Wysyłka jest funkcją. Jeśli nie przejdziesz całej odległości, jesteś tylko architektem.

Myślę, że problem ma niewłaściwy cel. Wygląda na to, że wyznaczyłeś sobie cel „system projektowania”. A potem robisz to dobrze i cel zostaje osiągnięty. Jedną z sugestii jest ustalenie innego celu, jakim jest „wdrożenie systemu”, ale wówczas jest to bardziej związane z motywacją i tym, jak to robisz.

Jest dla mnie jeszcze jeden sposób: ustalenie początkowego celu jako „dostarczanie systemu do określonych użytkowników” zamiast „projektowanie systemu” lub „tworzenie systemu”. W ten sposób nie będziesz zadowolony, dopóki użytkownicy nie zdobędą czegoś cennego. I robisz to dobrze od samego początku (w tym testy i inne nowoczesne fantazyjne rzeczy).

Pomijając motywację, myślę, że część rozwiązania można znaleźć w połączeniu procesu projektowania i kodowania. Tak najczęściej to robię. Zasadniczo sprowadza się do wdrożenia podstaw projektowania, gdy o tym pomyślisz, a następnie przejdź do następnego kroku.

Np .: Jeśli zaprojektowałem podstawowe klasy, wypiszę je i przeprowadzę na nim testy. Następnie zaprojektowałem bazę danych, skonfigurowałem ją i przetestowałem. Następnie mam metody i funkcje, których potrzebuję, aby uzyskać wszystko do / z bazy danych, idę dalej. Testowanie jest łatwiejsze, ponieważ mam już przygotowane podstawowe zajęcia. A kiedy w końcu zaprojektowałem interfejs użytkownika, mam już cały zestaw gotowych do zabawy.

Teraz zakłada się, że projektujesz również w blokach połączonych za pomocą interfejsów. Nie znam na to drogiego słowa, ponieważ z wykształcenia nie jestem programistą, ale wiesz, co mam na myśli.

Mam nadzieję że to pomoże.

Następnie zapisz swoje pomysły na projekt, opublikuj je (na blogu), postaraj się jak najlepiej wyjaśnić problem i rozwiązanie, które wpadłeś na innych.

Sztuczka: napisz swoje objaśnienie projektu jako umiejętnego programu! :) Następnie zajmujesz się interesującą częścią (swoimi pomysłami projektowymi), ale faktycznie uzasadniasz je prawdziwym kodem, który dostarczasz.

I opublikuj program czytania i pisania jako prezentację swoich nowych pomysłów innym!

To zabrzmi banalnie, ale zacznij. Prawdopodobnie będziesz musiał otworzyć swoje środowisko programistyczne, więc zrób to. Prawdopodobnie będziesz musiał zdefiniować każdą z klas w swoim projekcie i zapisać podpisy metod, więc zrób to. Musisz zacząć wdrażać najważniejsze metody, więc zrób to.

Zwykle w tym czasie zapomniałem, że miałem problemy z uruchomieniem i jestem w strefie.

Działa przez około 80% czasu. Reszta to Tetris.

To zdecydowanie nie tylko ty! W tej chwili odkładam projekt.

Nikt nie może cię motywować oprócz ciebie.

Stwórz realistyczną linię czasu i zmierz się z każdą sekcją na czas. Nie masz nic do pokazania projektom, jeśli nigdy nie przejdą fazy projektowania.

Sądząc po twoim pytaniu, twoim problemem jest to, że wydajesz się wymyślać koło na nowo. Jeśli już to wszystko zrobiłeś, dlaczego musisz to zrobić ponownie? Czy nie ma dla ciebie żadnych ram? Jeśli nie (choć jest to mało prawdopodobne), dlaczego nie napisać takiego?

Kluczowym zadaniem w programowaniu nie jest robienie nudnych rzeczy od nowa , ale robienie tego raz, robienie tego poprawnie, a następnie ponowne używanie. Lub jeszcze lepiej: znalezienie kogoś, kto już to zrobił raz i poprawnie.

Całkowicie rozumiem, skąd pochodzisz. Interesuje Cię problem, a gdy go zrozumiesz, wdrożenie jest po prostu skuteczne.

Dlaczego po prostu nie zaprojektujesz rozwiązania i nie wdrożysz innych?

Rzeczy które robię:

• Postaw przede mną duży minutnik (może być w trybie wstecznym, w kawałkach po 1 godzinie)
• Zmuszaj mnie do pozostania do czasu, aż osiągnę jakiś cel (czasem przy piwie zauważyłem, że trochę alkoholu pomaga)

Jednak nie zawsze działa

PS. Pracuję w domu