PHP, Node.js, C#
Dzielenie się wiedzą w zespołach programistycznych jest bardzo ważną sprawą. Nie wszystko co wiesz na temat projektu jest znane pozostałym członkom zespołu. Działa to także w drugą stronę – nie zawsze wszystko wiesz, a i też nie wszystkie zakamarki aplikacji musiałeś prześledzić. Budowanie silosu wiedzy, dotyczącego czy to aspektów biznesowych czy też technicznych nie wpływa korzystnie na utrzymanie projektu. Wyobraź sobie dłuższą nieobecność osoby odpowiadającej za funkcjonalność X, której nikt poza nią nie zna… Dlatego wychodząc na przeciw: Omawiamy metody, które używaliśmy w celu propagowania wiedzy projektowej. Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem: ➡️ W jaki sposób dzielicie się wiedzą projektową w zespole? ➡️ Czy i w jaki sposób propagujecie wiedzę pomiędzy zespołami? ➡️ Kto dba o propagowanie wiedzy w Twojej organizacji? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Ofert pracy na rynku IT nie brakuje. Pracodawcy próbują zwracać na siebie uwagę nie tylko prężnym, młodym i ambitnym zespołem ale też oferowanymi benefitami. Począwszy od tych spotykanych na co dzień jak owocowe piątki, imprezy integracyjne, prywatna opieka medyczna, fun roomy (wypełnione po brzegi „zabawkami”), elastyczny czas pracy, aż po te bardziej niespotykane jak samochód sportowy na weekend. Na początku swojej zawodowej kariery kręciły mnie te wszystkie extra rzeczy. Teraz podchodzę do tego w zupełnie inny sposób. Benefity z oferty nie odgrywają większej roli, a samo określenie benefit oznacza dla mnie/nas coś nieco innego. Więc zmierzając do sedna: Jakich benefitów oczekują programiści? Dyskutujemy między innymi o tym co nas kręci, co nam totalnie zwisa oraz czy formy benefitów zmieniają się wraz z rozwojem pracownika. Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem: ➡️ Które benefity są dla Ciebie wartościowe? ➡️ Czego brakuje Ci u obecnego pracodawcy? ➡️ Jakie benefity z Twojego punktu widzenia są ośmieszające? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję
IT przeżywa niesamowity rozwój. Słyszymy, że na rynku wciąż brakuje specjalistów, zarobki z roku na rok są coraz wyższe – ogólnie cud, miód i orzeszki w tej branży 😉 Mając doświadczenie, łatwo znaleźć pracę – lepiej płatną czy też oferującą więcej benefitów i ciekawszy projekt. Co jednak zrobić jeśli dopiero wchodzimy na rynek pracy w branży IT? Co zrobić gdy nikogo nie znamy kto może nas polecić? Jak sobie poradzić jako potencjalny junior z szukaniem swojego pierwszego zatrudnienia? Ale też przede wszystkim: Czy branża IT jest tylko dla programistów? W tym odcinku mocną uwagę skierowaliśmy na bootcampy programistyczne. Odpowiadając m.in na pytanie: czy 3 miesięczny kurs wystarczy aby podczas rekrutacji od razu wymagać 15k na rękę? 💰 Mówimy o tym na co zwracać uwagę, jak zahaczyć się w firmie technologicznej oraz skąd wiedzieć czego dana firma oczekuje od potencjalnego juniora. Zainteresowany? W takim razie zapraszam Cię do odsłuchu tego odcinka podcastu. Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem: ➡️ Jakie role może pełnić w IT osoba która wcześniej nie miała do czynienia z branżą? ➡️ Od czego zacząć wchodząc w IT? ➡️ Jakie materiały poleciłbyś osobom wchodzącym dopiero do IT? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍
Jakiś czas temu rozmawialiśmy w kuluarach na temat roli jak Lead Developer. Nasze spojrzenia na kwestię obowiązków były różne i wynikały z nabytych doświadczeń podczas pracy nad różnymi projektami w różnej konfiguracji personalnej. W tym odcinku podcastu staraliśmy się odpowiedzieć na zasadnicze pytanie: Za co może być odpowiedzialny Lead Developer? Dyskutujemy o potencjalnych odpowiedzialnościach, tym czy taka rola musi pojawiać się w każdym projekcie oraz kiedy może przynosić korzyści? Czy coś z tego wynikło? Tak. Zdefiniowaliśmy wstępnie pięć typów Lead Developera mając pełną świadomość, że to tak na prawdę typy wynikające z naszych obserwacji i wstęp do dłuższej dyskusji. Zainteresowany? W takim razie zapraszam Cię do odsłuchu tego odcinka podcastu. Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem: ➡️ Z jakimi typami Lead Developera się spotykałeś? ➡️ Za co powinien być odpowiedzialny Lead Developer i dlaczego? ➡️ A może sam pełniłeś/pełnisz rolę Lead Developera? Czym się w takim razie zajmujesz? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję.
Komu tak na prawdę wysoka efektywność w IT przynosi największą wartość? Czy tylko pracodawcy czy jednak pracownik może także na tym zyskać? Kiedy efektywność nie jest pożądana, nie przynosi wartości programiście i jest totalnie przez nich olewana? Podczas dwudziestego piątego odcinka razem z Bartkiem poruszamy temat, który dzieli zamiast łączyć dwa światy – świat pracodawcy oraz pracownika. Pracodawca wymaga efektywności działań programisty, natomiast programista oczekuje otoczenia które pozwala mu dobrze i efektywnie wykonywać swoją pracę. Na co więc zwracamy my – programiści uwagę? Po co warto i jak utrzymywać wysoką efektywność w pracy? Z Bartkiem dyskutujemy o tym dlaczego warto być efektywnym oraz dzielimy się spostrzeżeniami co wpływa na naszą efektywną pracę. Zainteresowany? W takim razie zapraszam Cię do odsłuchu tego odcinka podcastu ⤵️⤵️
Front-End development ewoluuje z szybkością bliską prędkości światła ⚡️ Rozwijane są kolejne wersje istniejących rozwiązań, pojawiają się nowe frameworki oraz biblioteki. Ogromna społeczność około frontendowa głowi się i trudzi aby dostarczać coraz lepsze rozwiązania ułatwiające co dzienną pracę programisty ale także rozwiązywać znane problemy w inny, a zarazem lepszy sposób. Jak zatem nadążać za pojawiającymi się nowościami? Jak podchodzić do wyboru konkretnych rozwiązań przy startowaniu nowego projektu frontendowego? Jakie narzędzia wybierać do front-end developmentu? Razem z Łukaszem oraz Rafałem staramy się odpowiedzieć na powyższe pytania, dając wskazówki co do wyboru: - frameworka, - biblioteki do testów jednostkowych, - bundlera oraz task runnera. Ciekawy co mają do powiedzenia specjaliści w temacie frontendu? W takim razie zapraszam Cię bardzo serdecznie do odsłuchu ⤵️⤵️
Testy jednostkowe to temat, który nie raz poruszaliśmy podczas naszego podcastu. Wspominaliśmy o ich wartości, głównych zasadach ale także zachwalaliśmy technikę Test-driven development. Z naszych rozmów jednoznacznie wynika, że praca bez Unit Tests jest dla nas ciężka i tak na prawdę zwiększa ilość pracy… Dlaczego? Ponieważ po każdej zmianie w kodzie, gdy brakuje testów jesteśmy zmuszeni do przeprowadzania manualnej weryfikacji czy nasza aplikacja dalej działa bezbłędnie. Myślicie, że dobrym pomysłem byłoby nagranie odcinka w którym rozprawiamy się z „wadami” testów jednostkowych i obalamy związane z nimi mity? ✨ Tym razem jednak skupiliśmy się na definicji kilku dobrych praktyk wspomagających tworzenie testów jednostkowych. Takich testów, które dobrze weryfikują implementacje, zapewniają jakość oraz łatwo jest je utrzymywać. Jakie dobre praktyki warto stosować podczas pisania testów jednostkowych? Wśród popularnych aspektów jak zasady FIRST czy grupowanie implementacji testu w trzy grupy – Given, When, Then pojawiły się także inne warte uwagi techniki. Jesteś ciekawy jakie? To serdecznie zapraszam Cię do odsłuchu ⤵️⤵️
Dzisiejszy odcinek jest wyjątkowy. Spotkaliśmy się z Krzysztofem z podcastu "Porozmawiajmy o IT" by porozmawiać o trendach, które według nas zdominują IT w tym roku. Rozmawialiśmy o: - Cloud Native - Progressive Web Apps - Internet of Things - wzmocnieniu znaczenia takich języków programowania jak JavaScript czy Python - technologiach głosowych - sztucznej inteligencji - big data - web APIs
Podczas pracy nad rozwojem oprogramowania dostrzegamy pewne rozwiązania, które są jasnym sygnałem do podjęcia się refaktoryzacji danego fragmentu kodu. Kenta Beck zdefiniował termin Code Smells – to cechy kodu, które świadczą o złej implementacji, utrudniającej utrzymanie oraz rozwój kodu. Na jakie Code Smells zwracać uwagę w swoim kodzie? W tym odcinku podcastu skupiamy się na Code Smells, które z naszej perspektywy pojawiają się najczęściej i nad którymi warto popracować. Jeżeli chcesz poznać więcej potencjalnych smrodków w kodzie serdecznie polecamy z zapoznaniem się z materiałem umieszczonym w serwisie Refactoring.Guru. Zapraszam do odsłuchu ⤵️⤵️
Niedawno rozmawialiśmy o różnych przyczynach zmiany pracy. Jedną z nich był szumny rozwój programisty – jeśli nie czujemy, że się rozwijamy, w tym co nas interesuje i angażuje, to może to właśnie jest punkt zapalny do szukania innego miejsca dla siebie. Nasza branża szybko się zmienia, dostarczając nam co raz to nowszych narzędzi do rozwiązywania problemów. Nie wszystkie jesteśmy w stanie wykorzystać od razu w projektach produkcyjnych – ze względu na poziom skomplikowania, zupełnie nowy koncept. Czy pracodawca powinien zapewnić nam czas na ich poznawanie? Czy programista powinien rozwijać się po godzinach pracy? W tym odcinku podcastu dyskutujemy czy odpowiednim miejscem rozwoju jest tylko i wyłącznie wykonywana przez nas praca. Zapraszam do odsłuchu ⤵️ Nasza opinia jest dość jednomyślna, jednak jakie jest Twoje zdanie? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
Micromanagement czyli styl zarządzania, który nie kojarzy nam się w sposób pozytywny. To kontrola i wywieranie wpływu na osoby w zespole. Coś z czym większość z nas nie chciała by mieć na co dzień styczności. Mi mocno kojarzy się z korporacją, hierarchiczną strukturą, raportowaniem postępu prac w formalny sposób. ? Relikt przeszłości. Zresztą nasz tytuł mocno nawiązuje do czasów w których komunizm był codziennością naszych rodziców. Taka forma zarządzania często obniża produktywność, morale zespołu czy też wpływa na podjęcie decyzji o zmianie pracy. Ogranicza nasz potencjał oraz ujawnia brak wiary w umiejętności. ? Micromanagement coś co utrudnia czy może ułatwia Ci pracę? Podczas tego odcinka definiujemy złe ale także dobre aspekty mikrozarządzania, staramy się nakreślić sytuacje w których jest to pewnego rodzaju „przysługą” w stronę zespołu. Mówimy o powodach, doświadczeniach i sposobach przeciwdziałania takiej formie współpracy. Zapraszam do odsłuchu ? Czy micromanagement wprowadzony w sposób świadomy (lub też nie) kiedyś pomógł Ci osiągnąć wyznaczony cel? Jak dokładnie wyglądała Twoja sytuacja? Co konkretnie Ci pomogło, a co utrudniło pracę? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
Jest piątek, wybija godzina 15:00. Pozostała zaledwie godzina do końca pracy. Do Twojego zespołu dociera informacja, że koniecznie teraz musicie wdrożyć na produkcję zmiany, które w ostatnim czasie wprowadziliście. Wdrożenia w piątek = istny koszmar? ? Pojawia się natychmiastowa negacja pomysłu, czy raczej z swobodą udajecie się w odpowiednie miejsce aby kliknąć w magiczny przycisk wrzucaj wszystko na proda! Czy w ciemno wdrożyłbyś aktualnie rozwijaną wersję aplikacji na produkcję? Ile rzeczy zostało zintegrowanych do rozwijanego kodu, które zaważają nad pewnością stabilności aplikacji? Ile z tych rzeczy nawet nie została w pełni ukończona, a jest już widoczna w systemie? Pomimo, że praktyki związane z CI/CD ? są bardzo dobrze znane, to często je pomijamy – stosując w swoim zwinnym podejściu elementy kojarzone głównie z modelu kaskadowego. Ustalamy zasady zero wdrożeń w piątek. Mamy obawy, że tworzone przez nas oprogramowanie może nie być do końca stabilne. Brakuje nam odpowiednich testów, a sami mieszamy dostarczane przez nas elementy – może nauczyliśmy się nie dostarczać spaghetti code, ale zamiast continuous integration wychodzi nam spaghetti integration. Dlaczego wdrożenia w piątek podnoszą nam ciśnienie? Gdzie leży problem? Od czego zacząć aby bo rozwiązać? W tym odcinku staramy się odpowiedzieć właśnie na te pytania. W jaki sposób i jak często dostarczasz ze swoim zespołem zmiany na wdrożenie produkcyjne? Praktykujecie CI/CD? Z jakich narzędzi korzystacie? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
Czym żyje prawdziwy programista? Kodem. I nie doszukuj się w tym żadnego ukrytego akronimu! Tym sucharem ? chciałem rozpocząć opis najnowszego odcinka naszego podcastu. Może się wydawać śmieszny, ale w gruncie rzeczy jest to idealne zobrazowanie potrzeb wielu programistów. Mocno skupiamy się na dostarczaniu idealnego kodu – spełniającego dobre praktyki z rozbudowaną i łatwą w utrzymaniu architekturą. ❗️ Kod to nie cel sam w sobie. Za jego pomocą tworzysz rozwiązania problemów. ❗️ Załóżmy, że zajmuje się sprzedażą produktów w internecie, prowadząc prosty sklep internetowy. Do tej pory nie posiadałem możliwości wprowadzania kodu rabatowego podczas procesu zakupowego. Zlecając wdrożenie takiej funkcji w aplikacji zgadnij na czym mi zależy? Nie, serio nie na kolejnym mikroserwisie uruchomionym w kontenerze Docker jako Pod w klastrze Kubernetes. Jeżeli to rozwiązuje klasę problemów związanych z wysoką dostępnością – jasne, będziemy brać to pod uwagę. Ale ja na ten moment potrzebuję udostępnić moim klientom kod rabatowy z 10% zniżką. Tyle. Kod jest narzędziem w rękach rzemieślnika, który w połączeniu z odpowiednimi technikami oraz surowcem daje rozwiązanie którego potrzebuje klient. Podczas tego odcinka podcastu Dev:Cast staramy się odpowiedzieć m.in. na pytania: ? Czym jest wartość biznesowa o której tak dużo ostatnio się mówi? ? Kto powinien odpowiadać za przedstawianie wartości biznesowej poszczególnych funkcji aplikacji? ? Czy programistom łatwo wyznaczać granice refaktoryzacji oraz wystarczająco czystego kodu? I o wielu innych ciekawych aspektach, które pojawiły się podczas naszej zawodowej pracy. Na co jeszcze Twoim zdaniem programiści zwracają więcej uwagi niżeli dostarczenie kodu rozwiązującego zadany problem? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
Dotychczasowa praca zawodowa wielokrotnie pokazała nam, że estymacja projektów i dostarczanie ich na czas to element układanki, który często nam nie wychodzi. Zamiast szukać rozwiązań tych problemów posiłkujemy się dociskaniem projektów w ramach nadgodzin. ? Jakie inne elementy sprawiają, że w realizowanym projekcie jesteśmy zmuszeniu lub chcemy realizować coś więcej kosztem swojego wolnego czasu? Jakie dostrzegamy negatywne i pozytywne aspekty nadgodzin? W tym odcinku podcastu Dev:Cast staramy się zdefiniować przyczyny oraz skutki nadgodzin w branży IT. Bierzemy pod uwagę aspekt jednostki, zespołu oraz firmy w której pracujemy. Jesteś ciekaw co sądzimy o nadgodzinach? Zapraszam do odsłuchu ? Jakie są Twoje doświadczenia z nadgodzinami? ? Kiedy nadgodziny mogą przynieść Ci korzyść? ? Czy powinniśmy zgadzać się na nadgodziny dla dobra ogółu? ? Czy warto wynagradzać za nadgodziny w jakiś ekstra sposób? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
Istnieje bardzo małe prawdopodobieństwo, że spędzimy całe swoje zawodowe życie w jednej firmie. W branży IT zmieniamy pracę kierując się rozwojem zawodowym, nowymi technologiami ale także poziomem zarobków, które mocno poszybowały w górę w przeciągu ostatnich kilku lat. ? W którym momencie warto podjąć decyzję o zmianie pracy? Przybliżamy powody naszych decyzji o zmianie pracy ale także rozmawiamy o przyczynach, z którymi się spotkaliśmy. Mateusz wspomina także swoją pierwszą zmianę pracy gdzie pomimo gorszych warunków finansowych i tak zdecydował się przejść do nowej firmy. Zapraszam do odsłuchu ? ? Podziel się doświadczeniem Chciałbym Cię poprosić o podzielenie się swoją perspektywą: ? Kiedy warto zmienić pracę? ? Czy powinniśmy na bieżąco brać udział w rekrutacjach? ? Jakie elementy skłoniłyby Cię do podjęcia decyzji o zmianie firmy? Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję ?
PHP, Node.js, C#
Na co dzień Software Engineer. Fascynat programowania, architektury, metodyk zwinnych i dobrych praktyk w szerokim ujęciu.
Polyglot Programer kochający poznawać nowe języki jednocześnie wykorzystując ich najlepsze strony. Założyciel DevEnv i współautor podcastu Dev:Cast.
After Hours czyli gdy nie pracuje i nie robi czegoś na DevEnv - podróżnik w miejsca zapomniane, pasjonat lokalnej historii. Mocno zajarany survivalem, urbexem i militariami. Jest jednym z opiekunów schronu bojowego WAWOK w Rybniku.