Zanim zaczniesz kodować, zapytaj dlaczego
TheCommitLineSpecjalista
7piorunówDwa tygodnie temu napisałam o feature'ach, których nikt nie potrzebował. Jeden z czytelników powiedział wprost: zdiagnozowałaś problem, ale nie dałaś rozwiązania. No to masz rozwiązanie.
W tym wydaniu: jedno małe pytanie, które może uratować Cię przed tygodniami bezsensownej pracy. Plus kilka pytań, które warto zadać zanim w ogóle otworzysz edytor.
https://thecommitline.substack.com/p/zanim-zaczniesz-kodowac-zapytaj-dlaczego
W offtopie z kolei pytam o coś, co chodzi mi po głowie od jakiegoś czasu - czy senior to stanowisko, czy po prostu ktoś, kto siedzi w projekcie dłużej niż Ty?
:arrow_right: Zapisz się i czytaj całość. A przy okazji - każdy nowy subskrybent dostaje ode mnie praktyczny poradnik o git i GitHubie. Same konkrety, które faktycznie przydają się w codziennej pracy.
Komentarze (14)
To będzie pewnie kontrowersyjne ale myślę, że zasady Kaizen to najlepsze co Japonia dała światu (nie jestem miłośnikiem anime 😆 ). Najwyżej cenię: "użyj sprytu zamiast pieniędzy", "problemy stwarzają możliwości" i właśnie: "pytaj (przynajmniej) 5 razy 'dlaczego?' "
Dziki.Debiutant0piorunówOgólnie przejrzałem całego bloga, jest bardzo... Subiektywny. Bardzo wygodny w formie eseju, napisany W celu przedstawienia własnego zdania i temu właśnie mają służyć blogi, niestety poursza on kwestie według ustalonych Przez siebie reguł, przez co tezy mogą być obalone Bardzo szybko, I choć teza nie będzie mieć argumentów by się obronić - nie ma z tego powodu jakiegoś poważnego wniosku. Najbardziej mi zgrzyta pod podlinkowanym artykułem I tym o vibe codingu.
Dziki.Debiutant0piorunów> To normalne, na tym polega wszechświat, że mamy różne doświadczenia i różne "podejścia" do tego.
Bardzo ładna hiperbola. Niemniej, widzę, że niezbyt dotarło to co starałem się przekazać. Aczkolwiek dziękuję za odpowiedź
TheCommitLineSpecjalista0piorunów@Dziki. tak, to są treści subiektywne, pisane zgodnie z moim subiektywnym doświadczeniem i moimi subiektywnymi opiniami. Podejrzewam, że 99% tez może być obalone bardzo szybko, nie tylko związanych z moimi treściami. To normalne, na tym polega wszechświat, że mamy różne doświadczenia i różne "podejścia" do tego. W IT jest tak samo, wiele kwestii zamyka się na "to zależy". Kluczem do dowodzenia tez są odpowiednie założenia, to pozwala na zawężenie, ale też zsubiektywizowanie problemu.
keborganGruba ryba0piorunówSenior to bardziej rola.
Bezsensowne kodowanie nie jest bezsensowne jeśli widnieje na fakturze 😉
@MostlyRenegade no widzisz i to już jest wkwestia zarządcza że ktoś daje sobie wejść na glowe bez spisania konkretnych wymagan.
Jeszcze raz. Błędy to nie jest spisanie czegoś nowego to poprawka tego co jest zapisane w specyfikacji i nie działa tak jak zapisane w specyfikacji a to że ktoś myślał że to oznacza co innego niż jest zapisane to kwestia zarządzania wymaganiami.
Ten podpięty przypadek to wręcz wzorowo pokazanie jak ktoś spierdolil zarządzanie projektem. Żeby uzależnić wszystko od jednej osoby i się tym nie interesować to już trzeba być debilem do kwadratu
MostlyRenegadeFanatyk0piorunów@kodyak to z tego, że nie ma faktury. Dostajesz polecenie naprawienia cudzych błędów, jesteś poganiany terminami i nie masz za to żadnej dodatkowej gratyfikacji.
O, coś jak np. tu: https://www.hejto.pl/wpis/jest-taki-moment-w-robocie-kiedy-wszystkie-klamstwa-wychodza-na-jaw-i-ja-juz-sie
Jedyna opcja to rzucić papierami, ale bez gwarancji, że w nowym miejscu będzie lepiej.
Jest taki moment w robocie kiedy wszystkie kłamstwa wychodzą na jaw i ja już się nie spinam xD Wziąłem od zespołu - DexterFromLab - Hejto.plJest taki moment w robocie kiedy wszystkie kłamstwa wychodzą na jaw i ja już się nie spinam xD Wziąłem od zespołu ich byle jaki kod, poczyściłem, zrefaktoryzowałem, pospinałem w pipeline. Ludzie co to projektowali stwierdzili że nie będą się tym zajmować bo nie rozumieją i to dlaHejto.pl@MostlyRenegade no i co z tego że robisz jeszce raz. Faktura to faktura pieniądze idą a to że klient jest glupi to już nie nasza wina. Programistom się wydaje że robią coś co musi się skonczyc i co dalej? Będzie robić to samo gdzie indziej i tak w kółko. Każda praca jest w takim razie bezsensu
MostlyRenegadeFanatyk0piorunów@kodyak ale to dalej jest bezsensowne, bo musisz robić jeszcze raz coś, co już zrobiłeś. Niezależnie od przyczyn.
A jeśli ktoś jest szeregowym programistą, to raczej rzadko kiedy ma wpływ na zarządzanie, na ustalenia z klientem i na to, czy dostanie dodatkową kasę za wykonanie nikomu niepotrzebnej roboty. On dostaje polecenie "weź zrób".
@MostlyRenegade ależ klient dostaje taki produkt jaki chce jaki został wyspecyfikowany ale potem okazuje się że jednak nie taki chce a to już jest CR
Nie mówimy o błędach. Błąd to błąd się naprawia i tyle. Natomiast z tego co widzę ty opisujesz fatalne zarzadzanie a to już inna para kaloszy
MostlyRenegadeFanatyk0piorunów@kodyak to nie zawsze tak działa. Klienta interesuje działający produkt. Jeśli produktu nie ma lub nie działa, zaczynają pretensje. I potem, zgodnie z hierarchią, wszystko to spada na szeregowego kodera: "_dlaczego to nie działa_", "_miałeś to zrobić miesiąc temu_", "_na kiedy to będzie, bo już klient/zarząd się piekli_", "_zrób to na wczoraj, tylko popraw jeszcze to i to_ (czyt.: rozwal architekturę systemu, bo nie działa im jeden konkretny przypadek)", i moje ulubione: "<_dodaj jeszcze na jutro taki pipsztyk, który będzie wymagał tygodnia roboty i przerobienia połowy interfejsu, nie dając w zamian absolutnie żadnej wartości dodanej, ale klient tak chce>_".
A programista to zwierzę z natury leniwe, bo wie, że informatyzacja ma, z założenia, ułatwiać robotę i jej odejmować, a nie na odwrót.
@MostlyRenegade ależ to rozwiązuje problem a na coś nowego robi się cr i wystawia się kolejna fakture 😉
MostlyRenegadeFanatyk0piorunów@kodyak tylko jeśli miernikiem wartości jest ilość naklepanego kodu, a nie rozwiązanie problemu.