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ć.

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