Jak uciec od CRUD development i rozwinąć się ponad to?

0

Myślę, że wielu z Was zadawało sobie to pytanie. Więc jakie macie pomysły na ucieczkę od biznesowych webowo bacekndowych CRUDów?
Ogólnie też wydaje się zauważalne, że "webówka" jest coraz bardziej jest biznesowa niż techniczna i no... generalnie pod względem technicznym wydaje się, że coraz mniej trzeba umieć. Coraz więcej "samo sie robi".

Może:

  • embedded
  • low level
  • infra/devops/SRE
  • Data
  • security
  • po prostu trza być dobrym

WDYT?

1

Możesz podjąć wyzwanie, które podjął już @jarekr000000 i refaktorować nierefaktorowalne za ciężkie pieniądze :]

0
Wibowit napisał(a):

Możesz podjąć wyzwanie, które podjął już @jarekr000000 i refaktorować nierefaktorowalne za ciężkie pieniądze :]

Ło panie. Ja już trochę projektów z 0 testów , 0 logow, ifami w stylu "if personId == 34 then" widzialem.
Wiec chyba zostalo mi troche instynktu samozachowawczego by tego nie robic ;)

1

Przy okazji też przypomne o temat embedded
"Ostrzeżenie dla chcących zaczynać karierę w embedded Linux/BSD/FreeRTOS itp" https://api.4programmers.net/Forum/Kariera/282620-ostrzezenie_dla_chcacych_zaczynac_kariere_w_embedded_linuxbsdfreertos_itp?page=1
(w sensie trawy bardziej zielonej po jednej stronie płota)

7

Po pierwsze - niestety logika biznesowa jest nudna. 5% z tego co biznes chce to "wyzwania", reszta to tony nudnych szczegółów.
Nic z alternatyw, które wpisałeś w żaden sposób cię od nudy nie uwolni. (Może na chwile, zanim opanujesz).
Chcesz mieć ciekawie - zrób własny projekt, firmę - będziesz mógł wynając ludzi od nudnych tasków. Ewentualnie zatrudnij sie jako szkodnik architekt i rób jakieś frameworki/ platformy, które reszta zespołu będzie musiała stosować (ze łzami w oczach). Poza Niemcami nie wiem czy ten model jest popularny.

Po drugie: pytanie czy nie byłyby te projekt tak tragiczne, gdyby je trochę inaczej robić. To ludzie robią CRUDy, chociaż nikt ich w praktyce nie potrzebuje - skutek tego jest taki, że cała ciekawa logika siedzi w GUI /JS, bo backend to przelotka na bazę danych. CRUD - to CRUD. Pytanie, czy masz pomysł jak robić, żeby było mniej zniechęcająco?

0

Wez taki system Crudowy i spraw zeby uzywal dwa raz mniej resourcow albo dzialal o polowe szybciej.

0
WhiteLightning napisał(a):

Wez taki system Crudowy i spraw zeby uzywal dwa raz mniej resourcow albo dzialal o polowe szybciej.

Fajnie, i tak w wiekszosci nikt tego nie doceni...

0

@rav3n: zależy, czego oczekujesz. Jeśli potrzebujesz feedbacku czy choćby prostej krytyki, pewnie to ma znaczenie. Ale jeśli robisz dla siebie, by samemu czuć, że robisz coś lepszego, fajniejszego, to może nie mieć znaczenia, czy ktoś to doceni, czy nie. PS. Żadna z tych możliwości oczywiście nie jest gorsza ani lepsza według mnie.

4

Przejdź do Security.

1

Może w sumie inaczej... Mam juz co nieco lat doswiadczenia. I w sumie caly czas brakuje mi tego aspektu Engineering. A web development (i backend) to moda i przeczucia a nie inżynieria. I czesto wrecz mozna sobie pozwolic na robienie syfu bo "rozejdzie sie po kosciach"

The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.

Nie pracowalem za bardzo przy cyzms low level ale jednak jak cos sie stanie w tych nizszych warstwach to ludzie dostaja ataku paniki... wiec wydaje sie, ze tam poziom inzynierii powinien byc wyzszy.

A architektura z kolei to mam wrazenie, ze to bardziej nauka o ludziach, Conway's Law i te sprawy...

1

Z rzeczami które działają live jest czasem nawet spoko zabawa: jakaś giełda, bukmacherka czy coś podobnego

4
rav3n napisał(a):

Może w sumie inaczej... Mam juz co nieco lat doswiadczenia. I w sumie caly czas brakuje mi tego aspektu Engineering.

Bo to żaden engineering nie jest. Tam gdzie jest prawdziwy engineering, za rozwiązanie w stylu

> Ej, jesteś pewien że to nie je**nie? Wychodzą za duże naprężenia na trzecim filarze, a czwarty jest prawie nieobciążony, źle to wyważyliśmy
> Powiemy robolom, żeby zespawali je tu i tu i będzie cito, nie pyskuj

Poleciałyby zarzuty prokuratorskie, gdyby coś potem je**o. W IT przyłazi Ci jakiś 'murican engineer i mówi, żebyś zahardkodował niektóre dane w kodzie aplikacji, bo jemu coś nie pasuje i on nie chce żeby cośtam. I można go w wentyl cmoknąć, nawet jeśli przez jego wymysły potem coś wybuchnie.

Nie pracowalem za bardzo przy cyzms low level ale jednak jak cos sie stanie w tych nizszych warstwach to ludzie dostaja ataku paniki...

Bo mają jakieś dziwne przeświadczenie, że jak zajrzą do tych bebechów i dotkną tego palcem, to palec się rozpuści od kwasu a świat wybuchnie. Wszystko, co nie jest wystawione na zewnątrz czarnej skrzynki przez jakieś API jest tajemnicze, złe i nietykalne.

wiec wydaje sie, ze tam poziom inzynierii powinien byc wyzszy.

:D co potwierdzają Spectre, Meltdown i inne ciekawostki tak niskopoziomowe, że bardziej się nie da, które wypłynęły w ciągu ostatnich 2 lat :] w kodzie LLVM też widziałem różne kwiatki, które co prawda nie weszły jeszcze z żadnym releasem tylko kisiły się w branchu na boku, ale np. przez pół roku "fixowały" jakieś issue, ale tylko w losowych momentach i nikt tego nie ruszał :D W ogóle dobrze też poczytać wyznania developerów z Oracle czy innego MS o tym, jak wygląda taki wieloletni, prawdziwie gigantyczny kod, którego pierwsi twórcy są już prawdopodobnie na emeryturach ;)

0

@superdurszlak:

Dokładnie. W programowaniu jest nuda, bo nie ma uczucia ryzyka.

2

Ja chciałbym przytoczyć
To to to https://clubhouse.io/blog/accountability-is-the-difference-between-software-engineer-programmer

"Of the 43 freelancers - all of whom had at least two years of experience in programming - 25 initially chose to store the passwords in plaintext."

"You might hear programmers referred to (negatively) as “code monkeys,” which sounds (and is) insulting, but how else could one describe the 25 freelancers choosing to implement password storage in plaintext?

“I was aware that the good practice is to store them securely, but the task didn’t mention anything about that.”

0

W low level i embedded też są nudne i powatrzalne zadania. Jeżeli soft jest na rynku dłużej to i utrzymania będzie sporo. Poziom programistów jest też różny, są przecietniaki, są i gwiazdy.

5

(W większości przypadków) robienie czegokolwiek biznesowego jest nudne z racji tego, że jest biznesowe. Pisząc "biznesowe" mam na myśli coś za co klienci płacą i oczekują stabilnego działania oraz wdrażania na czas potrzebnych im funkcjonalności. Mocno zaszaleć nie można bo:

  • kasa nie bierze się znikąd - implementowane funkcjonalności muszą przynajmniej wyglądać na opłacalne
  • funkcjonalności są narzucane z góry, a programiści tylko mogą zasugerować jak je nagiąć, by lepiej pasowały do aktualnej architektury
  • terminy gonią, a biznes chce widzieć postęp - stąd zmiany trzeba rozbić na krótkie fazy, które da się sukcesywnie wdrażać na produkcję, chociażby w stanie "dormant" (gotowe na włączenie)
  • pracujemy w zespole i nie możemy sobie hamować nawzajem pracy, a więc nie można zbyt dużo popsuć, nawet jeśli planujemy wszystko odkręcić i nawet znacznie polepszyć w ciągu np miesiąca
  • biznes zwykle nie zgadza się na zbyt egzotyczne eksperymenty - rozwiązania mają być w miarę standardowe, bo wynajdywanie koła od nowa czy szalona kreatywność są raczej kosztem niż zyskiem
  • kod musi spełniać szereg wymogów dotyczących zalecanych praktyk (np SOLID w OOP), pokrycia testami (różnego rodzaju), a przede wszystkim czytelności dla pozostałych (a także przyszłych) członków zespołu - z tego powodu np prosty i czytelny algorytm O(n lg n) oparty o wysokopoziomowe konstrukcje z wbudowanych w język kolekcji jest znacznie lepszy niż algorytm O(n) oparty o niestandardowe struktury danych (nawet jeśli te struktury są zrozumiałe dla przeciętnego studenta informatyki, który zaliczył przedmiot Algorytmy i Struktury Danych)
  • (w specyficznych branżach, np finansach) dużo czasu schodzi na spełnianie zachcianek klientów i regulatorów - tu trzeba ekstra raport dorobić i wysyłać co miesiąc, tam trzeba stosować niestandardowe nazewnictwo plików, jeszcze gdzieś trzeba optymalizować pod Internet Explorera (wersja 11 też zamula), etc
  • itd
1
rav3n napisał(a):

Nie pracowalem za bardzo przy cyzms low level ale jednak jak cos sie stanie w tych nizszych warstwach to ludzie dostaja ataku paniki... wiec wydaje sie, ze tam poziom inzynierii powinien byc wyzszy.

Raczej się bardzo rozczarujesz. Moje największe rozczarowania były związane z przeglądaniem kodu JVM i modułów do apache (to drugie to w sumie nie tak low level). To też robią programiści tacy jak my ;-)

Co do CRUDa jeszcze. Całkiem nieźle omija sie CRUDY jak sie popracuje nad wymaganiami. Zwykle nalegam, żeby dokumentacja/stories były w postaci szkiców gui, bardzo konkretnych przypadków użycia.

Jak zadanie jest postaci - zarządzanie listą zadań... to u każdego jurnego architekta wywołuje to niezdrową chęc walnięcia CRUDem i pozamiatane.
Jeśli natomiast sformułowane jest w stylu: lista pokazuje 10 ostatnio zmienionych zadań. to nagle zupełnie inaczej API wygląda i warstwa DAO pods spodem. Mniej nonsensu i logika nie jest tak rozmyta po systemie. Zwykłe Client first.

Ale dopracowywanie wymagań jest jeszcze nudniejsze niż CRUDY :-)

No i po kolejne, to nie znaczy, że taki system bankowy staje się nagle fascynujący. Nudy jak dawniej, tylko nieco mniejszy poziom frustracji w kodzie. Nieco.

1

"Devops" i SRE to też ciekawa ścieżka. Ale ogólnie większość tych ludzi ma dość tej fuchy. Z takich powodów jak niżej.

"Good operations can often work around the limitations of bad (or incomplete) software, but good software cannot run reliably with bad operations"

Spotkałem wielu z bardzo dobrą wiedzą ludzi na takich stanowiskach, którzy zjadaliby na śniadanie większość architektów i developerów.

Oni za milijony cierpią i supportując często coś co wydawałoby się nie ma prawa działać.

0

Ja jak szukam mięsa w mięsie to wchodzę np. tu:
https://blog.cloudflare.com/author/marek-majkowski/
https://idea.popcount.org/

0

A na to wszystko przychodzi HR i mówi "szukamy najlepszych" zamiast "mamy taki syf , że nikt nie chce tego dotykać dlatego tak dużo płacimy".

1

Myślę, że warto przytoczyć tu:

Btw. Programiści za często zrzucają winę na biznes, najczęściej to programiści są winni zaistniałej sytuacji.

0

@jarekr000000:
A robiłeś kiedyś audyt jakiegoś systemu?

2

Tak. Do oszacowania kosztu obsługi, szukania winnych, ukarania niewinnych. Ale tak naprawdę to lubie tylko te robione pod kątem wydajności.

6
rav3n napisał(a):

Myślę, że warto przytoczyć tu:

Btw. Programiści za często zrzucają winę na biznes, najczęściej to programiści są winni zaistniałej sytuacji.

Seliga to żaden autorytet, to jest problem naszej sceny "youtubowej", każdy się wypowiada z perspektywy samozwańczego wieszcza ;)

1

Załóż se pan firmę i pisz co chcesz ;)

1

Wlasnie w moim feed wyskoczył artykuł “The software development economy” by Andrew Howden https://link.medium.com/akPk0Smd0W

Bardzo mi tego brakuje. Widziałem dwie strony medalu.

  1. Produkt, który wstrzelił się w luke i bardzo dobrze zarabiał. Straszliwe marnotrawienie kasy, zero regulacji kosztów developmentu czy zasobów. Wewnętrzne projekty które trwały rok i zdechły - nie wiadomo czy kiedykolwiek miały szansę powodzenia.
  2. Cebula style software house - robimy absolutne minimum co chce klient - ogólnie całkiem uzasadnione. ale również oszczędzanie na każdym kroku na pracownikach itp.

Ogólnie jakość jednak była lepsza przy cebuli.

1

Ogólnie rynek u nas to:

  • albo rodzime projekty od (w większości) januszy vel "panie, a za co ja mam tyle płacić"
  • albo outsourcing, taki hindus+, co siłą rzeczy musi również mieć niższe, konkurencyjne stawki, w stosunku do firm stacjonarnych

Dodajmy do tego realia zarządzania polskiego betonu i niewiele zostaje miejsca na poezję kodu ;)

5
rav3n napisał(a):

Myślę, że wielu z Was zadawało sobie to pytanie. Więc jakie macie pomysły na ucieczkę od biznesowych webowo bacekndowych CRUDów?

Kluczem jest moim zdaniem rozwój nie w kierunku bycia super programistą tylko super inżynierem. To znaczy, nie rozwijać się w kierunku: jak coś napisać tylko: co napisać. Inżynier pogłębia wiedzę obszarową i skupia się na rozwiązywaniu problemów inżynierskich lub badawczych, a nie programistycznych.

Moim zdaniem należy wybrać sobie jakiś obszar, np: uczenie maszynowe, widzenie maszynowe, NLP, grafika i modelowanie 3d, przetwarzanie obrazów, automatyzacja, telekomunikacja, automotive - i w nim się rozwijać. Przy tym zgłębiać matematykę, algorytmikę, optymalizację. A odpuścić, a przynajmniej nie skupiać się na nauce kolejnego języka, albo kolejnej wersji języka który już zna, kolejnego paradygmatu, technologii, frameworka, sztuczek, kruczków, czyli 156-tej metody na robienie tego samego tylko w modniejszy, albo bardziej zgodny z aktualnymi programistycznymi dogmatami sposób, bo to jest właśnie na dobra droga by zostać super programistą i pisać nudne aplikacje biznesowe.

0

a gdyby tak po prostu znaleźć projekt, który według ciebie umożliwiłby Ci największy rozwój i zaaplikować do tej firmy?

Zamiast szukać od strony technicznej, to od strony produktu i liczyć, że od technicznej jest ok

1

@tdudzik wyciągam do posta, bo ambicje to już w ogóle temat na grubszą dyskusję

Nie chce porównywać do tego co bylo kiedys, bo nie wiem jak bylo, ale duzo ludzi ma teraz możliwości finansowe, czasowe i intelektualne ale nie chce nic z tym zrobić. Nie wiem skąd to wynika, może to nasza polska mentalność
Brakuje mi w ludziach pasji i zaangażowania w tym co robią. Dlatego pewnie nasz kraj wygląda jak wygląda, bo wszystko się robi na odwal się, bez jakiejś woli zrobienia tego po prostu dobrze.

Ależ oczywiście, że ludzie nie mają żadnych ambicji, niczego im się nie chce, wszystko załatwiają "na odwal się" i wszystko chcą mieć podane na tacy - tylko patrzeć, jak zaczną robić pod siebie na ulicach, jeśli ktoś ich w porę nie wyręczy i nie posadzi na najbliższym porcelanowym tronie. Bo chodzenie z czystymi czterema literami będzie już zbyt ambitne.

Za "moich czasów" - czytaj 1-3 rok studiów - w kołach naukowych było po 20-30 osób, 80% z tego to byli właśnie studenci pierwszych lat, którzy szukali pomysłu na siebie i coś tam próbowali działać, a reszta już od dłuższego czasu działała, coś robiła, coś organizowała, miała projekty, granty i takie tam, no i dodatkowo jakaś praca w międzyczasie więc i czasu mniej niż w przypadku młodych. Jak przychodziło do KSKN (konferencji kół naukowych na AGH) to w każdej podsekcji było *naście referatów, z tych 20-30 osób wychodziło po *naście referatów. Jak trzeba było organizować jakieś eventy typu Festiwal Nauki i Sztuki w Krakowie (takie tam, głównie pokazy dla dzieci) to młodsze roczniki latały i to ogarniały.

A teraz wszystko się totalnie odwróciło. Z 20-30 osób zrobiło się mocno naciągane 10, zamiast 15 referatów na konferencję mieliśmy może 6-7 (w tym dwa moje). Na Festiwalu Nauki i Sztuki stoiska ogarnialiśmy my - 4 i 5 rok, bo młodszym nawet się nie chce zapisać do koła i coś porobić, a co dopiero ruszyć gdzieś tyłek - może 2-3 osoby mamy z 3 roku i niżej, reszta to "stara gwardia" z magisterskich. Już w zeszłym roku było widać, że coś się psuje i coś się zmienia, ale w tym to już jest wg mnie dramat - zresztą do tegorocznej KSKN myślałem, że to u nas są jakieś słabsze lata, że to u nas jakoś mniej ludzi, że wprawdzie u nas się powykruszali, ale gdzie indziej się to jakoś trzyma - a gdzie tam... jak się rozmówiłem z osobami z innych kół na konferencji, to wielu skarżyło się na to samo.

Młodym nic się nie chce, nie angażują się, na nic nie mają ochoty, paluszkiem kiwnąć nie raczą. A na miasteczku studenckim pucha, emigrowałem i bez spiny, są trzecie terminy.

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