Jaki jest najbardziej absurdalny mit o problemach programistycznych?

101

Innymi słowy ... Jakie jest najczęściej utrzymywane i frustrujące nieporozumienie na temat programowania?

Które rozpowszechnione i długotrwałe mity / nieporozumienia są dla programistów trudne do usunięcia / poprawienia .

Proszę wyjaśnić, dlaczego to mit.

experience  self-improvement  code-quality  mistakes 
— bigown
źródło
24
Chciałbym zobaczyć, jak Pogromcy mitów przyjmują niektóre z nich.
— gąbka
8
Czy ktoś ma ochotę na kanał YouTube Mythbuggers? :-)
— Tamara Wijsman,
1
Ooooh, MythBusters i warunki wyścigowe! Meesa jak!
@TomWij, świetnie byłoby mieć stronę internetową o takiej nazwie!
— Junior M

Odpowiedzi:

272

To dlatego, że jesteś programistą, wiesz, jak naprawić maszynę wirusową [osoby].

— Neth
źródło
34
Analogia samochodu / klauzula wyjścia: „Jestem kierowcą wyścigowym, a nie mechanikiem”.
— Peter Boughton,
15
Ten komiks jest istotny: theoatmeal.com/comics/computers
— lunixbochs
16
— back2dos
21
@ Czas, jeśli potrafi gotować, zacznij ją zgłaszać na imprezy znajomych
— Steven A. Lowe
19
To nie tak, że nie wiem jak to zrobić ... Nie chcę marnować godzin na naprawę maszyny, którą i tak zepsujesz za 2 tygodnie.
— ChaosPandion,
267

Powszechna rzecz HR, która doprowadza mnie do szału, gdy szukam pracy: domniemane założenie, że wszystkie umiejętności kodowania są specyficzne dla języka i że nie ma specjalistycznej wiedzy inżynierskiej, która wykraczałaby poza zestawy poleceń. Dziesięć lat doświadczenia w Javie i kolejne pięć w Perlu oznacza, że ​​byłbyś całkowicie bezużyteczny w projekcie, który używa, powiedzmy, C #.

„Tak, jest krzywa uczenia się. Ale zrobiłem trudniejsze przejścia niż to. Zrobię ci umowę, zapłać mi 80% za pierwszy miesiąc, a pod koniec tego czasu, jeśli nie jestem ... och , czekaj, tak naprawdę nie prowadzimy tej rozmowy, ponieważ twoja małpa HR po prostu usunęła moją aplikację ”.

— BlairHippo
źródło
91
+ INF dla małpy HR.
— Rusty
67
Miałem faceta z działu HR, który odrzucił mnie do roli, ponieważ wiedziałem, jak C #, ale szukał kogoś, kto mógłby kodować w dotNet.
— burnt_hand
11
@burnt_hand: Tak, wiem dotNet. Znam również Excela i Internet Explorera. Mogę teraz zlecić Haz?
— Alan Plum,
Chociaż zgadzam się, że między Javą a C # istnieją ogromne nakładki na składnię, strukturę, SDLC itp., Jeśli dadzą ci dość trudny test C # w twoim wywiadzie, jak sobie poradzisz?
— JBRWilkinson
2
@ Kyralessa - Myślę, że teraz wiem wystarczająco dużo o podstawowej teorii obliczeń i funkcjach komputerów, aby nie popełniać podstawowych błędów w żadnym języku programowania. Potrafię czytać dokumentację. Jednak coś, co wynajmuje konkretny język z ograniczonymi umiejętnościami / wolą / czynnością inżynierską, popełnia podstawowe błędy w strukturze, projekcie, poprawności, skalowalności, niezawodności i łatwości konserwacji programu, które potencjalnie będą kosztować duże kwoty do naprawy. Jeśli w międzyczasie nie stracisz wszystkich klientów z powodu niskiej jakości oprogramowania (zakładając, że Twój projekt dotrze gdziekolwiek).
— flamingpenguin
261

Jeśli nie piszesz, nie pracujesz.

Uważam, że puste spojrzenia zombie i spacery po kawie są niezbędne dla programistów organizujących rzeczy w swoich głowach.

— ręka spalona
źródło
9
Strona w górę, strona w dół ... strona w górę, strona w dół ...
— czosnek Adolf
139
Nie dostaję pisma, piszę, myślę. Zapewniam pisanie jako bonus.
— Kevin Laity,
11
— Tobias Kienzler,
11
Dlatego nie bardzo cenię rynki freelancerów online, które oferują nagrywanie „czasu pracy” za pomocą wygaszacza ekranu i kamery internetowej. WTF? Jeśli uważasz, że mój cytat jest dobry, dlaczego obchodzi Cię, co dokładnie robię w czasie, gdy naliczam opłatę?
— Alan Plum,
10
„Gdybym miał więcej czasu na kodowanie, napisałbym mniej wierszy”. - zdejmij cytat Abe Lincolna.
— JeffO
158

że możesz przyspieszyć późny projekt, po prostu rzucając na niego więcej ludzi.

— chrmue
źródło
28
Ach, z The Mythical Man Month. pl.wikipedia.org/wiki/The_Mythical_Man-Month
— gąbka
2
Właściwie możesz. -1 (tak, oto nosiciel mitów!)
— P Shved
63
Używamy kolorowego powiedzenia: „Nie możesz umieścić 9 kobiet w pokoju i zrobić dziecka w ciągu miesiąca”.
— Walter,
10
W ubiegłym tygodniu dodaliśmy 4 osoby bez doświadczenia w projektach, aby „pomóc” w realizacji nierealistycznego harmonogramu. W tym tygodniu raport z projektu doprowadził do list wyższej kadry zarządzającej: „Zaplanuj poślizg Przyczyna: Zmniejszona wydajność z powodu krzywej uczenia się nowych członków zespołu” i „Plan naprawy: Dalsze dodawanie większej liczby osób tam, gdzie jest taka możliwość”. Niewiarygodne.
— AShelly
7
@ Walter, ale możesz mieć 9 dzieci w 9 miesięcy i drużynę baseballową małej ligi w 7 lat.
— Huperniketes,
132

To oprogramowanie do pisania jest łatwe.

Jak inaczej wyjaśnisz wszystkie te projekty, które trwają w czasie i przekraczają budżet, a ludzie (politycy, media itp.) Są nadal zaskoczeni, a klienci narzekają, gdy mówisz im, że ich „mała strona internetowa” (lub cokolwiek innego) faktycznie zajmie 6 miesiące na rozwój i kosztowały kilka tysięcy dolarów (funty, euro, [wstaw wybraną walutę])

Mając niewyraźne i ciągle zmieniające się wymagania, czasami myślę, że to niesamowite, że każde oprogramowanie się kończy!

Wiem, że to trochę bardziej skomplikowane;)

— ChrisF
źródło
11
I wtedy starają się opracować tańsze alternatywne rozwiązania off-shore. Tylko po to, by dowiedzieć się znacznie później, że okazało się to jeszcze droższe. I mniej tego, czego naprawdę potrzebowali, ze względu na fizyczne problemy z separacją i komunikacją między zespołem programistycznym a klientem.
— 7wp
1
To nie tylko problem wśród menedżerów, ale także samych programistów. Prawdziwy problem polega na tym, że często brakuje czasu, który nie spędza się aktywnie na pisaniu kodu (być może z powodu rozpowszechnionego LOC = mit kwantyfikacji wydajności).
— Alan Plum,
3
Nie chodzi o to, że wymagania się zmieniły, po prostu nie o to im chodziło.
— JeffO
1
Miałem kogoś, kto odrzucił programowanie jako „po prostu zbiór„ jeśli ”oświadczeń. OK, może tak jest ... w takim przypadku poezja to „tylko garść słów”… produkcja filmu to „tylko garść scen” itp.
— JoelFan
2
Pracowałem dla menedżera, który uważał, że programowanie jest łatwą częścią pracy. I nie, sam nie miał żadnego doświadczenia w programowaniu.
— Captain Sensible
114

Złożoność aplikacji jest wprost proporcjonalna do złożoności interfejsu użytkownika. Zgodnie z tym rozumowaniem powinieneś być w stanie zbudować Google lub Twitter przez weekend.

— JohnFx
źródło
2
to prawda, mogę zbudować Twittera i Google'a w ciągu jednego weekendu. To nie ich oprogramowanie jest złożone; w przypadku Google jest to ich algorytm wyszukiwania (który jest bardziej porównywalny z biblioteką kodów lub sterownikiem bazy danych), a Twitter (aż do ostatnich 1,5 roku) był niezwykle prosty, a jedynie problemy ze skalowalnością i bazą danych były skomplikowane. Teraz, gdy jest bardziej złożony (wymaga większej liczby pracowników), ma również znacznie bardziej złożony interfejs użytkownika i wiele innych interfejsów użytkownika.
— orokusaki,
3
Myślę, że przeczytałem go na blogu Joela Spolsky'ego, ale wspomniany artykuł pokazał jedynie postęp GUI w stosunku do postępu zaplecza. W ten sposób możesz realistycznie oszacować postępy spiczastych facetów, którzy są zbyt głupi, aby zrozumieć, że większość programów składa się z czegoś więcej niż słodyczy.
— Evan Plaice,
3
1+ Był czas, kiedy demonstrowałem projekt związany z SharePoint (wielojęzyczny dodatek) mojemu byłemu szefowi, spędzając godziny pracując nad złożonym kodem zaplecza. Końcowego rezultatu niewiele zrobiono w interfejsie użytkownika, co doprowadziło mojego szefa do przekonania, że ​​niewiele zrobiono w projekcie. To mnie wkurzyło. Nie był tym, który godzinami siedział przy klawiaturze, próbując obejść dziwactwa SharePoint, a także logikę zastępowania tekstu.
— Jason Evans,
1
Czy nie nienawidzisz, gdy jakaś ogromna, prawie niemożliwa prośba jest sformułowana jako „czy możesz dodać przycisk do zrobienia ...”
— JoelFan,
Zastanawiam się, co robiłem przez ostatnie kilka lat. Wszystkie te projekty, nad którymi pracowałem na pełnym etacie, powinny były zostać ukończone w krótkim czasie, ponieważ nie miały żadnego interfejsu użytkownika. :-)
— Bart van Ingen Schenau
95

Wszyscy programiści są dobrzy w matematyce. :-)

— David Cary
źródło
Komentatorzy: komentarze mają na celu poszukiwanie wyjaśnień, a nie dłuższą dyskusję. Jeśli masz rozwiązanie, zostaw odpowiedź. Jeśli Twoje rozwiązanie jest już opublikowane, głosuj za nim. Jeśli chcesz omówić to pytanie z innymi, skorzystaj z czatu . Aby uzyskać więcej informacji, zobacz często zadawane pytania .
Myślę, że zdolności matematyczne są w jakiś sposób powiązane ze umiejętnościami programowania.
— Diego,
@Diego: Chociaż nie musi to oznaczać, że wszyscy programiści są dobrzy w matematyce.
— Omega
95

Każdy nastoletni dzieciak, który hakuje za pomocą komputera, ma umiejętności (lub lepszy) od weterana pracującego programisty.

Mój 14-letni siostrzeniec dobrze zna się na komputerach i płacę mu 10 USD za godzinę, aby kosił trawnik. Dlaczego mam zapłacić sześć cyfr za napisanie następnego FaceBooka?

— JohnFx
źródło
5
Prawdopodobnie są we własnym środowisku, tzn. Pracują samodzielnie według własnych standardów. Umieść ich w zespole, w którym będą się komunikować i tam cierpią.
— czosnek Adolf
36
Przeciwne pytanie mogłoby brzmieć: „Co zapłaciłbyś mu za budowę domu?”
7
Dzieciak bez kwalifikacji, ale piszący porządny kod może pokonać Pana Spaghetti każdego dnia.
— Zaz
13
Winię za to Hollywood
— MAK
6
Kiedy zaczynałem, spodziewałem się, że to, czego sam się uczyłem i które wybrałem na uniwersytecie, będzie dopiero początkiem. Pracowałem z bardziej doświadczonymi ludźmi, którzy byli lepszymi programistami i bardziej kompetentnymi programistami, i uczyłem się wiele od nich. Doświadczenie nauczyło mnie inaczej. To absolutnie ważne, ale bez umiejętności i pasji doświadczenie to tylko zmarnowany czas.
— Peter Boughton,
69

Ten czas rzeczywisty oznacza szybki.

Stwierdzenie „Pakiety muszą być przetwarzane w czasie rzeczywistym”. jest bezwartościowy, a zły bliźniak ... odpowiada: „Jak szybko musi nastąpić X?” z „Real-time” jest prawdopodobnie mniej niż bezwartościowe… graniczące raczej z głupotą niż ignorancją.

W czasie rzeczywistym oznacza, że ​​po prostu ta funkcja Y zawsze zajmuje X czasu, a wszelkie odchylenia wskazują na poważny błąd. Czas trwania X nie definiuje „w czasie rzeczywistym”, może wynosić sześć mikrosekund lub sześć dni. To, że możesz określić, że funkcja Y zajmie czas X, definiuje „w czasie rzeczywistym”. Zgodnie z tą definicją systemy czasu rzeczywistego są deterministyczne.

Więc strąc to ...

— Zardzewiały
źródło
real-time = near-time
— brian chandley,
4
Zawsze myślałem, że czas rzeczywisty oznacza, że ​​wszystko, co się dzieje, dzieje się tak, jak tego potrzebujesz, a nie odniesienie do czasu.
— burnt_hand
14
Jest to prawdopodobnie tylko jeden z tych przypadków, w których źle nazwana koncepcja przyczynia się do zamieszania.
— JohnFx,
2
@JohnFx Dobrze powiedziane. Pojęcia potrzebują kontekstu.
— Rusty
2
@Richard: Rzeczywiście, iTunes zawsze zajmuje kilka minut, zanim cokolwiek odtworzy. Och, nie o to ci chodziło?
— konfigurator
69

Dlaczego po prostu nie napisacie tego poprawnie za pierwszym razem, zamiast spędzać tyle czasu na pisaniu błędnego kodu, a potem na czytaniu kodu, próbując znaleźć błędy?

:-) :-) :-) :-)

— David Cary
źródło
34
Szczerze mówiąc, to dobre pytanie. Najłatwiejszym sposobem na poprawienie kodu jest napisanie go po raz pierwszy.
— DJClayworth,
10
Mamy ustawienie w konfiguracji aplikacji: <add Key = "Bugs" Value = "true" />
— burnt_hand
1
@DJClayworth - to nie zawsze działa. W niektórych przypadkach problem jest tak duży, źle zdefiniowany lub po prostu bardzo trudny, że zbliżenie się do „właściwego” za pierwszym razem jest zbyt duże, aby się spodziewać. W takim przypadku lepiej napisać „pierwsze cięcie”, które nie jest całkowicie błędne, niż spędzanie dni / tygodni / miesięcy bez końca na projektowaniu i przeprojektowywaniu, starając się to zrobić za pierwszym razem.
— Stephen C
Może to być laicka wersja „Dlaczego nie robicie TDD?” Co, szczerze mówiąc, jest cholernie dobrym pytaniem, jeśli jest zbyt proste dla prawdziwego rozwoju świata.
— Dan Ray
1
@Stephen C: tak, ale jest różnica w tym, aby uzyskać poprawność (zamiast idealnie właściwej) w porównaniu z robieniem wszystkiego w lewo i prawo, aby tylko działało. Wiem, że nie to powiedziałeś, ale nadal uważam, że należy to powiedzieć.
— n1ckp
65

Jeśli nie studiowałeś, nie nadajesz się do tej pracy

— użytkownik2528
źródło
27
Ponadto: programista z dyplomem jest lepszy niż programista bez i powinien być odpowiednio opłacany. To samo prawdopodobnie odnosi się do starzenia się i seksizmu. Ten rodzaj bzdur doprowadza mnie do szału - jeśli nie wiesz, jak napisać dobry kod, nie przejmowałbym się tym, gdzie poszedłeś i co zrobiłeś. Może to być kolejny przypadek konfliktu kultury programisty / kujona (umiejętność == autorytet) z kulturą korporacyjną (autorytet == autorytet).
— Alan Plum,
1
A jednak ludzie nauczający na uniwersytecie również wydają się myśleć, że mogą uogólnić zachowanie programistów i projektów, obserwując, jak działają studenci po połączeniu. Komunikacja z ACM jest dobra dla 4-6 takich artykułów rocznie.
— MIA
1
@Billy A może tutaj, gdzie dyplom uczelni oznacza walet, ale dyplom uniwersytetu da ci wszystko? Obie chodzą do szkoły, obie są prawdopodobnie lepsze od drugiej, ale jest różnica socjologiczna
— Tarka
4
@Billy: w Kanadzie uniwersytet przyznaje ci dyplom, a uczelnie dają dyplomy. Uczelnie bardziej przypominają „szkoły, w których uczysz się praktycznych rzeczy”. Pomyśl o college'u wspólnoty w USA a normalnym college'u. Tutaj mają zazwyczaj dwuletnie specjalistyczne programy stosowane. Nie można uzyskać licencjata (magistra itp.) Na studiach. Zasadniczo poszedłbyś na studia, aby studiować pisanie oprogramowania, a na uniwersytet - na informatykę. Stopnie uniwersyteckie mają znacznie silniejszą preferencję przy zatrudnianiu.
— Adam Lear
4
Uniwersytety uczą co najmniej jednej ważnej rzeczy: sposobu myślenia . To bardzo ważne, ale ci, którzy tego nie wiedzą ... no cóż, nie wiedzą o tym.
61

Ta przedwczesna optymalizacja oznacza, że ​​nie powinieneś w ogóle optymalizować. Widziałem więcej strasznie złych baz danych, ponieważ nikt nie chciał brać pod uwagę wydajności (krytycznej dla dowolnego systemu baz danych) w projekcie, ponieważ była to przedwczesna optymalizacja niż jakikolwiek inny problem z projektowaniem bazy danych. Śmieci, są znani zabójcy wydajności, przestań ich używać jako pierwszego wyboru.

Kolejny mit, że zbyt trudno jest refaktoryzować bazę danych. Nie, ale musisz zastanowić się, jak przeprowadzić refaktoryzację na etapie projektowania, aby zrobić to skutecznie. A tak przy okazji, im dłużej będziesz czekać na rozwiązanie tego irytującego problemu związanego z wydajnością, tym trudniej będzie to naprawić.

Kolejny zły mit, projektowanie baz danych powinno odzwierciedlać zasady OOP. Nie, bazy danych są zaprojektowane do pracy z zestawami, a nie zasadami OOP. Niektóre rzeczy związane z OOP powodują okropne problemy z wydajnością, a inne są po prostu niemądre z punktu widzenia bazy danych.

Wreszcie należy wymusić integralność danych w aplikacji. Bazy danych będą trwać dłużej niż aplikacja i utraciłyby reguły, gdy aplikacja zostanie zastąpiona, wiele aplikacji będzie miało do nich dostęp i często będzie konieczne uruchamianie bezpośrednich zapytań w celu naprawy rzeczy, które nie przechodzą przez aplikację. Nigdy nie widziałem bazy danych, która odmawia wymuszania integralności danych w bazie danych, która ma dobre dane.

— HLGEM
źródło
+1 w szczególności za komentarze dotyczące kontroli integralności bazy danych.
— Frank Shearar,
+1 Szczególnie za ostatni akapit. Pokonałem ten bęben więcej niż raz.
— Binary Worrier
5
+1 za pierwszy akapit. Przedwczesna optymalizacja jest źródłem wszelkiego zła; pisanie złego kodu bez żadnego cholernego powodu jest jeszcze gorsze.
— konfigurator
3
„Niektóre rzeczy związane z OOP powodują okropne problemy z wydajnością, a inne są po prostu niemądre z punktu widzenia bazy danych” - czy możesz powiedzieć, które? Wiem o OOP, ale niewiele o bazach danych i jestem zainteresowany tym, jak daleko mogę przenosić pomysły z każdej strony na drugą.
— Tom Anderson
@HLGEM Chciałbym również zainteresować się przykładami @Tom zastanawia się nad ...
— Armand
53

Że istnieje mityczne źródło absolutnych najlepszych praktyk.

Żadne odchylenie nie może być nigdy uzasadnione.

Żaden dokument podający się za definicję najlepszej praktyki nie może być nigdy kwestionowany.

— Rachunek
źródło
1
lepszy członek zespołu niż twoi menedżerowie ...
— Bill
5
Czy możesz mi przekazać ten dokument?
— AShelly,
1
Kompletnie się zgadzam. Kogo to obchodzi, jeśli łączysz tabulatory i spacje w kodzie Python?
— Zaz
4
@Josh - ktoś, kto musi wyświetlić kod źródłowy za pomocą łańcucha narzędzi, który ma inne pojęcie o tym, gdzie znajdują się pozycje tabulatorów.
— Stephen C
1
Interpretuję „to najlepsza praktyka” jako „nie mogę tego uzasadnić”. Z pewnością tak to wykorzystuję.
— Tom Anderson
51

Fakt, że marketing wydaje się uważać, że dodanie wielu drobnych funkcji jest mniej pracochłonne niż dodanie pojedynczej, ale raczej ciężkiej funkcji. Co prawdopodobnie jest bardziej konkretnym przypadkiem błędnego przekonania, że ​​„przełączanie zadań nie ma narzutu”.

— Giel
źródło
12
A jeszcze bardziej zabawne jest to, że marketing nie ma pojęcia, które funkcje są łatwe, a które są cholernie niemożliwe.
— derobert
4
@derobert Dokładnie, często miałem doświadczenie, że niektórzy z bardziej rozważnych ludzi marketingu obawiają się nawet zapytać o jakąś prostą / łatwą funkcję, którą ich zdaniem bardzo trudno było wdrożyć. Chociaż znacznie częściej zdarza mi się coś przeciwnego: oto seria „łatwych” funkcji X, które już sprzedaliśmy klientowi, proszę załatw to wczoraj ....
— Giel
50

Ten kod komentowania jest niepotrzebny lub że „dobry kod nie wymaga komentarzy”. Czasami musisz wyjaśnić, co robi złożony kawałek kodu. Co więcej, komentowanie sekcji kodu pomaga znacznie bardziej efektywnie przeszukiwać.

— DisgruntledGoat
źródło
14
@DisgruntledGoad - To prawda. Nieporozumienie w tym „micie” wynika z faktu, że zbyt wielu programistów uważa swój monolityczny mylący kod za „dobry”. if user.is_logged_in: print('Welcome')nie potrzebuje komentarza.
— orokusaki,
3
@orokusaki Nie każdy algorytm jest taki prosty.
— Jouke van der Maas,
25
@orokusaki mylicie „dobry kod nie wymaga komentarzy” z „prosty kod nie wymaga komentarzy”. Dobry kod nie zawsze jest prosty.
— DisgruntledGoat
3
@Jouke van der Mass: oczywiście. Ale nie ma znaczenia, jak skomplikowany jest algorytm, celem jest jego proste wyrażenie. tzn. dobry kod wyraża złożone algorytmy, reguły, optymalizacje, w prosty i jednoznacznie zrozumiały sposób. Wyrażanie prostych rzeczy po prostu jest stosunkowo łatwe. Wyrażanie złożonych rzeczy jest po prostu tam, gdzie leży umiejętność.
— flamingpenguin
2
@orokuskai: dobry kod jest prosty. To, co robi, może być skomplikowane, ale prostota (elegancja) kodu sprawia, że ​​moim zdaniem jest dobry! Oczywiście kod robi wiele innych rzeczy, a kod śmieci może zarabiać dużo pieniędzy. Ale moim celem jest pisanie prostego kodu nawet w skomplikowanych sytuacjach.
— flamingpenguin
50

Najgorszy mit: jeśli programujesz przez długi czas, możesz łatwo zostać Project Managerem.

I że powinieneś zostać kierownikiem projektu, jeśli programujesz od dłuższego czasu.

— Namwar Rizvi
źródło
3
Albo jeszcze gorzej, jeśli nigdy nie programowałeś ani nie zarządzałeś projektem programistycznym, czytając kilka książek i magicznie sprawi, że oprogramowanie się wydarzy. Byłem na tej drodze z poprzednim PM i nie chcę powtarzać tego tak długo, jak żyję.
— Evan Plaice,
4
Co gorsza: ponieważ wszyscy wspaniali programiści w zespole wolą pisać kod od pisania raportów, powinniśmy promować miernego programistę na Project Managera. Chodzi o to, że będzie „wystarczająco techniczny”. Faktem jest, że ostatecznie staje się filtrem dezinformacyjnym między zespołem a wyższym kierownictwem.
— AShelly,
2
Ponadto: jeśli jesteś najlepszym programistą, powinieneś oczywiście zostać kierownikiem projektu i od tego momentu przestań samodzielnie programować! Nie, dziękuję bardzo, ale nadal przyjmę podwyżkę. Uwaga: nie mówię o zostaniu głównym programistą ani nic takiego, mówię o menedżerach, którzy uważają, że sprytnym pomysłem jest wypromowanie wszystkich do poziomu wystarczającej niekompetencji.
— Alan Plum,
1
Znany również jako Zasada Piotra. en.wikipedia.org/wiki/Peter_Principle
— Spoike
dobrze powiedziane
— Michael Easter
50

Jeśli użyjemy w naszym projekcie czegoś innego niż Java, C # i C ++, nie znajdziemy żadnego programisty, który by to obsługiwał.

— Pavel Shved
źródło
Nigdy o tym nie słyszałem, ale to jest ważne. Oczywiście, jeśli użyjesz niejasnego języka, tak by się stało.
— Maniero,
5
@bigown, „niejasny”? Jak niejasne? Czy TCL jest niejasne? Haskell? Pascal (Delphi)? Pyton? Myślę, że nie są one niejasne. Wiele osób uważa, że ​​są i tylko bardzo wąski zestaw języków (C ++, C # i Java) jest dozwolony w „poważnym” rozwoju.
— P Shved
5
@bigown: och, masz na myśli niejasne jak COBOL? : p
— AnonJr
2
Kiedyś pracowałem dla małej firmy, która tworzy kod Objective-C w systemie Linux. Dyrektor generalny - który nie był inżynierem, ale miał pewną wiedzę techniczną - nie mógł uwierzyć, że w pobliżu byli programiści ObjC lub że ktoś inny z nich korzystał. W rzeczywistości nigdy nie mieli problemów z zatrudnieniem dobrych programistów.
4
Przeczytałem argument, że jest dokładnie odwrotnie: w przypadku języków, które są niejasne (lub przynajmniej nieistotne z handlowego punktu widzenia), ale fajne, zabawne i interesujące (co w tym kontekście oznaczało Python i Ruby), jest więcej programistów niż miejsc pracy. Poza tym wszyscy ludzie znają fajne, zabawne i ciekawe języki, więc muszą być inteligentni. Tak naprawdę praca w Pythonie oznacza łatwiejsze zatrudnienie inteligentnych programistów niż praca w Javie. Nie wiem, czy w to wierzę, ale jest to co najmniej tak prawdopodobne, jak ortodoksyjny pomysł!
— Tom Anderson
42

Java to po prostu C ++ z różnymi klasami.

— Gordon
źródło
57
+1 Kiedyś ankieter zapytał mnie: „Jaka jest różnica między C ++ a Javą?” Wymieniłem więc kilka różnic. Natywny kompilator vs. JVM, standard ANSI vs. zastrzeżony, wyrzucanie elementów bezużytecznych, moduły ładujące klasy itp. Ryknął: „ŹLE! Nie ma różnicy! Są identyczne!” Nie był studentem, był kierownikiem inżynierii.
— Bill Karwin,
11
@Bill, moja odpowiedź brzmiałaby: „to po co odwoływać się do nich z zupełnie innymi nazwami?”
— Jesse C. Slicer,
2
@Bill, więc nie zaliczyłeś testu i zostałeś zatrudniony?
20
Moja odpowiedź brzmiałaby „Do widzenia”.
— Foole
6
@Foole Nie masz na myśli System.exit (1)?
— Barry Brown
33

Prawdopodobnie najbardziej niebezpieczny, jaki widziałem, ponieważ jest tak chętnie akceptowany, ponieważ umiejętność szybkiego pisania kodu jest dobra i dlatego im szybciej możesz napisać [wstawić tutaj funkcję] w danym języku, tym lepszy język jest.

Jest to poważny przykład przedwczesnej optymalizacji, ponieważ o wiele więcej pracy wymaga utrzymanie kodu niż jego tworzenie. Oznacza to, że o wiele ważniejsze jest pisanie kodu, który jest łatwy do odczytania, zrozumienia i debugowania, niż kod, który jest łatwy do szybkiego pisania, a ułatwienie łatwego do odczytania kodu jest znacznie bardziej użytecznym pomiarem jakości języka.

— Mason Wheeler
źródło
14
dokładnie to stało się z jednym z produktów, dla których pracuję; pośpieszny rozwój był postrzegany jako genialny. Produkt WYGLĄDAŁ ok, a programista został bardzo wysoko oceniony przez kierownictwo wyższego szczebla. Kolejny młodszy programista otrzymał wówczas zadanie naprawienia „małego” błędu, a po tygodniu próbowania zrozumienia kodu zrezygnował i szukał wskazówek od seniora… który nie mógł uwierzyć, jak bzdury były kodem. Wyższe kierownictwo odmówiło przyjęcia, jest głównym problemem przez dwa lata, po czym ostatecznie zgodzili się, że to stos śmieci i trzeba go było ponownie
— kodować
4
Istnieje utwierdzony mit wśród menedżerów technicznych, że twoi wykwalifikowani programiści są dziesięć razy wydajniejsi niż niewykwalifikowani programiści. Bezpośrednim rezultatem tego mitu jest to, że każdy programista, który potrafi szybko tworzyć kod - bez względu na to, jak trudny lub trudny w utrzymaniu - otrzymuje pochwały i promocję.
— rtperson
3
Ty POTRZEBUJESZ potężny język. Zobacz dyskusję języków Paula Grahama i możliwości ti: paulgraham.com/power.html
4
@ Thorbjørn: Przeczytałem ten artykuł, a Paul Graham go źle. Jest zwolennikiem Lisp, więc przekręca fakty na bezinteresowne argumenty, aby Lisp wyglądał dobrze. Może nawet nieświadomie, ponieważ tak naprawdę nie wymaga to zbytniego skręcania. Jak wskazuje na koniec artykułu, czytelność i zwięzłość nakładają się na siebie. Ale wnioski, które wyciąga, są całkowicie niezsynchronizowane ze stanem rozwoju oprogramowania w świecie rzeczywistym. Tak, potrzebujesz mocnego języka, ale on mierzy moc według niewłaściwych kryteriów, a wierzenie w to, co mówi, jest szkodliwe.
— Mason Wheeler,
3
@rtperson: Ta produktywność może różnić się dziesięciokrotnie, to nie mit. Ludzie, którzy kończą szybko, są z konieczności bardziej produktywni.
— David Thornley,
31

Lekcje wytwarzania można zastosować do procesu tworzenia oprogramowania.

— Mike King
źródło
6
Zależy od lekcji. Kiedy pracowałem w fabryce materacy, dowiedzieliśmy się, że zmiana zadań była szkodliwa dla naszej produkcji. Trochę to ważne, ponieważ płacono nam za liczbę wykonanych materacy, a nie za godzinę ... i lekcję, która obowiązuje tutaj również z wielu tych samych powodów.
— AnonJr
To taki uporczywy mit, gdy pracujesz w miejscu, które głównie produkuje sprzęt. Obręcze, przez które przeskakujemy, aby dopasować nasze „oprogramowanie” do tego samego modelu co „część” sprzętowa, są niesamowite ...
— AShelly
5
Rzecz w tym, że oprogramowanie do produkcji jest banalne. Tworzenie kopii jest łatwe i nie kosztuje wiele do zrobienia milionów kopii. To powoduje, że ludzie całkowicie ignorują część produkcyjną i starają się zastosować produkcję do procesu projektowania.
— David Thornley,
+100 za to, szczególnie ludzie, którzy studiowali ekonomię, tak myślą
— Kugel
1
Każdy powinien przeczytać Jacka Reevesa: developerdotstar.com/mag/articles/reeves_design_main.html - to jest geneza (lub przynajmniej wczesna i mocna wypowiedź) idei, że kod źródłowy jest projektem, a nie produktem . Programiści są jak projektanci w pokoju kreślarskim, a nie mechanicy w fabryce, a zarządzanie programowaniem musi przypominać zarządzanie innymi projektami inżynieryjnymi, a nie produkcją.
— Tom Anderson
31

że jako programista wiesz wszystko o najnowszych trendach sprzętowych, przetaktowywaniu, modowaniu skrzynek itp. przyjaciele i krewni konsultują się przy zakupie sprzętu.

— setzamora
źródło
5
Kiedyś śledziłem niektóre z tych rzeczy z powrotem w liceum, ale obecnie uważam, że są one generalnie nieistotne dla tego, co robię i chociaż niektóre są schludne, wolałbym zapłacić komuś, kto zna ich rzeczy, i wykorzystać czas, który ja zapisz robienie tego, co lubię (tj. pisanie kodu). Może kolejne nieporozumienie „dobre z komputerami”.
— Alan Plum,
2
+1 lub lekko jednorazowa styczna - Ponieważ jesteś programistą, masz superduper chłodzony wodą wentylator 300 LED obracający się błyskający top z najnowszej serii fabrycznie wysłany z fabryki przed wydaniem skrzynki. Eee nie do końca! To przyzwoicie szybka maszyna, w czarnej, bardzo taniej obudowie. Nie obchodzi mnie to!
— Surgical Coder
Śmiej się, w pracy jest asystent premiera, który ma w domu jakiś wszechmocny sprzęt do gier, zawsze przewraca się do strefy deweloperów i pyta, czy powinien kupić (Produkt A) czy (Produkt B) ... zakłada również, że zespół deweloperów spotykał się na 4Chan, (co faktycznie robi.) - westchnienie
— ocodo
+1 słowo. To jest na miejscu. Jestem programistą i zostałam poproszona o skonfigurowanie czyjegoś Internetu tak wiele razy i zasadniczo wszystko, co robię, to próby i błędy oraz wyszukiwania w Google. Najbardziej podoba mi się, gdy coś całkowicie niezwiązanego zrywa się po tym, jak wyświadczysz komuś przysługę, a potem to twoja wina.
— Anne Schuessler,
30

Gdy programiści twierdzą, że jest to bardzo trudne / po prostu niemożliwe, HR uważa, że ​​jest leniwy i niezmotywowany

— koos303
źródło
2
Uwzględnij także zarządzanie
— Prasham
Kiedy odmawiasz, myślą, że jesteś po prostu trudną osobą do pracy.
— Captain Sensible
+100, a przy wystarczającej „motywacji” mogą zmienić twoją odpowiedź. Możesz też udać się do innego [mniej doświadczonego] programisty i celowo pominąć połowę szczegółów, aby skłonić go do powiedzenia tak, tylko po to, by skończyć w połowie rozwoju i napotkać dokładnie ten problem, o którym ich ostrzegałeś.
— wildpeaks
28

Dla mojej firmy musi istnieć program typu open source. Nie możesz go po prostu pobrać i dostosować do moich wymagań.

— Tim Murphy
źródło
2
+1. Och, tak, wszystko, co musimy zrobić, musi już być typu open source.
— sharptooth
7
dużo czasu jest ... przynajmniej tak jest w przypadku tworzenia stron internetowych.
— WalterJ89,
@ WalterJ89: Być może tam jest, ale to nie znaczy, że warto go używać. Otwarte źródło nie oznacza automatycznie dobrego kodu.
— Alan Plum,
prawda ... ale w przypadku Wordpress, Drupal, jQuery ... mogą istnieć obszary, w których darmowy nie jest świetny, jak handel elektroniczny, ale często sieć jest bardzo otwarta i uważam, że lubię pracować z społeczność open source to coś więcej niż zastrzeżone biuro pomocy.
— WalterJ89,
7
Odwrotny jest także mit. Że nie możesz użyć FOSS do zaspokojenia potrzeb biznesowych.
— zakończenie
27

Kiedyś więcej niż jedna osoba pytała mnie, jak to jest programować, aby w połowie rozmowy uświadomić sobie, że tak naprawdę myślą, że programujemy bezpośrednio w postaci binarnej lub za pomocą symboli matematycznych.

Nie wiem, czy chcę rozwiać ten mit, sprawia, że ​​wyglądam naprawdę elegancko!

— JohnFx
źródło
6
Nie pomaga to, że większość ludzi nawet nie wie, czym tak naprawdę jest programowanie ... mają mgliste pojęcie, że tworzy oprogramowanie ... ale tak naprawdę nie mają jasnego pojęcia, czym jest oprogramowanie ...
— Spudd86
7
„Piszemy przepisy na drutach”. Babcie to rozumieją.
Znam ludzi, którzy napiszą program w C, a następnie przerobią najbardziej krytyczne pod względem wydajności części w asemblerze.
— Zaz
1
@Josh - chyba że występuje problem z wydajnością, wydaje się to stratą czasu.
— JohnFx
1
@ oosterwal - Asembler nie jest binarny, ani nie używa symboli matematycznych.
— JohnFx,
26

Myślę, że największym nieporozumieniem jest to, że ważniejsza jest umiejętność łatwego zapisywania kodu niż umiejętność czytania i rozumienia kodu.

— rev LennyProgrammers
źródło
5
* v (int) (void) ++
— Rusty
1
@Rusty: Mogę wymyślić wiele, wiele gorszych przykładów, jeśli nawet nie musi być poprawny składniowo.
4
Ach, tak, kod „Tylko do zapisu” ...
— Paddyslacker,
24

Programowanie jest jak praca na linii montażowej. Pracujesz nad produktem przez pewien czas (być może ze współpracownikami) i wreszcie go wysyłasz. Podobnie jak budowanie domu z cegieł.

Contra: Programowanie zawiera wiele kreatywności i planowania. To jest sztuka. Podobnie jak mason, także programista zna różnicę między kształtowaniem cegły a planowaniem całej katedry.

— Josua Schmid
źródło
6
Zgadzam się na różnicę w stosunku do pracy na linii montażowej - ale pod wieloma względami nie sądzę, że różni się to od budowy domu.
— Billy ONeal
24

Przeniesienie programu do C ++ automatycznie przyspieszy jego działanie.

— JohnFx
źródło
Chciałbym rozszerzyć na inne języki niskiego poziomu. Możliwe jest odwrotnie, gdy programista nie wie, co robi.
— Maniero,
2
Innym powszechnym wariantem jest przejście na architekturę klient-serwer. „Aktualizacja do SQL znacznie przyspieszy działanie mojej aplikacji!” Niekoniecznie.
— JohnFx,
Tak, wiele razy jest wręcz odwrotnie. Bazy danych w stylu SQL są dobre, aby mieć ACID lub prawie wszystko, co wiąże się z ceną. I może być najgorsze, złe myślenie o technikach SQL może być szkodliwe dla wydajności.
— Maniero,
6
Przenoszenie do C ++ / C dla tych napisanych w Python / Perl / Ruby / etc. Przenoszenie do asm dla tych napisanych w C / C ++: P. Zastanawiam się, do czego byś to przesłał? projektujesz to w sprzęt?
— MAK
1
— flamingpenguin
21

Każde środowisko programistyczne z jakimś projektantem wizualnym sprawi, że użytkownicy biznesowi będą mogli „pisać” program, a faktyczni programiści nie będą potrzebni.

— Jesse C. Slicer
źródło
9
O tak. Zawsze jest fajnie, gdy jakaś firma tworzy nowe narzędzie autorskie, aby zwolnić programistów, a następnie każdy, kto je przyjmuje, zatrudnia wysoko opłacanych specjalistów <narzędzie autorskie>, którzy faktycznie z niego korzystają. Przykład: Joomla! i wszystko to bezsensowne.
— Alan Plum,
HA HA HA HA HA HAAA HA +1 :)
— Billy ONeal
Cobol już tego próbował :)
— Carra
20

Ponowne użycie OOP. To największy błąd wprowadzony na rynek w programowaniu.

— grudka
źródło
1
Dobrze. HP XL WESM jest mniej więcej w 85% taki sam jak Symbol WS5100 (trwa proces OEM). Czy mógłbyś skopiować i wkleić ten procent mojego kodu monitorowania i konfiguracji, aby było dwa razy więcej błędów, czy wolałbym, żeby przepisać go od zera i zajął czterdzieści razy dłużej, a pięć razy więcej? A może po prostu wywiera na ciebie presja głupie zarządzanie, które uważa, że ​​jednym z kilku magicznych panaceum jest przyspieszenie projektu?
1
Ponowne użycie w małym rozwiązano 40 lat temu i więcej. Ponowne użycie w dużej jest trudne i nie zostało jeszcze rozwiązane IMHO. Tak jak Robert Glass mówi w faktach i błędach inżynierii oprogramowania
— MarkJ
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.