Kiedy ktoś mógłby zostać uznany za złego programistę? [Zamknięte]


57

Jak byś pomyślał, że programista jest zły w tym, co robi?

Jeśli to możliwe ... Jak powinien poprawić?


3
Ponieważ wspomniana osoba nie przyjmuje odpowiedzi na stronie internetowej poświęconej programowaniu. Żartuję :-)
Daniel

1
@EvanKroske: Nie, to nie jest poprawne .... Społeczność Wiki istnieje, aby umożliwić wspólną edycję postów. Zobacz także: Our Meta - Tag: community-wiki
Tamara Wijsman

W wielu pytaniach nie można zaakceptować jednej odpowiedzi. Zobacz także: Nasza meta - Szukaj: zaakceptuj
Tamara Wijsman,

Nie każde pytanie otrzymuje odpowiedź, która faktycznie rozwiązuje problem.
Loren Pechtel

Odpowiedzi:


134

Kiedy nie uczą się na własnych błędach i na podstawie recenzji.

W pewnym momencie wszyscy jesteśmy zieleni; Jeśli jednak nie poprawiasz się lub nie próbujesz się poprawić, jesteś złym programistą.


4
Zgoda - musisz mieć pętlę informacji zwrotnych, zawsze ucząc się na własnych błędach.
Marcel Lamothe

1
@PSU dobrze powiedziane. Podobnie jak w przypadku każdego rzemiosła, programiści są rzemieślnikami i nie są doskonali, zawsze uczą się, ale jeśli nie uda ci się uczyć na błędach, nie poprawisz swojego rzemiosła.
Chris

2
To bardzo szeroka definicja; nie ogranicza się to do programistów. Dotyczy to naukowców, kucharzy, sportowców, tłumaczy, dozorców, fotografów i każdego zawodu.
RegDwight

13
Wszyscy są kretynem przynajmniej raz w tygodniu.
MIA

@RegDwight: a twoim celem było ...?
SamB

125

Programista, który nie wie, czego nie wie i wcale go nie interesuje, aby się dowiedzieć.


16
Gdybym mógł poprzeć to 100x, zrobiłbym to. Na dłuższą metę odrobina pokory i głodu nauki.
William Pietri

1
+1 dla Ngu i Williama. Jest to najbardziej typowe kryterium złego „programisty”.
fabrik

Co się stanie, gdy dowiesz się, że nie znasz DUŻO i chociaż tak bardzo się starasz, nigdy nie poznasz większości?
Steven Evers

@snOrfus, odnajdujesz mentora, który cię nauczy ...

75

Dużym znakiem ostrzegawczym jest to, że są programistami „kultu kultu” - co oznacza, że ​​robią rzeczy, ale nie wiedzą, dlaczego to robią (to po prostu „magia”). Świetny post Erica Lipperta tutaj .

Z artykułu:

programiści, którzy rozumieją, co robi kod, ale nie wiedzą, jak to robi.

3
* i od dłuższego czasu programuje w tej technologii
Joe Phillips

5
Dotyczyłoby to prawie wszystkich programistów, którzy kiedykolwiek zajmowali się tworzeniem stron internetowych przy użyciu frameworków takich jak Java / Spring lub Ruby on Rails. Ramy te są pełne czarnej magii, której normalni programiści zwykle nie zawracają sobie głowy.
missingfaktor

3
@Missing Faktor - i dlatego nie byłoby tak niedokładne stwierdzenie, że większość programistów, którzy to robią, nie są świetnymi programistami :)
seanmonstar

14
Z drugiej strony nierealistyczne jest zakładanie, że programiści powinni w pełni zrozumieć wewnętrzne funkcjonowanie frameworka, maszyny wirtualnej lub czegokolwiek, na czym budują kod. (Lub, tak naprawdę, szczegóły wszystkich warstw abstrakcji poniżej, aż dojdzie do gołego metalu.) Możesz być doskonale dobrym, produktywnym programistą, nawet jeśli znasz tylko najbardziej odpowiednie części.
Jonik

4
@Missing Faktor: oni nie mogą zrozumieć wewnętrzne bibliotek i ram, które używają dokładnie, ale powinien przynajmniej wiedzieć, co każda rzecz w ich kodu: „do Snark z frobber”, „ponieważ dokumentacja mówi, że jest to potrzebne do zachowania integralności kontinuum czasoprzestrzennego ”itp.
SamB

45

Ważną wskazówką jest dla mnie to, że zadają oni tobie lub innym programistom pytania programistyczne, które wyraźnie pokazują, że podjęli absolutnie zerowy wysiłek, aby je rozwiązać.

Następstwem jest wielokrotne zadawanie tego samego pytania programowego, co oznacza, że ​​nie internalizują informacji.


Ach tak, pracowałem z nim. Na szczęście czas przeszły.
Mike Woodhouse

1
Niektórzy nawet nie są w stanie zadawać porządnych pytań, prosząc cię o „po prostu napraw”
deltreme,

21

Kiedy zajmuje im dużo czasu, aby rozwiązać problem FizzBuzz.


1
Myślę, że mogą być początkujący, którzy mogą być dobrymi programistami - którzy mają z tym problem.
JD Isaacks,

2
Początkujący są w porządku, jeśli szukasz młodszego programisty, którego chcesz uformować i uformować w dobrego. Ale ten problem jest tak trywialny, że pisanie nie powinno zabierać nikomu doświadczenia.
Matt DiTrolio,

8
Twierdziłbym, że rozwiązanie tego problemu nie powinno zająć nikomu, kto pomyślnie ukończył kurs programowania podstawowego.
EpsilonVector,

4
Jeśli początkujący nie może rozwiązać FizzBuzz, nie powinien ubiegać się o zadania programistyczne. Jeśli twierdzisz, że możesz programować (np. Ubiegając się o pracę programistyczną), powinieneś być w stanie rozwiązać FizzBuzz.
Chinmay Kanchi,

1
Warto sprawdzić pytanie Stackoverflow na FizzBuzz. Sprawdź rozwiązanie python, które nie wykorzystuje podziału ani modułu. stackoverflow.com/questions/437/…
Gordon

21

Programiści, którzy nie chcą uczyć się nowych technologii / języków i nalegają, aby trzymać się tego, co już znają.


Dodatek: (dodając myślnik poniżej w komentarzach)

Rozszerzeniem tego są ludzie, którzy znają podzbiór funkcjonalności niektórych technologii, ale nie wykazują chęci, aby dowiedzieć się o nim czegoś więcej. Język programowania, edytor, inne narzędzia ...


6
... i bez dobrych powodów, powinienem dodać.
missingfaktor

18

Gdy członek zespołu jest programistą produkującym negatywnie .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Oznacza to, że reszta twojego zespołu musi wykonać więcej pracy z powodu złego programisty. NNPP


1
Zgadzam się - ci ludzie mogą być bardzo niszczący dla swojego zespołu.
Marcel Lamothe

44
Huh ... Wczoraj usunąłem 500 wierszy zbędnego kodu i nie wprowadziłem błędów. LOC Metrics uważany za szkodliwy?
Piskvor

5
Większość wskaźników jest okropna, a wskaźniki LOC są zwykle bardziej bezużyteczne. Chodzi o to, że zły programista to ktoś, kto tworzy więcej pracy dla zespołu niż on / ona wykonuje.
danivovich,

5
Dane LOC nie są bezużyteczne. Są SZKODLIWE. Poza tym liczenie LOC jest bardzo trudne w większości współczesnych języków. Ale nie chodzi tu o dane. To tylko mówi | Praca nad tworzeniem | - | Praca, która była zła | - | praca nad naprawą | ... tj. jeśli zajęło ci 10 godzin, z czego spędziłeś 6 godzin pracując nad czymś, co ostatecznie musiało zostać naprawione i zajęło Ci to 6 godzin, to masz -2 godziny. W każdym razie tak naprawdę starasz się uzyskać czas.
MIA

1
Wskaźniki LOC to świetny sposób mierzenia, w ilu miejscach muszą się ukrywać błędy.
SamB


15

Kiedy wiedzą, że istnieją lepsze sposoby robienia rzeczy, ale nadal odmawiają ich wykonania, nawet jeśli pozwala na to czas.


Ale mogą istnieć nieporozumienia ekspertów dotyczące tego, co jest „lepsze”.
DarenW

@DarenW - Nie powiedziałbym, że ktoś jest złym programistą, ponieważ opowiedział się po kontrowersyjnym temacie, ale kiedy ma ostateczny wybór we własnym umyśle.
JeffO,

15

Osobiście uważam, że każdy programista, który potrafi spojrzeć na własny kod, który napisał jakiś czas temu i nie znajduje w nim nic złego, nie jest dobry. „Chwilę” można skalować wraz z doświadczeniem ... Powiedziałbym, że od kilku tygodni do roku.


5
Co jeśli nie mogą znaleźć niczego złego, a to ich martwi?
SamB

1
Albo gorzej, nie mogą znaleźć niczego złego i próbują to naprawić.
Toon Krijthe

15

Ci, którzy ignorują ostrzeżenia w swoich kodach i dbają tylko o błędy.


14

Kiedy byłem liderem zespołu w małym sklepie, było kilku ludzi, których musiałem ponownie przypisać (ani ja, ani mój bezpośredni przełożony nie mogliśmy wypowiedzieć umowy bez tony czerwonej taśmy i stosu dokumentacji.) Lub nie mieć przedłużenia umowy na koniec obecnego zlecenia. Niektóre z wymienionych typów działały również dla innych liderów zespołów i mieli oni podobne zdanie. Rzeczy, które zabrały ludzi do kategorii „Bad Programmer” w mojej książce:

  1. Nie do wyszkolenia lub skostnienia w przeszłości
    Kiedy „programista” nie wydaje się być w stanie wchłonąć nowego systemu, nowego narzędzia lub czegokolwiek, co jest wdrażane, bez względu na sposób szkolenia / edukacji. Musi często powtarzać wspomniany trening.
    Gdy „programista” zna tylko technologię lub paradygmat kodowania, z którego korzystali 10 lub 15 lat temu. To było wystarczająco dobre, więc dlaczego mieliby się zmieniać?
  2. Kowbojski programista
    Osoba, która jako pierwsza koduje, bez planu. „Programista”, który dokonuje nieprzetestowanych zmian w kodzie produkcyjnym i / lub danych „ponieważ musimy go teraz naprawić”, a potem jest zaskoczony, gdy „poprawka” kończy się niepowodzeniem.
    Kowboj też zdecydowanie nie jest graczem zespołowym. Nie potrzebuje śmierdzącego zespołu.
  3. Wiatrowskaz
    Ten „programista” jest zachwycony „technologią du Jour ” i widzi każdą nową strukturę, język, metodologię lub cokolwiek nowego i gorącego jak
  4. „Big Brain”
    Ten „programista” jest tak pewny swojego talentu i możliwości, że robią rzeczy, które nie mają większego sensu w projekcie. np. przepisywanie standardowej biblioteki „ponieważ jest ona nieefektywna dla naszego systemu” lub wprowadzanie narzędzi i technik nieodpowiednich do danego problemu. np. Wprowadzenie Lisp lub Forth w środowisku mainframe.
  5. LOC a. Sandbagger
    Ten „programista” wykorzystuje zaciemnianie i niewłaściwe kierowanie, aby zwiększyć a. LOC: Linie kodu, za które można zapłacić. Widziałem kod w tej sytuacji, który był strona po stronie, ekran po ekranie w zduplikowanej strukturze i logice, ze zmienionymi tylko nazwami akapitów lub zmiennych kontrolnych, aby zwiększyć liczbę wierszy.
  6. Niezbędny ekspert
    „Programista”, który ma wiedzę w dziedzinie rozwiązywania problemów, ale ponieważ „wie” o tym wszystko. W rzeczywistości, gdyby mieli zostać potrąceni przez autobus, cała organizacja upadłaby. { Obserwacja: zwykle ci, którzy uważają się za nieodzownych. (Czy ktoś ma źródło tego aforyzmu?)}
  7. Pasta Chef
    Ten „programista” specjalizuje się w kodzie spaghetti, doprawionym identyfikatorami, które są zbyt trudne do naśladowania bez składniowo zaimplementowanego IDE. np. IndexI1O0, Index1I0O itp.
  8. Letni stażysta - konkretnie podtyp Walking Disaster
    Mój stary sklep zatrudniał wielu stażystów z późnego liceum lub college'u. Pewnego razu dział potrzebował małej bazy danych, aby śledzić zużycie sprzętu (teraz było to opóźnienie i używano dBase III). Facet kodował przez całe lato, ale nie zostało to zrobione, gdy college zaczął się jesienią. Dostał przedłużenie o jeden tydzień, a potem o drugi tydzień. Pod koniec drugiego tygodnia zostałem wysłany, aby przejąć jego projekt i oddać go z powrotem do System Development, aby zakończyć. Pokazał mi rzeczy, które zrobił, a następnie niedokończoną część. To, co zadziałało, było miłe dla oka, ale aplikacja byłaniekompletny. Kiedy otworzyłem nowe pudełko sformatowanych dyskietek, aby uzyskać kopie, powiedział: „chwileczkę, pozwól mi usunąć moje pliki testowe ...” i zanim zdążyłem cokolwiek powiedzieć, usunął kilka plików.
    Będąc podejrzanym typem i odkrywając, że jego aplikacja była niczym innym, jak słodyczami, kiedy wróciłem do mojego sklepu, wróciłem do działu i wyciągnąłem Nortona i usunąłem pliki, które usunął, próbując znaleźć jakąś dodatkową logikę, nawet jeśli niekompletne.
    Znalazłem nie złą logikę, ale złe zachowanie. Drukarka podłączona do komputera, którego używał, była drukarką typu daisy wheel. Zestaw znaków normalnie montowany był wariantem szwajcarskim. Wyjście usuniętych programów podaje nazwę, adres, DOB, niektóre kody literowe i pewien rodzaj numeru identyfikacyjnego. Niepokoiło mnie format i układ. Wszystkie daty urodzenia dla wielu osób były zaledwie legalnym wiekiem alkoholowym. Większość adresów nie było tam, kiedy sprawdziłem je w naszym krzyżowym katalogu. Kiedy pokazałem wydruki swojemu przełożonemu, spojrzał na mnie i powiedział: „Prawa jazdy, nie sądzisz?” Powiedziałem, że to zrobiłem. Powiedział, że właśnie dlatego znalazł zapas przezroczystości wycięty w koszu obok Xeroxa. Nasz zły chłopiec wykonał nakładki, aby dostosować wiek jego i jego przyjaciół do prawa jazdy. Zgłosiliśmy to do władz.nie zapłacił za jego ostatnich dwóch tygodni.

To tylko niektóre ze złych postaci, z którymi musiałem pracować ...

/ s / BezantSoft


RE „Ci, którzy myślą, że są zwykle niezbędni” przypominają mi en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
DaveDev


10

Prócz oczywistego braku wiedzy / umiejętności, programista jest zły, jeśli jego kod jest trudniejszy do odczytania i / lub utrzymania niż powinien.


1
A programista jest naprawdę zły, kiedy nie potrafi dobrze odczytać dobrze napisanego kodu :-)
Maniero

4
Czy to nie byłby prawie każdy? To znaczy, czy kod nie zawsze jest trudniejszy do odczytania i / lub utrzymania niż powinien?
SamB

Nie. Kod zawsze łatwiej jest pisać niż czytać. Ale musiałem zachować bardzo dobrze napisany kod, który maksymalnie zmniejszył ten ból.
Chinmay Kanchi,

10

Gdy nikt inny nie może odczytać jego kodu. Nie ma znaczenia, jak jasny jesteś; żaden programista nie jest wyspą.


Cóż, jeśli pisze w Unlambda, nikt nie powinien być w stanie tego przeczytać.
SamB

Ponadto, gdy programista zajmuje bardzo mało czasu, aby zrobić coś na początku, a następnie dużo czasu, aby dokonać pewnych dostosowań w tym zakresie. Często widziałem, że tak się dzieje, ponieważ programista głównie kopiuje kod wklejania (dlatego szybko na początku), ale potem zajmuje dużo czasu, ponieważ trudno (nawet dla dobrych programistów) zmienić go stamtąd z powodu braku zamiaru napisać dostosowywalny kod na początku.
Sandeepan Nath

7

Ktoś, kto nie zwraca uwagi na szczegóły i zawsze jest w trybie „działa, więc zostawiam go w spokoju. Wszystkie te wyjątki w dziennikach nie mają znaczenia”.


7

Dla mnie są dwie kategorie programistów - solo i zespół.

Źli programiści solo są

  • Ci, którzy wykonali proste zadanie zbyt długo.
  • Ci, którzy nie mogą samodzielnie badać tego, co robią.
  • Ci, którzy zapomną to, co zostało zakodowane dzisiaj, w ciągu kilku dni i nie będą w stanie dobrze utrzymać własnej bazy kodu.
  • Ci, którzy nie mogą dostosować się do zmian wymagań.

Źli programiści zespołu to ci, którzy należą do kategorii złych programistów solo, w tym

  • Ci, którzy nie mogą koordynować z innymi członkami zespołu.
  • Ci, którzy nie przyjmują krytyki.
  • Ci, którzy nie wiedzą, jak być przydatnym dla innych i jak korzystać z innych członków zespołu.
  • Ci, którzy nie potrafią napisać czytelnego kodu.
  • Ci, którzy nie komentują ze względu na czytelność dla innych.

8
Nie pamiętam dokładnie, jak zaimplementowałem rzeczy, które zaprogramowałem w zeszłym tygodniu. Czy to rzadkie? Miałem wrażenie, że praca ze skończoną ludzką pamięcią była tylko jednym z wyzwań programistycznych. Stąd znaczenie strukturyzacji i kodu dokumentującej tak, że nie trzeba pamiętać szczegóły.
James

@James Proszę wybaczyć mój angielski;). Chodzi mi o to, że jeśli programista wróci do swojego kodu kilka dni później i nie będzie miał żadnych wskazówek, to zły znak. Nie pamiętam też, jak i co dokładnie zrobiłem kilka dni temu, ale jestem pewien, że nie muszę drapać się w głowę, patrząc na własny kod i mówić „o czym myślałem?”.
tia

@James: Dokładnie, powinien udokumentować swój kod, aby nie miało znaczenia, że ​​zapomniał, jak działa jego połowa
SamB

4

Nie chcą przyznać, że nie znają odpowiedzi i / lub nie chcą szukać.

Jeśli nie wiesz, nie poddawaj się - wymyśl to i załatw sprawę.


4

Wielkim znakiem ostrzegawczym z mojego doświadczenia jest to, że nie komentują swoich hacków ...

Wiesz, co mam na myśli: kiedy jesteś zmuszony zrobić coś bardzo zuchwałego, ponieważ po prostu nie ma lepszego sposobu na zrobienie tego.

Dobrzy programiści nie znoszą tego robić i umieszczają w komentarzach, jak bardzo nienawidzą tego rodzaju włamań, ale nie ma wyboru. Źli programiści po prostu włożą się do hacka i nie skomentują tego.


3

Cicho, oczywiście, gdy programista pisze DUŻO kodu. Bardzo duże funkcje, może kopiuj / wklej wiersze lub bloki kodu, używając o wiele więcej, jeśli jest to konieczne itp. Może to być spowodowane tym, że programista nie zna standardowej funkcji do robienia tego, co chce, ale przez większość czasu tak nie jest.


3

Będąc repreategly pokazano właściwą drogę, aby to zrobić, i wielokrotnie po prostu robi to w prosty sposób.


3

Przenoszę tutaj swoją odpowiedź z zamkniętego, zduplikowanego tematu, który brzmiał: czy potrafisz rozpoznać, czy jesteś złym programistą? Drugi temat był zamykany, gdy tworzyłem odpowiedź. Moja odpowiedź bardziej bezpośrednio odnosi się do pytania, które zostało sformułowane przez drugiego pytającego i lepiej je zrozumiesz, jeśli to zrozumiesz.

Westchnienie! Część mnie nie chciała dodawać do tego już zajętego tematu, ale inna część mnie wygrała! Dlaczego wygrał; dlaczego zawracam sobie głowę dodawaniem kolejnych słów do tego konkretnego multilogu? Cóż, ponieważ do pewnego stopnia mogę mieć nieco inne podejście do tego niż wielu poprzednich komentatorów.

Binarnie działa świetnie na komputerach: „1” lub „0”, „on” lub „off”. Możemy wyodrębnić i zakodować wiele informacji za pomocą tych dwóch słynnych stanów. Ale nie działa tak dobrze w przypadku spraw ludzkich: „dobry” lub „zły”, „rozsądny” lub „szalony”, „dobry” lub „zły”, „mądry” lub „głupi”, „gruby” lub „cienki”, „żywy” lub „martwy?” Tego rodzaju spolaryzowane oceny zawsze sprawiały, że troskliwy człowiek był częścią mnie strasznie niezadowolony. Niezależnie od schematów pomiarowych, które wybiorę, zwykle stwierdzam, że odpowiedzi na tak ostre kontrasty faktycznie leżą gdzieś wzdłuż kontinuum między jednym takim biegunem a drugim, a nie na żadnym końcu.

Z tą tendencją do polaryzacji walczyłem już od dłuższego czasu, a moim osobistym rozwiązaniem jest, że o wiele bardziej przydatne jest zastosowanie trzech słów do każdej takiej oceny: „ w jakim stopniu!”

Tak więc, moja odpowiedź na twoje pytanie brzmi: zasugeruj je ponownie i zadaj sobie następujące pytanie: „W jakim stopniu jestem złym programistą?”. Lub jeszcze lepiej zapytać w drugą stronę: „W jakim stopniu jestem dobrym programistą?” Jeśli będziecie dążyć do prawdy, prawdopodobnie zlokalizujecie się gdzieś wzdłuż kontinuum między byciem „złym” programistą a „dobrym”. Następnie, gdy uda ci się zlokalizować w przybliżeniu to, gdzie jesteś na tej ścieżce, prawdopodobnie możesz zidentyfikować punkt nieco bliższy „dobrego” końca - punkt, w którym chciałbyś znaleźć się w najbliższej przyszłości.

Jeśli nie ustawisz tego punktu zbyt daleko, prawdopodobnie dostaniesz tylny koniec biegu i zaczniesz go przesuwać w tym kierunku. Jeśli uda ci się kilka razy powtórzyć ten dość prosty algorytm heurystyczny, może się okazać, że jesteś zbyt zajęty programowaniem, aby ponownie zadać to pytanie! Och, i prawdopodobnie zrobisz szybsze postępy, jeśli zaczniesz walić w klawisze tak szybko i często, jak to możliwe; a jeśli robisz sobie przerwę, przeczytaj jakiś kod wysokiej jakości napisany przez twoich rówieśników! W dzisiejszych czasach dynamicznego rozwoju Open Source nie brakuje wolnego i wykwintnego kodu do nauki!

Tak więc gorąco polecam wam, abyście wypróbowali moje trzy małe słowa „w jakim stopniu” i przekonali się, jak daleko mogą was poprowadzić!


2

Ktoś, kto mówi „Nie da się tego zrobić”.

Moim zdaniem chodzi o rozwiązywanie problemów, narzędzie powinno być znacznie mniej przydatne niż faktyczne wykonanie pracy. Jeśli muszę to rozwiązać za pomocą MS-Access lub asemblera, to kwestia czasu i pieniędzy, a nie „Nie da się tego zrobić”

Znak ostrzegawczy to zbyt duży nacisk na akademicki i „właściwy” sposób robienia rzeczy, a niewystarczający nacisk na wykonanie pracy.


2
A kiedy mówi, dlaczego można to zrobić?
Maniero,

1
A co powiesz na rozwiązanie problemu zatrzymania? Czy da się to zrobić?
P Shved

2
Źle jest odrzucać coś jako niemożliwego, jeśli tak nie jest i odwrotnie.
Randall Schulz,

2
@Randall Schulz: O ile mogę stwierdzić z craigslist, programista gwiazd rocka to ktoś, kto zajmuje się wszystkimi poziomami rozwoju (baza danych, doświadczenie użytkownika, wdrożenie, sysadmin i obsługa użytkowników) w agencji reklamowej za znacznie mniej niż normalna płaca za jedna z tych rzeczy. Nazywają je gwiazdami rocka, ponieważ po 60 godzinach tygodniowo ich dieta jest podobna do osoby, która jeździ w ekonolicznej furgonetce i musi zastawiać gitary na jedzenie.
Dan Monego,

1
Tak, dokonałem szerokiego uogólnienia :), ale .. chodziło o to, żeby coś powiedzieć. „Moja profesjonalna opinia mówi, że nie należy tego robić” jest lepsza. Jeszcze lepiej „Co powiesz na rozwiązanie tego samego problemu w inny sposób”. Chodzi mi o to, że dobry programista powinien koncentrować się na rozwiązaniach. „Nie da się tego zrobić” bez oferowania opcji jest bardzo frustrujące dla klienta.
Dan Williams




2

Ci, którzy nie znają zasad takich jak SOLID, DRY, OOP i tak dalej. Ważne jest, aby dobrze rozumieć zasady programowania i podstawy, a nie znać konkretne technologie. Osoby o solidnych podstawach będą mogły łatwo uczyć się nowych tematów i tworzyć lepszy kod.


2

Wbudowany programator, który nie rozumie, bardzo dobrze przerywa lub wielozadaniowość. Również programiści, którzy muszą pracować z polami bitowymi, ale nie rozumieją na nich operacji logicznych i przełączania.


2

Bezpośrednim sygnałem rozpoznawczym jest ktoś, kto mówi: „Nie rozumiem, dlaczego to nie działa. Zrobiłem wszystko dobrze”.


Po nim następuje „Nie rozumiem, dlaczego to działa, to nie w porządku”.
Randall Schulz

Tak, to głupi komputer :)
Dan Williams

2

Jedną z rzeczy, która odróżnia złego programistę od początkujących, jest upór przy wdrażaniu swojego ulubionego systemu w jakimkolwiek języku i interfejsie API, w którym pracują.

Kiedyś odziedziczyłem system, w którym poprzedni programista ponownie wdrożył (w Javie) duży zestaw interfejsu Ashton Tate DBase III + nałożonego na niestandardową bibliotekę dostępu dbf. Żadna z ram kolekcji Java nie została użyta.

Dzięki temu mógł napisać aplikację Java / swing, która wyglądała i działała jak aplikacja DBase III + (lub ewentualnie clipper).

Aplikacje, które napisał w tym systemie, miały menu paska lite i otwierały pełne okno z rzędem przycisków na dole, gdy nawigowałeś pasek lite do opcji. To było jak mała wehikuł czasu z lat 80.

Ten człowiek był wyraźnie wykwalifikowanym programistą. Wiedział wystarczająco, że był w stanie sam napisać cały system w ramach czasowych tego projektu. Był również w stanie ponownie go użyć w kilku innych systemach wewnętrznych.

Ale był okropnym programistą, ponieważ jego kod niewłaściwie wykorzystywał funkcje systemów, nad którymi pracował. Był bardziej skłonny spędzić 3 miesiące na niestandardowej bibliotece wątpliwych korzyści, niż uczyć się Java / Swing / SQL.

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.