[singollo]

Bluznę, bo się #!$%@?łem a tutaj mogę się wyładować mniej-więcej anonimowo.
Koledzy programiści, czy jak jesteście na drugim piętrze i szef z dołu woła, żebyście jak najszybciej zeszli na dół, to skaczecie z okna? A jeśli nie, to czemu robicie skróty w kodzie, bo "szef naciska"? Czemu ignorujecie walidację formularzy, czemu omijacie normalny proces deploymentu, czemu olewacie dobre praktyki? Czemu model danych wygląda jak samochód zachlapany szpachlą, bo nie chciało się wam poświęcić mu nawet 10 minut.

Przecież to wy będzie musieli z tym kodem pracować później - albo wasi koledzy. Albo rozwiązywać bugi, które sami, z pełną świadomością, tam umieściliście. 30 minut zaoszczędzone dzisiaj dołoży wam 2 godziny pracy pojutrze.

#!$%@?. Trochę asertywności, #!$%@?.

#programowanie

[Xenesthis]

@singollo: okej, okej, od poniedziałku...

[FLAC]

@singollo: są rozpieszczeni bo jeszcze rynek się nie przesycił nimi. Sytuacja się zmieni jak to się stanie i programista będzie musiał patrzeć na to co robi bo będzie pod ciągłą obserwacją jak u jausza. Bo jak nie to będzie 20 hindusów na jego miejsce ( ͡° ͜ʖ ͡°)

[tjmps]

@singollo: Masz oczywiście rację ale nie wiedziałem, że to taka stresująca praca. Miałem inne problemy bo jestem z innej epoki. ( ͡° ͜ʖ ͡°)

[singollo]

@Xenesthis: w poniedziałek ten kod będzie tak samo #!$%@? jak dzisiaj.

[Ragnarokk]

@singollo:
Albo nie będziesz pracował nigdy więcej, pójdzie deploy i zapomnisz o kodzie, bo masz nowy projekt. Są sytuacje i sytuację, raz zależy na zajebistej jakości kodu, bo będziesz utrzymywał latami, raz zależy na zdążeniu z deadlinem, bo kasa misiu, kasa.
W pisaniu programów chodzi najpierw o zarabianie kasy. Oczywiście jest OS, wówczas zarabiasz nie kasę, a fejm i atencję, co przekłada się pośrednio też na kasę.

[C.....y]

@singollo: Nierealne wymagania funkcjonalne i nierealne ramy czasowe, nietechniczni managerowie, którzy wiedzą lepiej, wreszcie mentalność "jak działa, to na #!$%@? drążyć temat". Kiedyś chyba napiszę książkę o pracy dla pewnej bardzo dużej polskiej firmy (luzem jedna z najbardziej rozpoznawalnych marek w kraju), o ich praktykach, planowaniu, komunikacji między działami, jakości rozwiązań na produkcji i genialnych pomysłach kierownictwa.

[singollo]

@Ragnarokk: pisanie programów to nie jest #!$%@? linii kodu, podobnie jak budowanie budynków to nie jest usypanie kupy cegieł. Kod można pisać lepiej lub gorzej, ale pewnych procedur nie można pominąć bo się w 85% przypadków coś wywali. Np. jeżeli używacie gita, to używacie gita. Nie ma deployów "z mojego komputera ftp-em na serwer, a commit później" bo z tego będą baaaardzo poważne kłopoty. Zamiast fejmu i kasy będziesz miał dissa

[Mingu]

@singollo: A tak z ciekawoci, co rozumiesz przez skrót ? Brak walidacji ?
Nie ma jednego słusznego sposobó deploymentu, są lepsze i gorsze, a i to zależy co w czym i kto pisze.
Co oczywiście nie znaczy, że jakiś mechanizm powinien być wykorzystany, jeżeli jest wolna amerykanka to na pewno nie jest ładnie.
Tak czy inaczej nam formy, których biznes zarabia nie tylko na pisaniu ale także na utrzymywaniu projektów, a

[Ragnarokk]

@singollo Najczęściej oczywiście tak. Ale zdarza się że granica dopuszczalnej jakości kodu przesuwa się w dół. Z różnych przyczyn.

[singollo]

@Ragnarokk: raz obniżona granica zazwyczaj dalej się obniża. Pracowałem dwukrotnie w firmach, w których granica została obniżona tak nisko, że w końcu nie dało się wprowadzać dalszych zmian do kodu, bo nikt nie rozumiał, jak on właściwie działa. Za pierwszym razem udało się kod uporządkować (12 miesięcy pracy), za drugim razem niestety trzeba było zaorać.
W efekcie zostałem trochę specjalistą od grzebania w gównie i - jak mi się zdaje -

[singollo]

@Mingu: jak nie zadbasz o kontrolę wprowadzanych danych to w końcu ktoś czegoś nie wypełni, albo wstawi stringa gdzieś, gdzie powinna być liczba (zapisana jako string :D) albo coś innego - i to się odbije czkawką. Ale to taki niuans, choć potrafi napsuć krwi, kiedy zaczniesz wnikać "co tu się wydarzyło".
Deploy można robić na wiele sposobów, ale nie powinno się ich robić na wiele sposobów jednocześnie. Albo robimy tak, albo

[dan3k]

czemu robicie skróty w kodzie, bo "szef naciska"

@singollo: sam sobie odpowiedziałeś

[singollo]

@dan3k: to też pytam się, czy skoczy z okna, jak mu szef każe szybko zejść na dół.

[dan3k]

@singollo: nie skoczy, ale co to ma do rzeczy? Był czas na analizy, projektowanie, wyceny- tutaj można było uwzględnić odpowiedni narzut czasowy (lub nie uwzględniać jak w Twojej firmie), a dalej jest czas na realizację zgodnie z planem. Kierownik jest od nadzorowania pracy i dbania o dotrzymanie terminów i jego sztuka programistyczna (jeśli nie była uwzględniona w wycenie pracochłonności) nie powinna obchodzić.
Inna sprawa jak ktoś wycenia uczciwie pracę mając na

[singollo]

@dan3k: no więc kierownik ci wycenił problem na 1h, choć ty wiesz, że tobie zajmie 8h, a mimo to, jak pokorne cielę, przyjąłeś to zlecenie i uznałeś, że to jest Twój problem? Czyli jednak skoczysz z okna zamiast zejść po schodach? Taki przypadek może się zdarzyć raz a może dwa; jeśli zdarzył się po raz trzeci to w firmie jest poważny problem. Estymacje czasu wykonania to zadanie osoby piszącej kod; kierownik

[dan3k]

kierownik ci wycenił problem na 1h

@singollo: w żadnej poważnej organizacji (nie-januszsofcie) kierownik nie wycenia zadań, robi to programista.

[singollo]

@dan3k: no i dokładnie o to chodzi. Robisz wycenę i nie ma, że "kierownik naciska". Z drugiej strony, nawet pracując w januszsofcie trzeba być asertywnym i stawiać opór.