Kolejny piątek - a więc kolejny odcinek Patoarchitektów. Gorącym kartoflem na dzisiaj są umierające skille w IT. Co powinien wiedzieć specjalista, a co może sobie odpuścić. W tej kwestii nasze zdania są podzielone, więc sporo się dzieje w dzisiejszym odcinku. Na koniec robi się lekko sentymentalnie, bo rozmawiamy o programie studiów i o tym, co z perspektywy praktyków IT, powinno się tam znaleźć, co znacznie ułatwia pracę specjalistom IT. Przesłuchaj od razu!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda..
Łukasz Kałużny: i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io lub klasycznie gdzieś tu na dole w playerze, w którym słuchacie.
Szymon Warda: No więc oczywiście też ponawiamy opcję wysłania babci, cioci, koledze i tak dalej, bo wyciągnąłem “Pato to the Moon”, czyli chcemy trochę rozpromować nasze gadanie właściwie tak naprawdę. Łukaszu?
Łukasz Kałużny: Dobra Szymonie, to dzisiaj jaki temat odcinka?
Szymon Warda: Dziś temat odcinka, wynik z naszej rozmowy, którą mieliśmy odnośnie tego czy, a ja powiem to zadziornie, czy mamy być starymi trepami i mówić: a ci nowi deweloperzy niczego nie umieją? Czy zgodzić się z tym, że mamy na tyle dobre abstrakcje, że nie musimy uczyć nowych developerów UDP, np. TCP/IP, jak działają wewnętrznie. Może inaczej, czy nie musimy uczyć wszystkich, czy np. gołego Asemblera, albo jeszcze programowania po bitach. Jak można się domyślić ja jestem zdania, że nie musimy. Łukasz trochę innego, bym powiedział.
Łukasz Kałużny: Wiesz co, tak, z domysłu uważam, że dla wszystkich byłoby lepiej, gdyby ludzie w branży IT to znali. Byłoby prościej.
Szymon Warda: Uważam, że nie - z prostego powodu, to jest marnowanie dla większości ludzi czasu. Developer jak to naprawdę nie potrzebuje umieć pisać instrukcji procesora w formie nawet niższej niż Asemblera. Po prostu tego nie potrzebuje na co dzień i fajnie jest wiedzieć, ale to nie jest coś, co powinniśmy wymagać od tych ludzi. Tak samo jak mamy cały zestaw lekarzy, nie od każdego lekarza wymagamy tego wszystkiego tak naprawdę. Od kardiologa nie będziesz wymagał podstawowych chorób pediatrycznych, bo to po prostu nie ma sensu większego.
Łukasz Kałużny: Wiesz co, i teraz tak, z całością ja się tutaj mocno z tym nie zgadzam, bo jak podałeś przykład lekarzy to wszyscy łapią jakieś ogólny level wykształcenia i ogólny level podstaw. Tak samo jak zobaczysz jak mówisz sobie protokoły, Asembler i inne takie rzeczy, to jest materiał studiów. Jeżeli sobie… Popatrz, zobacz, że to jest materiał studiów. Nie mówimy o znaniu tego na pamięć. Ja Ci nie powiem, że masz zakodować i pamiętać jak zakodować Quick Sorta po 20 latach, tylko pamiętać, że: o, był taki algorytm jak Quick Sort, albo bąbelkowe albo Dijkstra. Czyli że pamiętasz, że takie rzeczy są i wiesz, że możesz użyć.
Szymon Warda: Łukasz, naprawdę miałeś na studiach kodowanie procesora na poziomie niższym niż Asembler?
Łukasz Kałużny: Nie, niższym niż Asembler nie, bo tego nie robisz.
Szymon Warda: To zobacz ile ludzi teraz na studiach ma Asemblera. Mniejszość. Ile ludzi ma kodowanie w C? Czyli mówimy o kodowaniu, gdzie musisz alokować i dealokować pamięć.
Łukasz Kałużny: Przepraszam, to był język wyższego poziomu za moich czasów. [śmiech]
Szymon Warda: Przypomnę Ci, że w naszej dwójce to ja jestem starszy.
Łukasz Kałużny: Właśnie, więc u ciebie to był super wysokiego.
Szymon Warda: Aż tak źle nie było. Ale o ile rozumienie powiedzmy sobie, że TCP, taka charakterystyka UDP, taka charakterystyka komunikacji, to wchodzenie w jak używać i rzeczy, nawet robienie broadcastu na UDP, nie ma to zastosowania. To się robiło raz na laborkach i jest koniec tego użycia tak naprawdę i szansa, że 99% developerów będzie tego używała jest zerowa. To są rzeczy, z których korzystają ludzie, którzy piszą niskopoziomowe rzeczy, które potem chodzą po sieci.
Łukasz Kałużny: Ja mam trochę takie jeszcze jedno rozgraniczenie, które mi trochę nie wszyscy… Albo masz role i chcesz iść dalej i mieć wpływ na pewne rzeczy, bo tak jak mówisz np. od strony developera, kodowanie to jest ostatnia czynność, którą w procesie inżynierii oprogramowania powinieneś wykonywać.
Szymon Warda: Ewidentnie nie czytałeś dobrego raportu McKinseya.
Łukasz Kałużny: Ewidentnie i cała z tym zabawa, trzeba powiedzieć sobie, czy chcesz klepać czy chcesz robić coś więcej. Jeżeli chcesz coś robić więcej to ta wiedza pomaga.
Szymon Warda: I tak i nie. Bo czy warto wiedzieć? Tak, warto wiedzieć wiele rzeczy. I zgodzę się, że im więcej wiemy, im więcej tych możliwości mamy w głowie, to jest taki nasz zestaw narzędziowy, tym więcej możemy. Pytanie tak naprawdę, bo czas mamy skończony, każdy z nas, czy warto jest w pewne rzeczy inwestować czas? Nie warto.
Łukasz Kałużny: Wiesz co? Dobra, ja sobie trochę pójdę, bo jest fajna rzecz na ten temat w dokumentacji AWS-a.
Szymon Warda: Tak kojarzę, całe w ogóle podejście.
Łukasz Kałużny: Tak, well-architected framework. Jest sobie tam cytat z Jackie Stewarta, kierowcy wyścigowego, gdzie po polsku on będzie brzmiał: “Nie musisz być inżynierem, aby zostać kierowcą wyścigowym, ale musisz mieć tutaj mechaniczną sympatię” - mechanical sympathy, czyli że musisz to czuć i rozumieć. Dlatego ja mówię, że ten poziom wiedzy ze studiów pozwala ci, poziom materiału studiów informatyki pozwala ci czuć to wszystko, jeżeli popatrzysz - czuć. Ja nie mówię, że znać. Czuć.
Szymon Warda: Rozumiem cię. Tak, czucie, tylko podejdźmy do tego jakie powinny być struktury organizacyjne w większości zespołów developerskich. Mamy dużo juniorów i taki tylko jeśli chodzi, na samej górze mamy powiedzmy jakiś architektów, principal architektów i tak dalej. To nie jest tak, że wszyscy juniorzy, wszyscy ludzie z samego dołu przejdą całą drabinkę aż do góry. Niektórzy, po pierwsze, zatrzymają się na którymś poziomie, niektórzy stwierdzą, że nie chcą iść na pewien poziom, niektórzy stwierdzą, że w ogóle informatyka ich nie interesuje, a niektórzy po prostu nigdy powyżej pewnego poziomu nie dojdą, bo jest milion powodów. I to wcale nie znaczy, że coś jest z nimi źle, czy cokolwiek, po prostu nie chcą. Znam ludzi, którzy po prostu nie chcą powyżej pewnego poziomu wchodzić, bo ich to nie interesuje, powiedzmy sobie. Lubią np. kodować, to jest ich bajka i czują się w tym dobrze. Ale nawet niekoniecznie to. Nawet po protsu to, że ich może interesuje kodowanie np. w C, C-Sharpie, w Javie, w czymkolwiek, architektura ich po prostu nie interesuje. Oni wzorce projektowe, kisdra i tak dalej, ten poziom jest, gdzie oni czują się bardzo, bardzo dobrze, czasami kodują dziewiąta - piąta, czasami po prostu siedzą po godzinach i trzepią fajne rzeczy, nie?
Szymon Warda: Ale ta grupa ludzi, którzy potrzebują albo którym się przyda ta wiedza wyższa, jest naprawdę bardzo, bardzo, bardzo wąska. Bo to są albo wąskie dziedziny IT, albo faktycznie, podajmy przykład AWS-a, fajnie, tylko AWS ma taką skalę, że faktycznie np. te elementy są dla nich ważne w optymalizacji takiej czysto sprzętowej.
Łukasz Kałużny: Tylko ten WAF jest podany, to jest framework dla klientów, nie ich wewnętrzny.
Szymon Warda: Tak, bo on fajnie brzmi tak naprawdę, nie oszukujmy się, fajnie brzmi to też częściowo z tego wynika. Czy w aplikacjach biznesowych podejście takiego mechanical sympathy jest dobre? Tak, jest fajne. Takie podejście też można wprowadzić jeżeli przygotujemy ludzi taką wiedzą, to potem prowadzi do zbyt wczesnej optymalizacji. To jest tylko: o, zoptymalizujmy tą instrukcję.
Łukasz Kałużny: Tutaj wrzucę ci, to jest błąd, który ludzie zdobywają i trzeba się go oduczyć jeżeli za bardzo zdobędą tą wiedzę, patrzenia się. Jak pytasz się, ta mechanical sympathy i aplikacja biznesowa powiedzmy sobie, utrzymanie tego, cokolwiek, większość rzeczy, które potem dzieje się w trakcie awarii, troubleshooting, szukanie, posiadanie tej wiedzy zazwyczaj pomaga ci to odnaleźć o wiele, o wiele szybciej.
Szymon Warda: Zgadza się. Ile osób w zespole powinno umieć odpalić i przeglądać Wiresharka? Jedna, dwie na naprawdę ogromny zespół.
Łukasz Kałużny: Wiresharka tak. Ale żeby wiedzieć co to jest DNS i jak działa, to powinien cały zespół. Co najczęściej…
Szymon Warda: Oj, jeżeli tak podchodzimy, to ja powiem, że większość developerów nie rozumie DNS-a.
Łukasz Kałużny: Tak, tylko zobacz, że to jest drugi rok studiów. Jeżeli popatrzysz na materiał.
Szymon Warda: I jest z tym różnie, zależy od studiów. Program też się zmienia. Jak ostatnio porównywałem jak wyglądał mój program, a jak wygląda obecny program, to chociażby to, że przeszliśmy od nauki Pascala, C do nauki JavaScriptu i Pythona, czyli języków zarządzanych, tak naprawdę, gdzie nie musisz się martwić alokacją pamięci. I to jest dobry ruch, bo nie walisz się z alokacjami i delokacją, bo to nie jest nauka programowania, to jest nauka niskopoziomowa. A potem dopiero przechodzisz: czy potrzebuję C? To używam C.
Łukasz Kałużny: Wiesz co, to jest architektura systemów operacyjnych i tam to się powinno znajdować.
Szymon Warda: Tak, w dużej mierze tak, bo to jest pisanie wirtualnych maszyn i tak dalej, zgadza się. Ale chodzi o to, że zaprzątanie ludzi głowy właśnie takimi problemami, kiedy zaczynają się uczyć i poznawać, dla mnie nie ma wartości. Wolę, żeby umieli algorytmy. Wolę, żeby właśnie, co rozmawialiśmy wczoraj, matematykę dyskretną. Wolę, żeby rozumieli pewne rzeczy, a potem takie rzeczy typu właśnie alokacja i tak dalej, na późniejszych latach, jak już ogarnęli co i jak.
Łukasz Kałużny: Tylko zabawa powiedziałeś, algorytmy, większość, algorytmy, struktury danych, nawet nie algorytmy, struktury danych, dla większości jest to taki sam low level jak mówienie sobie, że mamy protokoły sieciowe i inne rzeczy. To jest dokładnie ten sam poziom. Większość nie wychodzi od tego jak użyć tablicy i nie zna różnicy czym pod spodem jest tablica, czym jest lista w strukturach danych.
Szymon Warda: Zgadza się. Mój problem z tym polega na tym, że to, czy użyjesz listy, czy użyjesz słownika, czy użyjesz HashSetu, czy czegokolwiek innego, ma realny wpływ na wydanie naszej aplikacji, realny. To czy to się przekłada na taką instrukcję w Asemblerze czy jakakolwiek inna opcja, żadnego sensu.
Łukasz Kałużny: Nie, ja nie mówię przekładanie, tylko w jaki sposób to działa i co to jest. To jak mówisz, że ma realny wpływ to musi wiedzieć co to jest.
Szymon Warda: Zgadza się. Dlatego wolę generalnie część rzeczy wyciąć, a skupić się na innych częściach, bo w ten sposób przesunięcie suwaka. Wolę żeby przesunąć suwak w kierunku generalnie znajomości tej części aplikacjnej, tej części, gdzie większość ludzi spędzi znaczną część swojej kariery w kodzie i to będzie niezależne od Pythona, C i tak dalej, całego zestawu języków.
Łukasz Kałużny: Wiesz, język i ta cała rzecz niezależna, to w mojej opinii jest właśnie jak coś działa. Nie do szczegółu, żebyś umiał to zaimplementować, tylko właśnie jak coś działa, jakie mamy podejścia. I zauważ, że przy dobrym podejściu język programowania np. jest rzeczą wtórną.
Szymon Warda: To może zdefiniujmy jedną rzecz. Dla mnie rzeczy powiązane ze sprzętem i siecią, czyli właśnie protokoły niskopoziomowe TCP/IP, UDP, cały Asembler… Co tam jeszcze generalnie wchodzi… zarządzanie pamięcią, to są rzeczy, które już powinniśmy odciąć albo zmniejszyć nacisk na to, a większy nacisk położyć na jak coś działa, ale na poziomie kodu i algorytmów tej abstrakcji. Bo to musimy rozgraniczyć, bo tu się zgadzamy, że algorytmy, struktury danych i tak dalej, cała ta obudówka w z reguły innym programie, to ma sens, ale pozostała? Nie.
Łukasz Kałużny: Wiesz co? Inaczej, zarządzanie pamięcią, dla mnie to jest trochę też powiedzenie nie w kodowaniu, ale te kilka miesięcy poświęcone na architekturę systemów operacyjnych, żeby wiedzieć czym różni się wątek, proces i korutyna, czym są mutexy i inne rzeczy. Wypadałoby wiedzieć.
Szymon Warda: Ile masz teraz, ewidentnie idziemy w tym kierunku, że coraz więcej języków, maszyn wirtualnych, jakkolwiek nazwiemy te runtime’y języków, mają abstrakcje nad to.
Łukasz Kałużny: Tak, mają swoją maszynę stanów zazwyczaj i działają na korutynach. Tylko chodzi o to, że powinieneś potem wiedzieć dlaczego Ty masz postawić workerów, ile masz tej w maszynie, czy w zasobach masz tych core’ów na CPU.
Szymon Warda: Realnie nikt z developerów tego nie potrzebuje. To będzie robiła albo osoba zarządzająca, już z konkretnym stażem, albo będzie robił ktoś na poziomie architekta, albo taki typowy ekspert. Przeciętny developer tego nie potrzebuje. Tak samo jak absolutnie nie wolno nawet ludziom dawać, pozwalać na używanie mutexu, semaforów w kodzie, bo to wyrządza więcej krzywdy. Jak zaczynają pisać: może by się przydało. Nie.
Łukasz Kałużny: Nie, rozumieć, rozumieć.
Szymon Warda: Doskonale wiesz, że jak się da pewną zabawkę, to ludzie zaczną tego używać. Pewne tematy powinno się wprowadzać już po jakimś czasie kodowania. Ja bym wolał na studiach mieć chociażby sposoby modelowania danych, metodologie typu event storming, event modeling i tak dalej, zamiast tego całego low levelu, którego ludzie, po pierwsze, nadużywają, po drugie, nie potrzebują, a po trzecie to w ogóle nie rozumieją.
Łukasz Kałużny: I całość, one są po to, żeby je zrozumieć, ta nauka tego.
Szymon Warda: Na ile musisz rozumieć coś, czego nie będziesz wykorzystywał. Nagrywam właśnie i patrzę na moją kolekcję noży. Umiem z noża korzystać prawidłowo. Nie muszę rozumieć do końca jak działają odpowiednie stopy stali.
Łukasz Kałużny: A dla mnie np. stopów też nie muszę rozumieć, jak są zrobione i jak wynikają ich twardości z nawęglenia.
Szymon Warda: Nie tylko nawęglenia, tam jest jeszcze cała cała seria innych rzeczy.
Łukasz Kałużny: Tak. Dobra, nie wchodźmy, bo będziemy nerdować na inne tematy. Wiesz co, całość np., mi to pozwala wchodzić w dowolną teraz technologię, która się pojawia, poza machine learningiem, bo ze statystyki byłem nogą. To jeżeli popatrzysz, to pozwala ci to wchodzić de facto w dowolne technologie patrząc się przez analogię z czego one mogą być zrobione i w jaki sposób działają.
Szymon Warda: Łukasz, ja się z tobą zgadzam i też uważam, że to jest m.in. mój super power, że po prostu patrzysz na podstawowe elementy i wiesz co będzie z tego wynikało i jak to mniej więcej działa i jak się to nazywa i tak dalej. Znając np. wzorce projektowe, będziesz wiedział mniej więcej jakie postfixy, jakie prefiksy w nazwach funkcji będą. I bardzo wiele, czy dzięki temu jest łatwiejsze. Tylko teraz pytanie jest takie znowu moje - ile ludzi czegoś takiego potrzebuje? Bo realnie niewiele. Znam ludzi, którzy przesiedzieli całą swoją karierę w Oracle Formsach. Nie będą tego potrzebowali nigdy w życiu. Znam, masz całych DBA-ów, którzy wyraźnie mówią, że gdyby oni chcieli się czegoś uczyć, to wybraliby cokolwiek innego. Ale oni znają SQL-a i będą tego SQL-a do końca swego życia używać, nie będą używali niczego innego.
Łukasz Kałużny: Wiesz co, tu muszę skierować - chyba nasi słuchacze.
Szymon Warda: Nie, bo taka prawda jest. Jest dużo… Deweloperzy frontend-owi, czy oni będą tą wiedzę potrzebowali? Nie, nie będą tej wiedzy potrzebowali. Bo obecnie, to co właśnie rozmawialiśmy wczoraj, abstrakcja wokół HTTP zrobiła się już na tyle dobra, że o ile kiedyś jeszcze rozróżnienie między różnymi modelami, jak to działa, było ważne, ale obecnie… np. UDP. Kiedyś UDP było realnie zawodne, obecnie UDP stało się naprawdę dobre. Po prostu działa.
Łukasz Kałużny: Tak, tylko, że opędzlowaliśmy to na poziomie aplikacji, a dla ludzi abstrakcji.
Szymon Warda: Zgadza się. Chodzi o to, że pewne modele abstrakcji kiedyś były takie, przeciekały i trzeba było to znać. Ale obecnie te modele abstrakcji działają na tyle dobrze, że ogólnie mówiąc nie musimy się tym martwić. Obecnie wszystkie maszyny wirtualne do frameworków, Dot NET-ów, Dot NET Java i podobnych działają, po prostu działają dobrze. Z reguły nie martwimy się o pamięć, zarządzanie wątkami i tak dalej. Protokoły komunikacji działają. HTTP stał się uniwersalny i działa dobrze. Super. Więc przy tym developer nie potrzebuje tego. Wolałbym, żeby ten developer uczył się czegoś innego w tym czasie.
Łukasz Kałużny: Dobra. Ja mam teraz taką jeszcze jedną uwagę o umierających skillach albo skillach, które nigdy de facto się na świecie nie pokazały za bardzo w IT. To jest podchodzenie trochę z tabula rasą do nowych technologii i innych rzeczy. I to takie moje spostrzeżenie jest, że ludzie bardzo często, nawet wczoraj miałem taką rozmowę w jednym miejscu, bardzo często porównują wszystko do czegoś, co znają i dla nich baselinem zazwyczaj jest pierwsza technologia, której się nauczyli, bo nie rozumieją jak coś pod spodem działa. I porównują sobie, że mają komendę od tego, do tego, do wyklikania klikania GUI. Jak de facto oglądają dokładnie to samo, tylko inaczej narysowane.
Szymon Warda: Zgadza się, to jest ta opcja, o czym wspomniałeś wcześniej -
Szymon Warda: czy rozumiesz jak coś działa? Czy rozumiesz jak działa młotek generalnie i o co chodzi, po co w ogóle z niego korzystać? Czy po prostu uczysz się obsługi młotka, potem się uczysz obsługi śrubokręta i rozumiesz tylko te narzędzia i dalej nigdzie nie wyskoczysz?
Łukasz Kałużny: I wiesz co? Ja miałem rozmowę z architektem, który wbijał tylko młotkiem.
Szymon Warda: Ale to jest problem organizacji dla mnie. To jest kwestia tego, kogo odpowiednio promujemy i jak robimy. Ale z drugiej strony, jeżeli organizacja wdraża ten sam system, a jest sporo firm, które wdrażają ten sam system w inny sposób tylko odrobinę, to on używa młotka, bo wszystko co robią jest formą czegoś, co możemy wymłotkować. Więc się z tobą zgodzę w ogóle. Fajnie byłoby, żeby ludzie to umieli, ale jeszcze fajniej byłoby, gdyby umieli inne rzeczy tak naprawdę, to myślenie abstrakcyjne.
Łukasz Kałużny: No wiesz i tu dochodzimy do tego, że matematyka dyskretna jest królem dla osób pracujących w IT.
Szymon Warda: Matematyka w ogóle przydaje się i ta forma myślenia, o czym rozmawialiśmy też wczoraj, dla mnie często mówi się, że studia są nieprzydatne w IT. Im się idzie wyżej, tym się bardziej przydają te rzeczy matematyczne i rzeczy ze studiów i rzeczy teoretyczne, to po pierwsze. Po drugie, one, co powiedziałeś, umożliwiają zrozumienie pewnych tematów. A po trzecie, one przede wszystkim uczą myśleć, one uczą. I jak nazwać te podwaliny? Cała dyskretna, cała algebra i tak dalej. Algebra, to co mówiła moja profesorka, to ona uczy dokładnego wyrażania się i faktycznie dobrze uczy. A analiza matematyczna uczy dokładnego analizowania i budowania rzeczy na bazie pewnych prostych budulców, które mamy, budowania kolejnej warstwy abstrakcji, kolejnej warstwy abstrakcji i tak dalej, to ona uczy sposobów myślenia. Nie zakładamy, że będziecie używali przestrzeni Banacha na co dzień w pracy, bo nikt tego nie używa tak na co dzień w pracy, ale dla mnie problematyczne staje się w tej sytuacji jak nagle niby w warstwach abstrakcji budujemy w matematyce, a potem w IT mówimy: dawno temu komputery zaczęły się od liczydła. Możnaby od tego zacząć.
Szymon Warda: Nie ma sensu. Za nisko te warstwy abstrakcji kończymy na studiach. Powinniśmy pójść wyżej, w kierunku co się de facto dzieje i co się potem przydaje. Nauczyć myślenia się, właśnie te wszystkie techniki modelowania np., techniki podejścia do rozmowy z biznesem, planowania architektury, teraz uczą nas słabo, w ogóle całe podejście wokół form normalnych.
Łukasz Kałużny: Ale wiesz co i to jest moim zdaniem też trochę, jak już wchodzimy sobie w tą stronę, to jest zabawa pomiędzy - czym jest wytwarzanie oprogramowania a czym jest informatyka? Bo jak sobie popatrzysz to są 2 różne rzeczy. Czysta informatyka to są algorytmy, struktury danych, zarządzanie pamięcią etc. Praca na tym poziomie + cała teoria informacji, teorie kategorii i inne tego typu przyjemności. A wytwarzanie oprogramowania to jest to, co ty powiedziałeś, czyli część bardzo mocno praktyczna, którą, gdzieś cierpimy w IT, że nie ma podejścia, które gdzieś tam się pojawiło do sformalizowania software engineeringu, nigdy nie poszło dalej. Czyli świat akademicki nigdy nie przeniknął się ze światem praktycznym.
Szymon Warda: Właśnie nie wiem, czy to wynika z przenikania ze światem praktycznym, czy wynika z tego, że ciężko jest uczyć takich rzeczy. Bo to nawet nie mówimy praktyka, tu mówimy ponownie o sposobie analizowania problemów, żeby ludzie budowali swoje, tak samo jak zbudowali matematyczne modele abstrakcyjne, to informatyczne modele abstrakcyjne i tego nie budujemy. To jest takie słabe, bo znowu np. zrób przedmiot załóżmy z rozmowy z biznesem albo z tego, jak w ogóle podejść do moderowania dużych systemów. To jest trudne.
Łukasz Kałużny: No ja widzę, podchodzisz tak, mogę sobie powiedzieć, że zrobienie przez niepraktyka zajęć z DDD byłoby strzałem w kolano dla takich osób.
Szymon Warda: Tak, ale nawet załóżmy zrobienie porządnych zajęć z modelowania danych, to jest trudne, bo to też wymaga pewnej wiedzy, ostukania się z różnymi systemami i po prostu musiałeś sobie dupę obić na wielu problemach i zrozumieć. To jest cała piramida zrozumienia. Na samym dole musisz mieć świadomość problemu. A kiedyś na studiach tego problemu, że w pewien sposób moderowanie jest problemem nie masz, bo Twoja baza ma 10 rekordów, z czego połowa ma nazwę dupa 1, dupa 2 i dupa 3 generalnie, bo to wstawiałeś sobie na testowaniu, więc nie rozumiesz po co tak naprawdę. Więc uczenie tych ludzi kolejnych rzeczy jest trudne. Potrzeba lat de facto, żeby oni zrozumieli: ok, tu jest ciężko, więc może potrzebuję czegoś innego? Może potrzebuję jakoś inaczej do tego podejść? Więc to też wynika z doświadczenia letniego. Nie nauczysz tego podczas pięciu lat studiów.
Łukasz Kałużny: Raczej tak, dupogodziny są potrzebne.
Szymon Warda: Dokładnie tak, dupogodziny, ale też takie mądre dupogodziny, bo można spędzić dużo dupogodzin nad jedną rzeczą i nic z tego nie wyciągnąć.
Łukasz Kałużny: Tak, klepanie przesuwania buttona.
Szymon Warda: Dokładnie tak. Więc fajnie byłoby. Nierealne.
Łukasz Kałużny: Dobra, no to kończymy tym akcentem. Na razie, hej.
Szymon Warda: Na razie hej.