Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
...
Powiedz ilu znasz ludzi, którzy mają 10 lub więcej lat doświadczenia w tworzeniu kodu?

Z tuzin znam.Aleksander Olszewski edytował(a) ten post dnia 05.07.11 o godzinie 09:04

Temat: A ja się dziwię programistom, przepraszam Was...

Tępiłem i tępię samowolne zmiany w projekcie, ale jestem także bezwzględny w zakresie braku przepływu informacji: "dlaczego nie zapytałeś?"

tzn pracownicy projektu powinni wzajemnie dopytywać się o informacje ?

Temat: A ja się dziwię programistom, przepraszam Was...

Jakub Wojt:

Tępiłem i tępię samowolne zmiany w projekcie, ale jestem także bezwzględny w zakresie braku przepływu informacji: "dlaczego nie zapytałeś?"

tzn pracownicy projektu powinni wzajemnie dopytywać się o informacje ?

Myślę, że chodziło o to, że czasami ktoś nie jest pewien czegoś w dokumentacji / specyfikacji i robi tak jak jemu wygodniej, zamiast dopytać autora...

Temat: A ja się dziwię programistom, przepraszam Was...

Myślę, że chodziło o to, że czasami ktoś nie jest pewien czegoś w dokumentacji / specyfikacji i robi tak jak jemu wygodniej, zamiast dopytać autora...

dlatego powinien być dostępny do końca projektu ...

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

Paweł Włodarski:
Napisałeś, że Ty byś rzucił robotę a co gdybyś jednak nie mógł jej rzucić?

podaj przykład dlaczego? żyjemy w wolnym kraju ...

Można zacząć od klasycznego przykładu człowieka spłacającego kredyt hipoteczny .Dorzućmy do tego małe dziecko i mamy już trochę powodów żeby nie rzucać pracy z dnia na dzień. Na innym biegunie może pojawić się ktoś przywiązany emocjonalnie do danej firmy. Jest naprawdę wiele możliwości kombinacji dlaczego ktoś nie może(lub wkręca sobie ,ze nie może) rzucić etatu od tak.

Co do RUB - to to taka specjalna metodyka, dźwiękonaśladowcza do RUP a sprowadzająca się do "masz i RÓB" (Takie szastanie "zasobami" na lewo i prawo , przerzucanie ludzi z jednej komórki excela w drugą i maksymalne ukrywanie wszelkich informacji bo to (cyt.) "zwiększa przewagę psychologiczną", i inne takie głupoty).

Natomiast miło odebrałem to co napisałeś o nie robieniu z "informatyków" murarzy i ten watek poruszę w odpowiedzi na post Aleksandra.

PS. naprawdę przyjemniej się dyskutuje (przynajmniej mnie) jak nie szatkuje się tak wypowiedzi.

pzdr

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:38

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
Można zacząć od klasycznego przykładu człowieka spłacającego kredyt hipoteczny

to są ograniczenia, które sami sobie nakładamy na własne życzenie... osobiście "nie przepadam" za tą ścieżką uzasadnienia zachowań, bo w innym wątku pewien facet w ten sposób (trza zarobić na rodzinę) tylko otarł się o to napady i okradanie staruszek by zarobić na kredyt, samochód i wakacje w tropikach...

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
Mój wniosek jest taki, że tworzenie oprogramowania w Polsce wygląda jak wygląda bo mało kto się na tym zna:)

z niesmakiem ale się z tym zgadzam..

Ale cóż się dziwić, że w metodykach które robią z programisty najmniej znaczącą i decyzyjną rolę nikt nie chce tej funkcji pełnić (przynajmniej powyżej stopnia "nowicjusz").

tu widzę "zafałszowanie" rzeczywistości, ja "otoczenie" odbieram tak, że programiście, którzy nie umieją programować chcą się wykazać w "dyskusji o tym co ma powstać", jak wspomniałem logika biznesowa to ledwie kilka procent kodu, wiec programista ma co robić, rzecz w tym, że to najtrudniejsza (moim zdaniem) część kodu, w moim mniemaniu to ta odpowiedzialna za wymagania pozafunckjonalna, ale chyba jest tak jak napisałeś, prawie nie ma dobrych programistów a Ci "z niewiedzą" zaczynają wyżywać się na tych kilku procentach "prostego" kodu maszyny stanowej, bo nic więcej nie potrafią i w sumie zachowują się jak "wszyscy pracownicy znają się na marketingu" a tak na prawdę potrafią podyskutować o ulotkach na targi....

jest oczywiście alternatywa ale jak większość osób ja słyszy to mówi "edżajl sredzajl bo nie można wszystkiego do razu zaplanować i do szpiku kości kontrolować" (oczywiście pierwszego nie da się nigdy zrobić a drugie jest niepotrzebne ale to już na inną okazję)

:)

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
...
Goldenline ma takiego fajnego buga, który pozwala na sprawdzenie oryginalnej wersji postu autora:) I naprawdę Aleksander możesz pisać do mnie wprost co myślisz bo się nie obrażę i jest luz;) (No i niczego i nikogo nie biję ;))

Właściwie zmieniłem treść wypowiedzi, aby kogoś z szerszego grona nie obrazić przypadkiem. Obawiałem się, że ktoś, kto nie pracował w agencji reklamowej może tego żartu nie zrozumieć. Taki żarcik branżowy ;)

Generalnie zadałem to pytanie żeby trochę nakręcić dyskusję bo jedyna odpowiedź na to pytanie w ówczesnej Polsce to "niewielu" (tuzin rozumiem dosłownie).

Pytanie dotyczyło programistów z ponad dziesięcioletnim komercyjnym stażem pracy w roli programisty. Tak to zrozumiałem. Zgodzę się z Tobą, że jest ich jak na lekarstwo.

Dalszy ciąg wypowiedzi nie jest skierowany do nikogo personalnie ale ma formę
Broadcastu.

Sytuacja wygląda tak:
1) Istnieje Model zdobywania umiejętności, który powstał na bazie naukowej obserwacji i nazywa się :http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_ac...

Przedstawia on 5 etapów doskonalenia umiejętności do nowicjusza, który potrzebuje jasnych instrukcji do eksperta, który działa intuicyjnie i nad wyraz skutecznie.

2)W większości Polskich firm, które znam z programistów, którzy weszli na poziom "Advanced beginner" ale mają 3 lata doświadczenia robi się starszych programistów przez co ci jeszcze bardziej sobie wkręcają, że są zajebistymi programistami kiedy daleko im do tego.

Ze wszystkich starszych nie zrobisz, pozostali z reguły szukają ścieżkę kariery poza firmą. I tu pojawia się kilka kwestii: nie wszyscy menadżerowie zdają sobie sprawę z czegoś takiego jak cicha wiedza, stracony czas na poszukiwanie pracownika, koszt wprowadzenia do zespołu nowego człowieka (czas wdrożenia osoby + czas zajęty innym = spadek wydajności wszystkich).

3)Aby wejść ponad poziom "Advanced beginner" musisz pracować bezpośrednio z kimś ponad tym poziomem i być przez ta osobę szkolony. Drugą opcją jest korzystanie z "derywatów" ekspertów czyli wszelkiej maści publikacji i prezentacji jednocześnie będąc w stanie surowo i bez emocjonalnie oceniać swoje postępy.

I tu jest chyba największy problem. Niewielu ludzi z własnej woli poświęca swój czas i pieniądz na rozwój. Z reguły jak firma nie "postawi", to ten ktoś nie ruszy się. Firma nie "postawi", bo na starszym programiście ścieżka się kończy a przekwalifikowany pracownik traci motywację a zadania tracą charakter wyzwania. Koło się zamyka.

4)W Polsce jest jak na lekarstwo ekspertów w dziedzinie pracy z kodem ponieważ ,z tego co wiem, w większości firm ścieżka kariery Programisty jest króciutka i kończy się na "senior developer" (który często jest "zaawansowanym początkującym"). Później jedynym wyjściem jest ewakuacja, ucieczka na inną ścieżkę kariery zwana dla wewnętrznego spokoju "awansem".

Znam kolejny tuzin byłych programistów którzy przekwalifikowali się na projektantów lub menadżerów. Nie widzę w tym nic złego, o ile ten ktoś zyskuje dystans do tego co robił. Bo zadania w nowej roli są często sprzeczne z jego dotychczasową intuicją.

Kolejny tuzin programistów znam takich, co "drastycznie" zmienili technologię. W związku z tym traktować ich jako Novice? Mi osobiście pomagało sięganie od samego początku do standardów i uniwersalnych "technologii": xml parsuje się tak samo, wyrażenia regularne są te same w różnych językach itd. Czy wszyscy programiści mają takie podejście? Nie wiem.

Mój wniosek jest taki, że tworzenie oprogramowania w Polsce wygląda jak wygląda bo mało kto się na tym zna:) Ale cóż się dziwić, że w metodykach które robią z programisty najmniej znaczącą i decyzyjną rolę nikt nie chce tej funkcji pełnić (przynajmniej powyżej stopnia "nowicjusz"). jest oczywiście alternatywa ale jak większość osób ja słyszy to mówi "edżajl sredzajl bo nie można wszystkiego do razu zaplanować i do szpiku kości kontrolować" (oczywiście pierwszego nie da się nigdy zrobić a drugie jest niepotrzebne ale to już na inną okazję)

Ja osobiście wolę podobną do modelu Dreyfusa koncepcję Shuhari. Wszyscy początkujący programiści są na poziomie shu. Czy mamy ich ignorować czy dążyć do tego, by osiągnęli poziom ha? Potrzebują przecież dokładnych instrukcji. Wielu programistów poza ha nie wychodzi. Dotyczy to również pozostałych: projektantów, analityków, kierowników projektu (słowo kierownik mi mało odpowiada, ale po polsku tak to brzmi) itd. Mam wrażenie, że poziom ri w Polsce praktycznie nie występuje.

Do tego dochodzi środowisko niskiego zaufania, oraz krytyczność projektów i liczność zespołu, czas który jest potrzebny na dostrojenie się pracownika (patrz w XP współczynniki programisty), ulotność pamięci oraz duże systemy (te których dwóch studentów w garażu nie napiszą).

W obliczu tego wszystkiego nadal nie rozumiesz, że wizualne modelowanie jest koniecznością i obciążającym narzutem, takim samym jak paradygmat obiektowy? To że nie warto pisać klasa po klasie, metodo po metodzie, a wygenerować szkielet systemu oraz interfejsy z narzędzia CASE --- co wtedy zostanie dla programisty? Lub może wierzysz w samoopisujący się kod? A może całą dokumentację przenieśmy do kodu aplikacji, wtedy rzeczywiście programista będzie po łokcie urobiony.

Projekt jest grą zespołową. Bez przynajmniej podstawowego zaufania do pozostałych uczestników gry będziemy grać jak polscy piłkarzy.

Temat: A ja się dziwię programistom, przepraszam Was...

Tępiłem i tępię samowolne zmiany w projekcie, ale jestem także bezwzględny w zakresie braku przepływu informacji: "dlaczego nie zapytałeś?"

tzn pracownicy projektu powinni wzajemnie dopytywać się o informacje ?

Myślę, że chodziło o to, że czasami ktoś nie jest pewien czegoś w dokumentacji / specyfikacji i robi tak jak jemu wygodniej, zamiast dopytać autora...

Na marginesie:
Z doświadczeń wiem, że takie 'dopytywanie' nic nie daje; Na samą myśl, że ktoś mógłby takie pytanie zadać programiście - 'scyzoryk sam mi się w kieszeni otwiera'

Temat: A ja się dziwię programistom, przepraszam Was...

Jakub Wojt:

Tępiłem i tępię samowolne zmiany w projekcie, ale jestem także bezwzględny w zakresie braku przepływu informacji: "dlaczego nie zapytałeś?"

tzn pracownicy projektu powinni wzajemnie dopytywać się o informacje ?

Myślę, że chodziło o to, że czasami ktoś nie jest pewien czegoś w dokumentacji / specyfikacji i robi tak jak jemu wygodniej, zamiast dopytać autora...

Na marginesie:
Z doświadczeń wiem, że takie 'dopytywanie' nic nie daje; Na samą myśl, że ktoś mógłby takie pytanie zadać programiście - 'scyzoryk sam mi się w kieszeni otwiera'

To raczej programista zadaje takie pytanie projektantowi

Temat: A ja się dziwię programistom, przepraszam Was...

Na marginesie:
Z doświadczeń wiem, że takie 'dopytywanie' nic nie daje; Na samą myśl, że ktoś mógłby takie pytanie zadać programiście - 'scyzoryk sam mi się w kieszeni otwiera'

To raczej programista zadaje takie pytanie projektantowi

A co projektant miałby pytać programistę ? :)

Po czasie stwierdzam, że pytania dotyczące pytań 'dlaczego nie zapytałeś', to trudny temat do dyskusji ;)Jakub Wojt edytował(a) ten post dnia 07.07.11 o godzinie 21:05

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:39

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:39

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:39

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
Ciekawiło mnie po prostu jak postrzegasz motywację osób, o których pisałeś w pierwszym poście. Wydaje mi się, że tam gdzie ty widzisz pychę i złośliwość programistów ja widzę nieświadomość i brak edukacji.

obyś miał rację, jednak z blogów niektórych programistów wynika, że "czasem nie tak rzadko rację"... najbardziej mnie dziwi to, że znam osoby które na swoich blogach nie ukrywają "naciągania, dojenia" itp. na tych własnych blogach mają także profile z nazwami firm w których pracują, ... jak ich nazwać?

jednak mimo to, motyw finansowy jest w moich oczach kiepską wymówką... zostawmy ten wątek... Jarek Żeliński edytował(a) ten post dnia 06.07.11 o godzinie 23:28

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
...

Aleksander Olszewski:
W obliczu tego wszystkiego nadal nie rozumiesz, że wizualne modelowanie jest koniecznością

No powiem ci, że do tego momentu nawet podobał mi się twój post ale tu nagle takie zwroty w stylu NLPowskim? :)

Aleksandrze nadal nie rozumiesz już jak doskonała jest dokumentacja, która nie opisuje jeszcze raz tego co już gdzieś jest opisane?, czy rozumiesz już jak spójny i niezawodny kod tworzymy używając TDD czy dostrzegasz już jak efektywna będzie praca programisty jeśli nauczy się on tworzyć czytelny kod?:D

Rozumiem, że mówiąc o TDD masz na myśli to http://www.goldenline.pl/forum/2434238/projektowanie-a... :) Ciekaw jestem czy tylko Ty tak testujesz, czy pozostali twoi koledzy też? Czyli jak wrócisz do pracy rano, a testy przeszły pomyślnie zarzynasz cały dzień na przepisywanie testów? A może zamiast spisać test porządnie, z uwzględnieniem klas parametrów, napiszmy od bani test, po nocy będziemy wiedzieć czy jest źle spisany? A gdzie realizacja pozytywnej ścieżki? Gdzie weryfikacja czy test jest dobrze spisany? Sądząc po braku reakcji na pozostały pytania, wierzysz w samoopisujący się kod. Czyli analizę wymagań robi programista (Inżynier) lewą ręką i lewym okiem, bo prawą koduje a prawym okiem weryfikuje kod. Co do narzędzi CASE, to wydawało mi się, że są w programie każdego kierunku studiów, kształcących inżynierów. To że nigdy na takie narzędzie nie trafiłeś nie oznacza, że go nie ma.

Nie, nie musisz odpowiadać na powyższe pytania;)

Projekt jest grą zespołową. Bez przynajmniej podstawowego zaufania do pozostałych uczestników gry będziemy grać jak polscy piłkarzy.

No dokładnie, trzeba ufać programistom ;)

Zapominasz o tym że ta relacja powinna być dwustronna. Programista powinien mieć zaufanie do pracy analityka, projektanta, architekta, kierownika projektu, klienta i do starszego programisty też :)

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

świat składa się z redundancji.

Byłbym bliższy stwierdzeniu, że z "nieefektywnych" i często wieloznacznych powiązań (dla programistów - kluczy :).

Np. Adres, kod produktu, nr dokumentu, Nazwisko i imię. W zależności od kontekstu realizują odwołania do czegoś innego :)

Temat: A ja się dziwię programistom, przepraszam Was...

Wszystko zależy od tego, co robimy. W prostych sytuacjach redundancja na poziomie rekordu w bazie nie jest nam potrzebna i wystarczy tabela audytowa. Czasem potrzebne jest i jedno (FK - dla łatwego wyszukiwania informacji) i drugie (redundancja - historyczność danych) i jest to chyba najlepsze rozwiązanie.

Jeśli jest to aplikacja, w której nie interesuje nas historia zmian, to wystarczy FK w bazie do pacjenta, plus w razie czego jakiś prosty auditing do osobnej tabeli - tylko dla naszej wygody. Pacjent jest zawsze tym samym fizycznie bytem. I tutaj wygodnie się wyszukuje informacje w bazie. Załóżmy, że jesteśmy właścicielem wideoteki i chcemy zobaczyć, kto jakie filmy wypożycza celem wygenerowania oferty promocyjnej. Interesuje nas WW (wielokrotna wdowa :) ) Kunegunda Wrocławska, która zmieniała 3 razy nazwisko po kolejnych mężach. Wystarczy, że podamy jedno z nazwisk, a grzebiąc po tabeli audytowej dotrzemy, jak po sznurku, do jej PK, a mając PK - możemy wygenerować kompletną listę rezultatów wyszukiwania. Zakładamy, że nie można prościej się do tego dokopać (np. po
PESELu).

Ale już w aplikacji medycznej czy innej, obwarowanej ostro przepisami prawa, nie chcemy brońcie bogowie ingerować w np. treść dokumentu księgowego czy medycznego i nie chcemy tam kluczy, a konkretne wartości, jako, że ów dokument jest trwałym, odrębnym, historycznym bytem. Trudno bowiem wyobrazić sobie, że wystawiamy fakturę na Kunegundę Gitarowską, która, po kolejnym "zamęściu" zmieniła nazwisko na Wrocławska, a owa faktura ma jedynie FK do naszej pacjentki. Nagle wszystkie historyczne faktury automatycznie są wystawione na osobę, której personalia były w tamtym czasie inne. Podobnie z nazwą badania, która "linkuje" do wypisów ze szpitala, czy innych parametrów, których zmiana, w razie np. śledztwa będzie mieć kluczowe znaczenie.

Tutaj tabela zmian jest tylko częściowym rozwiązaniem, bo chociaż "pozwala się dokopać do tego, jak było", to nie eliminuje modyfikacji dokumentów opartych o FK. Jest to takie "niespójne", śliskie, bo niby wiemy, że fizycznie mielibyśmy osobny dokument z własnymi wartościami (papier, podpisany elektronicznie plik), a tu mamy FK plus dodatkowo jakieś mechanizmy wersjonowania danych.

Z drugiej strony utrudnia to bądź uniemożliwia wyszukiwanie, jeśli lista zmian nie jest powiązana z bytem "pacjent", a za każdym razem zmiany są zapisywane do bazy. Jak rezygnujemy z "relacji do pacjenta" i zapisujemy za każdym razem pełne dane (pomijam nawet literówki) i zapytamy o listę chorób Kunegundy Żelazny-Toporek, która rok wcześniej nazywała się Wrocławska po drugim mężu, a wcześniej Gitarowska po pierwszym mężu, nie dostaniemy kompletnej odpowiedzi. Oczywiście - ktoś powie, że należy wyszukiwać po PESELu albo innym atrybucie dyskryminującym, np. ID karty pacjenta, ale to była tylko ilustracja, gdyż rzeczywistość wskaże za chwilę taki atrybut, który może się zmienić, a mimo to trzeba po nim wyszukiwać również historyczne dane. Trzeba, bo pacjent, który dzwoni, nie pamięta swojego PESELa, numeru karty stałego klienta czy jeszcze tam czegoś innego. I tutaj najlepiej stosować zarówno FKi do łatwego wyszukiwania, jak również redundancję na poziomie rekordu dla zachowania historyczności danych.

PS: tak, świadomie operuję pojęciami z RDB, zamiast - asocjacja i agregacja :)Adrian Olszewski edytował(a) ten post dnia 07.07.11 o godzinie 12:55

Temat: A ja się dziwię programistom, przepraszam Was...

Wojciech Kłujszo:

Jarek Żeliński:
świat składa się z redundancji.

Byłbym bliższy stwierdzeniu, że z "nieefektywnych" i często wieloznacznych powiązań (dla programistów - kluczy :).

ja nie dyskutuję "ze światem" tylko go analizuję.. nawet jeśli "świat jest głupi" to nie my to zmienimy a oprogramowanie przetwarza dane o tym świecie...

Jeżeli jestem szatynem, to nie znaczy, że jestem zasocjowany z pozycją "szatyn" w słowniku kolorów włosów (gdzie on???) a znaczy, że mój kolor włosów to "szatyn".Na pytanie "kolor włosów" odpowiadam "szatyn", jak ktoś zawoła "szatyni wstać" to wstaję.

Np. Adres, kod produktu, nr dokumentu, Nazwisko i imię. W zależności od kontekstu realizują odwołania do czegoś innego :)

tego nie zrozumiałem...