Jesteśmy inżynierami?

Osobiście uważam, że tak. Ale niektórzy nie:
http://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/

Co prawda inż. przed nazwiskiem mi jeszcze nie dodali, ale uważam, że tak, programiści są inżynierami. Ale spotkałem się z opiniami nawet wśród znajomych, że jak to tak inżynier informatyk jak ma praktycznie zerową odpowiedzialność, nie robi nic namacalnego tylko siedzi i klepie w klawiaturę w dodatku trzepie kasę jakby był królem, a np. na takim budownictwie to oni świat zmieniają, muszą mieć uprawnienia, być odpowiedzialni, harują przy projektach, to są prawdziwi inżynierowie! :P Mam wrażenie, przynajmniej opierając się o własne otoczenie, że inżynier programista ma mniej więcej podobną opinię co inżynier architekt :P

Programowanie komputerów to dziedzina na pograniczu inżynierii, sztuki, nauki i rzemiosła.

Brak odpowiedzialności? Brak formalnych procedur? Autor tego artykułu chyba nigdy nie pisał oprogramowania dla urządzeń medycznych albo lotnictwa.

Porównywanie liczby katastrof i usterek mostów, dróg, budynków jest mocno nie fair, bo stopień skomplikowania tychże w porównaniu z nawet przeciętnym projektem informatycznym jest dosyć niewielki, a z kolei stopień podobieństwa kolejnych "projektów" do siebie znacznie większy. Zresztą nawet mimo tego, w przeciętnym projekcie budowlanym w trakcie jego powstawania jest mnóstwo większych, bądź mniejszych błędów i ten "rygorystyczny proces" projektowania oparty na procedurach wypracowanych w ciągu wielu lat to chyba tylko w idealnym świecie. Dużo z tych błędów "wychodzi" dopiero po zbudowaniu konstrukcji czyli na etapie "testowania". A, no i jednak samoloty czasem spadają, silniki wybuchają, dźwigi się przewracają, a mosty zawalają. :P

"Co prawda inż. przed nazwiskiem mi jeszcze nie dodali, ale uważam, że tak, programiści są inżynierami" inżynierem jest ten kto ma inż. przed nazwiskiem jako tytuł zawodowy koniec i kropka. Teraz przyszła tako moda z angielskiego nazywanie funkcji inżynier systemów, inżynier bezpieczeństwa itp., ale to nie ma nic wspólnego z prawdziwym inż.

Zawsze mnie fascynuje przywiązanie ludzi do tytułów ("Kiedy możemy się nazwać programistami", "Co trzeba umieć żeby się nazwać seniorem", "Czy programiści to inżynierowie") tak jakby po zdobyciu danego tytułu kompetencje człowieka nagle automagiczne staną się "godne" tego tytułu.
Póki mi płacą godnie, dają interesujące projekty i to wszystko jest udokumentowane i widoczne na CV, to mogą mnie nazwać małpim klepaczem kodu.

Zdefiniuj co znaczy dane słowo, a dopiero potem pytaj czy jakaś osoba czy grupa spełnia warunki definicji. Jeśli rozumujemy w myśl polskiego prawa to inżynierem jest osoba z tytułem zawodowym inżyniera, nawet jeśli zajmuje się później malowaniem obrazów. Jeśli przyjmiemy luźną definicję inżyniera jako osoby rozwiązującej problemy z wykorzystaniem wiedzy technicznej i ścisłej, dobrych praktyk itd. - to pewnie część z nas jest, część nie w zależności od konkretnego zajęcia.

Rozumiem, gdy takie przywiązanie do nazw i słówek występuje u normalnych ludzi, ale programiści powinni wiedzieć czym jest typowanie, klasa i instancja.

Taki kod:

ja = "Marian Kowalski"
print(isinstance(ja,Inżynier))

będzie wywalał błąd "NameError: name 'Inżynier' is not defined", dopóki nie określisz czym ten inżynier jest :)

Niestety "przygoda" z przed kilku dni gdy inżynier "po informatyce" nie ogarniał podstaw mechaniki klasycznej tylko potwierdza, że pomiędzy IT, a "prawdziwymi" inżynierami jest przepaść.

@Krolik, ale też nie wszystkie projekty w IT to medycyna. Tak samo nie każdy budowlaniec stawia co tydzień elektrownię atomową. Ponad to poziom powtarzalności w IT jest chyba nawet większy niż w budownictwie, bo warunki otoczenia są mniej zmienne. Jak miałbym to jakoś porównać to zmienność warunków w IT będzie na poziomie "wykończeniówki" w budownictwie. Klient ma durne pomysły, a ty się użerasz ze szczegółami. Samo stawianie ścian jest proste i przyjemne.

nie, jestesmy magikami

Z Wikipedii: "An engineer is a practitioner of engineering, concerned with applying scientific knowledge, mathematics, and ingenuity to develop solutions for technical, societal and commercial problems. Engineers design materials, structures, and systems while considering the limitations imposed by practicality, regulation, safety, and cost."

Jako że jest to definicja zupełnie inna niż ta występująca w języku polskim, ten artykuł nie ma zastosowania w kontekście nazwy wątku. Musisz wyjaśnić co masz na myśli, bo inaczej będziesz dostawał tak pomieszane odpowiedzi jak obecnie.

Niestety "przygoda" z przed kilku dni gdy inżynier "po informatyce" nie ogarniał podstaw mechaniki klasycznej tylko potwierdza, że pomiędzy IT, a "prawdziwymi" inżynierami jest przepaść.

U mnie na informatyce troche ludzi sie przenioslo na wydzial mechaniczny / budownictwo po pierwszym semestrze bo nie lapali programowania. Czego ma to niby dowodzic?

Ale spotkałem się z opiniami nawet wśród znajomych, że jak to tak inżynier informatyk jak ma praktycznie zerową odpowiedzialność, nie robi nic namacalnego tylko siedzi i klepie w klawiaturę w dodatku trzepie kasę jakby był królem, a np. na takim budownictwie to oni świat zmieniają, muszą mieć uprawnienia, być odpowiedzialni, harują przy projektach, to są prawdziwi inżynierowie!

Gdyby nie bylo tych krolow, to by panowie prawdziwi inzynierowie dalej robili obliczenia na kartkach papieru.
A jak wyglada w rzeczywistosci praca prawdziwego inzyniera? Niedawno byl temat 4p pod tytulem jak sie przekwalfikowac na programiste :D

Wg standardów amerykańskich to każdy kto pracuje w IT i umie obsługiwać komputer jest inżynierem. Ja jak coś czytam po angielsku to już się przyzwyczaiłem, że u nich engineer to po polsku to, co się zwie "osobą techniczną" w firmach (w odróżnieniu od osób nietechnicznych, czyli np. panie z HRu).

Natomiast obawiam się, że w języku polskim nazywanie się inżynierem bez studiów technicznych (a nie każdy programista musi je mieć w końcu) mogłoby spotkać się z co najmniej niezrozumieniem, o ile nie wyśmianiem ("jak to ktoś jest inżynierem, skoro nie ma dyplomu?").

Pytanie tylko co oznacza to słowo, czy raczej "co chcemy żeby oznaczało". O ile uważam, że programowanie można nazwać czasem inżynierią (np. jak mówimy o odpowiednim zaprojektowaniu złożonej aplikacji, o opracowaniu odpowiedniej koncepcji, o metodykach itp. czyli o tym wszystkim co wykracza poza zwykłe "klepanie") to jednak nazywanie każdego i w każdej sytuacji inżynierem (tak jak to się robi w USA - czyli każdy klepacz kodu - inżynier). To trochę przesada i groteska. Przynajmniej po polsku. Cięzko mi określić, czy to po angielsku też brzmi śmiesznie. Może oni się przyzwyczaili.

Zawsze mnie fascynuje przywiązanie ludzi do tytułów ("Kiedy możemy się nazwać programistami", "Co trzeba umieć żeby się nazwać seniorem", "Czy programiści to inżynierowie") tak jakby po zdobyciu danego tytułu kompetencje człowieka nagle automagiczne staną się "godne" tego tytułu.

Rozróżniłbym słowa inżynier a inżynieria.
O ile "inżynieria" (czy choćby "architektura") niesie ze sobą jakąś treść (inżynieria oprogramowania, architektura oprogramowania) i wg mnie są to całkiem w porządku metafory na to co robimy, to przyklejanie łatek ludziom w ten sposób (inżynier, architekt) łatwo może się stoczyć w kierunku groteski, np. tu są opisy inżynierów HTMLa:
http://learningpath.org/articles/HTML_Engineer_Career_Summary.html
http://grupy-dyskusyjne.money.pl/junior;xml;and;html;engineer,post,899982.html

swoją drogą jedna z tych ofert to polska oferta. Widocznie i do nas trafił ten dziwny trend.
XD

Zresztą nawet po polsku mamy konserwatora powierzchni płaskich xD to mniej więcej w tym stylu.

Swoją drogą - całkiem ciekawe, że nie krzyczą o:

Sanitation Engineer

Bo to znaczy tyle, co śmieciarz, czy tam "bin man".

Dawniej moja mama mówiła ty nic nie robisz tylko siedzisz przed tym komputerem :P

Teoretycznie, inżynierami sa ludzie, którzy maja to magiczne inż. przed nazwiskiem, tak jak profesorem, czy doktorem jest osoba posiadająca odpowiednio tytuł prof. czy dr.

Myślę jednak, ze bycie inżynierem to nie tylko to. To sposób myślenia. Zdolności analityczne, umiejętność rozwiązywania problemow. abstrakcyjnego myślenia, kreatywność, itd.

jak mowili radzieccy inzynierowie : wszystko ma wymiar

jak to sie tyczy programistow ?

no moze tych co robia gry 3d

@addicted ale to się tyczy tylko radzieckich inżynierów :/

Koziołek napisał(a):

Niestety "przygoda" z przed kilku dni gdy inżynier "po informatyce" nie ogarniał podstaw mechaniki klasycznej tylko potwierdza, że pomiędzy IT, a "prawdziwymi" inżynierami jest przepaść.

Szczerze mówiąc, osobiście zawsze wolałem poświęcać czas marnotrawiony na kwestie zupełnie mi zbędne w kontekście pracy zawodowej na pogłębianie wiedzy z zakresu, który dotyczy mojego (wtedy przyszłego) zawodu - czyli programowania i kwestii powiązanych z tym tematem. Skończyłem studia inżynierskie, projektuję kwestie związane z modelem, bazą, tworzę oprogramowanie dla różnych branż, projekty są coraz większe, moja odpowiedzialność również...ten czas, w ramach którego mogłem poznawać tajniki pędu, tranzystorów, matematyki dystretnej i innych odległych bezpośrednio od zawodowego programowania dziedzin, poświęciłem na dogłębne poznawanie systemów operacyjnych, tudzież zagadnień związanych z pracami frontendowymi, dzięki czemu moja praca w coraz większym wymiarze przypomina pracę osoby określającej się mianem full stack developer.

Teraz mnie przekonaj, że daleko mi do miana prawdziwego inżyniera, a moje podejście było błędne :) Równie dobrze mogę powiedzieć, że co to za inżynier który nie ogarnia podstaw programowania - czyli dziedziny, która w zasadzie jest aktualnie szalenie ważna we wszelkich innych dziedzin, których przedstawicieli możemy nazwać "prawdziwymi" inżynierami. Tak więc z takiego wykwalifikowanego budowlańca żaden inżynier. Moim zdaniem takie podejście jest archaiczne, gdzieś z czasów sprzed epoki komputerów, gdzie inżynier albo miał kontakt z maszynami elektrycznymi, albo tez z budowlanką, a inne branże inżynierskie były w powijakach. Tak jak mi nie jest potrzebna zabawa diodami (o ile nie zacznie mnie to rajcować), tak też inżynierowi budownictwa absolutnie zbędna jest wiedza z zakresu programowania.

Mówiąc o inżynierze w sensie stricte naukowym, trzeba rozróżnić dwie kwestie:
W USA nie ma tytułu naukowego inżynier jako engineer. Inżynier to u nich Bachelor of Engineering czyli licencjat inżynierii. Inżynier informatyk to Bachelor of Science in Computer Science (licencjat informatyki).

Gość chyba spisał to, co chodzi mi po głowie od jakichś dwóch lat. Ale do rzeczy.

Oczywistym jest, że angielskojęzyczny tekst o inżynierach zamieszczony na angielskojęzycznym portalu nie dotyczy polskiego systemu szkolnictwa wyższego, więc nie ma po co dyskutować tutaj o polskich dyplomach i polskich studiach.

Będę pisał o typowych programistach, którzy zajmują się pisaniem crudów, usług sieciowych, portali, parserów danych z LHC czy satelitów, nie o tych z branży medycznej czy kilku innych, które faktycznie stosują CERTYFIKATY JAKOŚCI i dużo bardziej rygorystyczne podejście do niezawodności oprogramowania, jak np. FORMALNE METODY DOWODZENIA POPRAWNOŚCI. (Druk oznacza rzeczy charakterystyczne dla inżynierii, które generalnie przy programowaniu miejsca nie mają.)
Będę też pisał o inżynierach po pierwsze zgodnie z definicją tego słowa, a nie polskim tytułem zawodowym udzielanym przez uczelnie wyższe, więc nie o inżynierach dietetyki czy matematyki (a są w Polsce ludzie z takimi tytułami!).

Inżynier to ogólnie mówiąc osoba, która zajmuje się projektowaniem, konstruowaniem i utrzymywaniem w działaniu: maszyn, przyrządów i procesów technologicznych. To, co łączy wszystkich inżynierów, to to, że ich praca jest ograniczona prawami fizyki, a do budowy swoich wytworów używają rzeczywistych materiałów. To rodzi różne problemy:

1. Jeśli zrobią coś głupiego mogą się okaleczyć albo nawet zginąć.
2. Nie mogą powiększać swoich produktów poprzez rozciąganie albo kopiowanie i doklejanie. To po prostu nie zadziała, albo nie będzie funkcjonalne.
3. Nie mogą tworzyć niczego siłowo; próbując wykonać coś, a potem przerabiając w nieskończoność. Muszą najpierw przemyśleć, potem zaprojektować, na końcu wykonać. To dotyczy także prototypów.
4. Nie zbudują niczego nowego sklejając ze sobą kilka kopii poprzednich wytworów.
5. Jeśli coś okazuje się za mało efektywnie zaprojektowane, to nie poprawią tego poprzez tanią zmianę infrastruktury.
6. Muszą optymalizować użycie materiałów, których używają do wytwarzania.
7. Ich praca wymaga wiedzy teoretycznej i obliczeń matematycznych.
8. Kształcą się na uczelniach, bo inaczej się nie da.

A programiści?

1. Najgłupsza rzecz może spowodować co najwyżej restart komputera.
2. Jeśli trzeba dodać nową, podobną funkcję, to wystarczy skopiować kod i zmienić w nim kilka rzeczy. Kod jest bytem wirtualnym, nic nie ogranicza jego rozmiaru.
3. Nie działa? Wystarczy zamienić dwie instrukcje miejscami i spróbować uruchomić znowu. I tak do skutku, to nic nie kosztuje.
4. Kod powiela się właściwie za darmo.
5. System zbyt wolny? To trzeba dołożyć kolejny serwer, proste.
6. Kod jest darmowy, można go wytworzyć ile się chce. Kopiuje się za darmo.
7. Chyba komentować nie trzeba.
8. Wszystkiego można nauczyć się z internetu. (Szkoda tylko, że mało kto robi to dobrze.)

Z uwagi na oparcie na prawach fizyki i właściwościach realnych materiałów, dyscypliny inżynieryjne mają solidne i niezmienne podstawy. (Np. nie zbuduje się silnika spalinowego z płatków kukurydzianych.) A programowanie? Kiedyś był modny service locator, waterfall i logika biznesowa w procedurach składowanych. Teraz są inne mody (chociaż wielu ze starych jeszcze nie wyrosło), równie absurdalne i równie bezmyślnie stosowane. Za pięć lat może wrócą tamte, a może będą inne.

W programowaniu nie ma fizyki, więc dowolnie głupi pomysł da się wykonać i ma szanse jakoś zadziałać (przynajmniej na maszynie developerskiej, bo na produkcji niekoniecznie). Gdyby samochody były projektowane tak, jak wiele systemów informatycznych, to karoseria byłaby wypełniona ziemniakami, silnik znajdowałby się na holowanej przyczepce, a kierowca siedziałby tyłem do kierunku jazdy na dachu, trzymając w reku wiosła.

U większości programistów nie występuje w ogóle inżynierskie podejście do rozwiązywania problemów, jest za to kompletny brak krytycznego i twórczego myślenia. Panuje powszechne kopiowanie kodu z SO bez próby jego zrozumienia, brak sceptycyzmu w stosunku do przyswajanej wiedzy, nieodpowiednie stosowanie przykładów z dokumentacji i tutoriali, ślepe podążanie za modami.
Prosty przykład na dowód - zdawałoby się dość proste wzorce projektowe, takie jak repozytorium i MVC są zazwyczaj używane niepoprawnie. 95% "programistów" tworzy "generyczne repozytoria" i wpycha logikę biznesową do kontrolerów, bo "model to baza danych", a poza tym tak było w tutorialu... No, a przecież niemożliwe, żeby ktoś w internecie wypisywał głupoty.

Większość ludzi w branży, to nawet nie są programiści tylko robotnicy konkretnej technologii. Znają jeden framework, potrafią w nim naklepać aplikację, a potem następną i następną. Oczywiście, wszyscy gadają o rozwoju... I rozwijają się, głównie w ramach tej technologii, który już znają. (No cóż, w końcu nauka tego, co już się umie, jest dużo bardziej efektywna i satysfakcjonująca. ) Dla większości programistów najważniejsze jest naklepanie kodu spełniającego przypadek użycia (przepraszam, zapomniałem, że teraz w modzie jest Agile) user story - mało kto myśli o architekturze, o jakości kodu, o wydajności aplikacji. A później mamy efekty w postaci pełnego błędów, niewydajnego i nierozwijalnego oprogramowania.

I taki stan niechlujstwa będzie trwał, póki procesy wytwarzania oprogramowania nie przestaną być marketingowymi okrzykami, póki jakość kodu nie będzie pustym hasłem z ogłoszeń o pracę, póki nie stanie się oczywiste, że do danego typu problemu należy użyć takiej architektury, a nie innej. Ale dopóki te rzeczy się nie zmienią, inżynieria oprogramowania pozostanie jedynie smutnym żartem, a programiści inżynierami nie będą.

somekind napisał(a):

1. Najgłupsza rzecz może spowodować co najwyżej restart komputera.

Słyszałeś kiedyś o NASA Mars Climate Orbiter lub Ariane-5? Podobnych przykładów jest jeszcze kilka..

@somekind, trzy uwagi:

1. Tak jak zaznaczyles sa branze gdzie bledy w kodzie moga meic bardzo powazne konsekwnecje.
2. Nawet przy klepaniu CRUDow zrobienie babola moze spowodowac potezne straty finansowe dla firmy.
3. Jest jedna istotna roznica: jesli inzynier buduje most, nikt mu nie zmienia koncepcji co tydzien (wie pan, ten most to jednak chcielismy wiszacy, do tego zapomnielismy powiedziec ze na srodku powinny byc tory zarowno tramwajowe jak i kolejowe, na srodku mostu przydalaby sie tez stacja benzynowa, aha i zamiencie ten asfalt ktory jest wylany na beton. Jest tez zla wiadomosc, musimy most oddac o polowe szybciej niz to bylo planowane) i nie dorzuca codziennie wrzutek na wczoraj.

A tak poza tym ja sie nie czuje inzynierem bo nie mam tytulu inz. przez co przynajmniej kilka lat temu niektore zawody byly dla mnie zamkniete (chocby rzeczoznawca od nieruchomosci).

ale chyba nawet przy projektach maszyn są testy, przy budynkach są odbiory, więc to chyba też nie jest na zasadzie- "włączmy i zobaczymy co się stanie"
a co kosztów błędów programistów to przykład z życia błąd w update firmware dysków plextora uceglił kilka tysięcy SSD, a z kolei sterownikach AMD palił rdzenie kart :)

Odnosnie kosztow nieudanych projektow IT: https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects

A ja teraz we własne gniazdo nasram, ale... Zgadzam się z @Koziołek że koderom brakuje często szeroko rozumianej kultury technicznej. Czy to będzie mechanika, czy elektryka czy może chemia podstawy warto mieć, ew. wiedzieć gdzie ich szukać, to raz.
Dwa: czy inżynierem jest facet klepiący odtwórczo formatki? Co ta praca wnosi? Jak to rozwija? Bo śmiem twierdzić, że raczej zwija. O patologicznej sytuacji na rynku pracy, gdzie w 90% dyplom uczelni wyższej do niczego nie byłby potrzebny ale jest moda to nawet nie chcę mi się zanadto rozgadywać, bo trochę po branżach poskakałem i wiedzy ze studiów używałem jedynie w trakcie pracy naukowej podczas studiów doktoranckich. W każdym innym przypadku wystarczyłoby technikum/liceum/minimalne zacięcie majsterkowicza. Pracodawcy najwyraźniej mieli o tym inne zdanie. Efekt był taki, że kur..ca, przepraszam, licho mnie brało na wysiadywaniu dupogodzin i oglądaniu kotów w sieci, a potem zdziwienie czemu pracę zmieniam.

BTW - teraz pracuję w branży, gdzie na skutek buga mogę uśmiercić kilkaset osób. Nie odczuwam szczególnej presji, bo poziomów kontroli jakości jest nade mną bazylion. Gorzej, że możliwości rozwoju są ograniczone przez dość sztywne struktury korporacyjne. Pytanie czy tłukąc crudy miałbym większe.
BTW - chyba coś za coś, kolega ze studiów ma b. fajną robotę i zakresu obowiązków mu zazdroszczę (projektowanie i certyfikowanie elektroniki iskrobezpiecznej). Gość faktycznie jest inżynierem pełną gębą. Tyle, że stosunku odpowiedzialność/wypłata mogę co najwyżej współczuć.

shagrin napisał(a):

Słyszałeś kiedyś o NASA Mars Climate Orbiter lub Ariane-5? Podobnych przykładów jest jeszcze kilka..

Słyszałem. Ale nie słyszałem, aby jakikolwiek programista zginał podczas wykonywania swojej pracy. Jak masz linki, to zarzuć, chętnie się zapoznam.

WhiteLightning napisał(a):

@somekind, trzy uwagi:

1. Tak jak zaznaczyles sa branze gdzie bledy w kodzie moga meic bardzo powazne konsekwnecje.
2. Nawet przy klepaniu CRUDow zrobienie babola moze spowodowac potezne straty finansowe dla firmy.

Ale za czym to argumenty, bo nie rozumiem?
Traktorzysta, operator żurawia, kosmetyczka, kucharka, czy bankowiec, też mogą spowodować potężne straty finansowe, i nie czyni ich to inżynierami.

3. Jest jedna istotna roznica: jesli inzynier buduje most, nikt mu nie zmienia koncepcji co tydzien (wie pan, ten most to jednak chcielismy wiszacy, do tego zapomnielismy powiedziec ze na srodku powinny byc tory zarowno tramwajowe jak i kolejowe, na srodku mostu przydalaby sie tez stacja benzynowa, aha i zamiencie ten asfalt ktory jest wylany na beton. Jest tez zla wiadomosc, musimy most oddac o polowe szybciej niz to bylo planowane) i nie dorzuca codziennie wrzutek na wczoraj.

Ta... bo niespodziewane zmiany są tylko w programowaniu.
Prosty przykład - przy zakupie mieszkania można sobie zażyczyć inny układ pomieszczeń w mieszkaniu. Ktoś przecież musi to przeprojektować i nadzorować wykonanie.
Kilka przykładów z branży automatyki przemysłowej:

• nie da się w danej chwili kupić wybranych komponentów do budowy zaprojektowanej maszyny, więc trzeba na szybko coś przeprojektować, żeby pasowały części od innego dostawcy;
• klient kupił innego robota niż było ustalone, trzeba przerabiać linię produkcyjną aby pasowała do jego rozmiaru;
• upadł inny podwykonawca, klient oczekuje, że przejmiemy wykonanie jego części hali;
• posadzka okazała się wykonana z twardszego betonu niż miała być, nie da się wywiercić otworów pod kotwy do naszego robota.

Nie chce mi się dalej wymieniać, ale problemy z klientami są chyba w każdej branży, a w przypadku prawdziwej inżynierii dochodzą jeszcze problemy powodowane przez naturę albo inne elementy rzeczywistego świata.

He he he... somekind a czy nie jest tak, ze masz #boldup, bo skonczyles jakas szkole lansu, masz kota, brak kobiety i nie masz tytulu inz i to Ci przeszkadza i wiesz podsiwadomie, ze jestes gorszy dlatego musisz udawac twardego zawodnika na forum? :D