W jaki sposób firma może łączyć pracę programistów z grafikami tak, żeby uniknąć nieporozumień pomiędzy nimi?
Myślę, że przede wszystkim najważniejsze jest zapewnienie bezpośredniej komunikacji pomiędzy programistami, a grafikami. Dystans też jest bardzo ważny. Nie wyobrażam sobie, aby programiści nie mieli możliwości komunikacji czy spotkania się z grafikiem. W zapakuj.to kładziemy też duży nacisk na wysokiej jakości narzędzia: Slack, Asana, Marvel, Avocode, Sketch, Figma, Zeplin – każde z nich gwarantuje bezpośrednią komunikację dla obu stron. Nasze procesy są transparentne, a wczesny feedback mile widziany.
Zachęcamy do samodzielności, unikamy “głuchego telefonu”. Muszę też podkreślić, że bardzo dużo zależy też od ludzi i ich charakteru. Nasz team tworzą otwarci, dociekliwi ludzie, którzy nie mają obaw zadawać nawet tych najbardziej oczywistych pytań.
Czy początkujący programista powinien uczyć się programowania w sposób kursowy czy może powinien zacząć naukę od stworzenia własnego projektu, do którego ukończenia sam będzie wybierał lekcje, które są mu potrzebne?
To zależy. Dobrej jakości kursy na pewno w niczym nie przeszkodzą, a mogą wstępnie “ułożyć” początkującego programistę. Kursy to też dobry moment, aby się przekonać “czy, aby na pewno programowanie jest czymś dla mnie”. Na pewno nie jest dla wszystkich.
Nie chcę zabrzmieć nader sceptycznie, ale na tak wczesnym etapie “własne projekty” rzadko się udają. Dlaczego? Rzadko kiedy “własne” projekty mają zamknięty scope, sztywny deadline i niezbyt wygórowane wymagania. Moim zdaniem lepiej jest podjąć ryzyko i zaproponować znajomemu postawienie prostej strony czy też zautomatyzować jakieś zadanie. To nie musi być jeszcze płatne, poważne zlecenie. Chodzi o to, żeby nie utknąć na etapie rzeczy nieważnych, takich jak wybór frameworków, sposób organizacji plików czy czytanie setek tutoriali. Deadline to rewelacyjny motywator do faktycznego napisania pierwszych linii własnego kodu.
Pierwszy krok jest zawsze trudny. Programowania uczy się w 90% programując. Lubię powtarzać, że to trochę tak jak ze skokiem w przepaść. Będzie strach, będzie ciężko, ale spadając nie pozostaje nam nic innego niż znalezienie rozwiązania i wyjście z tego cało. Nie warto czekać, w programowanie trzeba po prostu wejść. Nikt nie mówi, że będzie łatwo, w końcu to bardzo skomplikowana profesja.
Jaki rodzaj projektu powinien zrealizować według Ciebie początkujący programista? Co umożliwi mu liźniecie odpowiednich dla jego poziomu aspektów programowania i jednocześnie będzie dla niego możliwe do zrealizowania?
Trudne pytanie. Powiem tak: nawet najprościej wyglądająca strona może okazać się sporym wyzwaniem nawet dla doświadczonego developera. Sam zresztą sparzyłem się na tym, że “pusty, prosty” design okazał się jedną z trudniejszych rzeczy, które pisałem, a to był tylko CSS!
Natomiast przed projektem polecam spotkać się z doświadczonym, znajomym programistą i wspólnie ocenić poziom trudności. Dzięki doświadczeniu zwraca się uwagę na rzeczy, których gołym okiem nie widać.
Uważam, że odpowiedzi w stylu “prosta, statyczna strona”, czy “formularz w PHP i zapis do bazy” są zbyt pochopne.
Powiedź coś jeszcze o tym trudnym projekcie.
To była “prosta” strona, dwie podstrony, dla dźwiękowca pracującego przy filmach i reklamach. Stronę zaprojektował mój znajomy i zaangażował w projekt. Layout strony składał się z dużych zdjęć poukładanych jak kafelki, czasami parami, czasami pojedynczo, czasami czwórkami. Najechanie myszą na czarno-białe obrazki powodowało animację do kolorowego oryginału.
Wygląda to naprawdę prosto. Projekt ten można pewnie w parę minut zrobić nawet PowerPointem. Natomiast ja spędziłem ponad 20 godzin dopracowywując to tak, aby ten layout faktycznie “działał”. Miałem duże problemy z CSS: kwadratowe skalowalne containery, wyrównywanie zdjęć background-image: cover ale z wykorzystaniem tagu <img>, czy też fakt, że w Safari animacja do koloru powodowała stałe 100% użycie procesora. Jak tylko udało mi się coś naprawić w Chrome, psuło się w Safari. I na odwrót. Przez moje pierwsze dwa lata w zawodzie, musiałem wspierać IE8, IE10 oraz starsze Firefox i Safari. To mi dużo dało. Wtedy nie było flexboxa, gridów itd. Dzięki temu doświadczeniu w końcu podołałem. Udało się.
Jaki typ ludzi wg Ciebie najbardziej marnuje się przez brak podjęcia próby nauki programowania? Kto najczęściej nie dostrzega tkwiącego w sobie talentu?
Całe życie z jakiegoś niewiadomego mi powodu bałem się programować. Już we wczesnej podstawówce tworzyłem strony w HTML, rozwiązywałem masę Windows-owych bugów, konfigurowałem domowe sieci Wi-Fi. Jednak zawsze czułem strach przed programowaniem. Dopiero w moim pierwszym startupie okazało się, że jako techniczny co-founder programując mogę rozwiązać masę problemów, że jestem w stanie budować i rozwijać nasz produkt.
Programowałem bez tutoriali, bez jakiejkolwiek wiedzy, często “na żywo”. Czytałem istniejący już kod, zmieniałem jego części, wklejałem rzeczy z internetu. Szło mi topornie, ale nie poddawałem się. Pochłaniało to mnóstwo czasu, ale nie odczuwałem tego.
Myślę, że jeżeli czyta to osoba, której zdarza się niekontrolowanie zgłębiać jakiś temat, dostrzega powtarzające się patterny, nie męczy się skomplikowanymi problemami logicznymi – to programowanie może się okazać dla niej. Tutaj trzeba dużo pasji, zapału, szczególnie umysłu, który potrafi myśleć wielotorowo.
Ale niekoniecznie. Programiści naprawdę są różni, a ich historie potrafią nieraz zaskoczyć. Ja jeszcze niedawno stałem za kamerą, a do naszego teamu dołączył były tancerz, dzisiaj świetny programista.
A biznes tego nie odczuwał? To w pewnym sensie luksus, móc pozwolić sobie na taką pracę metodą prób i błędów. Myślisz, że każdy founder technologicznego startupu powinien próbować swoich sił z kodem? Dlaczego?
Mogłem pozwolić sobie na takie eksperymenty, ponieważ jako jedyny z co-founderów byłem “techniczny”, miałem pojęcie, jak to w ogóle działa. Nikt inny nie był w stanie nic zrobić, a nie było też pieniędzy na profesjonalistów. Nie uważam, że każdy founder absolutnie takiej wiedzy potrzebuje – ważne, aby w pierwotnym teamie ktoś z takim skillsetem się znalazł. To ważne, bo obecnie to wszystko kosztuje bardzo duże pieniądze. Strukturę kosztową startupów tech na pewno dominuje dział programistyczny czy R&D. W zapakuj.to dobraliśmy się naprawdę nieźle – w teamie znalazły się dwie już mocno doświadczone osoby.
Czy, według Ciebie, istnieje jakiś fundamentalny koncept programowania, z którego zrozumieniem problemy mają początkujący programiści? Coś czego niezrozumienie rzeczywiście stanowi zaporę do dalszej nauki?
Myślę, że najważniejsze jest, aby na początku pamiętać (bo zrozumieć raczej się nie da), że pod warstwą chaotycznych informacji, niezrozumiałych linii kodu, niejasnych “oczywistych” rzeczy, kryją się piękne, proste idee.
Fundamentalny koncept w programowaniu to rozdrabnianie dużych problemów na mniejsze, łatwiejsze do pojęcia kawałki. Już nie mówię o zaletach tego podejścia w kontekście budowania dużych systemów, ale podchodząc w ten sposób – praktycznie wszystko wydaje się być możliwe.
To podejście było bezcenne na początku zapakuj.to. Mieliśmy do zaprogramowania back-end, front-end, widoki 3D, 2D, e-commerce oraz mechanikę produkującą produkcyjne PDF-y. Krok po kroku rozwiązaliśmy wszystkie te problemy.
Co, według Ciebie, często jest nie tak w nastawieniu osób, które dopiero zaczynają uczyć się programowania? Jakie błędne wyobrażenia powodują najwięcej szkód?
Brak planu i tendencja pisania kodu od razu. Mi osobiście bardzo pomogło opisywanie tego, co chce osiągnąć za pomocą komentarzy w kodzie. To było rewelacyjne podejście zaczerpnięte z mojego egzaminu na prawo jazdy, gdzie egzaminator znienacka kazał mi na głos opisywać to, co zamierzam zrobić i co robię. Wydaje mi się, że dzięki temu przestałem się spieszyć i zacząłem świadomie myśleć i analizować to, co robię. W programowaniu ten etap pomaga mi uniknąć “ślepych uliczek”, wyciąć masę bugów i zadać samemu sobie nieoczywiste pytania. Planowanie, planowanie – przecież to nuda! Przecież programowanie to pisanie kodu.
Cóż… nic bardziej mylnego. Programowanie to rozwiązywanie problemów, zauważanie patternów, szukanie wspólnych części i… de facto znajdywanie sposobów na pisanie mniejszej ilości kodu.
Co jeszcze poza pisaniem komentarzy poleciłbyś początkującemu, co pomogło Tobie lub Twoim kolegom w nauce? Jakaś uniwersalna metoda
Ostatnią rzeczą, którą mogę polecić nowym programistom to, żeby się nie przejmować ilością informacji i faktem, że większości rzeczy się nie rozumie. Polecam dużo, bardzo dużo czytać, nawet tych rzeczy, których się nie rozumie. Po paru miesiącach wszystko zaczyna się łączyć w spójną całość i bardzo pomaga w rozumieniu kolejnych rzeczy.
Osoby, które myślą o rozpoczęciu nauki programowania często odstrasza informacja, że programista musi uczyć się przez całe życie. Jak z tym rzeczywiście jest? Czy programista musi w kółko uczyć się kompletnie nowych sposobów robienia zadań, które już wcześniej umiał, czy po prosto aktualizować swoją wiedzę o niewielkie rzeczy, które są mu akurat potrzebne?
W pewnym momencie dobrzy programiści przechodzą na zupełnie inny poziom myślenia o programowaniu, który można zrozumieć dopiero po paru latach w zawodzie. Nauka staje się fascynująca, poszukiwanie nowych sposobów czasami nawet misją, wielu prowokuje do pisania własnych rzeczy.
To prawda, dobry programista będzie się uczył przez całe życie, inaczej to nie byłoby tak fascynujące zajęcie. W zawodzie co chwila uświadamiasz sobie, że do problemów można podejść w zupełnie inny, czasem lepszy, czasem tylko ciekawszy sposób. Ci dobrzy i ambitni – na pewno nie odczują nudy.
Pracujesz w firmie, która zajmuje się tworzeniem spersonilizowanych pudełek na zamówienie. Dlaczego wybrałeś akurat tę niszę? Jak to się stało, że trafiłeś do zapakuj.to? Jakie specyficznie trudności napotkaliście podczas tworzenia i udoskonalania aplikacji, która umożliwia personifikację pudełek?
Przypadkiem. Prawda jest taka, że trochę wypalony zawodowo wróciłem z Paryża do Warszawy po startupowej przygodzie w jednym z tamtejszych akceleratorów. Pomysł nie wypalił, mi skończyły się pieniądze i musiałem coś ze sobą zrobić. Postanowiłem chwilowo zamieszkać Warszawie, popracować jako freelancer, a następnie wrócić do Londynu, gdzie spędziłem większość mojego dorosłego życia.
Tuż po powrocie, w pociągu na Tauron Festival, usiadłem obok znajomego (Wojtka, CEO) i zaczęliśmy rozmawiać. Po festiwalu spotkaliśmy się, aby porozmawiać o współpracy (Wojtek z resztą moich wspólników prowadził software house Move Closer). Skończyło się na tym, że zamiast programowania zająłem się researchem technologicznym pomysłu na biznes – zapakuj.to. Tak się w to wszyscy wkręciliśmy, że dzisiaj wspólnie tworzymy zapakuj.to.
Co do trudności, tego było naprawdę sporo. Z pewnością specyficznym dla nas problemem była architektura systemu, w którym pudełka projektuje się w przeglądarce, a następnie projekt musi zostać przepisany na produkcyjnego Print-Ready PDF-a. Wymyślenie precyzyjnej mechaniki, skalowania, wszelkich konwersji, transformacji z pewnością było dużym wyzwaniem. Mało osób zdaje sobie sprawę jak bardzo jest to skomplikowany temat i jak wiele w tym temacie udało się nam wymyślić innowacyjnych rozwiązań.
Nie mogę też pominąć tematu wystawiania faktur. O ile nie jest to duży problem programistyczny, to analiza polskiego prawa, masa niejasności, różnorodne interpretacje i brak konkretnych definicji – na pewno potrafią pochłonąć dużo czasu, energii i przede wszystkim frustrować. Dla wielu młodych polskich firm będzie to niemiłe zaskoczenie. Automatyzując ten proces programiści muszą bardzo dobrze zrozumieć prawo. Jak to programiści, zadają wiele pytań, co generuje jeszcze więcej pytań… W końcu okazuje się, że to wszystko wcale nie jest takie proste, a zawód księgowego w Polsce jak najbardziej niezbędny. Pamiętajmy tutaj o tym, że w zapakuj.to obecnie sprzedajemy pudełka do całej Unii Europejskiej, z czym wiąże się konieczność naliczania VAT 0%, walidacja numerów VAT w VIES, który często nie działa.
Ostatnia z rzeczy trudnych to integracja z zewnętrznymi narzędziami. Łatwo się przeliczyć analizując to, co takie narzędzie potrafi, a czego nie potrafi. Wiele problemów wychodzi “w praniu”, jakość dokumentacji oraz samego API ma się nijak do poziomu materiałów marketingowych na stronie… Warto się integrować, bo to konieczność przy skalowaniu, ale ostrożnie. Nie wszystko złote, co się świeci.
Jedną z największych zalet charakteru dla programisty jest ciekawość. Jakie są Twoje metody, żeby ją pielęgnować i wykorzystywać do tworzenia lepszych aplikacji?
Myślę, że bardzo ważne są projekty tzw. “greenfield”, gdzie nie mamy do czynienia z dotychczasowym stackiem technologicznym swojej firmy, czy też tym, co już znamy. Czasami o taki projekt faktycznie jest ciężko, ale warto poszukać. Zaletą takiego projektu jest dowolność wyboru języka, narzędzi, frameworków. Takie próby są niezwykle ważne, ponieważ poszerzają wiedzę i świadomość. Programista uczy się, że istnieją setki rozwiązań, uczy się wybierać i oceniać takie rozwiązania. Zgłębianie nieznanych wcześniej języków, przestrzeni (back-end, front-end) jest sposobem, aby popchnąć swoją karierę do przodu. Wysokiej klasy front-end developerzy rozumieją back-end i na odwrót. Czasami użycie funkcyjnej, a nie deklaratywnej metodyki programowania pomaga rozwiązać problemy nawet na front-endzie.
Opowiedź o swoich doświadczeniach w greenfieldzie. Który projekt był największym/najciekawszym wyzwaniem i czego się dzięki niemu nauczyłeś?
Jednym z takich projektów, był mój prywatny projekt zrobienia czegoś jak Reddit/HackerNews tylko dla foodies. Postanowiłem, że jako front-end, który większość czasu spedził w React, Angular, jQuery, SCSS, potrzebuję zaprojektować autentyczny system od back-endu. Moim celem było stworzenie HackerNews bez jakiegokolwiek JavaScriptu. Wszystko za pomocą HTML i obsługi back-endowej.
Postawiłem to na Node.js, ale nie o technologię tu chodziło. Chciałem się skupić na architekturze, na poukładaniu wszystkich zależności. Jedyną nieznaną rzeczą, której użyłem było RethinkDB, projekt mający świetną dokumentację i query syntax podobny do JS. Chciałem zminimalizować barierę wejścia, aby skupić się na bardziej abstrakcyjnych rzeczach i nie uczyć nowych języków itd.
Co ciekawe, podczas tego projektu zrozumiałem setki rzeczy. Między innymi olśniło mnie, dlaczego w WordPressie wszystko jest “postem”. Przysięgam, że w tym projekcie pierwszy raz w życiu użyłem (poza studiami) diagramów UML. Rozrysowałem wszystko, zmieniałem wszystko 4-5 razy, aż powstała architektura, którą z łatwością potem wdrożyłem. Ten projekt zmienił dla mnie wszystko.
Polecam próbowanie tego, czego się nie zna i nie rozumie.
Jak radzisz sobie z nagłymi problemami podczas pisania aplikacji, kiedy nagle przestaje ona działać tak jak powinna? W jaki sposób początkujący programista powinien wyłapywać swoje błędy?
Dla młodego programisty najważniejsze jest nauczyć się odpowiednio zadawać pytania. Chodzi o to, żeby się “wkleić” w Stack Overflow i Google. Serio! Polecam spędzić trochę czasu na Stack Overflow po prostu przeglądając pytania i odpowiedzi, zwrócić uwagę w jaki sposób ta dość unikalna społeczność sobie po prostu pomaga, za darmo. Następnie wpisać swoje pytanie w Google i szukać. Dostępna pomoc jest prawie nieograniczona.
Jeszcze jedno. Młodzi programiści – używajcie git-a. Zawsze i często, również we własnych projektach. “git diff bcfd39e0..74da46ef” to #1 debugger. Jeżeli w Twojej aplikacji pojawił się bug, to w 9/10 przypadkach został wprowadzony przez Ciebie. Diffy na GitHubie to jedna z pierwszych rzeczy, które sprawdzamy w zapakuj.to, kiedy trafimy na “trudniejszy” problem.
Skąd czerpiesz inspiracje do znajdowania nowych rozwiązań? Jak bardzo programista potrzebuje inspiracji?
Polecam serwis Panda, gdzie w łatwy sposób można śledzić feedy HackerNews, HackingUI, Lobsters, CSS-Tricks. Wchodzę tam regularnie, również wtedy, gdy czuję zmęczenie. Społeczność dodaje tam masę wartościowych artykułów inspirujących do działania i innowacji.
Polecam też podcasty w drodze do pracy JavaScript Jabber, Soft Skills Engineering, In Depth (Design). Wszelkie video z dużych konferencji dostępnych czy też mniejsze prezentacje dostępne na YouTube są świetnym źródłem wiedzy. Bardzo często też szukam raportów z badań naukowych. Przykładowo, ostatnio czytałem “Why most unit tests is waste”, coś spektakularnie kontrowersyjnego, ale utwierdziło mnie w moim (chyba) pragmatycznym podejściu do testów.
Uważam, że nie da się być ze wszystkim na bieżąco i nie trzeba. Natomiast bycie zainspirowanym jest świetne nie tylko dla samego programisty, ale dla wszystkich wokół niego.
Artykuł powstał dzięki:
Coders Lab
Łącząc doświadczenie edukacyjne ze znajomością rynku pracy IT, Coders Lab umożliwia szybkie i efektywne zdobycie pożądanych kompetencji związanych z nowymi technologiami. Skupia się się na przekazywaniu praktycznych umiejętności, które w pierwszej kolejności są przydatne u pracodawców.
Wszystkie kursy odbywają się na bazie autorskich materiałów, takich samych niezależnie od miejsca kursu. Dzięki dbałości o jakość kursów oraz uczestnictwie w programie Career Lab, 82% z absolwentów znajduje zatrudnienie w nowym zawodzie w ciągu 3 miesięcy od zakończenia kursu.
Zostaw komentarz