Kategoria: Uncategorized

Wiele osób, które nie miały wcześniej styczności z programowaniem myślą, że jest ono trudne. Częściowo wynika to z przekonania, że ma ono duży związek z matematyką, trochę z nieczytelnego wyglądu niektórych języków programowania, a odrobinę też z tego, że niektórzy ludzie z branży lubią pozować na magików, którzy zaklinają cyfrowe węże.

Prawdę powiedziawszy podstawy programowania są łatwe.

Element pierwszy: zmienne

Koncepcja zmiennej jest prosta, jak konstrukcja cepa. Mamy coś co ma nazwę i wartość oraz typ. Na przykład:

nazwa: ilość pieniędzy na koncie
wartość: 7000
typ: liczba

nazwa: imię mojego dziecka
wartość: Maciek
typ: litery

Element drugi: warunki

Warunki są koncepcją równie prostą, jak zmienne. W zależności od czegoś robimy coś albo coś innego. Banał.

Przykład:

Jeśli 
       data urodzin mojego dziecka jest równa dacie dzisiaj

To
       będę robić tort

Element trzeci: pętle

Pętle wykonują coś wiele razy. Proste? Proste.

Przykład:

Dopóki flaszka jest pełna
       nalej do kieliszka a potem wypij

Język

Oczywiście na końcu trzeba to wszystko zapisać w jakimś języku programowania. Kiedy ludzie myślą o nauce języka zwykle są przerażeni. Przychodzi im na myśl od razu ta wredna germanistka z podstawówki, rodzajniki, odmiana i czasy. I tysiące, nieskończone tysiące słówek do nauczenia.

Języki programowania są łatwe. Gramatyki prawie nie ma, a słów jest kilka.

Naprawdę.

Definicje zmiennych?

liczba: number;
napis: string;

Warunki?

ilośćCiastek = 5;
 if ( ilośćCiastek > 0 ) {
        jedzCiastka();
 }

Pętle?

while ( flaszka.czyJestPelna() ) {
        człowiek.pij()
 }

Oczywiście to są podstawy. Oczywiście jest dużo gorzej. Jednak nikt mi nie wmówi, że te podstawy są jakieś strasznie skomplikowane, że programowanie to matematyka i gramatyka niemiecka albo jeszcze gorzej.

Programowanie jest łatwe. I fajne!

Na przestrzeni dziejów, językom przytrafiają się rozmaite role do odegrania. Łacina, przez wpływ Kościoła, stała się międzynarodowym językiem średniowiecza. Chiński, będąc pierwszym przed wieloma innymi w Azji, który zyskuje formę pisemną, wpływa na Japonię, która do dziś w dużej mierze korzysta z chińskich znaków. Niemcy, rozwijając kulturę miejską szybciej od nas, pierwsi wymyślają pewne słowa, które trafiają później do polszczyzny – na przykład ratusz (w staroniemieckim Rathus).

Dominacja technologiczna krajów anglosaskich sprawiła, że zarówno w komunikacji morskiej, jak i lotniczej językiem oficjalnym stał się angielski. To samo wydarzyło się z technologią informacyjną. Wszystkie omal języki programowania składają się z słów kluczowych wyrażonych w języku Shakespeare’a. Komendy, które wpisujemy w konsoli to również słowa angielskie. Chcemy tego, czy nie – językiem branży IT jest język angielski.

Nie ma w tym nic odkrywczego. Co drugie ogłoszenie o pracę dla programisty zawiera na liście wymagań znajomość angielskiego. Jest to wymaganie wyrastające z potrzeby współpracy z zagranicznymi klientami albo członkami rozproszonych zespołów wielonarodowych. W wielu krajowych firmach nie wymaga się angielskiego. I choć z pozoru ma to sens, to konsekwencje mogą być poważne.

Każdy chyba, kto studiował, pisał podobne do poniższych koszmarki:

class Zwierze {
  oddychaj() {
    console.log('Sap sap')
  }
}

class Kot extends Zwierze {
  miaucz() {
    console.log('Miau miau');
  }
}

class Pies extends Zwierze {
  szczekaj() {
    console.log('Hau hau');
  }
}

let pies = new Pies();
let kot = new Kot();
pies.szczekaj();
pies.oddychaj();;
kot.oddychaj();
kot.miaucz();

Mieszanie języków jest powszechnie uznawane za nieeleganckie i nie spotkałem się jeszcze z takim kodem w żadnej firmie, w której pracowałem, czy to polskiej, czy zagranicznej.

W pewnym minimalnym stopniu każdy programista angielski zna. Bez niego ciężko utrzymać się w branży, w której cała niemalże dokumentacja techniczna jest w nim wyrażona. Subtelny problem, który niełatwo na pierwszy rzut oka zauważyć polega na głębokości znajomości języka.

Nie da się pisać czystego kodu nie znając dobrze angielskiego.

Jak wiemy kod powinien być czytelny. Nazwy zmiennych adekwatne, metody krótkie, zwięzłe, klasy odpowiedzialne za to, co ich nazwy sugerują. Niestety, jeśli programista nie czuje się z językiem angielskim naprawdę komfortowo, to dość szybko dopadnie go problem z nazwaniem nawet nieprzesadnie skomplikowanych rzeczy w kodzie.

Wszyscy znamy urocze pomyłki w gastronomii:

Żeby być jednak uczciwym, nie jesteśmy w IT wolni od grzechu. Podczas telekonferencji ze współpracownikami z zagranicy mój kolega powiedział swego czasu it’s in the first akapit – zapominając, że przecież akapit w języku angielskim nie istnieje, bo jest to paragraph. Choć równie urocze pomyłki zdarzają się ze strony klientów. Pewna Włoszka kazała mi, kilka lat temu, pewną rzecz semplificare zamiast simplify. 

Nie po to zostałem programistą, żeby rozmawiać z ludźmi – mawiają niektórzy. Programiści lubią czasem pozować na niezrozumiałych, heraklitejskich mędrców, stojących ponad masami nieświadomych użytkowników. Będąc wśród swoich, przynajmniej niektórzy z nas, pieszczą swoje ego spoglądając na niedoświadczonych kolegów z góry. Internet pełen jest zresztą memów ukazujących starszych programistów w blasku i chwale, juniorów zaś, razem z praktykantami jako niedoświadczonych  półgłówkow.

Kiedy pokazujemy juniorowi starą technologię

Źródło: https://thecodinglove.com/when-we-show-an-old-technology-to-a-junior-developer

Między nami, deweloperami toczy się walka, walka o dominację. Ile to razy widziałem już skracanie kodu przy użyciu mało znanych elementów języka, by pokazać, że jest się większym ekspertem. Zmniejszanie wycen, by udowodnić innym, że jesteśmy bardziej wydajni. Chodzenie na rekrutacje dla sportu. Delegowanie juniorom zadań nie prostych, a żmudnych.

W jednej firmie, w której pracowałem na stanowisku młodszego programisty pracował ze mną kolega. Nazwijmy go Przemek. Kolega Przemek również był młodszym programistą. Pewnego dnia jednak, z racji dłuższego o bodajże rok stażu pracy, awansowano go. Dwa tygodnie po tym wydarzeniu, pracując nad kodem produktu zapytałem na open-space o, nieznany mi wówczas, typ decimal w C#. Przemek oderwał się od komputera i roześmiał.

– Nie wiesz co to decimal? Ty juniorze!

Usłyszawszy to, znad swojego z kolei ekranu, podniósł się starszy programista i roześmiał gromko.

– Przemek, przecież sam mnie o to pytałeś miesiąc temu!

Tymczasem to współpraca i synergia, a nie ego i znajomość kruczków technologicznych budują zgrane, sprawne, produktywne zespoły, które tworzą piękne, zgrabne, wydajne rozwiązania cieszące klientów. Po latach zrozumiałem jedno…

Najważniejszą cechą dobrego programisty jest empatia.       

Empatia to umiejętność wczucia się w inną osobę. Jeśli deweloper potrafi zobaczyć świat oczami innych, będzie w stanie zaprojektować system łatwy i wygodny w użyciu dla zwykłych ludzi. Jeśli potrafi wyjść poza swoją perspektywę, będzie umiał pisać kod źródłowy, który będzie zrozumiały dla innych programistów, przez co modyfikowanie produktu będzie tańsze i sprawniejsze. Mając tę cenną umiejętność będzie też umiał rozmawiać z projektantami aplikacji, z tzw. biznesem.

Jako programiści zawsze powinniśmy próbować doskonalić naszą empatię. Możliwie często pytać samych siebie – czy będzie to zrozumiałe dla innych, którzy nie wiedzą tego co ja? Czy nie będzie to zbyt skomplikowane w użyciu? Czy używam dostatecznie prostego języka? Czy nie komplikuję czegoś nadmiernie?

Rekrutując programistów warto zwrócić uwagę na ich osobowość. Osoby zarozumiałe, tyraniczne, mało empatyczne, nawet jeśli genialne na płaszczyźnie technicznej, mogą więcej problemów stworzyć niż rozwiązać… Nie skupiajmy się jedynie na IQ i znajomości technologii. W większości projektów wyzwania techniczne nie są tak monumentalne, jak mogłyby się wydawać.

Same technologie zresztą – przeminą. To co pozostanie, to kod źródłowy. Napisany przez ludzi, którzy wyobrażali sobie, że ktoś, kiedyś po nich przyjdzie i będzie musiał go zrozumieć, nie znając tak jak oni technologii i uwarunkowań albo przez tych, których ich następcy nie interesowali. Po tych drugich nikt nie będzie chciał pracować, a praca będzie powolna. Nie chcemy tego…