Ilość czasu spędzona na myślenie a pisanie

Question

Cześć, chciałbym zapytać się ile czasu spędzacie na pisanie kodu, a ile na myślenie co napisać?

Zdarza mi się napisać nazwe metody, po czym przy pustych nawiasach siedzieć dobrą godzinę z kartkami (rozpisuje na kartkach, nawyk) lub patrząc pusto w czarną przestrzeń edytora, rozmyslając o metodzie i wszystkich możliwościach, po czym zaczynam pisać mając nazywane przeze mnie "natchnienie" czyli obmyślony schemat, po czym przy testach bądź dalszym pisaniu nadal spędzam więcej niz połowe czasu pisania na myślenie.

Pytanie czy nie spędzam na tym za dużo zadałem sobie jak ktoś wyśmiał że spędziłem kilka dni żeby napisać kilkaset linijek, które on by napisał w kilka godzin, a niektóre osoby wypominają ze tylko patrzę w monitor i naprawdę nic nie robię.

Jak to u was wygląda?

Answer 1

Myślę, że dużo zależy od złożoności problemu, od doświadczenia programisty, jego umiejętności logicznego myślenie, czy znajomości danego języka ;)

Moim zdaniem nie można tego porównywać,względem innych;  jest to kwestia osobowa.
 

Pozdrowienia

Answer 2

widocznie źle podchodzisz do całego procesu. U mnie w firmie jak mamy jakiś nowy ficzer to najpierw spotykamy się aby dokładnie przegadać to od strony biznesowej oraz technicznej i rozbijamy na mniejsze ficzery już techniczne. Do tego konsultacje UXowe i ewentualnie z analitykami jeśli jest taka potrzeba. I dopiero w tym momencie wchodzimy do pisania kodu, a mając dobrze rozpoznany temat to już zostaje tylko odpowiednie napisanie algorytmów itp. Oczywiście potem jeszcze są optymalizacje itp. ale to już często temat dalszy, a nawet dopiero w CRkach. Jak masz problem z analizą wszystkich przypadków to zacznij np. od napisania sobie testów jednostkowych dla jakieś metody i tam postaraj się tworzyć różne przypadki... i tak będziesz musiał napisać testy (no chyba, że należysz do grupy programistów typu "zrobić i zapomnieć") więc czasami warto podejść do nich przed stworzeniem samej implementacji.

Wydaje mi się, że u Ciebie brakuje tego etapu rozpoznania całego problemu. Spotykam się czasami z takim podejściem, ale we 99% przypadków kończy się to potem wieloma poprawkami itp. Na przykład jak robisz zmianę frontową to poczekaj aż UX da Ci makiety, nie startuj wcześniej bo może okazać się, że ficzer ma w ogóle inaczej wyglądać niż myślałeś. Tak samo jak robisz jakąś istotną zmianę dla userów to warto przegadać temat też np. z analitykami aby potem nie było pytań typu "słuchaj, a jak ja mam wyciągnąć userów którzy zrobili to i to... jak nie ma żadnych eventów statystycznych itp.".\

Także cofnij się o krok i dobrze rozpoznaj cały ficzer i dopiero potem startuj z kodowaniem, nigdy odwrotnie.