Clojurians Log v2
clojure-norway
@holyjak @slipset Jeg jobber i et lite utenlandsk firma som er 100% remote. Tror du har et poeng i at det er mer krevende å ha en mix av remote og ikke-remote. I vårt firma har alle et klart bilde av hvordan vi må gjøre ting for at det skal fungere bra. Vi er ganske gode på det, lite muntlige møter, mye skriftlig dokumentasjon, async, osv. Men det kanskje aller viktigste er en blanko tillit og respekt for andres tid. Det spørres veldig lite om når og hvor man har jobbet, kun om måloppnåelse og progresjon. Og det stilles veldig lite harde krav til å være tilgjengelige på bestemte tidspunkt. Er man ikke på jobb tirsdag kl 13 så er man ikke det, da er spørsmålet heller når neste brukbare tidspunkt er. For min del var det et lite sjokk å komme inn i et sånt miljø, der de som betaler lønna faktisk klarer å stole på de ansatte og helt eksplisitt viser at det er opp til meg selv å disponere min tid sånn at jeg er produktiv. Jeg har ingen problemer med å forstå at noe sånt ikke er for alle, og at det krever mye omstilling i flere ledd. Men noen må gå først. Jeg har vært i samtaler med firma som bruker Clojure i Norge, som var villige til å prøve ut en remote-løsning. Håper at det finnes åpninger om et år eller tre, for jeg har ikke så lyst til å gå tilbake til kontorlandskap og tegne klassediagram.
> at jeg ikke forstyrrer Et spm på slack forstyrrer jo aldri, siden man ikke trenger å følge med når man er dypt i noe? Sånn er det minst for meg. Ellers kan man sikker bruke slack status til å indikere off/on og meldinger i en dedikert kanal om man trenger å beskrive en mer kompleks schedule?
Kanskje det er inspirasjon å finne i distribuert IT-arkitektur? 🙂 Vi vet jo at noder som kommuniserer på et nettverk er et fryktelig komplisert problem. Den som spør kan blokkere eller ikke mens han venter på svar. Kanskje får han ikke svar. Kanskje er motparten “nede”. Kanskje oversvømmes en node av forespørsler, og må bruke tid på å prosessere alle. Beholder alle sin plass i køen, eller er den random rekkefølge? litt søkt kanskje, men parallellene er der. Poenget er at i IT-arkitektur har man løst det ved å akseptere miljøet man står i, og så bygd systemer som er tolerant og robust rundt. Man må f.eks. akseptere at kommunikasjon er grunnleggende asynk. Så spørsmål får man faktisk ikke svar på når man vil, men når motparten svarer. Det er en trade-off man må regne på om man synes funker.
Jeg tror det kommer veldig an på hvilken gruppe og tilnærming man har. Der jeg jobber funker dette veldig bra, sett fra mitt ståsted. Jeg føler meg mye mer produktiv enn i min forrige jobb, og jobber sannsynligvis færre timer. Latency på kommunikasjon kan i verste fall være flere døgn, oftest 1-10 timer, og det er helt klart en ulempe. Men en trade-off.
Jeg liker parallelen din veldig godt 🙂 Ekstra poeng for nerdnivået!
På tide med nok en Clojure Lunch her i Oslo https://doodle.com/poll/nkrw7p2cn7ie5h83
Og da kan vi sikkert diskutere denne
https://hire.withgoogle.com/public/jobs/ardoqcom/view/P_AAAAABkAAApKdYs6WQ6_9Y
Hey, Someone called Tim O’Ryan keeps signing up to the Clojure lunch, but I don’t have any contactinfo on him. Anyone knows him?