Co powinien wiedzieć każdy programista?


245

Co powinien wiedzieć każdy programista, niezależnie od zastosowanego języka (języków) programowania, systemu operacyjnego lub środowiska, dla którego opracowuje.

Niektóre tło:

Chcę zostać najlepszym programistą. W ramach tego procesu staram się zrozumieć to, czego nie wiem i bardzo by mi to przyniosło korzyść. Chociaż istnieje mnóstwo list w stylu „n rzeczy, które powinien wiedzieć każdy [wstawić język programowania]”, muszę jeszcze znaleźć coś podobnego, co nie jest ograniczone do konkretnego języka.

Oczekuję również, że te informacje będą interesujące i przynoszą korzyści innym.

Odpowiedzi:


636

Jak połknąć dumę i przyznać się do błędów, nie biorąc ich osobiście.


60
To jest coś, co każdy człowiek powinien robić bez względu na swoją pracę (... płeć, religię, kulturę, status społeczny ...), nie sądzisz? ;)

3
O tak. Ale programiści (przynajmniej ja) mają tendencję do dumy mają więcej niż większość jawnej :-)

17
Chciałbym móc dwukrotnie zagłosować.

4
Myślę, że tego nauczyłem się na uniwersytecie. W liceum zawsze byłem jednym z inteligentnych dzieci. Gdybym nie poszedł na studia, pomyślałbym, że jestem całkiem sprytny i mam duże ego. Idąc na uniwersytet i wchodząc w interakcje z ludźmi, którzy byli naprawdę bardziej wykwalifikowani, pomogło mi zobaczyć, jak głupi jestem
Kibbee

4
Chociaż jest to bardzo prawdziwe, problem nie zawsze jest zaprzeczeniem lub wielkim ego, ale potencjalnymi konsekwencjami otwartego przyznania się do popełniania błędów, przynajmniej nie bez pewnego rodzaju samoobrony / kontroli szkód. Czasami jest to kwestia kulturowa. :)

309

Jak myśleć jak użytkownik, a nie jak programista-geek.


2
Ironiczne jest dla mnie to, że wydaje się, iż to, czego wydaje się większości z nas w branży, może być jedną z najważniejszych umiejętności: umiejętności komunikacyjnych.

Nie mogłem się z tym bardziej zgodzić. To powinien być numer 1.

23
Właściwie się nie zgadzam. Do tego zatrudniasz ludzi. Nigdy nie będziesz w stanie myśleć jak użytkownik, ale z pewnością możesz powiedzieć, co użytkownicy myślą i postępują zgodnie z tą radą. Tylko nie pytaj użytkowników, jak myślą! To najgorsza opcja ze wszystkich.

1
Możesz zatrudnić innych ludzi, aby to zrobili, ale jeśli Twój zespół programistów zrozumie, jak myśli użytkownik, to będziesz miał o wiele mniej argumentów i iteracji, zanim wszystko pójdzie dobrze. Dodatkowo, jeśli programista może myśleć jak użytkownik, który wie, jakie nowe funkcje wymyślą

3
Użytkownik może równie dobrze być programistą technologicznym, ale rzadziej programistą technicznym, który również zaimplementował kod . Jeśli aplikacja ma bardzo subtelną i złożoną semantykę / zachowanie, osoba, która napisała kod, może być jedyną osobą, która może zrozumieć, jak korzystać z aplikacji ...
Reuben

244

Kiedy prosić o pomoc, a kiedy NIE prosić o pomoc.


2
Tak prawdziwe. Ostatnio odpowiedź pojawiła się w mojej głowie, gdy kogoś pytałem. :(
kevindaub,

więc jaka jest odpowiedź?)

28
Najpierw spytaj swojego gumowego kaczuszka. Jeśli nie może ci pomóc, poproś kogoś innego ...
Dean Rather

3
entuzjastycznie, ponieważ kiedy zaczynałem, nie zdawałem sobie sprawy z tego, jak bardzo denerwuję innych programistów, ciągle zadając im proste pytania, które powinienem wymyślić, dopóki nie zrobię tego n00b.

1
Zawsze zadaję sobie pytanie w stylu „Co powiedziałby mój kolega, gdybym je zadał”. Zwykle pomaga mi to rozwiązać problem, zanim muszę o to zapytać.

184

Jak czytać kod innych osób.


102
Dodatek: Jak pisać kod, który inni mogą czytać

42
Dodatek 2: Jak odczytać własny kod 6 miesięcy później

10
@Nathan Koop: Powinno być lepiej „Jak napisać kod, abyś mógł go przeczytać 6 miesięcy później”.
Doc Brown,

4
Gdy minęło 6 miesięcy, stał się już kodem innej osoby. W tym sensie, że od tego czasu ewoluowałeś, stałeś się lepszy i równie dobrze mógł to być ktoś inny, kto to napisał, więc traktuj to jako takie.
MPelletier

7
Dodatek 3: Jak odczytać kod 6 minut później.
mpen

152

Znajomość systemów kontroli wersji. Nie musi to być każdy, ale podstawowe pojęcia, które można zastosować do wszystkich z nich, powinny być znane.


a kontrola wersji nie jest oprogramowaniem
jrhicks,

4
Dodałbym, że istnieje znacząca różnica między scentralizowanymi SCM (np. Subversion, CVS) i rozproszonymi SCM (np. Git, mercurial, bazar), że ważne jest, aby nauczyć się jednego z nich.
intuicyjnie

128

Oto moje 10 bitów:

  • Jak być pokornym. Wszyscy jesteśmy tutaj, aby się uczyć. Możesz być mądrzejszy od innych, ale jest wielu ludzi mądrzejszych od ciebie.
  • Jak studiować / konsumować informacje. Nie wiem o tobie, ale zawsze się uczę! Książki, Internet, cokolwiek!
  • Czym jest słownik i jak go używać oraz jak szybko znaleźć akronimy.
  • Jakie są podstawowe narzędzia handlu i co robią (IDE, CVS i in.).
  • Poznaj wspólną terminologię i co one oznaczają: wzorce projektowe, użyteczność, testy (ha!), Stos itp.
  • Zrozumieć OOP.
  • Bądź „zdolny” w co najmniej jednym języku, nic niesamowitego, po prostu umieć identyfikować zmienne i metody itp. Stąd możesz uczyć się SZYBKO.
  • Zrozum, że ludzie ostatecznie używają oprogramowania i chcą ich uszczęśliwić.

38
To musi być ósemkowy post.
Nawet Mien

10
Jeśli chodzi o pierwszy kawałek ... „Nie bądź taki pokorny, nie jesteś taki wspaniały”.
Magnus

@TheOtherScott, nice catch lol, ale tak naprawdę mówiłem 2 bity: D;)

3
Odnośnie do punktu 3: www.acronymfinder.com
Jasper Bekkers,

1
@ jasper / intuited: wystarczy wpisać akronim w google, a wyświetli się jeden lub drugi ... odpowiedź i tak zwykle jest w jednym z pierwszych 10 wyników. więcej informacji można uzyskać klikając!
mpen

104

Może to zbyt subtelne, ale myślę o tym jako o „wiedzeniu, który problem rozwiązać”. Wielu programistów (i normalni ludzie) marnuje ogromny wysiłek na rozwiązywanie rzeczy, które po prostu nie są bardzo ważne; lub tworzą rozwiązanie z dużą ilością dodatkowej pracy, która nie do końca jest potrzebna.


4
Uzgodnione, martwienie się o skrajne scenariusze przypadków użycia, które napotka tylko garstka użytkowników zamiast większej liczby podstawowych funkcji, jest zbyt powszechną pułapką! Nadal uczę się tego na własnej skórze ...
Ian Robinson

Powinienem umieścić link do twojej odpowiedzi jako strony głównej mojego byłego lidera zespołu. Masz absolutną rację.

4
Uwielbiam to, że powiedziałeś „wielu programistów (i normalnych ludzi)” :-)

95

Jak się zrelaksować. To sekret wydajności.

W końcu siła woli i kofeina nie wystarczą. Ten ciągły skurcz, który wywołujemy, jest bardzo szkodliwy.

To wielka sprawa.


1
Co rozumiesz przez skurcz?

4
@ Jaj: Czasami, kiedy pracuję, mogę być całkowicie zrelaksowany i bardzo produktywny. W moje złe dni biegam po adrenalinie i kofeinie i odczuwam ogromne napięcie w moim ciele. Jeśli zwracam baczną uwagę, to faktycznie zaciska mi się mięśnie. Cały czas zauważam to napięcie u innych. Niestety może to prowadzić do różnego rodzaju problemów, takich jak wypalenie zawodowe i choroby serca, i prawdopodobnie prowadzi również do utraty wydajności netto, ponieważ można biegać tylko przez określony czas. O tym skurczu mówię.
Brian MacKay,

@ Egg, oznacza skurcz nieużywanych mięśni.

2
Mówiąc o kawie i skurczach, czy wiesz, że kawa kurczy tętnicę, dostarczając krew do mózgu. To powoduje, że mózg się budzi. Kawa wcale nie jest taka dobra. tl; dr pij wodę
Reno

83

Podstawowe typy danych i teoria algorytmów. Rzeczy takie jak notacja Big O, tablice, kolejki itp.


Nie pomaga ci wcale, jeśli wszystko, co robisz, to tworzenie szablonów dla systemów zarządzania treścią internetową.

3
No cóż, w bibliotekach / frameworkach zaimplementowane są standardowe algorytmy, ale zgadzam się, że niektóre twarde algorytmy są użyteczne, ale niezbyt często

7
Tylko dlatego, że są już zaimplementowane, nie oznacza, że ​​nie musisz rozumieć, czego użyć, kiedy złożoność gwarantuje itp. To ważne rzeczy stojące za algorytmami.

3
Uzgodniono z Gregiem Rogerem. Być może trzeba zaimplementować algorytmy, ale lepiej zrozumieć ich złożoność i kompromisy. Na przykład. Niektóre algorytmy zajmują więcej pamięci, ale są szybsze.

6
Nie będziesz wiedział, którego użyć, jeśli ich nie rozumiesz. Algorytmy są bardzo ważne.

60

Jak wybrać odpowiednie narzędzie do właściwego zadania i nie brać udziału w głupich płonących wojnach o jego ulubione narzędzia programistyczne.


+1, aby ten nie został na 42 :)
CharlesB

54

Cóż, oto moje .02 $:

  • Nauka nigdy się nie kończy. Bez względu na to, jak dobry jesteś, zawsze jest ktoś lepszy od ciebie i zawsze możesz coś poprawić w sobie. Jeśli przestaniesz się uczyć, nieuchronnie ulegniesz degradacji jako programista. Czytać książki. Czytaj blogi. Porozmawiaj z innymi programistami.
  • Spróbuj nauczyć się kilku języków. Co najmniej jeden z nich jest obiektowy. Powinieneś także wiedzieć coś o różnych technologiach związanych z językiem, którego się uczysz (np. Jeśli uczysz się Javy, byłoby miło, gdybyś wiedział coś o Spring i tak dalej ...).
  • Refaktoryzacja. Wcześniej czy później będziesz potrzebować tej wiedzy.
  • Dowiedz się, jak radzić sobie ze starszym kodem.
  • Napisz testy jednostkowe. Dowiedz się więcej o TDD.
  • Naucz się pracować w zespole.
  • Napisz elegancki i czytelny kod. Jak mówi stare powiedzenie: „Napisz kod tak, jakby osoba, która go utrzyma, jest psychotycznym seryjnym zabójcą, który wie, gdzie mieszkasz”.
  • Dowiedz się, jak być leniwym i zdyscyplinowanym jednocześnie. Dobrzy programiści posiadają obie te cechy. Dziwne, jak się wydaje, nie są ze sobą sprzeczne, ale się uzupełniają.

Czy to twoje 0,02 dolarów czy 0,02 centów? LOL! :-D

„Napisz swój kod tak, jakby osoba, która go utrzyma, jest psychotycznym seryjnym zabójcą, który wie, gdzie mieszkasz”. +1
Ben

50

Nie można przetestować jakości produktu.


2
Dlatego specjaliści „Quality Assurance” mają złą nazwę.

1
Technicznie rzecz biorąc, QA i Test to nie to samo, chociaż nie jestem pewien, czy większość organizacji faktycznie ćwiczy różnicę.
Wysoki Jeff

5
Ostatnio napotkany - i utknął: „Wynikiem testów nie jest jakość, ale wiedza”.
peterchen

richdiet: ekspert SQA James Bach uważa, że ​​„A” w SQA / QA powinno oznaczać „Assistance”. Zdecydowanie zgadzam się z jego opinią i twoim oświadczeniem.

44

Każdy programista powinien zrozumieć wzorce projektowe .


13
Dodałbym, że potrzebują również zrozumienia, że ​​nie wszystko da się zawrzeć w butach w danym wzorze.
tloach

10
Dodałbym również, że nie każdy programista powinien rozumieć wzorce projektowe. W odległych krainach istnieją języki, które mają inne funkcje tak potężne, że myśl płynie bezpośrednio z programisty do działających programów. W tych językach celowe wzorce są błędnym kierunkiem.
Ali

2
wzorce projektowe są na nie desingers „programistów” - programista musi wiedzieć, że kiedy on / ona staje się „projektant”

10
Istnieją dwa rodzaje ludzi: ludzie, którzy lubią kodować i ludzie, którzy wolą mówić o kodowaniu. Wzory projektowe są koniecznością dla drugiej grupy.
Bjorn Reppen

1
Takie wzorce są sposobem na przezwyciężenie ograniczeń językowych. Programista powinien je zrozumieć tylko dlatego, że powinien zrozumieć i być w stanie pokonać słabości swoich języków.

44

Trochę się spóźniłem, ale pójdę z wiedzą podaną przez Edsgera Dijkstrę:

Oprócz matematycznej skłonności, wyjątkowo dobra znajomość języka ojczystego jest najważniejszym atutem kompetentnego programisty.

Jeśli nie możesz napisać dobrego akapitu, prawdopodobnie nie możesz również napisać dobrego kodu.


8
Jestem jednak zaskoczony straszną pisownią, gramatyką i interpunkcją używaną przez niektórych programistów w pisaniu w języku naturalnym. Można by pomyśleć, że codzienna praca z systemami, które mają zerową tolerancję na błędy ortograficzne i niepoprawną składnię, miałyby korzystny wpływ ...

1
@cheduardo, ponieważ po skompilowaniu lub uruchomieniu programu w większości języków zostaniesz poinformowany o wszelkich błędach w pisowni, gramatyce lub interpunkcji, które następnie można łatwo poprawić. Nie dotyczy to błędów logicznych.
Inshallah

@Inshallah: chyba że robisz coś takiego if (BlowUpTheSystem = 1). To prawda, że ​​przy odpowiednich testach jednostkowych prawdopodobnie zaoszczędzisz tylko czas. Ale czas jest bardzo ważny.
intuicyjnie

2
Zgadzam się ... hmm ... pomijając część „ojczystego języka”, niektórzy z nas [niestety?] Komunikują się lepiej / wyraźniej w naszych językach obcych.

39

Nie angażuj się zbyt emocjonalnie, przywiązany ani religijny na temat jakiejkolwiek technologii, systemu operacyjnego lub języka - żaden z nich nie jest idealny - na dłuższą metę prawdopodobnie skończysz z marzeniem, aby stworzyć własną kartę ala carte z tego, co masz jak o każdym innym.

Pomyśl o tym jak o samochodach - być może wcześniej nie jeździłeś konkretnym samochodem, ale wszystkie mają kluczyki, kierownice, pedały przyspieszenia i hamulce - powinieneś być w stanie wsiąść do jednego i szybko odjechać po ustaleniu, gdzie jest. Traktuj systemy operacyjne i języki w podobny sposób i skup się na poznawaniu podstawowych pojęć leżących u ich podstaw, nawet jeśli masz ochotę poznać specyfikę danego wystąpienia.

Z czasem staraj się zrozumieć i docenić pochodzenie, dziedzictwo i cechy wspólne różnych technologii, które pomogą ci zachować perspektywę. Uświadom sobie na przykład, że podczas gdy drzewo ewolucyjne aktywnie rozgałęzia się i jest pełne ślepych zaułków, z czasem technologia często zbiega się wokół „najlepszych praktyk” i „korzyści skali” ( np. Zauważ, że Mac nie jest aż tak różny od Komputer pod maską w dzisiejszych czasach ...).

Na koniec pamiętaj, bez względu na to, jak dobrze się bawisz z tym wszystkim, technologia zasadniczo stanowi niedoskonały obiektyw między tym, co twój umysł może sobie wyobrazić, a tym, co faktycznie produkujesz. Daj z siebie wszystko, naucz się uczyć i pozostań elastycznym ...



35

Dzień, w którym przestaniesz się uczyć, powinien być dniem, w którym nie jesteś już programistą.


Gdybym miał jedno życzenie, Mikołaj byłby moim ojcem.

Ponieważ Święty Mikołaj ...?

1
Dzień, w którym przestaniesz się uczyć, powinien być dniem, w którym umrzesz. :) W każdym razie +1
ShdNx

Więc żeby żyć wiecznie, zawsze musisz się uczyć? Teraz jest pomysł, który mogę poprzeć!
canadiancreed

34

Testowanie i debugowanie jednostek.


Pierwszy eliminuje potrzebę drugiego. ;-)

4
Nie, gdy test jednostkowy się nie powiedzie, wymaga to debugowania. Obie idą w parze.
Zan Lynx,

Nie mogę tego wystarczająco podkreślić.
fastcodejava

33

Zostało to wspomniane wcześniej, ale myślę, że zasługuje na własną odpowiedź.


Coraz częściej go używam i zbieram tu i tam, ale wciąż nie jestem nawet amatorem.

Całkowicie się zgadzam. Wydaje się to dziwne i trudne, gdy go nie rozumiesz, ale kiedy go rozumiesz, jest to o wiele łatwiejsze niż tona wywołań funkcji substring / indexof, które byłyby konieczne, aby zrobić to samo inaczej. Chciałbym tylko upewnić się, że twoje wzory są dobrze skomentowane.
Kibbee

9
Niektórzy ludzie, gdy napotykają problem, myślą: „Wiem, użyję wyrażeń regularnych”. Teraz mają dwa problemy. - „Jamie Zawinski”: jwz.livejournal.com , w comp.lang.emacs
Bjorn Reppen

Korzystanie z edytora zbudowanego wokół nich jest dobrym sposobem na nauczenie się paskudnego, drobnego ziarenka. Mam doświadczenie z vimem - który używa w większości porównywalnego odpowiednika de facto standardowych PCRE - ale mam wrażenie, że te same zasady obowiązują w świecie emacsa.
intuicyjnie

1
Niektórzy ludzie w konfrontacji z wyrażeniem regularnym myślą: „Wiem, zacytuję Jamiego Zawińskiego”. Teraz mają dwa problemy (jednym z nich jest to, że prawdopodobnie nie wiedzą, co robią w pierwszej kolejności) .
Donal Fellows

29

Nikt nie chce używać oprogramowania. Chcą rozwiązania problemów.


7
Dokładnie. Kiedy słyszę, jak programiści próbują wyjaśnić bazę danych użytkownikowi końcowemu jako odpowiedź na pytanie, dlaczego czegoś nie można zrobić, kulę się. Nie muszą wiedzieć, jak robimy różne rzeczy. Chcą tylko, żeby to działało. I tak powinno być.
Kevin Fairchild

Lubię wierzyć, że można pisać oprogramowanie, z którego korzystanie ma przyjemność.

Nie można zgodzić się więcej. Dotyczy to jednak również interfejsów API. Nikt nie chce uczyć się nowych interfejsów API, ponieważ jest to tak cholernie zabawne. Chcemy funkcjonalności interfejsu API, a nie kodu, który reprezentuje.
Blub

Kevin, chciałbym, żeby nasz „programista wdrożeniowy” (eleganckie słowo do testowania faceta) przeczytał i zrozumiał to. Ja też siedzę za biurkiem, mając nadzieję, że świat go pochłonie, gdy zacznie mówić o pętlach i wypowiedziach użytkowników końcowych.

27

Kawa i IntelliSense są twoimi najlepszymi przyjaciółmi.


Chciałbym móc przekazać to więcej niż 1 głos!
Dina

Mam nadzieję, że napiję się więcej kawy !!!! ñ_ñ

Myślę, że zgadzam się z tym bardziej niż jakąkolwiek inną rzeczą na SO.
Unkwntech,

Praktycznie nigdy nie piję kawy, chyba że absolutnie muszę zakończyć projekt w X godzin, kiedy: Liczba zużytych godzin + X> 8 na dzień.
Blub

Kawa nie daje energii. Po prostu wyciśnij część z twoich wewnętrznych rezerw. To źle / niezdrowo.
Andrei Rinea

18

Jak obserwować duży skomplikowany obiekt i rozkładać go na małe proste obiekty, które wciąż wykonują to samo zadanie po ponownym złożeniu.


18

Nigdy nie ufaj użytkownikowi ( zwłaszcza jeśli aplikacja jest publiczna!), Często zrobi wszystko, co w jego mocy, aby złamać twoją aplikację w taki czy inny sposób.

Spraw, by był przyszłościowy i rozbudowy - nigdy nie wiesz, kiedy chcesz go rozwinąć za kilka lat i zdajesz sobie sprawę, ile wysiłku wymagałoby ponowne kodowanie źle utworzonego kodu.


1
To jest zbyt ogólne. Pewien pragmatyzm jest również dobry.
mafu

18

Że programista nie wie wszystkiego i powinien zawsze starać się uczyć nowych języków / technologii itp.


16

Podstawy dobrego projektowania interfejsu użytkownika i projektowania komunikacji (aka grafiki) .

Widzę wiele aplikacji i projektów zrujnowanych przez zły projekt lub słabą użyteczność. Już sama nauka podstaw może zmienić świat. Plus wizualne techniki rozwiązywania problemów (tj. Wizualne komunikowanie koncepcji) są stymulującym wyzwaniem, które powinno otworzyć oczy na nowe sposoby widzenia, które z kolei powinny mieć wpływ na kod.

Zalecaną książką jest The Non-Designer's Design Book autorstwa Robin Williams

Oto, co mówi o tym Joel Spolsky :

Łał! Każdy musi wykonać jakieś projekty graficzne i nie każdy zespół programistów ma luksus profesjonalnych projektantów. Ta doskonała, cienka książka pozwoli ci zapoznać się z zasadami dotyczącymi układu strony, czcionek itp. Dobrą wiadomością jest to, że możesz przeczytać ją w wannie, zanim woda się ochłodzi, a następnego dnia okna dialogowe i punkty PowerPoint i strony internetowe zaczną wyglądać lepiej.


1
Popieram to dodatkowym ukłonem w stronę „projektowania codziennych rzeczy”. amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

Każdy programista powinien umieć szybko się uczyć. Wiele razy wchodzisz do pracy i będziesz proszony o opracowanie technologii, której nigdy nie używałeś. Mogą dać ci tydzień na wstanie (jeśli masz szczęście), zanim zostaniesz poproszony o napisanie kodu jakości produkcyjnej.


Zacząłem swoją pierwszą pracę programistyczną i w ciągu tygodnia pisałem kod, który w końcu miałby zostać uruchomiony. Na szczęście jestem szybkim uczniem i miałam doświadczenie w programowaniu. W ciągu 6 miesięcy zrestrukturyzowałem połączenie klient-serwer, aby zwiększyć wydajność trzykrotnie. To było w języku, którego nigdy wcześniej nie używałem.

14

Kontrola wersji. Cytując moją przyjaciółkę: „Nie chcę tylko, żebyś zmywał naczynia, chcę, żebyś to lubił !”


10

Wymagania się zmieniają, twój kod będzie musiał się dostosować i to Ty możesz go nie dostosować.

Pojawiło się tutaj kilka pytań związanych z tematami, których to dotyczy.


10

Z czubka mojej głowy:

  1. Bardzo niewiele problemów programistycznych wymaga matematyki poza dodawaniem, odejmowaniem, mnożeniem i dzieleniem. Jeśli zastanawiasz się nad użyciem rachunku różniczkowego do rozwiązania problemu, dokładnie zapoznaj się z alternatywami.

  2. Za każdym razem, gdy zastanawiasz się, jak coś powinno działać, robisz to źle. Telepatyczne nie jest twoim zadaniem.

  3. Osoba podająca specyfikację rzadko wie wszystko, czego chce, dopóki tego nie rozwiążesz.

  4. Ponad połowa bycia świetnym programistą pochodzi z kontaktu z ludźmi. Połowa interakcji z zespołem, zarządzanie menedżerem i kłopoty z końcowym użytkownikiem.

  5. Dobry kod jest pisany do odczytu przez ludzi tak samo, jak do odczytania przez kompilator.

  6. Najlepsze praktyki i rzeczywistość praktyczna będą w konflikcie bardziej niż myśli programista, ale mniej niż kierownik. Kiedy wydają się być w konflikcie, to do ciebie należy wytyczenie i zrozumienie konfliktu, a następnie poddanie się praktyce. Subtelne i sprytne rozwiązanie jest lepsze tylko od brzydkiego, brutalnego rozwiązania, jeśli na dłuższą metę jest bardziej opłacalne.

  7. Świetne narzędzia nie potrafią zrobić wspaniałych programistów, ale złe narzędzia sprawiają, że jesteśmy równie okropni.

  8. Nigdy nie patrz w dół na technologię, ale zawsze szukaj najlepszej alternatywy.

  9. Im więcej języków znasz, tym lepiej będziesz w tym, którego używasz.

  10. Nie przeszkadza ci powolne wkradanie się myśli programistycznych w codzienne życie. Nawet gdy nie jesteśmy przy komputerze, wszyscy cierpimy z powodu ograniczeń przepustowości, ponosimy kary wydajnościowe za przełączanie zadań i musimy ładować rzeczy z magazynu kopii zapasowych. Komputery mają naśladować ludzką myśl, a analogi są wszędzie.


Numer 10 rozśmieszył mnie. Tak wiele razy będę pracować nad problemem w pracy, ale dopiero w łóżku o 22:00 w końcu wymyślę odpowiedź!

9

Czytanie kodu innych ludzi nie zepsuje twojego mózgu, ale raczej zrozum, dlaczego nie zrobiłbyś tego w ten sposób (jeśli jest to lepsze czy nie, to inne pytanie).

To daje ci programowanie gedankeneximent , a czasami możesz znaleźć kogoś, kto wdraża coś znacznie lepszego! Jakby o wiele lepiej.

Ta odpowiedź w naturalny sposób rozszerza się na czytanie własnego kodu, dlatego rozszerza się na użycie kontroli wersji i DIFF, a tym samym na 42.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.