Wątek przeniesiony 2020-07-06 19:27 z Off-Topic przez cerrato.

Dzielenie się wiedzą

2
katelx napisał(a):

napisalam "bez obrazy" ale widze ze jednak zabolalo.

Nie zabolało, wyłącznie rozśmieszyło, szczególnie ten fragment o marce, korpo-odlot wymieszany z brakiem doświadczenia życiowego :D Marka cię przeżuje i wyrzuci do kosza przy pierwszej okazji :) To był taki epicki odlot, że aż nick zapamiętałem :) Firma żywi, firma radzi, firma nigdy nas nie zdradzi!

wiec jeszcze raz - pomijajac wartosci etyczne

To praca, nie kierunek filozoficzny. Wystarczająco etyczna jest dobra kooperacja, co wbrew waszym jękom - ma miejsce w całkiem przyjemnej atmosferze, ale w zakresie, o którym ja decyduję.

czy zwyczajne kolezenstwo ktore to najzwyczajnej sa ci obce

Co jest mi obce nie tobie oceniać, ale jeśli już idziesz w tą stronę - stosownie odpowiem w dalszej części. Praca to nie Partia Przyjaciół Piwa.

jest to dosc oczywiste wymaganie dla doswiadczonego profesjonalisty pracujacego w zespole ze swoja wiedza sie dzieli. nie spotkalam sie jeszcze z zespolem w ktorym zacheca sie do tego co ty probujesz uskuteczniac, jest dokladnie na odwrot.

Gdzie padło, że się ZUPEŁNIE niczym nie dzielę? Wielokrotnie napisałem coś zupełnie przeciwnego, podkreślając jedynie, że:

  • poziom owego dzielenia jest uzależniony od jakości współpracy, poziomu współpracującego i tego, jak ów rokuje (np. wykładanie godziny teorii, gdy ktoś na koniec najwyżej pamięta, że opowiadałem śmieszne żarty, bo zwyczajnie nie jest zainteresowany, niezależnie od jakości tłumaczenia - jest oczywistą stratą czasu)
  • jestem przeciwny dzieleniu się rzeczami spoza scope (i swoimi obraźliwymi tekstami tylko mnie w tym utwierdzasz - rośnie moja świadomość, że niestety trzeba żyć wśród lasu przypadkowych roszczeniowców urwanych z bootcampów)

gdy ktos nie pomaga mniej doswiadczonym to albo nie ma wiedzy, albo jest leniem, albo nie nadaje sie do pracy w zespole, albo wszystko na raz.

W pracy masz wykonywać pracę, a nie szkolić team (o ile nie masz takiej roli). Jeśli nie wykonujesz swoich obowiązków, zamiast tego prowadząc ludzi za rączkę, to do zwolnienia. Dla mnie leniem jest ten, kto sam ma taski do ogarnięcia, a biega sobie po biurze i bawi się w nauczyciela.

tak jak wspominalam - takie podejscie przechodzi w firmach zajmujacych sie outsourcingiem. w miejscach gdzie liczy sie talent i rozwoj, normalnym jest dzielenie sie wiedza. jednostki ktorych glownym celem jest tworzenie sobie job security sa przez wspolpracownikow ostracyzowane a przez pracodawcow widziane jako zlo konieczne.

Nie widzę tu żadnego job security i nawet niespecjalnie staram się, aby takowe istniało, bo po prostu (to będzie dla ciebie ciężkie do przejścia) jestem dobry i odnajdę się wszędzie.

zdecydowanie nie jestem osoba ktora sie ciagnie za uszy zeby szly naprzod. za to wiele razy mialam do czynienia z takimi "ekspertami" co przez 3--6 miesiecy nie zdradzaja sekretow w stylu ze output z tej legacy libki trzeba zrzutowac na long bo jak nie to potem robi overflow w runtime, nie wiem czemu ale kiedys poswiecilem tydzien zeby do tego dojsc, niech sie kazdy tak meczy.

Jeśli dochodziłaś do tego 3-6 miesięcy (bo inaczej nie wiem o czym ta historia - jeśli wiedziałaś, to by cię te 3-6 miesięcy nie dotyczyło), to już świadczy samo za siebie, bez komentarza :)
Nie mam takich śmiesznych sekretów, takie trivia normalnie się sprzedaje na bieżąco na forum publicznym, to nie jest skala, o której mowa.

a potem mija nastepne pare miesiecy i nagle wielki buldopy ze junior zarabia tyle co ja, jak to mozliwe przeciez ja tak swietnie pracuje.

Nigdy nic takiego nie następuje, gdy faktycznie jest się dobrym. I u mnie nigdy nie miało miejsca. Już słyszę trzask tyłka w tle, miód na me uszy :)

a niby dlaczego nie? jesli zamiast spedzac 3h nad dokumentacja mozna spedzic 1h i przy okazji zobaczyc jak to dziala w naszym projekcie, dostac wskazowki na temat naszego git workflow i pare linkow co przeczytac zeby jak najszybciej byc w stanie cos robic zamiast odkrywac kolo na nowo

Dlatego, bo to podstawa podstaw. Poza tym własne przejście ścieżki uczy. Pozwala popełnić błędy, zrozumieć. Zlokalizować zasoby, ustawić sobie wszystko. Jadąc skrótem zawsze kończy się tym, że wcześniej czy później ktoś zawali coś poważniej, bo nie przeszedł podstaw sam. Nie ważne jak się to wytłumaczy i jakie ma się zdolności. Uczenie podstaw nie jest częścią pracy, nie wiem co kto robi przychodząc do firmy programistycznej i potrzebując tutoriala z gita, chyba pomylił drzwi.

lol, rozumiem ze nie spotkales sie z zadnym koderskim blogiem, forum czy kontem na githubie gdzie ktos za darmo daje rady odnosnie programowania? kolega z zespolu to dla ciebie "random" :D

Czytanie cię przerasta? Co trudnego jest w zrozumieniu stwierdzenia, że są rzeczy publiczne na githubach (blogach też), ale są też prywatne i prywatne projekty prywatnymi zwykle pozostają, a już na pewno nie są otwierane, bo ktoś tam stęknie "dej". Kolega z zespołu to - uwaga - współpracownik. Bywa, że przyjaciel, ale nie jestem zwolennikiem "kumplowania się", bo mając swoje lata doskonale wiem jak to się kończy - wychodząc z biura zostawiam biuro i ludzi za sobą. Niektórzy przyjaciele z byłych firm sprzed lat do dziś stale coś ode mnie chcą, choć ludzi na oczy nie widziałem i po 20 lat (co przy okazji świadczy, że aż taki zły jednak nie jestem, bo mogłem ich dawno przegonić). Wracając do meritum: jeśli nie widzę żadnego sensu w udostępnianiu czegoś komuś, bo nie wyciągnie z tego żadnych wniosków, ani niczego się nie nauczy - moje prawo.

tough life :D a tak serio to gadasz farmazony, nikt nie odpada, po prostu wdrazanie sie trwa duzo dluzej niz powinno przez arogancje projektowych "ekspertow".

Jeśli ktoś się wdraża np. 2 lata, mając dokumentacje, bazy wiedzy, tickety i to ma być winą tych "ekspertów", co nie chcą mu dać gotowego, to ktoś tu upadł na głowę, i to nie ja.

to dowodzi ze nie umiesz tlumaczyc albo po prostu nie rozumiesz co robisz. uczenie kogos nie polega na odpowiedziach w stylu tu daj nawias i odwal sie ode mnie.

Nie muszę, nie jestem zatrudniony na stanowisku nauczyciela, a firma to nie bootcamp. Uczenie kogoś w pracy jest nienormalne i niemoralne już samo w sobie. Zatrudnia się programistę (w założeniu) wykształconego. Wdrożenie oczywiście jakieś być musi, ale oparte o wiedzę kandydata, którą mieć musi. I to wdrożenie nie powinno przekroczyć miesiąca (nawet to za długo). W pracy się umie lub uzupełnia wiedzę o specyficzny workflow, toolsy itp. Gdyby nie było dokumentacji, to bym rozumiał, że trzeba dodatkowo siąść z kimś, ale nie - nie ma u mnie takiej sytuacji. Wszystko jest, poza zaangażowaniem. Zamiast zaangażowania jest za to roszczeniowość - widoczna też w twoich postach. Filozofia dej. Wydaje mi się, że to znak czasów, jeszcze parę lat temu tak nie było. Ludziom się chciało rozwijać, kombinować samemu, a teraz: łojezu, łojezu, jak sprawdzić, czy liczba jest nieparzysta, jak jest w ogóle "parzysta" po angielsku? o jak super, is-odd :D

wyczuwam bolace ego. a o co chodzilo z toolem? o automatyzacje zadan czy o zaangazowanie teamu w rozwoj toola? jak juz ustalilismy twoje soft skille sa na bardzo niskim poziomie, wiec moze po prostu nie zacheciles ludzi wystarczajaco?

Miałem im kupić jakieś prezenty? :D Zasponsorować wycieczkę na Bahamy dla najaktywniejszego commitującego? :D Dać całusa (facetowi? fuj) :D Już samo pchnięcie skostniałej struktury powinno być wystarczająco zachęcającym sygnałem, że coś się da. Tylko, że nie da się, jeśli po prostu nikomu się nie chce. Nic więcej nie muszę. Opaczny efekt końcowy utwierdza mnie w przekonaniu, że wszystko out of scope nie ma prawa trafić do szerokiego grona. Nawet dla dobra ich samych. I od tego mam doświadczenie, żeby to rozumieć.

Zastanawiałem się na początku, czy może się jednak nie mylę, przybyłem tu po argumenty, ale ich nie otrzymałem. Jedynie wyzwiska frustratów, którzy tam gdzieś głęboko w środku mają świadomość, że mnie by nie naciągnęli i że może ich też tak ktoś postrzega, co pewnie jest przykrym zderzeniem z rzeczywistością - są tacy, to nie żart... :)

dlaczego w ogole uzywamy libek zamiast pisac wszystko samodzielnie...

Zależy jakich libek, jeśli jesteś dumną użytkowniczką wspomnianego is-odd, to: za mało wiedzy i leniwość jednocześnie. W ogóle - ponownie - mądry senior (ma nad wyraz skromna osoba na ten przykład) nie używa bezmyślnie tony libek i zależności do każdego piernięcia w kodzie. Tym policy kierujemy się wszyscy w zespole. Wieloletnie doświadczenie (coś, czego nie masz) mówi, że bardzo szybko projekt staje się dependency hell. Koszmarem trudnym do utrzymywania, pełnym legacy i śmieci. To się odkrywa mając kilkadziesiąt dowiezionych projektów, w różnych technologiach i różnie podchodząc do rozwiązywania tego problemu na przestrzeni lat, z różnymi ludźmi i ich pomysłami. I nie ma to żadnego związku z tym, co napisałem i co cytujesz.

Cały twój post to obraz polskiego internetu. W zasadzie jakichkolwiek argumentów (i tak bezsensownych) to jest tu może z 5 wyrazów. Reszta to różne próby obrażania mnie, na co jestem zmuszony odpowiadać w podobnym żenującym tonie. A to bo nie pasuję do twojej wizji socjalistycznego świata :D I zapewne masz świadomość, że także trafiłabyś u mnie do grupy, którą odsyłam do dokumentacji (bo od tego jest) i nie bawiłbym się w siedzenie pół dnia i tłumaczenie tobie gita. Praca to nie bootcamp.

Wątpię, czy jest sens kontynuować tą dyskusję. Już widzę, że nie dowiem się od was nic odkrywczego, bo po prostu nie macie nic, co by merytorycznie odnosiło się do sprawy. Z mojej strony raczej EOT - i tu szkoda mi czasu. Oddaję moderatorom: jeśli widzicie w tym temacie sens, to proszę bardzo, ale jeśli to ma wyglądać jak przez ostatnie strony, gdzie argumentów ze świeczką szukać, za to ma to przyciągać frustratów, w ciągu dnia siłujących się z każdą jedną linijką kodu, za to mogących wreszcie zabłysnąć anonimowo po robocie, to szkoda prądu.

Albo która sama te problemy stworzyła ;) We fired our top talent

Uwielbiam, gdy ktoś linkuje ten tekst - fajna zmyślona historia megalomana :) Autor tegoż sam został chwilę później wypierniczony, co każe przemyśleć na ile to było best decision ever, jeśli autora tejże pożegnano ledwie 8 miesięcy później. Gość jest typowym teoretykiem, który dodatkowo nawyolbrzymiał sobie na swoje potrzeby prawdziwą historię. Jego kariera pokazuje, że nigdzie nie może zagrzać miejsca (współczuję Netflixowi - od 3 miesięcy się z nim użerają). Podejrzewam jak historia wyglądała naprawdę - facet się nie mógł dogadać, więc pozbył się ludzi z pojęciem, po czym nastąpiła zapaść, zamiast rozwiązania kompletnego, sam się przyznaje, że dostarczył klientowi wynik odcinający 5% klientów, okrojony względem oryginalnego planu (pachnie PM-em, który bezmyślnie negocjuje zmiany po zdemolowaniu zespołu, gdy już wiadomo, że nie dowiezie, bo nie ma kim, a mógł to zrobić wcześniej, ów Rick spokojnie zrobiłby wersję prostszą, gdyby taką dokumentację dostał od początku, a nie negocjowano ją już po jego zwolnieniu :) ). Przy okazji wydano kasę na kupienie czego się da gotowego, co też świetnie znam - najpierw nie ma kasy na nic, ale jak jest nóż na gardle, to magicznie się odnajduje i zawsze zaczyna się od tego, by robić jak najtaniej, nie kupować nic, ale winny został dev, nie PM. Cała opowieść pachnie farmazonem, bo jeśli tworzyli to 5 lat (na co + 2 lata opóźnienia nie zgodziłby się żaden poważny klient), a jest mowa o kilku tysiącach linii (przed - 150000) + 10% tego co zostało Ricka, to chyba musieliby pisać po 1 linijkę dziennie. Tyle co tam jest opisane ja sam tłukę w góra 2 miesiące. Poza tym cały czas jest tam mowa, jakby te 5 lat Rick siedział sam, jeden samotny winny, reszta genialnego teamu patrzyła się w monitory. Sądząc po linku, odpowiednik bajki o Kopciuszku dla bootcampowców. Każdego Ricka można zastąpić skończoną liczbą studentów :D Czas wierzenia w bajki mam nadzieję wszyscy tu mają za sobą.

13

skoro z twojej strony EOT to jasne, nie widze potrzeby kontynuacji tej dyskusji, jednak nie byloby to w porzadku twoj dlugi wpis zignorowac.
wyglada na to ze przyszedles tu utwierdzic sie w swoim mocno dyskusyjnym podejsciu do pracy.
zapewne frustruje cie to ze oprocz tego ze praktycznie zaden pracodawca sie z toba nie zgodzi w tej kwestii, to nawet na anonimowym forum malo kto ci przytakuje; ludzie z duzo wieksza wiedza i doswiadczeniem maja zdecydowanie odmienne podejscie do tematu.
na twoim miejscu zastanowilabym sie nad tym czy rzeczywiscie masz racje, zamiast wyskakiwac z wycieczkami osobistymi i innymi malo merotorycznymi argumentami.
zaprzeczasz sam sobie, z jednej strony boisz sie ze junior cie wygryzie gdy go za duzo nauczysz, z drugiej krejuesz sie na eksperta/profesjonaliste ktorego kazdy chcialby zatrudnic.

4

Jakich argumentów? Przecież ja nie mówię o tym, czy coś generuje korzyść dla firmy, czy nie, tylko o Twoim stosunku do drugiego człowieka. Kim Ty w ogóle typie jesteś żeby w ogóle ludzi oceniać w kontekście czy ktoś jest wystarczająco GODNY żeby ZASŁUŻYĆ na pomoc? Dalej nie powiedziałeś jakie prestiżowe projekty klepiesz, bo póki co to w prostu mówisz, że Twoje wiadomości to prywatne żale emocjonalne kolesia, który poświęcił sporą część życia na zapier******* przed ekranem, a kiedy ktoś inny ma zajmować się tym samym, to nie pomożesz mu, bo też powinien się męczyć tak jak Ty. Brzydzę się takich ludzi, na żywo nie byłbym w stanie Twojej mentalności znieść i jakbym tylko usłyszał taką opinię poza pracą, to bym zaraz się odwrócił i nawet nara nie powiedział. Takich jak Ty trzeba poddawać społecznemu ostracyzmowi, bo jesteście toksyczni. Takich jak Ty widziałem w życiu pełno kiedy byłem dzieciakiem, ale na szczęście nasze społeczeństwo wraz z upływem czasu się bardzo zmienia. I bardzo się z tego cieszę.

6

Dokumentacje, to pewnie chowacie z kolegami po kiblach, no bo w sumie to sami się meczyliscie pisac ten kod, a teraz ktos jeszcze sie z nim zapozna i się okaze ze seniorki w firmie sie zasiedzialy i młody ich przegania.

7

Myślę że masz zbyt osobisty stosunek do pracy. Ja nie czuję że cokolwiek w projekcie jest moje, ani też nie rozczulam się specjalnie nad godzinami które poświęciłem na jakieś rozkminy - wziąłem za to pieniądze i nara, pomaganie osobom mniej doświadczonym jest częścią tej pracy i tyle. Ludzie są jacy są, jedni są pracowici, inni są leniwi, jeszcze inni przyszli tu na pół roku itd. tylko że to nie moja sprawa jakie ci ludzie mają motywacje, nie do mnie należy decydowanie czy ktoś jest "godzien" pomocy, skoro biznes ich zatrudnił to widocznie są im potrzebni - ja co najwyżej mogę dać feedback na temat danej osoby jeżeli ktoś mnie poprosi albo powiedzieć że support świeżaka mi zajmuje czas więc niech manager zdecyduje jakie mam mieć priorytety.

1
musrus napisał(a):

Praca dla mnie to praca, a nie pełnienie roli lokalnego, żyjącego i oddychającego serwera Stack Overflow. Kto sobie nie radzi - odpada.

To w takim razie nigdy nie zostaniesz seniorem. Pozostaniesz na ścieżce kariery jako Mid Developer i tyle.

Senior to chyba ten ostatni krok przed zostaniem dinozaurem (pamiętajcie - dinozaurów nikt nie chce - na pewno nie ci z FAANG) więc w sumie to chyba dobrze.

2
BDA DVB napisał(a):

Krótko: czy dzielicie się wiedzą z juniorami?

Gryzą mnie dylematy.
Z jednej strony: nauczę czegoś młodego, młody zrobi to za mnie, będzie więcej czasu na memy i flirty z recepcjonistką :)
Z drugiej strony: do niektórych rzeczy dochodziłem czasami naprawdę długo (taka branża) i wiecie - jakoś słabo mi się to spina, że ja coś przechodziłem na piechotę, a młody zrobi to samo z moją pomocą w tempie rakiety. Jeszcze wyjdzie, że młody jest lepszy niż ja, bo ja to samo ogarniałem miesiąc (tylko mnie nikt nie uczył).

Jeśli tobie to zajęło miesiąc a jesteś w stanie komuś wytłumaczyć to szybko tzn że to coś jest niepotrzebnie zagmatwane albo nie masz najszybszego tempa przyswajania.
Jeśli temat naprawdę jest trudny to nie ma drogi na skróty, możesz komuś wytłumaczyć ale przecież on nie zrozumie bez przejścia tej żmudnej drogi.
Więc nie widzę jaka to tajemna wiedzę miałbyś przekazać.

Niby przepływ wiedzy działa na korzyść zespołu, firmy, ale u mnie to działa w jedną stronę i jakoś nie czuję korzyści. Nawet jak dotychczas recepcjonistka nie odwzajemnia moich zalotów, także wiecie - nie ma zysku.

Myślę że zwykle przepływ wiedzy jest jednym z obowiązków pracowników, takim samym jak wykonywanie zadań. Może u ciebie jest inaczej.
Nawet jeśli faktycznie są przypadki że coś zajmuje długo za pierwszym razem a następni mogą z tego skorzystać to rozkminianie jako pierwszy rozwija mocniej niż gotowe rozwiązania więc to nie jest tak że cały zysk z wysiłku konsumuje ktoś inny.

Dlatego niechętnie dzielę się trickami, jakimiś swoimi autorskimi patentami. Ograniczam się bardziej do kierowania do dokumentacji, RTFM, LMGTFY itp.

Ciężko powiedzieć bez konkretów co masz na myśli ale "tricki" i "autorskie patenty" brzmią jak pokręcone workaroundy.

Jakie macie strategie? :) Wiedza wartością "open source" w zespole i każdy możliwy problem rozwiązywać przy okazji sprzedając patenty, czy jednak lepiej mieć pewne asy w rękawie?

Oczywiście pewnie zawsze dojdzie w końcu do wyzwania, które jest do zrobienia tylko przez osobę, która na różnych problemach zjadła zęby, ale wydaje mi się, że im więcej uczysz - tym mniej zostaje takich "wyzwań".

Jakie strategie? Nianczyc juniorów tak jak i mnie nianczyli na początku. Zamykając się w swoim gronie nie wystawiasz swoich pomysłów na krytykę, to jak siedzenie przy piwie z kolegami o tych samych poglądach politycznych, z takich dyskusji nie wynika nic. Jeśli chcesz sprawdzić czy coś rozumiesz to wytłumaczenie tego komuś innemu, najlepiej komuś z minimalną wiedza jest świetnym sposobem na weryfikację.

0

Ja powiem tak, najskuteczniejszą metodą dzielenia się wiedzą z każdym levelem, jest: pair programing
Niestety stosowałem jedynie przez 4 miesiące (projekt w USA) i codziennie w parze pracowałem z kimś innym.
Leciał książkowy Extreame Programing.
Polecam w całej rozciągłości. Największa zaleta, nie ma potrzeby code review, bo tę rolę pełni pair programing.

W obecnej firmie próbuję przekonać managera, by spróbować choć w ograniczonej wersji pair programing.
Teraz jest home office więc jest to trudniejsze do osiągnięcia.

Jedyna wada jaką widzę, to fakt, że wszyscy muszą przychodzić do pracy o jednej porze

7

Moim zdaniem zmienił się zeitgeist, obecnie każdy chce zarobić zamiast bloga - kurs online, oczywiście płatny. Jeżeli ktoś występuje na konferencji to raczej w celu promocji swoich usług konsultingowych lub osobistej marki niż z chęci przekazania wiedzy. Z drugiej strony te wszystkie budżety szkoleniowe tylko to nakręcają, dochodzi już do takich patologii jak płatne kursy Git'a chociaż najlepszy samouczek jest dostępny za DARMO w sieci (https://git-scm.com/book/en/v2). Wszystko to sprawia że zaczynamy mieć wrażenie że wiedza musi kosztować. Dlaczego ktoś miałby się nią dzielić za darmo? Zamiast napisać posta lepiej zostać trenerem na jakimś bootcampie i więcej $$$ do domu przynieść.

Z drugiej strony olbrzymi wysyp bootcampów, straszenie outsourceing'iem sprawia że wielu programistów zaczyna martwić się o swoją posadę (nie wspomnę COVID'a). Istnieje obawa "wyszkolenia swojego następcy" jak to ujął jeden z managerów. I niestety często tak się dzieje że pracownika z doświadczeniem zastępuję się tańszym, z rocznym stażem w danej firmie. Często odbywa się to nie jako jawne zwolnienie ale zamorzenie płacy i brak awansów.

Rozumiem że sporo osób może się w obecnej sytuacji obawiać dzielenia się, zwłaszcza ciężko zdobytą wiedzą. Mimo wszystko gdy przypomnę sobie jak trudno było by mi się nauczyć programowania
gdyby nie te wszystkie blogi, tutoriale, guide'y i pirackie sitey z książkami (it-book info pamięta ktoś jeszcze?). Gdyby nie porządne review czy praktyczne rady w stylu "nie rób deploya w piątek" :D
To widzę że kierunek jest tylko jeden, dużo wiedzy dostałem za darmo, dużo wiedzy za darmo "oddaje". Na koniec wspomnę że mentoring może przynieść dużo satysfakcji i potrafi być miłą odskocznią od codziennego kodowania, a że i od juniora można się czegoś nowego nauczyć to tylko na plus.

1

All day, every day, jak tylko mam okazję i z każdym kto chciałby się czegoś nauczyć.

0
katelx napisał(a):

skoro z twojej strony EOT to jasne, nie widze potrzeby kontynuacji tej dyskusji, jednak nie byloby to w porzadku twoj dlugi wpis zignorowac.
wyglada na to ze przyszedles tu utwierdzic sie w swoim mocno dyskusyjnym podejsciu do pracy.
zapewne frustruje cie to ze oprocz tego ze praktycznie zaden pracodawca sie z toba nie zgodzi w tej kwestii, to nawet na anonimowym forum malo kto ci przytakuje; ludzie z duzo wieksza wiedza i doswiadczeniem maja zdecydowanie odmienne podejscie do tematu.
na twoim miejscu zastanowilabym sie nad tym czy rzeczywiscie masz racje, zamiast wyskakiwac z wycieczkami osobistymi i innymi malo merotorycznymi argumentami.
zaprzeczasz sam sobie, z jednej strony boisz sie ze junior cie wygryzie gdy go za duzo nauczysz, z drugiej krejuesz sie na eksperta/profesjonaliste ktorego kazdy chcialby zatrudnic.

Żaden pracodawca nigdy się z nim nie zgodzi, nawet jeśli to ludzie nie potrafiący użyć googla, albo pytający o coś czego na stacku ani nigdzie indziej nie znajdą. Powód jest prosty:

Pracodawce boli najbardziej rotacja w zespole programistów, nawet taki mid i co poniektóry senior co wbija na projekt, a już nie mówiąc junior jest kosztem, przez spory czas nie generuje zysków tylko wdraża się i uczy projektu. Więc pracodawca zrobi i powie wszystko, żeby ten długi proces skrócić, między innymi zaprzęgając i zmuszając OP do dzielenia się wiedzą/pisania poradników do wszystkiego,opisów project specifics językiem for dummies i assisting przy problemach w trakcie wdrażania się.

0xmarcin napisał(a):

Moim zdaniem zmienił się zeitgeist, obecnie każdy chce zarobić zamiast bloga - kurs online, oczywiście płatny. Jeżeli ktoś występuje na konferencji to raczej w celu promocji swoich usług konsultingowych lub osobistej marki niż z chęci przekazania wiedzy. Z drugiej strony te wszystkie budżety szkoleniowe tylko to nakręcają, dochodzi już do takich patologii jak płatne kursy Git'a chociaż najlepszy samouczek jest dostępny za DARMO w sieci (https://git-scm.com/book/en/v2). Wszystko to sprawia że zaczynamy mieć wrażenie że wiedza musi kosztować. Dlaczego ktoś miałby się nią dzielić za darmo? Zamiast napisać posta lepiej zostać trenerem na jakimś bootcampie i więcej $$$ do domu przynieść.

Z drugiej strony olbrzymi wysyp bootcampów, straszenie outsourceing'iem sprawia że wielu programistów zaczyna martwić się o swoją posadę (nie wspomnę COVID'a). Istnieje obawa "wyszkolenia swojego następcy" jak to ujął jeden z managerów. I niestety często tak się dzieje że pracownika z doświadczeniem zastępuję się tańszym, z rocznym stażem w danej firmie. Często odbywa się to nie jako jawne zwolnienie ale zamorzenie płacy i brak awansów.

Rozumiem że sporo osób może się w obecnej sytuacji obawiać dzielenia się, zwłaszcza ciężko zdobytą wiedzą. Mimo wszystko gdy przypomnę sobie jak trudno było by mi się nauczyć programowania
gdyby nie te wszystkie blogi, tutoriale, guide'y i pirackie sitey z książkami (it-book info pamięta ktoś jeszcze?). Gdyby nie porządne review czy praktyczne rady w stylu "nie rób deploya w piątek" :D
To widzę że kierunek jest tylko jeden, dużo wiedzy dostałem za darmo, dużo wiedzy za darmo "oddaje". Na koniec wspomnę że mentoring może przynieść dużo satysfakcji i potrafi być miłą odskocznią od codziennego kodowania, a że i od juniora można się czegoś nowego nauczyć to tylko na plus.

Bardzo ciekawa wypowiedź, ja też zauważyłem te zależności.

Mnie jeszcze nurtuje jedna rzecz, dlaczego polski rynek nie zalała fala programistów z Indii/Chin/Rosji. Którzy będą robić to samo za mniej i popsują rynek jeszcze bardziej.

2
BDA DVB napisał(a):

Fajny dał tu ktoś przykład z Gitem. Na litość boską, jeśli ktoś wchodzi w branżę i ma problem z takimi rzeczami, to nie - absolutnie nie należy i wręcz nie wolno tego tłumaczyć. Rozwala mnie kompletnie, gdy czytam, że tak - trzeba się nawet tym dzielić, niezależnie od stanowiska - gdybym miał to robić, to nic, tylko bym siedział i gita tłumaczył :)

Z gitem jest tak, że łatwo zacząć z nim pracę, ale ciężko o smaczki. Jak ktoś korzystał samemu z Gita to może nie umieć rozwiązywać konfliktów, merge'ować, rebase'ować, squashować, cherry pickować, reflogować, ba, nawet może nie umieć pracować na gałęziach, bo mógł nie odczuwać takiej potrzeby.

I teraz tak - jeśli uważamy, że zaawansowana znajomość Gita jest konieczna, to co za problem spytać o te rzeczy na rozmowie kwalifikacyjnej? I wtedy osoba, która nie zna dobrze Gita, nie dostaje się do pracy. Czyli np. nie znasz na pamięć komend do cherrypickowania czy reflogowania albo nie znasz wszystkich internali? To się nie nadajesz na programistę.

Jeśli natomiast uważamy, że wystarczą podstawy Gita, że całą resztę można ogarnąć od seniora albo ze StackOverflow - to zatrudniamy osobę bez zaawansowanej znajomości Gita (tak samo jak są zatrudniane osoby bez zaawansowanej znajomości Linuksa, Dockera itp.).

Jednak skoro w firmie, w której pracujesz, zostały zatrudnione osoby bez zaawansowanej znajomości Gita, to oznacza, że widocznie osoby odpowiedzialne za rekrutację w twojej firmie mają inne zdanie na ten temat niż ty. Więc to ty jesteś outsiderem, że nie chcesz współpracować z osobami zatwierdzonymi przez twoich przełożonych.

0
Uśpiony wiosenny but napisał(a):

Mnie jeszcze nurtuje jedna rzecz, dlaczego polski rynek nie zalała fala programistów z Indii/Chin/Rosji. Którzy będą robić to samo za mniej i popsują rynek jeszcze bardziej.

To samo? Student po tym agh z wiedzą teoretyczną po roku produkuje lepszy kod, niż wyżej wymienione osobistości po 100 latach w branży.

5

Ten wątek ma wartość edukacyjną. Np. czasem narzekamy na JanuszSofty, a tutaj mamy pokazany mechanizm, w jaki sposób tworzą się JanuszSofty - właśnie przez takie zachowania, że nie pomogę nikomu, niech sobie sam radzi, schowam toole do szafki, moje bagno.

czy może się jednak nie mylę, przybyłem tu po argumenty, ale ich nie otrzymałem.

Trollujesz w tym momencie, bo pojawiały się argumenty, a każdy ci nie pasuje.

2

Ale nie ma się co spinać. Po prostu są ludzie tacy co mają w dupie dzielenie się wiedzą i są tacy, którym zależy na szybko kogoś wdrożyć do projektu :)

9

Autorowi szkoda czasu na uczenie juniorów, a mnie szkoda czasu na argumentowanie oczywistości panu nieomylnemu. Myślę, że jesteśmy kwita.

2

Odbierać komuś możliwość popełniania własnych błędów? Przecież to najlepsze co może być z całej tej życiowej farsy. Później jak się taki wyuczy na seniorach to na starość będzie smęcił że do niczego sam nie doszedł, uczył się od złych ludzi, zmarnował najlepsze lata, czasy się zmieniły a on dalej mieli tych swoich mentorów sprzed 30 lat.

Patrzcie jak się uczą brzdące - one się ciągle pytają, obserwują, powielają ale robią to na własny rachunek (bo nikt nie ma tyle czasu by go zapełnić młodemu ;)). Błędy to nauka myślenia. Pokazywanie krok po kroku to też nauka - tyle że konformizmu i ignorancji.

Sami krypto-komuniści w tym wątku - i dziwić się że zachód się z nas śmieje xD

0
loza_wykletych napisał(a):

Sami krypto-komuniści w tym wątku - i dziwić się że zachód się z nas śmieje xD

A jak pracowałeś z kimś z zachodu (UK / Irlandia / USA / Szwajcaria) to nie dzielili się wiedzą, jak zapytałeś? Bronili sowich "trików"?

6
BDA DVB napisał(a):

@ToTomki

Nie odnosisz się do żadnych argumentów.

Tego, co przedstawiasz w tym wątku nie można nazwać argumentami, tylko swoją filozofię życiową - bardzo ponurą zresztą. Przy okazji dorabiasz okoliczności do poglądów - jeśli już nie pamiętasz co sam pisałeś na początku, zaczęło się od

  • pomagania juniorom w ogóle
  • braku osobistych korzyści z pomagania
  • lęku przed tym, że junior zrobi szybciej jak mu pomożesz i wyjdzie na "lepszego"
  • chowania po szufladach "trików" i "autorskich patentów"

Potem w miarę rozwoju wątku i niepodzielania Twojego zdania okazuje się nagle że

  • tak naprawdę to nie chcesz pomagać juniorom bo to chodzenie na skróty...
  • ... no i niczego nie chowasz po szufladach, przecież do wszystkiego jest ogólnodostępna dokumentacja!
  • w ogóle to juniorzy nawet nie chcą zrozumieć geniuszu Twoich tooli...
  • ....a nawet jakby chcieli, to są zbyt głupi i nie zrozumieją, bo przerasta ich świat pull requestów i commitów...
  • ...więc wybierasz sobie kto jest godny kąpać się w blasku Twej wiedzy, a kto nie :D
  • a w ogóle to najwyraźniej na forum programistycznym są sami lenie i kretyni, skoro się z tym nie zgadzają :D :D :D
  • więc wychodzi na to, że jesteś samotnym geniuszem w oceanie imbecyli, wściekle napierającym ze wszystkich stron :D :D :D

[...] Współpracownicy nie są twoimi prywatnymi pomocnikami. Przede wszystkim mają swoją pracę i obowiązki do wykonania. W ogóle nie istnieje coś takiego jak "pomaganie komuś w pisaniu kodu w trakcie pracy". [...]
[...] Tak - nie każdy zasługuje, podtrzymuję. Pomaganie osobom, które chcą się na różne sposoby prześlizgnąć lub nie wykazują kooperacji, jest wręcz szkodliwe i nie robiąc tego: pomagam zespołowi i firmie. Skuteczna nauka będzie, gdy ktoś kreatywnie rozwiąże problem, niż gdy dostanie rozwiązanie na tacy, często nie rozumiejąc nawet zasad działania (jak było z tym moim jednym wspomnianym toolem). [...]
[...] W ogóle senior ma być ekspertem, ale nie dobrym duszkiem ratującym zadki. Jako senior mam robotę, którą mam zrobić. [...]

Najwyraźniej nie rozumiesz lub nie chcesz zrozumieć, na czym polega praca zespołowa i mylisz ją z walkami gladiatorów - i to się już pewnie nie zmieni, skoro ze swym wieloletnim doświadczeniem zdążyłeś zabetonować się w tym przekonaniu na amen. Zespół ma dowozić rzeczy i dopilnowanie tego mieści się w zakresie obowiązków każdego. Ale skoro wolisz bawić się w samozwańczego pół-boga i klejnot w koronie, który robi z firmy swoją piaskownicę i decyduje kto jest godzien dostać łopatkę, a kto nie...

Od tego jest CR, żeby później albo naprowadzić albo po prostu zbutować i zglebić kompletne idiotyzmy (demaskując przy okazji, że ktoś radzi sobie mizernie i trzeba się zastanowić co dalej, co nie jest moją osobistą rolą - ukrywanie takiego przypadku "pomagając" jest szkodliwe dla zespołu).

To, do czego służy code review najwyraźniej również nie jest takie oczywiste. Bo wychodzi na to, że celem CR jest zabawa w pana i władcę, który ułaskawia bądź karze wedle swego kaprysu. A przy okazji może sobie do woli gnoić i pokazywać "młodemu" jakim to jest niesamowitym debilem.

Gdyby mi ktoś podszedł i zapytał wręcz o pomoc w pisaniu kodu, to natychmiast bym oddelegował. Nie po to zatrudnia się ludzi, żeby następnie pisać za nich. Zatrudniani są programiści (przynajmniej w założeniu, praktyka bywa różna, niestety) z określoną wiedzą i gdy jej nie wykazują - nie jest żadnym moim interesem to zmieniać i "pomagać w pisaniu kodu". Tym bardziej, że nie mam za to płacone. Zwłaszcza, że owo pomaganie najczęściej sprowadza się do "zrób za mnie" i nie pozostawia żadnego trwałego śladu w głowie. W trakcie pracy masz być samodzielny + jest dokumentacja, jest internet. Jeśli sobie nie radzisz i ciągle potrzebujesz pomocy - jesteś w złym miejscu. Lekarz, jeśli sobie nie radzi na sali operacyjnej - zostaje z niej wyrzucony, a nie prosi błagalnym wzrokiem, "pomusz plis".

Mamy rozumieć, że rozwiązaniem problemów z niekompetencją pracowników jest urządzanie jakiegoś groteskowego reality show pokroju "wyprawa Robinson"? Jeśli zamiast podejść do tematu profesjonalnie wolisz "glebić", wybierać kto na co "zasługuje" i w międzyczasie pilnować, żeby to nie poszło w drugą skrajność i żeby nikt nie wyszedł na lepszego od Ciebie, to sam siebie ustawiasz jako seniora / PMa / TLa w jednym szeregu z juniorami, którzy nie potrafią sami napisać linijki kodu albo zrobić commita.

@musrus

Strach mi pisać, bo możesz tego nie przeżyć - zawał murowany, ale seniorem jestem od dawna :) Co jednocześnie nie ma dla mnie żadnego znaczenia, bo o moim statusie decyduję ja, a nie 6 literek. Zresztą na rynku to pojęcie straciło jakikolwiek sens. Seniorzy są dziś seniorami zwykle przez wzgląd na staż (jednocześnie uważając się za półbogów, co widać po tym, co piszesz :) ). Bardziej interesuje mnie hajs na koncie.

W jednym akapicie podkreślasz, że sam decydujesz o swoim statusie, a nie jakaś firmowa tytulatura, a jednocześnie zarzucasz innym obwoływanie się półbogami. Interesujące.

Jesteś w totalnym błędzie i to co piszesz jest właśnie przykładem mida. Mid jest wymiataczem, ale nie rozumie jeszcze co ma sens, a co jest stratą czasu, nie ma świadomości jak wygląda projekt całościowo

Ciekawi mnie, w jaki sposób można wymiatać nie rozumiejąc, co się robi i po co. Taki mid biegnie najszybciej w wyścigu, tylko w przeciwną stronę? Ma już własną kolekcję autorskich patentów, ale napisał je w PowerShellu podczas gdy wszyscy używają Maców, bo nie rozumiał co robi i po co?

Nie mówiąc o tym, że jeśli nawet do midów nie docierają tego rodzaju informacje, to coś jest mocno nie tak.

i nie zdaje sobie sprawy, że umiejętności miękkie wykorzystuje się tylko, gdy jest sens.

Najwyraźniej nigdy, albo tylko wobec przełożonych / klienta, a tych poniżej można sobie mieszać z błotem.

Senior ("mentalny") to jest ten szczebel, gdy już rozumiesz, że nie na każdego i nie na każdą sprawę należy poświęcać czas, bo w ogólnej, szerokiej perspektywie - to nie pomaga, nawet jeśli wydaje się, że lokalnie to coś zmienia. Że matkowaniem juniorom nie naprawisz świata, a dając toole nikt cię i tak nie doceni, przy okazji tylko odciążysz innych, ale nie siebie i nie zostanie to też w żaden szczególny sposób docenione w firmie, gdzie dla nich jest całkiem obojętne, czy robisz coś 15 minut, czy godzinę, już dawno jest to wkalkulowane w estymacje. Senior widzi kto rokuje, wyłuska łatwo gościa z pojęciem spośród stada pozerów. [...] To jest senior, a nie pipka siedząca nad nierokującym osobnikiem (który i tak zaraz wyleci), bo jej się włączył tryb zbawiciela i myśli, że coś usprawnia.

Całe szczęście, że obecnie nie mam wątpliwej przyjemności pracować z "mentalnymi" seniorami. Ale fakt, z jednym takim ancymonem miałem do czynienia - dość powiedzieć, że ciężko mu było napisać jednego e-maila bez nawrzucania komuś, wyciągnięcie od niego jakichś dokumentacji i konkretnych wymagań graniczyło z cudem, no i oczywiście wszyscy byli wszystkiemu winni, tylko nie on.

U mnie senior = nieformalny PM. PM zajmuje się biznesem, polityką, urabianiem klienta, marketingu itp. Ale technicznie jest słaby i wtedy wkracza gość, który właśnie:

  • szerokokątnie rozumie i widzi projekt, ogarnia cały horyzont tego, co się dzieje i jak jego robota wiąże się z resztą szajsu

A zatem jest "robota seniora" i "reszta szajsu". Ponadto senior/PM wie, co się robi i po co, a reszta wykonuje rozkazy bo nie dostąpili zaszczytu posiadania tej wiedzy.

  • wie bardziej niskopoziomowo kto co umie i kto co udźwignie, potrafi przewidzieć pewne fakapy zanim się wydarzą, bo np. widzi, że task wpadł do osoby, która go nie dźwignie

I oczywiście nie pomoże (bo nie warto), ani nie zainterweniuje i nie da tej osobie czegoś innego do roboty (bo przecież ma swoją pracę), tylko pozwoli żeby fakap się wydarzył, zespół nie dowiózł, winni zostali ukarani, a senior mógł pokazać, że jest lepszy bo on fakapu nie spowodował.

  • wie kogo można i warto wtajemniczyć szerzej, a kto pozostanie kulą u nogi, choćby mu się robiło codzienne prywatne korepetycje

Znów wracamy do tematu wybierania "godnych" i "niegodnych" i załatwianie tego metodą "na reality show".

  • przyjmie na klatę ciężkie taski, wymagające wyobraźni i kreatywności

To po co właściwie firma zatrudnia kogokolwiek poza Tobą, skoro nikt nie radzi sobie z cięższymi taskami, nikt nie potrafi ruszyć głową, nikt nie ma wyobraźni, nikt nie jest kreatywny i w ogóle nic tylko śmierć i pożoga?

Jeszcze raz: wszystko, cała wiedza jest spisana, jest dokumentacja, notatki też. W tej chwili każdy zielony u mnie z kopa jest w stanie wykonać zadania, jeśli tylko cokolwiek faktycznie umie oraz umie czytać dokumentacje, przeszukiwać bazy wiedzy (czyli bez jakiejkolwiek mojej pomocy i tak powinno być).

Przeczysz sam sobie. Z jednej strony twierdzisz, że wszystko jest spisane i udokumentowane, a z drugiej rysujesz obraz rzeczywistości, wedle którego nikt nic nie wie, niczego nie pojmie, d**y sobie nie wytrze i nie ma szans nawet pomarzyTć o tym bez Twojej boskiej interwencji - i ogólnie jesteś wprost niezastąpionym tytanem wspierającym firmę na swych barkach, bez którego niebo spadnie wszystkim na głowy. To jak to w końcu jest?

Jak się okazuje - nawet to stanowi spory problem. Jako stary stażem jestem celem pielgrzymek. W tychże rozróżniam dwie grupy. Skromna baza 2-3 osób wykazuje chęć do poszerzania wiedzy, nie czeka na gotowe rozwiązania. [...] Nadal niezmiennie nikt tu nie przedstawił kompletnie żadnych mądrych argumentów za pomaganiem grupie 2, wręcz odnoszę wrażenie że najbardziej cisną tu (bez argumentów) osoby, które bym do tej grupy natychmiast przypisał :)

Nadal skupiasz się na wznoszeniu peanów na cześć swojej wyższości nad tabunami imbecyli otaczającymi Cię w pracy, w sklepie i na forum, i najwyraźniej doskonale sobie radzisz bez względu na argumenty lub ich brak.

Co do owych tricków/patentów - wyjaśniłem już, że po prostu siedząc w projektach długo opracowałem prywatne narzędzia szeroko mówiąc "ułatwiające życie", dotyczące środowiska pracy, danych. Nijak to się ma do kodu, długu technologicznego (póki używa się zgodnie z przeznaczeniem), hacków - po prostu wykorzystuję wiedzę i znane sobie zależności, żeby dowozić efekty szybciej. Nie wiem, nie rozdłubywać czegoś na piechotę, tylko wygenerować, automatyzować. I także nie pada w temacie jak do tej pory żaden poważny argument czemu miałbym je udostępniać, podczas gdy ja przywołałem jak skończyło się udostępnienie innego toola. Skończyło się źle i to wręcz wygenerowało faktyczny dług technologiczny, bo to nie było przeznaczone do chodzenia na skróty, tylko zrozumienia architektury, wyskoczenia poziom wyżej.

Jak dla mnie w dalszym ciągu podpada to pod kategorię hacków i zabawy w brodatego alchemika robiącego hokus-pokus w piwnicy. Nie mówiąc o tym, to świadczy również o stabilności tych narzędzi, gdy jeden autor wie, w jakiej fazie księżyca wolno ich używać i że trzeba je zgłębić na wylot, by nie wsadzić sobie patyka w szprychy...

Większość tu to jakieś socjalistyczne gadki, bo pomoże zespołowi, firmie, marce. Nie mam tego w umowie i za to mi nie płacono, a robotę robiłem sam dla siebie w czasie na własne projekty. Sama firma ma to w zadku, bo procesy technologiczne żyją bez tego i czas ich realizacji nie obchodzi kompletnie nikogo, już dawno wszystko wyestymowano, usprawnienia są high level. Są natomiast oczywiście pożądane wśród zespołu, ale nie widzę żadnej motywacji (i nie pisać mi tu bajek o wspólnym dobru, to praca a nie komuna).

I jak to wytłumaczyć?

Może większość pracuje w firmach, które płacą im firmowymi pieniędzmi za bycie pomocnymi dla firmy - i oczekują tego nawet, jak nie jest to wprost wymienione w umowie?

A może w tych firmach na porządku dziennym używa się jakichś narzędzi mających usprawniać pracę i nie robi się z tego jakiegoś prywatnego hokus-pokus dla wybranych?

Pozostaję na stanowisku, że udostępnianie prywatnej pracy usprawniającej wykonywanie tasków jest błędem i nie widzę, aby ktokolwiek miał tu jakiś realny argument,

Dostałeś sporo odpowiedzi kto dzieli się wiedzą, dlaczego i czemu Twoje podejście za niezdrowe - ale najwyraźniej nic, co stoi w sprzeczności z Twoimi osobistymi przekonaniami, nie może zostać uznane za argument i świadczy o debilizmie rozmówcy.

szczytem waszych osiągnięć są najwyżej inwektywy, co zmusza mnie do odpowiedzi na zbliżonym, niskim poziomie :)

Można by dyskutować o tym, kto się ucieka do stosowania inwektyw, nawet pod adresem ludzi którzy nie brali udziału w tej dyskusji, ale najwyraźniej zdążyli sobie zasłużyć na zostanie "pipkami".

To jest senior, a nie pipka siedząca nad nierokującym osobnikiem (który i tak zaraz wyleci), bo jej się włączył tryb zbawiciela i myśli, że coś usprawnia.

1

Ej, a gdzie płacą za to, że nie trzeba pracować w zespole ani robić dla firmy? Mogę być nawet "mentalny" jeśli to jest w wymaganiach.

0
somekind napisał(a):

Ej, a gdzie płacą za to, że nie trzeba pracować w zespole ani robić dla firmy? Mogę być nawet "mentalny" jeśli to jest w wymaganiach.

W radzie nadzorczej.

7

Ogólnie bardzo chętnie pomagam i nie mam z tym problemu. Ostatnio miałem pewien zgrzyt z tym związany i prawdę mówiąc trochę mi się odechciało.
Frontend Junior chciał się trochę doszkolić (jak twierdził dla własnego rozwoju) w kwestii Dockera. Spoko, poświęciłem mu łącznie ponad godzinę po pracy. Chłopak twierdził że to jego prwatny projekcik edukacyjny. Myślę sobie - spoko, czemu nie. Wytłumaczyłem mu trapiące go kwestie, pomogłem w tym i w tamtym, spoko.
Mina zrzedła mi dwa dni później gdy okazało się że nasz kochany kolega odszedł z firmy z dnia na dzień (nie przedłużając umowy, mimo że wcześniej obiecywał że to zrobi) . Jego projekt w domu okazał się zadaniem zaliczeniowym do innej firmy...
Jakoś przeszła mi ochota na tłumaczenie czegoś spoza projektu juniorom...

6

Ciekawe. Ja tu widzę dwie kwestie, pierwsza jest taka że jak ktoś do mnie przychodzi i pyta np. jak zrobić repozytorium albo jak zrobić w Springu to i to to najczęściej odsyłam albo do kodu (popatrz sobie w xyz.scala) albo daję linka do dokumentacji ewentualnie do wpisu na bloga. Jakby ktoś przyszedł do mnie z pytaniem jak Dockera postawić/skonfigurować to bym mu co najwyżej mógł dać linka do firmowego Wiki gdzie jest wszystko opisane, a jak nie ma to bym zasugerował przejrzenie oficjalnej dokumentacji (RTFM - Read the Friendly Manual) i dodanie brakujących rzeczy. Robienie za żywą dokumentację? - nie tak rozumiem dzielenie się wiedzą...

Z drugiej strony jeżeli: ktoś ma problem i potrzebuje drugiej osoby do debugowania, ktoś znalazł jakiś kawałek kodu z przed 10 latu i się zastanawia czy może uprościć, potrzeba zrobić review design'u lub udzielić wsparcia przy projektowaniu (czytaj tablica :D), pali się na produkcji i trzeba na gwałt naprawiać, trzeba się wysilić i napisać email lub inny soft-skillowy problem to zawsze jestem dostępny.

A od przekazywania sztuczek typu "lepszy kesz z Guavy" jest code review, tam można szpanować wiedzą z API i perfekcyjną znajomością języka (bez bycia mądralą oczywiście).

Wszystkie inne rzeczy typu setup środowiska, "mapa" jobów w CI, opis architektury systemu (C4 ktokolwiek?) powinny być w ogólnodostępnym i wyszukiwalnym WIKI firmowym.

PS. Warto też miec w firmie na komunikatorze kanał w stylu StackOverflow gdzie jak masz problem z kodem/libem wrzucasz pytanie i kto ma czas i ochotę odpowiada. Z własnego doświadczenia powiem że w praktyce sprawdza się świetnie, zwłaszcza jak się ma ogarnięty komunikator (Slack a nie M$ Teams).

4

Ja chyba jakiś dziwny jestem, ale się cieszę, kiedy ktoś mnie o coś pyta i mogę koledze pomóc, coś mu wytłumaczyć ;_;

2
ToTomki napisał(a):

Ja chyba jakiś dziwny jestem, ale się cieszę, kiedy ktoś mnie o coś pyta i mogę koledze pomóc, coś mu wytłumaczyć ;_;

Pomóc też lubię, ale po pierwsze są przypadki gdzie ludzie marnują czas - na forum można jeszcze wybaczyć nieumiejętność wyszukiwania informacji, bo pytający niekoniecznie jest koderem (nie dostaje za to cebularów).
Po drugie - często w firmach marnuje się zasoby odpowiadając cały czas na te same pytania, a wystarczyłby lepszy workflow. I potem bardzo często jest tak, że te firmy, w których dzielenie się wiedzą jest bardzo źle zorganizowane chełpią się jakie to są cool, bo zawsze można do kogoś uderzyć.

1
part napisał(a):

Po drugie - często w firmach marnuje się zasoby odpowiadając cały czas na te same pytania, a wystarczyłby lepszy workflow. I potem bardzo często jest tak, że te firmy, w których dzielenie się wiedzą jest bardzo źle zorganizowane chełpią się jakie to są cool, bo zawsze można do kogoś uderzyć.

Coś w tym jest. Często pytania wynikają z braku sensownej dokumentacji, a nikt nie pisze sensownej dokumentacji, bo "nigdy nie było czasu" albo "nigdy nie czuliśmy takiej potrzeby, bo mieliśmy mały zespół i rzadko była potrzeba wdrażania kogoś".

Więc potem, ponieważ nie ma dokumentacji ani żadnej firmowej spisanej gdzieś "bazy wiedzy", to okazuje się, że trzeba poświęcić bardzo dużo czasu na wdrożenie nowej osoby - bo jeśli wiedza nie jest nigdzie spisana, to musi zachodzić przekaz ustny.

Czyli - brak troski o dokumentację czy jakąś spisaną firmową "bazę wiedzy" to w rezultacie dług techniczny, który kiedyś trzeba będzie spłacić, właśnie tym, że wdrożenie juniora będzie trwało dłużej albo że senior będzie odrywany ciągle od pracy.

5

To żeby ludzie chętnie dzielili się wiedzą jest w interesie firmy i to firma, menadżerowie powinni do tego zachęcać.
Tu dawno już nie spotkałem się z patologią (ale kiedyś bywało), ale może dlatego, że już na rozmowach o pracy tłumaczę, że jak siedzę przy swoim biurku i robię "swoje" zadania to jest to raczej strata pieniędzy. Jakiś mid zrobiłby taniej i co najmniej tak samo szybko ( a pewnie szybciej).

Z drugiej strony nawet te firmy co ładnie promują podział wiedzy nie radzą sobie z wymianą wiedzy między zespołami. Jaki manadzer wydeleguje kogoś zespołu do pomocy innemu zespołowi, jesli przez to jemu velocity spadnie, a innym wzrośnie? A potem 4 zespoły po kolei w firmie walczą z wdrażaniem tego samego koła i robią te same błędy.

1
jarekr000000 napisał(a):

już na rozmowach o pracy tłumaczę, że jak siedzę przy swoim biurku i robię "swoje" zadania to jest to raczej strata pieniędzy. Jakiś mid zrobiłby taniej i co najmniej tak samo szybko ( a pewnie szybciej).

To ładnie dołki pod sobą kopiesz :D

Z drugiej strony nawet te firmy co ładnie promują podział wiedzy nie radzą sobie z wymianą wiedzy między zespołami. Jaki manadzer wydeleguje kogoś zespołu do pomocy innemu zespołowi, jesli przez to jemu velocity spadnie, a innym wzrośnie? A potem 4 zespoły po kolei w firmie walczą z wdrażaniem tego samego koła i robią te same błędy.

True, znasz jakieś rozwiązanie na to?

2
Pinek napisał(a):

True, znasz jakieś rozwiązanie na to?

Już były proponowane rozwiązania na łatanie dupa-managmentu. Ale kiedy zaczęto implementować takiego scruma okazało się, że to jak z komunizmem - w sumie za caratu nie było tak źle.

5
Pinek napisał(a):

True, znasz jakieś rozwiązanie na to?

Wywalić SCRUMa jak tylko pojawi się na horyzoncie. Jak już jest - to zgłaszać na retro, że CI się nie podoba i trzeba SCRUMa wywalić - w sumie od tego jest retro.

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