eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingBlad w oprogramowaniu Toyoty przyczyna wypadkow
Ilość wypowiedzi w tym wątku: 221

  • 61. Data: 2012-03-20 11:39:01
    Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Andrzej Jarzabek <a...@g...com>

    On Mar 20, 8:17 am, zażółcony <r...@c...pl> wrote:
    > W dniu 2012-03-16 18:12, Andrzej Jarzabek pisze:
    >
    > >> Jeśli dopuścimy, że główny ciężar odpowiedzialności
    > >> ponoszą specjaliści niskiego szczebla, to będziemy mieć
    > >> wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
    > >> na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
    > >> z innych rejonów świata.
    >
    > > Gdyby jednocześnie z tym dopuszczeniem weszła w życie certyfiacja
    > > zawodowa, to buć może nie będziemy.
    >
    > Papier przyjmie wszystko a sam w sobie jakości nie czyni.

    Oczywiście, że nie czyni. Dlatego mówię o certyfikacji, a nie o
    papierze.

    Pozwol, że wytłumaczę ci pewną różnicę: jeśli ja zapisze jakiś tekst w
    swoim zeszycie, a jeśli Sejm RP przegłosuje zapisanie takiego samego
    tekstu w Dzienniku Ustaw, to mimo, że papier przyjął to samo, to
    konsekwencje mogą być zgoła inne.

    > Politycznie to teraz będzie raczej fala deregulacji w różnych
    > obszarach, a nie regulacji.

    Czy przypadkiem nazywasz się Rip Van Winkle?

    > Jeśliby założyć, że PRACODAWCA wierzy i będzie wierzył
    > papierom, to wtedy może miałoby to sens. Ale jeśli pracodawca
    > i tak musi każdy papier zweryfikować, to ja tu raczej widzę
    > głównie nadymanie okresowego biznesu dla firm szkoleniowych.

    Sens nie jest taki, że pracodawca w cośtam wierzy albo nie wierzy,
    tylko że pracodawca może dostać karę za brak odpowiedniej
    certyfikacji, ewentualnie że w procesie fakt zatrudnienia
    certyfikowanego specjalisty będzie stanowić różnicę między orzeczeniem
    o wypadku a o karygodnym zaniedbaniu.

    > Pracodawca musi mieć mechanizmy kontroli własnych produktów,
    > a papiery są dla niego jedynie wskazówką - może ich wymagać,
    > ale nie musi, zależy jak mu się to wpasowuje we wskaźniki
    > jakości. Nikt nie zmusza do zatrudniania programistów
    > bez wykształcenia kierunkowego.

    Mówisz jak jest, ale to przecież żaden argument za tym, że inaczej nie
    byłoby lepiej.

    > Pod tym względem jestem za daleko posuniętą liberalizacją.

    No ale to twoja opinia, za którą nie przedstawiłeś żadnych argumentów.
    Napisałeś tylko, że nie ma certyfikacji, więc nie ma certyfikacji.

    > Główny problem, jaki tu widzę, to kontakt państwo-biznes
    > prywatny, gdzie państwo poszukując partnerów zwraca
    > większą uwagę na cenę, niż na wskaźniki jakości.

    A ja widzę problem taki, że producenci dla zwiększenia zysku tną
    koszty i produkują wadliwe towary, które wybuchają i zabijają ludzi.


  • 62. Data: 2012-03-20 12:09:49
    Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Paweł Kierski <n...@p...net>

    W dniu 2012-03-20 12:39, Andrzej Jarzabek pisze:
    > On Mar 20, 8:17 am, zażółcony<r...@c...pl> wrote:
    >> W dniu 2012-03-16 18:12, Andrzej Jarzabek pisze:
    >>
    >>>> Jeśli dopuścimy, że główny ciężar odpowiedzialności
    >>>> ponoszą specjaliści niskiego szczebla, to będziemy mieć
    >>>> wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
    >>>> na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
    >>>> z innych rejonów świata.
    >>
    >>> Gdyby jednocześnie z tym dopuszczeniem weszła w życie certyfiacja
    >>> zawodowa, to buć może nie będziemy.
    >>
    >> Papier przyjmie wszystko a sam w sobie jakości nie czyni.
    >
    > Oczywiście, że nie czyni. Dlatego mówię o certyfikacji, a nie o
    > papierze.
    >
    > Pozwol, że wytłumaczę ci pewną różnicę: jeśli ja zapisze jakiś tekst w
    > swoim zeszycie, a jeśli Sejm RP przegłosuje zapisanie takiego samego
    > tekstu w Dzienniku Ustaw, to mimo, że papier przyjął to samo, to
    > konsekwencje mogą być zgoła inne.

    Patrząc w drugą stronę - jeśli Sejm RP przegłosuje, że suma opadów nie
    może przekraczać 40mm na dobę (bo to rodzi ryzyko powodzi), to
    konsekwencje zapisania tego w zeszycie, czy w Dzienniku Ustaw są takie
    same. Żadne rzecz jasna.

    Z certyfikacją może być właśnie jak z zaklinaniem deszczu - certyfikat
    świadczy na pewno o zdobyciu certyfikatu. W mniejszej lub większej
    liczbie przypadków - o posiadaniu pewnych umiejętności czy wiedzy
    w momencie jego zdobywania. O posiadaniu tych umiejętności za jakiś czas
    - już mniej. A jeszcze mniej o tym, czy te umiejętności zostały
    faktycznie zastosowane.

    [...]
    >> Jeśliby założyć, że PRACODAWCA wierzy i będzie wierzył
    >> papierom, to wtedy może miałoby to sens. Ale jeśli pracodawca
    >> i tak musi każdy papier zweryfikować, to ja tu raczej widzę
    >> głównie nadymanie okresowego biznesu dla firm szkoleniowych.
    >
    > Sens nie jest taki, że pracodawca w cośtam wierzy albo nie wierzy,
    > tylko że pracodawca może dostać karę za brak odpowiedniej
    > certyfikacji, ewentualnie że w procesie fakt zatrudnienia
    > certyfikowanego specjalisty będzie stanowić różnicę między orzeczeniem
    > o wypadku a o karygodnym zaniedbaniu.

    I ma to sens, gdy certyfikacja działa zgodnie z założeniami - również
    tymi niedopowiedzianymi (jak wyżej wspomniane używanie certyfikowanych
    umiejętności). Praktyka pokazuje, że certyfikacja służy głównie
    certyfikacji. Klasyczne są już anegdotki o kładzeniu instalacji
    elektrycznej pod którą podpisuje się pijany właściciel stosownych
    uprawnień, który tej instalacji na trzeźwo nigdy nie widział.

    [...]
    > A ja widzę problem taki, że producenci dla zwiększenia zysku tną
    > koszty i produkują wadliwe towary, które wybuchają i zabijają ludzi.

    Czyli obowiązek certyfikacji ma powodować, że trudniej będzie wytwarzać
    produkty niebezpieczne? To tą samą ścieżką - producenci dla zwiększenia
    zysku będą naginać i łamać przepisy o certyfikacji, czyli wracać de
    facto do stanu bez certyfikacji. Argument, że jednak będzie im trudniej
    i bardziej opłacalnie pilnować certyfikacji, odpieram pytaniem: czy
    ogólny koszt certyfikacji i jej pilnowania nie będzie przypadkiem
    większy? Czy to faktycznie zmniejszy liczbę wypadków/zagrożeń?
    I kluczowe - czy ludzie nie mają prawa dostawać produktów tańszych, choć
    potencjalnie bardziej niebezpiecznych?

    --
    Paweł Kierski
    n...@p...net


  • 63. Data: 2012-03-20 12:15:25
    Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Andrzej Jarzabek <a...@g...com>

    On Mar 20, 8:31 am, zażółcony <r...@c...pl> wrote:
    > W dniu 2012-03-18 15:10, Andrzej Jarzabek pisze:
    >
    > > Ostatecznie, nie wchodząc w to, czy ja akurat uważam certyfikację
    > > sensowną, czy nie, to jeśli założymy, że (bez certyfikacji) "będziemy
    > > mieć tyle wybuchów ile fal wchodzenia na rynek niedoświadczonych ludzi
    > > lub fal imigrantów", to byłby to kontrargument na "certyfikacja
    > > programistów jest śmieszna" - nie jest śmieszna, bo ogranicza ilość
    > > wybuchów (wypadków samochodowych itd.) W przypadku certyfikacji jeśli
    > > menedżmen nie pozwoli zrobić zgodnie z zasadami sztuki, to nie znajdzie
    > > certyfikowanych programistów, którzy zrobią tak, jak pozwoli.
    >
    > Jest śmieszna, tak jak śmieszne byłoby wymuszanie certyfikatów na
    > murarzach w reakcji na zawalające się domy.

    Programista to nie murarz, tylko inżynier.

    A przy budowaniu domów kierownik budowy musi być certyfikowany.

    > Murarz nie wchodzi na plac budowy z własnym projektem domu, własnymi
    > cegłami i własnym cementem. Ktoś mu to organizuje i ktoś kontroluje
    > jego pracę.

    I co z tego? Inżynier np. projektujący mosty albo instalacje
    elektryczne też nie przychodzi do pracy z własną inwestycją, własnym
    biurem i własnym CAD-em. Też go ktoś zatrudnia i też ktoś kontroluje
    jego pracę. Problem taki, że poprawność pracy pod względem
    inżnieryjnym może jedynie stwierdzić inny inżynier. Tak samo jest z
    programowaniem - raczej trudno oczekiwać, żeby kierownik firmy
    produkującj samochody albo elektrowni atomowej przejrzał kod programu
    i sprawdził, czy wątki są poprawnie synchronizowane.

    > Jak postawi ścianę krzywo - wywali go z pracy. A nawet, jak
    > murarz będzie miał wszelkie certyfikaty, to jak mu nie dadzą czasu,
    > złe cegły i nie będzie miał pomocnika, to i tak wykona robotę niskiej
    > jakości albo ew. zrezygnuje.

    No więc jeśli postawienie krzywo ściany będzie grozić utratą
    certyfikacji, to zrezygnuje. Z punktu widzenia bezpieczeństwa produktu
    zaleta tej sytuacji jest taka, że on, jako certyfikowany specjalista
    nie będzie się bał, że jak zrozygnuje, to nie znajdzie innej pracy, a
    z kolei biznesmenel jego zatrudniający będzie się bał, że jeśli go
    doprowadzi do rezygnacji nierealistycznymi wymaganiami, to będzie miał
    potem problem ze znalezieniem innego certyfikowanego specjalisty, a
    nawet jeśli takiego znajdzie, to ten inny specjalista też się raczej
    nie zgodzi na takie wymagania.

    > Jak pracodawca nie będzie czuł, że cała odpowiedzialność spoczywa na
    > nim, to zawsze znajdzie sobie łosi, którzy mu zrobią taką jakość, za
    > jaką zapłaci. Np. Ci młodzi, choćby i z tysiącami certyfikatów,
    > ale bez pracy - zrobią gówno, żeby mieć cokolwiek do wpisania w cv.

    Ale co z tego, że będą mieli wpisane w CV, skoro stracą prawo do
    wykonywania zawodu?

    Poza tym z tą odpowiedzialnością to jest fałszywa dychotomia:
    przedsiębiorstwo i tak odpowiada przed klientem. Co najwyżej może
    pozwać swojego pracownika za poniesione straty, ale to może zrobić i
    teraz. Sens certyfikacji nie jest taki, żeby w razie wybuchu było
    wiadomo, kogo obwinić, tylko żeby wybuchy zdarzały się rzadziej.

    No i w końcu: zazwyczaj proces certyfikacji obejmuje praktyki
    zawodowe, co jakby likwiduje problem kolesia, który nie ma nic w CV i
    zrobi wszystko, żeby mieć cokolwiek - po prostu koleś, który nie ma
    nic w CV, nie będzie miał również certyfikatu.

    Weź jeszcze pod uwagę, że pracodawca, to ne jest raczej osoba
    fizyczna, i jako taki nie może nic czuć. Czuć mogą coś przedstawiciele
    kadry kierowniczej w zatrudniającym przedsiębiorstwie, i wtedy
    powstaje pytanie, po pierwsze co zrobić z sytuacją, kiedy taki
    kierowni czuje, że w jego najlepszym interesie będzie działanie, które
    zwiększy ryzyko wybuchów. W tej chwili bardzo trudno będzie udowodnić
    w takiej sytuacji zaniedbanie, bo przecież to, co bezpośrednio
    spowodowało wybuch (powiedzmy niezainicjowana zmienna) leży poza
    zakresem kompetencji takiego kierownika. Po drugie, zakładając, że
    dany kierownik ma faktycznie jak najlepsze intencje, to przecież i tak
    nie jest w stanie sprawdzić, że w programie nie ma niezainicjowanej
    zmiennej, która spowoduje wybuch.

    > Wspomniałem o 'falach' po to, by uzmysłowić, że certyfikaty nie obronią
    > młodych ludzi przed wmanewrowaniem przez pazernego biznesmana w
    > zgniłe układy.

    Dadzą pewną ochronę choćby w ten sposób, że certyfikowanemu młodemu
    łatwiej będzie powiedzieć pazernemu biznesmenowi "wypchaj się"
    wiedząc, że znacznie łatwiej znajdzie pracę gdzie indziej (a z drugiej
    strony wiedząc, że jak gówno trafi w wentylator, to być może już nigdy
    nigdzie nie znajdzie pracy w tym zawodzie). Z drugiej strony, nawet
    zakładając brak efektu psychologiczno-motywacyjnego, będzie
    przynajmniej działać selekcje - im ktoś bardziej będzie podatny na
    wmanewrowanie, tym większe prawdopodobieństwo utraty certyfikacji na
    wczesnym etapie kariery, co spowoduje zmniejszenie odsetku łatwo
    manewrowalnych wśród populacji certyfikowanych.


  • 64. Data: 2012-03-20 12:22:47
    Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Andrzej Jarzabek <a...@g...com>

    On Mar 20, 8:39 am, zażółcony <r...@c...pl> wrote:
    > W dniu 2012-03-18 19:25, Edek Pienkowski pisze:
    >
    > Ale jeśli spojrzeć na to tak: w firmie nie było w ogóle
    > procesu testowania, ba, nie ma nawet wspólnych
    > repozytoriów kodów źródłowych, programiści kompilują
    > wersje produkcyjne bezpośrednio u siebie na komputerach
    > i wysyłają mailem do klienta... - to gdzie tu wina programisty ?

    1. Programista powinien wiedzieć, że należy używać kontroli wersji,
    2. Programista powinien wiedzieć, że oprogramowanie należy testować,
    3. To właśnie programista skompilował tę wersję i wysłał do klienta
    i tu właśnie jest wina programisty.


  • 65. Data: 2012-03-20 12:38:57
    Temat: Certyfikacja, było: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>

    W dniu 2012-03-20 13:22, Andrzej Jarzabek pisze:
    > On Mar 20, 8:39 am, zażółcony<r...@c...pl> wrote:
    >> W dniu 2012-03-18 19:25, Edek Pienkowski pisze:
    >>
    >> Ale jeśli spojrzeć na to tak: w firmie nie było w ogóle
    >> procesu testowania, ba, nie ma nawet wspólnych
    >> repozytoriów kodów źródłowych, programiści kompilują
    >> wersje produkcyjne bezpośrednio u siebie na komputerach
    >> i wysyłają mailem do klienta... - to gdzie tu wina programisty ?
    >
    > 1. Programista powinien wiedzieć, że należy używać kontroli wersji,

    Wygodnie jest używać, ale czy należy, tu pewnie zdania mogą być podzielone


    > 2. Programista powinien wiedzieć, że oprogramowanie należy testować,

    Autor programu jest najgorszym testerem z możliwych.

    > 3. To właśnie programista skompilował tę wersję i wysłał do klienta
    > i tu właśnie jest wina programisty.

    Czyli wychodzisz z założenia, że w firmie nie pracuje więcej niż kilka
    osób, skoro takimi rzeczami, jak wysyłka do klienta programu zajmuje sie
    programista...

    --
    Kaczus
    http://kaczus.republika.pl


  • 66. Data: 2012-03-20 12:40:02
    Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Andrzej Jarzabek <a...@g...com>

    On Mar 20, 9:30 am, Roman W <b...@g...pl> wrote:
    >
    > Programista w duzym projekcie moze po prostu nie byc w stanie ogarnac calosci i
    ocenic, czy projekt jest organizowany dobrze, czy zle.

    Nie zauważy, że nie używa source control?

    Poza tym w całej dyskusji o odpowiedzialności chodzi raczej o to, czy
    programista ma być odpowiedzialny, a nie o to, czy osoba kierująca
    projektem ma nie być odpowiedzialna.


  • 67. Data: 2012-03-20 12:56:25
    Temat: Re: Certyfikacja, było: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Andrzej Jarzabek <a...@g...com>

    On Mar 20, 12:38 pm, Tomasz Kaczanowski
    <kaczus@dowyciecia_poczta.onet.pl> wrote:
    > W dniu 2012-03-20 13:22, Andrzej Jarzabek pisze:
    >
    > > On Mar 20, 8:39 am, zażółcony<r...@c...pl>  wrote:
    > >> W dniu 2012-03-18 19:25, Edek Pienkowski pisze:
    >
    > >> Ale jeśli spojrzeć na to tak: w firmie nie było w ogóle
    > >> procesu testowania, ba, nie ma nawet wspólnych
    > >> repozytoriów kodów źródłowych, programiści kompilują
    > >> wersje produkcyjne bezpośrednio u siebie na komputerach
    > >> i wysyłają mailem do klienta... - to gdzie tu wina programisty ?
    >
    > > 1. Programista powinien wiedzieć, że należy używać kontroli wersji,
    >
    > Wygodnie jest używać, ale czy należy, tu pewnie zdania mogą być podzielone

    No to jeśli nie należy, to nie ma problemu, prawda?

    > > 2. Programista powinien wiedzieć, że oprogramowanie należy testować,
    >
    > Autor programu jest najgorszym testerem z możliwych.

    I tak i nie. Istnieje wiele rodajów testów, dla których programista
    jest najlepszym testerem swojego kodu (unit testy na przykład). Na
    pewno programista może częściowo skompensować niedostatki w
    zewnętrznym testowaniu przez przyjęcie i rygorystyczne stosowanie
    odpowiednich metodologii na swoim odcinku. Na pewno programista może
    również zgłosić swojemu przełożonemu, że uważa, że brak zewnętrznego
    testowania jest błędem. W końcu programista również może brać udział w
    exploratory testing całego produktu, w tym części napisanych przez
    innych programistów. Może też nakłaniać innych programistów do takiego
    testowania.

    > > 3. To właśnie programista skompilował tę wersję i wysłał do klienta
    > > i tu właśnie jest wina programisty.
    >
    > Czyli wychodzisz z założenia, że w firmie nie pracuje więcej niż kilka
    > osób, skoro takimi rzeczami, jak wysyłka do klienta programu zajmuje sie
    > programista...

    Nie wychodzę z założenia, tylko odpowiadam na takie założenie, z
    którego wyszedł Edek P.


  • 68. Data: 2012-03-20 13:22:14
    Temat: Re: Certyfikacja, było: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid>

    On 2012-03-20, Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> wrote:
    > W dniu 2012-03-20 13:22, Andrzej Jarzabek pisze:
    >> On Mar 20, 8:39 am, zażółcony<r...@c...pl> wrote:
    >>> W dniu 2012-03-18 19:25, Edek Pienkowski pisze:
    >>>
    >>> Ale jeśli spojrzeć na to tak: w firmie nie było w ogóle
    >>> procesu testowania, ba, nie ma nawet wspólnych
    >>> repozytoriów kodów źródłowych, programiści kompilują
    >>> wersje produkcyjne bezpośrednio u siebie na komputerach
    >>> i wysyłają mailem do klienta... - to gdzie tu wina programisty ?
    >>
    >> 1. Programista powinien wiedzieć, że należy używać kontroli wersji,
    >
    > Wygodnie jest używać, ale czy należy, tu pewnie zdania mogą być podzielone

    Rozmawiamy tu chyba o zawodowych programistach, a nie niedoukach?
    Opór przed systemem kontroli wersji widziałem jedynie u starych,
    zasuszonych administratorów ("przecież mogę sobie zrobić kopię na boczku
    i będzie to samo").

    >> 3. To właśnie programista skompilował tę wersję i wysłał do klienta
    >> i tu właśnie jest wina programisty.
    >
    > Czyli wychodzisz z założenia, że w firmie nie pracuje więcej niż kilka
    > osób, skoro takimi rzeczami, jak wysyłka do klienta programu zajmuje sie
    > programista...

    Ja to rozumiem inaczej: programista winny, bo nie on powinien wysyłać
    program i powinien o tym wiedzieć.

    --
    Secunia non olet.
    Stanislaw Klekot


  • 69. Data: 2012-03-20 13:32:15
    Temat: Re: Certyfikacja, było: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>

    W dniu 2012-03-20 14:22, Stachu 'Dozzie' K. pisze:
    > On 2012-03-20, Tomasz Kaczanowski<kaczus@dowyciecia_poczta.onet.pl> wrote:
    >> W dniu 2012-03-20 13:22, Andrzej Jarzabek pisze:
    >>> On Mar 20, 8:39 am, zażółcony<r...@c...pl> wrote:
    >>>> W dniu 2012-03-18 19:25, Edek Pienkowski pisze:
    >>>>
    >>>> Ale jeśli spojrzeć na to tak: w firmie nie było w ogóle
    >>>> procesu testowania, ba, nie ma nawet wspólnych
    >>>> repozytoriów kodów źródłowych, programiści kompilują
    >>>> wersje produkcyjne bezpośrednio u siebie na komputerach
    >>>> i wysyłają mailem do klienta... - to gdzie tu wina programisty ?
    >>>
    >>> 1. Programista powinien wiedzieć, że należy używać kontroli wersji,
    >>
    >> Wygodnie jest używać, ale czy należy, tu pewnie zdania mogą być podzielone
    >
    > Rozmawiamy tu chyba o zawodowych programistach, a nie niedoukach?
    > Opór przed systemem kontroli wersji widziałem jedynie u starych,
    > zasuszonych administratorów ("przecież mogę sobie zrobić kopię na boczku
    > i będzie to samo").

    Jak napisałem - wygodne narzędzie, ale wpływ na jakość kodu ma mały.
    Uczy co najwyżej pewnej systematyczności i pozwala przejrzeć
    wcześniejsze wersje (notabene backupy kilku zapisów wstecz często mają
    wbudowane narzędzia deweloperskie).

    >
    >>> 3. To właśnie programista skompilował tę wersję i wysłał do klienta
    >>> i tu właśnie jest wina programisty.
    >>
    >> Czyli wychodzisz z założenia, że w firmie nie pracuje więcej niż kilka
    >> osób, skoro takimi rzeczami, jak wysyłka do klienta programu zajmuje sie
    >> programista...
    >
    > Ja to rozumiem inaczej: programista winny, bo nie on powinien wysyłać
    > program i powinien o tym wiedzieć.

    Czyli wielkie pole do interpretacji "co autor miał na myśli". Jednak tu
    też certyfikacja nie ma znaczenia, co najwyżej system pracy w danej firmie.

    --
    Kaczus
    http://kaczus.republika.pl


  • 70. Data: 2012-03-20 13:34:34
    Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: zażółcony <r...@c...pl>

    W dniu 2012-03-20 13:15, Andrzej Jarzabek pisze:

    [....ciach...]
    Ok, ale my mówimy tak ogólnie, czy o szczególnych przypadkach ?
    ja nie mam nic przeciwko temu, by dajmy na to, taka Lufthansa
    zatrudniała wyłącznie ludzi z dyplomami i obarczała ich adekwatną
    odpowiedzialnością. Nie mówię, że firma nie powinna zatrudniać
    kilku projektantów, którzy kładą głowę i mają to jakoś umocowane
    w papierach - jak kierownik budowy czy architekt. Ale mówiliśmy,
    zdaje się, o szarych programistach klepiących kod ?

strony : 1 ... 6 . [ 7 ] . 8 ... 20 ... 23


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: