Co wybrać: low-code czy język programowania

Transkrypcja

Dziś moim gościem jest Michał Guzowski. Michał opowie nam o rozwiązaniach low-code oraz ich związku z programowaniem. Michale, dziękuję, że przyjąłeś zaproszenie na rozmowę.

Cześć, Mateuszu. Dziękuję za zaproszenie. Dzień dobry wszystkim słuchaczom.

Michale, to może zacznijmy od Twojej osoby. Co łączy Cię z branżą IT?

Mnie z branżą IT łączy właściwie całe moje wykształcenie, ponieważ ukończyłem kierunek inżynierii oprogramowania na Politechnice Warszawskiej i byłem programistą przez następnych chyba 6 lat. Skakałem po różnych stanowiskach: od konsultanta programisty do team leadera aż po architekta.

Zawsze z tą branżą IT byłem gdzieś tam związany. Jako osobę, która grała dużo w gry, zawsze mnie ciągnęło do komputerów.

Od jakiegoś czasu, od 3-4 lat głównie zajmuję się platformami low-code i no-code.

Skoro już wywołałeś ten temat, to powiedz nam, czym jest low-code. Myślę, że to nie musi być takie oczywiste.

Ja wiem nawet, że dla wielu nie jest oczywiste. Mówię o tym od wielu lat, ale cały czas spotykam się z niezrozumieniem. To jest chyba normalny proces przyswajania, edukowania rynku.

W przypadku low-code/no-code trzeba wytłumaczyć, o czym mówimy. Z założenia większość ludzi, kiedy mówi, czym jest low-code/no-code, ma na myśli platformy low-code/no-code. Platformy no-code to platformy, które pozwalają budować rozwiązania – czy to będą aplikacje biznesowe, czy to będą strony internetowe, czy to będą jakieś automatyzacje, integracje – bez umiejętności programowania, bez żadnej najmniejszej linijki kodu.

Najczęściej wtedy buduje się takie rozwiązania, przyciskając i upuszczając. Czyli mamy to podejście drag&drop. Mamy też edytory, tzw. WYSIWYG, czyli what you see is what you get. Przykładem platformy no-code będzie na przykład WordPress albo Webflow, czyli platformy, które pozwalają na budowanie stron internetowych w bardzo prosty, przyjemny sposób.

No i mamy jeszcze platformy low-code’owe. One się różnią tym, że aby zbudować tam jakieś zależności, jakąś logikę, trzeba posłużyć się prostym językiem programowania. Choć nawet niekoniecznie to zawsze jest język programowania, czasem to są proste instrukcje.

Taką bardzo popularną platformą low-code’ową jest bardzo dobrze wszystkim znany Microsoft Excel. W momencie, w którym zaczynamy budować czy wykorzystywać funkcje w Excelu i używamy tego tak naprawdę języka funkcyjnego, to już zaczynamy programować w low-code. Ten język w ogóle ma nawet swoją nazwę: Power Fx.

Czyli chcesz powiedzieć, że jeżeli napiszemy tam „suma” i powiedzmy wiersze czy kolumny, to już możemy się nazwać programistami low-code?

Konsultantami. Trochę nie lubię, gdy na konsultantów czy osoby pracujące w low-code mówi się „programiści”. Po pierwsze to bardzo utrudnia komunikację z programistami, którzy czują się wtedy troszeczkę urażeni (i to utrudnia niestety współpracę z nimi). A po drugie to też odstrasza ludzi – jak myślą o tych narzędziach low-code i słyszą „programowanie”, to nagle pojawia się obawa: „ojoj, to lata studiów pewnie”. A to zupełnie nie tak. To jest tylko znajomość tych poszczególnych operacji, funkcji itd. I tyle. I można jak najbardziej z pomocą prostych składni budować rozwiązania.

Jak to rozróżnić: czym jest ten low-code a czym no-code? Gdzie znajduje się ta granica?

Wiesz co, wydaje mi się, że takie proste rozgraniczenie jest wyczuwalne dopiero już w samej platformie – w momencie, w którym zaczynasz budować rozwiązania i okazuje się, że już należy gdzieś wykorzystać jakiś język programowania czy zbudować jakieś funkcje. To jest taki główny wyróżnik.

Natomiast fakt faktem, wiele platform low-code’owych woli nazywać się no-code’owymi z tego powodu, żeby ludzie się mniej bali w nie wejść i z nimi zapoznać. Tak że to jest takie może troszeczkę marketingowo… nie chcę powiedzieć, że nieuczciwe, ale może nie dość precyzyjne.

To też wynika trochę z tego, że platformy no-code’owe w momencie, w którym się nie używa możliwości wykorzystania jakiegoś języka, to są no-code’owe. A w momencie, w którym zaczynamy budować w nich funkcje, stają się low-code’owe. Również każdą platformę low-code/no-code można rozbudować o funkcjonalności, których ona nie posiada, za pomocą normalnego języka programowania.

Czyli w zasadzie w przypadku takiego WordPressa, o którym wspomniałeś, część osób może być obrażona, bo do WordPressa w PHP-ie i pisze dużo rzeczy. Ale to prawda, że w WordPressie można wszystko wyklikać. Lecz jeżeli chcemy zrobić coś więcej, to też możemy: ostylować, napisać jakiś plugin czy stworzyć sobie jakiś motyw.

A jakie inne powszechnie znane narzędzia są low-code’owe czy no-code’owe?

Siłą rzeczy, ponieważ ja zajmuję się technologiami Microsoftu, to nie mogę nie wspomnieć o Power Platform, czyli Microsoft Power Platform. To jest tak naprawdę zestaw kilku platform pozwalających osiągać różne rezultaty.

I tak na przykład Power Apps służą do budowania aplikacji mobilnych i desktopowych – jest to więc prosty edytor pozwalający za pomocą przeciągania i upuszczania kontrolek budować ekrany. W momencie, w którym chcemy zbudować jakąś logikę między nimi (czyli jak np. kliknę na przycisk, to wyśle się mail albo zmieni się ekran, albo wykona jakieś obliczenie), to zaczynamy już wykorzystywać funkcję power fx-owe – czyli ten sam rodzaj funkcji, który mamy w Excelu.

Mamy też Power Automate, czyli narzędzie do automatyzowania i integrowania różnych aplikacji czy systemów. Na przykład: gdy pojawi się nowe nagranie na kanale YouTube, to chciałbym, żeby automatycznie poszło info na Twittera oraz e-mail, poszła jakaś informacja na moje urządzenie mobilne. Taką integrację możemy zbudować właśnie za pomocą Power Automate’a. Swoją drogą spopularyzowane na rynku narzędzia low-code’owe dookoła automatyzacji procesów to jeszcze np. Integromat, Zapier, IFTTT (czyli If This Then That). To są chyba takie pierwsze platformy, które pozwalały automatyzować.

Jeżeli chodzi o inne platformy dostępne w Power Platform, to mamy jeszcze Power BI, czyli narzędzie do analityki biznesowej i obsługi danych czy wyciągania z tych danych informacji i prezentowania ich pod postacią różnego rodzaju wykresów.

Muszę przyznać, że sam korzystam właśnie z takiego narzędzia, które nazywa się Make.com. Wcześniej był to właśnie Integromat. W zasadzie to nie byłem świadomy, że jest to low-code czy no-code. Po prostu bardzo dobrze mi się z tego korzystało, bo mogłem wiele rzeczy zautomatyzować i było super.

Mimo że jestem programistą, to wolałem to zrobić właśnie przy pomocy tej platformy, bo po prostu nie musiałem poświęcać na to czasu. Było wygodniej, i w zasadzie działało równie dobrze (jak nie lepiej). Po prostu większość błędów Make wyłapywał i nie musiałem się nimi martwić. Gdybym sam pisał te automatyzacje, to pewnie nie byłoby tak różowo.

No i też zapewne zbudowanie tych integracji zajęło Ci dużo mniej czasu niż jak miałbyś je kodować w PHP, Pythonie czy czymkolwiek innym.

Zdecydowanie tak.

Jakie są zalety korzystania z low-code’u?

Przede wszystkim wspomniana oszczędność czasu. Według mojej najlepszej wiedzy, mojego doświadczenia czas implementacji rozwiązania może się skrócić nawet 10-krotnie. Czyli zamiast poświęcać 10 tygodni, robimy rozwiązanie w tydzień. To jest ogromny zysk czasu, ogromna oszczędność.

Natomiast są też innego rodzaju korzyści, między innymi koszty finansowe implementacji. Bo to, że teraz pracujemy mniej nad rozwiązaniem, to są dla biznesu czy nawet dla nas samych mniejsze koszty budowy tego rozwiązania.

Mamy także koszty związane z ryzykiem inwestycyjnym. Wyobraź sobie, że masz problem do rozwiązania – integracja: jak wyślesz dokument klientowi, on wypełni jakiś formularz, to te dane trafiają do Twojego Excela. I teraz Ty byś chciał zbudować to Pythonem. Zaczynasz sobie kodować. Wszystko elegancko idzie i nagle się okazuje, że kurczę, właściwie to Ty nie przemyślałeś pewnej kwestii i musisz tam wprowadzić pewne drobne usprawnienie – to nagle dokłada Ci 20 godzin roboty.

Jeżeli w pewnym momencie by się okazało, że wszystko to, co teraz robiłeś, można było zaimplementować za pomocą platformy low-code, to właśnie wydałeś dodatkowo ekstra 60 godzin swojej pracy. W momencie, w którym zacząłbyś od razu z platformę low-code i doszedłbyś do momentu, w którym stwierdzasz, że pewne rzeczy nie zostały wcześniej dobrze przemyślane, to musisz dołożyć parę, maksimum paręnaście godzin do tego, żeby zweryfikować, czy kolejne założenie biznesowe będzie właściwe.

No i mamy też inne korzyści, jak np. to, że każda platforma low-code czy no-code pozwala na rozbudowę o jakieś funkcjonalności za pomocą tradycyjnych języków programowania. Nie jest więc tak, że wchodząc w low-code/no-code nie możemy już użyć innych języków.

Mamy także coś, co mi jako programiście bardzo się podoba – używając platform no-code, bardzo szybko jestem w stanie zaimplementować powtarzalne, proste rzeczy, które mnie zawsze nużyły, czyli na przykład budowa formularza, obsługa pól: jakiego typu będą, jeżeli to będzie lista drop-down, to jakie tam będą opcje itd. To się bardzo szybko, prosto klika.

Natomiast ja jako programista bardzo lubiłem poświęcać swój czas na nietypowe, nietuzinkowe problemy. Lubiłem usiąść i rozkminić jakiś temat – tak hardo. Używanie platform low-code/no-code, w szczególności w biznesie konsultingowym, pozwala programistom poczuć się jak jednostki specjalne na polu walki. Jesteśmy w stanie naprawdę skupić się tylko na tych trudnych, nietuzinkowych problemach, a nie na wszystkim tym, co musi zostać gdzieś tam okodowane.

Zdecydowanie tak. W pełni się zgodzę. Dodam, że ta platforma, o której wspominałem, ma powiedzmy (nie pamiętam ile) 100 wtyczek, 100 różnych rozwiązań, dodatków, a do tego jeszcze posiada uniwersalne rozwiązanie do API. Czyli w zasadzie jeżeli mam dostęp do jakiegoś API, to mogę pobrać te dane przy pomocy Make’a i coś z nimi zrobić.

To jest mega fajne, bo nie muszę pisać swojego kodu, tylko tak naprawdę wyklikuję sobie wszystkie rzeczy i mam to, co potrzebuję.

W zasadzie jakiś czas temu napisałem własnego bota do Slacka, żeby pomagał mi w mentoringu. Dopiero potem trafiłem na Make.com. Okazało się, że to, co ja pisałem, powiedzmy, tygodniami, mógłbym zrobić w jeden tydzień.

No właśnie. A tak z ciekawości, co ten bot robi?

Sprawdza, kto kiedy wrzucił pull request czy zrobił forka na GitHubie, i wysyła tej osobie dodatkowe materiały. Zgłasza jej też, że sprawdziłem już zadania itd. Jest to więc taka pełna automatyzacja moich działań związanych z zadaniami, projektami, code review itp.

To teraz może słabe strony, bo pewnie niekoniecznie musi być tak super.

Oczywiście, że tak. Nic nie jest idealne i low-code/no-code oczywiście mają swoje down sides, jak to się ładnie mówi. Taką najpopularniejszą wadą albo ograniczeniem czy też ryzykiem związanym z używaniem platform low-code/no-code jest uzależnienie od dostawcy.

W momencie, w którym na przykład wykorzystujemy Make.com, zbudujemy na tym jakieś rozwiązanie i nagle Make.com się zamknie albo podwyższy licencję, a Ty nie będziesz chciał płacić więcej, to nie możesz prostym eksportem-importem przerzucić rozwiązania na inną platformę – czyli nagle przerzucić się np. na Power Automate’a, Zapiera czy cokolwiek. To jest niestety w pewien sposób już gra w jedną stronę. Jeżeli trzeba by przenieść to na inną platformę, to trzeba by to w tej innej platformie wyklikać zupełnie od zera.

Był taka sytuacja – atak hakerski. Co prawda padła strona główna, a automatyzacje nie, ale faktycznie o tym trzeba pamiętać. W moim przypadku dużo rzeczy przestałoby działać.

No to też jest inna sprawa, że platforma sama w sobie powinna umożliwiać mechanizm eksportu i importu. Przykładowo w Power Apps i w Power Automate jestem w stanie wyeksportować sobie taki automat czy taką aplikację i potem zaimportować ją jeszcze raz w tym samym miejscu albo w środowisku innego klienta. Ale właśnie: mogę to zrobić tylko w ramach Power Automate’a, a nie, że nagle wrzucę to na inną platformę.

Jak już mówimy o takim uzależnieniu od dostawcy, co się ładnie w branży nazywa vendor lockiem, to jest też kwestia licencyjna. Zaczynamy pracować z Power Atomate’em albo z Power Apps i jeżeli Microsoft w pewnym momencie uzna, że koszty licencji trzeba zmienić (a historia zna takie przykłady), to, no to cóż, nie mamy wyjścia: płacimy więcej. Albo mniej. Raczej więcej. Chociaż historia też zna przykłady, że Microsoft najpierw podwyższył koszty, a potem je obniżył, bo stwierdził, że podwyższył za bardzo. Teraz skojarzyło mi się to z Elonem Muskiem, który wyrzucił programistów, a potem chciał ich przyjmować. Takie tam…

Inną kwestią jest to, że takim wyzwaniem związanym z korzystaniem z platform low-code/no-code jest to, że niektóre platformy nie są dostosowane do europejskich zasad RODO, czyli tego popularnego GDPR – regulacji związanych z udostępnianiem danych osobowych. Rynek amerykański nie jest pod tym kątem taki restrykcyjny, więc platformy, które działają w Ameryce i nie są dostosowane do europejskiego rynku, na pewno nie będą mogły znaleźć zastosowania w biznesach, które są mocno powiązane finansowo, prawnie z rynkiem polskim.

Jeżeli chodzi o inne down sides, czyli te problemy, wyzwania związane z platformami low-code/no-code, to ważne jest, aby pamiętać, że jeżeli chodzi o złożoność rozwiązania, które chcemy zbudować, żadna z tych platform – nawet jeżeli zaakceptujemy wyzwania licencyjne bądź vendor lock – nie jest uniwersalna. Czyli jeżeli np. chcemy w firmie postawić system klasy ERP, to nie będziemy go budować na low-code. Absolutnie nie. Są do tego dedykowane systemy z odpowiednim silnikiem pod spodem, odpowiednimi funkcjonalnościami dostosowanymi do branży.

Platformy low-code są raczej do małych i średnich rozwiązań. Ważne też, aby pamiętać, że jeżeli np. pomyślimy sobie „a, fajnie by było zbudować taką własną platformę, która jest targetowania np. w rynek marketingowy”, to nie zbudujemy jej za pomocą low-code’u. To jest platforma sama w sobie i możemy za jej pomocą budować różnego rodzaju inne rozwiązania, tzw. software as a service lub functions as a service, czyli systemy, które możemy użyć. No właśnie, jak to wytłumaczyć? Systemy, które możemy użyć w zakresie, w jakim one na to pozwalają. Chociaż w sumie można by tak opisać wszystko. Nie wiem, jak wytłumaczyć software as a service.

Może po prostu oprogramowanie, które udostępnia się wszystkim? Jest ono raczej realizowane zdalnie. Może w ten sposób.

Ale ja bym też tak opisał np. platform as a service czy infrastructure as a service. Osobom, które nie rozumieją różnicy pomiędzy FaaS, SaaS, PaaS, IaaS czy w ogóle jakichkolwiek „saasów”, ciężko jest tak to wytłumaczyć. Jaka jest różnica? Wiem, że np. z SaaS-em będzie Gmail, czyli usługa, którą ja sobie używam, ale nie mogę zbudować w niej jakiegoś rozwiązania, jakiegoś SaaS-a wewnątrz tego. Gmail jest SaaS-em, Facebook jest SaaS-em. No właśnie, budowanie na platformach low-code/no-code to zawsze jest budowanie jakiegoś rodzaju SaaS-a albo FaaS-a, czyli funkcji jako usługi.

Tak że to są, myślę, takie najpopularniejsze wyzwania związane z tymi platformami, które w czasie nie będą jakoś ulegać degradacji. Natomiast jest jeszcze ostatnie wyzwanie, o którym wspomnę, które z czasem będzie się bardzo zmniejszać, czyli brak odpowiednich specjalistów na rynku. Jeżeli masz jakieś wyzwanie, zaczynasz pracować z Make.com, to o ile sam sobie tego nie wykminisz, to ciężko znaleźć na rynku specjalistów. Są być może jacyś freelancerzy na jakimś tam Fiverrze czy Useme.com. Jest ich tam może kilku-kilkunastu, ale zdecydowanie nie jest to tak popularna specjalizacja jak teraz Python czy React developer. Natomiast kwestią czasu jest, by to się zmniejszyło – bo wraz z popularyzacją tych platform będzie rósł rynek pracowników.

Jestem programistą, a ten temat jest dla mnie naprawdę bardzo ciekawy, bo widzę ogromną liczbę korzyści płynącą z takich rozwiązań. Sam chętnie zrealizowałbym kilka projektów, wykorzystując właśnie tego typu platformę jak na przykład Make. Akurat z Anią robiliśmy tam dużo rzeczy – bardzo dobrze tę platformę poznaliśmy i bardzo nam pasuje. Jak by ktoś chciał coś w Make’u zautomatyzować, może się zgłosić do nas.

Wydaje mi się, że część programistów może też przejdzie właśnie do tego typu programowania. Sam mówiłeś, by nie nazywać tego programowaniem, czyli powiedzmy: do takiego rozwiązywania problemów. Bo to jest fajne. Przynajmniej mi się bardzo podoba.

Powiedziałeś, że to jest fajne. I to mi się od razu skojarzyło z tym, co mówią pracownicy u mnie w firmie. Ja zatrudniam ludzi, którzy wcześniej studiowali psychologię albo byli po marketingu, albo po jakiejś tam inżynierii budowlanej. To, co oni bardzo sobie cenią w platformach low-code, pracując z nimi u klientów, to jest właśnie to, że szybko widzą efekty swojej pracy. I to jest dla nich mega, mega fajne.

Bo kiedy np. organizujesz kampanię marketingową, to to jest bardzo złożony temat – trzeba przewidzieć, co się wydarzy w trakcie życia kampanii. Wystarczy Ci wojna na wschodzie i nagle wszystkie Twoje komunikaty marketingowe mogą być trafione kulą w płot, bo ludzie są już totalnie zaangażowani w inny obszar i nie zwracają uwagi na Twoją komunikację, którą przecież miałeś super rozkminioną. A w przypadku budowania rozwiązań low-code/no-code wiadomo, co ma być na koniec – tam jest to zerojedynkowe. Albo działa, albo nie działa. Jak działa, to znaczy, że dobrze działa i tyle. I to jest dla ludzi bardzo motywujące – by dalej się rozwijać i wykorzystywać te rozwiązania.

Mam już przygotowane kolejne pytanie. W zasadzie już poprzednio na nie, powiedzmy, odpowiedziałeś, ale może niech wybrzmi. Czy trzeba znać jakiś język programowania, by w ogóle zacząć korzystać z narzędzi low-code? Jeśli tak, to co byś polecał? Jeżeli nie, to od czego w ogóle zacząć?

Żeby pracować z platformami no-code, absolutnie nie jest potrzebna jakakolwiek znajomość języków programowania. Jeśli mówimy już o low-code, to znowu: nie trzeba ich znać, chociaż warto mieć jakieś doświadczenie, ponieważ już same funkcje w low-code wymagają już pewnych aspektów znanych programistom, jak na przykład wykorzystywanie zmiennych, operacji warunkowych (czyli if…else), robienie różnego rodzaju pętli. To są takie proste znane programistom i programistkom koncepcje, które na pewno się przydają.

Jeżeli natomiast ktoś zupełnie nie programował, a chciałby w to wejść, to wystarczy, że na przykład wejdzie sobie do Excela i zacznie korzystać z jego funkcji. To już jest, myślę, takie pierwsze przetarcie z tym, jak może wyglądać budowanie zależności czy logiki aplikacji na platformie klasy low-code.

W Twoim przypadku wyglądało to tak, że najpierw byłeś programistą, a potem zainteresowałeś się low-code’em. A co jeśli ktoś chciałby iść w drugą stronę: planuje być programistą, ale takim przystankiem miałby być low-code? Czy to uważasz za dobrą drogę?

Zdecydowanie tak, ponieważ tak jak powiedziałem, low-code zawiera pewne elementy znane programistom, ale w ogóle nie uwzględnia mnóstwa innych złożonych obszarów, takich jak obiektowe abstrakcje czy hermetyzacja. W związku z tym małymi krokami możemy zacząć uczyć się nowej dziedziny, jaką jest w IT, i zdobywać też doświadczenie w pracy.

Z kolei to, na czym wielu programistów się wykłada, i może to, co jest przyczyną długiego procesu kształcenia w IT, to to, że poza samym językiem programowania trzeba nauczyć się pracować w zespole, trzeba poznać strukturę czy charakterystykę pracy w projektach IT. I znowu: mamy projekty IT w firmach produktowych, mamy charakterystykę projektów IT w firmach konsultingowych, czyli w firmach usługowych. To jest zupełnie inny projekt IT i również kupa rzeczy do nauczenia.

W związku z tym wejście w low-code pozwala z jednej strony troszeczkę dotknąć tego środowiska pracy w IT, z drugiej strony poznać troszeczkę programowania – ale nie za dużo, co nie przytłoczy. Jeżeli komuś będzie mało, to super. To w takim razie może zrobić następny krok i zacząć uczyć się jakiegoś języka programowania. Ba, mało tego, wybór języka programowania będzie dużo prostszy. Bo jeżeli ja zacząłem pracować np. z platformami Microsoftu i robię rozwiązania w Power Apps, to automatycznie pierwszym językiem programowania, po który powinien sięgnąć, jest tę technologię, którą można rozbudowywać aplikacje power appsowe, czyli to będzie .NET, C# albo React.

Od czego poleciłbyś zacząć naukę low-code’u? I czy coś innego byś polecił osobie, która już programuje, i osobie, która dopiero chce zacząć?

Spróbowanie low-code’u polecam zdecydowanie każdemu programiście, ponieważ to nie jest platforma, którą on już będzie miał używać całe życie. To ma być bardziej taki jego podręczny zasobnik, z którego może korzystać w sytuacjach, w których nie chce mu się czegoś robić (albo można coś zrobić szybciej, prościej), a on by wolał swój czas poświęcić na coś innego, coś bardziej skomplikowanego.

Poznanie tych narzędzi to dla programistów jest jak kichnąć, naprawdę. Tam nie ma nic złożonego poza zrozumieniem, o co chodzi w tej platformie. Nie trzeba uczyć się jakiegoś specjalnego języka. Nie, to wszystko jest już bardzo proste. Zdecydowanie więc bardzo polecam takim osobom poznać te platformy.

Inna częsta sytuacja jest taka, że programiści czasem są zmęczeni programowaniem i być może chcą już troszeczkę od tego uciec. Low-code pozwala z jednej strony wykorzystywać ich umiejętności, ale jednocześnie daje im przestrzeń do tego, żeby np. nauczyć się zupełnie inne dziedziny, jak na przykład zarządzanie w biznesie. To jest mój case. Ja już nie chciałem być programistą, chciałem rozwijać się w innych obszarach i takie budowanie rozwiązań w low-code pozwoliło mi odzyskać trochę czasu, który z kolei mogłem poświęcić na to, by zrozumieć, na czym polega sprzedaż, na czym polega marketing, na czym polega zarządzanie finansami, administracja.

A jeżeli chodzi o osoby, które chcą wejść w temat low-code’u, a nie są programistami, to czy jest taka platforma, która będzie dla nich łatwiejsza?

Szczerze mówiąc, tych platform na rynku jest mnóstwo. Każda z nich jest piękna, prosta, przyjemna. Naprawd. Jeżeli chcemy budować aplikacje biznesowe, to mamy do wyboru Power Apps, Bubble.io, Betty Blocks. Mógłbym tych platform wymienić jeszcze przynajmniej z 6 – jeżeli chodzi o aplikacje biznesowe. Mamy też aplikacje związane z automatyzacją. Jest tego mnóstwo.

Więc teraz – co wybrać? Powiem szczerze: pytanie, czy mamy jakiekolwiek skojarzenia z jednym z tych dostawców. Jeżeli np. od zawsze pracowaliśmy z technologiami Microsoftu albo po prostu lubimy Microsoft, to automatycznie sięgnijmy po ich technologie. Jeżeli zawsze lubiliśmy Google, to sięgnijmy po google'owe technologie. Jeżeli nigdy nie czuliśmy się związani z żadnym z dużych vendorów, to popatrzmy sobie na strony dostawców danych platform i wtedy wybierzmy to, co nam się bardziej podoba.

Jest też pytanie, jaki mamy w tym cel. Bo jeżeli zależy nam na pracy, no to znowu: chcemy pracować dla małych klientów czy dla dużych klientów? Mali klienci będą pewnie związani bardziej z Bubble'em, Webflowem, a duzi z kolei będą pewnie bardziej związani z dużymi dostawcami, takimi jak Microsoft.

A jak wygląda taki dzień pracy programisty low-code? Już wspomniałeś, że programista to może nie jest dobra nazwa, ale wiadomo, o co chodzi.

Tak naprawdę dzień pracy polega na tym, że buduje się rozwiązania, ale jednocześnie pracuje się dużo bliżej klienta. Taka osoba, która już nie musi tyle czasu poświęcić na implementację i nauczenie się programowania, może więcej swojej energii poświęcić na to, żeby zacząć wsłuchiwać się w potrzeby klienta, zacząć analizować to, co on chce uzyskać.

To znaczy, że jeżeli przychodzi klient i mówi „dużo czasu tracimy na przerzucanie danych z Excela dokądś tam”, no to wtedy można zacząć dopytywać: „ok, to jakiego rodzaju są to informacje, jaki system jeszcze trzeba by zintegrować” itd. Rozumienie środowiska pracy klienta i analizowanie jego potrzeb biznesowych to jest coś, co jest chlebem powszednim u konsultantów low-code.

Bardzo często też pracuje się w zespołach, więc automatycznie umiejętność pracy w zespole jest mile widziana. Chociaż zespoły low-code’owe nie są tak duże jak zespoły IT. Największy mój zespół, który działa na projekcie, to jest 5 osób, a średnia wielkość zespołu to są 2 osoby na projekcie.

Powiedz nam, proszę, jakie zawody są ściśle związane z low-code’em?

Przede wszystkim związane z branżą IT. Czy to będą analitycy biznesowi, czy to będzie PM, czyli Product Manager, albo PO, czyli Product Owner, czy to będą osoby związane z designem – UI/UX (w jakiejkolwiek branży, bo to nie znaczy, że design jest tylko aplikacyjny) – to tutaj zdecydowanie jest to pierwszy taki wybór, czy może najlepszy wybór dla tych osób, gdyby były tym zainteresowane.

Jeżeli natomiast chodzi o osobę spoza branży IT (jakkolwiek z nią niezwiązaną), to znowu: wybór jest dość szeroki, bo tak jak mówiłem, u mnie pracują ludzie po psychologii, po inżynier środowiska i po marketingu. Są to ludzie, którzy w jakiś sposób lubili usprawniać swoją pracę, nie byli, że tak powiem, osobami, które lubią robić ciągle to samo, tylko ciągle szukali czegoś do usprawnienia, ciągle myśleli „a jak mógłbym/mogłabym to zrobić lepiej, szybciej, prościej?”. Myślę, że dla takich osób – niezależnie od ich wykształcenia czy dotychczasowego doświadczenia – praca w platformach low-code w branży IT to jest dla nich absolutnie dobry kierunek.

To teraz chyba nadszedł czas na trudne pytanie. Czy według Ciebie low-code może spowodować, że firmy zrezygnują z programistów? Może to się już dzieje? Jak myślisz, jak to będzie wyglądać?

Zdecydowanie nie. To znaczy: programiści zawsze będą na rynku potrzebni. Obecnie jest ogromny niedobór programistów. Jak byśmy sobie rozrysowali wykres funkcji w czasie zapotrzebowania na programistów oraz obecnie małą liczbę programistów, to zanim te dwie linie się spotkają, to jeszcze mamy spokojnie kilka lat kształcenia, edukowania i ułatwiania procesu implementacyjnego.

Natomiast programiści, którzy umieją programować, to będą osoby, które są w stanie bardzo łatwo zmienić troszeczkę swój obszar działalności. Czyli jak wczoraj programowałem stronę WWW i nagle mamy WordPressa, to jutro mogę programować aplikacje na urządzenia mobilne. Programiści więc nigdy nie przestaną być potrzebni. Zresztą ba – ktoś musi budować tę platformę low-code. Więc to nie jest tak, że oni nie będą potrzebni. Zdecydowanie uprości się natomiast ta część ich pracy, która do tej pory była monotonna, żmudna i w jakiś sposób powtarzalna.

Może jesteś w stanie coś polecić programiście, który chciałby sobie usprawnić trochę codzienną pracę. Z jakich narzędzi mógłby skorzystać, żeby móc przyspieszyć swoje działania?

Powiem szczerze: jest takie powiedzenie wśród programistów, że jeżeli musisz zrobić coś po raz drugi, pomyśl o automatyzacji. Jeżeli musisz zrobić coś po raz trzeci, to zautomatyzuj to. Myślę, że jeżeli jest jakiś programista, który robi tę samą rzecz po raz drugi, po raz trzeci, to warto, żeby od razu sięgnął po jakieś narzędzie do obsługi tego. Jaką platformę polecić? To tak na dobrą sprawę zależy od tego, co chcemy zrobić.

Przykładowo: za każdym razem, gdy przychodzą nam maile z jakąś umową, z jakimś dokumentem, to my je musimy wsadzić do odpowiedniego folderu na dysku (czyli gdzieś je zrzucić). Bardzo prosto można to zautomatyzować przykładowo Power Automate’em, gdzie każdy nowy mail może być analizowany pod kątem tego, czy posiada załączniki, od kogo ten mail jest wysłany, może są już w tym mailu jakieś informacje, które mogą nam się przydać do tego, żeby zlokalizować odpowiedni folder, do którego ten załącznik powinien być zapisany. I wtedy możemy tam to zrzucić.

Przypomniała mi się jedna historia. Nie wiem, na ile to jest prawdziwe, ale słyszałem o takiej osobie, która pracowała na stanowisku, powiedzmy, analitycznym, i miała przygotowywać raporty. Stworzyła więc taką automatyzację, która robiła wszystko i przez rok w zasadzie siedziała i grała. Więc można.

Słyszałem. To chyba była nawet prawdziwa, gdzieś tam opisywana historia. Gdy się okazało, że ta osoba tylko grała, to miała chyba jakieś konsekwencja albo jakieś nieprzyjemności w firmie.

Możliwe. Może się okazać, że nasi słuchacze mogą zautomatyzować swoją pracę i swój czas pracy wykorzystywać w inny sposób.

Podsumowując naszą dzisiejszą rozmowę – co wybrać: low-code czy jakiś język programowania?

To jest, powiem szczerze, trudne pytanie. To jest troszeczkę tak, jak byś szukał samochodu i zapytał: „jaki samochód wybrać?”. Pytanie teraz, czy jesteś przyzwyczajony do jakiejś marki, do czego ten samochód: czy sportowy, czy rodzinny, czy do przewożenia dużych ładunków. Wszystko zależy od tego, czego się szuka i czego się potrzebuje.

Wiem, że to trochę takie odbijanie piłeczki – Ty pytasz „co wybrać”, a ja na to „a czego szukasz?”. Niestety trzeba sobie odpowiedzieć na pytanie, dlaczego chciałbym w ogóle poznawać taki język czy taką platformę. Czy ja chcę zdobyć pracę? Czy chcę coś uprościć? Czy może chcę być na bieżąco z tym, co się dzieje w technologii, bo np. piszę artykuły do jakiejś gazety? Wszystko zależy od Twoich potrzeb.

Z mojej perspektywy, tak życiowo, na pewno warto umieć programować, ale z drugiej strony nie jestem przekonany, czy warto znać cały język jako taki. Może lepiej poznać tylko najprostsze obszary, koncepcje, paradygmaty programowania: obiektowość, instrukcje warunkowe, pętle itd.

Jeżeli chodzi natomiast o perspektywę osób, które nie są w IT i dopiero chciałyby wejść do IT, to co wybrać: język programowania czy low-code? Absolutnie, absolutnie lepiej jest wejść w low-code choćby z tego powodu, że (jestem przekonany, że) te osoby, gdyby weszły w język programowania, to zostaną przytłoczone tym, jak skomplikowane są języki programowania. Jeżeli ktoś wcześniej nie programował, to niech nie wierzy zapewnieniom, że można się tego nauczyć w rok. Nie ma takich szans. Nikt nie zostanie dobrym programistą w rok od zera – to jest pierwsza rzecz.

Druga rzecz jest taka, że jak się wchodzi na projekty IT, to cały ten proces software development lifecycle, czyli SDLC, to też jest kupa informacji, które trzeba przetworzyć i przyswoić. To nie są proste rzeczy. Może inaczej: nie wszystkie są skomplikowane (żeby też nie odstraszyć), ale jest ich po prostu dużo. Nie są trudne, ale jest ich dużo. Naprawdę więc uprośćmy sobie życie: zacznijmy od low-code’u, a jak będzie nam mało, to spokojnie do tego programowania, tego tradycyjnego software developmentu zawsze będziemy mogli wskoczyć.

To ja może tylko powiem jedną rzecz. Wspomniałeś, że nie można zostać dobrym programistą w rok. Ale w rok można znaleźć swoją pierwszą pracę w IT. Wiadomo, że to cały proces.

Oczywiście, że tak. Mówiąc „dobrym programistą” miałem na myśli regulara. Nie jesteś w stanie w rok zostać regularem. Można w rok znaleźć pracę jako junior – jak najbardziej. Ale na stanowisku regulara po roku nauki pracy nie znajdziesz. A z kolei w low-code/no-code jak najbardziej da się to zrobić.

Gdzie możemy śledzić tematy low-code’owe? Masz może jakichś ulubionych twórców, podcasty, kanały, eventy?

Po pierwsze jest taka fajna, duża konferencja zupełnym przypadkiem organizowana przeze mnie: No Code Days. Mieliśmy wydarzenie 12-13 października, dwudniowa konferencja na żywo – offline’owo, ale była też opcja uczestniczyć online’owo. Było łącznie 350 osób. Mega klimat, mega ludzie, mega konferencja, mega tematy. Będziemy robić powtórkę w przyszłym roku – pewnie przełom kwartału trzeciego, czwartego, w związku z czym wrzesień/październik – można się spodziewać, że wtedy to wydarzenie będzie miało miejsce. Nie znamy jeszcze szczegółów – plany zostawiliśmy sobie na styczeń.

Kolejny ciekawy projekt, który będzie startował w styczniu i powoli rośnie w internetach, to NoCodeMasters.com. Ma to być w założeniu miejsce, w którym będzie można pozyskać informacje ze świata low-code/no-code, dowiedzieć się o nowościach, ale również zdobyć wiedzę.

Jest już kanał youtube’owy, który zupełnym przypadkiem prowadzę od jakiegoś czasu: No Code Masters. Na razie są to materiały głównie polskojęzyczne, ale docelowo pojawią się też pewnie anglojęzyczne.

Nie mógłbym też nie wspomnieć o podcaście, który nie jest do końca dookoła low-code/no-code, bo jest on głównie o technologii, o biznesie, o pracy w zespole, ale tworzą go osoby z tejże branży. W związku z tym czasem pojawiają się tematy dookoła low-code/no-code. Jest to podcast Draft Rozmowy, który współtworzę ze wspólnikami. Rozmawiamy na różne tematy. Ostatnio rzeczywiście był odcinek na temat low-code’u i o tym, dlaczego programiści go nie lubią. Odcinek wcześniej był o mentorshipie, o mentorowaniu – czy warto mieć coś takiego w firmach i czy my to lubimy. A odcinek jeszcze wcześniej było o kolorach osobowościowych, czyli takie miękkie rzeczy dookoła zarządzania w IT. Myślę, że można tam dowiedzieć się ciekawych rzeczy.

To jeśli chodzi o konferencję, to ja już się zapisuje, jestem chętny, proszę o mnie pamiętać.

A jaką książkę poleciłbyś osobie, która chce się rozwijać w obszarze low-code/no-code?

Pamiętam, jak czytałem taką książkę Symfonia C++ (jedna z moich pierwszych książek do programowania) napisaną przez Jerzego Grębosza. On tam napisał zdanie, które zapamiętałem na całe życie. To jest niesamowite. Ja tę książkę czytałem na studiach i żadne zdanie nie wpłynęło tak mocno na moje życie, jak to jedno zdanie w tej książce. To było zdanie: Żeby pisać, trzeba pisać. Innymi słowy chodzi przede wszystkim o praktykę, o to, że żadna teoria nie da Ci tyle, co własna praktyka – w szczególności w programowaniu.

Łatwo to sobie przenieść na innych obszar, czyli na świat realny i na budownictwo: czy czytając o tym, jak buduje się mury, jesteś w stanie się tego nauczyć? Nie. Musisz zacząć budować mury. Wtedy pomimo tego, że będziesz mieć najlepszą wiedzę, na pewno popełnisz jakieś błędy, nie wymierzysz dobrze odległości albo nie postawisz sobie linek, które by Ci dawały odniesienie do tego, żeby cegły były równo ustawione, albo zaczniesz kłaść za dużo papy. Zawsze popełnisz jakieś błędy, które wychodzą dopiero w praktyce. Tak samo jest w programowaniu.

Jeżeli więc miałbym polecić komuś jakąś książkę, to najlepiej… nie tracić czasu na książkę, tylko odpalić sobie jakąś platformę, poszukać o niej na YouTubie, pouczyć się i samemu zacząć coś budować. To jest najlepsza forma zdobywania wiedzy.

Powinniśmy nagrać na swoje kanały odcinek, w którym mówimy: „samo oglądanie niewiele daje, pamiętaj, żeby pisać kod”. U osób, z którymi współpracuję, jest taki problem, że oglądają bardzo dużo różnych kursów, a bardzo mało kodują. Gdy oglądamy, wydaje nam się to fajne i proste, a jak trzeba napisać coś samemu, to jest duży problem.

Tak, to prawda. Ja też mam swoje kursy i to, co bardzo przydało się moim kursantom, to to, że po każdym module jest praca domowa na podstawie ostatnich lekcji. Kurs u mnie jest tak zbudowany, że kolejne moduły korzystają z tych poprzednich, prace domowe też są kontynuacją. Więc takie zmuszanie do praktyki…

Nie da się oszukiwać.

Nie da się oszukiwać, ale też to takie motywowanie do własnej pracy w praktyce to jest, myślę, coś, co warto by było uwzględnić w swoim kursie.

Zdecydowanie tak. Praktyka, praktyka i tylko praktyka naprawdę da nam umiejętności. Dodam tutaj, że u mnie też są zadania i projekty i to naprawdę daje bardzo duży efekt. Bardzo ważny też jest feedback. Nie wiem, jak u Ciebie jest to realizowane, ale u mnie wszyscy sobie też chwalą code review – dla nich jest to game changer.

Wow.

Ale dobra, zostawmy ten temat…

Ale dlaczego, to jest bardzo ważny temat! Myślę, że na tym polega teraz kształcenie nowego narybku wśród programistów – żeby pokazywać, że nie chodzi tylko o znajomość technologii, ale też o współpracę między ludźmi, o ten feedback, o to, żeby Ci ludzie trochę przeskakiwali swoje ograniczenia. Trzeba pomagać im przeskakiwać te ich ograniczenia, np. lenistwo albo to, że człowiek zamyka się w takim limbo wiecznego ostrzenia piły. Jest to problem: wiecznie ostrzymy piłę i nigdy jej nie użyjemy.

Zdecydowanie tak.

Na koniec: gdzie możemy Cię znaleźć w sieci?

Najlepiej na LinkedInie. Staram się być aktywny na swoim kanale linkedinowym, więc tam najlepiej do mnie uderzać, dodać do znajomych, napisać wiadomość. Zawsze odpisuję. Więc tak: to jest najlepsze miejsce.

No to super. To pamiętajcie: Michał Guzowski na LinkedInie. A ja Tobie, Michale, bardzo dziękuję za podzielenie się z nami swoimi doświadczeniami i wiedzą.

Dzięki serdeczne jeszcze raz za zaproszenie i za bardzo fajną rozmowę – także przed, także przed!

Dzięki, hej.

Na razie.