Wśród wydawców oprogramowania pojawiło się dziwne zjawisko. Wydaje się, że ludzie mają tendencję do odwracania swojego rozumienia tego, co czyni produkt wysokiej jakości lepszym, a przynajmniej jest to prawdą, jeśli chodzi o tych, którzy zajmują się marketingiem. Brzmi to mniej więcej tak: „Ich produkt ma milion linii kodu, ale nasz ma dwa miliony, więc nasz produkt musi być lepszy”.
Nikt nie wie, skąd wzięło się myślenie „więcej znaczy więcej”, kiedy wszyscy tak ciężko pracowali, aby stworzyć filozofię „mniej znaczy więcej”. Prawdopodobnie zaczęło się od dziennikarstwa konsumenckiego, ponieważ wielu pisarzy stara się zaimponować widzom, cytując wielkie liczby. W większości przypadków to działa — ten mały pendrive mieści 200 terabajtów danych, a procesor może przetworzyć 48 miliardów instrukcji na sekundę — a autorzy nie zawsze są na tyle bystrzy technologicznie, aby zrozumieć, że to samo nie dotyczy kodu źródłowego.
Ale wydajność w kodowaniu nie polega tylko na tworzeniu ścisłych algorytmów. Chodzi także o możliwość ograniczenia ilości odpadów. Oznacza to marnotrawstwo w postaci ilości czasu spędzonego na rozwiązywaniu problemów, marnotrawstwo w postaci zużycia zbyt wielu zasobów komputera, a nawet marnotrawstwo w postaci liczby pudełek po pizzy ułożonych w biurze do końca tygodnia. Idealnie byłoby, gdybyś ograniczył te wszystkie rzeczy.
W tym artykule przyjrzymy się więc temu, co możesz zrobić, aby poprawić wydajność i zwiększyć produktywność.
1. Zbuduj sprzyjające środowisko pracy
Każdy programista pracuje w wyjątkowych okolicznościach, a nasi czytelnicy to bardzo zróżnicowana grupa, więc niektórym z Was łatwiej będzie wdrożyć te sugestie niż innym.
Jeśli jesteś freelancerem, gratuluję, bo jesteś już panem własnego środowiska pracy. Oczywiście to się zmieni, kiedy pojedziesz do klienta i będziesz musiał pracować na miejscu, ale nadal jest to przyjemna pozycja, jeśli możesz odnieść sukces.
Jeśli jesteś menedżerem zespołu programistów, te sugestie mogą również pomóc w zapewnieniu maksymalnej wydajności Twojego zespołu. Lub jeśli jesteś pracownikiem zespołu programistów, możesz zasugerować niektóre z tych pomysłów swojemu menedżerowi lub przynajmniej wysłać mu link do tej strony i mieć nadzieję, że wszystko będzie dobrze.
Rozważ umożliwienie członkom zespołu pracy zdalnej
Programowanie jest po części ćwiczeniem logiki, ale jeszcze bardziej twórczym wyzwaniem. Najlepsi programiści mogą w równym stopniu zaangażować obie półkule mózgu do każdego zadania. Nauka od dawna potwierdza, że kreatywni ludzie najlepiej pracują w nocy i wszyscy tego doświadczyliśmy. Dlaczego więc większość menedżerów upiera się przy tradycyjnej rutynie od 9 do 5?
Właściwie znamy już odpowiedź na to pytanie. Częściowo chodzi o kontrolę, a częściowo o uczynienie rzeczy wygodniejszymi z biznesowego punktu widzenia (lub przynajmniej z punktu widzenia zarządzania). Jednak to naleganie na rutynę i lokalizację szkodzi wydajności i produktywności zespołu.
Musisz zdać sobie sprawę, że Twoi programiści prawdopodobnie nie spali całą noc, wypróbowując najnowszą grę, a może poszli na imprezę lub po prostu musieli spotkać się z rodziną. Oznacza to, że kiedy w poniedziałek rano przyjdą do pracy, nie tylko nie osiągną maksymalnego poziomu produktywności, ale są już wyczerpani energią i potwornie zmęczeni.
Zapewnienie pracownikom wyboru, kiedy i gdzie pracują, to doskonały sposób na poprawę produktywności i morale. Dopóki wykonują swoją pracę i osiągają doskonałe wyniki jakościowe, nie powinieneś przejmować się tym, kiedy, gdzie i jak to osiągną.
Wyjątkiem jest sytuacja, gdy potrzebna jest ścisła współpraca, ale tak naprawdę większość programistów radzi sobie lepiej, gdy pozostawia się je samemu, a potrzeba ścisłej współpracy jest rzadka. Opcja przyjścia do biura powinna nadal istnieć, ale nie ma realistycznego powodu, dla którego miałaby być ona wymagana, chyba że pracujesz nad ściśle tajnymi projektami wojskowymi.
Jako freelancer możesz również zauważyć, że kluczową kwestią jest to, że jeśli większość swojej pracy związanej z kodowaniem wykonasz w nocy, prawdopodobnie zrobisz więcej. Późną nocą jest mniej rozpraszających rzeczy, jest ciszej, a Ty czujesz się bardziej kreatywny.
Unikaj muzyki
Wszyscy widzieliśmy te szalone stereotypy filmowe, w których jakiś super-grungy überhacker zakłada słuchawki i gra w rytm death metalu, bez wysiłku wyświetlając całe ekrany kodu, nawet nie zatrzymując się, by oddychać. I wszyscy, którzy naprawdę kodujemy w prawdziwym świecie, wiemy, jak absurdalny jest ten obraz.
Jeśli jednak słuchasz muzyki podczas pracy, zachowaj ostrożność. Całkiem łatwo jest myśleć o muzyce zamiast o pracy, a niektóre rodzaje muzyki mogą mieć działanie usypiające. Kiedy idziesz na trening na siłowni, odpowiedni rodzaj muzyki może zainspirować Cię do wykonania kilku dodatkowych powtórzeń. Ale nikomu nie udało się dotąd stworzyć muzyki, która zainspiruje Cię do odnalezienia linii z brakującym średnikiem lub dokonania właściwego wyboru pomiędzy użyciem pętli for lub while. Najbliżej tego wszystkiego byliśmy w przypadku Electric Dreams.
Staraj się zachować porządek
Bałagan może być dziwnie pocieszający, ale może też Cię spowalniać. Możesz łatwo stracić 20 minut na szukaniu czegoś, co zaginęło w bałaganie, a potem zapomnieć, dlaczego w ogóle tego chciałeś.
Zatem pomimo wszystkich niedogodności, jakie to powoduje, dlaczego jesteśmy – przynajmniej niektórzy z nas – tak uzależnieni od bałaganu? Ekspert organizacyjny i autorka, Julie Morgenstern, twierdzi, że dzieje się tak dlatego, że te elementy łączą nas z naszą przeszłością i odgrywają rolę w definiowaniu naszej tożsamości. Marcus Geduld, nauczyciel i reżyser teatralny mieszkający w Nowym Jorku, sugeruje, że dzieje się tak dlatego, że bałagan jest lepszy od „sterylnego” środowiska i porównuje chaos bałaganu do affirmwolność i kreatywność.
Nie ma jednak wątpliwości, że ograniczenie bałaganu pomoże uniknąć rozproszenia uwagi i dezorganizacji. Jest to zatem cel godny osiągnięcia. Zdecydowanie trzymaj w pobliżu kilka świętych przedmiotów, dzięki którym poczujesz się lepiej i mniej zestresowany, ale nie przesadzaj. Posprzątanie jest jedną z najtrudniejszych rzeczy dla większości ludzi i nie dotyczy to tylko naszych problemów fizycznych desktopwymagają uporządkowania, ale często dotyczy to naszego komputera desktopteż. Jeśli naprawdę masz z tym problem, możesz spróbować użyć minimalistycznego DTE, takiego jak Fluxbox, który tak naprawdę nie pozwala na bałagan.
Ale w środku całego tego sprzątania nie przesadzaj. Istnieje wiele dobrych badań naukowych sugerujących, że odrobina chaosu w otoczeniu może faktycznie sprzyjać kreatywności. Jednym z najczęściej cytowanych fragmentów badań na ten temat jest wpis do czasopisma w Psychological Science autorstwa Vohsa, Reddena i Rahinela dla Uniwersytetu w Minnesocie zatytułowany Porządek fizyczny wytwarza zdrowe wybory, hojność i konwencjonalność, podczas gdy nieporządek wytwarza kreatywność. Prawdopodobnie powodem, dla którego tak trzymają się dziennikarze tej gazety, jest to, że jasno stwierdza, że: „…uczestnicy przebywający w nieuporządkowanym pokoju byli bardziej kreatywni niż uczestnicy w uporządkowanym pokoju”.
Dużo mniej popularne są poglądy odmienne, jak np Zaburzenie środowiska prowadzi do niepowodzenia samoregulacji (Chaye i Zhu, 2014), opublikowane w czasopiśmie Journal of Consumer Research. Badanie to wykazało, że zdolność wykonywania zadań przez osoby pracujące w nieuporządkowanym środowisku była ograniczona.
Więc gdzie cię to prowadzi? Czy warto pracować w chaosie czy sterylności? Odpowiedzią wydaje się być znalezienie równowagi tam, gdzie jest wystarczająco chaotycznie, aby zapewnić ci inspirację, ale nie na tyle, aby się rozproszyć lub mieć problemy ze znalezieniem rzeczy.
Zostaw za sobą trochę miejsca na uporządkowanie myśli
Dobrze jest mieć dużo miejsca na spacery, kiedy się zastanawiasz. Wielu najlepszych admirałów i generałów w historii było znanych z tego, że dużo czasu spędzali krążąc po pokładzie, planując strategie bojowe.
Nie tylko walczący mężczyźni stosują tę praktykę. Wielu mnichów buddyjskich również opowiada się za „medytacją chodzącą” i wierzy, że pomaga ona zachować jasność umysłu. Ilekroć masz do rozwiązania szczególnie zawiły problem programistyczny, pomocne może okazać się rozciągnięcie nóg podczas medytacyjnego spaceru po pokładzie. Oczywiście tutaj znowu brak bałaganu pomoże ci to zrobić bez konieczności lądowania w szpitalu.
Jako szef podchodź ostrożnie do krytyki wysiłków twórczych
Nie ma nic złego w konstruktywnej krytyce, ale musisz wybrać odpowiedni moment i podejść do niej we właściwy sposób, w przeciwnym razie może to przynieść odwrotny skutek i sprawić, że Twój personel będzie mniej produktywny w przyszłości. Zamiast inspirować ich i zapewniać wgląd, możesz w rzeczywistości sprawić, że będą bali się podejmować ryzyko, co jest dobrym sposobem na zabicie kreatywności. Marieke Roskes, w Ograniczenia, które pomagają lub utrudniają twórczość: podejście motywacyjne, zapewnia ramy radzenia sobie z motywacją kreatywnych pracowników, a w szczególności także tego, jak unikać ich niezamierzonej demotywacji (Zarządzanie kreatywnością i innowacjami, tom 24, Iss 2, 2015).
2. Ustal dobrą SOP
Istnieje wiele chwytliwych trendów w zarządzaniu przedsiębiorstwem i procedurach programowania, które w teorii brzmią o wiele rozsądniej, niż okazują się w praktyce. To, czy dane podejście będzie dla Ciebie skuteczne, czy nie, zależy od Twojego celu i tego, co osobiście uważasz za udany wynik.
Jednym z przykładów metodologii, którą firma, dla której pracowałem, wypróbowała i równie szybko porzuciła, jest programowanie w parach (nie mylić z programowaniem PEAR). Choć niektórzy naprawdę podziwiają tę metodologię pracy i chwalą jej miejsce w paradygmacie zwinnego programowania, my odkryliśmy, że jest ona strasznie nieefektywna. Na początek wymagało dwóch programistów na każdą stację roboczą, więc płaciłeś dwa razy więcej za mniej rzeczywistej pracy programistycznej. Odkryliśmy również, że praca w ten sposób była znacznie wolniejsza ze względu na częste zatrzymywanie/uruchamianie i tendencję do niepotrzebnego dialogu.
Zaletą programowania w parach było to, że skutkowało bardziej naturalną i rygorystyczną dokumentacją. Umożliwiło to także łatwiejsze wykrywanie błędów i zgłaszanie sugestii dotyczących udoskonalenia algorytmu. Jednocześnie jednak te same zalety stwarzały również problemy, ponieważ czasami poprawki i dostosowania nie były tak naprawdę konieczne.
Innym ryzykiem związanym z tym podejściem jest to, że można uzyskać efekt zidentyfikowany przez Roskesa, w przypadku którego programiści mogą wahać się przed wypróbowaniem różnych rozwiązań, ponieważ nie chcą, aby je poprawiano. Możesz zauważyć konflikty osobowości, gdy jeden programista jest bardzo pedantyczny i tradycyjny, a drugi jest bardziej kreatywny i spontaniczny.
Programiści często stwierdzają, że wolą programowanie w parach. Możliwe, że dzieje się tak dlatego, że lubią interakcje społeczne, jakie im to zapewnia, ale nie przyczynia się to w żaden sposób do wydajności produkcji, z wyjątkiem być może wzmocnienia morale.
Musisz więc ustalić, co faktycznie sprawdza się w przypadku programistów, a co nie. Jeśli chodzi o rzeczy, które nie działają, lepiej je wyrzucić, nawet jeśli są bardzo modną praktyką. Wszystko, co pomaga zespołowi w szybkim robieniu postępów, jest dobrą rzeczą. Jeśli jednak zostaną obciążeni metodologią, która nie pasuje do ich stylu, ostatecznie doprowadzi to do problemów.
3. Zachęcaj do szczegółowej dokumentacji
Chociaż może się wydawać, że gadatliwość zwiększy nieefektywność, niewielka ilość czasu potrzebna na podanie większej ilości szczegółów i precyzji w komentarzach może zaoszczędzić wielu kłopotów w trakcie realizacji projektu lub poddawania go rewizjom.
4. Zrezygnuj z niepotrzebnej dokumentacji
Dobrze napisany kod często jest samodokumentujący. Jeśli na podstawie nadanej nazwy jest całkowicie oczywiste, co funkcja robi (co prawie zawsze powinno mieć miejsce), wówczas dodawanie dodatkowego opisu jest zbędne. To samo dotyczy nazewnictwa zmiennych i zwracanych wartości. Z nazwy powinno jasno wynikać, czym się zajmują, a w przypadkach, gdy nie jest to możliwe, warto zamieścić ich opis w komentarzach.
5. Biała przestrzeń jest Twoim przyjacielem
Właściwe użycie białych znaków w kodzie jest cenne, ponieważ ułatwia czytanie, przeglądanie i zrozumienie kodu. Idzie to w parze z dobrym dokumentowaniem i pisaniem samodokumentującego się kodu. Każdy doświadczony programista – a może nawet nieprogramista – powinien mieć możliwość pobrania kopii kodu źródłowego i natychmiastowego zrozumienia celu każdej funkcji i sposobu jej działania. W idealnym przypadku ktoś powinien być w stanie nauczyć się programowania jedynie poprzez studiowanie dobrze napisanego kodu.
6. Wolisz prostotę od złożoności
Im bardziej skomplikowany kod utworzysz, tym trudniej będzie go rozwikłać. Jak na ironię, dotyczy to skrótów programistycznych, takich jak używanie skróconych warunków warunkowych zamiast zapisywania ich w całości. Oszczędza to czas na pisaniu, ale mniej doświadczony programista, który przyjdzie później, aby przejrzeć Twój kod, może nie zrozumieć Twoich intencji.
7. Testuj wyczerpująco
Kod należy testować stopniowo i często. Przed wdrożeniem czegokolwiek powinieneś przeprowadzić jak najwięcej wewnętrznych testów, nawet jeśli Twoje pierwsze wydanie zostanie oznaczone jako Alpha.
8. Użyj kontroli wersji
Trzeba być szalonym, żeby nie używać kontroli wersji w dużym projekcie. Bez tego nie jesteś chroniony przed własnymi drobnymi błędami, a także bardzo łatwo innemu członkowi zespołu przypadkowo (lub celowo) sabotować Twój kod, nadpisując go czymś, co Ci się nie spodoba.
Biorąc pod uwagę te osiem kluczowych sugestii, będziesz w stanie opracować własną strategię wydobywania największej wydajności dla siebie i wszystkich członków zespołu, z którymi współpracujesz. Niekoniecznie musisz stosować je wszystkie, a niektóre z nich mogą nawet nie być dla Ciebie praktyczne, ale jakakolwiek ich kombinacja prawdopodobnie sprawi, że praca będzie wykonana przy mniejszym wysiłku. Bardziej produktywny przepływ pracy zwróci się z czasem, nawet jeśli będzie to ograniczać stres i zapewniać więcej czasu dla siebie. To cel, nad którym warto pracować.
Komentarze Odpowiedzi 0