Dzielenie się wiedzą

GutekSan napisał(a):

Praca na typowej produkcji jest nieco inna niż praca programisty, czy inżyniera oprogramowania. Zrobisz programiście szkolenie z obsługi komputera?
Nie istnieją szkolenia, które przekażą większość niezbędnej wiedzy. Choćby dlatego, że jedynymi osobami które tą wiedzę posiadają są właśnie członkowie zespołów.

Uczysz świerzaka tego czego nie mógł się nauczyć w domu. Jeżeli mógł, to można go po tym odsiać.

standaryzację czego? Zadań czy wiedzy?
Zadań nie wystandardyzujesz, zadania narzuca cel.
A wiedzę standardyzujesz właśnie poprzez jej wymianę w obrębie zespołów.

Niekoniecznie. Możecie mieć sobie w firmie swój własny standard. Chociło mi o standaryzację całego zawodu - te same wzore, narzędzia, terminologia. Dzięki temu nie okazuje się potem, że większość wiedzy jest mądrością plemenia januszkrzaka sp. z. o. o.

part napisał(a):

Uczysz świerzaka tego czego nie mógł się nauczyć w domu. Jeżeli mógł, to można go po tym odsiać.

Nigdy nie uczę go tego, czego mógł się sam nauczyć w domu. Ani mnie nie uczono tego czego mógłbym się sam nauczyć w domu.

Niekoniecznie. Możecie mieć sobie w firmie swój własny standard. Chociło mi o standaryzację całego zawodu - te same wzore, narzędzia, terminologia.

To jest zaledwie niewielka część wiedzy potrzebnej do pracy.

loza_wykletych napisał(a):

Czy osoba programująca w kolorach będzie piśmienna? Nie. Czy będzie w stanie programować? Tak.

Czy osoba programująca w kolorach będzie piśmienna? - nie wiem, to zależy jakie wartości będą przypisane poszczególnym kolorom.
Pierwsze komputery były programowane samymi jedynkami i zerami. Ale można to było łatwo zamienić te symbole na kolory zielony i czerwony. Czy były te komputery w stanie programować osoby niepiśmienne? Wątpię

GutekSan napisał(a):

To jest zaledwie niewielka część wiedzy potrzebnej do pracy.

A niby jaka inna wiedza jest potrzeba do pracy? Domenowej i tak nie chłoniesz od innych programistów, a od klientów i biznesu.
No masz jeszcze kwestię doświadczenia, ale to wychodzi przy review.

part napisał(a):

A niby jaka inna wiedza jest potrzeba do pracy? Domenowej i tak nie chłoniesz od innych programistów, a od klientów i biznesu.
No masz jeszcze kwestię doświadczenia, ale to wychodzi przy review.

Nieprawda. Domenową jak najbardziej chłonę od programistów. Z klientami i biznesem nie mam w ogóle do czynienia.
Poza wiedzą domenową jest też kwestia przyjętych praktyk i znajomości środowiska. Tego nie nauczysz się z książek, bo to są rzeczy wypracowane na miejscu.

KamilAdam napisał(a):

Czy osoba programująca w kolorach będzie piśmienna? - nie wiem, to zależy jakie wartości będą przypisane poszczególnym kolorom.

Może ja jakiś dziwny jestem ale zawsze wydawało mi się że wartości przypisuje dopiero użytkownik danego programu. A cała reszta jest abstrakcyjnym opisem operacji.

Pierwsze komputery były programowane samymi jedynkami i zerami. Ale można to było łatwo zamienić te symbole na kolory zielony i czerwony. Czy były te komputery w stanie programować osoby niepiśmienne? Wątpię

Zera i jedynki to nie wartości tylko reprezentacje stanów. A tak się jakoś dziwnie składa że żeby jakakolwiek wiedza mogła zaistnieć to musi istnieć co najmniej jedno rozróżnienie. Bóg tak chciał.

GutekSan napisał(a):

Nieprawda. Domenową jak najbardziej chłonę od programistów. Z klientami i biznesem nie mam w ogóle do czynienia.
Poza wiedzą domenową jest też kwestia przyjętych praktyk i znajomości środowiska. Tego nie nauczysz się z książek, bo to są rzeczy wypracowane na miejscu.

No ale nie rozumiem, w czym jest problem z praktykami. Dajesz checklisty + lintery, reszta wyjdzie na review. Oznaczasz tickety, które będą dobry startem dla juniora, żeby mógł się wdrożyć.
Dużo rzeczy da się zautomatyzować, jeżeli pomyślisz nad workflowem. W naprawdę dobrych konfiguracjach junior może już rozwiązywać issuesy pierwszego dnia.
W większości firm, w których pracowałem nie było takich udogodnień i potem płacili czasem seniorów za nieprzygotowanie.

part napisał(a):

No ale nie rozumiem, w czym jest problem z praktykami. Dajesz checklisty + lintery, reszta wyjdzie na review. Oznaczasz tickety, które będą dobry startem dla juniora, żeby mógł się wdrożyć.

Najwyraźniej nie znasz specyfiki pracy spoza swojej domeny. Nawet nie sądziłem, że gdzieś praca wygląda tak prosto jak to opisujesz.
Gdziekolwiek nie pracowałem, praca wyglądała tak, że ticket nie określał ci co masz zrobić krok po kroku. Bo tego twórcy ticketów sami nie wiedzieli. Widzieli tylko problem i go opisywali. Nie wiadomo było czy problem dotyczy kodu czy konfiguracji, czy środowiska, czy danych. A każda z tych alternatyw otwiera pudełko setek innych pytań, które pojawiają się na każdym kroku. I to nie dotyczy wyłącznie juniorów - nawet eksperci pracujący po 10 lat mogą mieć pełno pytań, bo po prostu obecne ekosystemy produkcyjne są tak wielkie i tak często się zmieniają.

Dużo rzeczy da się zautomatyzować, jeżeli pomyślisz nad workflowem. W naprawdę dobrych konfiguracjach junior może już rozwiązywać issuesy pierwszego dnia.

Znowu zależy od dziedziny. Jak jak trafiałem do nowej pracy z jakim-takim doświadczeniem i miałem szczęście to może jakieś zadanie mogłem wziąć na widelec. Junior pierwszego dnia co może co najwyżej rozwiązać takie issue, że seniorowi brakuje kawy w kubku.

GutekSan napisał(a):

Najwyraźniej nie znasz specyfiki pracy spoza swojej domeny. Nawet nie sądziłem, że gdzieś praca wygląda tak prosto jak to opisujesz.
Gdziekolwiek nie pracowałem, praca wyglądała tak, że ticket nie określał ci co masz zrobić krok po kroku. Bo tego twórcy ticketów sami nie wiedzieli. Widzieli tylko problem i go opisywali. Nie wiadomo było czy problem dotyczy kodu czy konfiguracji, czy środowiska, czy danych. A każda z tych alternatyw otwiera pudełko setek innych pytań, które pojawiają się na każdym kroku. I to nie dotyczy wyłącznie juniorów - nawet eksperci pracujący po 10 lat mogą mieć pełno pytań, bo po prostu obecne ekosystemy produkcyjne są tak wielkie i tak często się zmieniają.

Najwyraźniej nie znasz specyfiki pracy z ticketami. Kiedy pracujesz, to czasem widzisz, że można poprawić dokumentację tu, trochę zrefaktoryzować tam, dopisać testy jeszcze gdzie indziej.
Jeżeli nie masz czasu, to składasz ticketa i potem taki junior może wziąć sobie na klatę taki task z niskim priorytetem, ale pozwalający na wdrożenie się (i całkiem pożyteczny przy okazji).

To trzeba umieć jednak wypośrodkować, bo może się skończyć tak, że będziesz robić wszystko za innych. Nie można być za bardzo pomocnym dla każdego bez wyjątku, bo zostanie to wykorzystane i wcale nie będziesz szanowany, tylko zadziała to odwrotnie. Dotyczy to zresztą nie tylko dzielenia się wiedzą, ale i każdej formy bezinteresownej pomocy.

To trochę tak, jak kujon w szkole daje wszystkim odpisywać pracę domową. Nie zyskuje szacunku, tylko kopa w dupę, gdy raz nie da odpisać.

Jakieś 1,5 roku temu odszedłem z pracy, gdzie ludzie mieli bardzo ciężką mentalność. Była to branża Automotive, automatycy i tym podobni. Unikali dzielenia się wiedzą jak tylko mogli. Nie odpowiadali na pytania, robili głupie miny, albo się oburzali, że jak ktoś może iść tak chamsko na skróty, oni musieli dokumentacje po niemiecku czytać i po 16 godzin w pracy siedzieć żeby się nauczyć. Szybko stamtąd odszedłem. Trafiłem do Fintechu, gdzie ludzie mają podejście takie, że dzielenie się wiedzą naturalnie oznacza, że ktoś dużo ogarnia i jest w tym dobry, czyli niosąc pomoc mniej doświadczonym, automatycznie stoi wyżej w hierarchii.

Kiedy przeczytałem posty autora tematu to aż mnie zatkało, że można w ogóle o czymś takim myśleć

Bardzo prosto :) Nawet nie myśleć - robić, everyday :) Żeby dolać oliwy do ognia: załóżmy, że pokazuję coś komuś, kogo uważam za "niegodnego oświecenia" - robię z premedytacją zgodnie z dokumentacjami, żadnych skrótów, żadnych uproszczeń (ale gdy się tylko odwróci... nagle puff zrobione, a teraz powtórz młody :) ). Dlaczego? Bo zwyczajnie uważam, że musi do tego dojść sam, inaczej w końcu trzeba będzie zacząć tłumaczyć gościowi jak oddychać. Szerszą wiedzę przekażę nadal tym 2-3 ogarniętym gościom, jeśli się zapytają.

Dziękuję wszystkim za odpowiedzi, szczególnie te jakoś argumentowane, przynajmniej jest się do czego odnieść...

Nadal uważam, że po prostu nie każdy zasługuje, żeby mu pompować wiedzę do głowy na siłę, kosztem swojego czasu. I kompletnie mnie nie przekonaliście, że jest inaczej, wręcz utwierdzacie mnie w przekonaniu, że się nie mylę (szczególnie inwektywami - podejrzewam że to właśnie od osób, które na co dzień trzeba rozpaczliwie ciągnąć za uszy, żeby szły na przód :) Np. @katelx tak właśnie widzę w tym momencie :) ). 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ł :)

Kolejna uwaga - padło, że wszak dzielimy się na Githubach, na konferencjach - owszem, ba - nawet ja (wbrew pozorom), tylko różnica jest taka, że na publiczne repozytoria wrzucamy to, co chcemy. Nie wydaje mi się, że ktokolwiek wrzucałby tu swoje prywatne kody publicznie, bo jakiś random go poprosi, żeby mu się szybciej pracowało :)

Praca dla mnie to praca, a nie pełnienie roli lokalnego, żyjącego i oddychającego serwera Stack Overflow. Kto sobie nie radzi - odpada. Nie jestem w firmie PM (niektórzy powiedzą - całe szczęście :] zgadzam się - nie miałbym do tego serca, nawet kiedyś odmówiłem), nie mam też zleconego taska świadczenia pomocy, które mógłbym rozliczać w godzinach pracy. To oznacza, że mój czas jest mocno reglamentowany i wydzielam go mądrze, szczególnie na osoby rokujące, z których uważam, że po prostu coś będzie. Nie przekonaliście mnie, że powinno być inaczej, nie padł żaden mądry argument czemu miałbym np. wyskoczyć ze swoich rozwiązań poza tym, że pomogę zespołowi, firmie, bo jak nie, to psucie marki (wtf? :) to mnie rozśmieszyło, prezes by się szczerze wzruszył, ocierając łzy banknotami studolarowymi :) ) - komuś chyba za mocno wszedł socjalizm.

Nawet z tym argumentem, że to pomoc zespołowi - dyskutowałbym. Jeśli podstawisz zespołowi wszystko pod nos, to nigdy młodzi w nim się nie rozwiną, zawsze będą ograniczeni do odbierania gotowców. Uważam, że kompletnie psuje to morale i przykładowo zderzyłem się z tym, kiedyś udostępniając na lokalnym gicie firmowym jeden istotny tool. Przez parę lat, przy zmieniającej się ekipie, nie znalazł się nikt, kto by chciał współpracować nad jego rozwojem (choć były zobowiązania, w serii: ej powiedz mi jak to działa, kiedyś tam coś rozwinę, jak się wgryzę, nigdy nie zrealizowane), za to pojawił się manual jak najszybciej i najprościej go zdeployować, żeby poświęcić jak najmniej czasu bez wnikania w to, co ten tool robi, jak go konfigurować, co w ogóle może :) Kolejne osoby dołączające już nawet nie rozumieją po co to jest, tylko wyklikują jako część rytuału i finalnie ilość wiedzy w zespole zamiast się podnieść - zredukowała się. Może coś jest szybciej, ale nie o to chodziło.

Ludzie mają naturalny talent do chodzenia drogami na skróty. Powodem, dla którego ktoś przychodzi pomiauczeć najczęściej nie jest to, że chce się nauczyć, tylko bo zaraz PM go dojedzie i włącza mu się tryb "jak trwoga to do Boga". Kompletnie nic z tego nie wynika dla rozwoju zespołu.

Jedyną wadą mojego rozwiązania jest to, że ocena, kto jest ogarnięty i rokuje, jest oceną moją, czysto subiektywną, może ktoś zostanie tu skrzywdzony, komu brakuje odwagi, żeby może wyraźniej się wybić, nie dam rady śledzić wszystkich. I chyba gdy tak dogłębnie nad tym myślę, to właśnie konkretnie to jest powodem moich dylematów. Nie żadne tam romantyczno-socjalistycze dyrdymały :)

Masakra, ręce opadają...

BDA DVB napisał(a):

pojawił się manual jak najszybciej i najprościej go zdeployować, żeby poświęcić jak najmniej czasu bez wnikania w to, co ten tool robi, jak go konfigurować, co w ogóle może :) Kolejne osoby dołączające już nawet nie rozumieją po co to jest, tylko wyklikują jako część rytuału

O to właśnie chodzi, właśnie w ten sposób cywilizacja idzie do przodu - jestem programistą javy, więc myślisz że powinny mnie obchodzić rzeczy na poziomie assemblera? Albo ktoś kiedyś zrobił Mavena do budowania projektu - okej, warto znać fazy, gole itp, ale główną rzeczą jest nadal to że się kopiuje 5 linijek xmlowych z mvn repo i mamy dostęp do nowej biblioteki w kodzie, bez jakiegoś rozpoznawania jego konfiguracji.

Tak samo Spring Boot - po to właśnie powstał framework do frameworka, żeby nie trzeba było co chwila patrzeć na te tutoriale ze Spring Security czy jak zrobić te servlety w web.xml.

Tak patrzę w Twój profil i cieszę się, że pracujesz w C# / C++ - przynajmniej nigdy się nie spotkamy w pracy xd

Tak, powinny, przynajmniej w jakiejś podstawie, później mamy takie kwiatki
https://www.npmjs.com/package/is-odd
:D
Ty się nie chcesz wgryzać w tutoriale, a ktoś nie chciał w modulo :) Teraz jest szybciej, a czy mądrzej... Śmiem wątpić.

BDA DVB napisał(a):

Tak, powinny, przynajmniej w jakiejś podstawie, później mamy takie kwiatki
https://www.npmjs.com/package/is-odd

A ty masz na czymś
**Weekly Downloads
481,149 **

I dwie osoby to ciągną
I 33 https://www.npmjs.com/package/is-odd?activeTab=dependents
I 7 Versions

I gdyby nie koronawirus to pewnie projekt wykupiłby jakiś Anioł Startupów za 100 milionów dolców.

BDA DVB napisał(a):

Teraz jest szybciej, a czy mądrzej... Śmiem wątpić.

To jeszcze tylko jeden przykład - cywilizacja poszła do przodu, ludzie się rozwijają, prawda? Prawda. A jakbyś cofnął się w czasie o 300 lat to byś wytłumaczył skąd wziąć prąd? W końcu korzystasz z niego cały dzień, to chyba powinieneś wiedzieć

Pinek napisał(a):

BDA DVB napisał(a):

Teraz jest szybciej, a czy mądrzej... Śmiem wątpić.

jakbyś cofnął się w czasie o 300 lat to byś wytłumaczył jak się wydobywa prąd?

Głównie w kopalniach odkrywkowych o mocy przynajmniej 700A ;)

O ch**, "nie każdy zasługuje" w kontekście pomagania komuś w pisaniu kodu w czasie pracy ;_;.

Kolego, czym Ty się dokładnie w pracy zajmujesz? Co za godne projekty wykonujesz? Co prestiżowego robisz?

BDA DVB napisał(a):

[...] przykładowo zderzyłem się z tym, kiedyś udostępniając na lokalnym gicie firmowym jeden istotny tool. Przez parę lat, przy zmieniającej się ekipie, nie znalazł się nikt, kto by chciał współpracować nad jego rozwojem (choć były zobowiązania, w serii: ej powiedz mi jak to działa, kiedyś tam coś rozwinę, jak się wgryzę, nigdy nie zrealizowane), za to pojawił się manual jak najszybciej i najprościej go zdeployować, żeby poświęcić jak najmniej czasu bez wnikania w to, co ten tool robi, jak go konfigurować, co w ogóle może :)

To IMHO normalne, że ludzie traktują narzędzia jako czarne skrzynki o ile nie mają oczywistej potrzeby ich modyfikacji - przykładowo ja też nie analizuję kodu Chrome z którego korzystam do wysłania tego posta na forum. Swoją drogą, to, że można coś bezboleśnie odpalić i działa świadczy właśnie o tym, że narzędzie jest dobre.

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.
Chęć i umiejętność dzielenia się wiedzą jest właśnie domeną Seniorów. Osoba ta ma być przykładem dla innych poprzez nauczanie i głoszenie dobrych praktyk, analizowania i wytyczania architektury/kierunku rozwoju aplikacji, do gaszenia poważnych pożarów.
Jeżeli nie odnajdujesz się w tej ścieżce to po prostu nie wchodź w nią. Bądź sobie dobrym midem, który klepie sobie swój kod i tyle.
Ale nigdy nie możesz siebie nazwać seniorem, nawet jeśli na papierku będzie widnieć Senior BDA DVB - to niestety, ale nie masz tych umiejętności miękkich, które determinują seniora z prawdziwego zdarzenia.

Ja dzielę się wszystkim co wiem i co uważam, że usprawnia mi pracę. Tak jak poprzednicy napisali - dobro wraca. Ale nawet nie o to dobro chodzi, po prostu taki jestem i tyle, chcę, aby inni korzystali z mojej wiedzy, chętnie też słucham i korzystam z wiedzy innych.
Każdy ma swoje zdanie i czasami mimo różnego rodzaju "kłótni" o architekturę itp. wynikają ciekawe wnioski i na bazie których wszyscy się uczymy.

To, że jesteś "mistrzem" w tej konkretnej firmie - nie da Ci mistrzostwa w innej. W innej aplikacji też możesz się nie odnaleźć tak super jak aktualnie.
Polecam trochę pokory we własnym kierunku.

musrus napisał(a):

Ale nigdy nie możesz siebie nazwać seniorem, nawet jeśli na papierku będzie widnieć Senior BDA DVB - to niestety, ale nie masz tych umiejętności miękkich, które determinują seniora z prawdziwego zdażenia.

Spoko, mi styknie wypłata seniorska. Nie potrzebuję sobie podbijać ego.
Swoją drogą to śmieszne, bo to wygląda jakby senior w Twoim odczuciu był jakimś poziomem oświecenia. Nie rozumiem jakie są benefity bycia "prawdziwym seniorem"? Koniec cyklu reinkarnacji?

ile godzin tygodniowo trzeba uczyć seniorów aby być prawdziwym fellowem? albo chociaż pryncypalem :D :D

zadania domowe też zadawać czy powyżej staff engineera nie ma sensu?

zabawne, w Polsce senior 5 latek i z gościa 25 lat robią jakiegoś przywódce stada :D ledwo taki dwa-trzy sensowne projekty zobaczył i już ma nauczać jezus jeden

Aż ciężko się do tych wywodów odnieść na poważnie :D

BDA DVB napisał(a):

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

W miarę możliwości każdy w zespole dzieli się z każdym. Nieważne czy senior z juniorem, mid z pryncypałem czy intern z seniorem. Dodatkowo dzielimy się wiedzą między zespołami - czy to przez jakieś tech talki, czy przez kanały tematyczne na Slacku.

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ą :) [...] 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ł).

Do bólu przypomina mi to relację z polskiej budowy - młody za****la z łopatą, a tymczasem majster osusza setkę :D

Jak Twoją główną motywacją uczenia młodego jest, żeby samemu móc zbijać bąki, to nic dziwnego że się boisz "detronizacji"... zacząłbym od przemyślenia priorytetów. U nas jak ktoś przechodzi przez coś upierdliwego, to robi jakieś notatki i wrzuca na Confluence. Następna osoba na ogół nie musi przechodzić na piechotę, ewentualnie dopisuje swoje obserwacje jak coś się zmieniło i tak się to kręci.

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.

:D :D :D

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

Nie wiem co to za tajemna branża, ale w mojej na tricki i autorskie patenty mówi się hacki i dług techniczny, z którym potem się trzeba użerać. Pół biedy, jak ze swoim, gorzej jak nahakował to specjalista od autorskich patentów 12 lat temu i już tak zostawił. O uczeniu "młodego", że obijanie paździerzem i szpachlowanie jakimiś trickami jest dobre już nawet nie wspomnę :D

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?

Od początku pisania tego posta nadal nie wiem, cóż to za tajemna branża w której się potajemnie skrywa tajemne patenty przed kolegami z pracy :D aczkolwiek nasuwają się na myśl jakieś agencje interaktywne i tym podobne... Nie, wiedza jest "open source", jak komuś się wydaje, że jest niezastąpiony bo ma tricki i patenty to mu się wydaje ;)

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ń".

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

@ToTomki

Nie odnosisz się do żadnych argumentów. W pracy masz pracować, a nie czekać na pomoc z każdej strony, bo świat pull requestów i commitów cię przerasta. 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". 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). 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".
Dodatkowo - co robię - nie twój interes :) Masz może dla odmiany jakieś mądre argumenty, inne niż prywatne zaczepki? :) Wątpię.

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

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

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 i nie zdaje sobie sprawy, że umiejętności miękkie wykorzystuje się tylko, gdy jest sens. W efekcie często mid traci czas właśnie na usprawnianie rzeczy bez sensu (czasami są to nawet usprawnienia odwrotnie skuteczne), na tłumaczenie ludziom, którzy ich zwyczajnie bez mydła wiadomo co. 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. W ogóle senior ma być ekspertem, ale nie dobrym duszkiem ratującym zadki. Jako senior mam robotę, którą mam zrobić. Nie mam zadania organizacji warsztatów z wyrównywania szans juniorów "Równy Start 15k" :D

Co do tego... "STATUSU" :) Widzę, że dla niektórych to coś jak tytuł szlachecki :) Ale odlot! Brakuje tylko jakiegoś pasowania, jak na rycerza :) Wychodzi PM i kablem ethernetowym uderza w prawy bark, powiadając na porannym CR - pasuję cię na SENIORA! Etos senior developera! Trzeba poszukać co o tym mówią pradawne pisma!

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
• 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
• wie kogo można i warto wtajemniczyć szerzej, a kto pozostanie kulą u nogi, choćby mu się robiło codzienne prywatne korepetycje
• przyjmie na klatę ciężkie taski, wymagające wyobraźni i kreatywności

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.

@superdurszlak

Myślę, że popełniłem błąd ubarwiając post w żartobliwą formę. Ironia w Polsce jest za trudna, co widać powyżej :) Jeśli ktoś poważnie potraktował ten wtręt o recepcjonistce, sam jest równie poważny :)

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ć). 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. Widzę, że gdy takiego gościa zarażę myślą, on pójdzie do siebie i będzie to rozkminiał, zobaczy nowe perspektywy, nie wykluczone, że on mnie czymś zaskoczy w zamian. Reszta (w mojej prywatnej ocenie, która może być błędna, ale mam do niej prawo) skupia się na przetrwaniu jakimś cudem.

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ł :)

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

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, szczytem waszych osiągnięć są najwyżej inwektywy, co zmusza mnie do odpowiedzi na zbliżonym, niskim poziomie :)

Tym bardziej, że nie mam za to płacone.

A może powinieneś, nie próbowałeś rozmawiać z przełożonym aby rozliczać się z tych godzin?

W tych dniach przeszedł mi przez ręce artykuł - nie pamiętam źródła - że najlepiej w karierze sobie radzą psychopaci i socjopaci

Pisanie tooli do optymalizacji pracy po godzinach to według mnie strzał w stopę. Według mnie powinieneś na samym początku wyjaśnić tego typu kwestie w firmie i po prostu brać za to pieniądze. W branży siedzę ~10 lat, i raz miałem przyjemność pracować przez kilka miesięcy w firmie, gdzie praktycznie nikt nie chciał dzielić się wiedzą i każdy tylko patrzył w swój monitor. Atmosfera fatalna, nie szło w ogóle pogadać - nawet o czymś niezwiązanym z pracą, a samo wytwarzanie oprogramowanie przez takie podejście mocno zwalniało. Uciekłem stamtąd najszybciej jak się dało i mam nadzieję, że więcej do takiej firmy nie trafię.
Autorze tematu - popatrz na to z trochę innej strony. Większość osób nie zgadza się z Twoim podejściem. Obstawiam, że siedzą w branży kilka ładnych lat i przez ten czas mieli styczność z osobą Twojego pokroju. Programowanie na dzień dzisiejszy to praca typowo zespołowa, a z tego co piszesz wnioskuję że akurat ten rodzaj średnio Ci wychodzi.

Dostrzegam pragmatyzm, proszę bardzo.

Dzielenie się wiedzą leży w moim interesie. Jak to mówił pewien hydraulik (czy tam elektryk, muszę sobie odświeżyć ten film), "we are in this together". Nawet jak ktoś ma IQ kijanki to wolę, żeby był mądrzejszy niż głupszy. Z tego też powodu chętnie przekażę takiemu komuś swoją wiedzę, którą ciężką zdobywałem, żeby był trochę mniej głupszy. Z mojego doświadczenia 100% osób, z którymi pracowałem ma zdolność uczenia się. To że przez moment poczuję się lepszy, że styram młodego, który dopiero się uczy programować nie wnosi niczego. Wydajesz się w pizdu toksyczny, może to działa, tam gdzie pracujesz, ale w normalnych projektach to kompletna patologia.

Nadal uważam, że po prostu nie każdy zasługuje, żeby mu pompować wiedzę do głowy na siłę, kosztem swojego czasu. I kompletnie mnie nie przekonaliście, że jest inaczej, wręcz utwierdzacie mnie w przekonaniu, że się nie mylę (szczególnie inwektywami - podejrzewam że to właśnie od osób, które na co dzień trzeba rozpaczliwie ciągnąć za uszy, żeby szły na przód :) Np. @katelx tak właśnie widzę w tym momencie :) ).

napisalam "bez obrazy" ale widze ze jednak zabolalo. wiec jeszcze raz - pomijajac wartosci etyczne czy zwyczajne kolezenstwo ktore to najzwyczajnej sa ci obce - 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.
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.
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.

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.
a potem mija nastepne pare miesiecy i nagle wielki buldopy ze junior zarabia tyle co ja, jak to mozliwe przeciez ja tak swietnie pracuje.

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ł :)

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

Nie wydaje mi się, że ktokolwiek wrzucałby tu swoje prywatne kody publicznie, bo jakiś random go poprosi, żeby mu się szybciej pracowało :)

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

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

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

Nawet z tym argumentem, że to pomoc zespołowi - dyskutowałbym. Jeśli podstawisz zespołowi wszystko pod nos, to nigdy młodzi w nim się nie rozwiną, zawsze będą ograniczeni do odbierania gotowców.

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.

Uważam, że kompletnie psuje to morale i przykładowo zderzyłem się z tym, kiedyś udostępniając na lokalnym gicie firmowym jeden istotny tool. Przez parę lat, przy zmieniającej się ekipie, nie znalazł się nikt, kto by chciał współpracować nad jego rozwojem (choć były zobowiązania, w serii: ej powiedz mi jak to działa, kiedyś tam coś rozwinę, jak się wgryzę, nigdy nie zrealizowane), za to pojawił się manual jak najszybciej i najprościej go zdeployować, żeby poświęcić jak najmniej czasu bez wnikania w to, co ten tool robi, jak go konfigurować, co w ogóle może :) Kolejne osoby dołączające już nawet nie rozumieją po co to jest, tylko wyklikują jako część rytuału i finalnie ilość wiedzy w zespole zamiast się podnieść - zredukowała się. Może coś jest szybciej, ale nie o to chodziło.

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?

Ludzie mają naturalny talent do chodzenia drogami na skróty. Powodem, dla którego ktoś przychodzi pomiauczeć najczęściej nie jest to, że chce się nauczyć, tylko bo zaraz PM go dojedzie i włącza mu się tryb "jak trwoga to do Boga". Kompletnie nic z tego nie wynika dla rozwoju zespołu.

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