Видео

Ależ to żaden atak, w trochę dramatyczny sposób chciałem przybliżyć realia pracy programisty, i wylać "kubeł zimnej wody na głowy" tych, którzy się szkolą na programistów, bo w ciągu kilku ostatnich tygodni słyszałem, widziałem jak ludzie (tak na oko to ich max pierwszy projekt w życiu tych osób) dyskutują, że "pracują w niepoważnej firmie, skoro muszą kasować kod", albo że "odrzucają PR, które zmieniają ich ciężką prace w weekendy" - gdyby śnieg leżał w górach powiedział bym, że przywiało trochę płatków śniegowych z tamtych stron dziękuję za komentarz

przyczyn jest kilka, ale ja wychodzę z założenia, że "kręcisz na siebie bat", nie raz widziałem ludzi, którzy brali ochoczo nadgodziny (sam byłem jednym z nich, gdy zaczynałem), aby po kilku tygodniach usłyszeć, że "jesteś niepoważny", skoro chcesz brać urlop w okresie świątecznym, albo odmawiasz, bo wykupiłeś sobie jakiś kurs i nie chcesz "wywalać pieniędzy w błoto", może ktoś z Twojego otoczenia ma urodziny, a Ty masz presję, że "czemu teraz nie bierzesz nadgodzin, zawsze brałeś", a jak trafisz na nadgorliwego menadżera, to może nawet będziesz miał "rozmowę naprawczą", że przez Ciebie projekt jest zagrożony, ale mogę tak wymieniać jeszcze kilka przyczyn ;)

celowo dałem ten tragizm i melodramatyzm, żeby pokazać, iż programowanie to nie "różowy jednorożec", gdzie nie ma problemów, sam pracowałem w instytucji gdzie "zmienność decyzji świadczyła o ciągłości dowodzenia", a w projektach IT, jest tylko nieznacznie lepiej (nikt nie odrywa się od obiadu, bo ktoś ważny przyjechał), jednak mam dużo bogatsze "doświadczenie zawodowe" i też pracowałem w dyskoncie, układając towar na półki, z tej perspektywy mogę stwierdzić, że praca na sklepie jest bardziej spokojna ;)

Cytując bardziej doświadczonych w kwestii prokrastynacji: "powodów, dla których prokrastynujemy jest wiele, często są to zaburzenia osobowości, zaburzenia depresyjne, lękowe, ADHD, ale też problemy w życiu prywatnym i zawodowym. Psychologia wyróżnia pięć lęków odpowiedzialnych za prokrastynację: lęk przed porażką, lęk przed sukcesem, lęk przed bezradnością, lęk przed izolacją, lęk przed intymnością." ale niemniej dziękuję za komentarz ;) , bo natrafiłem na nowe badani na ten temat: osf.io/preprints/psyarxiv/69zhd

też mam kolegów, którzy mają po 2-3 etaty (kontrakty), największy problem to spotkania w dwóch projektach o tych samych godzinach, ale mając już kilkanaście lat doświadczenia w zawodzie, mogę strzelać, że prawdopodobnie są to projekty wewnętrzne firmy (dla Pani z Księgowości, żeby ładniej coś wyglądało), z takimi ja się zetknąłem, one są dość "leniwe", tutaj nikt się nie śpieszy i najczęściej chodzi o zmianę "koloru przycisku", jednak można jeszcze w korpo trafić na projekt "jednego zadania rocznie", to już jest rzadkość, niemniej też się zdarza, a do "inflacji życia", że 55k miesięcznie to za mało, że by przeżyć od pierwszego do pierwszego, niedługo dodam film ;)

@@ProgramistaSchrodingerapytanie dlaczego opisywana przez Ciebie osoba nie mogła znaleźć przez rok pracy jak inni mają po kilka etatów ł. To ciekawe pytanie

@@mattkurantowicz tak, to zdecydowanie ciekawe pytanie, zdecydowanie na dłuższy wywód, jednak z moich spostrzeżeń wynika, że te osoby, które pracują dla kilku firm, pracują w tych samych technologiach, ta sama baza danych, te same biblioteki, itp. a czemu jest problem z zatrudnieniem, to z mojego własnego przykładu, jak poszukiwałem projektu, byłem odrzucany bo, nie znam wystarczająco dobrze, (dla kontekstu z Git pracuję już dość długo i jak to powiedziała Galadriela: "you haven’t seen what i have seen"), w jednej firmie - GitHub, w drugiej - GitLab, w trzebiej - BitBucketa, w czwartej Jenkinsa, ale wydaje mi się, że osoby, które rekrutują, chcą "poczuć władzę", bo kogoś odrzucają

mam do dziś Lenovo G505 E1-2100, od tego laptopa już Raspberry Pi są szybsze, ale przy lekkiej dystrybucji linuxa: Lubuntu, Puppy, BunsenLabs, "wszystko się może zdarzyć" ;)

nawet tej sztucznej inteligencji, ktoś będzie musiał "wklepać" co jest potrzebne, później to zweryfikować czy jakiegoś "Terminatora" nie wyprodukowała, czy innego Frikistaina i to też pod warunkiem, że rozwiązania, jakie tworzy ta firma są identyczne dla każdej firmy, bo im bardziej wąksa i dedykowana aplikacja, tym AI ma większe problemy, żeby coś sensownego zrobić

projekt, który wsadziłem do "Zamrażarki", na teraz nie mam przestrzeni na rozwój tego przedsięwzięcia, ale może kiedyś jeszcze wrócę, jak nie, to będzie jeden z projektów, który się nie udał - kolejny, który wylądował w koszu

Zapewne masz rację, ale nie jestem w stanie przypomnieć sobie takiej osoby wśród znajomych, jaką opisałeś, 5-6 etapowe rekrutacje występują wśród wielkich korporacji - te mają dziesiątki projektów i jak już się dostaniesz do jednego, to tylko składasz prośbę o zmianę projektu i tyle (bo ktoś inny sprawdził Twoje skille i nie ma innych rekrutacji, tylko płynne przechodzenie pomiędzy projektami/zespołami); szybciej 1-2 etapy są w "Małych rodzinnych kołchozach", jest max 2h rozmowy (bo prezentacja firmy, zespołów, i dziewczyny z HR muszą zaprezentować, że warto pracować u tego klienta), czasem jeszcze rozmowa z prezesem i "Witamy na Pokładzie"

@@ProgramistaSchrodingera to że nie ma takiej osoby w twoim gronie znajomych to nie znaczy że takiej osoby nie ma na planecie Ziemia, ja również nie mam wśród znajomych łysych więc zapewne tacy ludzie nie istnieją. Wracając do rozmowy statystyki mówią jasno, aktualnie na jedno stanowisko IT aplikuje 500-1000 osób, firmy prowadzą 4-6 etapowe rekrutacje oprócz jedynej pana firmy na ziemi, kandydaci szukają pracy miesiącami, stawki dobre tylko dla osób ze skilem 2-3 pracowników, pracując w Niemczech na magazynie na 2 etaty również możemy zarobki 4000euro 17k pln ;) z punktu ekonomicznego nie widzę sensu aby młodzi pchali się w ta branże

@@OpiniotworczyGracz-qm9pc niestety ja z łysymi spotykam się na co dzień (prześladują mnie, widuję ich kilka razy dziennie), ale do pracy w IT to na jedno miejsce jest kilkaset aplikacji, jednak są to osoby, które chcą wejść do IT, lub mają małe doświadczenie, osoby z większym stażem mają trochę inną drogę rekrutacji - tutaj najczęściej to firmy headhanterskie wydzwaniają (wysyłają maile) i poszukują, więc te statystyki są "ukryte", nie jestem zwolennikiem wpychania ludzi "kolanem" na stanowisko programisty, uważam, że warto nauczyć się programowania, ale od branży IT i programowania najlepiej trzymać się jak najdalej, a co do pracy na magazynie, to sam pracowałem jako magazynier, pakować, spedytor, itp

Zależy ile jest etapów i na którym etapie, czasem firmy mają dość rozbudowane "sita", szczególnie te większe, przez które przechodzi takie CV, teraz coraz częściej pierwszy etap sprawdzania jest systemy ATS - nikt nawet nie patrzy na CV, później, jak system uzna, że kandydat spełnia wyznaczone kryteria, pokazuje takie CV komuś z działu HR - tutaj może być już telefon do kandydata, albo przesłanie CV do jakiegoś menadżera, który decyduje, że można porozmawiać z kandydatem, albo CV jest dalej "procesowane" i przechodzi przez poszczególnych menadżerów, później jak już zbliża się rozmowa z kandydatem, to osoba techniczna może dostać takie CV (albo i nie), żeby się przygotować do rozmowy, albo to ktoś "z łapanki" (sam miałem nie-przyjemność być taką osobą), która dostaje CV kilka minut przed rozmową. Ale teraz świat się zmienia, coraz częściej do systemów ATS dodawana jest AI, połączenie z LinkedIn i rekruterzy dostają "gotowy produkt" w postaci kandydata na rozmowę.

na początku, tylko spring web i innych nie dodawałem, chodziło tylko o uruchomienie aplikacji, a później - w miarę potrzeb - będę dodawał kolejne, tutaj pokazuję jak się pisze program bez "gdybania", bierzesz tylko to co jest potrzebne, mam wizję, ale jak to w IT, wizja może się zmienić, bo pojawił się klient, który "zapłaci więcej"

"Stanę Okoniem" i powiem, że Nie warto mieć nowego szybkiego sprzętu, dobrze mieć sprzęt, którego możliwości wykorzystasz, bo po co ci jakiś Ryzen 9 (Intel ma zadyszkę z i9, więc je pomijam 😉), skoro jedyna gra jaką uruchamiasz to Pasjans, a w przeglądarce masz 3 zakładki, jak każdy "Janusz Biznesu" tnę koszty gdzie się da, ale realnie podchodzę do sprzętu, bolidem F1 nie pojedziesz naszymi Polskimi drogami, ale Maluch na A4 to prośba od kierowcy do Świętego Piotra o wpuszczenie bez kolejni za "Brany Niebieskie" 😉

@@ProgramistaSchrodingera problem może się pojawić jak przy uruchamianiu programu w IDE masz odpaloną przeglądarkę i jeszcze przydało by się Postman-a odpalić. Czasem ten czas i niepotrzebne nerwy lepiej zamienić na jakiś lepszy sprzęt

Wa alejkum szalam. Nic ciekawego nie pokazuję na tych nagraniach, więc trochę "przycinam" obraz, ale ostatnio eksperymentuję z innym "tłem", niemniej jeszcze nie mam satysfakcjonującego rezultatu i jeszcze mam stare background :)

Ludzie i interakcje ponad procesy i narzędzia... To prawda, często jest to błędnie interpretowane a dokumentacji, zwłaszcza na tym poziomie logicznym, gdzie pracuje Analityk, który rozumieć powinien zarówno Biznes jak i IT, nie ma właściwie wcale! To błąd nie tylko dlatego, że "Programista może obejrzeć film, czy przeczytać streszczenie". To błąd również na etapie Utrzymania i Rozwoju (czyli przy rozwiązywaniu Zgłoszeń), bo wtedy brak dokumentacji powoduje brak świadomości potrzeb zmian w poszczególnych miejscach Systemu. Wstępem do każdej Analizy Zgłoszenia powinna być lektura Dokumentacji Projektowej, ale AKTUALNEJ I UTRZYMYWANEJ W AKTUALNOŚCI RÓWNOLEGLE Z KODEM! Trudniej po prostu przedzierać się za każdym razem przez kod, by się zorientować w potrzebach, bo kodu z reguły jest masa, a Analiza, byle jakościowo dobra, prowadzi niemal od razu "w punkt". Bardzo niedoceniana, pozytywna strona posiadania Dokumentacji, ale... POPRAWNIE ZBUDOWANEJ! Miewałem do czynienia z kilkunastoma tomami dokumentacji, każdy tom liczył od kilkuset do tysiąca kilkuset stron, a całość warta była tyle, co... Papier, na której ją spisano! "Nie ma co czytać dokumentacji, ona niewiele ci da! Musisz pytać ludzi!" - słyszałem to często, a to znaczy, że nie wykonano roboty, jak należy!

Działające oprogramowanie ponad obszerną dokumentację... Dokładnie tak. Pod warunkiem, że Dokumentacja jest dobrze sporządzona. Tak, jak zostało powiedziane - dokumentacja łączy tych, co odeszli (ich wiedzę - nie ważne, czy "zeszli", czy "odeszli";) z tymi, co przyjdą. Jest skala CMMI "dojrzałości procesowej" organizacji. Można w tej skali oznaczyć również proces produkcyjny: 1 Poziom - procesy organizowane "ad hoc", za każdym razem inaczej, po czym zespół się rozchodzi i nie korzysta z doświadczenia poprzedników. 2 Poziom - procesy intuicyjne i powtarzalne, stały, zgrany zespół. Wszystko działa, ale do momentu, gdy odchodzi członek Zespołu - wszystko trzeba "układać" od nowa z tym, że prawdopodobnie uda się "Nowego" przysposobić, ale coś na pewno zrobi po swojej "intuicji" a to prosta droga do błędów... 3 Poziom, "bezpieczny" - procesy jak na poziomie 2, ale udokumentowane, co pozwala przekazać widzę pomiędzy "zeszłym" a dopiero co "przyszłym" członkiem w Zespole. 4 Poziom - procesy udokumentowane, jak na poziomie 3, ale też opatrzone KPI - Key Performance Indicator'ami, czyli miarami, które pozwalają określić ich parametry. 5 Poziom - jak na 4, ale KPI służą do weryfikacji efektywności procesów, które dzięki temu są często modyfikowane, usprawniane. To poziom Organizacji Uczącej się. Dokumentacja to poziom 3 CMMI, czyli pierwszy BEZPIECZNY DLA ORGANIZACJI poziom dojrzałości procesowej (Procesu Wytwórczego, Projektu itp.). Jak wspomniałem wyżej, to pozwala szybciej i lepiej zrozumieć zagadnienie - nieważne, czy będzie to CR, czy Zgłoszenie Serwisowe.

Jeszcze odnośnie "Działające oprogramowanie ponad obszerną dokumentację..." Potrzeba UTRZYMANIA dokumentacji, jak kodu - o tym już pisałem, ale... Dokumentacja powinna być sporządzana nie tylko na poziomie Kodu, ale wyżej, na poziomie Projektu Technicznego, jeszcze wyżej, na poziomie LOGICZNYM - Analizy Biznesowej czy Analizy Systemowej. Rzecz w tym, by była nieprzegadana i "doszczegóławiana" na drodze "od biznesu, aż po kod"! Tak, to trzeba umieć, a większość Analityków tego nie potrafi, o "Developerach" nie wspominając... Dlatego w projektach pojawia się Analityk, jako próba stworzenia "hybrydy" pomiędzy podejściem Agile, a opartym o standardy Inżynierii Oprogramowania (części Inżynierii Systemów). Ale problem pozostaje - umiejętna organizacja i zarządzanie WIEDZĄ w Projekcie - dokumentacją na różnych jej poziomach. Bo naprawdę, można zaszkodzić, zamiast pomóc, jeśli dokumentacja będzie pływała od Sasa, do Lasa, od obłoków, aż po lochy... Odpowiednia Granulacja, poziom szczegółowości/poziom abstrakcji - to sztuka tak zorganizować dokumentację, by łatwo w niej znaleźć potrzebne informacje na odpowiednim poziomie abstrakcji, z możliwością uszczegółowienia, w razie potrzeby. Właściwa organizacja dokumentacji, to sztuka. Ale da się.

Współpraca z Klientem ponad negocjację Umów... To podejście "nieformalne" jest dobre w "Projektach Wewnętrznych" (jeśli kiedykolwiek da się je prowadzić projektowo wewnątrz firmy...), ale zdecydowanie nie pomiędzy Zamawiającym i Wykonawcą Zewnętrznym! Znaczy, gdy nie ma budżetu i możemy sobie pozwolić na przeciąganie prac, bo zakres w niekontrolowany sposób "popłynął". W projektach "na zamówienie", w przetargach, to jest murowana katastrofa, bo w trakcie projektu pojawiają się różnice w interpretacji ze względu na inaczej rozłożone interesy stron! Po prostu, każda ze stron zawsze będzie interpretowała uzgodnienia na swoją korzyść, dlatego... W projektach kiedyś, każdy warsztat/spotkanie projektowe było dokumentowane, ustalenia były weryfikowane i formalnie zatwierdzane, a uzgodnienia były rygorystycznie przestrzegane! Oczywiście po każdym Warsztacie było tworzeni Modelu Systemu (w danym zakresie), czyli inaczej "Dokumentacji Projektowej" (de facto specyfikacji pracy do wykonania). To wszystko w oparciu o określone procedury. Nadal tak to wygląda w projektach w przetargach, np. dla Administracji Publicznej, z prostej przyczyny - potrzeby ŚCISŁEGO rozliczania budżetu (oraz bardziej po ludzku - potrzeby posiadania "dupokrytki" przez Urzędnika). Takie procedury postępowania z ustaleniami, wymaganiami, modelem(dokumentacją) często zawarte są w Umowach i bywają bardzo szczegółowe.

Reagowanie na zmiany ponad realizację Planu. Plan? JAKI PLAN! Rozpoznanie, Mitygacja i zarządzanie Ryzykami w Projekcie? Jakie RYZYKA?! Harmonogram? A PO CO TO KOMU! Tak, to też często ma miejsce. W jednym z ostatnich, dosyć dużych projektów, w jednym z największych banków w Polsce, miałem problem - PMa praktycznie nie było w projekcie (i w sumie po jego pojawieniu się, z koleżanką doszliśmy do wniosku, że "na szczęście", go w Projekcie nie było...). Ryzyka nam "odpalały" jedno, po drugim, z powodu niekontrolowanych wrzutek! Pracy nad Procesem wytwórczym (a przypominam, była to ogromna korporacja) było tyle, że w zasadzie miałem 3 refleksje: - Nie wiem, w co mam ręce włożyć! Od braku jakichkolwiek formalnych standardów i ich kontroli, aż po organizację pracy, przy pierdylionie narzędzi - każdy mógł korzystać z dowolnego narzędzia, z całej puli, nieraz robiących podobne rzeczy... - Stajnia Augiasza, taki był galimatjas, - Powinienem porozmawiać ze wszystkimi - dosłownie, niemal od przysłowiowej "Sprzątaczki", aż po Prezesa... Prawie nikt nie wiedział, jak zorganizować robotę z Projektem (i firmą...). "Huston, mamy problem", chciało by się powiedzieć... Koleżance powiedziałem, że w zasadzie, gdybyśmy tak nieefektywnie wykonywali pracę, przez te "wrzutki" i sposób organizacji pracy, nasz Projekt powinien trwać... 4 lata (a obliczony był na 12-14 miesięcy!). No i faktycznie, musieliśmy "okroić zakres", znaczy części roboty nie zrobiono... Płynny i niedookreślony zakres pozwolił ukryć fakt, że nie ruszyliśmy systemu "głęboko"... Jak odchodziłem z firmy, jej Szef stwierdził, że musieli powołać zewnętrzną firmę i tam przenieść część Aplikacji do przepisania, bo "jesteśmy tak nieefektywni, że gdybyśmy chcieli zrobić to własnymi siłami, przepisywanie aplikacji trwałoby 4 lata"... niemal powtórzył to, co i mnie się "objawiło", w trakcie pracy. Oczywiście po "przesunięci" części Zespołu, ta zewnętrzna firma zaczęła rekrutować ludzi... Najbardziej prymitywny sposób rozwiązania problemu - poszukać na zewnątrz, a nie utrzymać kompetencje Zespołu na wysokim poziomie. To też trzeba umieć...

Agile/Scrum to narzędzia używane głównie przez zespoły inżynieryjne. Inżynierzy nie lubią spraw komplikować.

nigdy nie byłem filozofem, też nie wiedziałem jak głęboko mam zejść, ale uznałem, że głębokość morza Bałtyckiego będzie wystarczająca :)

dziękuję za podpowiedź i fakt trochę szkoda, że nie ma tej możliwości na ukrycie kanału

dziękuję za informację o książce, aż tak nie zgłębiałem tego "artykułu", jednak czytając go miałem wrażenie, że jest przeznaczony dla pewnego wycinka menadżerów, który nie potrafią zarządzać projektami (czy ludźmi), ale szukają winnych na około, a tu trafił się "chłopiec do bicie", w postaci Agile, pominąłem fakt, że uważam iż autor tworząc ten artykuł, chciał usprawiedliwić swoją niekompetencję w kierowaniu ludźmi, a jego analiza Scrum miała tylko "połechtać jego ego" (ale tu się jednak pomyliłem z oceną, bo chodziło o promocję książki)

Brytyjska matematyka, wystarczy mówić z pewnością siebie.

Oryginalny artykuł mówi o "268% wyższym wskaźniku porażek", to tłumaczenie tutaj jest (chyba) celowo click-baitem. :)

ta ja tez tak robilem, ze ogladam tutorial jednoczesnie na drugim monitorze programuje to, implementuje albo sie tym bawie

dla mnie również, takie podejście jest najlepsze, sam uczę się najwięcej próbując uczyć innych, albo "udaję, że tłumaczę coś małemu dziecku", od razu widać luki, których mi brakuje podczas takiej nauki, ale z drugiej strony barykady, uczę ludzi, którzy potrzebują powtórzyć materiał kilka razy i po tygodniu, przy "niedzielnej kawce" im coś zaskoczy, wszystko się rozjaśnia, są różne metody nauki, najtrudniej jest znaleźć ten, który pasuje "Tobie", a szkoła uczy tego najmniej przydatnego i najgorszego: Zapamiętywania Na Blachę

"przysłuchiwałem się" takiej rekrutacji (zostałem zaproszony, żeby wypełnić puste krzesło), ale osoba odpytująca podsumowała, że na stronie firmy są informacje o "Współpracach", więc kandydat nawet nie zadał sobie trudu sprawdzenia, z czym będzie miał do czynienia w firmie, raczej nie chciałbym współpracować z Tym rekruterem w jednym zespole, bo on "nigdy się nie myli", ale to historia na inną "przypowieść" ;)

Zdaję sobie sprawę, że to jest perspektywa tylko jednej strony, i zapewne zamglona emocjami, niemniej widzę dużo osób w swoim otoczeniu, które postępują podobnie, "domyślając się" czego oczekuje pracodawca i zabierając pracę do domu, osobiście mam nadzieję, że ktoś obejrzy ten film i zastanowi się, czy aby na pewno nie żyje złudzeniami o awansie, podwyżce, itp. poświęcając swoje prywatne życie. Ale Tak, strata pracy to nie koniec świata, przynajmniej nie dla mojej koleżanki, ma nowe perspektywy ;)

mam w planach jeszcze webinary gdzie będę pokazywać podejście do nowych funkcjonalności, jak to ugryźć i rozpocząć implementowanie, chcę też przygotować materiał w postaci eBooka, który by pokazał proces i kroki decyzyjne przy rozpoczynaniu nowych funkcji

Miałem styczność z dużą ilością programistów, dla części z nich (tej mniejszej) Clean Code jest pretekstem, żeby pokazać kto ma większe Kochones, ich komentarze są raczej przytykami jakiegoś toksyka: "Ty zawsze...", "Już nasz stażysta lepiej pisze kod..." Do samego Clean Code, to uważam, że jest on dla mnie, czasem pisząc kod mam wrażenie, że tu i teraz to jest OK, ale gdy wracam do kodu po miesiącu i tak dokonuję jakiejś małej zmiany: aktualizacja nazwy zmiennej, wyciągnięcie jakiegoś warunku do metody, bo jednak pamięć ludzka jest zawodna i to co na pierwszy rzut oka, było czytelne i klarowne, po pewnym czasie już nie jest, a to że koledzy mogą po mnie "odziedziczyć" czytelny kod, jest tylko pozytywnym "wypadkiem przy pracy"

w teorii to tak powinno działać, jednak na daily mówisz, "że jeszcze testy dopiszesz, zrobisz fasadę, wydzielisz interfejs, żeby szybciej zaimplementować ostateczną funkcjonalność", w odpowiedzi słyszysz, że "do jutro ma to działaś i być przetestowane przez zespół testerski, bo jutro jest demo, a poza tym to za dwa tygodnie ma pobierać dane z bazy danych", a osoba, która robi review: "co ten menago wie, mają być testy, nawet jak będzie opóźnienie", i zaczyna się ping-pong, gdzie piłeczką jest osoba pisząca kod

​@@ProgramistaSchrodingera a wtedy mówię, a mnie to lotto, za dużo bierzesz do siebie

nie możesz przejmować się rzeczami które od Ciebie nie zależą

@@ProgramistaSchrodingera jak jest toksyczna atmosfera to pyk i zmieniamy pracę

@@Niceguy54444 o 15:00 wysłałem maila do wszystkich zainteresowanych z cc do mojego bezpośredniego przełożonego, że wszystko jest już gotowe, zgodnie z ustaleniami i można merdżować, i wyszedłem do domu, 2 dniu późnij miałem "rozmowę korygującą", że jestem nieodpowiedzialny, a kilka tygodni późnij zmieniłem projekt (tak, projekt był toksyczny - np.: ściągali ludzi z urlopów, bo trzeba "coś" dowieźć na CITO)

bardzo dziękuję, tutaj jedynie pokazuję pomysł na własny projekt i odpowiadam na pytanie "jak zacząć pisać aplikacje?", można to traktować jak szkielet, każdej aplikacji, którą chcesz stworzyć

Nie chodzi o "Dirty Code", tylko o przepalony czas i perfekcjonizm, oraz (czasem) nadgodziny, dla przykładu wpada zadanie o 17:00, trzeba zrobić hotfixa, produkcja stoi, poprawa to tylko usunięcie zbędnych spacji ze stringa, ale siedzisz do 2 w nocy i dopisujesz testy, których zabrakło, hotfix miał być "na wczoraj", i pytanie czy skoro siedzisz do 2 w nocy ten hotfix jest tak ważny? Staramy się trzymać wyśrubowanych standardów, tracąc z oczu celowość pisanego kodu, "dlaczego tworzysz kod?", a odpowiedzią na to pytanie, są jakieś piękne słowa zasłyszane na konferencji.