Utknął z powodu „zbyt dużej wiedzy” [zamknięte]

Zwróć uwagę na więcej dyskusji na stronie http://news.ycombinator.com/item?id=4037794

Mam stosunkowo proste zadanie programistyczne, ale za każdym razem, gdy próbuję go zaatakować, wpadam w spiralę głębokich przemyśleń - jak to może przedłużyć przyszłość, czego będą potrzebować klienci drugiej generacji, jak wpływa to na „niefunkcjonalny” aspekty (np. Wydajność, autoryzacja ...), jak najlepiej zaprojektować architekt, aby umożliwić zmianę ...

Pamiętam siebie jakiś czas temu, młodszy i być może bardziej chętny. „Ja”, którym wtedy byłem, nie pomyślałby o tym wszystkim - poszedłby naprzód i coś napisał, a następnie przepisał, a następnie przepisał (jeszcze raz…). „Ja” dzisiaj jest bardziej niepewne, bardziej ostrożne.

Dzisiaj jest mi o wiele łatwiej siedzieć, planować i instruować innych, jak robić rzeczy, niż robić to samemu - nie dlatego, że nie lubię kodować - wręcz przeciwnie, uwielbiam to! - ale ponieważ za każdym razem, gdy siedzę przy klawiaturze, kończę w tym samym irytującym miejscu.

Czy to źle? Czy to naturalna ewolucja, czy też popadłem w rutynę?

Uczciwe ujawnienie - w przeszłości byłem programistą, dziś moim tytułem pracy jest „architekt systemu”. Powodzenia w ustalaniu, co to znaczy - ale taki jest tytuł.

Łał. Szczerze mówiąc, nie spodziewałem się, że to pytanie przyniesie tyle odpowiedzi. Spróbuję to podsumować.

Powody:

1. Analiza paraliż / nadmierna inżynieria / złocenie / (każde inne „zbyt duże myślenie z góry może cię zranić”).
2. Zbyt duże doświadczenie dla danego zadania.
3. Nie skupianie się na tym, co ważne.
4. Za mało doświadczenia (i uświadomienie sobie tego).

Rozwiązania (niepasujące do przyczyn):

1. Najpierw testowanie.
2. Rozpocznij kodowanie (+ dla zabawy)
3. Jeden do wyrzucenia (+ jeden API do wyrzucenia).
4. Ustaw ograniczenia czasowe.
5. Zdejmij puch, zostań przy materiale.
6. Stwórz elastyczny kod (coś przeciwnego do „jeden do wyrzucenia”, nie?).

Dzięki wszystkim - myślę, że główną korzyścią tutaj było uświadomienie sobie, że nie jestem sam w tym doświadczeniu. Właściwie już zacząłem kodować, a niektóre zbyt duże rzeczy odpadły, oczywiście.

Ponieważ to pytanie jest zamknięte, dzisiaj przyjmę odpowiedź większością głosów. Kiedy / jeśli to się zmieni - postaram się śledzić.

Myślenie o tych rzeczach jest zdecydowanie dobre, ale nie pozwól, aby powstrzymało to twój postęp.

Jednym z podejść, które działa naprawdę dobrze (szczególnie przy iteracyjnym rozwoju) jest wdrożenie prostego rozwiązania, a następnie refaktoryzacja w razie potrzeby później. Dzięki temu kod jest tak prosty, jak to możliwe, i pozwala uniknąć nadmiernej inżynierii. Większość zmian wydajności lub architektury, które rozważasz, prawdopodobnie i tak nie będą wymagane, więc nie zawracaj sobie głowy ich pisaniem, dopóki nie staną się one konieczne. Na przykład nie martw się wydajnością, dopóki profiler nie powie Ci, że nadszedł czas na poprawę wydajności.

Jedną z rzeczy, które możesz zrobić, aby pomóc Ci się dostosować, jest ustalenie ciężkiego limitu czasu na zastanowienie się przed napisaniem kodu. Przez większość czasu kod okaże się lepszy, jeśli zastanowisz się trochę, napiszesz go, zrozumiesz swoje błędy, a następnie naprawisz je przez refaktoryzację.

Tutaj trzeba znaleźć równowagę. Nie powinieneś po prostu rzucać się na głowę i nie myśleć o konsekwencjach, ale także nie powinieneś próbować nadmiernie modyfikować kodu.

Wikipedia nazywa to „paraliżem analizy” w oprogramowaniu. Przepis polega na trzymaniu się zwinnych metodologii. Oznacza to, że każde działanie lub działanie indywidualne ma znacznie większą wartość niż próba ustanowienia praktyk lub zasad. Każdy współpracownik w zespole jest cenny, bez względu na to, jak dobre lub złe są umiejętności danej osoby do ideałów architektonicznych. W zwinnym ludzie, ego są pierwsi, zasady są ostatnie.

Moja ulubiona odpowiedź to „Architektura jest czasownikiem”. Przestań myśleć, zacznij działać, bez względu na to, jak niedoskonale i nieefektywnie poczujesz się wraz z zespołem. Być może pierwszym działaniem może być zniesienie niewłaściwych zasad.

40 lat temu Fred Brooks napisał o tym „Napisz jednego, który wyrzucisz, i tak będziesz”. Nic się nie zmieniło........

Czy to źle? Czy to naturalna ewolucja, czy też popadłem w rutynę?

To zależy. Jest to zwykle krok na drodze dewelopera.

1. Zacznij rzucać bzdurami, ugryź się w tyłek
2. Zacznij przebudowywać piekło od wszystkiego, zdaj sobie sprawę, że YAGNI
3. Osiedl się na pragmatycznym środku, gdzie łatwe rzeczy są spięte razem, a rzeczy trudne / prawdopodobne, które mają zapewnioną wystarczającą inżynierię, aby ułatwić pracę z / zmienić.

To tylko koleina, jeśli pozostaniesz pod numerem 2.

Jedną z rzeczy, o których zawsze lubię pamiętać, jest powiedzenie „przyszłość nie jest taka, jak kiedyś”.

Przy pewnym doświadczeniu pokusa wierzy, że możesz przewidzieć przyszłość, ale nie możesz. Łatwo jest wyobrazić sobie funkcje, które przyszli klienci / użytkownicy / cokolwiek mogą chcieć, ale to nie znaczy, że będą chcieli ich od razu. Nie oznacza to również, że będą chcieli mieć je nad jakąś inną sprzeczną funkcją. Naprawdę musisz ograniczyć ilość czasu, który spędzasz dziś, planując przyszłość. W szczególności musisz ograniczyć czas, który spędzasz na budowaniu rzeczy, które będą przydatne tylko w przyszłości.

Pytanie, które zadaję, które utrzymuje mnie w pozycji prostej i wąskiej, brzmi: „o ile trudniej będzie zbudować tę funkcję później niż w przypadku jej obsługi?” Zazwyczaj odpowiedź jest taka, że ​​przyszły wysiłek jest mniej więcej taki sam lub może dwa razy większy niż teraz. W takim razie, ponieważ nie mogę przewidzieć przyszłości, nie mam problemu z jej budowaniem. Jeśli odpowiedź wzrośnie do 10x lub więcej, zacznę pytać o to, jak prawdopodobne są ludzie, że będziemy potrzebować tego w ciągu najbliższego roku lub dwóch. Nawet wtedy, chyba że istnieje powszechna zgoda, ograniczam się tylko do upewnienia się, że nie trzeba cofać działań, które dziś robimy, aby osiągnąć ten cel w przyszłości.

Na przykład pracowałem nad kilkoma projektami, w których spędziliśmy dużo czasu wyodrębniając fakt, że później korzystaliśmy z Hibernacji jako dostępu do danych. (Nigdy nie widziałem, żeby projekt oparty na Hibernacji przestał go używać, więc na początku była to strata czasu, ale odłóżmy to na bok.) Nawet gdyby to była rozsądna możliwość, że moglibyśmy chcieć to zmienić później, ponieważ używaliśmy również wzorca obiektu dostępu do danych, nie byłoby trudniej zbudować elastyczności, aby zmienić Hibernację i zmienić ją w tym samym czasie, kiedy potrzebowaliśmy, niż było to możliwe od samego początku. W obliczu takiej sytuacji teraz odkładałbym tę elastyczność, dopóki jej naprawdę nie potrzebujemy.

Jeśli nie planujesz strategicznie dla dużej korporacji, nie warto nawet myśleć o kwestiach architektonicznych za dwa lub trzy lata, ponieważ technologia zmienia się tak szybko. Funkcja, o której dzisiaj myślisz, może być dostępna za darmo w wersji open source za dwa lub trzy lata. Niemal na pewno zmieni się analiza kosztów i korzyści.

Ogranicz się do zbudowania systemu, który robi to, czego potrzebujesz dzisiaj, z którego jesteś dumny i który z przyjemnością będziesz pracować za kilka miesięcy, bez względu na kolejną rundę zmian. Naprawdę to najlepsze, co możesz zrobić.

Oto mój osobisty proces eliminacji szalonych projektów, które (w pierwszej wersji) mogą okazać się niepraktyczne i zaszkodzić projektowi z perspektywy biznesowej.

1. Zidentyfikuj epicentrum : Pomyśl o swoim projekcie jako stoisku z hot-dogami, epicentrum to hot dogi. Możesz usunąć wszystkie inne przyprawy / dressingi / warzywa ze swojego stoiska i nadal być w stanie sprzedawać hot dogi. Jaki jest główny cel twojego oprogramowania? Wyodrębnij z niego co drugi dodatek i / lub wartość dodaną i skup się najpierw na epicentrum.
2. Powtarzaj sobie: „robienie tego później oznacza robienie tego lepiej” : sprawdź, gdzie to ma sens, i dodaj do tego małą notatkę „na później”. Jeśli zrobisz to dobrze i pomyślisz o jego zastosowaniu w rzeczywistości, skończysz z tym samym projektem, ale priorytetem będzie mapa drogowa.
3. Odrzuć-Odrzuć-Odrzuć : Niezależnie od tego, jaki masz moduł, uczyń go tak prostym / niezbędnym / czystym / uniwersalnym, jak to tylko możliwe (czasami można to osiągnąć bez usuwania funkcji). Jeśli nie możesz tego dalej uprościć, zacznij odsprzęgać elementy, które mogłyby żyć same i mieć cel. W końcu, jeśli nadal będziesz miał trochę tłuszczu, będziesz mógł go po prostu odciąć.
4. Oddziel „kod biblioteczny” od „kodu produkcyjnego” : zawsze będzie kod, którego nie można ponownie użyć, ale zawsze powoduje hałas w projekcie. Ten kod zawiera ten, który zawiera reguły biznesowe. Przekonasz się, że czasami niektóre reguły biznesowe są łatwiejsze i szybsze do zmiany ( niezwykle ważne ) niż przy solidnej konstrukcji. Znajdziesz kod, na którym możesz polegać, i kod, który klient musi zmienić lub ponownie wdrożyć w przyszłości. Będziesz chciał, aby były one rozdzielone tak, jak to możliwe.

A tak przy okazji, krok 0 brzmi: „oszalej na punkcie projektu”. Pomaga mi to wydostać się z mojego systemu i często znaleźć nowe implikacje, ukryte wymagania, a nawet nowe funkcje.

Wziąłem 1 i 2 z Rework .

Napisz testy. Skończysz, gdy wszystkie testy zakończą się pomyślnie: nie wcześniej, a na pewno niedługo potem w epickiej fazie nadmiernej inżynierii. Posiadanie zestawu testów dla pisanego kodu da niezależnego, bezstronnego obserwatora, który powie ci, kiedy możesz przestać.

Kiedy jesteś młody, nie widzisz ryzyka (być może powodem, dla którego młodsi politycy są przerażający), ale z wiekiem twoje złe doświadczenia paraliżują cię przy każdej okazji (być może powodem, dla którego starsi politycy są w stagnacji). Zastosuj podejście oparte na brzytwie Ockhama - wybierz rozwiązanie, które ma najmniej potrzeb, a następnie ewoluuj.

Są tylko dwie rzeczy, o których naprawdę musisz pamiętać podczas pisania i projektowania oprogramowania: łatwość konserwacji i poprawność.

Prawidłowość jest najważniejsza w perspektywie krótkoterminowej i można ją łatwo udowodnić za pomocą testów.

Utrzymywalność pomoże na późniejszym etapie rozwoju, ale trudniej jest ją określić.

Moja obecna strategia polega na tym, aby najpierw uzyskać monolityczny dowód koncepcji, a następnie oddzielić interfejs użytkownika od modelu (upewniając się, że model nie wie nic o interfejsie użytkownika), gdy tylko będę zadowolony, że jest on wykonalny. Gdybym zbyt długo czekał na ten krok, dostałbym coś nie do utrzymania. Jeśli zacznę od oddzielnych warstw, po prostu nie mogę zacząć, ponieważ utknąłem na tym, co interfejs użytkownika powinien wiedzieć o modelu.

Kiedy utknąłem w takich sytuacjach, odkryłem, że uparcie wyobrażam sobie, że jestem użytkownikiem końcowym używającym hipotetycznego programu do zrobienia czegoś dość trywialnego. Następnie staram się skupić na tym, jakie byłyby programowe punkty wejścia potrzebne do wspierania tych działań, starając się jak najbardziej zignorować inne aspekty systemu. Stąd często można zbudować (małą!) „Listę życzeń” funkcji gotowego systemu i napisać nierealistyczny kod, który zacznie to implementować. Po tym ćwiczeniu zwykle zaczynam, a reszta systemu staje się bardziej przejrzysta. Chodzi przede wszystkim o punkt wejścia - a punktem wejścia ogromnej większości oprogramowania są początkowe działania użytkownika końcowego z programem.

Myślę, że to syndrom, że zadania, które wykonujesz, są dla ciebie zbyt łatwe.

Kilka lat temu głównym wyzwaniem było napisanie kodu, który spełni dane zadanie. To właśnie w pełni zaangażowało twój umysł. Teraz twój umysł (twoje doświadczenie itp.) Pracuje bardziej efektywnie, a wykonanie tego samego zadania wymaga tylko części energii, która była wcześniej potrzebna. Właśnie dlatego kończysz w spirali głębokich myśli. Twój umysł broni się przed rutyną i walczy o wyzwanie.

Myślę, że powinieneś rozważyć zmianę pracy. Może powinieneś nauczyć się nowego języka programowania.

Miałem ten sam problem 15 lat temu. Chciałem napisać idealny, wielokrotnego użytku, uniwersalny ... kod, który sprawił, że rozwiązanie było znacznie bardziej skomplikowane niż to konieczne. Dziś widzę to jako złocenie . Bardzo pomogła mi rada kolegi:

• jeśli masz pomysł, co może poprawić funkcjonalność, uczyń go bardziej uniwersalnym, ... zapisz ten pomysł w osobnym pliku tekstowym „ideas.txt”, ale nie wdrażaj go teraz .
• realizuj pilne zadania.
• po sześciu miesiącach przejrzyj swój „ideas.txt” i przeanalizuj, które z tych zmian naprawdę przyniosłyby korzyści projektowi.

Jest to po prostu paraliż analizowany. Zdarza się wielu ludziom w wielu dziedzinach. Możesz się przez to przebić.

Odpowiedź brzmi - po prostu zacznij z nim ;-)

Publikuję na forum fitness i wiele razy ludzie piszą o różnych procedurach, starając się znaleźć dla nich idealny. Mówimy im, że po prostu zacznij szkolenie i pracuj zgodnie z planem. Chcesz stać się silniejszym, wykonywać ćwiczenia siłowe, a następnie dostosowywać rzeczy w miarę upływu czasu.

Kiedy masz duży program, a twój mózg pracuje w nadgodzinach - najpierw napisz kod dla prostych przypadków. Początkowo program musi zostać uruchomiony, następnie musi pobrać dane wejściowe itp.
Twoim zadaniem jest pozostawienie łatwych aktualizacji i refaktoryzacji później, ale kod MUSI być nie bardziej skomplikowany, niż musi być do wykonania danego zadania.

Pamiętaj, że w przyszłości refaktoryzacja kodu jest zgodna z nowymi priorytetami. Nie możesz przewidzieć wszystkich z góry, więc nie próbuj.

Kod do następnego zadania - TYLKO. Kod jest prosty i dobrze, więc w razie potrzeby można go łatwo refaktoryzować. Upewnij się, że program działa. Powtarzać.

Ponieważ „utkniesz” w przesadnym myśleniu o możliwych scenariuszach przypadków użycia przez użytkownika końcowego, jest coś do rozważenia, jeśli zamierzasz opublikować interfejs API i oczekiwać, że nieznane Ci osoby będą z niego korzystać. Po opublikowaniu interfejsu API musisz albo nadal go obsługiwać, nawet jeśli później zdasz sobie sprawę z tego, jak złe jest twoje pierwsze wydanie, lub musisz złamać kod każdego, być może nieznanego Ci, który napisał przeciwko niemu, ryzykując w ten sposób wyobcowanie je na cały przyszły czas.

Standardowym rozwiązaniem jest publikowanie z zastrzeżeniem, że interfejs API może zmienić się w jakikolwiek sposób w dowolnym momencie, dopóki nie zorientujesz się, czego potrzebują użytkownicy i co robią konsumenci API.

W tym rozwiązaniu myślę, że to twoje własne rozwiązanie. Napisz tylko małą rzecz, która robi jedną lub dwie rzeczy, może robi to dobrze, zachowując dla siebie zrozumienie, że wszystko, co zrobisz, może się zmienić w przyszłości.

Nie da się tego zrobić dobrze, aw niektórych przypadkach nawet ŻADNEGO z nich, kiedy zaczynasz, ponieważ projektowanie jest naprawdę odkryciem; pojawia się ostatni, a nie pierwsza rzecz do zrobienia.

Nie możesz od razu zaprojektować interfejsu API i nigdy nie musisz go łamać swoim klientom. Rozumiesz, dlaczego tak jest. Z tego samego powodu nie możesz pisać oprogramowania i nie musisz go wyrzucać i zaczynać od nowa z nowym podejściem.

Nie sądzę, że masz problem w tym sensie, że przypadkowo ewoluowałeś w coś mniej kreatywnego, produktywnego lub pożądanego. Myślę, że masz wysokie standardy, które przypadkowo niewłaściwie stosujesz do swojej sytuacji - powszechny błąd w myśleniu, że każdy popełnia.

Doświadczenie nigdy nie liczy się przeciwko tobie, chyba że staniesz się cynicznym znającym wszystko, zrobionym wszystkim, a to naprawdę brzmi jak przeciwieństwo twojej situtacji.

Mam kilka zdjęć, o których pamiętam, kiedy osiągam duże rozmiary. Jednym z nich jest zabawa z Lego. Złożyłem to w całość i rozebrałem do woli. To, co zaczynam, może nie być tym, co skończę. Surfuję i korzystam z możliwości, które przychodzą mi na myśl, gdy często podążam, często odtwarzając swoje cele od razu w mgnieniu oka ... oto czym jest kreatywność.

Drugi obraz to analogia, którą słyszałem, która opisuje prawdziwą naukę. Poszukujesz w ciemnym pokoju czarnego kota, którego może nie być. Jest to niepokojące tylko wtedy, gdy uważasz się za porażkę z powodu nie znalezienia tego kota. Nie ma innego sposobu na znalezienie czarnych kotów. To jedyna czynność, która je lokalizuje. Wszystko inne to jakaś forma posiadania tego, czego rzekomo szukasz.

Nie wiesz za dużo; nie wiesz wystarczająco! Dopiero niedawno zdałeś sobie z tego sprawę.

Nie myśl o swoich wyborach projektowych jako o czymś, co musisz zrobić „dobrze”, ponieważ nie ma „dobra” - jest wiele „błędów”, ale są też kompromisy (w szybkości wykonania, czas na ukończenie kodowania zadanie, rozszerzalność itp.). Kod, który napiszesz, jeśli dobrze przemyślany, nadal będzie miał różne mocne i słabe strony.

Celem powinno być osiągnięcie punktu, w którym zrozumienie tych mocnych i słabych stron w kontekście obecnego i przyszłego użytkowania i konserwacji nie jest znacznie trudniejsze niż pisanie kodu w pierwszej kolejności.

Więc nie unikaj głębokich myśli, ale pamiętaj, że potrzebujesz doświadczenia, a nie tylko myśli, aby zostać mistrzem w tego rodzaju projektach. Myśl, dopóki nie osiągniesz punktu, w którym nie jesteś pewien konkretnego wyboru, a następnie zastosuj to, co według ciebie jest najlepsze, wypróbuj je i ucz się od tego, jak poszło.

Ćwicz kodowanie. Wymyśl ćwiczenia lub znajdź je online i postaraj się je poprawnie zakończyć tak szybko, jak to możliwe. Gdy przyspieszysz, dodaj uwagi, takie jak łatwość konserwacji i wydajność. Przekonasz się, że odświeżanie koduje rzeczy, które nie zostaną wprowadzone do produkcji, i może pomóc ci wyjść ze strachu przed kodowaniem.

Pisz kodowanie w wolnym czasie, tak jak 10 lat temu, bez obaw i zabawy.

Zostań menedżerem zespołu i bezpośrednimi młodszymi programistami - którzy są teraz w takim samym stanie psychicznym, jak 10 lat temu.

Nie, jeszcze nie wiesz wystarczająco dużo.

Wzbogać swoją wiedzę np. O te proste zasady:

• KISS: Niech to będzie małe i proste.
• YAGNI: Nie będziesz tego potrzebować.
• Gorzej jest lepiej: Niektóre gorsze rozwiązania są lepsze pod względem łatwości konserwacji.

Nie przepełniaj inżynierii. Przygotuj się na zmianę dzięki umiejętnościom refaktoryzacji, ale nie koduj każdej możliwej zmiany w kodzie. Jeśli zauważysz, że z czasem klasa lub funkcja staje się zbyt duża, zmień ją. Dziel i rządź. Używaj interfejsów, używaj więcej funkcji. Jeśli uważasz, że podzieliłeś za dużo (tj. Stał się on bardziej wymyślny, ale mniej czytelny), cofnij ostatnią zmianę.

Podsumowując: Uczyń swój kod wystarczająco elastycznym, ale nie bardziej. Zamiast tego uelastycznij się, kup książkę o refaktoryzacji.

Dwie rzeczy:

1. Nie wystarczy dużo wiedzieć. Musisz mieć opinie na temat tego, co warto wdrożyć. Osobiście uważam TDD za kulę, która umożliwia złą architekturę. Biorąc pod uwagę dużą liczbę popularnych opinii, które działają przeciwko mnie, prawdopodobnie się mylę, ale czy wdrożenie TDD w JavaScript nie jest problemem, o którym myślałem, ponieważ debugowanie nigdy nie było dla mnie ogromnym bólem głowy i hej, nie byłby to pierwszy raz, gdy popularna opinia w społeczności programistów została później uznana za wadliwą po latach. Naucz się więc być aroganckim kutasem. Przynajmniej w środku. Możesz się mylić, ale przynajmniej angażujesz się w rzeczy, które działają dla ciebie, a nie w przemyślenia rzeczy, które mogą nie działać.

2. Wygląda na to, że zaczynasz od mikro. Zacznij od makra. Najpierw narzędzia, których potrzebujesz do robienia rzeczy, które musi zrobić Twoja aplikacja. Ta część powinna przyjść dość łatwo. Następnie zacznij od problemów związanych z architekturą / interfejsem. To, jak łączy się instalacja hydrauliczna i z czym się łączy, tak naprawdę powinny być cienkimi kawałkami wszystkiego, co możesz po prostu przesunąć na bok i zastąpić kaprysem. Podobnie ze szczegółami tego, jak się to robi. Odpowiednio zapakowane można je łatwo wymienić / edytować.

ale za każdym razem, gdy próbuję go zaatakować, kończę spiralę głębokich myśli

Nie ma w tym niczego złego. Zauważyłeś tylko, że nadszedł czas, aby ulepszyć swój proces: w tym przypadku proces myślenia.

Wiele osób gubi się w analizach lub jest śledzonych na inne sposoby i nawet tego nie zauważa. Zauważyłeś, że możesz zmienić proces myślenia, aby pozostać na dobrej drodze.

Istnieje wiele rozwiązań tego problemu, a najlepszym, jakie widziałem powyżej, jest ustanowienie ograniczenia czasowego. Zanim zaczniesz, zdecyduj, jak długo (1 godzina?) Poświęcisz analizie i myśleniu o tym. Ustaw minutnik.

Następnie, gdy zegar się wyłączy, rozpocznij kodowanie. Jeśli znów zbyt długo myślisz o rzeczach, po prostu podejmij natychmiastową decyzję. Cokolwiek zdecydujesz w tym momencie, jest właściwą decyzją. Zawsze możesz później wprowadzić zmiany i ulepszenia.

Poza tym nasze środowisko ciągle się zmienia. Często musimy aktualizować nasz kod, aby obsługiwał nowe wymagania, nową technologię, nowy sprzęt, aktualizacje języka i systemu itp.

Tak, ten kodujący horror zdarza się nawet dla mnie. Uderzenie przepełnieniem stosu. Kodowanie w szczegółach dla małej aplikacji. Ale kiedy jest to projekt zlecony na zewnątrz, nie zjada dużo czasu z powodu ograniczeń czasowych. Wydaje mi się, że praca z grupą nowych ludzi może się z tym pogodzić.

Nie jesteś wystarczająco bezwzględny

http://playswithfire.com/blog/2012/02/19/you-are-not-not-ruthless-enough/

Edycja: Celem tego artykułu jest zwrócenie uwagi na drobne szczegóły podczas opracowywania, ale odkryłem, że pomaga podejść do każdego prostego lub złożonego zadania z bezwzględną postawą, aby znaleźć jedno najbardziej skuteczne rozwiązanie i po prostu wykonać zadanie.