Hub pełen jest prognoz i porad, co robić w przyszłym roku – jakich języków się uczyć, na jakich obszarach się skupić, co zrobić ze swoim zdrowiem. Brzmi inspirująco! Ale każdy medal ma dwie strony i potykamy się nie tylko w czymś nowym, ale przede wszystkim w tym, co robimy na co dzień. „Dlaczego nikt mnie nie ostrzegł!” – krzyczymy zirytowani, zwykle zwracając się do siebie. Rozpalmy ogień – przygotowaliśmy dla Was listę tego, czego NIE robić w 2020 (a może i zawsze).
Ale nie pytali o grawitację
Bardzo chcielibyśmy uporządkować antyrekomendacje od najważniejszych do najmniej ważnych. Ale są one na tyle powszechne, równoważne i znane prawie każdemu, że napiszemy losowo. Cóż, sprawdźmy listę?
Nie ma potrzeby iść do IT, jeśli wszystko jest w porządku
Nie ucz się nowych technologii, aby zmienić karierę lub zacząć od nowa. Nasze czasy są cudowne, bo można się uczyć, zmieniać pracę, radykalnie zmieniać zawód – i tak dalej, aż do emerytury. To fajna, uwodzicielska rzecz. Ale jeśli masz więcej niż 28-30 lat, nie powinieneś rezygnować ze wszystkiego, aby wejść do IT lub przejść na nowy stos (na przykład piszesz mocno obciążone systemy w Javie i nagle decydujesz się na sieci neuronowe w Pythonie). Powód jest prosty: nie będzie to dla Ciebie łatwe. Po pierwsze, istnieje duża konkurencja ze strony specjalistów, którzy „siedzą” na tym stosie od początku swojej kariery, po drugie, będziesz musiał ponownie zostać juniorem z niską pensją, a po trzecie, moralnie będzie ci trudno stać się podwładnym najniższego szczebla hierarchii. Dlatego jeśli chcesz pójść w innym kierunku, spróbuj to zrobić albo zgodnie z obecną pracą i bieżącymi zadaniami, albo rozwijaj nową wiedzę w ramach hobby, rozpocznij projekt domowy, aby po przyjściu do nowej pracy nie być już juniorem.
Zmiana stosu za stosem to tylko strata czasu
Nie spiesz się między stosami technologii w celu rozwoju. Jeśli piszesz projekt w jednym języku, korzystając z określonego frameworka i bibliotek, nie powinieneś rzucać wszystkiego w cholerę i przepisywać w Darcie tylko dlatego, że wydaje ci się to interesujące. Zasadą jest szukanie uzasadnienia dla zmiany technologii – nie tylko na poziomie „chcę albo nie mogę”, ale także na poziomie finansowym i inżynierskim.
Nie musisz upierać się przy swoim i zdobywać brązu
Trzymanie się jednego języka lub technologii i nieuczenie się nowych rzeczy jest tak ekstremalne, jak zmienianie stosu przy każdej nowej technologii. Koniecznie studiuj nowe biblioteki i frameworki, nie upieraj się, że wszystko zostało lepiej wymyślone przed tobą i ukończone wyłącznie przez ciebie. Ciągle wychodzą aktualizacje dla prawie każdego języka, co czasami może znacznie ulepszyć Twój projekt. Nie bądź leniwy w monitorowaniu dynamiki swojego stosu, a gdy tylko znajdziesz coś fajnego i przydatnego, nie wahaj się przeciągnąć tego do projektu!
Twoja własna głowa jest dobra, zawsze dobra
Nie myśl o cudzych głowach, twoja własna jest lepsza. Niestety, niektórzy programiści siedzą i czekają, aż otrzymają zadanie kodowania od poprzedniego błędu do końca, nie próbując wnieść do projektu czegoś własnego, opracować nowej funkcji, przetestować jej i zaproponować do produkcji. Po co zawracać sobie głowę, skoro jest lider zespołu lub menadżer firmy, który sam o wszystkim zdecyduje? Jeśli rozpoznajesz siebie, to mamy złą wiadomość: stanowisko pasywne nie pomoże ani w Twojej karierze, ani w rozwoju. Masz szansę spróbować swoich sił jako inżynier rozwoju, a nie koder, w prawdziwym projekcie bojowym i zrozumieć, dokąd iść, czego brakuje, ale wolisz spędzać czas na czymś innym i robić dokładnie „odtąd do Teraz." Tacy ludzie coraz gorzej radzą sobie we współczesnym IT, wychodzą z zawieszenia animacji.
Użytkownicy to okropni ludzie
Nie przeceniaj użytkowników swojego oprogramowania: jeśli nie piszesz dla programistów, spodziewaj się, że program napotka nieprzeniknione nieporozumienia. Przez pierwsze kilka dni lub tygodni użytkownik będzie nienawidził Twojego oprogramowania, ponieważ „stare nie było takie głupie”. Aby tego uniknąć, twórz świetną dokumentację i tutoriale. Podczas instalacji lub zakupu bardzo nachalnie podpowiadamy, że instrukcje należy przeczytać przed rozpoczęciem pracy z programem, a nie po awarii bazy danych, utracie hasła i samokontroli.
Nie należy też lekceważyć użytkowników: są bardziej przebiegli, mądrzejsi i ciekawsi, niż myślisz. Jeśli myślisz, że błąd ze zmiennym formatem i wyjątek przy 138. naciśnięciu Enter w odstępach sekundowych nie wyskoczy, to się mylisz - wyskoczą i w najdziwniejszy sposób wpłyną na działanie Twojej aplikacji. Obowiązuje zasada amatora: to on najlepiej radzi sobie z testowaniem. Ale z jakiegoś powodu użytkownicy nie lubią znajdować błędów na produkcji - nie ma w nich solidarności IT. Ogólnie rzecz biorąc, im bardziej pewny jesteś swojego oprogramowania, tym lepiej. W końcu lepiej opóźnić wydanie niektórych funkcji, niż dodać je do działającej aplikacji i nagle uczynić ją surową.
Przestań googlować!
Przestań zwracać się wyłącznie do Google. Nawet nie będziemy się kłócić - w dziedzinie rozwoju można wiele znaleźć, wysyłając bezpośrednie żądanie do wyszukiwarki. Im głębiej będziesz szukać informacji, tym więcej „pobocznych” danych otrzymasz i tym więcej się dowiesz, bo dowiesz się czegoś nowego, co nie jest związane z Twoją prośbą, ale prawdopodobnie będzie potrzebne w przyszłości. Zapoznaj się z pełnowartościowymi materiałami, książkami, artykułami itp. Języki i biblioteki mają specyfikacje, społeczności, instrukcje, dzięki czemu otrzymujesz najbardziej niezawodny sposób rozwijania umiejętności programisty - wystarczy przeczytać dokumentację, a nie szukać lokalnych rozwiązań i fragmentów kodu innych osób. A co jeśli Twoje rozwiązanie będzie bardziej optymalne, szybsze i chłodniejsze?
Zaufanie, ale sprawdzić
Nie używaj bibliotek i frameworków stworzonych przez zewnętrznych programistów bez sprawdzenia kodu i dostosowania go do swoich celów. Nie masz powodu, aby bezwarunkowo ufać autorowi kodu, którego w ogóle nie znasz. Tak, różne celowo szkodliwe elementy w kodzie stron trzecich nie są tak powszechne i nie powinieneś wpadać w paranoję, ale ślepe kopiowanie gotowych części oprogramowania do swojego projektu może prowadzić do nieprzewidywalnych konsekwencji. Dlatego koniecznie przeczytaj i przeanalizuj kod przed użyciem oraz przetestuj po zaimplementowaniu kodu.
Twórz kopie zapasowe!
Przestań nie tworzyć kopii zapasowych ani nie przechowywać ich na tych samych serwerach innych firm, na których hostowany jest Twój projekt. Czy uważasz, że to śmieszna i bezużyteczna rada? Ale ponad 700 uczestników czatu na Telegramie, którzy niedawno znaleźli się w nieprzyjemnej sytuacji związanej z zamknięciem jednego znanego centrum danych, tak nie uważało - było tam wszystko: od projektów domowych po duże strony rządowe. władze oraz korporacyjne bazy danych 1C i rozliczeniowe. Znaczna część odbywa się bez kopii zapasowych lub z kopiami zapasowymi w tym samym miejscu. Rozłóż więc ryzyko i przechowuj kopię zapasową przynajmniej na głównym hostingu, na pewnym niezawodnym VDS i na serwerze lokalnym. W dłuższej perspektywie wyjdzie to znacznie taniej.
Przestań wnosić własne działania ze szkodą dla projektu
W projekcie roboczym nie rób tego, co chcesz, ale rób to, czego potrzebują klienci. Tak, stworzenie własnej sieci neuronowej, wyszkolenie jej i wdrożenie w swoim oprogramowaniu jest niezwykle interesujące i świetne, ale jeśli Twoi klienci potrzebują prostego menedżera kontaktów, będzie to przesada. Zobacz, jak działa projekt, przeczytaj dokumentację, przeczytaj recenzje i prośby klientów i wdroż to, co doda wartość biznesową do projektu. Jeśli chcesz stworzyć coś naukowego lub niezwykle złożonego, zacznij od własnego projektu.
Nie kod, ale kłębek nerwów
Nie pisz nieczytelnego i nieudokumentowanego kodu. Znamy ten trik: programista pisze kod do syta, celowo go trochę mieszając, aby nikt z jego kolegów nie zrozumiał tego, co napisał - jest to rodzaj zemsty zapobiegawczej, zanim coś się stanie. Jednak narażasz na ryzyko nie tylko firmę (która płaci Ci pieniądze za Twoją pracę), ale także siebie: prawdopodobnie sam nie będziesz pamiętał, co chciałeś powiedzieć poprzez to niezamierzone zaciemnienie. Tak samo jest z nieudokumentowanym kodem: opierając się na logice nazewnictwa zmiennych i funkcji oraz dobrej pamięci, po kilku latach możesz nie pamiętać, dlaczego wybrałeś tę konkretną pętlę, metodę, wzorzec itp. Dokumentowanie kodu i jego dobrej struktury to świetna usługa dla Twoich współpracowników, pracodawcy, a przede wszystkim dla Ciebie.
Niech to będzie możliwie proste
Zadbaj o prostotę kodu, rozwiązań i projektów. Nie ma potrzeby ogradzania złożonej struktury i tworzenia bytów bez specjalnego znaczenia. Im bardziej skomplikowany jest Twój kod, tym bardziej stajesz się jego zakładnikiem - utrzymanie go i rozwijanie będzie dla Ciebie maksymalnie trudne. Oczywiście słynna zasada KISS („Keep it simple, głupi”) nie zawsze jest odpowiednia, ale została stworzona nie bez powodu: prostota i elegancja kodu są kluczem do jego udanego zastosowania i ponownego użycia.
Chroń się
Nie ignoruj bezpieczeństwa - w 2020 roku jest to dosłownie przestępstwo. Nawet jeśli Twoja firma, rozwój i Ty nie jesteście zainteresowani dla atakujących, mogą Was spotkać problemy związane z porażką jakiegoś segmentu sieci, dostawcą usług hostingowych, atakiem na centrum danych, kradzieżą haseł do poczty elektronicznej i niebezpiecznym zachowaniem pracowników, którzy mogą ukraść dane z firmy, kradnąc klientów lub kod programu całego projektu. Jeśli leży to w Twojej mocy i leży w Twojej specjalizacji, staraj się chronić projekty, nad którymi pracujesz. No cóż, sami obserwujcie bezpieczeństwo informacji, nikomu to nigdy nie przeszkadzało.
Nie pluj do studni
Nie zadzieraj z pracodawcą. Dziś komunikacja osiągnęła taki poziom, że na przykład wszyscy pracownicy HR w mieście znają się zaocznie i mogą wymieniać się wszelkimi informacjami na czatach i w zamkniętych grupach (zarówno po to, aby pomóc im w znalezieniu pracy, jak i napisać „Wasilij Iwanow, architekt systemu, zabił wszystko przed opuszczeniem kont, usunął kopie zapasowe i wyłączył sieć, odzyskiwanie trwało 3 dni. Nie zatrudniaj go. Zatem Twoje zachowanie będzie skierowane wyłącznie przeciwko Tobie - a czasami nawet przeprowadzka do innego miasta lub stolicy nie pomoże. Nawet jeśli odchodzisz z urazą, nie ma lepszej zemsty niż zostać pożytecznym i fajnym pracownikiem konkurencji :) A co najważniejsze, całkowicie bezkarnie.
Ty też nie powinieneś tego robić. Jednak, jak pokazuje doświadczenie, nie będziemy się zatrzymywać
Ogólnie rzecz biorąc, przyjaciele, czytajcie rady, ale róbcie to, co uważacie za najlepsze - w końcu prawdziwych odkryć dokonuje się wtedy, gdy wątpimy w już odkryte prawdy. Szczęśliwego Nowego Roku, niech wasze projekty odniosą sukces, niech wasza kariera będzie przyjemna, niech wasi koledzy i menedżerowie będą odpowiedni i niech wasze życie w ogóle będzie udane. Ogólnie rzecz biorąc, życzę Nowego Roku i nowego kodu!
Z miłością,
Zespół RegionSoft Developer Studio
W nowym roku będziemy nadal pracować dla Ciebie i rozwijać potężny system CRM na komputery stacjonarne oraz prosty i wygodny system pomocy technicznej i zgłoszeń .
Źródło: www.habr.com