Znane przysłowie mówi, że czym skorupka za młodu nasiąknie... Data science dopiero zaczynam, ale pracuję z danymi już kilkanaście lat. W praktyce poznałem jak ważne są dobre nawyki:

  • Używanie właściwych narzędzi do właściwych celów. Przygotowanie środowiska pracy i koncepcji. Chyba nie wymaga komentarza - przygotuj się dobrze do analiz. Przemyśl metody, sprawdź wiele możliwości. Zastanów się z jakich danych chcesz skorzystać. Może ten projekt lepiej wykonam w Python niż R? Jak poradzę sobie z 60GB plikiem? Które dane nie są mi potrzebne? Jaki chcę output? Może lepiej gdy od razu pomyślę o wykresach - przyda mi się do raportu i prezentacji. Zrób raz, ale kompleksowo, to nie będziesz wracał do tematu piętnaście razy.
  • Zdrowa równowaga pomiędzy: "zrobię wszystko sam od podstaw" a "wezmę gotowca". Nie zawsze wszystko trzeba robić samodzielnie. Np. odwracanie macierzy jest doskonale oprogramowane w R a do tego wbudowana funkcja zadziała znacznie szybciej niż kod R (łatwo sprawdzić dodając dwa wektory "wbudowanym" operatorem sumy i pętlą). Przesada w drugą stronę oznacza, że bierzemy tylko to co jest gotowe. Szybko, tanio i wygodnie :) Niestety, w takim przypadku nie wiemy czy działa i w jaki sposób działa. Najprostszy przykład to mediana ze zbioru: 0, 1, 3, 7. Najczęściej wynik będzie średnią z 1 i 3, ale nie zawsze. A 10 percentyl z takich 4 obserwacji? Okazuje się, że jest kilka możliwości, jeśli zbytnio zaufasz gotowcom - otrzymasz niezrozumiały (nieoczekiwany) wynik.
  • Czystość kodu. To jest ważne, gdy nie jesteśmy jedynymi czytelnikami/autorami kodu. Nawet jeśli kod jest tylko dla nas, bałagan w kodzie spowoduje, że za rok nie będziemy rozumieli własnej twórczości. Dlatego zachowujmy kod czysty: (1) Nazwy zmiennych (a także klas, funkcji, plików...) odpowiadają temu co zawiera dana zmienna (czyli Page_adress, Sender_name zamiast x1, x2), (2) Używaj komentarzy! Rób to w trakcie pisania kodu, kiedy jeszcze doskonale wiesz po co tak napisałeś/aś, czemu służy dane zmienna. W komentarzach można też napisać o tym co jest jeszcze wymaga poprawy, uzupełnienia (np. "TODO: Dodaj sprawdzenie czy wektor jest niepusty."), (3) Nie komplikuj kodu. Potrójne list comprehension wygląda super mądrze, ale może w tym przypadku pętla (albo częściowo pętla) byłaby lepsza? Przydatne są konwencje kodowania a w dużych projektach wręcz wzorce projektowe.
  • Dokumentowanie własnej pracy. Czyli coś więcej niż komentarze (które robi się głównie dla siebie lub własnego teamu). Jeśli jesteś programistą w dużej firmie to zapewne będziesz musiał robić dokumentację na bieżąco (i będziesz z tego rozliczany!). A jeśli nikt Ci nie każe tego robić? Moim zdaniem staraj się robić krótkie notatki z tego co robisz. Może będziesz w przyszłości robił podobny projekt? Albo napiszesz o tym artykuł naukowy czy wpis na blogu? Prędzej czy później przekażesz komuś nie tylko wyniki ale i "wnętrze projektu" - wtedy będzie trzeba conieco opisać, ale po czasie zapomnisz większość swoich genialnych pomysłów. Poszerzasz team? Zamiast tłumaczyć wszystko od zera, możesz dać opis tego co już jest i na tej podstawie wdrażać kolegę/koleżankę do pracy. Trzeba zrobić instrukcję obsługi? Super, mam już większość w swoich notatkach. Chcesz pochwalić się tym już jest zrobione albo dostać wynagrodzenie za ukończony etap projektu? Nie ma problemu, bo zapisywałeś sobie na bieżąco co się działo :) Docenisz to szczególnie kiedy będziesz "z drugiej strony". Zdarza się, że dostajemy dane z fajnym opisem albo przejmujemy projekt z dokumentacją. W bardziej pesymistycznej (realistycznej?) opcji możesz dostać: opis zbyt lakoniczny żeby cokolwiek zrozumieć albo dokumentację w zupełnie nie znanym Ci języku.

Oczywiście to są tylko zajawki, a każdy z tych punktów można rozwinąć, ale tak naprawdę najlepiej spróbować zastosować w praktyce (spróbuj, zobaczy że oszczędzi to trochę czasu i nerwów).
Wreszcie na koniec dwie krótkie refleksje. Same obliczenia to tylko 10% pracy. Większość czasu zajmie Ci zrozumienie danych, wstępna obróbka (usunięcie braków danych, filtracja błędów technicznych - w miejscu gdzie oczekujemy liczby znajduje się tekst albo w bazie brakuje pewnych informacji, weryfikacja logiczna danych - obejrzyj dane, popatrz czy nie ma tam np. ujemnych zarobków albo czy średnia liczba dzieci w gospodarstwie domowym nie odbiega za bardzo od tego co wiemy z ogólnodostępnych danych demograficznych - jeśli tak to dlaczego?, ograniczenie zbioru). W przypadku data science dochodzą jeszcze techniczne wyzwania związane z bardzo dużymi zbiorami danych. Być może będzie trzeba zainstalować jakiś serwer bazodanowy albo zastosować jakiś szybszy algorytm? No, a na koniec trzeba to jeszcze opisać i zrobić prezentację.Teoria też jest ważna. Wszyscy mówią teraz, że studia mają uczyć praktyki, oczekujemy praktycznych rad czy wręcz gotowców. Uwierzcie mi, jestem praktykiem. Ale z czystego lenistwa warto zapoznać się z teorią - przykłady już wkrótce na blogu.