Jak dokopać Unii Europejskiej?

Któtka odpowiedź: nie da się. Długa: należy minimalizować podatki płacone reżimowi unijnemu. UE stara się nam dokopać na każdym kroku poprzez różnorodne podatki. VAT, akcyza, podatek dochodowy, płaca minimalna to tylko kilka najbardziej powszechnych i zarazem najbardziej dotkliwych podatków.

Piszę o minimalizacji, choć zdarzają się sytuacje, gdzie niektóre podatki można całkowicie wyeliminować. Mówię tutaj o kupowaniu przedmiotów z ebay.com wysyłanych spoza UE. Osobiście próbowałem Stany oraz Hong-Kong. Opisuję tutaj sytuację gdy zamiawiamy przesyłkę do Irladnii, nie wiem jak to wygląda w Polsce. Otóż prawo irlandzkie mówi, że przesyłki spoza UE o wartości do 22€ nie podlegają opodatkowaniu cłem, ani VATem. Pamiętać należy, że ta kwota 22€ zawiera również koszty przesyłki, zatem jeśli przedmiot kosztuje 15€, a przesyłka 8€ to niestety przekraczamy kwotę nieopodatkowaną o 1€ i musimy zapłacić od całej wartości czyli 23€ VAT plus opłatę pobieraną przez pocztę. Wydaje mi się, że wynosi 5€, ale mogę się mylić ponieważ ostatni raz płaciłem kilka lat temu. Jeśli przekroczymy kwotę 22€ to płacimy VAT, cło dopiero od kwoty ~150€ (nie pamiętam dokładnie). Czasem zdaża się, że nawet po opłaceniu VATu będzie nam się opłacało kupić przedmiot spoza UE. Kolejna sprawa to przeliczanie kursu walut, należy użyć oficjalnego kursu walut Banku Centralnego Irlandii.

Jeszcze jedna sprawa, nie liczyłbym zbytnio na uprzejmość sprzedawców, którzy zaniżają wartość przedmiotu, nie wkładają paragonu do paczki itp. To nie ma większego znaczenia, mnie osobiście otworzyli paczkę z Hong-Kongu pomimo tego, że wartość zadeklarowana była niższa niż rzeczywista. W jaki sposób weryfikują faktyczną wartość? Proszą nas abyśmy im na emaila wysłali linka do aukcji lub Paypala...

Jeśli chodzi o czas oczekiwania na przesyłkę to jest on dość zróżnicowany. Stany, zwykle około tygodnia-dwóch. Hong-Kong, do kilku tygodni, z tym że tak było w przypadku gdy paczkę mi otworzyli. Gdy kupowałem przedmioty do 22€ to raz zdażyło mi się czekać tylko 5 dni roboczych!

Optymalna wielkość teamu

Aktualnie pracuję w teamie 3 osobowym. Jako osoba z największym doświadczeniem pełnię rolę lidera. Rozdzielam zadania oraz podejmuje kluczowe decyzje odnośnie architektury. Muszę przyznać, że to najlepszy team w jakim udało mi się pracować. Nie dlatego, że moi koledzy są tak świetnymi programistami, wręcz przeciwnie, dlatego, że decydujące słowo mam ja.

Od pewnego czasu nie mogę już patrzeć na niechlujstwo młodych programistów (i nie tylko!). Traktują oni pisanie kodu jak wyuczoną czynność, którą wykonujemy podświadomie, bez zastanawiania się. Niesie to niestety za sobą opłakane konsekwencje. Kodowanie to nie jest czynność taka jak jazda na rowerze czy picie herbaty. Jeśli ktoś przejechał 1000 kilometrów na rowerze czy wypił 1000 herbat, można powiedzieć, że w pełni opanował te czynności. W przypadku kodu, napisanie tysięcy linii nie gwarantuje, że programista potrafi kodować. Być może potrafi szybko wklepywać kod do pamięci komputera, ale nie koniecznie oznacza to, że jest dobrym programistą. Dla mnie kodowanie zaczyna się znacznie wcześniej niż etap pisania, rozpoczyna się w momencie otrzymania wymagania. Etap poprzedzający pisanie kodu jest znacznie ważniejszy, jest decydujący. Ustalenie takich wydawałoby się prostych rzeczy jak odpowiednie miejsce dla nowego kodu jest kluczowe. Może kiedyś napiszę o tym więcej, a teraz wrócę do głównego tematu tego wpisu. Jaka jest dla mnie optymalna wielkość teamu? Jest to team składający się z jednej osoby - mnie. Prawda jest taka, że najlepiej pracuje mi się samemu. Rozumiem swój kod, wiem jak go pisać, aby był czytelny i mam swoje przyzwyczajenia, które mi to ułatwiają. Zwracam uwagę na wiele szczegółów i nie mogę patrzeć, gdy ktoś bezmyślnie mi go psuje. Pisanie kodu polega na ciągłym zastanawianiu się nad jego konsekwencjami. Tego właśnie brakuje słabym.

Największe kłamstwo programisty

"Poprawię to później" jest największym jakie znam kłamstwem programisty. Najczęściej jeszcze połączone z drugim: "bo teraz nie mam czasu". Oba się świetnie sprzedają w świecie IT. Przecież naszemu klientowi na czasie bardzo zależy. Im szybciej dostarczymy gotowy kod tym szybciej może go wykorzystać, więc co w tym złego, że chcemy usprawnić kod później, gdy przyjdzie na to czas? Uważam, że nic, jeśli programista jest szczery i naprawdę chce dany kod poprawić. Najczęściej jednak taki programista w ogóle czegoś takiego nie powie. Profesjonalista, uzna swoją pracę za skończoną dopiero wtedy, gdy jest skończona czyli gdy jego kod jest wystarczająco dobry. Oczywiście, zdarza się, że i on potrzebuje więcej czasu jednak zamiast kłamać po prostu zostanie po godzinach i kod dopracuje.
Kiepscy programiści nie zdają sobie sprawy z implikacji swoich poczynań. Z kodem jest podobnie jak z zabezpieczeniami. Jest tak dobry jak jego najsłabsza część. Jeśli system, który budujemy zawiera słabe rozwiązanie to właśnie ono najczęściej zawodzi. Nie jest wówczas istotne, że pozostałe 99% systemu działa poprawnie bo dla użytkownika program zawiódł jako całość. Pół biedy jeśli leń po prostu zrobił błąd, który daje się niewielkim kosztem naprawić. Zwykle nie jest jednak tak różowo, szczególnie z przypadku poważniejszych architektonicznie zmian. Takie zmiany bywają w praktyce nieodwracalne. Nasz piękny system, nad którym w pocie czoła miesiącami pracowaliśmy poległ z ręki nieodpowiedzialnego programisty.

Hakerzy

Załamałem się ostatnio słysząc w pracy rozmowę dwóch deweloperów omawiających rozwiązanie. Pierwszy zapytał: "How we're going to implement this?". Na co otrzymał natychmiastową odpowiedź: "Do you want a small hack or big hack?". Ci dwaj, których od tego czasu nazywam hakerami bawili mnie już wcześniej swoimi rozmowami. Słowo "hack" dominowało ich dyskujsje od conajmniej tygodnia. Najśmieszniejsze jest to, że zdają sobie sprawdę, że tak się software'u nie pisze, ale pretensji do siebie nie mają. Jeden z nich oburzony raz stwierdził, że muszą stosować hacki, aby skończyć zadanie. Na co odpowiedziałem, że to już ich problem.

Obserwuję to zjawisko od dłuższego czasu. Programiści bardzo rzadko są krytyczni wobec własnego kodu. Najczęściej jest to krytyka kodu, z którym należy się zintegrować lub użyć by zakończyć zadanie. Tak było i w tym przypadku. Hakerzy rozszerzyli jedną z klas istniejącego frameworku. Całe rozwiązanie było jednak niezwykle nieudolne. Czy programista ma w ogóle prawo narzekać na to, że musi stosować haki? Z mojego doświadczenia wynika, że nie. Zwykle deweloperzy są tak słabi, że zewnętrzny kod traktują jako dobrą wymówkę dla własnego kiepskiego kodu.

Raz! Dwa! Trzy! Blog start!

To jest testowy wpis, aby sprawadzić jak działa blogger.com.