Pokonywanie powolnego rozwiązywania problemów ze względu na większą wiedzę o tym, co może pójść nie tak [zamknięte]

Martwi mnie to od jakiegoś czasu i bardzo doceniam wkład innych profesjonalistów.

Krótkie tło: zacząłem programować, gdy moi rodzice kupili mi pierwszy komputer w 1988 roku (w wieku 14 lat mam teraz 39 lat). Przeszedłem kilka innych ścieżek kariery, zanim ostatecznie zostałem profesjonalnym programistą w 1997 roku. Być może późno rozkwitłem, ale tak właśnie było. Nadal jestem zadowolony z mojego wyboru, uwielbiam programować i uważam się za dobrego w tym, co robię.

Ostatnio zauważyłem, że im więcej zdobywam doświadczenia, tym dłużej zajmuje mi ukończenie projektów lub niektórych zadań w projekcie. Nie idę jeszcze na starczą. Po prostu widziałem tak wiele różnych sposobów, w jakie rzeczy mogą pójść nie tak. A potencjalne pułapki i problemy, o których wiem i pamiętam, stają się coraz większe.

Trywialny przykład: kiedyś było „okej, napisz plik tutaj”. Teraz martwię się o uprawnienia, blokowanie, współbieżność, operacje atomowe, pośrednie / frameworki, różne systemy plików, liczbę plików w katalogu, przewidywalne nazwy plików tymczasowych, jakość losowości w moim PRNG, niedobory mocy w środku dowolnego obsługa, zrozumiały interfejs API do tego, co robię, odpowiednia dokumentacja itp. itp.

Krótko mówiąc, problemy już dawno zmieniły się z „jak to zrobić” na „jaki jest najlepszy / najbezpieczniejszy sposób”.

Wynik jest taki, że ukończenie projektu zajmuje mi więcej czasu niż nowicjusz. Moja wersja może być solidna i tak nieprzenikniona, jak wiem, jak to zrobić, ale trwa to dłużej.

Powyższy przykład „Utwórz plik” był właśnie przykładem. Rzeczywiste zadania są oczywiście bardziej złożone, ale mniej dostosowane do ogólnych pytań takich jak to. Mam nadzieję, że rozumiesz, dokąd zmierzam. Nie mam problemu z opracowaniem wydajnych algorytmów, uwielbiam matematykę, lubię złożone przedmioty, nie mam trudności z koncentracją. Myślę, że mam problem z doświadczeniem, a co za tym idzie ze strachem przed błędami (wewnętrznymi lub zewnętrznymi).

Prawie dwie godziny dziennie spędzam na czytaniu o nowych rozwiązaniach, nowych technikach, językach, platformach, zagrożeniach bezpieczeństwa i tak dalej. Problem polega na tym, że im więcej wiedzy zdobywam, tym wolniej pracuję nad realizacją projektów.

Jak sobie z tym radzisz?

Nie jesteś wolniejszy w realizacji projektów. Wcześniej myślałeś, że twoje nowicjusze zostały zrealizowane, kiedy tak naprawdę nie były. Powinieneś sprzedać tę jakość klientom.

„Ta firma może to zrobić szybciej i taniej, ale czy to naprawdę zrobione? A może polujesz na błędy przez lata?”

Poza tym musisz poznać i zaakceptować stary idiom: „Idealny jest wrogiem dobra”.

Wygląda na to, że czas dołączyć do ciemnej strony: zarządzania.

Nie sugeruję, żebyś zrezygnował z programowania i został menedżerem. Wygląda jednak na to, że całe przytoczone do tej pory doświadczenie miało charakter techniczny. W prostej operacji zapisywania pliku możesz pomyśleć o 10 różnych aspektach, których mniej dojrzały programista nigdy nie wziąłby pod uwagę. Niekoniecznie zła rzecz, ale ...

Ciemna strona dotyczy wartości bieżącej. Chodzi o dokonanie minimalnej inwestycji w celu uzyskania maksymalnego zysku (analiza kosztów i korzyści). W biznesie wszystko sprowadza się do tego, ile mnie to będzie kosztować, prawdopodobieństwo sukcesu, prawdopodobieństwo awarii, prawdopodobieństwo spektakularnej awarii i potencjalnego zysku. Zrobić matematykę; działaj odpowiednio.

Działa to równie dobrze, gdy jesteś programistą: utwórz plik tymczasowy, ignorując uprawnienia i kolizje nazw - 5 min. Zysk netto, reszta zespołu może rozpocząć pracę nad dowolnym kodem zależnym od obecności tego pliku. Czy to idealne rozwiązanie? Absolutnie nie. Czy dostaniesz 99%, 95%, może 90%? Tak, prawdopodobnie tak będzie.

Kolejne pytanie: jak oceniasz dług techniczny? Niektórzy uważają, że należy to wyeliminować. Myślę, że ci ludzie się mylą. Podobnie jak w biznesie, dług techniczny pozwala pożyczyć „gotówkę” lub „czas” w celu dostarczenia czegoś wcześniej. Co jest lepsze: Idealne rozwiązanie za 2 lata lub całkowity hack, którego klient może użyć i kupić w ciągu 4 miesięcy? Każda sytuacja jest inna, ale w niektórych sytuacjach, jeśli poczekasz 2 lata, klient już zarejestruje się w konkurencji.

Kluczem jest zarządzanie długiem technicznym w taki sam sposób, jak dobrze zarządzana firma zarządza długiem finansowym. Jeśli nie weźmiesz wystarczająco dużo, nie uzyskasz optymalnego zwrotu z inwestycji. Jeśli przyjmiesz za dużo, zainteresowanie cię zabije.

Tak więc moja rada: zacznij oceniać swoją pracę na podstawie tego, czy maksymalizujesz swoją wartość, zamiast maksymalizować dokładność. A jeśli ćwiczysz to, rozwiniesz tę samą intuicję, którą już rozwinąłeś w swojej dziedzinie techniki.

Na marginesie, ostatnio zacząłem ćwiczyć technikę pomodoro i to bardzo pomogło. Zamiast iść na styczną do stycznej, skup się w krótkich odstępach czasu, a następnie przydziel pomodoros na przyszłe prace / badania. To zdumiewające, ile razy zanotowałem notatkę, żeby zbadać jakiś temat, ale godzinę później, gdy nadszedł czas, pomyślałem sobie: „Są co najmniej 3 inne rzeczy, które mogę zrobić z dzisiejszym czasem, które są bardziej cenne”.

Miałem (prawdopodobnie) ten sam problem wiele lat temu, trwał kilka lat i go pokonałem. Być może zainteresuje Cię to, jak to osiągnąłem, nawet jeśli nie jestem pewien, czy moja droga będzie dotyczyła Ciebie.

Powinieneś także rzucić okiem: Siedem etapów wiedzy specjalistycznej w zakresie inżynierii oprogramowania Pokazuje, że produktywność jest w dużej mierze efektem ubocznym poziomu umiejętności. Możliwe, że nadal znajdujesz się w pewnym momencie pomiędzy etapem 3 a etapem 4 w technologii, której obecnie używasz (biegłość w umiejętnościach zależy od technologii, możesz opanować niektóre technologie, jednocześnie ucząc się innych).

Teraz zaczynam od świadectwa biograficznego.

Trochę kontekstu. Mam 47 lat. Zacząłem programować w wieku 12 lat 80-tych. Podczas liceum pracowałem również jako profesjonalny programista gier w niepełnym wymiarze godzin. Zasadniczo nie dostałem tyle pieniędzy, tylko tyle, żeby kupić sprzęt, ale podobało mi się to i wiele się nauczyłem. W wieku 18 lat rozpocząłem formalną naukę informatyki.

W rezultacie, kiedy skończyłem 20 lat, za każdym razem, gdy zaczynałem jakieś zadanie programistyczne, znałem wiele sposobów rozwiązania zadanych problemów i byłem bardzo świadomy wielu parametrów i pułapek pod ręką, a także wad i ograniczeń dowolnej metody.

W pewnym momencie (powiedzmy, że ma około 26 lat) napisanie jakiegokolwiek programu stało się dla mnie naprawdę trudne. Było tak wiele możliwości, że nie mogłem już wybierać między nimi. Przez kilka lat (zrób to 6) przestałem nawet programować i stałem się pisarzem wiadomości technicznych.

Niemniej jednak nigdy całkowicie nie przestałem próbować programować. I w pewnym momencie wrócił. Kluczem było dla mnie ekstremalne programowanie, a dokładniej zasada prostoty: „Napisz najprostszą rzecz, która może zadziałać”.

Zasadniczo zmusiłem się, żeby nie dbać o wydajność kodu (to była moja główna blokada, unikaj nieefektywnych projektów), ale po prostu idź najłatwiej. Zmusiłem też mnie do mniejszej dbałości o błędy i odłożyłem obsługę błędów na później, po napisaniu testów podnoszących błąd (tak naprawdę to TDD).

Tego się nauczyłem, kiedy pisałem. Kiedy nie wiem, co napisać, lub wiedziałem, że to, co piszę, było złe . Po prostu idź dalej. Właściwie napisz złe rzeczy. W końcu poprawię to później. Lub jeśli naprawdę jest tak źle, usuń go i przepisz, ale szybciej jest napisać rzeczy dwa razy, które napiszą wszystko za pierwszym razem.

Naprawdę bardzo prawdopodobne jest, że kod, który Twoim zdaniem jest dobry na początku, będzie wymagał tyle samo usprawnienia, co naprawdę zły.

Jeśli podążysz ścieżką prostoty, otrzymasz również dodatkową premię. Łatwo akceptujesz usunięcie / zmianę wstępnego projektu / kodowania. Masz bardziej elastyczny umysł.

Przyzwyczaiłem się także umieszczać tymczasowy komentarz w kodzie, wyjaśniając, czego nie robiłem teraz i zamierzałem zrobić później, gdy kod będzie funkcjonować w normalnym przypadku użycia.

Uczestniczyłem również w XP Dojo i ćwiczyłem kata kodu z innymi programistami, aby zinternalizować praktyki XP. Pomogło. Dzięki temu powyższe metody formalne stały się instynktowne. Pomogło również programowanie w parach. Praca z młodymi programistami nabiera rozpędu, ale z doświadczeniem widać także to, czego nie robią. Na przykład w moim przypadku często widzę, jak angażują się w zbyt skomplikowane projekty i znam koszmar projektowania, który może do nich doprowadzić. Tak poszło. Zrobił to. Miałem problemy.

Najważniejszym dla mnie jest utrzymanie przepływu. Bycie szybkim naprawdę udaje się utrzymać przepływ.

Teraz wróciłem jako profesjonalny programista i wierzę, że jestem lepszy i szybszy dzięki głębszemu zrozumieniu tego, co robię. Ćwicząc TDD, wciąż mogę być nieco wolniejszy niż gdy byłem młodym bykiem (i niczego nie testowałem), ale nie mam też refaktoryzacji strachu i na pewno spędzam znacznie mniej czasu na debugowaniu (prawie wcale nie ma czasu, zrób to mniej niż 10% czasu) ).

Podsumowując: Pokonałem blokadę kodu za pomocą zwinnych metod (XP), przechodząc do uproszczenia, a następnie refaktoryzacji i ćwicząc, aby zrobić to instynktownie. To zadziałało dla mnie. Nie jestem pewien, czy można go uogólnić na kogokolwiek innego.

Jeśli chodzi o poziom nabywania umiejętności, głównie nauczyłem się akceptować to, że za każdym razem, gdy zmieniam technologię (uczę się nowego języka, nowych ram itp.), Przechodzę przez etap, w którym zwalniam. Jest to normalne i ostatecznie to przezwycięży. Mogę to również zrekompensować dobrą metodologią i umiejętnościami programowania ogólnego i nie będzie to stanowić większego problemu.

Ważną częścią programowania jest zarządzanie i kontrolowanie złożoności, a dla mnie osobiście jest to jeden z najważniejszych problemów. Jeśli zostanie to zignorowane, wówczas wzrośnie częstotliwość braków lub, jak w twoim przypadku, ETA gotowego oprogramowania gwałtownie wzrośnie.

Złożonością oprogramowania można sterować i zarządzać z wielu różnych poziomów i sposobów, ale dobrą zasadą jest uzyskanie pewnej perspektywy: „Najwyższym priorytetem każdego projektu oprogramowania jest zadowolenie klienta, które jest funkcją jego oczekiwań”.

Innymi słowy, złożoność oprogramowania zależy w dużej mierze od umiejętności opanowania oczekiwań klienta.

Przyjmując ten pogląd, stają się oczywiste dwa ważne punkty:

1. oczekiwania klienta muszą być jasno określone (w dowolnej formie);
2. Oczekiwania klientów mogą być zawsze modyfikowane i odbywa się to poprzez sztukę negocjacji.

Twój przykład jest bardzo dobry: „po prostu napisz” kontra „mnóstwo innych rozważań”. Pomyśl o tym - jeśli ktoś zapisuje wyczerpujące wymagania dla obu wariantów, czy może istnieć równoważność opisanych funkcji?

Budowa F16 różni się od budowy Cessny, chociaż oba mogą latać.

Prosta odpowiedź brzmi: zaakceptuj.

We wszystkich systemach trzeba dokonać kompromisu między niezawodnością, solidnością, bezpieczeństwem, szybkością, kosztami sprzętu, kosztami rozwoju, czasem wprowadzenia produktu na rynek, jak to nazywasz. Nie zawsze zgadzasz się ze sposobem, w jaki klient dokonuje tych kompromisów, ale to nie ty podejmujesz te decyzje. Możesz jedynie podać przemyślaną opinię. Rozwój oprogramowania obejmuje całą gamę, od „mojej osobistej strony internetowej” po „uruchomienie reaktora jądrowego”, a kod musi być odpowiednio napisany. Jeśli awaria oznacza „przeładuj moją osobistą stronę”, to kogo to naprawdę obchodzi, jeśli tak się stanie? Ale jeśli awaria oznacza „Czarnobyl”, wtedy preferujesz solidny kod, jeśli cokolwiek jest nieco przypadkowe dla moich upodobań.

Niektórzy klienci chętnie przyjmą kod poziomu „Proof of Concept” i uruchomią go w swoich aktywnych systemach, a często mają dobrze przyzwyczajonych administratorów systemów. IME ich systemy są zwykle niedostępne przez około godzinę w środku nocy, podczas gdy następuje kilka zaplanowanych restartów. Ale podjęli decyzję biznesową, że właśnie tak chcą rzucić. Idealnie, ponieważ ich pole jest tak szybkie, że wysokiej jakości kod nigdy nie byłby gotowy, ale często dlatego, że nie widzą wartości (jeśli system „po prostu działa”, nigdy go nie zauważa, dlatego system nie reprezentuje wartości dla pieniądze). Jeśli zbytnio ci to przeszkadza, staraj się unikać tych klientów.

Bycie na bieżąco to czas, który wszyscy musimy spędzić, a przynajmniej powinniśmy spędzić. Czasami sprawi to, że będziesz pracować, innym razem po prostu utrzyma twój umysł w dobrej formie. Tak czy inaczej, spróbuj się tym cieszyć.

Wygląda na to, że Twoje umiejętności byłyby bardzo przydatne do tworzenia bardzo wysokiej jakości systemów o kluczowym znaczeniu, takich jak aplikacje związane z finansami / handlem, nadawanie, lotnictwo, obrona ...

Błędy w tego rodzaju aplikacjach są bardzo kosztowne i zatrudniają ludzi, którzy myślą podobnie jak ty, ponieważ możesz zająć się wszystkimi przypadkami.

Prawda jest taka, że ​​nowoczesne systemy stają się coraz bardziej złożone. Komputer jest teraz podobny do tej gry „Jenga”, w której wszystkie te elementy polegają na wielu innych. Wyciągnij niewłaściwy kawałek, a pojawi się błąd, wyciągnij prawidłowy / konieczny kawałek, a nadal może pojawić się błąd. Im bardziej złożony system, tym więcej czasu poświęcisz na zastanowienie się nad sposobami uczynienia kodu bardziej niezawodnym i, miejmy nadzieję, również bezpieczniejszym. Szybkość byłaby dobra, ale myślę, że prędkość ostatnio zajmuje dużo miejsca, gdy słyszysz w wiadomościach, że włamano się do firmy „XYZ” i skradziono 6 milionów numerów kart kredytowych klientów.

Twoi klienci mogą nie chcieć słyszeć, że ich program musi być bezpieczny, solidny itp. Ale możesz im powiedzieć, że ich samochód nie potrzebuje pasów bezpieczeństwa i poduszek powietrznych, a ich dom nie potrzebuje zamków i drzwi ... bo kto chce usłyszeć wszystko że?

Jeśli zastanawiasz się nad tym, podchodzisz do rzeczy we właściwy sposób, z tym wyjątkiem, że musisz wybrać strategię, która wydaje się „konkretna” i po prostu iść z nią.

Wygląda na to, że jesteś świadomy swojej skłonności do myślenia o wszystkim, co może pójść nie tak.

Doświadczeni Ostrożni Programiści często uczą się podążać za mantrą YAGNI, nie będziesz jej potrzebować, gdy będą próbować powrócić do szczupłego, zwinnego i produktywnego przepływu pracy po tym, jak zbyt dusią się w chwastach trybu awaryjnego-analizy-zniknął-amok.

Jeśli jednak piszesz coś w dziedzinie, w której poziom opieki jest nie mniejszy niż wymaga tego profesjonalizm, powinieneś zdawać sobie sprawę, że twoją „prędkość”, twoją „produktywność”, w ujęciu netto, można zmierzyć na podstawie tego, ile dobrego ( lub wyrządzić szkodę), które wyrządzasz swojej firmie, klientom oraz pakietowi oprogramowania lub rodzinie produktów, którą budujesz lub konserwujesz.

Pamiętaj by:

• Uwzględnij całkowity koszt utrzymania, całkowity koszt posiadania oraz całkowity koszt wdrożenia i utrzymania rozwiązań, gdy rozważasz zmiany w swoim podejściu. Szybsze działanie i popełnianie większej liczby błędów może, ale nie musi, poprawić sytuację.

• Jeśli pracujesz w dobrej firmie, prawdopodobnie możesz porozmawiać o tym we własnym zespole i ze swoim przełożonym, bez ograniczania kariery. Jeśli nie możesz, teraz jest dobry moment, aby się tego dowiedzieć i znaleźć nową pracę.

Jedyne, co widzę, to: „Stajesz się coraz bardziej cenny”.

W miarę zdobywania doświadczenia dowiadujesz się o rzeczach, których powinieneś unikać, a to czyni cię lepszym od innych.

Zauważyłbyś jedną rzecz, że Twój kod byłby teraz bezpieczniejszy i łatwiejszy w utrzymaniu.

• Jedyne, co musisz zrobić, to wyjaśnić swojemu klientowi, dlaczego zajęło to trochę czasu i jak byłoby dla niego przydatne.
• Musisz pokazać im głębię swojej wiedzy.
• Musisz powiedzieć im, dlaczego to zrobiłeś, co zrobiłeś i jak to będzie miało znaczenie dla nich i ich interesów.

Moją sugestią byłoby skoncentrowanie się na tej części.

w razie wątpliwości domyślnie źle cytuje Knutha ...

„Przedwczesna optymalizacja jest źródłem wszelkiego zła”.

Oto, co sugeruję, ponieważ wydaje się, że masz od czasu do czasu problem ...

Co naprawdę dla mnie działa ...

1. Napisz testy jednostkowe, jakby cały kod został wykonany.
   
2. udokumentuj interfejs.
   
3. wdrożyć interfejs.

co naprawdę zrobiłeś:

1. przejrzyj wymagania dotyczące warstw modelu
2. naprawdę ustaliłem podział pracy, które obiekty są za co odpowiedzialne
3. zabierz się do pracy w środowisku, w którym możesz faktycznie przejść przez działający kod, dzięki czemu rzeczy są o wiele szybsze i dokładniejsze ...

opieraj się również na stwierdzeniach we wczesnym etapie rozwoju ... a następnie dowiedz się, jakie środki zaradcze należy wdrożyć, a nie napiszesz kodu, który jest nieosiągalny lub trudny do przetestowania.

Myślę, że powinieneś trzymać się standardów kodowania, ale upewnij się, że masz bezpośredni kontakt ze swoimi klientami. Wielu klientów nie wie, co potrzeba / kosztuje zbudowanie dobrego oprogramowania. Edukowanie ich jest częścią pracy profesjonalnego programisty.

Bez względu na to, czy jesteś zwinny, czy wodospad, klient otrzymuje jakąś zgodę na to, czego oczekuje od aplikacji. Zbyt wielu programistów (OK, może więcej sprzedawców) jest winnych worków z piaskiem . „Nie powiedzieli, że chcą dobrze zabezpieczonej witryny”. W większości przypadków dzieje się tak dlatego, że ich nie pytano. „Nie masz nic przeciwko, jeśli Twoja witryna e-commerce zostanie zhakowana?” Oczywiście, że ich to obchodzi i dlaczego miałbyś to zbudować, aby ktoś mógł przeniknąć do bezpieczeństwa? Musisz ich edukować.

Upewnij się tylko, że robisz tylko to, za co klient ci płaci. Częścią twojego serwisu jest twoje doświadczenie. Klienci oczekują, że znasz pułapki, bez konieczności pytania. To od nich zależy spełnienie wymagań. Możesz przekazać klientom, którzy chcą czegoś taniego.

Pomyśl o praktycznych konsekwencjach błędu w porównaniu do wszystkich innych problemów, które wymagają rozwiązania.

Rozważ następujące konsekwencje utworzenia źle napisanego fragmentu kodu:

1. Cała baza danych jest zrzucana co drugi miesiąc. 48 godzin przestoju podczas przywracania kopii zapasowych.
2. Dane klientów zostają powiązane. Zamówienia o wartości 200 USD są wysyłane do niewłaściwych klientów miesięcznie.
3. Raz w tygodniu zamówienie utknie w złym stanie. Zamów statki, ale magazyn, aby za każdym razem dzwonić do działu pomocy technicznej.
4. Raz na około dwa tygodnie aplikacja ulega awarii, a użytkownik musi ponownie wprowadzić dane o wartości 2 minut.
5. Raz w miesiącu aplikacja zawiesza się przy uruchomieniu. Użytkownik musi zabić proces i zacząć od nowa.

Pierwszy jest oczywiście nie do przyjęcia. # 2 - # 5 może, ale nie musi, w zależności od charakteru firmy. # 2 - # 5 należy ocenić w kontekście innych problemów, przed którymi stoi firma.

Idealnie # 2 - # 5 nigdy by się nie wydarzyło. W prawdziwym życiu, przy sprzecznych priorytetach, osoby podpisujące twoją wypłatę mogą chcieć, abyś pracował nad innymi rzeczami, zamiast pisać idealny kod, który nigdy nie ma problemu. Nie będą pod wrażeniem, jeśli numer 5 zostanie naprawiony kosztem nie naprawienia poważniejszego błędu w innym programie.

Rozwiązaniem jest utworzenie kolekcji bibliotek z często używanymi funkcjami, które można ponownie wykorzystać w różnych projektach. Na przykład mam bibliotekę StringFunctions.dll .NET, która wykonuje takie czynności, jak kodowanie, szyfrowanie, deszyfrowanie, ocena wyrażeń regularnych itp. W ten sposób nie muszę ciągle przepisywać rzeczy, które się nie zmieniają.

Posiadanie opakowania do zadań tworzenia plików również ma sens. Twoja biblioteka może udostępniać metodę o nazwie GetFile (), która wykonuje wszystkie sprawdzenia za Ciebie i zwraca wartość null lub plik (lub cokolwiek, co uznasz za przydatne).

Myślę, że musisz nauczyć się decydować, ile trzeba zrobić dla danego projektu. Niektóre projekty mogą być trywialne i naprawdę nie musisz poświęcać tyle czasu na ich doskonalenie. Nie wszystko będzie wymagało solidnego szyfrowania ani skalowania do milionów użytkowników.

Napisanie programu, który można dobrze skalować dla ponad miliona użytkowników, będzie wymagało czasu i doświadczenia, które masz teraz, ale jeśli wiesz, że Twoja aplikacja nie będzie używana przez więcej niż 1000 użytkowników, nie ma sensu wydawać wszystkich tym razem doskonaląc go.

Myślę, że jest to ważny etap w twojej karierze programistycznej i teraz musisz przejść do następnego poziomu, który dotyczy dojrzałości, a nie programowania. Musisz być w stanie poprawnie zdecydować, ile czasu i kodu powinno wystarczyć na konkretny projekt.

I podobnie jak wszystko inne, możesz to osiągnąć również poprzez praktykę. Spróbuj więc zdecydować o tym, zanim zaczniesz projekt, czasem nawet, gdy już nad nim pracujesz, z doświadczeniem, które również przejdziesz. Na początku może być kilka trafień i chybień, ale z czasem je udoskonalisz (podejmowanie decyzji, a nie kodowanie).

@Zilk, nie jestem świetnym programistą i programuję od 1998 roku. Nawet teraz mam do czynienia z tym problemem. Ale zdałem sobie sprawę, że ostatecznie jakość ma znaczenie. Jeśli dzisiaj umrę, ktoś powinien być w stanie odebrać to, co robię teraz, z miejsca, w którym opuściłem. Takie powinny być standardy programowania (Universal).

Teraz przeniosłem się z programisty na architekta. Przejście do zarządzania zmienia linię. Jeśli chcesz kontynuować swoją pasję, możesz zostać Architektem.

Początkowo jako architekt techniczny -> architekt rozwiązań -> architekt przedsiębiorstw -> główny architekt i tak dalej.

Jako architekt poprowadzisz ludzi do sukcesu. Ludzie tacy jak ty, którzy programują od dziesięcioleci, te lata doświadczenia, które można wykorzystać, aby poprowadzić innych.

Jak ptak wyżej leci więcej lądów, które widzi, więc twoje doświadczenie.

Pozwól, że powiem ci, że programowanie poprawnej implementacji jest ważne niż szybsze programowanie niewłaściwej implementacji. Niedawno jeden z moich juniorów zaprogramował coś złego i kosztowało to bank dużo pieniędzy. Oczywiście, że dostarczyliśmy na czas wcześniej, ale to nie miało sensu! Czy powierzono mi rolę przewodnika, mimo że ten sam junior zakodowałby, że problem nie miałby miejsca. Podaję ten przykład, aby podkreślić, że dobre wskazówki są również ważne. Niektórzy nazywają tę pracę konsultacją.

Inną opcją jest: przestań pisać kod, zamiast tego sprzedaj swoją wiedzę specjalistyczną w wykrywaniu problemów z wyprzedzeniem.

Innymi słowy, zostań konsultantem .

Wiele organizacji chętnie płaci drogie dolary (jeśli nie najwyższe dolary), aby ktoś dostrzegł problemy, zanim spędził miesiące na tworzeniu kodu, który sprawia problemy. Powszechnie wiadomo, że naprawienie błędu w projekcie jest o rząd wielkości tańsze / łatwiejsze niż naprawienie go po jego zakodowaniu, przetestowaniu i wdrożeniu.

Nie będziesz pisać tyle kodu i prawdopodobnie możesz tego przegapić, ale wydaje się, że rzeczywiste wiersze kodu nie są twoją podstawową siłą, ale wiedzą, które wiersze kodu należy napisać - a które nie.

Skoncentruj się na swoich mocnych stronach.
(cóż, jeśli to lubisz ...)

Moja najlepsza rekomendacja dla Ciebie to: bloki konstrukcyjne.

Stwórz blok budowania plików, któremu zawsze możesz zaufać, stwórz go dla swojego API, przestań marnować czas na pisanie tego samego w kółko. Pomyśl o każdym problemie raz i napraw go raz na zawsze.

Nikt tego nie dogoni, z pewnością nie nowicjusz, który spędza 80% swojego czasu na debugowaniu kodu, który zawodzi w przypadkach, których nie rozumie.

Przede wszystkim nie naprawiaj problemów, które nie mogą się zdarzyć, takich jak nieprawidłowe uprawnienia.

Jeśli uprawnienia są niepoprawne, coś jest już nie tak i powinieneś to naprawić, zamiast uczynić program kuloodpornym.

W pewnym momencie musisz po prostu nie strzelać sobie w stopę, zamiast zawsze sprawdzać, czy zrobiłeś to, czy nie.

Zamiast poświęcać czas na dokumentację, poświęć czas na samodokumentowanie kodu i jak najkrótsze. Zamień wszystkie te funkcje duplikatów. Zmniejsz bibliotekę, zmieniaj nazwy elementów z precyzją.

Nie bądź dla siebie zbyt surowy. Pracujesz w zawodzie o coraz większej złożoności, który wymaga więcej ludzkiej inteligencji, wiedzy i doświadczenia niż kiedykolwiek wcześniej.

Moc przetwarzania komputera spowalnia - być może wkrótce utknie w martwym punkcie - co prowadzi do konieczności wprowadzenia układów wielordzeniowych, układów numerycznych zasilanych GPU, równoległości itp. Istnieje tylko tyle tranzystorów, które można umieścić na układzie.

Dlatego wielkie postępy obecnie i w przyszłości będą pochodzić od programistów - zaawansowane algorytmy i bardziej wydajny kod.

Jeśli spojrzysz na GTA 4 i GTA 5, różnice są zdumiewające. Ale oba działają na tym samym sprzęcie. Jest to wynik bardzo inteligentnej i zaawansowanej praktyki programowania, która po prostu nie była wymagana ani dostępna 10 lat temu.

Może to również oznaczać, że doświadczeni programiści mogą stać się bardziej wartościowi w przyszłości - podobnie jak inne zawody, takie jak inżynieria, w których najwyższe zarobki zwykle pojawiają się na późnym etapie kariery.

Tak jak ty, zacząłem programować w wieku 14 lat, także kiedy dostałem swój pierwszy komputer (chociaż w tym momencie studiowałem przez kilka miesięcy). Jednak mam teraz „tylko” 33 lata. :-)

Moja sugestia jest taka, że ​​przy opracowywaniu czegoś bierzesz każdy z tych zmartwień (uprawnienia do plików, liczbę plików w katalogu itp.), A następnie wykorzystujesz całe swoje ogromne doświadczenie, aby odpowiedzieć na kilka pytań na ten temat, w tym duchu:

• Ile czasu zajmie prawidłowe rozwiązanie tego problemu w kodzie?
• Jeśli nie poradzisz sobie z tym właściwie, to jak prawdopodobne jest, że to coś cię ugryzie później?
• Jeśli cię gryzie, jakie są konsekwencje?

Uzbrojony w te odpowiedzi tak doświadczony facet nie będzie miał problemów z podjęciem mądrej decyzji. ;-)

Obowiązkiem „weteranów” takich jak ty jest wymyślenie tego rodzaju wymagań, a to obejmuje zarówno identyfikację tego, co może pójść nie tak, jak i określenie potencjalnych problemów, na które należy zwrócić uwagę.

Znajomość wszystkich możliwych kryteriów podczas tworzenia aplikacji jest najważniejsza w tworzeniu wysokiej jakości produktu. Dobrze sobie z tym radzisz. Jedno, co możesz zrobić, to: możesz podzielić wymaganie na poziom jakości, a następnie zmapować poziom z podanym terminem. W ten sposób możesz łatwo dotrzymać terminu projektu.

Według słów Edsgera Dijsktry: „Jeśli debugowanie jest procesem usuwania błędów oprogramowania, wówczas programowanie musi być procesem ich wprowadzania”. Robisz tylko mniej tego drugiego, więc musisz zrobić mniej tego pierwszego. To tylko kwestia nauki spędzania czasu na odpowiednim kodowaniu. Nadal jestem stosunkowo młodym programistą (czytam 20ish) i staram się raz kodować coś całkowicie poprawnie. Godzina planowania i 10 minut kodowania jest znacznie lepsza niż 10 minut planowania, godzina kodowania i trzy debugowania.