"Dobry programista to sprytny programista, a nie pracujący w pocie czoła" - A co Wy myślicie na ten temat?

0

Właśnie wpadłem na taki cytat w internecie i zastanawiam się ile w tym prawdy. Jedni mówią, że naprawdę trzeba się wysilić, żeby być dobrym programistą, a przytoczony cytat jest całkowicie temu przeciwny. Postępując zgodnie z cytatem - dobry programista jest.. leniwy? Zapraszam do dyskusji.

0

najnizszy naklad pracy + wysoki zysk = wysoka wydajnosc

Ogolnie sie z tym zgadzam. Tylko imo zawsze trzeba patrzec na szerszy kontekst + trzeba pamietac, ze kazda decyzja to zaciąganie dlugu technicznego lub nie. A dlug techniczny = koszt.

1

Automatyzacja przynosi realne korzyści, pozwala zaoszczędzić czas i pieniądze. Firmy chętnie zapłacą za algorytm, który pozwoli im zredukować koszty swojej działalności.

Z kolei leniwy programista ma na koncie niejedną aplikację, która zautomatyzowała jakąś czynność, której ten programista nie chciał wykonywać. Zatem taki programista ma większe doświadczenie w rozwiązywaniu tego typu problemów i w takim sensie lenistwo może mu pomóc lepiej wykonywać swoją pracę.

Uważam jednak, że to anegdotyczne ujęcie tematu. W rzeczywistości programista musi włożyć sporo pracy aby zdobyć kompetencje, a później nie raz crunchuje nad swoim kodem.

1

Zawsze myślałem, że to jest anegdotycznie i zabawne. Ale potem spotkałem kilka razy na swej drodze pracowitych programistów i jestem uczulony. Taki pracuś potrafi w jeden tydzień wycopy pastować tyle kodu, że już się tego potem nie odkręci. Przykład dość świeży pracowitości z tego forum: http://wklej.org/id/3345813/. Tylko to zrobił człowiek, który się dopiero uczy i pewnie za 2 miesiące będzie pisał ode mnie lepiej. W branży trafiają się pracowici mający po 5-10 lat doświadczenia, którzy taki kod mają za dobry (czytelny, każda linijka widać co robi...) - i dokładają codzienine cegiełki. A potem wiadomo: ośmiotysięczniki.

Z drugiej strony:
Z pewnością straciłem wiele miesięcy życia (sumarycznie) próbując upchnąć w 3 nieczytelnych linijkach coś co mozna załatwić było jednym zamaszystym copy - paste. No ale do diaska : "jeste programisto".

1
Sunnydev napisał(a):

Jedni mówią, że naprawdę trzeba się wysilić, żeby być dobrym programistą, a przytoczony cytat jest całkowicie temu przeciwny.

Nie jest temu przeciwny – trzeba się wysilić, aby być dobrym programistą i trzeba się również wysilić, aby nauczyć się być sprytnym programistą. Ten spryt później pozwoli zaoszczędzić czasu i pieniędzy, więc jest to cenna umiejętność, zarówno dla pracownika, jak i dla pracodawcy.

1

Wszystko zależy od tego jak rozumieć wspomiany cytat. Ja rozumie, że chodzi tu o taką sytuacje, kiedy ktoś pracowicie w pocie czoła klepie wielkie ilości, nikomu niepotrzebnego kodu :)
Miernikiem wydajności developera nigdy nie powinna być liczba wyprodukowanych linii kodu, ani "rozmiar" projektu który napisał. Ba, niejednokrotnie dobry developer ma właśnie ujemny licznik linii kodu, bo zamiast żmudnie produkować kolejny 8-tysięcznik, to przemyśli całą sprawę i zrobi jakiś refaktor który spakuje kilka takich molochód w jedną prostą klasę. Albo zamiast pisać kolejną bibliotekę do czytania csv, po prostu doda zależność od jakiejś istniejącej.
Więc w tym powiedzeniu, przynajmniej dla mnie, nie chodzi o to że sprytny programista "nie pracuje", tylko że wykorzystuje swój czas efektywnie.

0

Takie typowe pytanie. Lepiej w 3 dni napisać 3k linii kodu, czy 5 dni poświecić na wymyślenie jak problem rozwiązać 3 linijkami kodu.

1
hyde napisał(a):

Takie typowe pytanie. Lepiej w 3 dni napisać 3k linii kodu, czy 5 dni poświecić na wymyślenie jak problem rozwiązać 3 linijkami kodu.

Trzy linijki kodu w takiej sytuacji sugerują wciągnięcie jakiejś dużej zależności, co wcale nie musi być takim dobrym rozwiązaniem…

1
jarekr000000 napisał(a):

Przykład dość świeży pracowitości z tego forum: http://wklej.org/id/3345813/.

Sorry, ale to nie jest przykład pracowitości, ponieważ autor tego dzieła nie poświęcił zbyt wiele czasu i pracy na naukę. Widać ewidentnie, że utknął gdzieś na rozdziale o instrukcjach warunkowych, jeszcze przed pętlami, a następnie przeskoczył do rozdziału o Swing.

0

@Haskell: skąd wiesz, może napisał sobie generator, który wypluł ten kod – sprytnie. ;)

0

Kolega kiedys debugowal przez tydzien jakiegos paskudnego buga z produkcji. Fix to byla zmian aw jednej linijce. Komentarz klienta: najdrozsza linijka jaka w zyciu widzialem :)

Spryt jest potrzebny. Ja np. bardzo mocno zautomatyzowalem swoja prace. Teoretycznie w niektore dni moglbym tylko odpalac rozne joby i potem przesylac co wyszlo. Ale dzieki temu mam sporo czasu na robienie ulepszen. Szukanie bottleneckow w kodzie itp. Wiec tak naprawde z czasem jestem w stanie zrobic coraz wiecej w coraz mniejszym czasie.

No i mam czas na 4programmers i douczanie sie.

0
hyde napisał(a):

Takie typowe pytanie. Lepiej w 3 dni napisać 3k linii kodu, czy 5 dni poświecić na wymyślenie jak problem rozwiązać 3 linijkami kodu.

Jeśli te 3 linijki będą czytelne to zdecydowanie będą bardziej opłacalnym rozwiązaniem. Kod źródłowy nie jest write-only. Kod jest przede wszystkim czytany, sprawdzany/ testowany, poprawiany, etc a to kosztuje. No chyba, że robicie krótkie zlecenia i po takim copy-paste oddajecie kod i o nim zapominacie. Wtedy bardziej opłacalnym rozwiązaniem jest owo copy-paste.

2

Tu nie chodzi o programowanie tylko o percepcję czasu, która jest w osobach pracujących w IT mocno zaburzona (wiadomo, że programiści nie umieją estymować, ale problem dotyczy również wszelkiego rodzaju menedżerstwa, którzy wierzą, że 9 kobiet urodzi dziecko w miesiąc).

Chodzi o to, że ładny kod, automatyzacja, testy to pewnego rodzaju inwestycja. Coś co kosztuje na początku, ale po jakimś czasie zaczyna się zwracać.

Nawet napisanie skryptu automatyzującego pracę się czasami nie opłaca, bo na napisanie takiego skryptu można poświęcić więcej niż faktyczna robota.

Jednak na dłuższą metę (jeśli będziemy potrzebować tego skryptu ciągle) to może się okazać, że napisanie skryptu się zwróciło i że dzięki niemu poruszamy się szybciej.

Tak samo testy jednostkowe czy dobra architektura - na krótką metę to pewien koszt czasowy, na dłuższą metę to coś, co pozwala robić coś szybciej w przyszłości.

I teraz mam wrażenie, że bardzo wiele osób w IT ma myślenie bardzo krótkowzroczne i nawet robiąc projekty, które ciągną się miesiącami czy latami podchodzą dokładnie tak samo, jak do krótkich projektów. Myślą od sprintu do sprintu. I potem okazuje się, że "nie ma czasu na testy" (mimo, że napisanie testów do czegoś by zajęło może z 2 godziny z 40 w których ktoś siedzi w robocie), albo "nie ma czasu pisać ładnie kodu, bo trzeba dowieźć taska na kolejnego sprinta" i w rezultacie mamy potem spaghetti kod w projektach projekt bardzo wolno się posuwa i coraz więcej traci się czasu, właśnie dlatego, że ludzie robią długotrwałe projekty tak, jakby robili projekt tygodniowy.

0

mozna to zastosowac do wszystkich zawodow. hard thinking, smart working

1 użytkowników online, w tym zalogowanych: 0, gości: 1