Zawartość
- 01. Kodowanie już nie przeszkadza
- Szerokość i głębokość
- 02. Duże zastrzeżenie
- 03. Co mówi internet
- Zrozum medium
- 04. Rzeczy z których budujemy
- 05. Devops
- Zrozum stos
- Tajemnicza praca
- Poręczne narzędzia
- 06. Dev to naprawi ... może
- Debugowanie
- 07. Czego chcą użytkownicy
- Konkurencyjny rynek
- 08. Rysowanie i pisanie
- 09. Baw się dobrze
- 10. Bądź ostry
- Lubiłem to? Przeczytaj to!
Programiści muszą być kimś więcej niż tylko podstawowymi robotami generującymi kod. Oczekujemy więcej od naszego cyfrowego życia i to ci faceci je tworzą, więc co powinni wiedzieć najlepsi programiści? Oto rzeczy, których brakuje zbyt wielu programistom. To nie jest wyczerpujące, ale to właśnie te cechy sprawiają, że rozsądny programista staje się niesamowitym programistą.
Ale to nie jest jedna rzecz, a szczególnie nigdy nie jest to możliwość analizowania XML lub optymalizacji kodu. To zaskakujący zbiór umiejętności, których nie uczy się w książkach o pisaniu kodu. To coś ekstra.
Po co się tak upuszczać? Ponieważ rozwój ma znaczenie, ale deweloperzy zbyt często są przenoszeni do innego świata, nie zawsze od ich twórców. To nigdy nie działa. Rozwój - wszystko techniczne - zawsze rozwija się, gdy ci, którzy wiedzą, jak rozumieją więcej niż tylko kod.
01. Kodowanie już nie przeszkadza
Żyjemy w świecie, w którym kodowanie staje się mniej imponujące. Wszyscy budują witryny, niektóre z nich kodują, ale nie musisz. Nie tylko nerdowiec może tworzyć witryny, aplikacje i funkcje.
Odkąd pojawił się Internet i ludzie mogli się uczyć, było wielu programistów-samouków. Ale nawet absolwenci są zagrożeni. Dostaję CV z osobami z dyplomami informatyki, kursami sztucznej inteligencji, różnymi mediami i kodowaniem na swoim koncie, ale wciąż czegoś brakuje. Czasami wiele brakuje.
Nie jestem pierwszym, który to powiedziałem. „Kodowanie już tego nie przerywa” to tytuł rozdziału 3 z Namiętny programista, który wraz z książkami takimi jak Myślenie pragmatyczne i uczenie się zachęcać programistów do doskonalenia się poza kodem; stać się odpowiedzialnymi i całkowicie ludzkimi członkami zespołu.
Szerokość i głębokość
Programiści muszą być lepsi pod dwoma względami: szerokością i głębią. Muszą zrozumieć zakres interakcji międzyludzkich w swoim zespole oraz rzeczy, które tworzą. Muszą zrozumieć głębię systemu, z którym pracują, aż do systemu operacyjnego.
Nie tylko programiści powinni czytać te rzeczy. Jeśli pracujesz z programistami, myślę, że powinieneś oczekiwać od nich więcej. Niech naszkicują, o czym mówią. Poproś ich, aby wyjaśnili za pomocą zdjęć, przedmiotów i (to działa) wycinków ludzi dokładnie, jak system będzie wyglądał dla ludzi, którzy go używają.
02. Duże zastrzeżenie
Mam zamiar mówić negatywnie o programistach, ale myślę, że mi wolno, bo nim jestem. Również dlatego, że przynajmniej jedna rzecz, o której tu mówię, odnosi się do wielu programistów, których spotykam. Chociaż ich praca jest świetna i znają swój kod, czasy są konkurencyjne. Musisz mieć przewagę, a to jest:
- być bardziej technicznym
i
- być dużo bardziej ludzki
03. Co mówi internet
Szukanie w Google „podstawowych umiejętności tworzenia stron internetowych” przyniesie oczekiwane rezultaty. Znajomość frameworka, przeglądarka X, CSS i JS. Znajdują się w nich frameworki, które powinieneś znać, platformy, dla których musisz pisać, i nowe trendy, na które powinieneś zwrócić uwagę.
To są nasze media. To na nich budujemy, ale to nie one zapewniają sukcesowi projektu. Deweloper może zrozumieć każdy szczegół systemu, opowiedzieć Ci o każdej funkcji API i nowej technologii CSS, ale nadal tworzy coś bezużytecznego.
Zrozum medium
Programiści, jak wszyscy, muszą rozumieć swoje medium - ale muszą także rozumieć odbiorców, czy to użytkowników, zespół czy innych programistów. Muszą zrozumieć, jak ich medium pasuje do świata (innymi słowy do środowiska produkcyjnego) i jaki ma wpływ (jak ludzie go używają).
Widziałem to jako osobę „szeroką i głęboką”. Szerokie, ponieważ musisz rozumieć świat jako człowiek pracujący z innymi ludźmi. Głębokie, ponieważ potrzebujesz gruntownej wiedzy technicznej poniżej poziomu swojej części projektu. Ci programiści znacznie przyspieszają Twój projekt i zmieniają jego tempo, bez czego nietechniczny personel grzęźnie w żmudnych szczegółach, które wylewają się z zespołu technicznego.
04. Rzeczy z których budujemy
Niedawno spisałem listę wszystkiego, czego używamy do tworzenia witryn, zarządzania hostingiem i załatwiania spraw, aby osoby dołączające mogły mieć ściągawkę technologii, których mogliby się nauczyć w ciągu pierwszych kilku tygodni. Odebraliśmy to jako przeczytane, że ludzie znają te rzeczy, więc aby dać nowym rekrutom szybki start, wymienialiśmy wszystko, czego używamy każdego dnia.
Spodziewałem się pół tuzina technologii, ale ostatecznie otrzymałem znacznie więcej. Ta lista - „czego używamy” - obejmuje zwykłe systemy CMS, języki programowania i technologie przeglądarek, ale także zestaw narzędzi, których zespół nawet sobie nie przypominał. To wszystko była pamięć mięśniowa. Wpisując „git”, „phing”, „thor” w wierszu poleceń, nawet nie myśleliśmy, że ktoś może tego nie robić.
Narzędzia do budowania; CI; git do kontroli wersji było czymś oczywistym, ale patrząc wstecz na CV, prawie się nie pojawiały. Pojawiały się modne (i czy to cyniczne, że według mnie niektóre agencje je dodają ?!), ale często bez konkretnego doświadczenia.
Narzędzia te są ważne dla przyspieszenia rozwoju projektów, więc upewnij się, że masz znacznie bogatszy zestaw narzędzi niż Twój język, CMS i kilka frameworków. Potrzebujesz wdrożenia, testowania, CI, silnej kontroli wersji (w zespołach - nie samodzielnie) i musisz zrozumieć podstawowe pojęcia z nich, a nie tylko kilka samouczków.
05. Devops
Te dodatkowe narzędzia i sztuczki idealnie pasują do tego, co ludzie nazywają „devopsami”. Devops walczy z dwoma tradycyjnymi silosami: produkcją, która zapewnia ciągłość działania, i rozwojem, który tworzy nowe rzeczy (i często je zatrzymuje). Dzięki silosom powstają dwa obozy, które nie darzą się wzajemnie sympatią.
Programiści bez wiedzy produkcyjnej częściej tworzą kod, który nie nadaje się do produkcji, używając konfiguracji lub funkcji, które nie znajdują się jeszcze na stosie produkcyjnym. Ponieważ nie zdają sobie sprawy z problemów środowiska produkcyjnego, kodują, aby ukończyć tę funkcję, a nie wdrożyć ją w środowisku produkcyjnym.
Te drobne szczegóły mogą powodować bolesne opóźnienia, zaostrzone przez trend wysyłania zarządzania serwerem za granicę.
Zrozum stos
Devops to ogromne pole samo w sobie, obejmujące ciągłe wdrażanie i dużą automatyzację. To obszerne podsumowanie, ale kluczową rzeczą, którą programiści muszą zrozumieć, jest stos, na którym pracują. Nie wystarczy delegować tego na administratora serwera, musisz zrozumieć wpływ platformy na Twój kod.
Jeśli pracujesz na Railsach, przeczytaj kod Railsów i dowiedz się, jak Ruby jest wykonywany przez Apache. Jeśli pracujesz w Javie, zapoznaj się z opcjami konfiguracyjnymi. Jeśli używasz Perla, dowiedz się, jak zainstalować moduły Perla i je skonfigurować.
Tajemnicza praca
Lista „czego używamy” zawiera wiele takich rzeczy, a dobrzy programiści robią to szybko, aby zrozumieć, jak odbywa się ta cała tajemnicza praca. A kiedy już to zrobią, wdrożenia przebiegają szybciej, praca przebiega sprawniej i wszyscy są po prostu szczęśliwsi.
Ciągłe wdrażanie i powiązane praktyki DevOps stają się tak standardowe, że każdy deweloper lub firma, która tego nie robi, może zostać wyprzedzona. Ktoś inny zacznie to robić, a wtedy będzie szybszy od ciebie.
Poręczne narzędzia
Wyszukiwanie w Google „devops” daje wyobrażenie o narzędziach, których używają ci faceci. Nie chodzi o PHP i MySQL ani o Railsy. Chodzi o dostarczanie oprogramowania i utrzymywanie ryzykownych fragmentów projektów bez ryzyka. Koncentrują się na wdrażaniu, automatyzacji i utrzymywaniu jak najszybszego działania potoku od dewelopera do środowiska produkcyjnego.
Przekonasz się, że ten styl rozwoju zapewnia programistom, którzy lepiej współpracują ze sobą oraz z innymi działami i firmami. Jeśli pracują z interfejsem API innej firmy, zrozumieją problemy, które mogą pojawić się po drugiej stronie. Współpracując z administratorami serwerów, rozumieją, czego potrzebują do zainstalowania, i wiedzą, w jaki sposób ich oprogramowanie umieszcza się na serwerach produkcyjnych. Odwrotna sytuacja może być bolesna ...
06. Dev to naprawi ... może
Poszukiwanie „podstawowych umiejętności programistów internetowych” przynosi miłą odpowiedź od Michaela Greera (CTO The Onion) w serwisie Quora:
- Lenistwo: odmawia zrobienia czegokolwiek dwa razy: pisze dla niego skrypt lub algorytm.
- Tchórzostwo: myśli o testowaniu, martwi się o obciążenie i wpływ kodu
- Lekkomyślność: nieustannie próbuje nowych rzeczy, wprowadza pomysły tego samego dnia
Tchórzostwo to dobry sposób wyrażenia „dbałości o szczegóły”. Debugowanie i testowanie to 99 procent życia programisty, o którym nikt nie wspominał, kiedy trafiał na W3Schools lub zaczynał kurs informatyki 101.
Możliwość naprawiania aplikacji wymaga doskonałych umiejętności rozwiązywania problemów, ale nie tylko debugowania kodu. Czasami rozwiązaniem dla użytkowników, którzy nie mogą pobrać faktur, jest umożliwienie wydrukowania strony zamiast spędzenia dnia na generowaniu plików PDF. Czasami łącze może zastąpić tydzień programowania, ale to eleganckie rozwiązanie nie przydarzy się, jeśli programiści rozwiązują problemy wyłącznie poprzez pisanie wielu wierszy kodu.
Testowanie to wspaniała ślepota dla wielu programistów, pomimo wielu dostępnych narzędzi. Użyj testów jednostkowych, selenu, testów obciążenia i narzędzi do profilowania, takich jak xhprof. Analiza na podstawie takich rzeczy, jak New Relic, aby utrzymać niewielki ślad Twojej aplikacji. I weź pod uwagę to wszystko jako część pracy programisty: to twój kod, upewnij się, że wiesz, że działa zgodnie z przeznaczeniem, a nie miej nadzieję, że tak.
Debugowanie
Debugowanie jest również drażliwym punktem. Nie jak używać debuggera, ale jak debugować problem - więc dodałbym do listy Michaela Greera:
- Niecierpliwość: agresywnie ignoruje nieistotne informacje, aby znaleźć i rozwiązać prawdziwy problem
To podstawa wszystkich technik debugowania. Ignorowanie nieistotnych i znajdowanie znaczenia w odpowiednich. Niestety, wielu ma skłonność do niewolniczego wbijania nieistotnych godzin lub dni, naprawiając problem, próbując 10 razy tego samego.
Jest wiele książek (niestety nie ta, którą przekazałem wydawcy, którego nie wymienię) na temat debugowania i każdy programista powinien przeczytać je wszystkie. Naprawdę świetny programista może debugować problemy w systemie bez zobaczenia linii kodu.
07. Czego chcą użytkownicy
Zrozum, co próbują zrobić ludzie wokół ciebie. Ciesz się kodem - uwielbiaj sztukę perfekcyjnego wcięcia plików CSS lub optymalizowania aplikacji railsowej - ale pamiętaj, że to wszystko ma jakiś cel.
Programiści muszą rozumieć biznes, operacje i procesy biznesowe, ponieważ ich personel pomaga je obsługiwać. Twórcy posiadający tę wiedzę są w stanie tworzyć oprogramowanie i aplikacje, które pomagają użytkownikom, ale często wydają się one niezwykle produktywne. Może to być spowodowane szybkim pisaniem na klawiaturze lub niesamowitą znajomością stosu, ale jest bardziej prawdopodobne, że wiedzą, czego chcą użytkownicy.
Konkurencyjny rynek
Wracając do mojego pierwotnego punktu, że rozwój jest coraz łatwiejszy, a rynek dla świetnych programistów jest bardziej konkurencyjny, każdy programista, który jest w stanie zrozumieć wymagania biznesowe i wnieść coś doskonałego do ich spełnienia, będzie miał przewagę. Zrozumieć rynek, klientów i dlaczego ludzie rozstają się z pieniędzmi, wszystko to pomaga.
Zapoznaj się z danymi i dowiedz się, jak będą się zmieniać w czasie. Zdaniem programisty powinni oni dopasować nowe technologie do wyzwań, które masz dzisiaj lub które nadejdą. W ten sposób, kiedy proponujesz dyrektorowi zarządzającemu lub klientowi wymyślny nowy pomysł, będzie on oparty na tym, czego naprawdę chcą klienci, a Ty dostaniesz na to budżet / czas. (Dla kontrastu, najgorsze jest to, że programiści sprzedają swoją nową ulubioną technologię jako rozwiązanie wszystkich naszych bolączek).
Programiści mają dużą kontrolę - czy muszą wiedzieć, co każde pole w bazie danych oznacza dla użytkownika końcowego? Jeśli zmienimy dane, co zobaczą użytkownicy? Czy istnieje lepszy sposób pomagania użytkownikom? Zbyt często opinia administratorów baz danych jest taka, że świat jest raczej złym odzwierciedleniem ich bazy danych, a nie ich bazą, która jest złą reprezentacją świata rzeczywistego. Świat jest chaotyczny i zaskakująco pełen skrajnych przypadków. Skorzystajcie z tego, administratorzy DB.
08. Rysowanie i pisanie
Rysowanie to najbardziej bezpośredni sposób na przekazanie, jak będą wyglądały rzeczy. Deweloperzy muszą umieć narysować swoje pomysły na tablicy, papierze i podstawkach do piwa.
Programiści muszą mieć możliwość tworzenia prototypów na papierze, drukowania zrzutów ekranu i bazgrołów na nich tylko po to, aby przekazać swoje zamiary. Nie ufaj deweloperowi, który kiwa głową, mówi, że rozumie i otwiera swojego redaktora.
Niedrogie niepowodzenie: najlepsze kodowanie zaczyna się od rysowania jako szybkiego prototypu. Częściej przegrywaj i upewnij się, że wszyscy deweloperzy wokół ciebie robią to samo, ponieważ masz większe szanse na odniesienie sukcesu w ten sposób.
09. Baw się dobrze
A co, jeśli musisz spędzić 10 godzin na rozwiązywaniu problemu, przenosząc łącze? Ciesz się tym - nawet jeśli jest to tylko wyzwanie związane z pracą.
Najgorsze nastawienie programistów (lub kogokolwiek) to apatia wobec tego, co zespół próbuje osiągnąć. Niestety jest to powszechne, ponieważ programiści postrzegają siebie jako osoby spoza tego, co osiąga zespół. (Namiętny programista stawia pytanie „o ile fajniej byłoby ci sprawić swoją pracę?” - spróbuj).
I bądź gotowy, aby pokazać swoją pracę, ponieważ odwrotność tego jest następująca: nie rozszerzaj po wypróbowaniu kilku samouczków na temat Rubiego do „Doświadczenia Rubiego”!
Tworzenie stron internetowych i aplikacji to wciąż młody zawód, ale umiejętności, których potrzebują naprawdę wielcy programiści, stale się poszerzają. Każdy powinien oczekiwać więcej od programistów, ponieważ im szybciej wszyscy wyjdziemy z nieprzyjemnego zaplecza i zaangażujemy się w proces twórczy, tym lepsze będą wyniki.
10. Bądź ostry
Aby doprowadzić to do ładnej dziesiątki, dodam jeszcze jedną rzecz. Bądź ostry. Znajdź konkurencję. Najgorsze jest to, co dzieje się w izolacji.
„Zawsze bądź najgorszym facetem w każdym zespole, w którym jesteś”.
Najgorsi - naprawdę bardzo źli - programiści, programiści, projektanci uczą się swoich rzeczy i spoczywają na laurach. Bez rozrusznika zbyt łatwo jest zwolnić, a bez oglądania konkurencji staje się nawykiem postrzegania siebie powyżej średniej.
Więc bądź najgorszy, jaki możesz, znajdując lepsze. Dołączaj do projektów poza pracą, udzielaj się i szukaj opinii i krytyki, ponieważ im więcej krytyki otrzymasz, tym mniej ludzi da Ci w przyszłości. Kiedy zgadujesz, czego chcą lepiej niż oni, wtedy jesteś programistą ninja, którego wszyscy chcą.
Dan Frost jest dyrektorem technicznym firmy 3EV oferującej pełen zakres usług, która jest oficjalnym partnerem AWS. Od siedmiu lat zajmuje się tworzeniem CMS i aplikacji internetowych.
Lubiłem to? Przeczytaj to!
- Jak zbudować aplikację
- Najlepsze darmowe czcionki internetowe dla projektantów
- Dowiedz się, co dalej z rzeczywistością rozszerzoną
