Takie tam gadanie. Jestem właśnie takim full-stackiem, który stawia apki od backendu przez frontend, mobilki po infrastrukturę i deployment. Szukam nowej roboty od 6 miesięcy i nadal wszystkie softwarehousy chcą tylko super wyspecjalizowanych ludzi. Konkretny język, konkretny framework, jak nie jesteś ekspertem w tej konkretnej rzeczy, to odpadasz. Trzymam kciuki, żeby faktycznie było tak, jak mówicie.
Soft sam pisać się nie będzie, ale osoby które ten soft piszą (o ile mają odpowiedni poziom doświadczenia), będą w stanie pisać soft szybciej - widzimy to po sobie. 100% pisanie softu przez AI to temat raczej bardzo odległy. Pozdro, Adam Polak
Niestety z AI da się szybko zrobić coś co działa ale już niekoniecznie jest optymalne czy w łatwy sposób rozszerzalne - to po pierwsze. Po drugie - czasami dostaniemy podpowiedź, która w ogóle jest sprzeczna z dokumentacją. Oczywiście do przetarcia szlaku jest okej, w wielu przypadkach pozwala osiągnąć efekt ale możemy skończyć z nierozszerzalnym codebase w pewnym momencie. AI nie przechodzi typowej ścieżki rozwojowej, on zlepia kawałki kodu. Może wkleić jakieś API przestarzałe i zblendować to z czymś nowszym. To tak jakby mieć różne wersje bibliotek, bo de facto to jest w źródle danych. Wiedza w AI jest ale nie każdy temat ma taką samą datę aktualności. Osobnym aspektem jest to, że ktoś kto nie ma ogólnego doświadczenia z programowaniem, nie jest w stanie ocenić słuszności danego rozwiązania. To, że coś daje oczekiwany w danym momencie efekt, nie oznacza, że się odpowiednio skaluje i nie wybuchnie na przykład ze względu na nieuwzględnione zależności w docelowym środowisku. Mało tego... czasami pozornie coś wydajniejszego niekoniecznie jest najwydajniejsze na danym środowisku. Przykładem może być technika Hardware Occlusion Queries, gdzie chcąc renderować scenę raz, renderujemy ją raz w bardzo niskiej jakości i patrzymy jakie obiekty są widoczne, by nie renderować ich w docelowej jakości. Inny przykład to kompresja stratna - naszym celem pozornie jest przeniesienie idealnego odwzorowania a algorytm finalny degraduje jakość w taki sposób, by była niezauważalna dla człowieka - przykład kodek MP3. Podsumowując, przez AI operujemy na nieliniowo podwyższonej abstrakcji, co może powodować brak wglądu w to jak działa biblioteka, której używamy czy nawet całe klasy, które napisaliśmy z pomocą AI. To trochę jak z kuciem notatek, tylko na nie patrząc versus pisanie ściągi, która dziwnym trafem nie przydaje się na egzaminie, bo lepiej zapamiętaliśmy jej treść.
Dlatego mówimy, że obecne rozwiązania AI to nie jest coś skierowanego do juniorów, tylko bardziej element który w rękach dobrego programisty potrafi odblokować go w innych obszarach. W tej chwili, o ile ktoś nie ma szerszego doświadczenia, bazowanie tylko na AI na bank nic nie da. Pozdro, Adam Polak
@@TshIo to znaczy nie tyle nic nie da, co czasem wpędzi w ślepą uliczkę. Mam wrażenie też, że jeszcze do niedawna była taka postawa wśród managerów. Wepchnęli by najchętniej model językowy do bzdur typu sprawdzenie czy liczba jest liczbą pierwszą :) Inna sprawa, że wiązanie stawianie swojego biznesu na OpenAI to trochę jak stawianie domku z kart. Jeden niespodziewany podmuch i po ptakach.
Co sądzicie o narzędziach no-code i low-code? rozumiem że deweloperzy są przeciwni ale wydaje mi się że coraz szerzej się rozpychają i będzie się mocno rozwijać w najbliższym czasie..no i wiadomo hype na AI rośnie :)
Pierwsze 10 minut określą chyba 80 procent aktualnych ogłoszeń o prace dla branży. Mamy coś dla Ciebie jak masz w swojej skrzynce z narzędziami 2-4 języki i otwarta głowę na inne technologie (nie znaczy nowe!). Stąd jak nie masz 7 lat doświadczenia to Ci dziękujemy!
Każdy kij ma dwa końce ;) Są oferty które są przesadą, ale są też takie, które skupiają się doświadczeniu (które nie musi być liczone w latach, tylko np. w jakimś tam jednym projekcie). Pozdro, Adam Polak
Cześć! Na początek polecamy odcinki: #9 ruclips.net/video/xZ7BLbhkQSM/видео.html #25 ruclips.net/video/3BiUZ4KBF5M/видео.html #27 ruclips.net/video/HGApphbk6fU/видео.html Ale nie ukrywamy, że chyba nadeszła pora, żeby wrócić do tematu i spojrzeć na niego z aktualnej perspektywy!
@@TshIo dziękuję za odpowiedź W obecnych czasach rzeczywiście warto by odświeżyć temat Ja interesuje cię rekrutacja, podesłać wam może tematy do filmiku?
@@profx53 pewnie, zapraszamy na podcast@tsh.io, na pewno weźmiemy pod uwagę Twoje pytania, gdy zdecydujemy się nagrać odcinek o takiej tematyce. :) Pozdro!
Do tej pory określałem sie jako frontaś. Skoro i tak pracuję rowniez w środowisku Node i PHP to do CV juz lepiej wpisać fullstack? (Mimo, ze w papierach mam FE) 🤔
Jeżeli praca w środowisku oznacza że naprawdę dodajesz jakieś elementy kodu do backendu - a nie tylko że jesteś w projekcie z nimi - to jak najbardziej bym szedł w tym kierunku. Tutaj musisz pamiętać, że CV musi pokazywać co potrafisz, a nie tylko co miałeś w projekcie. Jeżeli miałeś Cobola, ale nie napisałeś tam nawet linii kodu/omijałeś tę część jak największym łukiem... to lepiej nie wpisuje że znasz Cobola, bo na rozmowie takie coś zweryfikujemy. ;) Pozdro, Adam Polak
❤ zdroworozsadkowe podejscie. Ja sam nastawiam sie juz na freelancing w przyszłości. Dodam do tego co powiedzieliscie, ze inwestor nie chce juz miec armii 10 devow. Chce 5 a 5 z doskoku jak ma wyzszy demand na produkcje kodu
Pierwsze 10 min to typowy dzień pracy w każdej firmie w której do tej pory miałem styczność. Mimo specjalizacji frontendowej robi się wszystko backend, migracje, optymalizacje, testy a nawet uxy
Obejrzałem i naszła mnie refleksja że już teraz nie można być specjalistą tylko generalistą kapiącym doświadczenie. Myślę że przewagę będą miały osoby które będą w stanie stworzyć sobie armię agentów AI i RAG do bazy wiedzy. Wtedy wszystkie taski i problemy były rozwiązywane w locie. Patrząc na postęp modeli LLM szczególnie lokalnych myślę że będzie to kwestia czasu, kiedy makietę aplikacji będzie sobie tworzył pracownik w biurze a programiści będą tylko po to żeby usprawnić komponenty ale tylko jeśli będzie na to budzet. Nie uważam to za nic złego bo właśnie pracownik najlepiej zna swój proces.
To ja od 2020r (jak zaczynałem pierwszą pracę jako dev C#), trafiałem do jakiś dziwnych firm i teraz się okazało, że to były firmy z przyszłości 😱 Dla mnie to nie nowość robić wszystko (rozmowa z klientem, front, back, DB, test, deploy, wdrożenie, serwis, dokumentacja). Ale jest jeden minus takiego rozwiązania, w porównaniu do kogoś kto typowo programuje Backend w C# - ja nie mam startu, to są ludzie którzy obudzeni w środku nocy potrafią wymienić różnice między C# 10 a C# 11, a ktoś kto się zajmuje wszystkim umie wszystko ale po łebkach.
Sam pamiętam jak byłem webmasterem (strasznie lubię to słowo), ale wtedy stawiało się Wordpressa. Uważam, że niemożliwe jest dzisiaj w dużych projektach przyjąć taką rolę. Chyba że mówimy o małych aplikacjach bez nacisku na jakość.
Dowolna aplikacja pisana obecnie to kwestia rozpisania jej na ficzery i zbudowanie odpowiednich podwalin, aby móc te ficzery dodawać. Design system, boilerplate frontu/backendu, platform engineering - tak długo, jak masz składowe do budowy tych aplikacji dodawanie ficzerów to nic innego jak komponowanie/wykorzystywanie pewnych elementów. W zespole dalej masz osoby, które są mocnym frontem, mocnym backendem, mocnym devopsem, ale jednocześnie nie boją się wziąć odpowiedzialności za pozostałe części danego zadania. Masz dodać kolejny modal, który po kliknięciu buttona zrobi X - jeżeli jesteś backendem, to backend robisz bez zająknięcia, frontend bazuje już na czymś, a do CR dodajesz fronta. Jak jesteś frontem, to robisz front bez zająknięcia, a backend bazuje na istniejących endpointach/domenie - do CR dodajesz backenda. Brzmi niemożliwie, ale działa i to nie u nas, a u wielu naszych klientów. ;) Pozdro, Adam Polak
Daje to jeszcze jeden ogromny plus dla developerów, a mianowicie pozwala im się rozwijać i ciągle uczyć czegoś nowego. Moim zdaniem to jest jeden z najważniejszych elementów w pracy programistów. A chwilowe wychodzenie z tzw. "strefy komfortu" mocno stymuluje do nauki. ;) Pierwsze CSS-y dla backendowca będą katorgą, tak samo, jak robienie endpointów na backendzie przez fronta. Jednak po kilku razach robimy to automatycznie i mierzymy się z kolejnymi wyzwaniami w "nieswojej" części aplikacji rozwijając swoje kompetencje przy każdym kolejnym kawałku kodu. Najważniejsze, żeby jednak spróbować się odnaleźć w czymś nowym i mieć wsparcie od kolegów z zespołu - potem to już jakoś idzie. ;) Pozdro, Andrzej Wysoczański
Spoko, tylko że jak ktoś 95% czasu przez 3-4 lata dostaje taski tylko z tej wąskiej działki, to jak ma trzymać sensowny poziom kompetencji w obszarze z którym de facto nie pracuje, a wszystko się zmienia. Troche albo rybki albo akwarium.
I tak jest obecnie. Czy tak będzie za 3-4 lata? To co obserwujemy na rynku pokazuje, że raczej nie. Dostajesz teraz taski tylko z backendu? Może warto rzucić temat, że chciałbyś sprobować coś z DevOps/Frontend? Masz taski tylko z frontu? Poproś o coś z backendu. Wykaż się inicjatywą i chęcią sprobowania czegoś innego. Pozdro, Adam Polak
Ja obawiam się, że backendowiec kręcił ten podcast. Widać to przede wszystkim w kadrach rodem z Mr. Robot gdzie osoba mówi poza kard, a nie do środka kadru. To mi pokazuje wyraźnie, że rola backendowca i frontendowca nadal powinna być podzielona, gdyż backendowiec po prostu zrobi, ale experiance dla użytkownika będzie o wiele gorszy. To samo tyczy się tego, że frontendowiec nie zrobi dobrego backendu. Nie ma fullstacków. Są nieliczne jednostki, ale uważam, że nie da się nauczyć dobrego frontendu i dobrego backendu.
Fullstack to nie ninja - nie musi być tak samo dobry w backendzie, frontendzie, devopsie, AI, ML. Musi potrafić wykonać zadania z innych obszarów, które zazwyczaj bazują na czymś już istniejącym, a jednocześnie był dobrym w innym obszarze. Od tego w zespole są osoby ze specjalizacja backend, aby robić CR backendu, analogicznie osoby specjalizujące się we froncie aby robić CR frontu (często też UX/UI aby ocenić czy implementacja to jest coś co będzie wyglądać dobrze ;)). Pozdro, Adam Polak
"braża" it, ai, ioioio w skrócie Ciągłe zatrudnienie to jest dla menedżerów i wzwyż dla ciebie areczku to jest ciągle zmieniana narracja jak się nam podoba a twoje doświadczenie to do ostatniego projektu reszta się nie liczy. Taki mądry jesteś to swojego hausa załuż i swój zarząd areczku.
Ja bym się bał oddać frontowe taski backendowcom. Po pierwsze ich podeście od lat do frontendu jest wiadomo "fontend to nie programowanie". Brak żadnego wyczucia stylu. Jest coś przesunięte... a olać to. Nie! Frontend to osobne stanowisko które wymaga empatii i wyczucia smaku.
tak samo działa to w drugą stronę - raczej żaden backendowiec nie będzie szczęśliwy jak przypadnie mu zaszczyt pracować/rozwijać/poprawiać backend pisany przez frontendowców. Dodatkowo uważam, że kategorycznie nie można nazywać fullstackiem kogoś kto jest specjalistą w swojej dziedzinie (backend/frontend) i jednocześnie "z pomocą AI" oraz czasu jest w stanie coś podłubać w kodzie "po drugiej stronie barykady". Dla mnie fullstack to osoba, która czuje pasję i zaangażowanie do obu stron barykady (frontendu i backendu) w podobnym stopniu, a nie jest backendowcem który potrafi z pomocą AI nadłubać jakiś koszmarny komponent w Reactie, albo frontendowcem, którzy przy wsparciu AI wyklepie jakiś paskudny endpoint. Jakby na to nie spojrzeć - nazywanie fullstackiem takiej osoby to abberacja i trywializowanie frontu/backu (zależnie od punktu widzenia).
@dzienisz Od tego jest CR i zapewnienie odpowiedniego poziomu procesu jakości, aby takie sytuacje wyłapywać i eliminować. Przykładowo - do każdego taska gdzie jest backend, frontend, devops przypisujemy do CR osoby z tych specjalizacji / eksperckości aby wskazały jak to powinno wyglądać/działać. Każdy task frontowy w naszym procesie ma wymagane wstawienie screenshotów/filmików z działania - tak aby było widać jak to wygląda/działa. Pozdro, Adam Polak
@coder_one tak i nie. Bądźmy realistami - czucie zaangażowania i pasji po obu stronach barykady ma sens tylko wtedy kiedy ktoś naprawdę jest one man army i ma samemu cały projekt ciągnąć. Realia są takie że w projekcie jest więcej osób i nie jest tak że mamy tyle samo zadań na front, devops, backend, a jednocześnie trzeba takie rzeczy wykonać. Ludzie też naturalnie będą szli w kierunku rzeczy które w danym momencie ich interesują - a to właśnie buduje specjalizacje, która na przestrzeni czasu może się zmieniać. Developer dojrzały to taki który robi to co jest potrzebne w produkcie, a nie tylko to co w danym momencie zgadza się z tym co go interesuje. I właśnie to z naszego doświadczenia zmienia mocno definicję fullstacka - która kiedyś była dokładnie taka jak piszesz - w kierunku osoby która ma pewną ekspertyzę, ale nie boi się wejść w inne obszary (bo taka jest potrzeba produktowa). Pozdro, Adam Polak
Jak najbardziej o ile nie wchodzi my w AI w formie ML - trenowanie/budowanie modelów. Obecnie narzędzia AI rozwinęły się do tego stopnia (i to nawet po tym jak nagraliśmy ten odcinek), że budowanie RAG staje się co raz łatwiejsze - gotowe moduły, SDK przygotowane do wykorzystania innych baz. Pozdro, Adam Polak
Akurat tutaj nie mowimy o SH (pomimo że sami jesteśmy z SH), tylko o sytuacji na rynku w firmach produktowych. Od +/- roku jest bardzo mocno widoczny trend, aby w projekcie pojawiały się osoby które nie boją się brać zadań z innej działki. Pozdro, Adam Polak
@@Foryal w USA może polecą. W Polsce nie polecą. Polecam Forbes sobie w necie poczytać. Inflacja w Polsce się utrzymuje i rada polityki pieniężnej na pewno szybko stóp procentowych nie obniży.
@@Foryal jak ja nie lubię takiego pierdololo w stylu mordo do obcej osoby. Beznadziejna mania jakaś. Mnie natomiast nie interesuje w ogóle rynek amerykański, mimo, że świetnie wiem o tym, że gospodarka jest światowa i to co się dzieje na Wall Street ma odzwierciedlenie też w Europie, a także w Polsce. Patrzę spokojnie na Microsoft, który zwalnia, bo to podnosi ceny akcji. Patrzę na innych, też zwalniają. Patrzę na to, że inwestują w energię atomową, żeby rozwijać AI w skrócie, chociaż w zasadzie to są po prostu algorytmy i struktury danych. Prawda jest taka, że kilku dobrych seniorów z pomocą modeli LLM opierdzieli frontend, backend, zrobi testy i puści deployment na produkcję. Dokładnie tak. Jak ktoś jest dobry i ogarnia, to co ja, albo więcej, to sam to zrobi. Wystarczy zbudować odpowiednie środowisko. Po co armia ludzi? Bez sensu. Każdy, kto się na tym zna, wie, że tak właśnie jest. Czeka nas robotyzacja i automatyzacja. Nie od razu, ale stopniowo. Ford Henry zautomatyzował produkcję samochodów. Automatyzacja zwiększa bezrobocie. To jest oczywiste. Mniej zatrudnionych to większe oszczędności. To prosty rachunek.
W skrócie: Areczku, co prawda dostaniesz sporo mniej kasy, ale będziesz musiał zapieprzać jeszcze za kolegów, których zwolniliśmy. Masz AI do pomocy więc nie marudź.
Realia są takie, że do niedawna niewiele firm interesowało się efektywnością i tym, czy ich proces developmentu realnie ma sens (co naprawdę doprowadziło do sytuacji że mamy role od wszystkiego, a zespołu się rozrosły niemiłosiernie) - więc… trochę jest tak jak mówisz, ale tylko od strony że osób będzie mniej, roboty tyle samo i teraz pytanie jak sprawić, aby to poukładać (np. można wywalać część spotkań ;)).
@@TshIo Myślę, że w tych nowych warunkach warto rozważyć przestawienie w naszym regionie domyślnej długości scrumowego sprintu z 14 dni na np. 10. Wtedy więcej tasków się każdemu wciśnie. Niestety dla koderów oznaczałoby to, że prawdopodobnie będzie trzeba robić też w soboty i niedziele. Niestety trudne czasy wymagają większych poświęceń. Ale z drugiej strony to szansa na szybszą naukę i sprawniejszy rozwój. Inaczej w średniej perspektywie przegramy konkurencję z zasobami ludzkimi ze wschodu i dalekiego południa. Pozdrawiam 😉
Eeee tam zaraz zapieprzać za kolegów, jeśli dobrze pracowali to raczej dalej są z tobą w projekcie. Gorzej, jeśli ci koledzy robili na przysłowiowe "pół gwizdka". ;) Pozdro, Andrzej Wysoczański
Jak dla mnie, jeśli Areczek zostaje sam, 2 innych jest niepotrzebnych, to Areczek ma więcej pracy, ale też może liczyć na trochę więcej PIENIĄŻKÓW. Takie realia realistyczne są, bez jaj. Czyli w sumie nieźle dla Areczka. I nie, że konkurencja, bo przecież takich doświadczonych nie jest chyba dużo.
Jestem ciekaw jakie firmy chciały zatrudniać Full-Stacków, z mojego doświadczenia było tak że: pisze pan w technologii X no to tylko tym jesteśmy zainteresowani a to że chce Pan robić więcej to to nas nie obchodzi to nie robił Pan tego w poprzedniej formie i nie ma Pan doświadczenie w tym
Wszystko zależy od firmy. Są jeszcze takie które tego trendu nie widzą, są natomiast takie które już teraz otwarcie będą informować, że dobrze aby kandydat miał doświadczenie w czymś innym. Tu dalej każdy będzie miał jakąś swoją wąską specjalizacje - nie chodzi o to aby zrobić mityczną one man army, ale o to aby móc efektywnie developować bez blokad - w postaci nieobecności, urlopów etc. I nie musieć specjalnie skalować zespołów tylko dlatego że od teraz będziemy mieli do robienia więcej frontu niż backendu ;) Pozdro, Adam Polak
Taki fullstack może brać odpowiedzialność za cały feature. Jeżeli proces w projekcie jest do tego dostosowany, to można tym o wiele łatwiej zarządzać. I tak jak Adam powiedział, to bardzo zależy od konkretnego przypadku, natomiast widzimy, co się dzieje na rynku i tych zmian prowadzących do wdrażania/zatrudniania/uczenia fullstacków jest co raz więcej. Czy ten trend się utrzyma? Czas pokaże. Pozdro, Andrzej Wysoczański
@@TshIo zobaczymy co przyniesie AI i automatyzacja pracy - moje produkcje są takie że fillstacku będą teraz w cenie i dzieki chatGPT czy tym podobnym tworom procesy programowanie będzie którzy i prostszy
@@TshIo [inny temat] właśnie tak teraz pomyślałem o temacie na nowy filmik: czy planujecie zrobić odcinek o rynku analizy danych (analitycy danych, raportowanie, data science) Teraz jest duży hype na data science.i ciekawy jestem czy warto w to iść
Tu nie chodzi aby kogoś nauczyć w rok wszystkiego - chodzi o to aby zacząć eksponować ludzi na rzeczy z poza ich działki. Zaczyna się od rzeczy prosty - fixowanie jakiś prostych bugów, robienie prostych zmian na interfejsie/infrze/dodawania endpointów które będą bazować na innym kodzie. Dopiero potem przechodzi się do budowania całego projektu takim a nie innym teamem (do tego dodaje się wsparcie w postaci kogoś doświadczonego w tym obszarze). Zrobiliśmy to już wielokrotnie u nas - działa. Pozdro, Adam Polak
@@dzienisz da się. W rok może nie, ale w trzy do pięciu już tak. Ja ogarniam i front, którego nie lubię, ale jak muszę to wiadomo i backend, który lubię dużo bardziej. Jestem QA DevOps expert. Jednak nie nazwę siebie full stack, bo full to naprawdę sporo narzędzi. Swoją drogą tak w zasadzie to nie lubię programować i jak mogę, korzystam z obecnych rozwiązań, by jak najwięcej kodu pisało się samo, a ja tylko sprawdzam, czy jest poprawnie i bzdur nie ma, a potem testuję, czy działa.
niesamowite, jak panowie na to wpadli? zmniejszmy zespol o polowe i oczekujmy ze beda dowozili to samo bo nazwiemy ich fullstack ze wskazaniem na BE/FE xDDDDDD I jeszcze te gadanie że developrzy przestana robić błędy jak sobie "wezmą do serca" coś. Panowie handlowcy, serio super kabaret robicie.
Takie tam gadanie. Jestem właśnie takim full-stackiem, który stawia apki od backendu przez frontend, mobilki po infrastrukturę i deployment. Szukam nowej roboty od 6 miesięcy i nadal wszystkie softwarehousy chcą tylko super wyspecjalizowanych ludzi. Konkretny język, konkretny framework, jak nie jesteś ekspertem w tej konkretnej rzeczy, to odpadasz. Trzymam kciuki, żeby faktycznie było tak, jak mówicie.
Uważam, że Management został otumaniony AI i wydaje im się, że teraz soft sam się będzie pisał. To marzenie wprost z utopii. Tak nie będzie.
Soft sam pisać się nie będzie, ale osoby które ten soft piszą (o ile mają odpowiedni poziom doświadczenia), będą w stanie pisać soft szybciej - widzimy to po sobie.
100% pisanie softu przez AI to temat raczej bardzo odległy.
Pozdro,
Adam Polak
Niestety z AI da się szybko zrobić coś co działa ale już niekoniecznie jest optymalne czy w łatwy sposób rozszerzalne - to po pierwsze.
Po drugie - czasami dostaniemy podpowiedź, która w ogóle jest sprzeczna z dokumentacją. Oczywiście do przetarcia szlaku jest okej, w wielu przypadkach pozwala osiągnąć efekt ale możemy skończyć z nierozszerzalnym codebase w pewnym momencie. AI nie przechodzi typowej ścieżki rozwojowej, on zlepia kawałki kodu. Może wkleić jakieś API przestarzałe i zblendować to z czymś nowszym. To tak jakby mieć różne wersje bibliotek, bo de facto to jest w źródle danych. Wiedza w AI jest ale nie każdy temat ma taką samą datę aktualności.
Osobnym aspektem jest to, że ktoś kto nie ma ogólnego doświadczenia z programowaniem, nie jest w stanie ocenić słuszności danego rozwiązania. To, że coś daje oczekiwany w danym momencie efekt, nie oznacza, że się odpowiednio skaluje i nie wybuchnie na przykład ze względu na nieuwzględnione zależności w docelowym środowisku. Mało tego... czasami pozornie coś wydajniejszego niekoniecznie jest najwydajniejsze na danym środowisku. Przykładem może być technika Hardware Occlusion Queries, gdzie chcąc renderować scenę raz, renderujemy ją raz w bardzo niskiej jakości i patrzymy jakie obiekty są widoczne, by nie renderować ich w docelowej jakości. Inny przykład to kompresja stratna - naszym celem pozornie jest przeniesienie idealnego odwzorowania a algorytm finalny degraduje jakość w taki sposób, by była niezauważalna dla człowieka - przykład kodek MP3.
Podsumowując, przez AI operujemy na nieliniowo podwyższonej abstrakcji, co może powodować brak wglądu w to jak działa biblioteka, której używamy czy nawet całe klasy, które napisaliśmy z pomocą AI. To trochę jak z kuciem notatek, tylko na nie patrząc versus pisanie ściągi, która dziwnym trafem nie przydaje się na egzaminie, bo lepiej zapamiętaliśmy jej treść.
Dlatego mówimy, że obecne rozwiązania AI to nie jest coś skierowanego do juniorów, tylko bardziej element który w rękach dobrego programisty potrafi odblokować go w innych obszarach.
W tej chwili, o ile ktoś nie ma szerszego doświadczenia, bazowanie tylko na AI na bank nic nie da.
Pozdro,
Adam Polak
@@TshIo to znaczy nie tyle nic nie da, co czasem wpędzi w ślepą uliczkę. Mam wrażenie też, że jeszcze do niedawna była taka postawa wśród managerów. Wepchnęli by najchętniej model językowy do bzdur typu sprawdzenie czy liczba jest liczbą pierwszą :)
Inna sprawa, że wiązanie stawianie swojego biznesu na OpenAI to trochę jak stawianie domku z kart. Jeden niespodziewany podmuch i po ptakach.
Czy moglibyście wrzucić link do artykulu i prezentacji o którycn mówicie na początku?
hej, koniecznie podpinajcie linki do wspomnianych źródeł, pomoże to bardzo, dzięki
newsletter.pragmaticengineer.com/p/zirp-engineering-practices :)
Co sądzicie o narzędziach no-code i low-code? rozumiem że deweloperzy są przeciwni ale wydaje mi się że coraz szerzej się rozpychają i będzie się mocno rozwijać w najbliższym czasie..no i wiadomo hype na AI rośnie :)
a myslisz ze kto sklada apki w tych narzedziach low code jak nie developerzy własnie
Pierwsze 10 minut określą chyba 80 procent aktualnych ogłoszeń o prace dla branży. Mamy coś dla Ciebie jak masz w swojej skrzynce z narzędziami 2-4 języki i otwarta głowę na inne technologie (nie znaczy nowe!). Stąd jak nie masz 7 lat doświadczenia to Ci dziękujemy!
Każdy kij ma dwa końce ;) Są oferty które są przesadą, ale są też takie, które skupiają się doświadczeniu (które nie musi być liczone w latach, tylko np. w jakimś tam jednym projekcie).
Pozdro,
Adam Polak
Mam propozycję: proponuję zrobić odcinek o rekrutacji i o tym czego potrzebują firmy i coś o biznesie
Cześć!
Na początek polecamy odcinki:
#9 ruclips.net/video/xZ7BLbhkQSM/видео.html
#25 ruclips.net/video/3BiUZ4KBF5M/видео.html
#27 ruclips.net/video/HGApphbk6fU/видео.html
Ale nie ukrywamy, że chyba nadeszła pora, żeby wrócić do tematu i spojrzeć na niego z aktualnej perspektywy!
@@TshIo dziękuję za odpowiedź
W obecnych czasach rzeczywiście warto by odświeżyć temat
Ja interesuje cię rekrutacja, podesłać wam może tematy do filmiku?
@@profx53 pewnie, zapraszamy na podcast@tsh.io, na pewno weźmiemy pod uwagę Twoje pytania, gdy zdecydujemy się nagrać odcinek o takiej tematyce. :) Pozdro!
Do tej pory określałem sie jako frontaś. Skoro i tak pracuję rowniez w środowisku Node i PHP to do CV juz lepiej wpisać fullstack? (Mimo, ze w papierach mam FE) 🤔
Jeżeli praca w środowisku oznacza że naprawdę dodajesz jakieś elementy kodu do backendu - a nie tylko że jesteś w projekcie z nimi - to jak najbardziej bym szedł w tym kierunku.
Tutaj musisz pamiętać, że CV musi pokazywać co potrafisz, a nie tylko co miałeś w projekcie. Jeżeli miałeś Cobola, ale nie napisałeś tam nawet linii kodu/omijałeś tę część jak największym łukiem... to lepiej nie wpisuje że znasz Cobola, bo na rozmowie takie coś zweryfikujemy. ;)
Pozdro,
Adam Polak
❤ zdroworozsadkowe podejscie. Ja sam nastawiam sie juz na freelancing w przyszłości. Dodam do tego co powiedzieliscie, ze inwestor nie chce juz miec armii 10 devow. Chce 5 a 5 z doskoku jak ma wyzszy demand na produkcje kodu
Freelancing może być ryzykowny... Zresztą cholera wie co nie będzie...
Cursor, Void IDE, clean coder na Github - perełka. Chatgpt spoko. Copilot też spoko.
Pierwsze 10 min to typowy dzień pracy w każdej firmie w której do tej pory miałem styczność. Mimo specjalizacji frontendowej robi się wszystko backend, migracje, optymalizacje, testy a nawet uxy
Obejrzałem i naszła mnie refleksja że już teraz nie można być specjalistą tylko generalistą kapiącym doświadczenie. Myślę że przewagę będą miały osoby które będą w stanie stworzyć sobie armię agentów AI i RAG do bazy wiedzy. Wtedy wszystkie taski i problemy były rozwiązywane w locie. Patrząc na postęp modeli LLM szczególnie lokalnych myślę że będzie to kwestia czasu, kiedy makietę aplikacji będzie sobie tworzył pracownik w biurze a programiści będą tylko po to żeby usprawnić komponenty ale tylko jeśli będzie na to budzet. Nie uważam to za nic złego bo właśnie pracownik najlepiej zna swój proces.
To ja od 2020r (jak zaczynałem pierwszą pracę jako dev C#), trafiałem do jakiś dziwnych firm i teraz się okazało, że to były firmy z przyszłości 😱
Dla mnie to nie nowość robić wszystko (rozmowa z klientem, front, back, DB, test, deploy, wdrożenie, serwis, dokumentacja).
Ale jest jeden minus takiego rozwiązania, w porównaniu do kogoś kto typowo programuje Backend w C# - ja nie mam startu, to są ludzie którzy obudzeni w środku nocy potrafią wymienić różnice między C# 10 a C# 11, a ktoś kto się zajmuje wszystkim umie wszystko ale po łebkach.
Historia lubi się powtarzać!
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀🧚🧚♂🧚♀🧞🧞♂🧞♀
Sam pamiętam jak byłem webmasterem (strasznie lubię to słowo), ale wtedy stawiało się Wordpressa. Uważam, że niemożliwe jest dzisiaj w dużych projektach przyjąć taką rolę. Chyba że mówimy o małych aplikacjach bez nacisku na jakość.
Dowolna aplikacja pisana obecnie to kwestia rozpisania jej na ficzery i zbudowanie odpowiednich podwalin, aby móc te ficzery dodawać.
Design system, boilerplate frontu/backendu, platform engineering - tak długo, jak masz składowe do budowy tych aplikacji dodawanie ficzerów to nic innego jak komponowanie/wykorzystywanie pewnych elementów.
W zespole dalej masz osoby, które są mocnym frontem, mocnym backendem, mocnym devopsem, ale jednocześnie nie boją się wziąć odpowiedzialności za pozostałe części danego zadania. Masz dodać kolejny modal, który po kliknięciu buttona zrobi X - jeżeli jesteś backendem, to backend robisz bez zająknięcia, frontend bazuje już na czymś, a do CR dodajesz fronta. Jak jesteś frontem, to robisz front bez zająknięcia, a backend bazuje na istniejących endpointach/domenie - do CR dodajesz backenda.
Brzmi niemożliwie, ale działa i to nie u nas, a u wielu naszych klientów. ;)
Pozdro,
Adam Polak
Daje to jeszcze jeden ogromny plus dla developerów, a mianowicie pozwala im się rozwijać i ciągle uczyć czegoś nowego. Moim zdaniem to jest jeden z najważniejszych elementów w pracy programistów. A chwilowe wychodzenie z tzw. "strefy komfortu" mocno stymuluje do nauki. ;)
Pierwsze CSS-y dla backendowca będą katorgą, tak samo, jak robienie endpointów na backendzie przez fronta. Jednak po kilku razach robimy to automatycznie i mierzymy się z kolejnymi wyzwaniami w "nieswojej" części aplikacji rozwijając swoje kompetencje przy każdym kolejnym kawałku kodu.
Najważniejsze, żeby jednak spróbować się odnaleźć w czymś nowym i mieć wsparcie od kolegów z zespołu - potem to już jakoś idzie. ;)
Pozdro,
Andrzej Wysoczański
Spoko, tylko że jak ktoś 95% czasu przez 3-4 lata dostaje taski tylko z tej wąskiej działki, to jak ma trzymać sensowny poziom kompetencji w obszarze z którym de facto nie pracuje, a wszystko się zmienia. Troche albo rybki albo akwarium.
I tak jest obecnie. Czy tak będzie za 3-4 lata? To co obserwujemy na rynku pokazuje, że raczej nie.
Dostajesz teraz taski tylko z backendu? Może warto rzucić temat, że chciałbyś sprobować coś z DevOps/Frontend?
Masz taski tylko z frontu? Poproś o coś z backendu. Wykaż się inicjatywą i chęcią sprobowania czegoś innego.
Pozdro,
Adam Polak
Ja obawiam się, że backendowiec kręcił ten podcast. Widać to przede wszystkim w kadrach rodem z Mr. Robot gdzie osoba mówi poza kard, a nie do środka kadru. To mi pokazuje wyraźnie, że rola backendowca i frontendowca nadal powinna być podzielona, gdyż backendowiec po prostu zrobi, ale experiance dla użytkownika będzie o wiele gorszy. To samo tyczy się tego, że frontendowiec nie zrobi dobrego backendu. Nie ma fullstacków. Są nieliczne jednostki, ale uważam, że nie da się nauczyć dobrego frontendu i dobrego backendu.
Fullstack to nie ninja - nie musi być tak samo dobry w backendzie, frontendzie, devopsie, AI, ML. Musi potrafić wykonać zadania z innych obszarów, które zazwyczaj bazują na czymś już istniejącym, a jednocześnie był dobrym w innym obszarze.
Od tego w zespole są osoby ze specjalizacja backend, aby robić CR backendu, analogicznie osoby specjalizujące się we froncie aby robić CR frontu (często też UX/UI aby ocenić czy implementacja to jest coś co będzie wyglądać dobrze ;)).
Pozdro,
Adam Polak
"braża" it, ai, ioioio w skrócie
Ciągłe zatrudnienie to jest dla menedżerów i wzwyż dla ciebie areczku to jest ciągle zmieniana narracja jak się nam podoba a twoje doświadczenie to do ostatniego projektu reszta się nie liczy. Taki mądry jesteś to swojego hausa załuż i swój zarząd areczku.
Ja bym się bał oddać frontowe taski backendowcom. Po pierwsze ich podeście od lat do frontendu jest wiadomo "fontend to nie programowanie". Brak żadnego wyczucia stylu. Jest coś przesunięte... a olać to. Nie! Frontend to osobne stanowisko które wymaga empatii i wyczucia smaku.
tak samo działa to w drugą stronę - raczej żaden backendowiec nie będzie szczęśliwy jak przypadnie mu zaszczyt pracować/rozwijać/poprawiać backend pisany przez frontendowców.
Dodatkowo uważam, że kategorycznie nie można nazywać fullstackiem kogoś kto jest specjalistą w swojej dziedzinie (backend/frontend) i jednocześnie "z pomocą AI" oraz czasu jest w stanie coś podłubać w kodzie "po drugiej stronie barykady".
Dla mnie fullstack to osoba, która czuje pasję i zaangażowanie do obu stron barykady (frontendu i backendu) w podobnym stopniu, a nie jest backendowcem który potrafi z pomocą AI nadłubać jakiś koszmarny komponent w Reactie, albo frontendowcem, którzy przy wsparciu AI wyklepie jakiś paskudny endpoint. Jakby na to nie spojrzeć - nazywanie fullstackiem takiej osoby to abberacja i trywializowanie frontu/backu (zależnie od punktu widzenia).
@dzienisz Od tego jest CR i zapewnienie odpowiedniego poziomu procesu jakości, aby takie sytuacje wyłapywać i eliminować.
Przykładowo - do każdego taska gdzie jest backend, frontend, devops przypisujemy do CR osoby z tych specjalizacji / eksperckości aby wskazały jak to powinno wyglądać/działać.
Każdy task frontowy w naszym procesie ma wymagane wstawienie screenshotów/filmików z działania - tak aby było widać jak to wygląda/działa.
Pozdro,
Adam Polak
@coder_one tak i nie. Bądźmy realistami - czucie zaangażowania i pasji po obu stronach barykady ma sens tylko wtedy kiedy ktoś naprawdę jest one man army i ma samemu cały projekt ciągnąć.
Realia są takie że w projekcie jest więcej osób i nie jest tak że mamy tyle samo zadań na front, devops, backend, a jednocześnie trzeba takie rzeczy wykonać. Ludzie też naturalnie będą szli w kierunku rzeczy które w danym momencie ich interesują - a to właśnie buduje specjalizacje, która na przestrzeni czasu może się zmieniać.
Developer dojrzały to taki który robi to co jest potrzebne w produkcie, a nie tylko to co w danym momencie zgadza się z tym co go interesuje. I właśnie to z naszego doświadczenia zmienia mocno definicję fullstacka - która kiedyś była dokładnie taka jak piszesz - w kierunku osoby która ma pewną ekspertyzę, ale nie boi się wejść w inne obszary (bo taka jest potrzeba produktowa).
Pozdro,
Adam Polak
ja bym nawet powiedzał, że fullstack może ogarnąć AI na poziomie korzystania z API czy zbudowania prostego RAGa
Jak najbardziej o ile nie wchodzi my w AI w formie ML - trenowanie/budowanie modelów.
Obecnie narzędzia AI rozwinęły się do tego stopnia (i to nawet po tym jak nagraliśmy ten odcinek), że budowanie RAG staje się co raz łatwiejsze - gotowe moduły, SDK przygotowane do wykorzystania innych baz.
Pozdro,
Adam Polak
Skoro One Man Army to poco mi software house? Cała kasa dla mnie 😂
Akurat tutaj nie mowimy o SH (pomimo że sami jesteśmy z SH), tylko o sytuacji na rynku w firmach produktowych. Od +/- roku jest bardzo mocno widoczny trend, aby w projekcie pojawiały się osoby które nie boją się brać zadań z innej działki.
Pozdro,
Adam Polak
Chuja tam, stopy procentowe polecą w dół w USA, znowu zaczną się kredyty i zatrudnianie w opór. Znowu zmieni się narracja.
Jak mawiał klasyk ruclips.net/video/njX58y8zG3E/видео.html - we will say what time will tell.
@@Foryal w USA może polecą. W Polsce nie polecą. Polecam Forbes sobie w necie poczytać. Inflacja w Polsce się utrzymuje i rada polityki pieniężnej na pewno szybko stóp procentowych nie obniży.
@@sysadmin-info Mało obchodzą polskie stopy procentowe ludzi, którzy pracują dla Jankesa, albo którzy u Jankesa się kredytują. Mordo mordeczko
@@Foryal jak ja nie lubię takiego pierdololo w stylu mordo do obcej osoby. Beznadziejna mania jakaś. Mnie natomiast nie interesuje w ogóle rynek amerykański, mimo, że świetnie wiem o tym, że gospodarka jest światowa i to co się dzieje na Wall Street ma odzwierciedlenie też w Europie, a także w Polsce. Patrzę spokojnie na Microsoft, który zwalnia, bo to podnosi ceny akcji. Patrzę na innych, też zwalniają. Patrzę na to, że inwestują w energię atomową, żeby rozwijać AI w skrócie, chociaż w zasadzie to są po prostu algorytmy i struktury danych. Prawda jest taka, że kilku dobrych seniorów z pomocą modeli LLM opierdzieli frontend, backend, zrobi testy i puści deployment na produkcję. Dokładnie tak. Jak ktoś jest dobry i ogarnia, to co ja, albo więcej, to sam to zrobi. Wystarczy zbudować odpowiednie środowisko. Po co armia ludzi? Bez sensu. Każdy, kto się na tym zna, wie, że tak właśnie jest. Czeka nas robotyzacja i automatyzacja. Nie od razu, ale stopniowo. Ford Henry zautomatyzował produkcję samochodów. Automatyzacja zwiększa bezrobocie. To jest oczywiste. Mniej zatrudnionych to większe oszczędności. To prosty rachunek.
@@sysadmin-info To zabawne jak niewiele prawdy może być w takiej ilości wypocin.
W skrócie: Areczku, co prawda dostaniesz sporo mniej kasy, ale będziesz musiał zapieprzać jeszcze za kolegów, których zwolniliśmy. Masz AI do pomocy więc nie marudź.
Realia są takie, że do niedawna niewiele firm interesowało się efektywnością i tym, czy ich proces developmentu realnie ma sens (co naprawdę doprowadziło do sytuacji że mamy role od wszystkiego, a zespołu się rozrosły niemiłosiernie) - więc… trochę jest tak jak mówisz, ale tylko od strony że osób będzie mniej, roboty tyle samo i teraz pytanie jak sprawić, aby to poukładać (np. można wywalać część spotkań ;)).
@@TshIo Myślę, że w tych nowych warunkach warto rozważyć przestawienie w naszym regionie domyślnej długości scrumowego sprintu z 14 dni na np. 10. Wtedy więcej tasków się każdemu wciśnie. Niestety dla koderów oznaczałoby to, że prawdopodobnie będzie trzeba robić też w soboty i niedziele. Niestety trudne czasy wymagają większych poświęceń. Ale z drugiej strony to szansa na szybszą naukę i sprawniejszy rozwój. Inaczej w średniej perspektywie przegramy konkurencję z zasobami ludzkimi ze wschodu i dalekiego południa. Pozdrawiam 😉
Eeee tam zaraz zapieprzać za kolegów, jeśli dobrze pracowali to raczej dalej są z tobą w projekcie. Gorzej, jeśli ci koledzy robili na przysłowiowe "pół gwizdka". ;)
Pozdro,
Andrzej Wysoczański
Jak dla mnie, jeśli Areczek zostaje sam, 2 innych jest niepotrzebnych, to Areczek ma więcej pracy, ale też może liczyć na trochę więcej PIENIĄŻKÓW. Takie realia realistyczne są, bez jaj. Czyli w sumie nieźle dla Areczka. I nie, że konkurencja, bo przecież takich doświadczonych nie jest chyba dużo.
@@nicolasujwbrew pozorom to jest tych doświadczonych nawet dużo.
Jestem ciekaw jakie firmy chciały zatrudniać Full-Stacków, z mojego doświadczenia było tak że: pisze pan w technologii X no to tylko tym jesteśmy zainteresowani a to że chce Pan robić więcej to to nas nie obchodzi to nie robił Pan tego w poprzedniej formie i nie ma Pan doświadczenie w tym
Wszystko zależy od firmy. Są jeszcze takie które tego trendu nie widzą, są natomiast takie które już teraz otwarcie będą informować, że dobrze aby kandydat miał doświadczenie w czymś innym.
Tu dalej każdy będzie miał jakąś swoją wąską specjalizacje - nie chodzi o to aby zrobić mityczną one man army, ale o to aby móc efektywnie developować bez blokad - w postaci nieobecności, urlopów etc. I nie musieć specjalnie skalować zespołów tylko dlatego że od teraz będziemy mieli do robienia więcej frontu niż backendu ;)
Pozdro,
Adam Polak
@@TshIo oj tak, również jestem takiego zdania i jestem tzw "T shaped developerem" i dążę do tego aby rozwijać się w różnych dziedzinach
Taki fullstack może brać odpowiedzialność za cały feature. Jeżeli proces w projekcie jest do tego dostosowany, to można tym o wiele łatwiej zarządzać.
I tak jak Adam powiedział, to bardzo zależy od konkretnego przypadku, natomiast widzimy, co się dzieje na rynku i tych zmian prowadzących do wdrażania/zatrudniania/uczenia fullstacków jest co raz więcej.
Czy ten trend się utrzyma? Czas pokaże.
Pozdro,
Andrzej Wysoczański
@@TshIo zobaczymy co przyniesie AI i automatyzacja pracy - moje produkcje są takie że fillstacku będą teraz w cenie i dzieki chatGPT czy tym podobnym tworom procesy programowanie będzie którzy i prostszy
@@TshIo
[inny temat] właśnie tak teraz pomyślałem o temacie na nowy filmik: czy planujecie zrobić odcinek o rynku analizy danych (analitycy danych, raportowanie, data science)
Teraz jest duży hype na data science.i ciekawy jestem czy warto w to iść
Jak chcecie znaleźć lub wyszkolić tych "ludzi od wszystkiego"? Backendowców nie nauczycie frontu a fronty nie ogarną w rok devopsu i backendu.
Tu nie chodzi aby kogoś nauczyć w rok wszystkiego - chodzi o to aby zacząć eksponować ludzi na rzeczy z poza ich działki.
Zaczyna się od rzeczy prosty - fixowanie jakiś prostych bugów, robienie prostych zmian na interfejsie/infrze/dodawania endpointów które będą bazować na innym kodzie. Dopiero potem przechodzi się do budowania całego projektu takim a nie innym teamem (do tego dodaje się wsparcie w postaci kogoś doświadczonego w tym obszarze).
Zrobiliśmy to już wielokrotnie u nas - działa.
Pozdro,
Adam Polak
@@dzienisz da się. W rok może nie, ale w trzy do pięciu już tak. Ja ogarniam i front, którego nie lubię, ale jak muszę to wiadomo i backend, który lubię dużo bardziej. Jestem QA DevOps expert. Jednak nie nazwę siebie full stack, bo full to naprawdę sporo narzędzi. Swoją drogą tak w zasadzie to nie lubię programować i jak mogę, korzystam z obecnych rozwiązań, by jak najwięcej kodu pisało się samo, a ja tylko sprawdzam, czy jest poprawnie i bzdur nie ma, a potem testuję, czy działa.
niesamowite, jak panowie na to wpadli? zmniejszmy zespol o polowe i oczekujmy ze beda dowozili to samo bo nazwiemy ich fullstack ze wskazaniem na BE/FE xDDDDDD I jeszcze te gadanie że developrzy przestana robić błędy jak sobie "wezmą do serca" coś. Panowie handlowcy, serio super kabaret robicie.
Ani Adam, ani Andrzej nie są handlowcami, ale skoro potrafią tak fantastycznie rozbawić słuchaczy, to może pora na karierę w stand-upie. ;)