Sytuacja kobiet w IT w 2024 roku
24.04.20204 min
Joseph Cardillo

Joseph CardilloCustomer Support Specialist / Backups AdministratorLinode

Jak programować, żeby się nie frustrować

Sprawdź, na czym polega pisanie pseudokodu, dlaczego konsola jest Twoim najlepszym przyjacielem i czemu warto zachować dystans i śmiać się z samego siebie podczas programowania.

Jak programować, żeby się nie frustrować

Najważniejsze rzeczy, których nauczyłem się o programowaniu, nie mają nic wspólnego z pisaniem kodu. Są to raczej sprawy, które zdarzają się przed i pomiędzy pisaniem kodu. Kiedy po raz pierwszy dostaję problem lub zadanie do rozwiązania, moją normalną reakcją jest kodowanie lub szukanie rozwiązań w Google. Robienie czegokolwiek innego, może wydawać się bezproduktywne. Szybko zdałem sobie jednak sprawę, że to nieprawda.

Generałowie zwykli powiadać:
„Zamiast zrobić pierwszy ruch lepiej poczekać i zobaczyć, co się stanie.
Zamiast pójść o cal do przodu, lepiej wycofać się o metr.” (Tao Te Ching, №69)


Nigdy nie walczyłem w żadnej bitwie, ale myślę, że rozumiem powyższy cytat. Pójście naprzód może się wydawać najbardziej produktywną rzeczą, jaką możesz zrobić, a wycofanie się oznacza ustąpienie wrogowi... Chociaż niekoniecznie. Podczas pisania kodu, cofnięcie się o kilka kroków pomaga lepiej zrozumieć niektóre rzeczy. Pisanie pseudokodu i myślenie o moim problemie z ołówkiem w ręku i z kartką papieru daje mi lepszy insight i przywodzi na myśl bardziej przemyślane pytania. W rzeczywistości oszczędza mi to sporo czasu na dłuższą metę.

Pisanie pseudokodu

Kiedy po raz pierwszy zachęcano nas do powyższej czynności, nie widziałem w tym wiele sensu. Może dlatego, że pracowaliśmy nad prostszymi problemami, które nie wymagały obszernego przemyślenia pewnych spraw. Jednak w miarę, jak zadania stawały się coraz bardziej skomplikowane, podejście to stało się bezcenne. Daje mi to szansę rozwiązania problemu od początku do końca.

// Mój proces pisania pseudokodu:
// 1. Wczytuję się w problem.
// 2. Piszę dłuższą formę wypowiedzi dotyczącą tego, co próbuję osiągnąć, nawet jeśli powtarza się dosłowne części pytania. Od czego zaczynam? Dokąd zmierzam? Jaką ścieżkę wybieram? Jakie ścieżki poboczne mogę wybrać po drodze? Jakich narzędzi potrzebuję? Jakiej funkcjonalności potrzebuję?
// 3. Wracam do moich notatek (od #2) i dodaję przemyślenia, aby doprecyzować proces. Co więcej, dołączam pytania, które mam do siebie (lub innych, lub Google), które prawdopodobnie zadam po drodze.
// 4. Rozpoczynam kodowanie.
// 5. Testuję każdy najmniejszy krok w konsoli.
// 6. Powtarzam krok piąty.
// 7. Powtarzam krok piąty.
// 8. Powtarzam krok piąty. [...]

Najpierw pomyśl, potem wygoogluj

Inną moją naturalną reakcją było natychmiastowe zadawanie pytań w Google. Powiedziano nam, że 80–90% (lub więcej) dnia programisty zlatuje na googlowaniu rzeczy. Dlaczego mam więc tego nie robić? Nie mogę tego w żaden sposób poświadczyć, ponieważ nie jestem jeszcze w pełni opierzonym programistą. Zdaję sobie jednak sprawę, że istnieją metody Googlowania, które są dla mnie pomocne, ale są też takie, które przynoszą efekt przeciwny do zamierzonego.

Mam wrażenie, że kiedy zwrócę się do Google'a w pierwszej kolejności, to część mojego mózgu się wyłącza. Inaczej: jeśli zwrócę się do Google, zanim zacznę myśleć, nie uczę się myśleć jak programista. O co mi chodzi: jeśli nie poświęcę czasu na napisanie pseudokodu i przemyślenie szczegółów projektu, skończę googlując w nieefektywny sposób i, w rezultacie, stracę czas.

Choć w perspektywie krótkoterminowej pisanie pseudokodu może sprawiać wrażenie znacznego cofania się, tylko po to, aby pójść o jeden krok dalej — to w rzeczywistości zaoszczędza czas w perspektywie długoterminowej. Pomaga mi to bardziej przemyśleć pytania, które zadaję w Google. Bardziej prawdopodobne jest to, że będę rozumiał, o co pytam i dlaczego o coś pytam.

console.log(“everything”)

To niezwykle ważna sprawa. Na początku nie zdawałem sobie z tego sprawy, ale console.log oszczędza również ogromną ilość czasu i energii. Daje mi to szansę przetestowania każdego pomysłu w Developer Tools Chorme'a, i sprawdzenia, czy są jakieś błędy lub bugi do rozwiązania.

Porażka jest szansą (№79)

Oto co myślę o frazie: „Porażka jest szansą”. Konsola nie wybacza. Ale z tego powodu jest to również mój najlepszy przyjaciel. Nie owija w bawełnę i mówi mi, że mój kod wygląda świetnie oraz wiele innych komplementów. Jeśli coś nie działa, konsola też mi o tym mówi. Nie chwali mnie ani nie krytykuje. Po prostu mówi tak, jak jest. Utrzymuje mnie w pokorze i sprawia, że się rozwijam.

Jeśli pseudo kod pomógł mi rozbić proces na małe kroki, konsola pomaga mi rozbić go na jeszcze mniejsze. Powiedzmy, na przykład, że jednym z moich małych kroków jest stworzenie funkcji, która zastąpi innerHTML elementu na podstawie jego identyfikatora.

Konsola daje mi możliwość sprawdzenia, czy moja składnia jest poprawna, gdy używam jQuery do sprawdzania tego identyfikatora, czy faktycznie przechwytuję innerHTML i czy wszystko jest poprawnie sformatowane po uruchomieniu funkcji. A to wszystko bez zmieniania czegokolwiek w kodzie. Konsola daje mi polec i uczyć się na własnych błędach. Pomaga mi też utrzymać rzeczy w ruchu i celować tam, gdzie szczególnie utknąłem. Pomaga mi zadawać lepsze pytania.

Miej poczucie humoru

Programowanie może być frustrujące! A ja dopiero zaczynam. Ale jeśli po drodze potrafię się śmiać, pomaga mi to rozładować napięcie, które zwykle powoduje, że nie mogę ruszyć z miejsca. Staram się pisać zabawne rzeczy w moim pseudokodzie, nawet jeśli wyśmiewam tam samego siebie, bo pomaga mi to rozładować napięcie i się uspokoić. Jeśli dopadnie mnie frustracja, humor jest lekarstwem. Pomaga mi to przełamać blokadę i wrócić do pisania kodu.

function letsConnect(yes) {
    if (yes === true) {
        console.log("linkedIn");
        console.log("Twitter");
    } else {
        console.log("thanks for reading!");
    }
}
<p>Loading...</p>