Unikaj zostania programistą „teoretykiem”

Znalazłem ten artykuł w kilku postach na SO. Uważam, że wpadam w szósty archetyp; „teoretyk”.

Definiuje „Teoretyka” jako:

Teoretyk wie wszystko o programowaniu. On lub ona może spędzić cztery godziny wykładając historię niejasnego języka programowania lub dostarczając dowód, że napisany kod jest mniej niż idealnie optymalny i uruchomienie dodatkowych trzech nanosekund. Problem polega na tym, że teoretyk nie wie nic o rozwoju oprogramowania. Kiedy teoretyk pisze kod, jest on tak „elegancki”, że zwykli śmiertelnicy nie mogą go zrozumieć. Jego ulubioną techniką jest rekurencja, a każdy blok kodu jest maksymalnie dostosowywany, kosztem terminowości i czytelności.

Teoretyk łatwo się rozprasza. Proste zadanie, które powinno zająć godzinę, zajmuje Teoretykom trzy miesiące, ponieważ decydują, że istniejące narzędzia nie są wystarczające i muszą zbudować nowe narzędzia do budowy nowych bibliotek, aby zbudować zupełnie nowy system, który spełnia ich wysokie standardy. Teoretyka można przekształcić w jednego z najlepszych graczy, jeśli uda mu się zmusić go do grania w ramach samego projektu i przestać spędzać czas na pracy nad ostatecznym algorytmem sortowania.

Nawet pracując nad czymś, co powinno być prostym projektem, mam tendencję do wpadania w osłupienie, próbując przerobić wszystko od zera (prawdopodobnie to wyjaśnia, dlaczego zmarnowałem około 2 lata, próbując stworzyć system operacyjny od zera. Ale nawet ja to widziałem ostatecznie nie miało sensu).

Co może mi pomóc uniknąć tego? I trzymać się zasad KISS?

Dzięki

Będąc z natury teoretykiem, mogę powiedzieć, że praca w sklepie Agile szybko i zdecydowanie wyleczy wszystkie takie tendencje. W szczególności operacja eXtreme Programming z programowaniem par (najlepiej często obracającym się), programowaniem opartym na testach, boksem czasowym i ograniczonymi sprintami, natychmiast odsłania twoją pracę dla wszystkich twoich kolegów i wymaga od ciebie otwarcia się i współpracy z minuty na minutę. Jest to ogromne odejście od oddzielnych zadań w odizolowanym środowisku biurowym, w którym kwitnie praca w stylu teoretyków. Wymaga całkowitej uczciwości i całkowitej uczciwości, ponieważ wszyscy aktywnie polegają na wszystkich innych w sposób ciągły.

Nadal cenię sobie pępek, ale muszę sobie na to pozwolić w domu lub w tych rzadkich przypadkach, gdy mogę pracować nad projektem po stronie, który nie jest częścią rozwoju głównej linii.

1. Miej cele dla tego, co powinieneś rozwijać.

2. Zawęź te cele do czegoś, co będzie możliwe w najbliższej przyszłości.

3. Następnie skup się na tych celach, eliminując wszystkie inne względy. Bez tła. Bez historii. Brak rozszerzeń. Nic ogólnego ani abstrakcyjnego.

4. Następnie zawęź je dalej, tak aby przynajmniej było to możliwe. Niedobrze. Nie elastyczny. Nie do utrzymania. Akceptowalne.

5. Następnie nadaj priorytet absolutnemu minimum wymaganemu, aby osiągnąć co najmniej tyle, ile możesz zrobić. Chodzi o to, aby wybrać datę w ciągu około tygodnia i budować w kierunku tej daty. Jeśli nie możesz dostarczyć czegoś w ciągu tygodnia. Wąski. Skupiać. Trym. Redukować.

6. Następnie usuń puch. Masz tylko tydzień. Ciąć dalej.

7. Następnie skoncentruj się na ograniczonym wdrażaniu, które zostanie wykonane jak najwcześniej. Idealnie mniej niż tydzień, więc masz czas na napisanie dokumentacji.

Pracowałem z teoretykami. „Dodatki” uważam za wymówkę, aby uniknąć robienia czegoś, co może być oznakowane niepowodzeniem.

Robienie - i porażka - jest trudne. Mówienie o robieniu czegoś jest łatwiejsze niż robienie czegoś. Wiele badań i myślenia jest sposobem na uniknięcie niewłaściwego działania, a następnie przerobienie go po dowiedzeniu się, że użytkownicy kłamali.

Po prostu umieść kod przed nimi. Nazywają kod niepowodzeniem. Zdarza się. Ale w trakcie niepowodzenia dowiesz się, jakie są prawdziwe wymagania. I dowiesz się, że kłamali.

Nie jestem pewien, czy to takie złe. Oczywiście musisz być produktywny, bo inaczej nie będziesz wykonywać swojej pracy, ale interesujesz się tym, będąc studentem sztuki, że tak powiem, nie jest złą rzeczą.

Wykorzystałbym twoje mocne strony, szukałbym okazji, w których twój styl i preferencje są zaletą.

Aby zapewnić sobie produktywność, pozwalając sobie na pisanie frameworka MVC w Erlang (lub cokolwiek, co uważasz za interesujące), być może powinieneś poświęcić więcej czasu na swoją eseoteryczną pracę, powiedzmy, godzinę dziennie. Przez resztę dnia po prostu skup się na chrząkaniu i załatw sprawę. Gdy zobaczysz coś interesującego, co mogłoby odwrócić uwagę, dodaj do zakładek lub poczytaj notatkę, ale przejdź dalej, a następnie wróć do niej w przydzielonym czasie.

Osobiście mam mnóstwo adresów URL, które wyglądają interesująco, a także stos książek z biblioteki. Może w końcu dostaję około 10% tych adresów URL, a może w końcu czytam 50% książek, ale nadal wykonuję codzienną robotę.

Sam miałem ten problem. Pomogły dwie techniki:

1. Użyj techniki Pomodoro lub innej techniki zarządzania czasem, w której wyznaczasz sekwencję bardzo krótkoterminowych celów. Kiedy musisz dowiedzieć się, co możesz osiągnąć w ciągu następnych 25 minut, koncentrujesz się na użytecznej pracy.
2. Rozwój oparty na testach. Jeśli musisz napisać konkretny test przed napisaniem jakiegokolwiek kodu, minimalizuje on marzenia. (Nie ma sposobu, aby napisać test na „elegancki”.) Po tym, jak coś zacznie działać, możesz poświęcić więcej czasu niż powinieneś go refaktoryzować, ale przynajmniej będziesz pracował na prawdziwym kodzie, a nie na wymyślonym ideale.

Nie pobijaj się za bardzo. Łatwiej jest zdobyć teoretyka, aby się skoncentrował i wykonał pożyteczną pracę, niż skłonić ludzi, którzy nie dbają o poszerzenie swoich horyzontów.

Unikaj stackoverflow.com . Nie zrozum mnie źle - jestem wielkim fanem - ale fora SO i inne zorientowane na programowanie czynią idealnego wroga dobra . Po pewnym czasie możesz zacząć mieć wrażenie, że tysiące inteligentnych ludzi spoglądają przez ramię i nic, co piszesz, nie jest wystarczająco dobre. Po prostu uruchom coś i staraj się, aby było to zrozumiałe. Zawsze możesz odwiedzić ponownie, jeśli wymaga to poprawy.

Unikaj także artykułów takich jak ten, który podłączyłeś. Czy naprawdę wierzysz, że istnieje dziesięć rodzajów programistów? A może ktoś, kogo znasz, pasuje całkowicie do dokładnie jednej z opisanych kategorii? Artykuły takie jak ten mają pewien urok, ponieważ zawierają odrobinę prawdy - możesz zobaczyć siebie i / lub niektórych współpracowników w niektórych stereotypach. Ale kategorie zawierają tyle wody, ile znaków astrologicznych. Spróbuj następnym razem, gdy będziesz w mikserze po konferencji: „Cześć, jestem Code Cowboy! Jaki masz typ?”

Nie oznacza to, że twoje pytanie jest nieprawidłowe - jeśli zastanawiasz się nad czymś, dobrze jest nauczyć się, jak unikać tej tendencji. Ale nie pozwól, aby ta dziwactwo nakłoniło cię do zaszufladkowania.

Jest jedna prosta wytyczna, która po całkowitym rozpakowaniu wyjaśnia w pełni, jak uniknąć tego scenariusza.

Zrób najprostszą rzecz, która może działać.

- Kent Beck

Myślę, że jednym ze sposobów, aby trzymać głowę z dala od chmur, jest zmuszenie się do pisania rzeczywistych aplikacji od początku do końca, oprócz pisania teoretycznych interfejsów API lub ram. Postaraj się wokół czegoś ustawić ramkę czasu i spróbuj ją „skończyć” w tym czasie. Pisanie frameworków wymaga dobrego zrozumienia wzorców projektowych i architektury, ale odkryłem, że napisanie kompletnej aplikacji w ustalonym czasie wymaga innych umiejętności niż pisanie super dobrze zaprojektowanego frameworka.

Jeśli chcesz kiedykolwiek wypełnić wniosek, w pewnym momencie musisz sprowadzić się na ziemię i po prostu załatwić sprawę. Może to wymagać poświęcenia projektów lub zmuszenia do implementacji funkcji w sposób, z którego nie jesteś zadowolony z powodu pewnego rodzaju ograniczenia. Jestem trochę podobny do ciebie - mam skłonność do pisania i przepisywania rzeczy milion razy, ale jeśli mam do czynienia z zadaniami, które trzeba wykonać w określonym czasie, stwierdzam, że wybieram swoje bitwy i wybieram tylko najważniejsze rzeczy.

Prosty :

1. Bądź pragmatyczny .

Przeciwną stroną Teoretyka (która ma swoje zalety po stronie informacji / wiedzy w dziedzinie programowania) jest Pragmatic.

Stosowanie KISS, DRY, SOC i innych sposobów myślenia opisanych w tej odpowiedzi oznacza bycie pragmatycznym.

Możesz także nauczyć się być pragmatycznym, czytając tę ​​książkę:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

Nie zapominaj, że teoria i praktyka działają razem, a nie same. Bez dużej praktyki wiedza jest niczym. Bez dużej wiedzy nie można szybko poprawić swojej praktyki.

Więc ćwicz dużo. I dużo się uczę. Ale nie pozwól, aby jeden przeszedł przez drugi.

W swoich projektach ustal termin. Trzymaj się tego. Następnie pomyśl pragmatycznie o tym, jak zakończyć swój projekt przed tym terminem. (naprawdę czytaj książkę) Następnie zacznij kodować, zacznij czytać to, co musisz wiedzieć, przełącz się z czytania na kodowanie i ogranicz lub czas czytania.

Hrm ... Być może spróbuj znaleźć pracę w firmie, która wymaga pisania aplikacji zgodnie z harmonogramem. Powiedziałbym sobie, że prawdopodobnie jestem tak daleko od bycia teoretykiem, jak tylko możesz, przynajmniej w pracy. Wykonywanie tego rodzaju pracy ma swoje miejsce i czas i jest ważne dla rozwoju. Chociaż doceniam ten rodzaj umiejętności, nie ma on miejsca w świecie biznesu, szczególnie tam, gdzie pracuję. Szybkie środowisko programistyczne, w którym czasami piszesz aplikacje w kilka tygodni, a klient chce je wczoraj! Zostałem pobłogosławiony niesamowitymi programistami i zajęło mi to czasu, aby wszyscy pracowali jako zespół.

Miałem faceta, który był tak genialny, jak to tylko możliwe, ale tak jak ty, zawsze musiałem wyciskać ostatni kawałek jego kodu, nawet gdy działał dobrze, nawet do tego stopnia, że ​​zaczął pisać niestandardowe formanty, które były w zasadzie takie same jak te dostarczane przez środowisko. Wszystko było bardzo fajne, ale taka strata czasu, kiedy musieliśmy wydostać rzeczy na czas. Często te poboczne projekty wspierały zespół, aż w końcu zaczął odczuwać presję ze strony innych i kształtował się. Sugerowałbym rozpoczęcie pracy w środowisku zespołowym z innymi dobrymi programistami, którzy muszą wypychać produkty. Zawsze jest czas później na przeredagowanie i przeróbkę rzeczy lub napisanie najbardziej zadziornego MergeSort w historii; ale czasami musisz doprowadzić produkt do punktu, w którym działa, i przekazać go klientowi.

Nie ma nic złego w byciu „teoretykiem” w zwykłym tego słowa znaczeniu. Posiadanie podstawowej wiedzy i zrozumienie najnowszych badań CS jest wielką umiejętnością, ponieważ jest to kopalnia złota dobrych i oryginalnych pomysłów.

„Prawdziwe pytanie” tutaj jest bardziej widoczne w dalszej części postu. Poznaj konkretny cel projektu i pracuj w tym celu, a nie w żadnym innym celu. W tym przypadku jest to po prostu kwestia samodyscypliny. Więcej informacji na ten temat znajdziesz w odpowiedzi S. Lotta :).

Skoncentruj swój umysł od programowania, a nawet robienia rzeczy na dostarczaniu działającego oprogramowania. To poprawia twoje priorytety.

Jak to osiągnąć, to inna historia. Najlepszym sposobem jest opracowanie jakiegoś projektu i wykonanie wszystkich kroków w celu uruchomienia go w produkcji. Potem będziesz miał inny sposób myślenia niż wcześniej.

Dzięki za ten post. To sprawia, że ​​moja praca jest jeszcze bardziej cenna. Czuję to samo, mając wykształcenie w zakresie architektury informacji pracujące jako programista. Często mam problemy z „gdzie zmienić rzeczy”, a nie „co zmienić”. Istnieje zbyt wiele relacji, zbyt wiele inteligentnych i ogólnych rzeczy, których sprawdzenie, jak to działa, zajmuje zbyt długo.

Zaczynam więc zadawać pytania, a nawet więcej pytań, dopóki nie poznam JAK i GDZIE to jest naprawdę zbudowane. I powiem ci - to działa. Im więcej pytań zadaje pożar, tym mniej ważne jest utrzymanie oryginalnej architektury i wreszcie powrót do podstaw

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Poproś szefa o mentora, a następnie zrób tak, jak mówi mentor.

Trudność polega na utrzymywaniu ostrości i uznaniu, że „hej, przepiszmy system operacyjny” nie przyniesie znaczących korzyści w ukończeniu powierzonego zadania (dlatego kierownik projektu nie zrobi tego).

Poproś także mentora o przejrzenie WSZYSTKICH projektów przed kodowaniem oraz rzeczywistego kodu po kodowaniu. Pomoże ci to skoncentrować się na tym, co należy zrobić.

Mam taką samą pokusę, by nad-inżynierować rzeczy, a samodyscyplina i organizacja muszą przejść przez to. Kiedy koduję dla kogoś innego, oto jak to zrobić:

1. Rozpoczynając dyskretne zadanie, poświęć kilka minut na zastanowienie się, co jest naprawdę wymagane, jeśli chodzi o funkcjonalność, jakość, datę dostawy itp.
2. Poświęć trochę więcej czasu na zaplanowanie tego , dzieląc go na podzadania, podzadania itp., Pamiętając o celach klienta kodu.
3. Oszacuj czas dla każdego przedmiotu , dodając do 50% dla nieznanych. Jeśli przedmiot zajmie więcej niż cztery godziny, zniszcz go jeszcze trochę. (Gdybym realizował projekty uczelni, korzystałbym z arkusza kalkulacyjnego, ale jako konsultant z wieloma klientami korzystam z systemu śledzenia problemów o nazwie Redmine.)
4. Co najważniejsze: rób tylko przedmioty, które wymyśliłem .

Oczywiście rzeczy się zdarzają. Czasami stwierdzam, że muszę robić więcej rzeczy - więc zaczynam od nowa od nr 1. Czasami uważam, że zadanie zajmie znacznie więcej czasu, niż myślałem - zacznij od początku # 1. Czasami wiem z góry, że mój projekt będzie później potrzebował więcej szczegółów - dlatego planuję podzadanie ponownej oceny, w którym zaczynam od nowa od nr 1.

Im więcej to robię, tym lepiej. Samodyscyplina jest mięśniem mentalnym, które wzmacnia się podczas ćwiczeń, a także poprawiam szacowanie, jak długo to potrwa, i dokonuję technicznych kompromisów. Przydaje mi się też przypomnienie cytatu generała Pattona: „Dobry, brutalnie wykonany teraz plan jest lepszy niż idealny, wykonany w przyszłym tygodniu”.

Jako samotny programista mój przepływ pracy łączy to z aspektami Agile, w tym z tablicą Kanban. Czasami wychodzę na styczne, ale staram się ograniczać odchylenia do kilku godzin w tygodniu i działa całkiem dobrze.

Jeśli planujesz pracować w prywatnym przemyśle, naprawdę ważne jest kontrolowanie impulsu „teoretyka”. Najbardziej genialny programista, jakiego znam, mieszka w Dolinie Krzemowej, ale od lat nie miał pracy, ponieważ ma taką reputację, że dostarcza zbyt późno idealny kod.