Burdel w projekcie

1

Lider techniczny chce by pisać byle jak i to grubo byle jak. Nie chcę podawać szczegółow bo nie chce być rozpoznany. Sytuacja w projekcie jest napięta i nie chcę żeby np ktoś wykorzystał jakoś fakt pisania na forum.
Nie chce się na to godzić, bo w efekcie to ja jako deweloper będę pisał i ja za to będę odpowiadał.

No i jestem wrogiem bo się czepiam zamiast pracować, a ja nie chcę tak pracować. Czuję się jakby wymagano ode mnie gotowania dania z nieswiezych produktów.

Wychodzi na to że będzie trzeba postawić sprawę na ostrzu noża.

Nie jest to jakiś tzw Janusz soft ale zespół w korporacji z siedzibą w USA. Poza mną jeszcze jeden dew to widzi, też o tym głośno mówi, ale to ja.jestem bardziej twarzą w tym duecie, bo pierwszy się postawiłem i pierwszy powiedziałem głośno o szaleństwie pomysłów lidera technicznegi. Ostatni trzeci programista jest swiezakiem totalnym w branży to korzysta z okazji i siedzi cicho.

Co zrobić?
Jak dodatkowo manager chce mieć święty spokój i gra na czas oraz trochę na tzw emocjach,bo projekt czas ucieka itd.

Mieliście kiedyś taką sytuacją że byliście naklaniani do totalnej bykejakosci, ale takiej że np tylko brak testów w projekcie to przy tym mały pikuś. Powiem jedno - spytałem o testy, na co tech lead, a co już chcesz testować? Teraz wyobraźcie sobie tego typu odpowiedź na każde techniczne pytanie.

Jak sobie z tym poradziliscie?

1

Jak wyżej - a jeśli to z jakichś powodów nie wchodzi w grę to jest prosta zasada - miej wyj*bane a będzie ci dane. W tym wypadku zasada ta dotyczy ludzi lida technicznego :)

12

jest takie powiedzenie:

let employee;
while (employees.length) {
    employee = employees.pop();
}
employee.turnOfTheLight();

;)

4

Byłem kiedyś w podobnej sytuacji: mając dwa lata doświadczenia w branży w androidzie zostałem wysłany w delegację do doliny krzemowej z "liderem" na kilku miesięczny projekt. Lider wylądował na miejscu dwa tygodnie wcześniej. Po przylocie do stanów zobaczyłem projekt: o kur... Jak dla mnie całość do przepisania, zapytanie do bazy danych na 400+ znaków, 0 czystego kodu, 0 testów, overengineering na każdym kroku. Miałem z liderem kilka cięższych rozmów o zmianę tego, wszystkie sprowadzały się do tego: ja jestem liderem ja decyduję a od strony klienta: no hej ale jakie zmiany terminy, przecież działa nie będziemy tego zmieniać! Naszym PO / PM byli ludzie od strony klienta. Co zrobiłem? Największy błąd, zaakceptowałem to. Po kilku miesiącach lider odszedł z firmy a ja zostałem z całym tym bagnem. Miałem później kilka nieprzyjemnych rozmów prawie z każdym szczeblem w firmie - nie polecam.

Co bym zrobił teraz w takiej sytuacji: jeśli jesteś pewien swoich racji alarmuj piętro wyżej ponad lidera, może jakiś line manager? Może na przykład niech inna doświadczona osoba zrobi PR / audyt wewnętrzny Twojego projektu? Warto mieć po swojej stronie osoby które mają więcej doświadczenia i są szanowane w firmie.

5

Mój ex szef jak się ostatnio dowiedziałem robił już takie czary w projektach, że daty sumowal na stringach/intach (a mógł skorzystać z wbudowanych klas od dat/czasu) no i potem klient dostał informacje o terminach typu 34 październik, albo 27.14.2018.

U takich mentalnych Januszow widziałem już takie scenariusze
S: "ej, dopisz mi tu funkcjonalność"
Ja: "ale to potrwa minimum 2 dni robocze"
S: "no ale to przecież wystarczy ifa jednego dodać, co Ty będziesz to dwa dni pisał?"
Ja: "wbrew pozorom jest tam więcej zależności i jak dostawie ifa to to pier.olnie"
S: "rozumiem, ale wiesz.. To co już mamy działa i nie mamy czasu na takie rozgrzebywanie kodu"
Ja: "ok"

Po określonym czasie (tydzień, max miesiąc)
Klient: "panowie. Nowa funkcja działa dobrze, ale nie możemy teraz zrobić x, y, z"
Szef do mnie: "no to dlaczego to tak kiepsko napisane i niedziala? Ile czasu zajmie Ci naprawa?"
Ja: "no teraz odkrecenie tego to już zajmie z 3 dni"
S: "to Ty takich prostych rzeczy nie umiesz zrobić? I tyle czasu Ci trzeba.... Ehhhh, daj mi ten kod to sam dopisze"
Po tygodniu
Szef do mnie: "Spier.olilo się na amen, pomush [sic!]"

Jak to u nas się mówi, nie warto kopać się z koniem. Dokończ projekt, a w międzyczasie szukaj innej roboty.

0

Ech nawet nie wiesz jak ky wszyscy Cię rozumiemy. U nas jest w projekcie dociągnę ponad 90 randomowych gemow, juz o backdoorach czy innych podatnosciach nie wspomnę. Plus jest taki ze mlody za 3 miesiące odchodzi do innego teamu, więc mówimy mu co jest zwalone, ostatnio nawet funkcjonuje tekst: Jak zrobisz cos takiego jak tutaj to odesla cie do nas z reklamacja.:)

3

Jeśli to nakłanianie do bylejakości
To montuj spierdolkę.

Tracisz czas, kiedy inni programiści w innych firmach uczą się jak pisać kod coraz lepiej (a to neverending story). Będziesz coraz bardziej z tyłu.

Jak ten lider pisze i robi ten bajzel to pewnie tylko on się w nim rozeznaje i jeszcze będzie wychodzić, że tylko on umi kodować :-)

W międzyczasie wysyłaj linki i artykuły do wszystkich na temat konkretnych zasad kodowania, jakie macie naruszone, to czasem minimalnie przemawia do managementu.
Zwłaszcza jak uda się powiązać bug z konkretnym przypadkiem. Powracające błedy to np. często wynik braku testów.
Pomożesz chociaż innym programistom trochę.

0

często słabsze firmy stosują metodę na "zamęczenie" klienta, po prostu przyjmują poprawki, nieudolnie je implementują, potem to wraca i tak w kółko, klient z czasem je odpuszcza (chcąc mieć produkt, bo termin goni) firma wykonująca ma to gdzieś, bo ciągnie takich projektów kilka, więc nawet jak spłaty się przedłużają to ma je z kilku (też nowych) źródeł, więc tak czy inaczej ktoś zapłaci, a reszta jest "męczona" :)

5

W słabym kodzie też trzeba umieć pracować.
Trzeba wiedzieć kiedy można zrobić refaktoring (np. po implementacji testów).
Trzeba umieć zacisnąć zęby jak widzisz private final class xxxUtil z logiką biznesową.
Albo for który nie jest pętlą - to akurat przypadek z tego tygodnia.
Po prostu odpalasz n analiz statycznych i to co możesz naprawiasz.
I nie wymądrzasz się bo na studiach to nam mówili że tak się nie robi. Bo może lead dawno o tym wie, tylko też ma związane ręce.

Polecam narzędzia:

  • Checkstyle
  • Sonar
  • IDEA \ analiza kodu
  • FindBugs
0

Uciekać. Ja jestem juz na wypowiedzeniu, sytuacje podobne. Najpierw robimy demo technologiczne żeby sprzedać pomysł, wtedy jest gadka "zrób jak najszybciej i byle jak, jak kupią projekt to zrobimy na porządnie". Po miesiącu klient się zdecydował i słyszę "No to połowę roboty już mamy, dopisz do tego reszte funkcjonalności", i lead rzeczywiście wycenia mi projekt na połowę realnego budżetu, FML

0
czysteskarpety napisał(a):

często słabsze firmy stosują metodę na "zamęczenie" klienta, po prostu przyjmują poprawki, nieudolnie je implementują, potem to wraca i tak w kółko, klient z czasem je odpuszcza (chcąc mieć produkt, bo termin goni) firma wykonująca ma to gdzieś, bo ciągnie takich projektów kilka, więc nawet jak spłaty się przedłużają to ma je z kilku (też nowych) źródeł, więc tak czy inaczej ktoś zapłaci, a reszta jest "męczona" :)

oooooo dokładnie taki projekt ratowałem ostatnio, miałem robić 10h, robiłem chyba 200h, nie był to jakiś duży projekt no ale syf na każdym kroku, mój kontrahent przejął ten projekt po 2 innych firmach, całość by zajęła ze 300h robiona od 0 a tak ja 200h przepisywałem to tak by się dało używać i pozbyć się większości błędów i spaghetti.

0

Dziękuję za liczne odpowiedzi
Po prostu jak lider techniczny, uzasadniając to brakiem czasu, zalecił pisać tyko happy path mówiąc że obsługę błędów to się dorobi. To mnie trafiło. Na wiele mogę się zgodzić, ale takiej pracy nie będę firmował.
No po prostu nie.

0

Jak robię porządnie i po swojemu to taka praca mnie po prostu cieszy i czuje się nią spełniony, gdy robimy na odwal się jest wprost przeciwnie. Jeśli nie mogę czerpać przyjemność i spełnienia ze swojej pracy to po co ją w ogóle wykonywać, tym bardziej że jest dużo alternatyw na rynku

2

Na wiele mogę się zgodzić, ale takiej pracy nie będę firmował.

Problem istnieje - tylko jest typowo narodowy :P

5

To, że "jesteś twarzą" w jakiejkolwiek firmie, to typowa januszowa taktyka (również w korpo) - biorą kogoś, mówią mu, jaki jest ważny, więc się zaczyna czuć ważny i bierze więcej odpowiedzialności niż faktycznie może. A potem łatwo się go obwinia jako "twarz" i kogoś "ważnego" - w końcu sam wziął odpowiedzialność, nawet jeśli nieoficjalnie. Szczególnie skuteczna taktyka na ambitnych świeżych studentów - tacy nie chcą przestać być ważni, więc posiedzą po godzinach i w weekendy i jeszcze nie będą chcieli dużo kasy, itd...

I to wszystko niezależnie, czy na prawdę jesteś zajebisty, czy nie. Ważne, aby zwalić na kogoś odpowiedzialność.

Nie powtórz tego błędu w następnej firmie. Bądź nieambitnym nikim, ale rób swoje. Jedynymi sytuacjami w których powinieneś pokazać własną zajebistość jest rozmowa kwalifikacyjna i późniejsze żądania podwyżki. Na codzień się nie wychylaj, bo Cię znowu wydoją.

0
  1. W większości firm wcale nie jest lepiej - "do MVP byle jak a później będziemy poprawiać"
  2. Ty za nic nie odpowiadasz, skoro dostałeś wyraźny sygnał od lidera czego oczekuje to rób swoje. To on odpowiada za projekt i on wie jakie są oczekiwania wobec niego. Skąd wiesz jakie są faktyczne założenia biznesowe, może klientowi faktycznie bardziej zależy na szybkim dostaniu półproduktu niż jakości kodu?
  3. Mimo wszystko rozumiem Twój ból ;)
0
Tadeuszem napisał(a):

Lider techniczny chce by pisać byle jak i to grubo byle jak. (...)
No i jestem wrogiem bo się czepiam zamiast pracować, a ja nie chcę tak pracować. (...)
Co zrobić?

Sposobu funkcjonowania w tej firmie, jak widać, nie zmienisz.
Ktoś Ciebie zmusza do pracy tam? Siłą trzyma?
Nie pasuje - składasz wymówienie i tyle.

0
nobody napisał(a):

To, że "jesteś twarzą" w jakiejkolwiek firmie, to typowa januszowa taktyka (również w korpo) - biorą kogoś, mówią mu, jaki jest ważny, więc się zaczyna czuć ważny i bierze więcej odpowiedzialności niż faktycznie może. A potem łatwo się go obwinia jako "twarz" i kogoś "ważnego" - w końcu sam wziął odpowiedzialność, nawet jeśli nieoficjalnie. Szczególnie skuteczna taktyka na ambitnych świeżych studentów - tacy nie chcą przestać być ważni, więc posiedzą po godzinach i w weekendy i jeszcze nie będą chcieli dużo kasy, itd...

I to wszystko niezależnie, czy na prawdę jesteś zajebisty, czy nie. Ważne, aby zwalić na kogoś odpowiedzialność.

Nie powtórz tego błędu w następnej firmie. Bądź nieambitnym nikim, ale rób swoje. Jedynymi sytuacjami w których powinieneś pokazać własną zajebistość jest rozmowa kwalifikacyjna i późniejsze żądania podwyżki. Na codzień się nie wychylaj, bo Cię znowu wydoją.

Podpisuję się dwiema rękami.

6

tak jest :)
screenshot-20180701224045.png

0
czysteskarpety napisał(a):

tak jest :)
screenshot-20180701224045.png

*Jeśli sprawiasz wrażenie bezużytecznego. A jak przyjdzie do podwyżek to pokaż fakty, a nie wrażenia.

0

"Hurr durr wzorce projektowe, hurr dure testy, hurr durr prawdziwe programowanie to tylko javka i C, hurr durr po co zarabiac pieniadze wazniejszy czysty kod" - polskie janusze programowania.

0

To może druga strona medalu?

Zleciłem projekt swojemu pracownikowi, bardzo dobry programista, zwolennik czystości kodu, potrafi napisać na kilka stron ogólne wymagania jak ma kod wyglądać. Nie akceptuje żadnych kompromisów.

Mieliśmy kilka istotnych rzeczy do dodania w aplikacji, spieszyło nam się - ale nie. najpierw refaktoryzacja, bo nie ma sensu dodawać funkcjonalności do starego kodu. Brzmi logicznie - przekonał mnie... więc zaczął refaktoryzację. Przepisał praktycznie wszystko prawie od zera, zajęło to 3-4 razy więcej niż miało zająć. Przez cały ten czas próbowałem go przekonać żeby jednak trochę odpuścił ale nie - ma być idealnie i tak jak on lubi.

Myślę sobie - zagryzę zęby, będę potem miał kod który on zna od podszewki bo sam go napisał i dodawanie funkcjonalności będzie potem szło jak burza. prawda? niestety nie.

Po skończeniu refaktoryzacji uznał że projekt już zna tak dobrze że warto zmienić pracę i szukać nowych wyzwań. I odszedł niby zostawiając "zrefaktoryzowany kod", fakt sensowniejszy ale jednak zrobiony też trochę pod siebie (momentami miał dość specyficzne wymagania). Ja po 3-4 miesiącach nie miałem nadal nic co chciałem osiągnąć. Proponowałem mu więcej kasy żeby został, ale zaakceptował inny projekt bo "coś nowego więc ciekawsze" za mniejszą kwotę niż ja proponowałem. Po prostu się znudził.

Kolejna osoba jak zaczęła przebąkiwać o drobnych refaktoryzacjach (już nie takich wielkich oczywiście bo jednak kod był lepszy, ale jednak chciał przynajmniej część jego lekko kontrowersyjnych decyzji odkręcić) to po prostu zagroziłem zakończeniem współpracy. I możliwe nawet że ten drugi programista poczuł się dokładnie tak jak Wy. Wkurzający szef każe mu się babrać w cudzym kodzie i nie rozumie... Bo co go obchodzą wymagania biznesowe, programowanie to przecież sztuka a nie praca...

1 użytkowników online, w tym zalogowanych: 0, gości: 1