Dzisiaj, chyba o 19:00 polskiego czasu, rozpoczyna się coroczny Apple Event, na którym gigant z Cupertino ogłasza premiery swoich nowych produktów. W planach są między innymi smartwatche.

Od kilku dobrych miesięcy krążą „plotki” że Apple znalazło nowego dostawcę modemów - MTK.

Tak się składa, że pracuję dla MTK… ba, nawet płacą mi za pisanie kodu dla modemów. Przypadek? Nie sądzę.

#programowanie #programista15k #programista15k #pracait #chwalesie #apple #applewatch

Wiedzieliście, że Polska ma swój własny DCF77?!

Momentalnie na usta cisną się miliony pytań! A komu to potrzebne? Jak do tego doszło? Otóż okazuje się, że GUM prowadzi serwis e-Czas, którego jedną z części jest e-Czas radio.

Oczywiście, zamiast wykorzystać bardziej popularny DCF77, musieliśmy stworzyć własny protokół, który jest gorszy od DCF77. e-Czas gwarantuje dokładność synchronizacji poniżej (trochę analne stwierdzenie) 10ms, a błąd synchronizacji w DCF77 nigdy nie przekroczy 5.5us. Czyli mówimy tutaj mniej więcej o trzech rzędach wielkości różnicy, ale jak to było, nie będzie Niemiec pluł nam w twarz.

Odbiornik referencyjny jest zamieszczony na Githubie. Świetnie! Tja... Schemat w Eaglu z adnotacją, odsyłającą do schematu w KiCadzie. Okay, tylko dla kicadowej wersji nie ma PDFa, a mi nie chcę się ściągać specjalnie KiCada. RF frontend na scalaku, okay. DSP zrobione na lekko prehistorycznym PICu (mimo że projekt został wrzucony na Githuba w zeszłym roku, no ale może jest starszy). Z opisu odbiornika na stronie GUMu wynika, że demodulacja jest napisana w assemblerze. No okay, czyżby zabrakło mocy obliczeniowej i trzeba było ręcznie optymalizować kod? Tylko, że częstotliwość IF to 1kHz, a ten PIC może się kręcić do 40 MIPSów. A teraz najlepsze - kod źródłowy nie jest dostępny, tylko plik hex! Także ten...

W okolicach projektu oczywiście musieli się kręcić krótkofalarze. Jedną twarz nawet kojarzę.

#programowanie #programista15k #programista25k #pracait #telekomunikacja #radiokomunikacja #elektronika #telcozhejto

Wszystko zaczęło się kiedy miałem 12 lat (albo w tych okolicach). Mój pierwszy, wymarzony komputer. Myślałem, że będę giercował całe noce. Myliłem się.

Niestety, okazało się, że z coś było nie tak z moim pierwszym komputerem. Gry, zaraz po odpaleniu, potrafiły się "minimalizować". Dopiero po kilku próbach mogłem zacząć zabijać Niemców w pierwszym Call of Duty albo ścigać się w Need for Speed Underground 2. Było to niewiarygodnie frustrujące. Nigdy nie dowiem się, na czym polegał błąd. Bug w Windowsie XP? Wadliwe sterowniki Nvidii? A może po prostu uszkodzona karta graficzna.

Byłem znudzonym nastolatkiem. Miałem komputer, miałem dostęp do Internetu, ale nie mogłem grać. To nie mogło skończyć się dobrze. Zacząłem programować.

Pisałem pierwsze programy Turbo Pascalu 7.0. Do dzisiaj pamiętam, że na końcu programu, po ostatnim "end" trzeba postawić kropkę. W sumie, to jedyna rzecz, którą pamiętam z Pascala.

Na samym programowaniu się nie skończyło. Poszedłem krok dalej. Odkryłem u siebie zamiłowanie do rzeczy niszowych, indie, off-topowych. Został hipsterem zanim stało to się modne. I zainstalowałem swojego pierwszego Linuksa - Mandrake, chyba w wersji 9.0.

Oczywiście, jak to z Linuksami bywa, coś tam tradycyjnie nie działało. Po kilku dniach poszukiwań w Internecie, na zagranicznych forach, znalazłem rozwiązanie. Musiałem "skompilować jądro"!!! Nie wiedziałem co to znaczy, nie wiedziałem dlaczego dokładnie muszę to zrobić. Wiedziałem tylko, że musiałem skompilować jądro.

Kompilacja jądra nie rozwiązana problemu. Ale to już nie miało znaczenia. Wszedłem na ścieżkę, z której nie było odwrotu. Zacząłem programować na poważnie - najpierw w C, potem w C++. Wreszcie zrozumiałem jaka jest różnica pomiędzy kompilacją a linkowaniem. Dowiedziałem się o innych architekturach niż x86 - ARM, Sparc, etc. Poznałem, co to endianness i przerwania procesora.

Sam Linuks mi już nie wystarczał. Musiałem zainstalować FreeBSD i oczywiście również skompilować jądro. Potem wróciłem na Linuksa, a konkretnie na Gentoo. Gardziłem gotowymi paczkami i uważałem, że wszystko trzeba kompilować ze źródeł.

Marzyłem, żeby dostać się na informatykę. I dostałem się. Ale nie taką zwykłą, tylko na starym Wydziale Elektroniki (W4) na PWr. Tam, dowiedziałem się o jeszcze bardziej niszowych rzeczach - DSP, FPGA. To było jak nieopisane spadanie w studni nieskończonego potencjału. Implementowanie stałoprzecinkowego FFT w VHDL od podstaw. Transformata falkowa jako podstawa mojej pracy inżynierskiej. Eh, wspaniałe czasy. Aż łezka mi się w oku kręci.

Aż w końcu nastał 1 października 2014. Przez czysty przypadek (a może zdecydowali tak starożytni bogowie) trafiłem to fińskiej firmy zajmującej się telekomunikacją bezprzewodową. DSP, FPGA, matematyka, informatyka, elektronika, system engineering. Wszystko w jednym miejscu! Czy może być coś piękniejszego? Ależ oczywiście, że nie!!!

Moje życie pewnie potoczyłoby się zupełnie inaczej, gdyby nie te problemy z pierwszym komputerem. Przypadek? Może... a może po prostu tak miało być? Może to jest moja karma. Może o moim przeznaczeniu zadecydowali starożytni bogowie? Tyle pytań, tak mało odpowiedzi!

Jestem kucem. Jestem pasjonatem. Jestem z tego dumny. Nikt nie jest w stanie mi tego zabrać. Właśnie skompiliwałem sobie kernela Linuksa na RISC-V w wersji 64 bitowej. Dla czystej przyjemności.

#programowanie #programista15k #programista25k #pasjonat15k #pracait

#praca #cv #pracait #zalesie

Hmm, więc @moll robi sobie przerwę a pracowaliśmy nad moim CV, wolno szło bo miałem po drodze masę zajęć.

Jest tutaj może ktoś, kto by się podjął rzucenia okiem, pytam raczej o osoby zaznajomione z procesami rekrutacji?

Dalsze odkrywanie trybu pracy w firmie produktowej #it

Przez ostatni rok pracowałem z zespołem, gdzie dwie główne devki były, w mojej ocenie, dość nielotne.

Po każdym refinemencie jak już wiedziałem jakie są wymagania zabierałem się za design. Moje pliki z figmy zawsze zawierają mockupy poukładane tak że odzwierciedlają ścieżkę użytkownika i stany komponentów (jakieś errory, empty, active, hover itp.) tak żeby frontend dev miał wszystko na tacy. Czasem nawet robiłem klikalny prototyp i nagrywałem to żeby dev mógł łatwo obejrzeć jak wygląda happy path. Dodatkowo każda ścieżka posiada tytuł z linkiem do taska w jirze w którzym są kryteria akceptacji (np. dodawanie do koszyka JP-2137) tak że jak się czegoś nie rozumie z mockupów to można łatwo znaleźć dodatkowe informacje. Na każdym design handoverze tłumaczę dlaczego tak coś zostało zaprojektowane, w oparciu o co, i robię często dwie wersje: minimum z której nie da się już nic wywalić żeby nie zepsuć ficzerka, oraz pożądaną.

I jak przychodziło do implementacji, to i tak te devki potrafiły miesiąc po klepnięciu wszystkiego zadawać pytania "a czemu tak? a mi się podoba inaczej" albo "a jak to działa?", "a po co ten przycisk?". Mając dokładne mockupy, kryteria akceptacji i spotkanie z handoverem.

Przełknąłem to, nauczyłem się z tym żyć.

Ale przyszedłem do drugiego zespołu i jest to samo. Porozmawiałem w zespole o tym, bo pomyślałem że może to ja coś za dużo zakręciłem i się w tym gubią. Pogadałem ze znajomymi devami z innych firm żeby dali mi feedback czy takie coś pozwalałoby im mieć wiedzę co zrobić i jak i wychodziło że bez problemu.

I wtedy eureka, dotarło do mnie.

Otóż wczoraj przekazałem kolejne mockupy i dosłownie minutę później pisze do mnie PO projektu:

-Siema Maciek, bo Tomek jest zblokowany z taskiem, nie może rozkminić o co chodzi w tych mockupach

-Tak jak mówiłem na spotkaniu chodzi o blablabla, co jest dodatkowo opisane w tasku blablabla

i zatrzymałem się bo raz że wkurzyłem się że znów muszę to powtarzać, a dwa dlaczego ten dev sam do mnie nie napisze

I sobie pomyślałem, że jakby ten dev od razu wziął się do pracy, to wyszłoby że albo

a) zrobiłby to szybko i miał czas na dodatkową wrzutkę

b) jakby chciał to porobić na chillu to wyszłoby że robi to dłużej niż przewidywano i musiałby się tłumaczyć czemu

tak źle i tak niedobrze.

więc co robią devi?

W d⁎⁎ie mają te taski, mockupy, handovery itp. Oni już z góry wiedzą, że jak przyjdzie do implementacji to napiszą na priv (no bo wiadomo że nie na kanale zespołu) do PO czy innego BA że brakuje im danych do rozpoczęcia pracy, wrzucają taska na "blocked" i mają labę, bo wtedy druga osoba musi te informacje zdobyć. Zanim ten PO czy BA ogarnie o co chodzi i napisze do mnie, zanim ja mu odpiszę, zanim on upewni się że faktycznie wszystko jest i zanim odpisze devowi mija jakieś pół dnia, a może nawet i kilka dni jak BA uzna że może lepiej zrobić spotkanko. W tym czasie można mówić "no ja jestem zblokowany z tym taskiem" i mieć wywalone.

I podstawą tu jest pisanie na priv, nie bezpośrednio do ludzi którzy mogą ci pomóc, tylko znaleźć sobie takich który wielbią się w byciu potrzebnymi.

Serio, przejście z software house do firmy produktowej to nadal jest dla mnie odkrywanie nowych poziomów opierdalactwa i spychologii.

#pracbaza #pracait #korposwiat #design

uwielbiam tę robotę, piszesz jakiś skrypt, który kasuje cudzą pracę, a quality kodu rośnie i wszyscy zadowoleni

#pracait #heheszki #programowanie trochę #devops

Tak się zastanawiam, czy byłby ktoś zainteresowany streamem na Twitchu jak programuję PRACHa w Pythonie?

#programowanie #programista15k #programista25k #pracait oraz #telcozhejto

Eh, wszystko co dobre się kończy - postanowiłem opuścić mojego tajwańskiego ciemiężcę. Od pazdzierka będzie ciemiężył mnie już ktoś inny.

Co ciekawe, po raz pierwszy zostanę masterem. Master of disaster, to idealnie pasuje do mnie.

Przyznam, że było dla mnie oczywiste że dostanę tę pracę. Dlatego mocno się zdziwiłem, że pani z HR pogratulowała mi przejścia rekrutacji na „tak wysokie stanowisko”.

#programowanie #programista15k #programista25k #pracait

Hej, robicie jakieś ciekawe projekty na git gdzie by można się podpiąć i dorzucić kilka cegiełek.

Ja działam nad narzędziem terminalowym pisząc w pythonie(z ai - jakieś ładniejsze to wszystko)

#programowanie

#pracait

Uwielbiam słuchać o procesach w wielkim korpo mojej żony, utwierdzają mnie one w przekonaniu że praca w takich firmach to nie praca.

Dział #it u niej liczy kilka tysięcy osób rozsianych po całym kraju, a praca idzie tak wolno, że ja już przestałem się dziwić że branża w której działa ta firma jest jaka jest.

Ogólnie u niej jest niemożliwe być wypierdzielonym za nicnierobienie.

Wyobraźcie sobie sytuację, że pracujecie w zespole w którym jest 10 osób, ale jedna kompletnie nic nie robi - nie pojawia się na spotkaniach, jej zadania wiszą niezrobione przez kilka sprintów, no ewidentne lecenie w kulki. Co można zrobić z taką osobą? Naturalnie odpowiedź nasuwa się jedna - zwolnić.

Ale jeśli ją zwolnisz, to nagle się okaże że nie będzie można nikogo dostać na miejsce tej osoby, tylko jej pracę trzeba będzie rozdzielić na innych. Teraz ona jest po prostu nie robiona, nikt nie musi sie za to brać. Więc ludzie są wściekli bo sami mają przez to zastoje w swoich zadaniach, ale wolą tak niż żeby dostać dodatkową pracę.

Ale żeby morale zespołu nie leciało na łeb to liderzy zespołów znaleźli na to rozwiązanie, słuchajcie tego:

Zauważono że praktycznie w każdym zespole jest ktoś taki kto się opieprza. Więc uruchamia się dla nich program naprawczy, jakieś feedbacki, cele i inne duperele, tylko po to żeby dostać zgodę na rotowanie tych ludzi między zespołami. Dzięki temu pozostali członkowie zespołu mają wrażenie pozbycia się zgniłego jaja, ale nie wiedzą że na jego miejsce przyszło może i gorsze - liderzy zespołów doszli do wniosku że to poczucie "pozbyliśmy się problemu" spowoduje że nie odkryją nowego jakoś bardzo szybko, a jak go odkryją to znów trzeba będzie robić feedbacki, eslakacje, procesy naprawcze itp. i tak minie rok albo więcej kiedy lider będzie miał spokój.

#praca #pracait #korposwiat

Biorę ostatnio udział w dużej liczbie rekrutacji IT i to jest kurde chore, jakie teraz są wymagania i jak długie są procesy rekrutacyjne. Oto jak to wygląda:

1. Najpierw jest 15-30min rozmowy telefonicznej z zaproszeniem na właściwą rozmowę z HR. Najgorzej, jak zadzwoni Hindus, musisz wtedy wyłapać kontekst wypowiedzi z co drugiego słowa wymawianego w języku hinglish (najczęściej telefon z UK zwiastuje kłopoty)
   

2. Dalej najczęściej jest 30-60 min rozmowy z HR z pytaniami typu "wyobraź sobie, albo przypomnij jakąś bardzo stresującą sytuację w pracy, jak sobie z nią poradzisz?" Srak k⁎⁎wa, zastanowię się, jak rozwiązać problem i go rozwiążę, co więcej mam tutaj powiedzieć? Najgorsze jest to, że zazwyczaj te rozmowy są po angielsku, a ja nawet po polsku nie wiem, co bym odpowiedział we więcej niż 3 słowach, więc podwójny stres. Tutaj też musisz wyrecytować całe CV, bo najwidoczniej w dziale HR nie potrafią czytać.
   

3. Aplikuję na stanowisko programisty, więc pewnie spodziewacie się, że kolejny etap, to sprawdzenie tego co będziesz robić i umiejętności technicznych? Bynajmniej. Tym razem musisz opowiedzieć mniej więcej to samo co na poprzedniej rozmowie, ale czasami 1, czasami 3 osobom (managerowie od różnych rzeczy). Tutaj też opowiedzą ci do jakiej super firmy aplikujesz i jaki super projekt cię czeka. Kolejne 60-90 minut, czasami całość rozmowy jest po polsku, czasami po angielsku, czasami trochę tak, trochę tak.
   

4. No dobra teraz czas na zadanko. Niektórzy dają coś do zrobienia w domu, inni od razu organizują rozmowę techniczną. Na zadanie trzeba poświęcić kilka godzin, a na rozmowę znowu 60-90 minut. Nawet jak jest zadanie do zrobienia w domu, to i tak czeka cię rozmowa z omówieniem rozwiązania - czasami online, czasami stacjonarny white board. Jeżeli myślisz, że będziesz programować w swoim ulubionym środowisku z podpowiadaniem składni, to zapomnij. Naucz się pisać kod na kartce, w google docs, albo w zwykłym notatniku. O dziwo rzadko spotyka się te wszystkie platformy online typu leetcode. Zadania z samego kodowania są najczęściej łatwe/średnie.
   

5. Jeżeli aplikujesz do kontraktorni, to okazuje się, że czeka na ciebie kolejna rozmowa techniczna, czasami z prawie identycznymi pytaniami, ale innymi ludźmi, bo najpierw sprawdzał cię ktoś z kontraktorni, a teraz będzie to robił jeszcze raz ktoś z konkretnego projektu. (znowu 60-90 minut)
   

6. Uff, to już koniec prawda? Prawda??? Otóż nie, niektóre firmy prowadzą jeszcze rozmowy behawioralne, w końcu musisz pokazać odporność na łapówkarstwo i inne śmieszne historyjki, z którymi jako programista co prawda nigdy nie będziesz mieć styczności, no ale zawsze to okazja do zmarnowania twojego czasu. (30-60 minut)
   

7. No dobra to już dostajesz ofertę? Nie. Jeszcze musisz opowiedzieć po raz kolejny to samo, co był na wszystkich poprzednich rozmowach, ale jeszcze innemu managerowi. Nie wiadomo po co, jakby sobie nie mógł obejrzeć nagrań z rozmów. (60 minut).
   

Ekstremalnie krótka rekrutacja to dzisiaj 3 etapy i na razie trafiłem na taką tylko raz, bo firma ma ciśnienie na zbudowanie zespołu, najczęściej są jednak 4-5, a najwięcej j/w i cały proces trwa minimum tydzień, a maksymalnie miesiąc. Łącznie będziesz rozmawiać z 4-8 różnymi osobami.

Ja prowadzę własną działalność, mam czas, żeby sobie teraz chodzić na rozmowy choćby po to, żeby pozbierać jakieś doświadczenie, ale jak ktoś normalnie pracuje i chciałby zmienić firmę, to trzeba mieć naprawdę za⁎⁎⁎⁎stą motywację, żeby to wszystko wcisnąć w swój grafik.

Z plusów, to wszystkie rozmowy techniczne, na których do tej pory byłem, były w spoko atmosferze, nie trafia się już raczej na osoby, które wymagają bycia chodzącą encyklopedią.

Ekstremalnie ważne jest dobre zbudowanie CV, napchanie słów kluczowych, żeby w ogóle przebić się przez HRowe automaty filtrujące. Nawet jak masz 20 lat doświadczenia, ale w cv zabraknie jednego słowa kluczowego, to nikt na to cv nie spojrzy. Ze słabym CV na 30 wysyłek miałem jedną odpowiedź, po wprowadzeniu poprawek na 50 wysyłek było jakieś 10 odpowiedzi i na dzień dzisiejszy wydaje się to bardzo dobry wynik.

Oczywiście nie istnieje już instytucja bycia programistą jednego języka typu Java, JavaScript itp. Teraz musisz umieć programować backend, frontend, musisz administrować serwerem, dockera mieć w jednym palcu, ogarniać kubernetesa, co najmniej jednego cloud providera, znać wzorce architektoniczne i narzędzia pozwalające zbudować drugiego netflixa. Oczywiście nie ma tutaj znaczenia to, że będziesz tworzyć wewnętrzną aplikację dla 500 osób, uruchamianą na zwykłym VPSie.

Z jednej strony było czuć, że rynek IT potrzebuje oczyszczenia, ale to, co się odpierdala, to też nie jest normalne.

Człowiek ma normalnie ochotę zrobić kurs na operatora koparki, czy innego dźwigu i sobie pojeździć na budowie, a nie codziennie napierdalać jakieś kursy, side projekty itp.

#praca #pracait #kariera

Niejaki Zabbix wysłał do mnie w ten weekend już blisko 250 smsów. Nawet tego nie czytam, nie płacą mi za to tym razem, ale licznik bije.

Lepiej pójdę już spać, bo coś myślę, że jutrzejszy poranek będzie dynamiczny.

#sysadmin #pracait #gownowpis

Moje korpo właśnie wpadło na genialny pomysł, żeby mnie przerzucić z B2B na "atrakcyjny" śmieciowy UoP. Normalnie świetny deal, nie? Już widzę jak się to opłaca komuś, kto choruje raz na dekadę. Po co mam płacić za coś, z czego nie korzystam? Rocznie biorę maksymalnie tydzień urlopu, a tu nagle ktoś chce mi na siłę wcisnąć 26 dni. Kto to niby wykorzysta? Multisport i Luxmed kompletnie mnie nie interesują – lekarza odwiedzam raz na rok prywatnie, a siłownię mam pod domem. Poza tym, jak już się trafi jakaś grypa, to wolę po ludzku napisać, że dziś nie pracuję, niż błagać lekarza o zwolnienie. Żadnych dzieci nie mam, więc prorodzinne benefity i inne takie cuda są mi całkowicie zbędne. Na B2B spokojnie optymalizuję koszty, a na UoP muszę oddawać fiskusowi połowę wypłaty. Zdecydowanie wolę mieć kontrolę nad swoją kasą, niż finansować biurokratyczny bałagan. Serio ktoś myśli, że UoP jest lepszy? Ktoś z Was też miał taki genialny pomysł u siebie w firmie czy tylko moje korpo odleciało? #pracbaza #pracait