Niedawno rozpocząłem karierę jako programista stron internetowych dla średniej wielkości firmy. Gdy tylko zacząłem, dostałem zadanie rozszerzenia istniejącej aplikacji (źle napisane, opracowane przez wielu programistów przez lata, obsługuje te same zadania na różne sposoby, bez struktury).

Więc po pomyślnym rozszerzeniu tej aplikacji o żądaną funkcjonalność, dali mi zadanie pełnego utrzymania aplikacji. To oczywiście nie był problem, a przynajmniej tak myślałem. Ale potem usłyszałem, że nie wolno mi poprawiać istniejącego kodu i skupiać się na naprawie błędów, gdy błąd zostanie zgłoszony.

Od tego czasu miałem jeszcze trzy projekty, takie jak powyższe, które teraz muszę również utrzymywać. Dostałem cztery projekty, w których pozwolono mi stworzyć aplikację od zera, i ja też muszę je utrzymywać.

W tej chwili lekko zaczynam wariować z codziennych maili użytkowników (menedżerów czytających) dla każdej aplikacji, którą muszę utrzymywać. Oczekują, że bezpośrednio obsłużę te e-maile, jednocześnie pracując nad dwoma innymi nowymi projektami (a po nich jest już pięć kolejnych). Smutne jest to, że nie otrzymałem jeszcze raportu o błędzie na temat wszystkiego, co sam zakodowałem. W tym celu otrzymałem tylko okazjonalne prośby o zmianę - 180 stopni.

W każdym razie, czy to normalne? Moim zdaniem wykonuję pracę równoważną całemu zespołowi programistów.

Czy byłem idiotą, kiedy początkowo spodziewałem się, że będzie inaczej?

Wydaje mi się, że ten post zmienił się w wielki rant, ale proszę, powiedz mi, że nie jest tak samo dla każdego programisty.

PS Moja pensja jest prawie równa, jeśli nie niższa niż w kasie w supermarkecie.

Podczas jednego ze staży odkryłem, że spędziłem dużo czasu na naprawianiu błędów. Musisz zdać sobie sprawę, że jako pracownik na poziomie podstawowym nie dostaniesz najseksowniejszej pracy, dostaniesz cholernej pracy, której nikt inny nie chce. To niefortunne, ale tak jest w każdej pracy.

Ponadto musisz zdać sobie sprawę, że dla firmy posiadanie działającego kodu jest ważniejsze niż posiadanie kodu, który jest czysty. Z punktu widzenia firmy zmiana istniejącej struktury jest marnotrawstwem pieniędzy na ponawianie czegoś, co już zostało zrobione, i potencjalnie wprowadza jeszcze więcej błędów. Zazwyczaj tego rodzaju firmy nie są firmami komputerowymi / programistycznymi, więc żaden wystarczająco wysoki kierownik nie ma wystarczającego zaplecza technicznego, aby wiedzieć, że czasami trzeba przeprowadzić te poważne remonty. To powiedziawszy, jeśli twoją firmą zarządzają technicznie kompetentni ludzie i rozumieją wartość dobrego kodu, możesz uzyskać większą swobodę, chociaż czasami musisz wybrać swoje bitwy (w końcu głównym celem firmy jest zarabianie pieniędzy ).

To powiedziawszy, nie jesteś nierozsądny, jeśli chcesz pozostawić swój ślad w oprogramowaniu i chcesz bardziej sensownej pracy. Szkoda też, że masz do czynienia z tak wieloma projektami jednocześnie, jednocześnie wypełniając wnioski od wielu różnych menedżerów.

Jako programista jest faktem, że poświęcisz więcej czasu na utrzymanie i modyfikowanie kodu innych ludzi niż na pisanie własnego od zera. Jeśli jest to dla ciebie problem, być może powinieneś pozostać przy rozwijaniu się jako hobby i rozpocząć inną karierę. Jeśli nie masz nic przeciwko utrzymywaniu kodu, ale czujesz, że nie używasz go skutecznie lub jesteś przytłoczony, musisz to omówić ze swoim menedżerem. Jeśli Twoje problemy są poważniejsze lub uważasz, że menedżerowie nie wiedzą, jak skutecznie zarządzać zestawem umiejętności, warto rozważyć znalezienie pracy w innej firmie. Biorąc pod uwagę stwierdzoną niską pensję, jest to prawdopodobnie najlepszy sposób działania.

Wygląda na to, że zarządzanie ma problem z zarządzaniem obciążeniem i ustalaniem priorytetów zadań. Powinieneś porozmawiać ze swoim przełożonym i dać im do zrozumienia, że ​​jesteś przeciążony i nie możesz wykonywać efektywnej pracy, jeśli wszyscy będą bombardować cię żądaniami, które chcą natychmiast zrealizować.

To sprawia, że ​​przeskakujesz z jednego zadania i projektujesz na drugie, marnując mnóstwo czasu na zmianę biegów. Aby skutecznie pracować nad tworzeniem oprogramowania, należy być w stanie zanurzyć się w zadaniu i w pełni się na nim skoncentrować. Im więcej zakłóceń, tym więcej czasu marnuje się na przełączanie kontekstu. Badania pokazują, że zanurzenie się i dojście do stanu przepływu, w którym nasz umysł działa najskuteczniej, zajmuje około 15 minut . Jeśli pojawią się przerwy co 15 minut, nigdy nie zaczniesz płynąć, co jest ogromnym marnotrawstwem zarówno dla ciebie, jak i dla firmy.

Dlatego powinieneś spróbować wynegocjować bardziej rozsądny tryb pracy ze swoim menedżerem . Powinno to obejmować ustalanie priorytetów dla przychodzących wniosków i planowanie do pewnego stopnia . Wszystkie żądania użytkowników powinny być przechowywane na liście uporządkowanej według priorytetów. O priorytetach nie powinien decydować wnioskodawca (ponieważ oczywiście wszyscy uważają, że jego prośba jest najważniejsza na świecie), ani przez ciebie, ale przez osobę posiadającą wystarczającą wiedzę biznesową i przegląd całej gamy produktów, które utrzymujesz ( właściciel produktu ).

Idealnie byłoby, gdyby wszystkie przychodzące żądania były wprowadzane do modułu do śledzenia problemów, takiego jak JIRA lub Mantis . Lub przynajmniej wysłany pocztą do właściciela produktu, a nie do ciebie. I powinien on również rozpatrywać wszystkie skargi użytkowników dotyczące „dlaczego moja prośba nie jest jeszcze gotowa ?!”, umożliwiając Ci skupienie się na pracach programistycznych. Jeśli jest to nieosiągalne, powinieneś przynajmniej negocjować niektóre przedziały czasu, kiedy patrzysz na przychodzące żądania i radzisz sobie z nimi, rezerwując nieprzerwaną część swojego czasu wyłącznie na rozwój.

Jeśli jest to możliwe, następnym krokiem może być do pewnego stopnia wcześniejsze planowanie. To znaczy, oszacuj czas potrzebny na wdrożenie żądań o najwyższym priorytecie, a następnie zaplanuj swój czas na sprinty , które mogą trwać jeden lub więcej tygodni, i przydziel wystarczającą liczbę zadań na następny sprint, aby pokryć swój czas.

Prawdopodobnie chcesz poświęcić trochę czasu na przychodzące żądania alarmowe, ale resztę można zaplanować z wyprzedzeniem. Możesz także chcieć zorganizować pracę nad różnymi projektami w osobne „pasma”, to znaczy, pracować nad projektem A w poniedziałek, projektem B w Tueday-Wednesday, projektem C w czwartek rano i D po południu itp., Aby dalej zmniejszyć przełączanie kontekstu.

W ten sposób masz ogólne pojęcie o tym, co masz zrobić w ciągu najbliższego tygodnia lub kilku tygodni. Co więcej, daje to również mapę drogową twoim klientom: mogą zobaczyć, kiedy otrzymają, które żądanie zostało zrealizowane. Być może możesz chcieć wspomnieć tutaj swojemu menedżerowi słowo „zwinny” - jest to zasadniczo zwinny rozwój , ale niektórzy ludzie sprzeciwiają się zwinnemu, nie wiedząc, co to jest :-)

Pamiętaj, że nawet jeśli Twoja obecna pozycja wydaje się być przez Twoją firmę nisko ceniona, im więcej utrzymujesz projektów, tym więcej masz siły negocjacyjnej .

Znalezienie i przeszkolenie nowego pracownika do obsługi wszystkich tych projektów zajmuje firmie dużo czasu (= pieniędzy). I możesz słusznie wskazać, że Twój kod jest o wiele lepszy niż starsze części tych aplikacji, więc nie jest oczywiste, że mogą łatwo znaleźć kandydata o podobnych możliwościach za tę samą kwotę. Nie wspominając już o tym, że jeśli nie poprawią warunków pracy, sprawią, że kolejny facet będzie miał dość i odejdzie tak szybko jak ty ... Postaraj się, aby zrozumieli, że w ich najlepszym interesie jest, aby cię zatrzymać, i abyś był szczęśliwy tam, gdzie jesteś :-) Może to dać ci siłę do negocjowania powyższych warunków i / lub zażądania podwyżki.

Ile masz siły negocjacyjnej - to duże pytanie. Twoje kierownictwo może, ale nie musi, być otwarte na te pomysły i może cię nie szanować na tyle, aby poważnie potraktować twoje prośby. Ale jeśli dobrze grasz w swoje karty, masz szansę. A jeśli odmówią ... zawsze możesz poszukać lepszego miejsca pracy. Ta sytuacja nie jest taka sama dla każdego początkującego, chociaż (niestety) twoje doświadczenia są dość typowe. Ale naprawdę są lepsze miejsca pracy . Jakość miejsca pracy jest tylko luźno skorelowana z lokalizacją geograficzną, ale mam wrażenie, że w Europie Północnej masz większe niż przeciętne szanse. Więc jeśli nie możesz wyraźnie poprawić obecnych warunków, powinieneś zacząć szukać natychmiast , zanim całkowicie się zmęczysz i wypalisz.

Niezwykle lepiej jest poszukać pracy, dopóki ją masz, więc nie musisz przyjmować pierwszej oferty tylko dlatego, że potrzebujesz pieniędzy natychmiast. W końcu znajdziesz lepsze miejsce :-)

PS Moja pensja jest prawie równa, jeśli nie niższa niż w kasie w supermarkecie.

Heh Chciałem napisać coś o tym, jak negocjować, dopóki tego nie przeczytam. Teraz wszystko, co mogę powiedzieć, to wyjść! Zakładając, że to połowa tego, co zwykle zarabia programista z dyplomem. Zakładając, że wszystko ulegnie poprawie i że od razu da ci 10% wzrost, sam możesz dowiedzieć się, ile czasu potrzeba, aby się tam dostać. Wygląda również na to, że nie uczysz się niczego w pracy i nie wydaje ci się, że otaczają cię wspaniali inżynierowie, więc to strata czasu.

Byłem w podobnej sytuacji i mogę powiedzieć, że jeśli zostaniesz na tym torze, nigdy się nie skończy. Zarząd będzie naciskał na ciebie, ponieważ ... mogą.

Jest kilka dodatkowych przemyśleń na ten temat.

1. Rób to co kochasz. Jeśli go nie kochasz, przygotuj się na próbę znalezienia tego, co możesz pokochać.

2. Porozumiewanie się. Wyraźnie komunikuj swoje niezdolności do spełnienia nierealistycznych oczekiwań. Z mojego podobnego doświadczenia architekt (który wykonał najwięcej przeszukań) powiedział: „musisz sprostać innym oczekiwaniom”.

3. Wypalić się. Jeśli nie doświadczyłeś wypalenia, nie kusz losu. Wysysa twoje życie i duszę z twojego umysłu. Mimo dołożenia wszelkich starań cel pracy staje się szary, ponury i pozbawiony znaczenia. Udzielam tej rady, ponieważ za wszelką cenę należy unikać wypalenia zawodowego.

4. Trening. Oto srebrna podszewka. Twoje szkolenie i doświadczenie, choć frustrujące i być może niedopłacane, są w rzeczywistości bardzo cenne dla twojej kariery. To twoja zbawcza łaska, aby to zrozumieć, ponieważ możesz pochłonąć jak najwięcej nauki i opóźnić każdy nieunikniony szklany sufit.

Skoncentruj się na rozwijanych talentach i umiejętnościach ... Będą one prowadzić Cię przez kolejne możliwości Twojej kariery.

Masz tutaj do czynienia z wieloma problemami ... Zacznijmy od oczywistych ...

Czy to normalne?

Piekło nie Ale ... czy to jest powszechne? Niestety tak.

Odnośnie frustracji związanej z usuwaniem błędów

Chociaż nie usprawiedliwia to reszty bałaganu, z którym musisz sobie poradzić, i wielu projektów, którymi cię przeciążają, chcę tylko szybko zauważyć, że podejście „naprawiające błędy” zbliża się, jednocześnie frustrując cię jako programistę , może być całkowicie rozsądnym podejściem dla firmy i jej zarządu.

Powierzchnia dla większej liczby błędów i kosztów

Im więcej kodu dotkniesz, tym większe prawdopodobieństwo wprowadzenia błędów, nawet jeśli Twoim celem jest jego poprawienie. Oznacza to wydłużony czas programowania, czas testowania i koszty. A jeśli przejdzie do wersji serwisowej ze średnią do wysokiej wady, to dla nich wielki bałagan.

Hałas / mgła w twoich logach

Z perspektywy SCM ma to również sens, jeśli pracujesz bezpośrednio w gałęzi wydania usługi, ponieważ chcesz mieć czysty widok zmian związanych z naprawą błędów. Jeśli jest 15 zatwierdzeń z tysiącami zmian otaczających poprawkę, które faktycznie wymagały zmiany kodu 1-liniowego, jest to trochę denerwujące.

Będąc nowym pracownikiem, jeszcze bardziej sensowne jest prosić o powstrzymanie się od refaktoryzacji i / lub ulepszania oprogramowania, i całkiem w moim odczuciu, aby być jak najbardziej „chirurgicznym” przy swoich poprawkach błędów. Po prostu powstrzymuje bóle głowy.

Czy możesz zrobić coś na ten temat?

Teraz NIE oznacza to, że istniałyby sposoby na osiągnięcie zarówno rozsądku kodu, jak i rozsądku umysłów zaangażowanych ludzi. Będąc młodsi, powinni poprosić kogoś o sprawdzenie twoich zmian, zwłaszcza poprawek błędów, i upewnienie się, że są zatwierdzone przed przejściem do kompilacji wersji serwisowej. Pozwoliłoby to zapobiec radykalnym zmianom lub je ograniczyć i byłoby bezpieczniejsze.

Projekt z piekła rodem

Kod bzdury, stado programistów, powielanie, architektura bzdur

Ponownie, adwokat diabła tutaj, ale tylko pokazując, że twoje początkowe żądanie zawiera kilka nieistotnych bitów.

Chodzi mi o to: naprawdę naprawdę bardzo rzadko przejmowałem bazę kodów, która nie była w tym stanie. I przy okazji, że to zrobiłem, były to ostatnio projekty lub prototypy, które zostały zapoczątkowane przez dość gwiezdnych programistów. Ale zadziwiająca większość z nich wyglądała jak bzdury, a przerażająca ich liczba to bzdury. Nawet te założone przez dobrych lub świetnych programistów mogą być bzdurami, terminami i innymi zadaniami pomagającymi ...

Witamy w prawdziwej inżynierii oprogramowania przemysłowego!

I wiesz co jest fajne? Często jest gorzej w świecie tworzenia stron internetowych. Cieszyć się! :)

Zbyt wiele projektów i próśb, za mało rąk i czasu

Problem leży prawdopodobnie tutaj:

• twoje kierownictwo (być może nieświadomie) znęcało się nad tobą ,
• twoi koledzy (być może nieświadomie) znęcają się nad tobą ,
• twoje (być może nieświadomie) niewystarczające zasłonięcie się w tyłek i wystarczające stoczenie bitew .

Menedżerowie powinni mieć świadomość, że pracujesz nad zbyt wieloma projektami do zarządzania. Jeśli nie są, upewnij się, że są jak najszybciej. Upewnij się także, że wiedzą, że w parku nie było nic złego, że poczułeś presję i że to musi się skończyć.

Spróbuj się rozejrzeć i upewnij się, że twoi koledzy nie odbijają na tobie więcej zadań i projektów, bezpośrednio (mówiąc naprawdę „X będzie mógł się tym zająć”) lub pośrednio („Nie jestem odpowiednią osobą do znajdź kogoś innego ”-> kończy się to, że jesteś tobą).

Osobista anegdota tutaj: odbyłem staż kilka lat temu i właśnie ostatniego dnia, kiedy dostałem ocenę, mój szef powiedział mi, pomimo ogólnego zadowolenia z mojej pracy, że jeden z kierowników miał wrażenie, że ja rozładowywał niektóre „niezbyt zabawne zadania” na innym stażyście, kiedy spodziewali się, że je podniosę. Byłem przerażony tym, że czuję się zawiedziony, i na pomysł, że będę wyglądać, jakbym się rozluźnił, kiedy mój zamiar był dokładnie odwrotny: starałem się podjąć trudniejsze zadania i sprawić, by inny młodszy stażysta miał mniej włosów problemy z pompowaniem. Nie zdawałem sobie sprawy, że gdybym był na jego miejscu, nudziłby mnie brak wyzwań i prawdopodobnie czułbym się tak, jak on. Chodzi o to, że musisz się komunikować, aby upewnić się, że nikt nie przyjmuje fałszywych założeń dotyczących 3 bardzo różnych rzeczy:

• co można zrobić ,
• co chcesz zrobić ,
• i co chcesz zrobić .

Więc to częściowo twoja wina, że ​​tak się stało. Ale to normalne, to lekcja, której wszyscy muszą się nauczyć. Posiada w dwóch liter: N - O .

Zwykle używasz go jako prefiksu dla dłuższej, ale nie o wiele bardziej obciążonej odpowiedzi: Nie, nie mogę tego zrobić. Nie, nie wiem jak to zrobić. Nie, nie jestem pewien, czy jestem odpowiednią osobą do tego. Nie, nigdy tego nie robiłem.

Na początku bardzo łatwo jest poczuć, że można po prostu powiedzieć „tak, ja (w końcu) to zrobię” i ułożyć rzeczy w stos i załatwić je, może przez poświęcenie dodatkowych godzin. To wszystko źle. Musisz zrozumieć, że Twój czas, po Twoich umiejętnościach, jest najcenniejszym zasobem dla Ciebie i Twojej firmy. Jeśli jest niewłaściwie wykorzystywany, wpływa na projekty, terminy i budżety . Tak proste jak to.

Wygląda na nieco niepokojące, że miałbyś zbyt wiele osób do zgłoszenia. Można mieć do czynienia z wieloma klientami i wieloma właścicielami projektów, a nawet głównymi interesariuszami, z którymi musisz się komunikować. Ale ogólnie rzecz biorąc, zwłaszcza, że ​​jesteś nowym pracownikiem, powinieneś głównie zgłosić się tylko do kilku menedżerów (i najprawdopodobniej tylko do bezpośredniego kierownika, a być może do głównego lub starszego programisty). Jak to się stało? Nie wiem Może to być problem organizacyjny w Twojej firmie lub wynikać z tego, że wyświadczysz przysługę, a następnie skontaktujesz się bezpośrednio i nie powiesz „nie”. Lub może być tak, że twój bezpośredni menedżer ma problemy z wysyłaniem zadań, o ile wiem (naprawdę zgaduję, ale wzór jest rozpoznawalny i dobrze znany).

Radzę raczej szybko wykonać następujące czynności: porozmawiaj osobiście ze swoim bezpośrednim menedżerem, wyjaśnij, że inni menedżerowie mogą być nieco nachalni lub (prawdopodobnie mniej marudny), że masz zbyt wiele rzeczy gromadzących się od zbyt wielu osób, i że potrzebujesz jego wkładu (i być może również ich), aby wiedzieć, które z nich należy traktować priorytetowo.

Żądania zmiany o 180 stopni

To kolejny duży problem. Prawdopodobnie to nie twoja wina, ale możesz spróbować pomóc im to rozwiązać.

„Prośby o zmianę o 180 stopni”, jak je pięknie i dokładnie nazywasz, są wyraźnym znakiem, że wymagania są od samego początku niewyraźne i że nikt nie stara się wystarczająco, by je wykuć i wyjaśnić z czasem.

Zwykle wtedy ktoś musi zadzwonić (lub lepiej, stanąć na nogi), złapać interesariuszy za rękę i powiedzieć im jasno: „tam jesteśmy, tam, gdzie chcesz, abyśmy poszli, czy potwierdzasz, że jesteśmy zmierza we właściwym kierunku? ”. Nie można uzyskać jasnych odpowiedzi na początku, ale im więcej czasu mija, tym wyraźniej powinni się stać, lub ten projekt jest katastrofą, która czeka.

Zwykle powiedziałbym, aby złapać wszystkich interesariuszy w zasięgu ręki, umieścić ich w pokoju, poprowadzić przez sporne problemy i stopniowo próbować je rozwiązać - i uzyskać priorytety, gdy jesteś przy tym. Jednak w Twoim przypadku może to już nie być Twój telefon. Ale wspominasz, że naprawdę powierzyli ci odpowiedzialność za projekty; więc jeśli tak jest naprawdę, weź na siebie odpowiedzialność i zrób to. I NIE wahaj się powiedzieć „nie możemy tego zrobić” , a nawet „nie zrobimy tego” . Naprawdę ważne jest ograniczenie zakresu projektu.

Jeśli nie ma zakresu, nie ma wyraźnych wymagań na końcu dyskusji.

Przeciążenie e-mail

Ludzie zachowują się inaczej w zależności od używanego medium komunikacyjnego. Osobiście, chociaż jestem raczej łagodną osobą (i pracuję głównie w obcych krajach, więc nie lubię też zbytnio rozmawiać przez telefon), wolałbym w kolejności preferencji opartej na wydajności:

• rozmawiać z ludźmi twarzą w twarz ,
• rozmawiać z ludźmi przez telefon,
• rozmawiać z ludźmi przez komunikator internetowy,
• rozmawiać z ludźmi przez e-mail.

E-maile są przydatne do śledzenia, uzyskiwania potwierdzeń, wysyłania notatek.

Do planowania, planowania i omawiania problematycznych punktów są prawie bezużyteczne. Idź pukać do drzwi faceta, aż on je otworzy, i usiądź z notatnikiem i kopią dokumentacji, aby wyjaśnić wszystko. Po zakończeniu wyślij wiadomość e-mail i poproś o potwierdzenie. Jeśli wróci z negatywną odpowiedzią lub nieco ukrytą próbą wykradnięcia czegoś innego z koperty, idź ponownie oblegać biuro swojego rozmówcy.

To jest inżynieria oprogramowania. Często jest bardziej produktywny, gdy nie piszesz na klawiaturze i może faktycznie wyciąć z góry bzdury, z którymi musisz sobie poradzić.

Wykonywanie pracy zespołowej

Czy wykonujesz ekwiwalent pracy zespołu? Może.

Czy wykonujesz równowartość pracy swojego zespołu? Prawdopodobnie nie.

Mam na myśli to, że Twój zespół jest prawdopodobnie zajęty pracą i jesteś przepracowany. I na tym polega problem: jesteś przeciążony rzeczami, które należy wypchnąć z obecnych ram czasowych projektu lub przekazać komuś z czasem na rękach.

Czy byłem idiotą, kiedy początkowo spodziewałem się, że będzie inaczej?

Nie; po prostu nowość na imprezie. To jak pierwszy kac lub związek. Przeżyjesz to.

Wydaje mi się, że ten post zmienił się w wielki rant, ale proszę, powiedz mi, że nie jest tak samo dla każdego programisty.

To samo dotyczy każdego dewelopera w chaotycznych organizacjach, bez względu na to, czy są to start-upy czy ugruntowani giganci, i bez doświadczenia lub pewności siebie, aby coś się poruszyło, aby zwiększyć szanse na przetrwanie po prawej stronie skali.

PS Moja pensja jest prawie równa, jeśli nie niższa niż w kasie w supermarkecie.

Zrobiłem przyzwoite wynagrodzenie za pracę, która wydawałaby się kiepska. Liczy się nie liczba na czeku, to kontekst. Co robisz, twój wiek, gdzie mieszkasz i pracujesz itp.

Biorąc to pod uwagę, jeśli jesteś rażąco niedostatecznie wynagradzany, pracujesz za dużo i nie jesteś całkowicie młodszy, poproś o podwyżkę lub znajdź nową pracę!

To proste:

• jeśli cenią to, co robisz, chętnie zgodzą się na podwyżkę,
• jeśli nie, przyszłość w tej firmie nie wygląda bardzo różowo (przynajmniej dla ciebie, co się liczy), więc nie przejmuj się odejściem.

Pamiętaj, że prośba o podwyżkę jest dobrą rzeczą, nawet jeśli na początku nie będziesz skłonny tak myśleć. Dowodzi to, że śledzisz swoje działania, i daje do zrozumienia, że ​​pilnujesz innej opcji, a jednocześnie chcesz pozostać na pokładzie. Dobrze jest przyzwyczaić się do proszenia o nie, ponieważ są one jak rozmowy kwalifikacyjne lub negocjacje w ogóle: jest to coś, co wymaga praktyki i nie spadają z nieba, jeśli sam nie sięgniesz po nie. Niektóre firmy będą regularnie dystrybuować podwyżki, ale nie są o to proszone, ale tylko dlatego, że są wystarczająco sprytne, aby wiedzieć, że to sprawia, że ​​jesteś w połowie szczęśliwy i mniej chętny do zmiany, i chcą ścinać trawę pod twoją stopą (większość ludzi czułaby nieco niespokojne o podniesienie oferty przebicia, którą zaoferowano bezpośrednio).

Sposób realizacji tego żądania jest nieco poza zakresem tego projektu, więc nie będę wchodził w szczegóły. Ale zalecam, abyś przygotował rejestr identyfikatorów zatwierdzenia SCM, naprawionych błędów i osiągnięć oraz abyś przygotował raporty porównujące je z ogólnym wysiłkiem zespołu. Tą drogą:

• możesz sam sprawdzić, czy skutecznie zrobiłeś znacznie więcej niż inni,
• możesz wytrzymać, jeśli powiedzą, że twoja prośba jest nieuzasadniona.

Oprócz komentarzy innych osób:

1. Tak, to normalne, że pracownik na poziomie podstawowym otrzymuje zadania, których nikt inny nie chce wykonywać.

2. Powinieneś postrzegać to jako element składowy przyszłej kariery.

Co powinieneś zrobić? Aby udowodnić, że jesteś profesjonalnym programistą, musisz upewnić się, że twoja praca jest uporządkowana i zaplanowana, w przeciwnym razie możesz mieć trudności z budowaniem dobrych rzeczy, które obecnie robisz - dlatego powinieneś spróbować wykonać następujące czynności (jeśli jeszcze nie jesteś).

1. Zapisz dokładnie swoją pracę dla każdego projektu. Jeśli więc poświęcisz godzinę na naprawienie błędu w projekcie A, zaloguj się tym razem. Przyda się to menedżerowi, jeśli chcesz omówić obciążenia.

2. Napisz testy jednostkowe. Wspominasz, że niektóre projekty, które prowadzisz, są pełne błędów, więc przypuszczam, że jest kilka (jeśli w ogóle) testów jednostkowych. Dla każdego zgłoszenia błędu napisz test jednostkowy, który powiela błąd, a następnie napraw błąd. Pomoże to zapewnić, że nie wystąpią żadne regresje, poprawi jakość kodu i będzie służyć jako platforma do refaktoryzacji kodu, jeśli masz szansę (na przykład, może pomóc przekonać interesariuszy, że przepisywanie niektórych części może poprawić jakość bez wprowadzania nowych błędów, dzięki pakietowi testów jednostkowych).

3. Poszukaj nowej pracy - pracujesz nad wieloma projektami naraz, napisałeś kod od zera i prawdopodobnie doświadczyłeś całego cyklu życia projektu - są to dobre doświadczenia w aplikowaniu gdzie indziej.

Twoja sytuacja jest nieco nerwowa, ale nadal normalna. Ale sposób, w jaki sobie z tym radzisz, jest bardzo zły. Oto, co musisz zrobić:

• Spróbuj skonfrontować się z szefem. Powinieneś mieć jakiś dowód (liczby), ile czasu faktycznie kosztuje baza złego kodu. Jeśli nie rozumie takich rzeczy jak dług techniczny, przestań o tym wspominać. Zrujnuje ci głowę i możesz zostać uznany za faceta „złego nastawienia”. Twoim zadaniem nie jest uczyć szefa wykonywania swojej pracy.

• Utrzymaj swój własny backlog (kanban). Kiedy pojawią się nowe zadania, zakończ je i podaj szacowany czas wykonania.

• Wydłuż czas reakcji, sprawdź pocztę e-mail tylko dwa razy dziennie. Zazwyczaj przed obiadem i tuż przed wyjazdem. (Po sprawdzeniu wiadomości e-mail nie powinno następować kodowanie, ponieważ może to zrujnować ci głowę).

• Dokonaj drobnego ulepszenia kodu w ramach każdego zadania. Twoim zadaniem jest poprawa kodu, umiejętności i narzędzi, których używasz. W dłuższej perspektywie zwiększy także twoją moralność.

• Brak zmiany projektu w ciągu dnia. Dzisiaj po prostu pracujesz nad projektem X, a jutro rozpoczniesz inne zadanie dla Y.

• Przydziel godzinę na utrzymanie bramy. Oznacza małe zadania, które są trywialne do wykonania. Jeśli to zadanie trwa dłużej niż 10 minut (bez względu na przyczynę), trafia do zaległości i powiadamia kierownika o opóźnieniu.

Teraz nadchodzi najtrudniejsza część. Obecnie menedżerowie nie komunikują się ze sobą i po prostu zakładają, że zakończysz swój projekt z maksymalnym priorytetem. Powoduje to duży stres na głowie, ponieważ jesteś w trakcie kłótni. Musisz zmusić menedżerów do rozpoczęcia koordynacji pracy. Na koniec powinieneś mieć ładne i proste zaległości, a menedżerowie powinni się zastraszać bez ciebie.

Zróbmy więc kilka prostych ról. Są trzej menedżerowie i projekty (Xavier z projektem X, Yvonne z projektem Y i Zed z projektem Z). Masz zaległości na dwa tygodnie, 5 dni na X i 5 dni na Y.

• Z prosi o wykonanie jakiegoś zadania (1 dzień)
• Odpowiadasz, że nastąpi to za 11 dni.
• Z odpowiada, że ​​jest to proste zadanie i nie powinno zająć więcej niż jeden dzień (zauważ, że Z wywiera niewielki nacisk).
• Odpowiadasz, że obecnie pracujesz dla X, a dla Z. Możesz potem wykonać jej pracę.
• Z odpowiada, że ​​i tak powinieneś natychmiast wykonać jego zadanie (zwiększona presja, bezpośrednie naruszenie terytorium X i Y).
• Odpowiadasz, że wykonanie jej zadania opóźni pracę X i Y. Najpierw powinien ich zapytać. Ty także CC X i Y.

Teraz są dwa końce:

• Menedżerowie zaczną na siebie szczekać, wiele e-maili, prawdopodobnie niektóre spotkania ... Powinieneś trzymać się z daleka i pozwolić zwycięzcy przypisać ci zadanie.

• Nic się nie wydarzy, Z zapyta cię dwa dni później, gdzie jest jego zadanie. Odpowiadasz, że obecnie pracujesz dla X, a on nie wspomniał nic o projekcie Z. Znowu CC X.

Teraz tego rodzaju zachowanie może cię zwolnić. Ale twoja sytuacja jest niezrównoważona i prawdopodobnie i tak wkrótce zrezygnujesz. To rozwiązanie działa tylko wtedy, gdy menedżerowie konkurują ze sobą (bardzo zwykle). Powinieneś również prowadzić rejestr swojej pracy (zaległości), na wypadek gdyby ktoś narzekał, że zwlekasz.

Siedem lat temu robiłem przez pewien czas prawie 100% prace konserwacyjne i napisałem o tym artykuł: The Art of Maintenance Programming . Jedna część, która może ci się przydać:

1. Polub to

Jak ktokolwiek może lubić programowanie konserwacji? Deweloperzy marzą o byciu głównymi architektami w swoich zespołach, a kiedy kończą utrzymywanie istniejącego oprogramowania, wydaje się to prawie karą. Nie musi tak być: programowanie konserwacji ma swój własny zestaw wyzwań i wymaga dużo kreatywności, zdolności adaptacyjnych, cierpliwości, dyscypliny i dobrej komunikacji. Może to być również dobre dla twojej kariery: posiadanie bombastycznych wpisów, takich jak „Architektoniczna aplikacja korporacyjna n-tier 24/7” w twoim CV, wygląda dobrze, ale pracodawcy cenią ludzi, którzy rozwiązują problemy; a programowanie konserwacji może być dobrą okazją do wykazania się umiejętnościami rozwiązywania problemów.

Twój problem brzmi jak sommet, o którym częściej słyszysz. Wydaje się, że jest to praca, która z łatwością pasuje do The Daily WTF .

Wiele organizacji bardziej koncentruje się na sprzedaży lub wypychaniu nowych funkcji niż na jakości. Te firmy nie dostrzegają tego, że oprogramowanie ma coś więcej niż cechy zewnętrzne. Ward Cunningham ukuł termin dług techniczny .

Możesz także przeczytać Steve McConnell na temat długu technicznego . Ma kilka interesujących punktów. W Google Tech Talk Ken Swaber mówi o zwinnym tworzeniu oprogramowania . Dobra część dotyczy historii podobnej do twojej. Mówi o projekcie oprogramowania, który stał się „braindead” po 10 latach programowania przez różnych programistów, bez konieczności dokonywania refaktoryzacji . Myślę, że jeśli zobaczysz ten film, zobaczysz wiele podobieństw do tego, co opisujesz.

Każde oprogramowanie ulegnie pogorszeniu pod względem jakości, gdy będzie rozbudowywane. W rzeczywistości, aby przetrwać, będzie musiało. Przepisy Lehmana dość dobrze wyjaśniają tę zasadę. Ostatecznie sprowadzi się do następującego pytania: „Jak przekonać szefa do dokonania refaktoryzacji?” .

Jak podchodziłem do podobnego problemu:

• Zwróciłem się do mojego szefa i wyjaśniłem, że jakość kodu pogarsza się, gdy cały czas się rozwijamy ( Lehman Laws ).
• Próbowałem wyjaśnić mojemu szefowi pojęcie długu technicznego . I że sposób, w jaki pozwala ci pracować, będzie kosztował go pieniądze w dłuższej perspektywie.
• Aby faktycznie pokazać mu, jak poważny był problem, przeprowadziłem (w swoim czasie) analizę kodu statycznego. Szefowie nie rozumieją oprogramowania, ale rozumieją liczby. Chociaż metryki kodu mają swoje wady , dobrze jest mieć coś mierzalnego, o czym można mówić. Spróbuj dowiedzieć się, jakie są normalne odczyty dla tych wskaźników, a będziesz zaskoczony, gdy porównasz to z własną bazą kodów.
• Jeśli nic nie pomaga i nic się nie zmienia, jedyne, co możesz zrobić, to wyjaśnić, że pewna nowa funkcja będzie wymagała przeróbek innych części bazy kodu. Wyjaśnij, że jeśli masz zduplikowany kod, a oni chcą coś zmienić, koszty duplikacji również się powielają.
• Powszechną odpowiedzią na poprzedni punkt będzie to, że nikt nie zapytał, a zatem nie zapłacił za tę przeróbkę. Ta „być może” ta przeróbka jest zbyteczna. Będziesz musiał wyjaśnić, że oprogramowanie zawsze będzie musiało się zmienić. Jak mówią Prawa Lehmana ; będzie musiał się zmienić, aby pozostać w użyciu. Jeśli nie, inne programy, które zmieniły się, zawsze będą żyły. Przetrwają ci, którzy oczekują zmian i mogą się dostosować do zmian. Na tym właśnie polega sprawne tworzenie oprogramowania . ( Wikipedia )

Mój szef używa obecnie koncepcji długu technicznego, aby wyjaśnić naszym klientom, że czasami musimy przerobić części tworzonego oprogramowania. Aby to udowodnić - jeśli masz rozsądnego bossa, możesz zmienić rzeczy na lepsze.

Sytuacja, przed którą stoisz, jest prawie (jeśli nie całkowicie) taka sama dla wielu odświeżaczy.

Dzieje się tak w początkowych fazach kariery. Oto haczyk: musimy przezwyciężyć ten problem i udowodnić naszą wartość firmie (czy to średniej, czy wielonarodowej ). Powinniśmy być w stanie podejmować decyzje dotyczące tego, czego wymagają od nas okoliczności. Więc nie ma nic złego w włożeniu wysiłku w pracę, pod warunkiem, że zostaniesz zauważony i staniesz się indywidualnym pracownikiem. Jeśli jesteś tego wart, firma to zauważy! Adios i powodzenia.

Moim zdaniem firma, która zabrania refaktoryzacji, nie jest warta pracy. Refaktoryzacja jest kluczową umiejętnością tworzenia oprogramowania i narzędzi kontroli wersji sprawiają, że jest bardzo łatwy do opracowania zmian w izolacji bez uszkadzania się „kufer” (w przypadku Refactor faktycznie robi przerwy coś). Jak mówi wujek Bob (parafrazując): „Nie powinieneś prosić o bycie profesjonalistą i dobrze wykonywać swoją pracę”.

Programowanie konserwacji nigdy nie powinno oznaczać utrwalania złego kodu.

Otrzymałem ten e-mail pięć lat temu od jednego z moich przyjaciół.

Email body:    

Nowo dołączony inżynier stażysta pyta swojego szefa „jakie jest znaczenie oceny?”

Szef: „Czy znasz znaczenie rezygnacji?”

Stażysta: „Tak, wiem”

Szef: „Pozwól, że zrozumiem, czym jest wycena, porównując ją z rezygnacją”

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Stażysta: „Tak, szefie, teraz zrozumiałem swoją przyszłość. W celu oceny będę musiał zrezygnować ... !!!”

Gdybym był tobą, spędziłbym kilka godzin po pracy, przebudowując aplikację za darmo. To byłoby prawdopodobnie fajne zadanie. Po zakończeniu pokaż go swojemu szefowi. Jeśli to działa, a ty zajmujesz się konserwacją, nie powinien się martwić. Ułatwi to pracę i otworzy oczy wyższym na Twój potencjał w firmie.

Jestem studentem w pełnym wymiarze godzin, pracuję na pół etatu za 10 USD za godzinę. Robię kontrolę jakości, która jest nudna, powtarzalna i łatwa. Uważam się za szczęściarza, ponieważ wiem, że któregoś dnia otworzy to drzwi do większych i lepszych miejsc.

Tak, zawsze będziesz musiał utrzymywać aplikacje napisane zarówno przez ciebie, jak i przez inne osoby. Jedynym wyjątkiem jest pisanie programu, który nigdy nie wymaga żadnej konserwacji. Więc lepiej bądź dobry w utrzymaniu.

Myślę, że istnieje subtelna wskazówka w twoim pytaniu o wadę w twoim podejściu. Oznacza to, że naprawianie błędów nie wymaga ulepszania kodu.

Ale potem usłyszałem, że nie wolno mi poprawiać istniejącego kodu i skupiać się na naprawie błędów, gdy błąd zostanie zgłoszony.

Nie mogę uwierzyć, że ktoś powiedział ci: „musisz naprawiać błędy bez ulepszania kodu”. To jest trudne i niemożliwe. Nie możesz ponownie napisać aplikacji tylko dlatego, że nie podoba ci się lub trudno jest zrozumieć podejście zastosowane w istniejącej bazie kodu.

Radzę nauczyć się refaktoryzować. Za każdym razem, gdy naprawiasz błąd, masz okazję poprawić przynajmniej część kodu. To, jaka część kodu zostanie przekształcona, zależy od błędu i od tego, jak dobry lub zły jest kod. Ale jeśli naprawiasz błędy i świadomie zostawiasz zapach kodu wszędzie, to nie wykonujesz swojej pracy i narastasz techniczny dług .

Niektóre błędy są naprawiane po prostu przez refaktoryzację, a czasem jest to przydatne refaktoryzować, aby pomóc ci zrozumieć kod . Wynika to z faktu, że refaktoryzacja powinna poprawić łatwość konserwacji i spójność kodu.

Kiedy oceniam naprawę błędu, zwykle podejmuję decyzję, czy główny refaktor będzie najlepszym sposobem na zrobienie tego i biorę to pod uwagę. To samo z testami jednostkowymi. Obie te rzeczy powinny być częścią sposobu pisania kodu, a nie opcjonalne, co wymaga dodatkowego czasu.

Więc nie powinieneś pytać „czy mogę poprawić kod, gdy naprawię błąd?” Bo i tak powinieneś być. Nie powinieneś pytać „czy mogę użyć refaktoryzacji, aby naprawić błąd?” Ponieważ jeśli kod powodujący błąd aplikacji jest pilnie potrzebny do refaktoryzacji, powinieneś to zrobić i tak. Nie powinieneś pytać „czy mogę napisać testy jednostkowe, kiedy naprawię ten błąd?” Ponieważ powinieneś napisać test regresji, zanim zaczniesz próbować naprawić błąd.

NB: Uważam, że odpowiedź na tę odpowiedź powinna być przypisana Jeffowi Atwoodowi, ponieważ połączyłem 3 jego artykuły.

Ten dotyczy pieniędzy. Domyślam się, że na początek jesteś prawdopodobnie zbyt miły dla klientów, którzy już dostali więcej niż zapłacili.

Naucz się podawać cenę za nowe zapytania. Nie jest to łatwe, a klienci często cię wypróbują. Jeśli możesz, skorzystaj z pomocy doświadczonego kierownika projektu / produktu.

Kiedy myślisz o pieniądzach, komunikacja z zarządem staje się znacznie łatwiejsza. Jeśli Twoi obecni klienci dostarczają pieniądze w pełnym wymiarze godzin, nie powinieneś odbierać nowych projektów. Ale zrozumiesz, że kierownictwo będzie nadal próbowało cię zmusić do ich zrobienia.

Jeśli rzeczywiście jesteś cenny dla firmy, zyskasz siłę przetargową. Możesz poprosić ich o zatrudnienie większej liczby osób, pozyskanie mniejszej liczby nowych projektów, pomoc w zmniejszeniu obciążeń związanych z utrzymaniem lub zwiększenie wynagrodzenia.

Pracodawca nie powinien podejmować decyzji o mikromanowaniu w zakresie, w jakim zabronione jest ulepszanie istniejącego kodu. Użyj własnego profesjonalnego osądu. Podczas szacowania pracy uwzględniałbym dodatkowy czas, aby umożliwić pewne refaktoryzowanie, jeśli zwiększy to wydajność w przyszłości.

W każdym razie wygląda na to, że nie komunikujesz się skutecznie ze swoim pracodawcą.

1. Masz dowody, że refaktoryzacja pozwoli zaoszczędzić pieniądze. Przygotuj propozycję projektu refaktoryzacji i pokaż, ile czasu i pieniędzy firma może zaoszczędzić. Nakreśl dokładnie, jakie zmiany wprowadziłbyś w kodzie i jak długo to potrwa.

2. Prowadź dokładny dziennik, aby zapisać, ile czasu spędzasz na kodowaniu, spotkaniach i odpowiadaniu na e-maile. To cię ochroni, jeśli nie dotrzymasz terminu.

3. Zwolnij. Może się to wydawać nieco sprzeczne z intuicją, ale twój czas zostanie wykorzystany tylko wtedy, gdy zrobisz wszystko szybko. Ludzie będą bardziej szanować twój czas, jeśli zrobisz mniej. Na przykład sprawdzałbym e-mail tylko raz lub dwa razy dziennie. W przeciwnym razie ryzykujesz wypaleniem.

4. Biorąc pod uwagę stawkę wynagrodzenia, nie warto się martwić. Pamiętaj, aby codziennie wychodzić na czas. Nie przeznaczaj dodatkowych godzin bez dodatkowego odszkodowania. Wyjątkiem jest to, że jeśli istnieją dobre opcje awansu lub jeśli reputacja firmy znacznie poprawi twoje CV, będziesz musiał go po prostu wyssać.

Nie wiedząc więcej, sugerowałbym, abyś starał się być bardziej otwarty ze swoimi menedżerami. Może zacznij zwiększać swoje prognozy zadań. Ciągle przypominaj im o tym, jak intensywne jest twoje obciążenie pracą. Powinieneś także spotkać się z szefem i wyjaśnić, że chciałbyś podwyżki wynagrodzeń w ciągu najbliższych sześciu miesięcy, i zapytać, jak możesz poprawić swoje wyniki, aby osiągnąć ten wzrost wynagrodzenia.

Powodzenia.

Z mojego doświadczenia wynika, że ​​świat akademicki lub pierwsze 6-12 miesięcy start-upu zorientowanego na technologię to jedyne dwa niezawodne obszary, w których spotkasz prawdziwą pustkę. Obie ponoszą własne koszty, ale jeśli lubisz kodować i często jesteś przerażony jakością kodu, którą odkrywasz na wolności, powinieneś zacząć kierować swoją karierę w jednym z tych kierunków.

Spróbuj porozmawiać ze swoimi pracodawcami i sprawdź, czy możesz to rozwiązać. Wygląda na to, że jesteś o wiele za daleko i nie ma to nic wspólnego z byciem złym programistą.

Mniejsze firmy internetowe zwykle realizują wiele projektów jednocześnie, co pod wieloma względami pozostawia cię w dość trudnej sytuacji. Spróbuj jak najlepiej wykorzystać swoją sytuację lub spróbuj znaleźć nową pracę, jeśli uważasz, że możesz. Obiecuję, że są lepsze zadania kodowania, więc nie pozwól, aby ten pierwszy cię odstraszył.

Powodzenia i mam nadzieję, że zarówno ty, jak i twoi współpracownicy rozumiecie powagę lub wasze wysiłki!

Osobiste doświadczenie

Jak wielu tutaj, rozpoznaję twoją sytuację. Zasadniczo dostałem pierwszą pracę programistyczną z niskim wynagrodzeniem i musiałem utrzymywać dużo wbudowanego kodu o złej strukturze. Na początku zabawnie było uczyć się nowych rzeczy, ale kiedy w końcu miałem wiele projektów do utrzymania, nowe projekty do zrobienia i biała tablica, która z każdym dniem stawała się coraz większa, z punktami, z którymi nie skończyłem, zdałem sobie sprawę, że to nie działało.

Po dwóch latach rezygnacji z pracy zrezygnowałem i kilka miesięcy później znalazłem inną pracę programistyczną, która idealnie do mnie pasuje.

Zresztą wiele razy problemem mogą być nie tylko twoje projekty. Czuję się bardziej komfortowo w miejscu pracy, kiedy jestem doceniany i szanowany za swoją pracę. Problem z sytuacją, w której się znajdujesz, polega na tym, że twoi pracodawcy mogą zauważyć tylko błędy wynikające z tworzonych projektów, a nie czas potrzebny na usunięcie wszystkich innych błędów.

Wynagrodzenie

Jeśli chcesz więcej pieniędzy, często możesz je zdobyć. Udało mi się wynegocjować wynagrodzenie w ciągu dwóch lat do podwyżki o 33%.

Zasadniczo pomyśl o wartości swojej pracy i tym, jak bardzo firma Cię potrzebuje. Jeśli nie mogą sobie pozwolić na wynagrodzenie, które zarobiłeś, firma musi spojrzeć na swoje wydatki lub uświadomić sobie, że ich firma nie działa.

Jak wspomniało wielu tutaj, zgadzam się, że jesteś bardzo wartościowym elementem układanki firmowej. Do diabła, prawdopodobnie jesteś jedynym, który może rozwiązać tę zagadkę. :)

Ponieważ nie mogę jeszcze komentować, ponieważ jestem czającym się w tej witrynie Stack Exchange, dodam tylko informacje tutaj.

1. Ponieważ dopiero zaczynasz, twoja pensja nie będzie gwiezdna, chyba że pójdziesz do pracy dla dużej firmy, takiej jak Microsoft, Amazon czy coś podobnego. Ale nie powinien to być pracownik sklepu spożywczego! Nie znoś tego zbyt długo, zdobywaj doświadczenie robiąc to, co robisz i idź dalej, gdy pojawi się lepsza okazja.

2. W przypadku występu na poziomie podstawowym jest to normalne. Twoje obciążenie pracą jest zbyt duże, ale oczekuje się rodzaju pracy. Aby zostać lepszym programistą, musisz uczyć się na błędach innych. Im więcej widzisz, tym lepiej się stajesz. Ale to oznacza, że ​​szukasz rzeczy do nauki, a nie uczenia się złych nawyków ...

3. Stosunek konserwacji do prac projektowych powinien zmieniać się w czasie. Jeśli tak nie jest, oznacza to, że firma, dla której pracujesz, nie zdaje sobie sprawy, jak utrzymać dobrego programistę; zamierzają, abyś robił to samo każdego dnia. Wyznacz sobie roczny cel co do tego, gdzie chciałbyś być, mądre wynagrodzenie i oczekiwania na pracę, i odpowiednio się przenieś.

4) Jeśli nie jesteś szczęśliwy, wyjdź! Życie jest zbyt krótkie, aby poradzić sobie z głupimi ludźmi.

Wszystkiego najlepszego.

Zaczynasz używać narzędzia do śledzenia problemów do śledzenia listy rzeczy do zrobienia.

Pomoże to nie tylko śledzić, co jest najważniejsze, ale pomoże użytkownikom i szefowi zobaczyć, jakie jest twoje obecne obciążenie pracą.

Ponadto, jeśli kiedykolwiek zatrudnią drugiego programistę (lub zrezygnujesz, a Twój zastępca przejmie teraz twoje obciążenie pracą), pomoże to w zarządzaniu obciążeniem i będziesz w stanie uniknąć nadepnięcia sobie nawzajem.

Jedynym sposobem na przełamanie tego łańcucha jest opracowanie nowych infrastruktur zaprojektowanych z myślą o elastyczności i przetestowanych pod kątem pełnej integracji z jednostką.

Jeśli uda ci się sprzedać to kierownictwu (zapisz innych programistów i menedżerów do koncepcji na spotkaniach 1: 1), możesz powoli osiągnąć stan, w którym większość kodu aplikacji znajduje się w infrastrukturze i łatwo jest rozszerzaj i utrzymuj, podczas gdy rzeczywiste aplikacje są lekkie i można je pisać dość szybko.

Rozwój infrastruktury może umożliwić najpierw wymianę części istniejących aplikacji, a po pewnym czasie (może potrwać kilka lat) wymianę całych aplikacji.

W dłuższej perspektywie może to drastycznie skrócić czas opracowywania nowych aplikacji i czas konserwacji istniejących aplikacji.

Nowe opracowanie będzie wymagało co najmniej 80% poświęcenia (najlepiej więcej) z zespołem złożonym z więcej niż jednego programisty (kilka umysłów jest lepszych niż jeden). Wszyscy programiści będą musieli myśleć twórczo i przełamać istniejące uprzedzenia.

Spróbuj zdefiniować i zaprojektować nowy poziom takiej nowej infrastruktury, a następnie przedstaw definicję swoim rówieśnikom i zarządowi.

Jeśli chodzi o warunki pracy, poproś o kierowanie nowym zespołem ds. Infrastruktury, który zajmuje się tymi problemami (w oparciu o twoje definicje i projekt) i pozyskanie nowych programistów, którzy utrzymają stare rzeczy, podczas gdy ty będziesz im pomagał, jeśli to konieczne (do 10-20% czas). Jeśli kierownictwo zaakceptuje pomysł, możesz poprosić o renegocjację warunków. Przygotuj się na znalezienie innej pracy, jeśli odmówią. (Pamiętaj, że twoja praca wymaga umiejętności, wiedzy i doświadczenia, nie jesteś tak łatwy do zastąpienia, jak płacą ci za wiarę).

Czy Twój kierownik jest świadomy wszystkich tych żądań zmian (zleceń konserwacji)? Czy zdaje sobie sprawę, że Twój czas zajmuje przesiewanie przez takie prośby, że nie masz uprawnień do sankcjonowania? A może wprowadzasz zmiany za każdym razem, gdy menedżer Cię o to pyta?

Wydaje mi się, że twoim pierwszym portem do zawinięcia jest umieszczenie tego wszystkiego na biurku twojego kierownika. Nikt nie powinien do ciebie przychodzić bezpośrednio. Problemy powinny pochodzić od każdego, kto obsługuje takie pola - zwykle zespół wsparcia. To normalne, że obsługujesz swój kod przez krótki okres przekazania - zwykle około tygodnia. Zmiany powinny być wyceniane i naliczane (ładowanie transferowe) w każdej firmie, która klasyfikuje się jako „średniej wielkości”, i wydaje się, że jest omijana (nic dziwnego, że cię zalewają - jesteś jak dziwka na balu maturalnym).

Powinna istnieć odpowiednia procedura zgłaszania problemów i zgłaszania zmian. Wsparcie / konserwacja polega na naprawianiu błędów i problemów (które pasują do oryginalnej specyfikacji, ale zawodzą z powodu błędu w kodzie lub zdarzenia zewnętrznego - takiego jak wyłączenie zasilania lub uszkodzony system nadrzędny itp.).

Jeśli Twoja firma tego nie oferuje i oczekuje, że poradzisz sobie z odpowiedzialnością za niezliczoną liczbę losowych próśb, poważnie powinieneś rozważyć kontynuację. Płaca jest zawsze niska na dole - w mojej pierwszej pracy programistycznej (prawie 25 lat temu) spędziłem 8 lat w tej samej firmie i moja pensja nieznacznie wzrosła (chociaż zawsze była znacznie wyższa niż w kasie!). W ciągu 2 lat od odejścia podwoiłem go - a dwa lata później zabrałem do domu ponad dziesięć razy, od czego zacząłem (ale wtedy byłem niezależnym wykonawcą). Jak zawsze, zarabiaj ostrogi, ucz się handlu i skacz statkiem do cieplejszego otoczenia.

Być może jesteś w stanie udać się do menedżera i powiedzieć: „Słuchaj, będę z tobą szczery. Moje wynagrodzenie jest okropne, mógłbym dostać N razy tyle jako programista na poziomie podstawowym w X.

Robię zbyt wiele rzeczy z A, B i C. Nie mogę tego utrzymać. Szczerze mówiąc i bez zamiaru przestępstwa, wyjdę z tego pokoju z tym albo naprawionym, albo z listem rezygnacyjnym pozostającym z tobą. Teraz, gdy wszystko jest już w powietrzu, jak możemy współpracować, aby to naprawić? ”

Odpowiedź brzmi: spróbuj wyjaśnić to w zrozumiały sposób;

• To jest jak wymiana oleju. Nie są pilne ... ale muszą być wykonywane regularnie
• pomaluj rdzę, a będzie świetnie wyglądać. Aż się wykrwawi
• zbuduj nowe biurko na dachu na dachu bez wzmocnień. Może będzie działać przez jakiś czas. Wtedy to się zawali i skrzywdzi ludzi, a ty będziesz odpowiedzialny.
• klimatyzacja jest świetna. Jednostka okienna doskonale nadaje się do jednego lub dwóch pomieszczeń. Próbując umieścić 146 klimatyzatorów okiennych w budynku mieszkalnym, a będziesz miał ... problemy.
• Nauczanie 5 dzieci jest w porządku. 10 nie jest takie złe. Ale są ograniczenia. Spróbuj nieformalnie uczyć 75 dzieci, a zobaczysz to.

Jeśli nie rezonują. Wyjdź - DZIEŃ, KTÓRY OTRZYMASZ OFERTĘ NA PISANIE, nie następnego dnia! Gdy masz nową pracę, wyjdź z powiadomieniem ZERO. Dosłownie po prostu nie przychodzą tego dnia. Ale upewnij się, że masz kolegę lub dwóch, którzy wiedzą, co zrobiłeś. Pomoże to firmie, jeśli można jej pomóc, pokazując, że ich brak szacunku i arogancja ma swoją cenę. W ostatnim towarzystwie byłem TRZY Z CZTERECH CZTERECH TECHNIK W LEWO W CIĄGU 6 MIESIĘCY, BEZ ZADANIA, DO KTÓREGO MOŻNA PRZEJŚĆ. Przyniosło to przynajmniej oświadczenie i dawało osobie odchodzącej dobrą okazję, by powiedzieć: „tak, miło, że mówisz codziennie, ale jesteś tego tak pełen, że nawet nie daję ci satysfakcji z mojego powiadomienia.

Wreszcie, wiedzcie, że ta sprawa była NORM i standardem 20 lat temu, zanim agile, tdd, bdd i refaktoryzacja stały się czymś więcej niż normą. Być może rozmawiasz ze starszymi ludźmi, którzy natychmiast odpowiadają: „Cóż, zrobiłem to sam i zadziałało dobrze, bla, bla, bla”. Cóż, nasze konie i powozy działały dobrze 150 lat temu. W dziedzinie technologii techniki sprzed 20 lat są tak samo przestarzałe jak transport sprzed 150 lat. Jeśli odrzucą tę grzywnę. Po prostu wiedz, że nigdy nie będą zatrudniać żadnych przyzwoitych programistów, którzy będą się trzymać. Dostaną najgorsze z najgorszych i okropnie zaszkodzą ich biznesowi. Jeśli zależą od technologii i nie mogą się przystosować, poniosą porażkę, co ostatecznie może być najlepszą nagrodą dla Ciebie. To'

Wygląda na to, że twoje kierownictwo zasadniczo cię nie szanuje ani nie rozumie obciążenia pracą.

Nie powinieneś wdrażać każdego przychodzącego żądania funkcji. Twój menedżer powinien działać jako bufor między tobą a przychodzącymi żądaniami (z wyjątkiem być może najprostszych żądań przerwania / naprawy). Następnie powinien usiąść z tobą i ustalić wykonalność i priorytet wszelkich zatwierdzonych wniosków.

Powinieneś też robić prawdopodobnie 2x (przynajmniej) tyle, ile ci płacą.

Wygląda na to, że prawdopodobnie naprawdę potrzebują co najmniej 1 programisty, aby współpracował z tobą, ale przy tym, co płacą, brzmi to raczej mało prawdopodobne.

Jeśli nie chcą odpowiednio zapłacić lub pomóc w zarządzaniu obciążeniem, szukałbym nowej pracy. Chcesz pracować w miejscu, w którym jesteś częścią zespołu i gdzie twoje zarządzanie współpracuje z Tobą przy realizacji Twoich projektów. Jak najszybciej wysiądź z tonącego statku.

Bycie bohaterem w jednym zespole tylko cię wypali.

Jestem tylko studentem (nadal), ale to całkiem normalne (z mojego doświadczenia zawodowego). Właśnie to dostajesz, pracując w pomocy technicznej i aplikacjach internetowych.

Radzę zrozumieć, czego chce klient (menedżer) przed rozpoczęciem kodowania. Może to być trudne, ponieważ czasami sami tego nie wiedzą, więc pracuj z nimi, dopóki się nie zgodzą. Upewnij się, że oboje zgadzacie się na ostateczne rozwiązanie przed jego kodowaniem.

Również jeśli jesteś opiekunem, możesz prawie wszystko zmienić w kodzie - po prostu upewnij się, że nie zmienia to zachowania ani nie wprowadza błędów. Oczekuję, że menedżerowie „nie pozwolą” na nic zmienić, ponieważ są przyzwyczajeni i zadowoleni z obecnej sytuacji i nie chcą płacić za nowe zmiany.

Wreszcie, nie martw się, jeśli nie możesz sobie z tym poradzić, ponieważ robisz coś innego. Radzę poinformować ludzi, że jesteś przytłoczony pracą, a ich prośba zajmie trochę czasu. Jeśli nie, menedżerowie uważają, że jesteś leniwy. Poinformuj ich, że masz już pracę, a mogą zatrudnić więcej osób. Nie ma innego sposobu, aby wiedzieć, że praca jest zbyt duża dla jednej osoby.

Jest to problem zarządzania projektem. Użyj pewnego rodzaju zarządzania projektami, aby zdecydować, nad czym ma najwyższy priorytet.

a) Potrzebujesz backlogu przedmiotów do pracy. Twój plan ulepszenia kodu umieściłeś w zaległościach.

b) Wszystkie błędy trafiają do zaległości

c) Zaległości są traktowane priorytetowo.

d) Wszystko robisz w kolejności priorytetowej.

Błędy mogą równie dobrze mieć wyższy priorytet, ale jeśli raz naprawisz wszystko, masz cykle do wydania na nowe funkcje lub na refaktoryzację projektu.

Najłatwiej jest po prostu wprowadzać ulepszenia refaktoryzacyjne stopniowo, gdy przechodzisz przez sekcje, które mają problemy / błędy do naprawienia. Następnie możesz powiedzieć zarządowi: „Musiałem naprawić A, ale B został zasadniczo zepsuty i musiałem zrobić rozwiązanie C, aby naprawić wszystko, aby D w przyszłości będzie łatwiej / taniej” Gdzie A = Błąd, B = Błąd anty-wzór, C = rozwiązanie, D = przyszłe zyski

Jeśli nie możesz usprawiedliwić pracy jako wartościowej inwestycji, ludzie biznesu nigdy jej nie zaakceptują.

To normalny biznes. Wydaje się, że będziesz eksploatowany tak długo, jak długo będziesz tam pracował. W interesie firmy leży kontynuacja korzystania z tego modelu, a nie sprawianie, abyś był zadowolony z tego, co robisz. Jeśli chodzi o to, tak naprawdę ich to nie obchodzi. Chodzi o stworzenie dla nich niezawodnego kodu, a jeśli jesteś zespołem jednoosobowym, z pewnością robią to za ciebie. Dlaczego mieliby się zmienić?

Dobrą wiadomością jest to, że jesteś dla nich VIP-em, nawet jeśli tego nie wiedzą. Sugeruję, aby wyrównać szanse przed skokiem statku, a następnie złapać je za kule i zażądać wyższej pensji. Jeśli nie, przejdź do lepszej okazji. Moim zdaniem wkrótce powinieneś znaleźć więcej ekscytujących prac. Celuj jak najwyżej. Po przejściu do sklepu dla programistów będziesz znacznie szczęśliwszy, jak Google lub jakiś fajny startup, w którym istnieje kultura współpracy dla programistów, w której naprawdę poczujesz się szczęśliwy.

To, co zrobiłem osobiście, to skorzystanie z usług organizacji head hunterów i szybkie zdobycie wielu wspaniałych doświadczeń, przechodząc od jednego do drugiego, jednocześnie utrzymując stałe zatrudnienie u mojego kontrahenta. Zapobiega znudzeniu i stanowi wyzwanie. W końcu w wolnym czasie założyłem małą firmę, która przekształciła się w rzeczywistą działalność, a potem zrezygnowałem z pracy na zlecenie.