Czym się różni Crud-owiec od programisty z prawdziwego zdarzenia

Crudowiec częściej wykonuje powtarzalną pracę na taśmie, szablonowe projekty, odtwarza, nie ma za bardzo pola dla rozwoju/inicjatywy. Wszystko może mu się tak przejeść, że na swoje problemy patrzy głównie odgórnie, a przede wszystkim w znacznie większym stopniu koncentruje się na realizacji biznesowych wymagań, dopięciu projektu na czas niż na jakiś technicznych detalach. Im lepszy spec tym bardziej zadaje sobie sprawę, że klient nic nie wie, a oprogramowanie to najmniej istotna część jego biznesu.

Prawdziwy Programista widzi to wszystko odwrotnie, dokłada więcej abstrakcji, narzędzi o które nikt nie prosił. Patrzy na problemy tak wnikliwie i analitycznie, jakby los całej firmy zależał od jego pracy i zaangażowania. Nim napisze coś na ekranie, jeszcze ręce mu zadrżą, jeszcze 2-3 wróci do swojej koncepcji, jeszcze się zawaha, aż w końcu napisze const, by nie robić zmiennej, a potem idzie do domu.

IMO obie perspektywy są słabe. Lepiej unikać pracy przy taśmie i postawy rozwiązywania nieistotnych problemów w heroiczny sposób. Jeśli już ktoś musi wybierać czy chce być orkiem czy elfem to niezależnie od wyboru niech chociaż raz się zastanowi i ograniczy wpływ wytwarzanej kuli błota.

Na początek samokrytyka. Jestem pewnie zwykłym crudowcem i piszę z tej perspektywy.

Wrzucę link do postu:
Czy naprawdę rośnie liczba ludzi nie rozumiejących techniki?

Jedna osoba napisała tu, że jeśli programista ma napisać program do odtwarzania muzyki to musi mieć PO który mu naklepie taska i opisze wymagania. I to jest dla mnie kwintesencja crudowca. Zero myślenia. Praca odtwórcza według opisanego schematu. Bez wiedzy o dziedzinie dla której tworzy oprogramowanie. Krótko mówiąc człowieka od naciskania kombinacji przycisków na taśmie.
@somekind: poruszył chyba pierwszy ważny temat. Osób które mogą mieć wiedzę, chęć by np. popracować nad wydajnością. Żeby jednak usprawnić wydajność też trzeba mieć ten zarys ogólny gdzie najlepiej to zrobić, czyli wychodzić de facto poza schematy.

I teraz dochodzimy do kolejnej rzeczy czym powinien być Inżynier IT a czym powinien być np. technik programista.
W branżach z jakimi miałem styczność inżynier nie był od pracy powtarzalnej. Problem -> projekt -> prototyp za cały proces odpowiedzialny był inżynier. W IT teraz inżynier programista często ogranicza się do napisania 50 linijek kodu źródłowego na taska z wymogami o kontrakcie dla FE i to wszystko bezrefleksyjnie.
W IT się to mocno miesza i wszyscy górnolotnie starają się mieć tytuł senior programmer

Używam określenia CRUDy - crudowiec, na dwa nieco różne zjawiska:
a) pozornie skomplikowana aplikacja, używająca tony bibliotek, mapperów i warstw, która po krótkiej analizie okazuje się mocno rozdmuchaną przelotką do bazy danych, (> 95% mapperów przepisuje 1-1 rzeczy z bazy danych).
Prawda zwykle wychodzi na jaw, jak dopisuje się kolejne pole do formularza - programista przez dwa dni tylko wrzuca to pole w kolejne DTOsy, CTOsy, ETOsy, DBOsy... + (dawniej) gettery i settery i mocki - praca mechaniczna i totalnie bez sensu.

b) podejście polegające na tym, że klient opisuje swoją domenę, a backendowcy od razu zaczynają się ślinić modelując w pseudo ERD (czyli diagramy klas UML) domenę. Tworzą bezsensowny backend (serwisy) - mający w dupie przypadki użycia. Doprowadza to frontendowców do płaczu (bo żeby wyrenderować pierwszą stronę to muszą walnąć 100 requestów). To oczywiście zakłada "typową" aplikację, gdzie mamy backend(y) i frontend(y) (niekoniecznie web). (Tutaj w sumie zamiast CRUD pasowałoby coś w stylu "bajkowe modelowanie obiektowe")

Gdyby ktoś robił świadomie cruda, przelotkę do bazy danych, w projekcie gdzie ma to uzasadnienie technologiczne i to jeszcze tak, że jedna linijka i kolejna tabelka wystawiona, to problemu nie mam - jestem na tak.

jarekr000000 napisał(a):

Używam określenia CRUDy - crudowiec, na dwa nieco różne zjawiska:
a)
b)

Najgorsze że przychodzą tu ludzie co sami to sobie robią z tutoriali.
Przypadek a) był jakiś czas temu gdy ktoś przedstawił odsyłanie pinga na 4 warstwach i logach na aspectach. Apka wyglądała jak hołd dla architektury Javy EE z czasów EJB2, ale w nowszych technologiach.
Przypadek b) jest jeszcze świeższy tu na forum. Człowkiek chciał pobierać całe listy i robić joiny na frontendzie (jesli go dobrze zrozumiałem). Zadziała mu w projekcie studenckim bo ma po 10 elementów w każdej liście. ale pójdzie do pracy i będzie miał 100k elementów w każdej liście

Czym się różni Crud-owiec od programisty z prawdziwego zdarzenia

Praktyką od teorii.

Dobre CRUDy też trzeba umieć pisać, gdyż często ludzie je przekombinowują tak jak to @jarekr000000 napisał powyżej "pozornie skomplikowana aplikacja, używająca tony bibliotek, mapperów i warstw, która po krótkiej analizie okazuje się mocno rozdmuchaną przelotką do bazy danych"

Chyba chodzi o ludzi którzy ciągle wykonują ta sama powtarzalną pracę, która jest rozwijająca jedynie na początku kariery a ludzi którzy ciągle stawiają się przed problemami wymagającymi o wiele więcej umiejętności niż jedynie znajomość biblioteki.

Takie porównanie co przychodzi mi do głowy to jakbyś skończył fizykę i poszedł po najniższej linii oporu i został nauczycielem a mogłeś spróbować się ciągle rozwijać i spróbować znaleźć robotę w jakimś instytucie badawczym, albo jako inżynier w sektorze prywatnym.