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

Dzielenie się wiedzą

Odpowiedz Nowy wątek
2020-07-05 04:52

Rejestracja: 10 lat temu

Ostatnio: 2 godziny temu

3

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

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.

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

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

edytowany 1x, ostatnio: BDA DVB, 2020-07-05 04:55
Zabrzmiało jak "typowe myślenie polaczka" - "skoro ja miałem źle to niech inni też mają". Serio? Nikt Ci w życiu nigdy nie pomógł? To nie tak, że ty masz powiedzieć juniorowi po kolei od a do z co ma zrobić(prawie, że napisać za niego) ty masz mu dać wskazówki, dobre rady, poprawić ewentualne błędy, wytłumaczyć czemu tak a nie inaczej. - RequiredNickname 2020-07-06 08:47
@RequiredNickname: Jak dla mnie nie tyle polaczka co osoby niepewnej swoich umiejętności. @BDA DVB do niektórych rzeczy dochodziłem czasami naprawdę długo serio? Korzystasz może z frameworków, albo bibliotek? Jak tak, to przestań i sam zgłęb temat, a potem napisz to samemu XD - Dregorio 2020-07-06 12:06

Pozostało 580 znaków

2020-07-11 14:09

Rejestracja: 4 lata temu

Ostatnio: 1 minuta temu

1

A gdyby tak zacząć zarabiać na dzieleniu się wiedzą? Ja bym to nazwał Programming Training Camp, gdzie niedoświadczeni devowie mogliby za $$ dowiedzieć się czegoś od pryncypali, ciekawe czy by to przeszło jako business

edytowany 2x, ostatnio: WeiXiao, 2020-07-11 14:09
masz na myśli takie Udemy, które wcale nie będzie jak Udemy, ale skończy jak Udemy? ew. jakaś firma konsultingowa a'la to co robi Bottega? - superdurszlak 2020-07-11 14:13
Tak, śmieszkowałem o Bootcampach ;) ale twoje przykłady też są spoko - WeiXiao 2020-07-11 14:13

Pozostało 580 znaków

2020-07-11 18:23

Rejestracja: 3 lata temu

Ostatnio: 1 tydzień temu

9

Profesjonaliści są graczami drużynowymi. Biorą odpowiedzialność za wynik całego zespołu, a nie tylko za swój. Pomagają sobie wzajemnie, uczą się od siebie, a nawet zastępują się, kiedy zachodzi taka potrzeba. Jeśli jeden członek zespołu nie jest w stanie wykonać swojego zadania, drugi wchodzi na jego miejsce, wiedząc, że pewnego dnia on też będzie potrzebował pomocy.

edytowany 1x, ostatnio: Michał Kuliński, 2020-07-11 18:32

Pozostało 580 znaków

var
2020-07-11 22:44
var

Rejestracja: 2 lata temu

Ostatnio: 9 godzin temu

Lokalizacja: Wrocław

0

Problem pojawia się w sytuacji kiedy dzielenie się wiedzą nie przynosi najmniejszych rezultatów i w rezultacie - jakość kodu nie wzrasta, nikt nic nie wie, ten kto wiedzę przekazywał sfrustrowany rzuca robotę i idzie gdzie indziej.
Dzielenie się wiedzą jest jak najbardziej pożądane w kontekście zespołu i firmy, wymaga to jednak chęci z dwóch stron. Jeśli ktoś nie będzie chciał stosować jej w praktyce to jakiekolwiek sugestie i naciski z drugiej strony nie przyniosą rezultatu.

Przykład z własnego doświadczenia.
W jednej z firm w których pracowałem miałem w zespole znajomego - gość wydawał się całkiem w porządku, w czasie rozmowy wykazywał się całkiem sporą wiedzą. Natomiast kod który pisał był nie do utrzymania - wielowarstwowe spaghetti (a nawet rozproszone pomiędzy różne części systemu). Ile razy w czasie code review padały pytania dlaczego zrobił to w taki a nie inny sposób to jedyną odpowiedzią było to, że on wie że mógł zrobić inaczej no ale nie zrobił i że poprawi.

i co się potem działo? trzymaliście mu PRa dopóki faktycznie nie poprawił, kończyło się na obietnicach i szło w zapomnienie? - superdurszlak 2020-07-11 22:49
Poprawiał, albo ostatecznie ktoś po nim robił poprawki. Po dłuższym czasie tej części zespołu, której zależało na jakości zaczęło to bardzo przeszkadzać i padła sugestia żeby przełożony zaproponował tejże osobie dalszy rozwój poza strukturami firmy. Niestety przełożony mimo pozornego zrozumienia i przyznaniu nam racji niczego nie zrobił. Robiliśmy wielokrotnie spotkania zespołowe poświęcone wyłącznie tej kwestii, ale niestety na wyższym szczeblu zabrakło jaj. To była jedna z przyczyn totalnego upadku morale wewnątrz zespołu - var 2020-07-11 22:55
Też miewałem akcje, że PR pewnych osobistości były parokrotnie odrzucane na review, a potem już z górki, bo branch nie był synchronizowany z developem od miesiąca. Ale dobrze wiedzieć, że nie tylko u mnie się zdarzało, bo z opinii tutaj wynika, że potęga przyjaźni potrafi podtrzymać każdy projekt. - part 2020-07-11 23:43

Pozostało 580 znaków

Odpowiedz

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