Better Software Design

Aż trudno mi w to uwierzyć, ale Better Software Design ma już 6 lat 🥳 I dzisiaj właśnie ukazał się odcinek nr 100 🔥

Gościem pierwszego odcinka był Kuba Pilimon, z którym później często rozmawialiśmy o różnych aspektach architektury czy Domain-Driven Design. Więc tym bardziej jest okazja aby wrócić do takich tematów właśnie z Kubą, bo pozmieniało się w tym czasie w branży sporo 😉

W pierwszych odcinkach obaj przynosiliśmy do stolika problemy do przedyskutowania. Tym razem zrobił to Kuba, jeden ze słuchaczy podcastu 🔥

A jeśli chciałbyś/abyś przedyskutować swój techniczny problem 1:1, to zapraszam na otwarte, darmowe konsultacje. Terminy są jak zwykle dostępne na https://bettersoftwaredesign.pl/wspolpraca/bezplatne-konsultacje/

PS: Link tradycyjnie w pierwszym komentarzu

Chyba każdy na swojej drodze spotyka osoby, które mają na nas duży wpływ i nagle coś się zmienia. Można połączyć różne kropki i zacząć patrzyć na rożne sprawy inaczej. Dla mnie taką osobą jest Daniel Owsianski, na rozmowę z którym zapraszam w dzisiejszym odcinku Better Software Design, a z którym mam okazję pracować na codzień w Volt.io.

Dziś na tapecie temat, z którym wiele osób zwracało się w kontekście rozwoju własnej kariery IT. Chief Technology Officer - CTO, trzy literki, dzięki którym można mieć naprawdę spory wpływ na wiele rzeczy, ale za którymi stoi znacznie więcej niż tylko technologia. I właśnie o roli CTO w kształtowaniu organizacji, kultury i zespołów rozmawiamy dziś z Danielem.

Polecę tę rozmowę nie tylko managerom zarządzającym zespołami, ale także (a może przede wszystkim) programistom i architektom, bo gdy kiedyś pojawi się w myślach pytanie "i co dalej?", warto wziąć takie doświadczenia pod uwagę.

Link tradycyjnie w komentarzu.

PS: Podziękowania dla osób, które pomogły mi Daniela zaskoczyć na początku rozmowy :)

Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym.

Ale wiadomo, są wyjątki od reguł, bo czasem pracujemy po prostu nad proof-of-concept i potrzebujemy tylko zweryfikować naszą wizję. Inna sprawa, że taki prototyp ląduje często na produkcji i tam wygrzewa się w testach na użytkownikach końcowych. Klasyczne protoduction....

Jak pisać wartościowe testy, które realnie sprawdzają zachowania systemu, a nie same mocki, jak nawigować po szarej strefie testów Kevlina Henney'a, dlaczego unit to więcej niż klasa czy metoda i jakie lessons-learned wynieśliśmy z wielu projektów - to tylko niektóre tematy, które poruszamy dziś w Better Software Design z Piotr Stawirej

Mam nadzieję, że wnioski z tej rozmowy zapadną głęboko w pamięć, bo naprawdę warto 🔥 Link tradycyjnie w komentarzu...