Wpisy z tagiem: podcasty

Dla mnie brzmi obiecująco. Ale ja się nie znam. Takie mam wrażenie.

PS A na YouTube nie ma opisu do wideo (do audio jest). To chyba omission? — Myślę sobie o tym low-code i no-code i tak, jak wyżej napisałem, obiecujące. Mówiąc mimochodem, jestem za automatyzacją; oczywiście nie w znaczeniu zastępowania wszystkich działań ręcznych, a tylko tych, które nie spełniają pokładanych w nich oczekiwań (to zależy od konkretnego przypadku). — Zastanawiam się, jak obiecujący (rozwinięty?) jest rynek infrastruktury dla low-code/no-code. Przez "infrastrukturę" rozumiem zarówno rozwiązania chmurowe, jak i np. frameworki do testów. — Chętnie spróbowałbym podziałać w no-codzie czy low-codzie, gdybym widział w tym, hm… wartość zawodową dla siebie. — Nawiasem mówiąc, podoba mi się przykład wyjścia na rower użyty przez Michała. Oczywiście oba podejścia moim zdaniem mają swoje plusy, zarówno pracowanie dłużej nad projektem, jak i krócej. Chodzi mi o to, że przykład Michała uwydatnia, budzi potrzebę określenia priorytetów (a przynajmniej budzi ją we mnie): które z tych dwóch podejść sprawdzi się lepiej w naszej sytuacji.

PS Ach, już wiem: https://jaroslawstadnicki.pl/2016/03/01/itan-projekt-rusza-razem-z-dajsiepoznac/

:)

@KamilAdam: O wszystkim, bo dobrze ogarnięty scrum też to zrobi. Jasne jak masz dobrego PM/PO to też to ogarnie, czy sam czy z pomocą jakiegoś systemu? Jak to się będzie nazwyało agile/scrum/funky-management-7.3.2.beta ;)

Ja o Scrumie i ogólnie agile'u wiem tyle co nic, ale dziś sobie to przesłuchałem, i jak słuchałem Roberta, to czułem dość często: "Kurczę, ja myślę podobnie! Tylko bym to inaczej ujął, może zmienił punkt ciężkości". Dużo o emocjach było. Zarządzanie to emocje. (Zarządzanie emocjami też, tylko o tym było trochę mniej). A Wy, @Jarosław Stadnicki , coś cicho byliście. :) Podobało mi się to Twoje "Szu!", że tak zaufanie spada.

(Przesłuchałem. Nie mam komentarza).

Fair point, @Jarosław Stadnicki , o "dojrzewaniu" kodu. Chociaż w mojej ocenie jest to raczej spojrzenie z innej perspektywy niż np. ta uwzględniająca koszty projektu. To takie podejście, którego nie powinno stosować się oddzielnie od innych. Mówiąc mimochodem, myślę, że opisujesz szczególny przypadek ogólnego problemu zarządzania energią (tą ludzką). — Kolejny fair point, @Jarosław Stadnicki , o tym, jak postrzegamy własną pracę. Ważne tu są emocje. Krytykując (=dając feedback) trzeba brać je pod uwagę (54-ta min.). — Podoba mi się podejście niestawiania własnych nawyków za wzór (56-ta min.). — Metafora sprzątania mieszkania (70-ta min.), zdaje się, też szczególny przypadek zarządzania energią. — Przychodzi budżet do zespołu. :d — Ogólnie co do Ostrej Piły, to wpadło mi takie przemyślenie podczas słuchania tego odcinka, że dobrze łączycie rozmowę na temat z rozmową nie na temat (nie mówię o żartach). Choć być może dlatego tak to widzę, bo jestem przezwyczajony do Was (słuchałem dawniej, teraz wróciłem).

Chwała Ci za powrót :)

Odcinek poruszał kwestie dla mnie trochę nieznane, szczególnie, że nie znam świata .NET, i być może dlatego wydał mi się trochę chaotyczny. — Sam problem z left-padem znam tyle o ile, niemniej mam pytanie do Pawła dotyczące problemu kojarzonego z left-padem: korzystanie z jakiej zależności (paczki, pakietu itp.) będzie powodowało więcej problemów – mniejszej, prostszej, którą możemy sami napisać, czy większej, bardziej złożonej, której sami nie napisalibyśmy? (my = firma; pytam, bo chciałbym sprawdzić, czy dobrze myślę; i nie chcę sugerować odpowiedzi, bo jak mówię, nie znam się dobrze na temacie odcinka). A może w ogóle to pytanie nie ma sensu, bo "poziom problemów" będzie podobny w obu przypadkach? Przepraszam, jeśli było o tym w odcinku (a tylko ja nie odnotowałem).