Temat: czego się uczą dzisiaj programiści...
Paweł Włodarski:
Jeśli zaś chodzi o twoje pytanie. To spróbujemy teraz drogi empatycznej . Wysil teraz wszystkie neurony lustrzane i wyobraź sobie sytuację kiedy jesteś zdegradowany do roli pasywnego elementu projektu.
daruj sobie interpretacje moich neuronów bo ja Twoich nie oceniam...
Przed tobą w łańcuchu jest pan ,którego wypowiedź wyśmiałeś w pierwszym wątku. On tworzy projekt a twoim zadaniem jest tylko i wyłącznie pomóc programista go zrozumieć, nie masz prawa nic zmieniać.
ktoś go, na podstawie czegoś, do tego projektu zatrudnił jako projektanta, to pierwsze ryzyko projektu (taka rekrutacja jest niestety powszechna w dużych projektach w tym kraju).
No i teraz nie zgadzasz się z jego dokumentem. Są dwie opcje albo "szanujesz" autora dokumentu i chowasz głowę w piasek albo zaczynasz dyskutować z nim na co słyszysz "Panie Jarku proszę nie dyskutować pan ma swój etap ja mam swój , ma Pan szanować wyniki mojego etapu , potem je wytłumaczyć , nie dyskutować i koniec!" .
opisałeś swoją propozycję a ja robię to tak: zanim podejmę się pracy opisuję swoją ofertę czyli co potrafię zrobić i czego potrzebuję, stawiam minimalne wymagania na produkt mojego poprzednika - określam swoje "zamówienie", jeśli nie wiadomo tego na początku, przydają się standardy w szczególności podział projektu na etapy i role wykonawców (zakres odpowiedzialności każdego wykonawcy), standardy (np. notacje i metodyki) opisują jakie wymagania ma spełniać produkt etapu. Nie toleruje jednak podejścia "jak coś razem wypracujemy to potem coś z tym zrobimy"... bo to praca na zasadzie "może coś z tego wyjdzie"...
Nie masz wpływu na to jakie (twoim zdaniem) bzdury i bełkot masz przekazać programistom.
ja mam bardzo duży wpływ: mogę nie przyjąć zamówienia, jak dostaje coś do "dalszej" pracy i widzę w tym jakieś ryzyka, zgłaszam to sponsorowi projektu, są to pytania i uwagi do cudzego produktu. Otrzymuje jakąś odpowiedź, zależnie od tego co dostanę wchodzę w projekt lub rezygnuję.
Teraz naprawdę wysil swoje zdolności empatyczne bo to jest kluczowe : chce ci się rozwijać dalej w tej dziedzinie czy raczej po pracy znajdziesz sobie inne hobby dla zabicia frustracji?
mam taki zwyczaj, że zanim zaneguje cudze zdanie staram się dobrze poznać problem ale nie od jednego "mentora" czy "guru" a z możliwie dużej ilości rożnych źródeł, korzystanie z wiedzy tylko jednej osoby naraża nas na ryzyko bezwiednego powiela cudzego bełkotu ... tak więc to co robię to także hobby, a każda kolejna książka uczy mnie większej pokory zamiast nadymania się ... po drugie na pewno ilość nie decyduje o uznaniu "prawdziwości tezy", gdyby tak było tworzył bym diagramy klas jako "modele danych"... a na szczęście nie robię tego.
w każdym razie opisałeś patologię, do której nie dopuszczam w swoich projektach: ja nic nie muszę... w szczególności nie musza akceptować cudzego bełkotu.
Staram się tylko umieć poprzeć każdą prezentowaną tezę, nie uciekam do idiotycznych "przecież każdy wie" co niektórzy mają tu w zwyczaju, bo to przyznanie się do niewiedzy, niemocy, niezrozumienia.
Współpracuję między innymi z wieloma programistami, nie dlatego że oni mnie "namówili" a dlatego że uznałem ich autorytet i wiedzę. Tych samych moich projektów jedni nie rozumieją a inni je szybko i sprawnie realizują. Są tacy, którzy je negują i mają prawo, ja w takich przypadkach rezygnuje z ich usług. Ale nie toleruję przypadków podjęcia się projektu i późniejszego jego negowania i wprowadzania nieautoryzowanych zmian, bo o tym tu głównie mowa.
Ot tak widzę wzajemny szacunek.
Kiedy nazywam coś bełkotem? Są sytuacje, gdy coś nie podlega ocenie przez aklamację bo jest wynikiem konkretnej wiedzy, np. formalne notacje czy paradygmaty (tu obiektowy), który albo się rozumie albo nie, podobnie jak 2+2=4 gdzie 2+2=5 to bełkot.
пропозиції роботи
