Forfatter: Ove

Neat trick for unstable network cards

Are you experiencing an unstable network card? And have you perhaps run out of alternative network card drivers to try out?

For years I had problems with my Atheros L1 Gigabit Ethernet 10/100/1000Base-T card every time I decided to give it a new chance. It would usually freeze up on me within seconds when uploading data with it.

But today I finally stumbled upon a solution:

By deactivating "Task Offload" the card started working properly again immediately after being reactivated.

Perhaps this neat little trick works for you as well since you’re here reading this post.

Egenlagde vektskiver

I disse pandemitider er det mange som har kjøpt eget treningsutstyr. Dermed er butikkene utsolgt for blant annet vektskiver, og gjerne i lang tid. I tillegg skrur de kanskje også opp prisen p.g.a. økt etterspørsel eller lav kronekurs.

Et alternativ kan da være å lage egne harry vektskiver, så lenge man er litt praktisk anlagt og ikke altfor kresen:

Du trenger kun å kjøpe tre ting:

  1. Gummihjul, noe både Biltema og Jula har. Pass på at du kjøper noen som passer på vektstanga du har. For hjemmeutstyr er vanlig diameter 25 og 30 mm. (I bildet over er vektstanga 30 mm. Og for hvert hjul ble navet slått ut med hammer for å øke åpningen fra 12 til ~40 mm.)
  2. Sement som blandes med sand og vann, eller ferdigbetong som kun trenger vann.
  3. Et lim som limer gummi, f.eks. superlim eller tokomponentlim.

Når du har alt dette kan du sette igang:

  1. Skjær et hull i både dekk og slange, på toppen, når hjulet står oppreist.
  2. Lag ferdig en porsjon med våt betong. Noen få liter er nok til å begynne med. Hvis du er fersking; vær forsiktig med vannet. Det trengs mindre enn man tror!
  3. Mat hjulet med betong til det er fullt, bruk f.eks. en melkekartong. Klem og bank på dekket underveis for at hjulet skal fylle seg best mulig.
    1. Hvis du ønsker en flat kant så hjulet/vektskiva ikke kan rulle må du la være å fylle hjulet helt opp.
    2. Biter av dekket må da skjæres vekk ved liming, så man får en mer flat overflate.
  4. La hjulet stå oppreist og vent minst et døgn på at betongen herder.
  5. Lim igjen åpningen.

En sekk med sement eller ferdigbetong koster ikke allverden, men det er likevel bortkastede penger hvis man bare skal lage f.eks. 2 vektskiver. Det lønner seg derfor å lage flere.

For å regne ut vekt: Bruker du f.eks. 1 liter med betong blir vekten ca 2.4 kg. (I bildet over er hvert hjul ca 5 kg.)

I stedet for små gummihjul kan man også bruke små utslitte hengerhjul. Dette blir da mer «hardcore» vektskiver som i grunn kun passer markløft fordi de blir så tunge. (Av erfaring: Gjerne 40 kg eller enda mer ..)

AWS Lambda

Etter å ha knotet med AWS Lambda i over en måned har jeg lært mye nyttig som kanskje kan hjelpe andre som skal bruke denne superkjekke tjenesten.

(Det er lite kodeeksempler i AWS’ API-dokumentasjon så hver gang man skal ta i bruk ny funksjonalitet blir det gjerne noe prøving og feiling kombinert med googling.)

Første problemet man som regel opplever er at ens egen Lambda-funksjon avslutter før kall til andre AWS-tjenester returnerer et resultat (eller error). Dette er simpelthen fordi kallet er asynkront og kanskje trenger flere hundre millisekunder før det fullfører.

For å vente på asynkrone kall har man heldigvis flere muligheter.

Promise

En mye brukt, men fortsatt ganske ny løsning, er promise:

const AWS = require('aws-sdk');

exports.handler = async () => {

   var dynamodb = new AWS.DynamoDB(...);
   await dynamodb.putItem(...).promise().then(function() {
      // Kode for suksess her
   }).catch(function(error) {
      // Kode for feil her
   });

   // Synkron kode fortsetter her
};

Her er det await og promise som styrer showet. Og på promise lenkes then også catch. Etterpå kan man fortsette med annen synkron kode. Dette er en veldig ryddig måte å gjøre det på. Dessverre er det ikke alle AWS API-er som har promise.

Om det er flere asynkrone kall som skal gjennomføres bør man fjerne await over og vente på kallene samtidig med Promise.all:

...
var dynamodb = new AWS.DynamoDB(...);
var promise1 = dynamodb.putItem(...).promise();
var promise2 = <annet asynkront API-kall her>.promise();
// o.s.v.
Promise.all([promise1, promise2, ...])

Også henger man på then og catch her i stedet for å ha det på hver promise over. Men dette er selvsagt bare mulig så lenge kallene kan kjøres uavhengig av hverandre.

Hendelser

Man har også anledning til å bruke hendelser:

const AWS = require('aws-sdk');

exports.handler = () => {

   var dynamodb = new AWS.DynamoDB(...);
   var kall = dynamodb.putItem(...);
   kall.on('success', function(respons) {
      // Kode for suksess her
   });
   kall.on('error', function(error) {
      // Kode for feil her
   });
   kall.send();

   // Synkron kode
   // fortsetter her
};

Tilbakekall

Alternativt har man bruk av tilbakekall (altså «callback» på engelsk), men hvor man dessverre havner i "callback helvete" hvis man skal gjøre mange kall:

const AWS = require('aws-sdk');

exports.handler = () => {

   var dynamodb = new AWS.DynamoDB(...);
   dynamodb.putItem(..., function(error, data) {
      if (error) {
         // Kode for feil her
      } else {
         // Kode for suksess her
      }
   });
};

Problemet med alle eksemplene over er at det blir unødig venting. Og siden man betaler for hver påbynte bolk med 100 millisekunder er det viktig å begrense ventingen så mye som mulig.

Eksemplet nedenfor viser den raskeste måten jeg har funnet til nå:

const AWS = require('aws-sdk');

exports.handler = (hendelse, kontekst, tilbakekall) => {
   kontekst.callbackWaitsForEmptyEventLoop = false;

   var dynamodb = new AWS.DynamoDB(...);
   dynamodb.putItem(..., function(error) {
      if (error) {
         // Kode for feil her
      } else {
         // Kode for suksess her
      }

      tilbakekall(null, ...);
   });
};

Gjentatte tester viste at tidsforbruket minst ble halvert.

Å eksperimentere med AWS Lambda er noe man aldri blir ferdig med ..

TBC

Hvordan gjør man en avstemming?

Når man tar et regnskapsstudie blir man på skolebenken ofte fortalt at avstemming er viktig, for å undersøke at ting stemmer.

Å avstemme betyr simpelthen bare å få en bestemt del av regnskapet til å stemme med det som er virkeligheten. Dessverre gis det som regel ikke gode praktiske eksempler som viser hvordan dette foregår i virkeligheten.

Men egentlig er det ganske enkelt, og det er bare tre trinn:

  1. For den aktuelle perioden man skal avstemme for må man hente ut utskrifter fra regnskapssystemet. Og i tillegg utskrifter av tilgjengelig regnskapsdokumentasjon fra andre kilder som viser situasjonen i virkeligheten.
  2. Deretter sammenligner man utskriftene for å finne de transaksjoner som mangler og som kan bokføres.
  3. Til slutt stiller man opp de transaksjoner som enten i regnskapet eller i den innhentede dokumentasjonen kommer utenfor den aktuelle perioden p.g.a. senere bokføringsdato.

Her er et eksempel på oppstilling for bankavstemming på en fiktiv kunde. Og med forklaringer på hvordan noen transaksjoner kan få forskjellige bokføringsdatoer i regnskapet og i banken:

Det er her 1920 Bankinnskudd i balansen som avstemmes, mot tilhørende bankkonto.

Øverst er saldo fra regnskapskonto lagt inn. Nederst er saldo fra bankkontoutskrift plassert, med minustegn foran. Hvis saldoene ikke stemmer er forklaringen èn eller flere transaksjoner som har oppstått etter perioden eller som er bokført etter.

Så lenge disse transaksjonene listes opp riktig utifra type (dvs. uttak eller innskudd) og opphav (dvs. regnskapskonto eller bankkonto), og med forklaring, er det ingen problem å få avstemt regnskapskontoen (altså 1920 Bankinnskudd.)

Eventuelle øre- eller kroneavvik oppstår også fra tid til annen, men disse føres vekk.

Hvor ofte bank avstemmes kommer an på aktivitet og hva som er avtalt med kunden, men det er vanlig å avstemme èn gang per mnd.

Der hvor jeg jobbet pleide folk å ta fysiske utskrifter også sammenligne manuelt når de skulle avstemme. Dette er tidsløsing når man kan gjøre det digitalt og automatisk.

Er du litt datavant står du fritt til å mekke noe selv, slik jeg gjorde. Eventuelt kan du bruke en form for automatisk avstemming i regnskapssystemet hvis det er støtte for det. (Noen har det og noen ikke.)

Den store skumle fristlista

«Hvordan jobber egentlig eksterne regnskapsførere?» «Hva er det som styrer arbeidsdagen?» «Hvordan prioriterer man arbeidsoppgaver hvis tiden er knapp?» «Hvordan klarer man å holde oversikt over alle oppgavene som skal gjennomføres?» «Får man straff hvis man glemmer en oppgave eller gjør noe feil?»

Dette tror jeg er ganske vanlige spørsmål når man sikter mot en jobb som ekstern regnskapsfører eller er nysgjerrig på yrket. Svaret er at man i praksis forholder seg til fristlister i en eller annen form. Dette gjelder både regnskapsføreren og regnskapsmedarbeiderne når de skal arbeide med en kunde.

Vanligvis er det 1 stk. fristliste per kunde, men hvor omfattende den er kommer an på hvilke arbeidsoppgaver som er avtalt med kunden i den skriftlige oppdragsavtalen.

Eksempel på stor fristliste for en oppdiktet kunde ved navn Skummel Butikk AS:

Denne fristlista er satt opp med hjelp av PowerOffice Win som er en mye brukt programvare i regnskapsbransjen. Den muliggjør effektiv kundeadministrasjon, timeføring/fakturering, med mer.

Forklaringer:

  • «P1», «P2», «P3», o.s.v. er for hver regnskapsperiode. Hvis man følger det vanlige kalenderåret vil «P1» da være januar, o.s.v.
  • «25/12», «1/1», «15/1», o.s.v. er fristen som er satt for en bestemt arbeidsoppgave.
  • «Ok» betyr at oppgaven er ferdig utført for den aktuelle perioden.
    • «Ok v» betyr at den ferdige oppgaven har vedlegg. Hvis det er dokumenter er det gjerne i filformat fra Adobe eller Microsoft. Hvis det er regneark er det i filformat for Microsoft Office Excel.
    • «Ok v n» betyr at den ferdige oppgaven i tillegg til vedlegg har et tekstnotat. Dette kan være en kort kommentar, en forklaring eller lignende.
    • «Ok n» betyr at den ferdig utførte oppgaven kun har notat.
  • «IA» betyr «ikke aktuell» og brukes der en oppgave ikke trenger å gjøres hver periode.
  • Rødt felt betyr at fristen er forbigått uten at oppgaven er utført.
  • Grønt felt betyr at den som har det egentlige ansvaret for kundeoppdraget (en autorisert regnskapsfører) har kontrollert og godkjent den utførte arbeidsoppgaven.

Hvert felt for en arbeidsoppgave i kolonnene «P1» til «P12» kan man dobbelttrykke på for å åpne oppgavevinduet:

Her er oppgavevinduet for en oppgave som handler om avstemming av bank.

For ferdige oppgaver vil det som regel være lagret tekstnotat og eller vedlegg, litt avhengig av hvor omfattende oppgaven var og om det er avvik.

De fleste arbeidsoppgaver har frister man vanligvis prøver å overholde. Ellers havner man fort bakpå og blir stressa.

Fristene er spesielt viktige hvis det er snakk om informasjon som skal sendes inn til det offentlige. Her kan konsekvensen bli tvangsmulkt hvis man ikke får sendt inn tidsnok. Og hvis det skjer p.g.a. eget sommel er det pinlig for kundeansvarlig. Attpåtil vil selvsagt ikke kunden betale når det er andres feil. (But not to worry: Du får ikke slike arbeidsoppgaver uten tilsyn og eller når du er fersk i yrket, så slapp av. 🙂 )

Man vil likevel være veldig opptatt av å overholde frister og ikke gjøre en eneste feil når man er fersking. Det ligger i ens natur å være nøye når man er av den typen som liker regnskap. Og man har jo fått det hamret inn på skolebenken hvor viktig det er at regnskapet er riktig. I starten kan man derfor bruke veldig mye tid på detaljer før man blir komfortabel med jobben og senker skuldrene.

Det er derfor lett å bli litt sjokkert og få panikk første gangen man ser fristlisten til en ny ukjent kunde. Spesielt hvis det allerede er masse røde felt (fordi man overtar andres rot).

Uformelt blir ofte fristlista kalt for ‘hamsterhjulet’ eller ‘hamsterburet’ av de som har litt humoristisk sans. Fordi lista inneholder mye gjentagende arbeidsoppgaver som grunnleggende er like uansett hvilken kunde det er snakk om.

Programlus i W10 for venstre museknapp

Hvis du en dag erfarer at venstre museknapp plutselig slutter å fungere når du har Windows 10 vil kanskje dette blogginnleget løse problemet for deg.

Kort historikk: Jeg hadde akkurat installert Malwarebytes og skulle kjøre programmet, men så klikka musa. Venstre museknapp sluttet helt å fungere. Og jeg fikk ikke liv i den igjen uansett hva jeg prøvde. Selv ikke brukeravlogging, omstart av datamaskin eller fjerning (også tillegging) av museenhet via Enhetsbehandling fungerte.

Helt tilfeldig snublet jeg over en YouTube-video som viste bytte av primærknapp for mus, altså fra venstre til høyre. Jeg tenkte derfor at jeg kunne prøve å bytte til høyre, vente litt, også bytte tilbake igjen, og at dette kanskje ville fungere .. Noe det gjorde!

Så om du selv erfarer dette problemet:

  1. Gå til museinnstillinger og bytt primærknapp.

2. Bruk høyreknappen litt slik du ville brukt den venstre. Høyreklikk f.eks. på Start for å åpne Start-menyen.

3. Sett primærknapp til venstre igjen (i museinnstillinger avbildet over).

4. Om venstre museknapp ikke fungerer øyeblikkelig så trykk intenst igjen og igjen helt til den fungerer. For meg gikk det ca 5 sekunder før den begynte å reagere igjen ..

Good luck.

Jobbeskrivelse: Regnskapsmedarbeider i regnskapsførerselskap

Det kan være vanskelig å vite hva man egentlig går til når man får jobb som regnskapsmedarbeider i et regnskapsførerselskap.

Er man uten utdanning har man kanskje fått foten i døra fordi man allerede har noe erfaring som er relevant. Men hvis man kommer fra skolebenken er det mye som vil bli annerledes fra det man har trodd.

Bokføring

Før man utarbeider årsregnskap og (eller kun) skatteregnskap for et regnskapspliktig selskap må man gjennom hele året ha bokført alle transaksjoner som er relevante for det aktuelle selskapet. Hvis dette ikke gjøres automatisk blir det i stedet tidkrevende manuelt arbeid gjennom hele året som kunden selvsagt må betale for.

For at det skal gjøres automatisk må kunden bevisst ha valgt systemer som støtter automatisering, i tillegg må disse være satt opp riktig.

Her er noen muligheter – med dagens moderne datasystemer:

  • Kassaapparat kan konfigureres til å kommunisere med regnskapssystemet og fortelle hvilke kontoer som skal få nye poster hver gang man tar kassaoppgjøret.
  • Banker kan kommunisere med regnskapssystemet hvilke transaksjoner som er gjort.
  • Med hjelp av OCR og ML kan klienten scanne inn eller ta bilde av fysiske kvitteringer og fakturaer. Disse sendes så inn og bilagføres automatisk, slik som digitale kvitteringer og fakturaer.

Hvordan bokføring gjøres i praksis, hvilke systemer som finnes, og hvilken plass automatisering har, hopper man gjerne helt over på skolebenken. I stedet gis man en innføring i balanse og resultat samt standardkontoplanen. Også bruker man det dobbelte bokholderis prinsipp og gir studentene litt mengdetrening i å løse teoretiske bokføringsoppgaver ..

Det betyr at overgangen og lærekurven blir stor, og mye større enn mange tror.

Oppgaver

Det finnes flere typer bokføringsoppgaver man kanskje ikke har hørt så mye om på skolebenken, her tenker jeg å liste opp flest mulig av disse.

Avstemming

Når man gjør en avstemming undersøker man om en bestemt del av regnskapet for en bestemt periode stemmer overens med det tilgjengelig regnskapsdokumentasjon sier er riktig.

Dette vil man f.eks. måtte gjøre minst hver måned for bankkontoer som har mye trafikk, sånn som 1920. Bankkontoutskriften for den bestemte perioden vil her bli "fasiten" som man sammenligner opp mot.

Som regel finner man transaksjoner som mangler. Da må man bruke tilgjengelig regnskapsdokumentasjon og bokføre de. Har man likevel avvik til slutt må disse forklares så man ikke har reelle ukjente differanser.

Les «Hvordan gjør man en avstemming?» for mer om avstemming og for å se et eksempel på oppstilling av transaksjoner som gir avvik.

Åpne poster

Alle firmaer har kunder og leverandører. Og siden det er vanlig å handle på kreditt sendes det mye fakturaer. Så lenge en faktura er ubetalt vil den utgjøre en åpen post i regnskapssystemet. Disse rapporteres gjerne til klienten med jevne mellomrom.

Rent praktisk genererer man lister i regnskapssystemet som viser alle åpne poster også sender man disse til klienten, f.eks. via e-post.

MEN før man gjør dette må de kontoer som brukes til sending eller mottak av betalinger avstemmes. Ellers risikerer man å sende lister med åpne poster som faktisk er lukket. Klienten vil da purre på kundefordringer som allerede er betalt og eller i verste tilfelle dobbeltbetale til leverandører. Simpelthen fordi regnskapet ikke var helt oppdatert.

Dokumentasjon

Når man sitter på skolebenken og tar et regnskapsstudie får man stadig høre at ting må dokumenteres, at dokumentasjon er viktig o.s.v. Jeg så alltid for meg at ting ble registrert automatisk fordi man idag bruker databaserte regnskapssystemer som det stilles strenge krav til. Men dette stemmer bare delvis.

Det er fortsatt mye som må gjøres manuelt for å dokumentere at en arbeidsoppgave er utført. Og dette er tidkrevende. Noen ganger bruker man kanskje mer tid på dokumentasjonen enn selve oppgaven.

En utført arbeidsoppgave må dokumenteres så omfattende at andre personer som ikke nødvendigvis kjenner kunden (eller din arbeidsmoral) skal kunne gå inn i systemene og enkelt se at den faktisk er gjort. I praksis er regelen slik at det som ikke er dokumentert skikkelig det er ikke gjort. (Her bruker man fristlister for å holde oversikt over utførte og ikke utførte arbeidsoppgaver.)

I tillegg til å dokumentere f.eks. helt konkrete planlagte bokføringsoppgaver hvor det er satt frister, må man også dokumentere kundekontakt, kontakt med det offentlige på vegne av kunden, o.s.v.

Om man legger til seg gode vaner kommer man heldigvis fort inn i det. Og det finnes programvare som tilrettelegger for dokumentasjon i forskjellige former, og hvor alle ved behov kan gå inn og se historikken.

Kunden

På skolebenken gis man oppgaver som har alle nødvendige opplysninger.

I virkeligheten derimot må man forholde seg til kunden som gjerne har andre ting å bruke tiden på. Vedkommende har i tillegg ikke den samme sterke interessen for regnskap som man selv har. Dette kan fort gå utover ryddighet og punktlighet for videresending av regnskapsdokumentasjon til regnskapsfører, regnskapsmedarbeider eller regnskapssystemet.

Noen ganger må man også etterspørre regnskapsdokumentasjon fra kundens leverandører når kunden har mistet noe av den.

Oppsummering: Å være avhengig av informasjon fra kunden betyr at ting tar mer tid.

Et annet problem er at kunden noen ganger kan være sine egen verste fiende:

  1. Vedkommende kan ønske å ta mest mulig av regnskapet selv, for å spare penger når det er dårlige tider. Men hvis regnskapsfører eller en medarbeider må jobbe ekstra for å sjekke eller rette opp gjør dette bare vondt verre.
  2. Kunden kan ha kortvarige kreative (og kanskje ulovlige) løsninger på problemer som ikke egentlig lar seg løse veldig lett. Er det f.eks. dårlig likviditet så er det fristende å låne skattetrekkspenger og eller utsette lønnsutbetaling. Altså låner man penger selv om man ikke egentlig har anledning til det. Kunden kan også velge å delbetale på fakturaer eller utsette all betaling. Dessverre glemmer vedkommende da forsinkelsesrentene og gebyrene som gjør dette "lånet" dyrt.
  3. ….

Ulik praksis

I tillegg til bokføring, dokumentasjon og samarbeid med kunden for å få gjort jobben sin har man også det problemet at ting kan gjøres på flere måter: Hvordan og hva som skal rapporteres, hvilke kommunikasjonskanaler man skal bruke, hvilke kontoer (i regnskapet) som skal brukes og til hva, o.s.v.

Dette er som regel forskjellig fra kunde til kunde fordi ingen kunder er like. Samme gjelder regnskapsførerne når de skal sette opp kontoplan og utarbeider rutiner.

For en regnskapsmedarbeider med bokføringsoppgaver på flere ukjente kunder er det derfor fort gjort å surre litt. F.eks. er det lett å bruke feil kostnadskontoer. Man må da undersøke hvordan ting er gjort tidligere også kopiere etter beste evne.

Av kollegaer med humor kan man få betegnelsen ‘apekatt’ når man "kopierer" tidligere bokføring. Fordi man aper etter det som er gjort tidligere. Men dette er ikke for å gjøre narr. Vanligvis vil de være sympatiske med deg fordi det er ukomfortabelt å ikke kjenne kunden.

For når du ikke kjenner kunden føler du ikke at du er i kontroll. (Dermed blir du en stressa apekatt og hvem ønsker vel å være det?)

Jobbeskrivelse: Kundekonsulent på ringesenter

For noen år siden fikk jeg sommerjobb som kundekonsulent. Dvs. å hjelpe kunder som har problemer. Lite visste jeg da hva jobben egentlig ville innebære. Jeg tror derfor dette innlegget kan hjelpe alle som selv vurderer å søke på en slik jobb.

Der jeg fikk jobb ble det brukt brevpost, telefon, e-post og chat som kommunikasjonskanaler med kundene. Dette var på et ringesenter, altså «call center» på engelsk, med flere titalls andre kundekonsulenter.

Alle som jobbet med kundeservice ble sittende i et felles kontorlandskap ved sin egen arbeidsstasjon, fremfor sin egen dataskjerm. Her foregikk all kundekontakt og problemløsing.

De første dagene var det opplæring som tok for seg alt fra firmakultur til riktig bruk av datasystemene. Deretter begynte ‘medlytt’ hvor nyansatte lyttet til telefonsamtaler med kunder, for å få innblikk i hvordan man jobbet for å hjelpe de.

Etter to uker hjalp alle nyansatte kunder på egenhånd, etter beste evne.

Først løste vi saker som kom på e-post. Deretter begynte vi også på telefon. Det ble omtrent samme prosess for hver kunde som tok kontakt:

  1. Kunden tar kontakt og forklarer problemet (mer eller mindre). Ved uklarheter stiller man oppfølgingsspørsmål.
  2. Man søker opp kunden i datasystemet (som var en CRM der jeg jobbet).
  3. Man forsøker å løse problemet til kunden + forklare underveis. Det kan være så enkelt som å fikse feil navn, adresse, etc. Eller godskrive et beløp for feil eller mangler ved produktet. Eventuelt sjekke status på noe, purre på noe, bestille på nytt, etc. Systemet hadde funksjonalitet for alt og gjorde jobben med å varsle de som var ansvarlige for hver type oppgave en annen plass.
  4. Prøve å finne alternative løsninger hvis man ikke får gjort det kunden ber om. Her er det greit å være en kreativ type og løsningsorientert. Bare ytterst sjelden videformidles saken til noen lengre opp i systemet. Da må det være nødvendig og viktig.

Dessverre var det mye kjeft å få fra de fleste privatkunder som tok kontakt. Noen ganger ble det også rent verbalt misbruk.

Det saklige i mange negative tilbakemeldinger var ofte fortjent fordi kunden ikke hadde fått det som var blitt avtalt, og var derfor frustrert. Ekstra ille ble det visst dette var et evigvarende problem. Men en del negative tilbakemeldinger kom også med altmulig av dyre krav som jeg overhodet ikke hadde anledning til å innfri.

Noen av disse personene med ekstreme krav ble smårabiate. Hadde det vært i butikk ville de nok klart å oppføre seg. Men når det ikke lenger er ansikt til ansikt er det mange som mister all folkeskikk og blir ganske så utrivelige.

Jeg ble aldri komfortabel med all den negative kundekontakten. Etter hver eneste arbeidsdag følte jeg meg kokt i hjernen. At mange sluttet etter å ha jobbet der bare en kort periode er ingen hemmelighet. Og det er synd fordi arbeidsplassen var grei ellers, med hyggelige kollegaer og sjefer.

Stekende sol og feriemodus kan kanskje forklare noe av folks oppførsel denne sommeren. Forhåpentligvis er jobben greiere ellers i året.

Det er også viktig hvilket firma man skal yte kundeservice for. Jobber man for et firma som ikke behandler kundene pent er det DU som kundekonsulent som får skyllebøttene. Hele dagen lang, dag etter dag ..

For å like denne jobben må man elske å prate med folk og i tillegg ha tykk hud.

Prinsippet om avhengighetsomvending

Et viktig utviklingsprinsipp er prinsippet om avhengighetsomvending [«Dependency inversion principle» (DIP) på engelsk] som gir dekobling av viktige programvarekomponenter, såkalte høynivåkomponenter.

I stedet for at disse skal konsumere mange små "arbeidskomponenter" (dvs. lavnivåkomponenter) direkte, for å fungere, velger man å heller gjøre seg avhengig av abstraksjoner. Dette gjelder begge typer komponenter, både lavnivå og høynivå. I praksis vil man da gjerne benytte grensesnitt.

DIP er det siste viktige designmønsteret i SOLID.