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

Dzielenie się wiedzą

4

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

32

Nie chciałbym z tobą pracować.
Sam się wszystkiego uczyłem, bo w pracy to jedynie nauczyli mnie jak nie pisać oprogramowania.

Wiedzą chętnie się dzielę.
Co za problem.
Programowanie to bardzo obszerna dziedzina i dzięki twoim kilku wskazówkom nikt nie stanie się wymiataczem. Żeby się takim stać i tak swoje będą musieli odsiedzieć.
Poza tym pewnie pracujecie przy tym samym projekcie, to mają dostęp do kodu źródłowego, to i tak widzą co i jak.

Oczywiście nie mówię o przypadkach, gdy ktoś jest leniwy i robi za pasożyta, to niech sam sobie radzi, bo widocznie go ta branża nie kręci i chce oblecieć na kopiowaniu kodu z neta, a resztę mu senior napisze jak nie znajdzie.

Także czasem lepiej wskazać miejsce gdzie dana osoba powinna doczytać.

Ale ty idziesz już w skrajność z czystego bólu tyłka.

Potem jako senior i tak będziesz musiał gasić pożar, bo szkoda Ci było komuś coś pokazać i spieprzył, bo nie wiedział, a na code review nikt nie zauważył.

2

Bardziej kierowałem myśli w stronę juniorów-pasożytów.

Jeśli ktoś przybiega miauczeć mi nad uchem, a okazuje się, że nie zajrzał wcześniej do dokumentacji, to szczerze - wolę gasić pożary. Co też ma swoją wagę naukowo-poznawczą. Pozwala się nowym sparzyć, co i moim udziałem bywało. Niestety pożary zdarzają się już bardzo rzadko, bo dobre pokrycie testami, ktoś musiałby okazać się wyjątkowym antytalentem... No cóż, szkoda :P

Ale... i udzielając porad i niepasożytom (powiedzmy "neutralom") - wolę jednak transakcje wiązane - chętnie coś sprzedam, ale nie za darmo :] Na team 20 osób mam 2-3 gości, którzy się wybijają i tu jest kooperacja, wiem że gdy im dam patent, to mogę chociaż na nich liczyć. Co do reszty mam zastrzeżenia.

Kod źródłowy to nie wszystko u mnie, są pewne możliwości przyśpieszenia różnych spraw, optymalizacji obsługi danych - długo by pisać. Do ułatwiania sobie życia wytworzyłem sporo rozwiązań i teoretycznych i praktycznych, toole, skrypty, generatory, fuzzery. Firmie globalnie się to by pewnie nie przydało, ale dla różnych tasków - czasami bez tego trzeba się zdrowo napocić.

Wyobraźcie sobie pytanie: wow, Anon, jak mogłeś to zrobić tak szybko? A ja mam toola, którego sobie napisałem na boku, żeby - znając pewne zależności i mając określoną wiedzę - robotę na godzinę zrobić w 10 minut. Są trzy opcje:

  1. mówisz: wiesz, Anon2, jestem geniuszem, temat ucinasz
  2. sprzedajesz patent teoretyczny, koncepcję, ale nie toola
  3. dajesz toola, opcja full socjalizm

Ja obecnie odpowiedzi 3 nie stosuję nigdy. Moja robota poza projektem, która ułatwia życie - ułatwia je mi i tylko mi, nikt nie broni nikomu wymyślić czegoś podobnego. Odpowiedź 2 dla tych 2-3 kumatych. Reszta uzyska ode mnie odpowiedź 1.

Żeby była jasność - pomagam chętnie, ale skala tej pomocy znacząco się różni w zależności kto pyta, czy użyje magicznego słowa "proszę", czy ową osobę lubię, czy mogę liczyć na transakcję wiązaną patent za patent. Niektórym pomogę poświęcając z pół godzinki na wdrożenie, innym do 5 sekund na wymienienie strony dokumentacji z pamięci :) Wydaje mi się to całkiem sprawiedliwie, ale chętnie posłucham kontrargumentów - bo jak napisałem na początku, jednak jest ten problem, że czasami junior może po prostu wyklepać jakąś czarną (podobno teraz się tak nie mówi) robotę i wtajemniczając go - zrobi więcej, zabierze może jakieś bezsensowne obciążenie. Dlatego mam z tym coraz większy dylemat.

W zeszłym tygodniu miałem po prostu sytuację, w której wiem, że mógłbym uciąć czyjeś męki, ale powstrzymało mnie to, że gość pokazał się z pasożytniczej strony i jedyną korzyścią tego, że mu pomogę byłoby tylko to, że szybciej uwolni zasoby i będzie go można wtłoczyć w coś innego, w czym pewnie też trzeba będzie pomóc. Żadna korzyść.

14

Dzielę się z juniorami, seniorami, nawet ludźmi, którzy nie chcą, żebym się z nimi wiedzą dzielił. Nie widzę w tym problemu, za to widzę masę zalet, ludzie są bardziej zainteresowani tematem, mają więcej motywacji i chętniej dzielą się swoimi "odkryciami", są bardziej pozytywni. To jest do tego o tyle ważne, że jak tylko wyjdziesz ze swojego poletka, to nagle okaże się, że w większości rzeczy dalej jesteś juniorem.

Juniorów często mentoruję tak, że najpierw podsyłam im linki do tematu, a potem odpytuję i sprawdzam, czy rozumieją, a jak coś jest niejasne, to opowiadam długo i powoli. Oczywiście z pasożytami tak się nie da, ale pasożyta zazwyczaj eliminuje się z firmy i tak, więc nie jest to wielki problem.

Przy czym ja od zawsze dzieliłem się wiedzą, występowałem na konferencjach czy blogowałem, więc też mogę mieć przez to inne spojrzenie. Domyślam się, że aspekt psychologiczny jest tu ważny, jak w pewnym momencie nie będziesz miał już czym się dzielić, to może zrobić się smutno, taka perspektywa, że "dawniej to ja byłem ktoś, a teraz to wszyscy wszystko wiedzą". Ale to i tak się stanie z upływem czasu (bo przecież nie da się bez przerwy uczyć nowych frameworków), a do tego może to też sygnalizować stagnację i brak rozwoju, ale niedzielenie się wiedzą nie jest rozwiązaniem.

10

Tam gdzie pracujesz, dzieje się patologia.

Na team 20 osób mam 2-3 gości, którzy się wybijają i tu jest kooperacja, wiem że gdy im dam patent, to mogę chociaż na nich liczyć. Co do reszty mam zastrzeżenia.

Do większości osób w zespole masz zastrzeżenia? Ciekawe czy problem jest w nich, czy w tobie. Bo albo pracujesz w jakimś strasznym zespole, albo masz zaburzoną percepcję.

W zeszłym tygodniu miałem po prostu sytuację, w której wiem, że mógłbym uciąć czyjeś męki, ale powstrzymało mnie to, że gość pokazał się z pasożytniczej strony i jedyną korzyścią tego, że mu pomogę byłoby tylko to, że szybciej uwolni zasoby i będzie go można wtłoczyć w coś innego, w czym pewnie też trzeba będzie pomóc. Żadna korzyść.

Albo masz dziwny sposób myślenia, albo pracujesz z dziwnymi ludźmi. Albo to i to.

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?

Ale jakie asy? Jak nie będziesz się dzielił wiedzą, to ludzie nie będą wiedzieć, że coś umiesz. I możesz poczuć się niedoceniony.

Dlatego niechętnie dzielę się trickami, jakimiś swoimi autorskimi patentami.

Z kolei ludzie, którzy dzielą się trickami czy patentami, zdobywają poważanie wśród innych programistów.

Niby przepływ wiedzy działa na korzyść zespołu, firmy,

A brak przepływu wiedzy działa na niekorzyść. Więc jeśli nie będziesz się dzielił, to spowolnisz cały proces. Wyjdziesz na burka, ale również inni programiści wyjdą na słabszych niż są. Szczególnie jeśli nie będziesz się dzielił wiedzą nt projektu (bo o ile wiedza nt frameworków wala się po necie, to jednak wiedza o projekcie już nie i często programiści są jedyną dokumentacją).

ale u mnie to działa w jedną stronę i jakoś nie czuję korzyści

Jak to? Nie płacą ci w tej firmie? Kasjerka wydając resztę też może "nie czuć korzyści", ale jednak ta korzyść się pojawia w postaci wynagrodzenia.

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

Na tym polega programowanie, że ktoś jest pionierem, coś odkrywa, a potem przekazuje innym wiedzę w pigułce. Przecież też tak na pewno robiłeś.

Jeszcze wyjdzie, że młody jest lepszy niż ja

Przydałaby się pewna maść, ew. zmiana firmy, bo może w tej firmie jest taka dziwna atmosfera, że każdy się boi o swój stołek, nie wiem.

4

@LukeJL
Po prostu nie masz bolesnych doświadczeń z ludźmi - ja ostatnio delikatnie zasugerowałem koledze, że nie powinien duplikować kodu, to powiedział że go obrażam, że mówię że nie potrafi nic, a napisałem dokładnie, że jak mamy powtarzające się fragmenty kodu, to trzeba wydzielić metody po tym, jak na PR skopiował 4 razy to samo z innym podmienionym stringiem (50 linijek) - dopóki nie spotkałem tego typu ludzi nie miałem pojęcia, jak wielkim ignorantem można być.

5

Ja tu widzę dwie różne rzeczy: dzielenie się wiedzą i brak szacunku do czyjegoś czasu. Ja nie widzę nic złego w dzieleniu się wiedzą. Jeśli rozwiązałem jakiś problem w zakresie wiedzy domenowej, piszę artykuł w Confluence "jak dla debila" (czyli tak, żeby zieloną osobę poprowadzić za rękę). Jeśli ktoś nie szanuje mojego czasu niech siedzi nad artykułem sam. Przynajmniej mam wtedy dupochron: mogę pokazać kierownikowi, że świeżak ma wszystkie materiały pod ręką.

4

Pracowalem w srodowisku gdzie bylo kilku ludzi z przekonaniami jak OP.
Najpierw zrobilem jakis tool ktory zmniejszyl potrzebe komunikowania sie ze "smietanka" o jakies 70%, potem stwierdzilem ze moze jak chca przez kolejne 20 lat w tym sofcie sami siedziec to im w tym pomoge i... odszedlem.
Jesli firma nie zauwaza ze juniorzy maja o wiele gorsze wyniki niz mogliby miec, ze ich motywacja spada juz w pierwszym roku, ze proste rzeczy robi sie calymi dniami zamiast w ciagu godziny, to nie warto w takim miejscu pracowac

Poza tym od strony OP takie zachowanie tez mi sie wydaje ze szkodzi bo nie wymienia sie trickami, nie poznaje nowych technologii (bo nie chce wyjsc z roli eksperta), calymi dniami tylko sie okopuje zamiast sie rozwijac.
A swiat sie nie konczy na jednym frejmłorku ktory akurat zna. Firma moze w dowolnym momencie zdecydowac sie na jego zmiane i on sam moze stac sie kiedys juniorem. Kto mu wtedy pomoze?

3
BDA DVB napisał(a):

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

Junior ma soft skill i ogarnia kodowanie i flirtowanie :))) a ty, jak widzisz, jesteś "close to the cold metal" i jak sobie urządziłeś mały świat w piwnicy tak tej piwnicy pilnujesz jak niepodległości.

15

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

z kazdym niezaleznie od stanowiska

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

bez obrazy ale takie dylematy to domena cieniasow i leniuchow. osoby z takim podejsciem powinny zostac jak najszybciej naprostowane lub zwolnione, no chyba ze liczy sie wylacznie headcount sprzedawany klientowi, ale nawet wtedy to zwyczajne psucie marki.

1

Jak to dobrze że zawsze w moich zespołach byłem programistą z najmniejszym doświadczeniem :) (co nie znaczy, że nie przekazywałem wiedzy innym)

6

Swoją drogą ciekawe autor wątku tak samo by podszedł do wychowywania dzieci: przecież do darmozjady i jeszcze potrafią wypomnieć słaby procesor w nowym lapku.

2

Jeżeli chodzi o mnie to bardzo lubię dzielić się zdobytą wiedza ALE nie w każdym przypadku. Jeżeli jest osoba która poszła w IT tylko dlatego że pieniundze, to mocno ograniczam strumień danych do minimum. Jeżeli ktoś jest pasjonatem IT, widać że chcę się rozwijać, jara go temat związany z programowaniem i chce jeszcze prowadzić dyskusje na jakiś temat, to wtedy jak najbardziej(aż miło że można komuś pomóc).

3
PerlMonk napisał(a):

Swoją drogą ciekawe autor wątku tak samo by podszedł do wychowywania dzieci: przecież do darmozjady i jeszcze potrafią wypomnieć słaby procesor w nowym lapku.

Juniorzy to takie trochę adoptowane dzieci które dostałeś z przydziału.

12

Moim zdaniem dobro krąży. Jak jesteś spoko to ludzie Cię lubią. Jak będziesz w potrzebie to Ci pomogą dlatego, że Ty im kiedyś pomogłeś. Może i junior nie pomoże Ci rozwiązać problemu w pracy, ale kiedyś padnie Ci auto to się okaże, że jego wujek ma warsztat samochodowy i naprawi Ci auto po cenie części. Pewnie kilka razy komuś pomożesz i nie dostaniesz nic w zamian i co z tego? Przecież Ciebie to nic nie kosztuje. Może zespół jest taki, że trudno się z nim współpracuje, ale zawsze musi być ktoś kto się pierwszy uśmiechnie. Kiedyś pracowałem w firmie gdzie był strasznie zrzędliwy gość, którego nikt nie lubił. Bylem dla niego miły, kilka razy mu pomogem i się okazało, że nagle był calkiem spoko i sam zaczął mi pomagać.
Dobro krąży, a życie to gra o sumie różnej od zera. Wchodzisz do windy to się uśmiechaj i mów dzień dobry. Zobaczysz, że po miesiącu ludzie widząc Cię w windzie będą się uśmiechać i pierwsi mówić dzień dobry.

2

Ten wątek mnie trochę pociesza. Jestem na początku swojej drogi (2 lata doświadczenia) i od samego początku dużo pytam i zawsze staram się pomagać w miarę swoich możliwości. Zawsze stawiam zespół ponad indywidualne sukcesy bo wiem, że w dłuższej perspektywie wszystkim to wyjdzie na dobre a karma wraca :)

Tutaj wchodzi kolejny problem. Niektórzy dzielą się wiedzą tak jakby byli zmuszeni wraz z jakimś wyrzutem "jak możesz tego nie wiedzieć?" i podbijaniem własnego ego. Kompletnie z mojego punktu widzenia tego nie rozumiem.

Jeśli ktoś przychodzi do mnie z pytaniem to podświadomie mówi "Hej, mam problem nie do końca rozumiem/umiem/ jestem słabszy w tym aspekcie". Jak można jako ten "ekspert" sprawiać wrażenie jakby się chciało pokazać wyższość nad pytającym? Apel do takich osób. Jeśli macie dobijać tak osobę pytającą to lepiej w ogóle nie pomagajcie bo nic tak nie demotywuje jak takie zachowania i próba podbicia swojego ego.
Przecież wiadomo, że wiecie więcej dlatego pytający przyszedł własnie do Was i prosi Was o pomoc.

Mam nadzieję, że w następnej pracy trafię na takie osoby, które wypowiadają się w tym temacie :)

0

Nawet na zachodnich uniwersytetach mają rozdział stanowisk naukowych od pedagogicznych - więc skoro ktoś woli rozwijać wiedzę a nie uczyć głupszych od siebie to ma taką możliwość i prawo. Od uczenia są ludzie którzy to lubią.

U nas niestety sowiety wdrożyły program socjalizmu naukowego w którym człowiek który nie potrafi się dzielić zrozumieniem jest bezużyteczny jako taki więc mamy to co mamy.

9
loza_wykletych napisał(a):

U nas niestety sowiety wdrożyły program socjalizmu naukowego w którym człowiek który nie potrafi się dzielić zrozumieniem jest bezużyteczny jako taki więc mamy to co mamy.

Expert programowania, który ma zerową komunikację i nie dzieli się wiedzą, jest warty tyle co junior. Change my mind.

2
Pinek napisał(a):

Expert programowania, który ma zerową komunikację i nie dzieli się wiedzą, jest warty tyle co junior. Change my mind.

Jest wart tyle ile firma zgodzi się mu zapłacić.

1
Pinek napisał(a):

Expert programowania, który ma zerową komunikację i nie dzieli się wiedzą, jest warty tyle co junior. Change my mind.

Dobra komunikacja != umiejętność dzielenia się wiedzą.
Jak pracujesz z ogarniętymi ludźmi, wystarczy że wytkniesz im błędy na review.
Problem w tym, że zazwyczaj nie pracujesz z ogarniętymi ludźmi i często trzeba mieć "specjalne podejście".

3
loza_wykletych napisał(a):

Nawet na zachodnich uniwersytetach mają rozdział stanowisk naukowych od pedagogicznych - więc skoro ktoś woli rozwijać wiedzę a nie uczyć głupszych od siebie to ma taką możliwość i prawo. Od uczenia są ludzie którzy to lubią.

U nas niestety sowiety wdrożyły program socjalizmu naukowego w którym człowiek który nie potrafi się dzielić zrozumieniem jest bezużyteczny jako taki więc mamy to co mamy.

Trochę mieszasz pojęcia. W większości programowanie to zajęcie zespołowe. Obecnie większość dużych odkryć to też zajęcie zespołowe. Więc zarówno programiści jak i naukowcy muszą umieć rozmawiać z współpracownikami. Zupełnie czym innym jest nauczanie pedagogiczne (w szkole, na uniwersytecie, w bootcampie, czy na konferencji) gdzie musisz wyjść przed tłum 25 lub 250 osób i mówić 45 minut lub więcej

1
KamilAdam napisał(a):

Trochę mieszasz pojęcia. W większości programowanie to zajęcie zespołowe. Obecnie większość dużych odkryć to też zajęcie zespołowe. Więc zarówno programiści jak i naukowcy muszą umieć rozmawiać z współpracownikami. Zupełnie czym innym jest nauczanie pedagogiczne (w szkole, na uniwersytecie, w bootcampie, czy na konferencji) gdzie musisz wyjść przed tłum 25 lub 250 osób i mówić 45 minut lub więcej

Programowanie to nie żadne rozwijanie wiedzy/dzielenie się wiedzą tylko zwykły industrial job. Dlatego korpo cisną w zespołowość - bo tak postrzegają ten zawód w swoich tabelkach w ekcelu. Można się zastanowić czy starszy majster w fabryce co jako jedyny w robocie skończył podstawówkę i nauczył się pisać-czytać ma tak samo przekazywać swoją wiedzę o zawodzie młodszym co dalej pozostają niepiśmienni (circa 100 lat temu). I czy ma to sens.

Obecnie większość dużych odkryć to też zajęcie zespołowe.

Chyba w przemyśle naukowym nastawionym na ciągłe publikacje.

1
loza_wykletych napisał(a):

Programowanie to nie żadne rozwijanie wiedzy/dzielenie się wiedzą tylko zwykły industrial job. Dlatego korpo cisną w zespołowość - bo tak postrzegają ten zawód w swoich tabelkach w ekcelu. Można się zastanowić czy starszy majster w fabryce co jako jedyny w robocie skończył podstawówkę i nauczył się pisać-czytać ma tak samo przekazywać swoją wiedzę o zawodzie młodszym co dalej pozostają niepiśmienni (circa 100 lat temu). I czy ma to sens.

To nie jest industrial job, tylko praca biurowa jak np. księgowość. To bardziej na zasadzie uczenia koleżanki jak obsługiwać drukarkę - czy byłoby bardziej opłacalne nauczyć ją jak czytać instrukcje? Pewnie tak, ale to wymaga pewnego poziomu ogarnięcia. Z tym że w IT masz gorzej, bo senior zarabia 15k i zysk z marnowania jego czasu na uczenie juniora jak działa git, jest ujemny.

3

zysk z marnowania jego czasu na uczenie juniora jak działa git, jest ujemny.

Zysk z juniora, który nie zostanie nauczony jak działa git jest jeszcze mniejszy. Z dwojga złego chyba lepiej mu powiedzieć.

1
part napisał(a):

To nie jest industrial job, tylko praca biurowa jak np. księgowość.

Industrial job to dla mnie coś co podlega skalowaniu i uniformizacji. Programowanie jako takie jeszcze się przed tym broni bo mimo wszystko wymaga choć trochę abstrakcyjnego myślenia. Ale cały wysiłek jest wkładany w uniformizację - wzorce, OOP, schematy kodowania, TDD. To że to się kończy póki co słabo to inna rzecz.

Bo z drugiej strony - jeśli zastąpilibyśmy litery alfabetu abstrakcyjnymi znakami + zdefiniowali stałe operatory to czy nawet osoba niepiśmienna miała by problem z zaprogramowaniem modułu prostego CRUDa?

8

zysk z marnowania jego czasu na uczenie juniora jak działa git, jest ujemny.

Nie wiem czemu wszyscy zakładają że uczy się tylko juniorów. Pracuje 9 lat i teoretycznie jestem seniorem, ale zdarza mi się czegoś nie wiedzieć co wie pewnie niejeden junior. Z drugiej strony miałem okazję tłumaczyć ekspertom bazodanowym (20+lat doświadczenia) jak działają gałęzie w gicie ( oraz Release Managerowi czym się różnią tagi od gałęzi i że w przypadku wydawania releasu używa się tagów, ale to akurat śmieszne) Im większa specjalizacja eksperta tym większe prawdopodobieństwo że nie wie czegoś co prawie wszyscy wiedzą

loza_wykletych napisał(a):
part napisał(a):

To nie jest industrial job, tylko praca biurowa jak np. księgowość.

Industrial job to dla mnie coś co podlega skalowaniu i uniformizacji. Programowanie jako takie jeszcze się przed tym broni bo mimo wszystko wymaga choć trochę abstrakcyjnego myślenia. Ale cały wysiłek jest wkładany w uniformizację - wzorce, OOP, schematy kodowania, TDD. To że to się kończy póki co słabo to inna rzecz.

Bo z drugiej strony - jeśli zastąpilibyśmy litery alfabetu abstrakcyjnymi znakami + zdefiniowali stałe operatory to czy nawet osoba niepiśmienna miała by problem z zaprogramowaniem modułu prostego CRUDa?

abstrakcyjnyne znaki to pismo (niekoniecznie alfabet) więc twój argument jest inwalidą

1
loza_wykletych napisał(a):

Można się zastanowić czy starszy majster w fabryce co jako jedyny w robocie skończył podstawówkę i nauczył się pisać-czytać ma tak samo przekazywać swoją wiedzę o zawodzie młodszym co dalej pozostają niepiśmienni (circa 100 lat temu). I czy ma to sens.

A jak inaczej chcesz zapewnić niezależność procesu produkcyjnego od konkretnych osób? Jak w ogóle chcesz sprawić by ktokolwiek nowy nabrał wiedzy potrzebnej do realizacji zadań?

0
GutekSan napisał(a):

A jak inaczej chcesz zapewnić niezależność procesu produkcyjnego od konkretnych osób? Jak w ogóle chcesz sprawić by ktokolwiek nowy nabrał wiedzy potrzebnej do realizacji zadań?

A jak to jest na produkcji? Też masz szkolenia z używania maszyn.
A niezależnośc uzyskujesz przez standaryzację.

2
part napisał(a):

A jak to jest na produkcji? Też masz szkolenia z używania maszyn.

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.

A niezależnośc uzyskujesz przez standaryzację.

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.

0
KamilAdam napisał(a):

abstrakcyjnyne znaki to pismo (niekoniecznie alfabet) więc twój argument jest inwalidą

Pismo to jeden z sposób przekazywania ludzkiej mowy. Dzieli większość jej cech - wieloznaczność, kontekstowość, niezupełność. To zupełnie odrębne pojęcie od zestawu abstrakcyjnych znaków jakim jest alfabet. Hieroglify były pismem. Ideogramy również.

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

GutekSan napisał(a):

A jak inaczej chcesz zapewnić niezależność procesu produkcyjnego od konkretnych osób? Jak w ogóle chcesz sprawić by ktokolwiek nowy nabrał wiedzy potrzebnej do realizacji zadań?

Baza wiedzy, procedury i częsta ewaluacja. A problem niezależności procesu produkcyjnego od konkretnych osób zna jedno rozwiązanie - odpowiednią skalę.

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