DevEnv - O programowaniu bez kaca

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ę 👍

Nowe osoby w projekcie i to takim trwającym już od pewnego czasu to niemałe wyzwanie. Baa, to cały proces, który może trwać dłuższy czas. Dotyczy nie tylko lidera zespołu ale także każdego członka zespołu. Różnorodność procesów, technologi, wzorców oraz rozwiązań typowych problemów sprawia, że łatwo przytłoczyć „nowego” 👶🏻 ilością informacji. Finalnie zapamiętując niewielki fragment.

Co tak na prawdę jest niezbędne, aby zagłębić się w projekt?

Kilkaset stron dokumentacji biznesowej, dostarczonej programiście w pierwszy dzień pracy, nie jest najlepszym zachęceniem do pracy. Jako programiści nasze pragnienia są zupełnie inne – interesuje nas kod, architektura oraz cała techniczna otoczka projektu nawet ta dotycząca utrzymywania legacy code.

Podczas tego odcinka dzielimy się swoimi doświadczeniami i przemyśleniami z perspektywy lidera oraz osób zaczynających prace w istniejących projektach. Staramy się odpowiedzieć na czym warto się skupić i kto powinien być odpowiedzialny za onboarding.

Chciałbym Cię poprosić o garść Twoich przemyśleń i doświadczeń:

🔹 Czy pamiętasz jak wyglądało wdrażanie Cię w trwające projekty?
🔹 Czy jest coś co szczególnie zapadło Ci w pamięć?
🔹 Czego unikać podczas wdrażania nowych osób do trwającego projektu?

Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję 👍

Odcinek specjalny z okazji 📢 Międzynarodowego Dnia Podcastów 📢

Jako twórcy polskich podcastów IT odpowiadamy na pytania Grzegorza Kotfisa (Devsession) - czym są podcasty, co dają nam osobiście, jakie są ich zalety i mówimy o kulisach ich realizacji.

W tym wyjątkowym odcinku znaleźliśmy się także MY 😃 Co jest dla nas nie małą satysfakcją, że to co robimy staje się widoczne i doceniane przez innych 💪

W odcinku usłyszycie także wypowiedzi autorów podcastów:

▶️ Ostra Piła
▶️ Podcast "Porozmawiajmy o IT"
▶️ devstyle.pl - Maciej Aniserowicz
▶️ Javadevmatt - Mateusz Kupilas
▶️ Devsession - Grzegorz Kotfis

Do usłyszenia!

My – programiści poświęcamy zbyt wiele czasu na sprawy o niskiej wartości biznesowej. Rozwiązujemy 🔨 problemy, które mogą się nie wydarzyć. Przeciwdziałamy zapobiegawczo sytuacjom, których prawdopodobieństwo wystąpienia jest mniejsze niż 1% poświęcając na to olbrzymie pokłady energii, czasu oraz nadwyrężając budżet 💸 inwestora… Tytułowy overengineering może objawiać się na wielu płaszczyznach – definiując jednak najważniejsze trzy – może dotyczyć on:

▶️ rozwiązań funkcjonalnych, które nie są wykorzystywane przez klientów aplikacji,
▶️ architektury, która rozwiązuje lub „zapobiega” nie istniejącym problemom,
▶️ kodu, który przewiduje zmiany w obszarze, który się nigdy nie zmieni.

Podczas tego odcinka podcastu, zahaczamy o tematy związane z praktykami Extreme Programming wspomagającymi rozwiązywanie problemów w łatwy i prosty sposób, starając się odpowiedzieć na pytanie:

Kiedy nasze rozwiązania są zbyt przekombinowane?

Wychwycenie odpowiedniej równowagi pomiędzy rozwiązaniem technicznym, a problemem biznesowym jest bardzie ciężkie. Podczas tego odcinka podcastu Dev:Cast 📢 staramy się określić co odbierane jest w sposób negatywny jako overengineering.

Warto również poświęcić kilka minut na świetny artykuł "How To Accept Over-Engineering For What It Really Is".

Mam do Ciebie jednak dodatkowe pytania:

🔹 Spotkałeś się kiedyś z rozwiązaniami, które technicznie wyprzedzały wymagania projektu o lata świetlne?
🔹 Kto powinien dbać o zachowanie równowagi pomiędzy dostarczaniem, a rozwiązaniem technicznym?
🔹 Czy wszystko zawsze musi być w 100% doskonałe technicznie?

Jeżeli chcesz, to podziel się swoją opinią, zostawiając nam krótki komentarz pod artykułem. Będziemy bardzo wdzięczni za rozpoczęcie konwersacji 👌 W końcu warto się wymieniać doświadczeniem – co nie? 😎

Udostępnianie interfejsów programistycznych w formie WebAPI stało się pewnym standardem. Integrujemy ze sobą różne systemy – komunikując je w celu wymiany wymaganych danych. Popularne serwisy udostępniają swoje dane, by programiści mogli wykorzystać potencjał zagregowanych danych. 📑
Jak natomiast podejść do projektowania API, które będzie dostępne dla konsumentów?
Na co zwracać uwagę?

Na te pytania staramy się odpowiedzieć w nowym odcinku podcastu Dev:Cast 📢

Na koniec mam jeszcze do Ciebie trzy pytania:

▶️ Czy projektowałeś kiedyś WebAPI?
▶️ Na co zwróciłbyś jeszcze uwagę?
▶️ Jakie elementy muszą zostać dobrze zaprojektowane by w przyszłości nie utrudniały wykorzystywania WebAPI?

Daj nam znać w komentarzu. Do usłyszenia ✌️

Zarządzanie zespołem składającym się z specjalistów w branży IT nie jest łatwe. Często osoby będące programistami zmieniają swoją ścieżkę kariery, stając się liderami zespołu. Czy jednak Team Leader musiał być wcześniej osobą techniczną? Czy musiał ukończyć studia informatyczne? Może jednak w branży potrzeba nam więcej humanizmu aby uzupełnić proces wytwarzania oprogramowania? Strasznie dużo pytań… 😳 Na część z nich staramy się odpowiedzieć w tym odcinku.

Pytanie otrzymaliśmy od Marceliny w ramach konkursu Code Europe i jest zarazem jednym z pierwszych, które poruszać będziemy na łamach naszego podcastu Dev:Cast. Zapraszam do odsłuchu 📢

Jakie są Twoje doświadczenia? Lider zespołu, który nie posiada kompetencji technicznych nadaje się na zarządzanie zespołem IT? Czy może to totalnie nietrafiony pomysł? ⛔

Czy osiągnięcie pułapu Senior Software Developera to koniec programistycznego rozwoju kariery? Czy każdy dobry programista staje się po pewnym czasie Project Managerem? 👮 Może to gdzie zmierzamy zależy tak na prawdę od nas samych?

Z Marcinem rozmawiam na temat kariery programisty na jego z życia wziętym przykładzie. Przykładzie, który pokazuje rozwój i przekształcenie do innej roli. Nie zawsze zostając programistą ⌨, jesteśmy nim do końca życia. Często szukamy nowych wyzwań – wcześniej dla nas niedostępnych ze względu na brak wymaganego doświadczenia.

Zainteresowany jak wygląda kariera Marcina w świecie IT zapraszam serdecznie do jedenastego odcinku podcastu 📢 Dev:Cast.

A Ty zostaniesz programistą do końca życia?

… ja na razie nie wyobrażam sobie innej opcji 😎