Craft-IT 2023 - Jarosław Pałka - 25 lat mijania się z prawdą

Kto nie chciałby zobaczyć, jak tym wystąpieniem niszczę swoją karierę? Minęło 25 lat, co brzmi jak wyrok za ciężką zbrodnię z mrocznych zakątków kodeksu karnego, ale dla mnie to czas podsumowań. Prezentacja, stand-up, coaching? - nazwijcie to jak chcecie. Będzie o naszej branży, biznesie i o nas samych, o "uniwersalnych kłamstwach", które często powtarzane stają się prawdą. To będzie brutalny przewodnik po karierze w IT. Wielu z was zapewne poczuje się urażonych, ale jestem gotów na to poświęcenie. Czy wybór technologii ma znaczenie? Dlaczego większość stanowisk to "bullshit jobs"? Czy greenfieldy naprawdę są takie fajne? Komu potrzebne są estymaty? Co się dzieje, kiedy nie udaje się dowieźć sprintu? Jak feedback stał się rakiem toczącym organizacje? Dlaczego duża część z nas ma wrażenie, że ciągle robi to samo? I jak w tym bajzlu zachować szacunek do siebie, zdrowie psychiczne i dobrze bawić się przez 25 lat? Postaram się odpowiedzieć na te i inne pytania, które sam sobie stawiam od dłuższego czasu. Ci którzy odsieją śmiech przez łzy w tej prezentacji, odnajdą kilka cennych rad jak pokierować swoją karierą.

[@ernestbursa4791]

Pięknie

[@rniestroj]

"Nie podejmowanie odpowiedzialności" 👈

[@remek712]

Trochę jakbym o mnie słyszał, ja jeszcze spotkałem się z tym że Sprinty są często wykorzystywane przez managerów jako „2-tygodniowe” deadline’y. Praca co dwa tygodnie ma być skończona i już, bo na kolejne dwa tygodnie jest już nowy materiał zaplanowany. Gdy byłem młodszy dawałem się wciągnąć w to, inni koledzy także, ale aż wstyd mówić ale robiliśmy darmowe nadgodziny bo taka presja w Sprintach była by dowieźć wszystko na czas.

[@kapelin2]

Jakie są tytuły książek wymienionych w prezentacji?

[@grandpapamacias]

Antykruchość. Jak żyć w świecie, którego nie rozumiemy - Nassim Nicholas Taleb
Thinking in Systems: A Primer - Donella Meadows
Simple_Complexity: A Management Book For The Rest of Us: A Guide to Systems Thinking - William Donaldson PhD

[@AmonAsgaroth]

Narzekanie na managerów i testerów to trochę domena juniorów. Nikt doświadczony, kto miał okazję zasmakować jak to jest być firmowym człowiekiem orkiestrą na to nie narzeka.
Hasło "sami się prosicie, nie podejmujecie odpowiedzialności" chyba nie przynosi tu spodziewanego efektu, bo odpowiedź brzmi "tak, a o co chodzi"?
"Wyoutsourcowanie" rzeczy, którymi zajmują się teraz te stanowiska, pozwoliło programistom na skupienie się na węższym zakresie tematów (dalej bardzo szerokim), zwiększenie rzeczywistego impactu (postrzegany pewnie zmalał) w firmach i tym samym zwiększenie zarobków.
To trochę jak spodziewanie się, że jak zrobimy programistom więcej spotkań w ciągu dnia, to lepiej i szybciej napiszą ten kod.
Kiedyś właśnie trzeba było myśleć o wszystkim i już w ogóle nie było czasu na automatyzacje i jakiekolwiek przemyślenia na temat usprawnień w kodzie.
Z większością reszty prezentacji się zgadzam, ale przecież "ostrożnie z tempem rozwoju" i "nie przejmujcie się deadlinami, bo ustalają je ludzie przy golfie" i "opuszczanie strefy = bullshit" to przeciwieństwo tego co było na początku.

[@allegro3785]

37:40 Jaka jest druga i trzecia książka? Ktoś może mi pomóc i podać tytuł wraz z autorami? P. S. Znalazłem odpowiedź w innym wpisie.

[@stig44]

SM właśnie jest osobą, która upewnia się, że zespół pracuje optymalnie, tj. maksymalnie efektywnie. Kropka. Lepiej jeśli nie jest to jeden z programistów, bo są sytuację w których ktoś w roli SM musi wyjść poza zespół, spojrzeć krytycznym okiem czy wręcz dosadnie skrytykować. Wg mnie dobrze jeśli jest ktoś taki na kilka zespołów, bo mitem jest, że SM musi a) organizować każde spotkanie b) wiedzieć o wszystkim co robi zespół c) robić cokolwiek konkretnego w sprincie lub być taką "sekretarką". Jeśli dany zespół akurat nie potrzebuje uwagi, może w ten sposób skupiać się na innych. Bo przecież zespoły powstają, zmieniają się, degradują i SM jest od tego, aby zespół dążył do lub był zawsze w jak najlepszej formie. Chyba miałem szczęście pracować w firmie, gdzie rozumiano tę rolę poprawnie.

[@ukaszszurgot1624]

U mnie SM na zespół, chociaż zdarza się, że SM ma dwa zespoły. Zwykle większość czasu SM nie ma co robić, więc wysyłamy go na spotkania z klientem, lub robi demo produktu. Nie jestem zwolennikiem tego co się dzieje, ale tak chce duża korporacja w której pracuje.
Kiedyś słyszałem, że niektóre firmy mają agile coacha, który jest na kilkanaście zespołów i służy radą, jeśli zespół przyjdzie do niego i powie, że z czymś ma problem. Nie jestem pewien, czy każdy zespół jest na tyle świadomy problemów, że sam przyjdzie i spyta o pomoc. Ze swojego doświadczenia wiem, że raczej jak zespół widzi problem, to go sam rozwiązuje, a jak nie widzi problemu, to zwykle go nie naprawiają bo nie mają świadomości jego istnienia. Wtedy pomocny wydawałby się SM.

[@afronski]

Jarku, fantastyczne wystąpienie! Nawet nie wiesz jak bardzo, bardzo, BARDZO się z Tobą zgadzam - i dokładnie ze wszystkim, co poruszyłeś w trakcie. *Amen*.

[@jacekm.1789]

świetne! dokładnie tak miałem w dużych korpo

[@SearDark]

Dla mnie to jest trochę socjalistyczna prezentacja o tym jak klasa robotnicza zdaje sobie sprawę, że w pracy ich celem nie jest jak najbardziej wydajna praca i dostarczenie dobrego produktu tylko spełnianie potrzeb emocjonalnych właścicieli kapitału.

[@maciej12345678]

tia 26:24 wszystko bardzo pięknie a teraz ML wykosił 75% stanowisk razem z bankami 38:14 jej odkryłeś matematykę a dowody do tego są ? 39:46 a to działa gdy starasz się o pracę hmm dobry tip do Juniorów po co macie czytać programujcie bez pojęcia przeczytajcie 4 książki o filozofii i was zatrudnią mhm to są pomysły z dupy -- DOWIEZIECIE słowo klucz menagerów

[@AirQKosmo]

Agile: zestaw dobrych praktyk, SCRUM: maszynka do zarabiania pieniędzy luźno oparta na tym pierwszym th-cam.com/video/hG4LH6P8Syk/w-d-xo.htmlsi=Gqr1IfAViqAA-APW&t=983