Jakiego kapelusza nie powinien nosić programista? [Zamknięte]

29

Z mojego doświadczenia wynika, że ​​twórcy oprogramowania noszą wiele czapek i pełnią różne role z różnymi obowiązkami. Od nie tylko kodowania, ale czasem pisania SQL, projektowania interfejsu użytkownika, projektowania bazy danych, manipulacji grafiką, a nawet testowania jakości.

Jeśli podstawową rolą jest pisanie oprogramowania / kodu, jakie role powinien przyjąć programista? Czy są jakieś?

Celem tego pytania nie jest to, że programista nie jest w stanie pełnić innej roli, ale posiadanie dodatkowej roli faktycznie działa wbrew głównej roli lub powinno być naprawdę dedykowaną rolą kogoś, kto nie programuje przede wszystkim.

gąbka
źródło
20
Czepek
21
IMO programista nie powinien nosić jednego z tych wielkich meksykańskich sombrer, ponieważ rondo wciąż waliłoby w monitor.
Mason Wheeler,
1
@Peter Turner: „Niesamowity kapelusz programisty” byłby jednym z tych nowatorskich zadań, w których montowane są dwie puszki po piwie. Tylko bez piwa. Czerwony Byk.
BlairHippo
4
Cholerny. Taki obiecujący tytuł ...
Nikt
4
@Mason, trzymanie sombrero nad monitorem ochroni przed odbiciami na błyszczących ekranach. Innymi słowy - technika.

Odpowiedzi:

54

Sysadmin. Opracowywanie oprogramowania i obsługa infrastruktury IT to dwa różne zestawy umiejętności, które wyglądają podobnie do osób postronnych. (To wszystko po prostu uderza w komputery, prawda?) Dla małej firmy pokusa będzie bardzo silna, aby sprawić, by Informatyk był odpowiedzialny za wszystkie maszyny w biurze.

Jeśli masz umiejętności, aby faktycznie nosić obie czapki, niesamowite; ale jest to jedna z tych rzeczy, które mogą być o wiele dłuższe niż ludzie sobie uświadamiają, a jeśli samouka podczas swojej drogi, prawdopodobnie nie radzą sobie zbyt dobrze.

BlairHippo
źródło
7
TO. Poważnie, to, że pracuję na komputerach, nie oznacza, że ​​mogę naprawić infrastrukturę. Po prostu marnujesz czas programistów.
Jaco Pretorius
5
+1 do obrażeń, które może zadać amatorski administrator systemu, jest ogromne.
davidtbernal
A jeśli dostaniesz czapkę sysadmin, mogą też przykleić ci czapkę kierownika obiektu, której należy unikać za wszelką cenę.
HLGEM
3
OTOH, pracuję w firmie z niezwykle niekompetentnym i powolnym działem IT. Czego bym nie dał, aby móc samodzielnie wprowadzić zmiany w zaporze ogniowej ...
Gabe Moothart
1
Ktoś zwrócił uwagę, że mój szef nie był wystrojony, ale powiedział im, że brudzi się z podłogi, konfigurując komputery. Wskazali na mnie, wskazując, że powinienem to zrobić. Prawie przeskoczyłem przez ich biurko i udusiłem je, ale wypiłem kawę i wspomniałem, że nie robię sprzętu.
JeffO
35

Nosisz kapelusz, o który prosi pracodawca. To sprawia, że ​​jesteś graczem zespołowym. To właśnie sprawia, że rozwiązujesz problem .

Ludzie są zbyt pochłonięci pomysłem bycia „deweloperem”, „architektem” lub „analitykiem”. Chrzanić to. Powinieneś być rozwiązaniem problemu. Kod to tylko narzędzie w twoim pasie.

Rozwiązywanie problemów nigdy nie wychodzi z mody.

Jeśli mój pracodawca chce, żebym zapewnił wsparcie techniczne lub zbudował komputery, niech tak będzie. Wydaje się, że marnują pieniądze, biorąc pod uwagę wynagrodzenie programistów, ale to ich sprawa. Jestem tutaj, aby rozwiązać problemy. Jakkolwiek mogę to zrobić, zrobię to. A jeśli po pewnym czasie czuję, że moje talenty są zmarnowane lub satysfakcja z pracy nie jest tam, gdzie chcę, to mam po prostu prawo do przejścia do innej pracy.

Ale podstawowe pytanie - nie ma kapelusza, którego nie nosisz. Cholera, jeśli chcą, żebyś przyniósł kawę, zrób to. Rozwiąż ich problemy; po prostu wiedz, że masz prawo znaleźć inną pracę, jeśli chcesz zmienić.

Chris Holmes
źródło
5
@Josh: Myślę, że byłaby to jedna z tych sytuacji „znajdź nową pracę”.
Adam Lear
21
Bądź z tym ostrożny. Szefowie zwykle wykorzystują chętnych do zrobienia czegokolwiek. Tylko upewnij się, że otrzymujesz właściwą rekompensatę.
Tony
5
Nie sądzę, że Chris mówi „rób cokolwiek” (cóż, na końcu jest trochę; nie przyniosę kawy każdemu, kto też nie przynosi mi drinków), ale „Jestem deweloperem, ja nie wymieniam wkładu drukarki ”to po prostu spryt.
Peter Boughton
10
Nie zgadzam się. Łatwo jest powiedzieć, że programista powinien być w stanie zrobić wszystko, o co poprosi, ale to nie znaczy, że POWINIEN. W takich sytuacjach powstają poważne problemy związane z konfliktem interesów. Nie chcę dostępu do systemów produkcyjnych, ponieważ będę obwiniony, gdy spadną („no cóż, XXX był tam w zeszłym miesiącu, więc jestem pewien, że coś pomieszał, ponieważ jest programistą, a nie administratorem”)
MBPon
7
-1; jest tutaj jądro prawdy, ale istnieją pewne surowe ograniczenia w tym sposobie myślenia, które ta odpowiedź nie wystarczy, aby uznać. A jeśli prawdziwym problemem jest to, że twój pracodawca jest do bani zarządzania personelem? Kiedyś widziałem upadek biura, ponieważ przełożeni nalegali, by inteligentni, zdolni inżynierowie wcielili się w role, których nienawidzili i bardzo źle sobie radzili. Są chwile, kiedy mówi się „nie!” jest najlepszą rzeczą, którą możesz zrobić zarówno dla siebie, jak i swojego pracodawcy.
BlairHippo,
29

Próbnik!

W razie potrzeby wyślij nam testerów bezpośrednio ze szkoły testera!

Bez testerów ludzie oczekują, że wszystko zadziała bez końca, ponieważ programista jest testerem i są bardzo inteligentni, więc powinno działać.

Nie twierdzę, że jedzenie psów nie jest dobrym pomysłem. Myślę, że testerzy są teraz bardzo ważni, kiedy jestem programistą.

Peter Turner
źródło
4
Dobrzy oddani testerzy są zdecydowanie niedoceniani!
Peter Boughton
3
Psie jedzenie!? Gotuję tylko pięciogwiazdkowego homara! ... i dlatego potrzebuję testera, który powie mi, kiedy coś spieprzę. Zrobiłem to i wiem, jak to działa. Nikt, kto stworzył interfejs użytkownika, nigdy nie jest uprawniony do dokładnego przetestowania go, po prostu dlatego, że wie, jak to działa, a nie jak działa z kimś, kto tego nie robi.
Morgan Herlocker
15
Nie ma nic złego w byciu testerem w ogóle. Błędem jest bycie jedynym testerem TWÓJ WŁASNY kod. Programiści kodują zestaw założeń, a jeśli tester ma identyczne założenia, nie wykonają nieoczekiwanych części i przegapią wiele błędów.
dbkk
5
Testowanie własnego kodu jest zdecydowanie dużym nie-nie. Programiści mogą obejmować wiele innych rzeczy, ale faktyczne testowanie funkcjonalne (jeśli nie przeprowadzasz testów jednostkowych, możesz nie być programistą) własnego kodu jest bardzo złym pomysłem. Karmienie z nim jest dobre, umyśle.
glenatron
3
+1 - programiści myślą wyraźnie inaczej niż nieprogramiści pod względem korzystania z programów. Czy kiedykolwiek odkryłbyś błąd w punkcie menu „Plik -> Zapisz”?
26

Powinieneś być ostrożny, aby stać się zwykłym facetem w przypadku problemów ze sprzętem biurowym . Może to obejmować rozwiązywanie problemów z komputerem, administrowanie serwerem, tworzenie kopii zapasowych, a nawet pracę systemu telefonicznego. Popełniłem błąd, wspominając o moim poprzednim doświadczeniu ze sprzętem i ostatecznie moje obowiązki związane ze sprzętem / rozwiązywaniem problemów poważnie kolidowały z moimi obowiązkami programistycznymi.

Jon Onstott
źródło
Powiedz winowajcom, że potrzebują pozwolenia od swojego szefa i zarejestruj się przez cały czas wykorzystywany do tego.
@Thor Kierunek pracy nad sprzętem - przyszedł - od mojego szefa. Było to pomocne dla biura, ale nie mogłem skoncentrować swojej kariery na programowaniu tak, jak bym wtedy chciał.
Jon Onstott,
@Jon, jeśli szef mówi, że musisz to zrobić, cóż ... musisz to zrobić. Możesz następnie omówić z nim, czy jest to satysfakcjonujące, czy nie, a jeśli nie możesz dojść do porozumienia, czas odejść.
+1 To samo mi się przydarzyło. Chcą, żebym nie tylko napisał kod, ale również zajął się problemami sieciowymi wraz z producentami przeglądającymi strony, co doprowadziło do dużego stresu.
Rich
16

Programista nie powinien być jedynym testerem własnego kodu .

Programiści piszą kod z zestawem założeń. Jeśli testerzy mają identyczny zestaw założeń, nie wykonają nieoczekiwanej funkcjonalności poza tymi granicami, a wiele problemów pozostanie niewykrytych.

Co więcej, aby posunąć się naprzód, deweloperzy nie mają silnej motywacji, by próbować coś zepsuć, podczas gdy testerzy (być może na poziomie podświadomości).

Nie oznacza to, że testy programistyczne są bezużyteczne. Wręcz przeciwnie - dobre testowanie przez programistów umożliwia testerom skupienie się na poszukiwaniu głębszych problemów. Jednak testy programistyczne nie zastępują dedykowanego testera.

dbkk
źródło
10

Dwa, o których mogę myśleć od samego początku.

  1. Wsparcie techniczne. Nie jestem tu po to, aby pomagać klientom w przejściu przez nową witrynę lub uczyć ich korzystania z funkcji.
  2. Chociaż może być konieczne komunikowanie się z klientami na różnych etapach procesu, chyba że jesteś programistą zarządzającym, tak naprawdę nie powinieneś bezpośrednio komunikować się z nimi na temat funkcji i implementacji projektu.

Można powiedzieć, że rozwój CSS / UI byłby poza „sferą programistyczną”, ale z mojego doświadczenia wynika, że ​​jest to dziś umiejętność niezbędna. Nie możesz po prostu uciec od tabel i polegać na kimś, kto je poprawnie zaimplementuje. Może nie podoba mi się wdrażanie projektu lub modyfikowanie kodu w celu obsługi nowego projektu, ale to część zadania.

Pisanie zapytań jest w porządku, testowanie Q / A jest w porządku (a IMO powinno być zadaniem programisty, mając do czynienia z działem zewnętrznym, ale najpierw powinieneś go przetestować). Administracja serwera to trochę szara strefa. W zależności od tego, jak duży jest projekt lub jeśli masz dedykowanego administratora serwera, może on być potrzebny.

Josh K.
źródło
7
Jeśli chodzi o punkt 2, istnieje co najmniej jedna firma, która opiera się na zasadzie, że osoba pisząca kod powinna rozmawiać bezpośrednio z klientem: dezintermediacja ma swoje zalety.
Frank Shearar
10

Ogólnie rzecz biorąc, z mojego doświadczenia wynika, że ​​większość programistów nie powinna rozwijać wyglądu interfejsu użytkownika - chociaż z pewnością jestem w stanie opracować interfejs użytkownika (i często go tworzyć podczas budowania prototypu lub dowodu koncepcji), to jest to lepiej pozostawić ludzkiemu czynnikowi (który w naszej małej firmie jest grafikiem, który również układa ekrany i tworzy większość podręczników i broszur).

Poza tym programiści nie powinni przeprowadzać testów zapewniania jakości - to jest zadanie działu kontroli jakości (firma, w której pracuję, produkuje wbudowane urządzenia medyczne, więc jest to wymóg, aby testy były wykonywane przez osobny dział).

Z drugiej strony nie widzę powodu, dla którego programiści nie mogą projektować baz danych i pisać SQL, jeśli mają do tego odpowiednie zaplecze - robiłem to wiele razy.

tcrosley
źródło
2
+1 Zgodził się, że testowanie jakości przez programistów, którzy go napisali, pokonuje cel.
gąbka
2
@JoshK Niektóre testy QA mogą być wykonywane przez programistów, ale główne testy QA powinny być wykonywane przez innych. Jeśli przetestujesz własną aplikację, którą napisałeś, podświadomie obejdziesz wszelkie potencjalne problemy. Chodzi o to, aby odkryć problemy, których programiści nie są w stanie znaleźć, rodzaj świeżego zestawu oczu, że tak powiem.
gąbka
2
@JoshK @ChaosPandion Zgodzono się, że niektóre wcześniejsze testy programistów powinny zostać wykonane - ale nie należy im ufać, a zatem osobne testy kontroli jakości przez tych, którzy go nie opracowali.
gąbka
5
-1: Nie zgadzam się, że programiści nie powinni projektować GUI. Pracuję przez 8 lat w małej firmie i zaprojektowałem cały interfejs użytkownika. Zawsze przestrzegałem doskonałych wytycznych projektowych firmy Microsoft i czytałem kilka książek o projektowaniu HMI. Zleciliśmy zewnętrznym ilustratorom wyłącznie grafikę.
Wizard79
3
Jedną z rzeczy, która mnie niepokoi, jest implikacja, że ​​osoba graficzna jest bardziej odpowiednia niż programista do projektowania interfejsów użytkownika. Być może twój grafik jest bardzo dobry w projektowaniu interfejsów, ale w ogólnym przypadku może przerodzić się w mylący, bezużyteczny, ładny interfejs w przeciwieństwie do mylącego, ledwo użytecznego, brzydkiego interfejsu, który dostaniesz od stereotypowego programisty.
David Thornley,
8

Wsparcie techniczne

Tak wiele mojego dnia jest marnowane, odbierając połączenia z pomocą techniczną ...

Niektóre popularne to:

  • „Moje konto jest zablokowane” lub „Nie pamiętam hasła”
  • „Mój [telefon | klawiatura | mysz | komputer] nie działa”
  • „Mój komputer działa wolno, czy możesz sprawdzić, czy jest coś niezwykłego?”
  • „Dlaczego X zdarza się, kiedy kliknę ten przycisk? Powinien to być Y”
  • „Ciągle otrzymuję te wyskakujące okienka ....” lub „Myślę, że mam wirusa”
  • „Tej osoby już nie ma, czy możesz wyłączyć wszystkie jej rzeczy?”
  • „Mamy nowego pracownika, czy możesz skonfigurować go przy użyciu loginu, karty bezpieczeństwa, numeru telefonu, e-maila itp.?”
Rachel
źródło
6

Każda rola, która zmusza go do samodzielnego zarządzania. W małych zespołach często występuje tendencja do mianowania jednego ze starszych programistów kierownikiem projektu, ale także utrzymywania go w zespole jako programisty. Prowadzi to do różnego rodzaju problemów, ponieważ ten facet, jako programista, jest zasadniczo niezarządzany. Zamiast delegować wszystkie zadania innym członkom zespołu, często kusi go przydzielenie wielu z nich, zwłaszcza najtrudniejszych. Tak więc najtrudniejsze zadania, które najprawdopodobniej powodują problemy, są przypisywane do osoby, która jest tylko w 50% dostępna jako programista i jako taka nie podlega nikomu. Kiedy inni członkowie zespołu nie są w stanie dostarczyć, zamiast skopać tyłek, spróbuje wykonać swoje zadanie, ponieważ jako kierownik projektu odpowiada za sukces, a najbezpieczniejszym sposobem na zrobienie tego jest zrobienie tego sam prawda?

użytkownik 281377
źródło
5

Wsparcie techniczne dla czegoś, czego nie miałeś ręki przy opracowywaniu, wdrażaniu lub utrzymywaniu, a także nie odbyłeś szkolenia i nie jesteś na bieżąco z ważnymi zmianami. Część mojej pracy polegała na odbiorze telefonu dla klientów dzwoniących z pytaniem, dlaczego ich internet nie działa. Nie zajmuję się tą połową biznesu, więc nie mogę im powiedzieć nic na temat pożytku.

Nie ma potrzeby korzystania z pomocy technicznej, z którą nie ma problemu. To bycie sekretarką / wsparciem technicznym podczas prób rozwoju.

To dość obciążające, że trzeba słuchać ludzi narzekających przez cały dzień i nie być w stanie im nic powiedzieć. Radzę unikać tego za wszelką cenę.

Tarka
źródło
Tak, opodatkowanie wymaga zmiany osobowości kilka razy w ciągu dnia. Trudno jest pracować nad zadaniami, które wymagają koncentracji, gdy ciągle ci przeszkadza.
Rich
5

Sprzedaży .

Niektóre biedne robale muszą to zrobić, ale na pewno nie powinni to być deweloperzy.

Dan Ray
źródło
4

W miarę, jak się starzeję, zdałem sobie sprawę, że jest to najlepsze, jeśli programiści nie wykonują własnych wdrożeń (walczyłem z tym jednym zębem i paznokciami). Nie powinni mieć żadnych praw do produkcyjnej bazy danych oprócz praw do wyboru. Nasz kod ma dużo mniej błędów (i to samo nie pojawiło się wiele razy, ponieważ zmiana została wprowadzona tylko w prod, a późniejsze wdrożenie dev nadpisało go ponownie, a następnie naprawiono tylko w prod w pośpiechu, płukaniu i powtórzeniu), kiedy musiał zacząć przekazywać go innym osobom do wdrożenia, a nie wolno im wprowadzać szybkich zmian produkcyjnych, ponieważ wdrożenie nie było w porządku. Ponadto przestaliśmy mieć te przypadkowe „aktualizacje bez wyróżnienia klauzuli where, które zmieniały każdy problem w tabeli”.

HLGEM
źródło
Tak, tak i tak. Nigdy nie zapewniaj programistom dostępu do produkcji i bardzo ograniczonego (a najlepiej żadnego) do inscenizacji. Jeśli nic innego nie zmniejsza stresu, na który są narażeni.
ElGringoGrande
1
Tak! Jestem programistą i nie chcę dostępu do wszystkich tych produkcji. A wraz z innymi osobami wdrażającymi oprogramowanie, jest to kolejny test procesu wdrażania. (I być może poprawi się także odzyskiwanie po katastrofie).
żal
3

Artysta i projektant interfejsu użytkownika .

Większość programistów jest bardzo słaba w grafice, ale firmy nie zadają sobie trudu, aby artysta rysował obrazy i ikony dla swoich produktów, a jedynie używa „sztuki programisty” - z ohydnymi rezultatami. (Do Windows Vista był to najbardziej oczywisty czynnik odróżniający komputery Mac od komputerów PC - komputery Mac wyglądały pięknie i przyjaźnie, komputery PC były odrażające)

Podobnie wielu programistów nie interesuje się interfejsem użytkownika - zależy im przede wszystkim na kodzie. Po prostu eksponują zawartość swoich zmiennych składowych bezpośrednio w niektórych polach edytowalnych, często nie dbając o to, gdzie umieszczają przyciski i pola w swoich formularzach i zakładają, że jest to wystarczające, co powoduje, że oprogramowanie nie nadaje się do użytku. (Cała branża telefonii komórkowej była tego bardzo winna, dopóki nie pojawił się iPhone, aby pokazać im, że możesz stworzyć interfejs telefonu, który byłby przyjemny w użyciu)

Lotus Notes jest świetnym przykładem tego, jak złe mogą być obie te rzeczy, jeśli nie otrzymasz profesjonalnego projektanta, który pomógłby programistom.

Jason Williams
źródło
2
„Większość programistów jest bardzo słaba w artwook” i „Wielu programistów nie jest bardzo zainteresowanych” to nie to samo, co „żaden programista nie jest zainteresowany” i „wszyscy programiści są źli”. Znam parę, która radzi sobie całkiem nieźle.
MIA,
1
@Jim Leonardo: Rzeczywiście. Dlatego powiedziałem „większość” i „dużo” zamiast „wszystko”. :-)
Jason Williams
3

Pisanie ogólnych testów i planów testów. Poważnie, chłopaki, mogę pisać własne plany testowe, ale to oznacza pieczenie w produkcie wszelkich nieporozumień, fałszywych założeń i błędów poznawczych, które popełniłem podczas pisania tego materiału. To była jedyna rzecz, której nienawidziłem w jednej firmie, w której pracowałem; gdzie jestem teraz, mamy przynajmniej recenzje kodu, które prawdopodobnie złapią to.

David Thornley
źródło
Tak, większość testów powinna być napisana obok specyfikacji, zanim utworzony zostanie jakikolwiek kod. Chociaż posiadanie przez programistę dodatkowych testów opartych na wiedzy o tym, czego dotknęli, nie jest złą rzeczą.
Peter Boughton,
3

Nigdy nie noś więcej „czapek”, niż możesz sobie z nimi poradzić i czujesz się swobodnie, próbując zaszufladkować twórców dziur, mówiąc, że nie powinni robić A lub B, oznacza, że ​​świetny projektant interfejsu użytkownika może pozostać niezauważony, ponieważ ktoś uważa, że ​​programiści powinni trzymać się z dala od interfejs użytkownika.

Pod koniec dnia każdy będzie miał różne mocne i słabe strony, a dobry menedżer / przełożony / lider zespołu powinien wiedzieć, jak najlepiej kierować ludźmi, którzy dla nich pracują, aby zapewnić odpowiednie wykorzystanie talentów. Podobnie, jeśli nie czujesz się komfortowo w projektowaniu interfejsów użytkownika lub kontaktach z użytkownikami końcowymi, daj znać zespołowi, abyś mógł zminimalizować swoją rolę w tym obszarze. Jednak powinieneś być przygotowany na podjęcie dodatkowej pracy w innym obszarze.

Ponadto, jeśli nosisz zbyt wiele czapek (np. Programista, projektant interfejsu użytkownika, tester, analityk biznesowy itp.), To albo będziesz źle sobie radził na niektórych z nich, albo się wypalisz. Upewnij się, że wiesz, ile czapek możesz obsłużyć, i staraj się utrzymać obciążenie na tym poziomie.

Poza tym tak naprawdę nie ma „czapek”, których twórca nie powinien nosić, jeśli mają umiejętności, które pozwolą mu odnieść sukces w tej roli.

rjzii
źródło
1

Zwykle podejmuję się każdej pracy, która jest mi rzucana, jeśli i tylko wtedy, gdy:

  • Ostrzegam z wyprzedzeniem o moim poziomie umiejętności i możliwych implikacjach, a mój szef decyduje, że jest to akceptowalne
  • Jest osoba na poziomie guru, która może (i prawdopodobnie na pewnym etapie) pomoże mi poradzić sobie z czymś nieoczekiwanym
  • Przeczytaj dokumentację, zadawane pytania online itp.

W ten sposób jestem w większości ubezpieczony od mojego szefa, a jeśli ktoś się pomyli, można to przynajmniej naprawić.

Audrius
źródło
1

Deweloperzy są zainteresowanymi stronami (takimi jak klienci, właściciele itp.), Więc mają prawo oczekiwać znaczącej pracy. Moim zdaniem oznacza to możliwość pracy ze swoimi mocnymi stronami .

Deweloper nie powinien więc nosić czapki, która nie energetyzuje, nie przyczynia się do rozwoju osobistego i prowadzi do szczytowej wydajności - i kradnie czas „czapkom”, które robią te rzeczy za nich.

Poza tym, że nie jest jedynym, który testuje własny kod, myślę, że każdy „kapelusz” jest w porządku, jeśli ma znaczącą pracę dla dewelopera noszącego ten kapelusz.

Ingvald
źródło
1

„Projektant” lub „kreatywny facet”. Przejdziesz od niewinnego tworzenia makiety interfejsu aplikacji do pisania tekstu marketingowego do następnej internetowej kampanii reklamowej lub niekończących się dyskusji na temat „właściwego” odcienia niebieskiego, zanim się zorientujesz x_x.

dzikie piki
źródło
0

ten kapelusz z puszkami piwa z boku ze słomką. zły pomysł, jeśli zostaniesz złapany.

edytować:

Oto kapelusz, którego nienawidzę, ale ma wielką nagrodę - to wielki znak dla mnie, który mówi, że jeśli to się zepsuje, to wszystko z Twojej winy ... ah, ale jeśli to dobrze, to ty, mój syn, jesteś dobrym chłopcem, którego wszyscy znamy są - teraz wróć do piwnicy ... dobry chłopak ... to wszystko.

Wina czapka.

Jasio
źródło