« Hem

Utbildning

Åtta saker jag önskar att jag hade känt till innan jag började jobba

Pluggar du informatik och funderar vad du borde lära dig om du har tid över? Varsågod, här kommer en lista på verktyg och begrepp som jag verkligen önskar att jag hade varit mer bekant med innan jag började jobba!

SQL Server jobs

Det första jag grejade med som konsult på Integrationsbolaget var SQL Server, och jag kände mig hyfsat hemma på den planhalvan. (Hey, jag har ju faktiskt undervisat i ämnet..) Ändå satt jag som ett frågetecken när en kollega sa att det är ett ”SQL jobb” som sköter en viss funktionalitet. Det är alltså en aktivitet, ofta att exekvera en lagrad procedur, som körs enligt ett schema, allt ifrån var tredje minut till en gång i månaden. Så om du sitter med SQL Server, ta en titt på SQL Server Agent och Jobs i object explorern, då slipper du sitta som jag och se oförstående ut när du stöter på det på jobbet.

Capture kopiera

 

Virtuella maskiner

Jag var svagt bekant med begreppet virtuella maskiner tidigare, men jag hade absolut ingen praktisk erfarenhet av att använda det förrän jag började jobba. Och när jag gjorde det så insåg jag att det enda arbetsverktyget jag använder i min ”riktiga” dator är i princip mailen och skype, all utveckling sker i virtuella miljöer. Fördelen med dessa är att man kan förbereda och spara färdiga uppsättningar, ex en Windows 10 maskin med SQL Server och Visual studio förinstallerat, som man lätt kan sätta upp och sedan ta bort när den inte längre behövs.

Internet Information Services

Jag har svaga minnen av att vi använde IIS i C#-projektet nåt år för att skapa en web service, men jag minns också att det var jäkligt förvirrande, vilket det också fortsatte vara när jag sedan började jobba. IIS är en webserver som följer med Windows, och är du inte bekant med den eller begreppet web service så är det ett hett tips att läsa på lite om innan jobbet börjar.

Soap UI

Och när du ändå håller på och har satt upp en web service i IISen, så kan du passa på att använda det trevliga verktyget SoapUI för att testa tjänsten. Den genererar automatiskt ett request för webtjänsten och visar sedan responset snyggt och prydligt. (En parentes: det här programmet är bra, men ibland känns det lite ostabilt, så har du erfarenhet av liknande program får du gärna lämna en kommentar och tipsa mig!)

Scheduled tasks

På samma sätt som man kan schemalägga aktiviteter i SQL Server, kan man göra det i Windows. Det gör du enkelt genom att söka på Task Scheduler från startmenyn, och här kan du definiera saker som ska hända antingen vid en viss tidpunkt, eller kopplat till ett visst event. Vi använder detta på flera servrar för att ex. schemalägga triggers för olika integrationsflöden hos en av våra största kunder, men den absolut bästa användningen är den Douglas implementerade någon gång i våras, nämligen att fredagslåten drar igång automatiskt varje fredag kl 17.

Global Assembly Cache

När jag i början på karriären (jao, jag är fortfarande i början, men jag menar i början-början, typ första veckorna) så satt jag med en integration och skulle testa lite ändringar i den, men hur jag än gjorde så fick jag inte den nya funktionaliteten att fungera. Det var som att BizTalk inte fattade att jag hade gjort en uppdatering, och när jag frågade en kollega om råd så svarade han: ”Har du gaccat assemblyn?”. Jag gav då det intelligenta svaret ”Va?”, men har sedan dess bekantat mig lite mer med begreppet. GAC är, enkelt uttryckt, ett ställe där dll-er behöver ligga för att de ska vara åtkomliga från andra applikationer, ex BizTalk, och ibland måste man manuellt uppdatera dessa genom att använda kommandoverktyget gacutil. Jag vet inte hur mycket detta används utanför systemintegrationsområdet, men vi använder det dagligen och det är bra kunskap att ha med sig ut i arbetslivet tror jag.

Message Queue

Det här är en sak som jag inte har en aning om ifall det används i ”vanliga” system och applikationer, utanför området systemintegration, men återigen är detta något vi använder hela tiden. En message queue är precis som det låter en kö där man kan lägga meddelanden, dvs. data i olika format, ofta som xml. Det som gör kön speciell, till skillnad mot att bara lägga filerna i en folder någonstans, är att de garanterar FIFO, alltså First In First Out och används när man behöver garantera att filer skickas i rätt ordning.

DebugViewer

Sist, och kanske även minst på den här listan, kommer verktyget DebugViewer, som är otroligt trevligt när man vill debugga kod i en annan miljö än direkt i Visual Studio. Det är också väldigt enkelt att använda: i din C#-kod skriver du System.Diagnostics.Trace.WriteLine(”Valfri text”); och sedan kan du deploya koden till en server, och bara du har debugviewer installerat på servern så kommer dina meddelanden dyka upp i dess fönster.

dbgview

Det var allt för den här gången! Nu kommer jag och bloggen ta lite välbehövlig semester och återkommer i slutet på augusti. Önskar er alla en fortsatt trevlig sommar!

Lära sig programmera

Innan jag började på systemutvecklarbanan hade jag ingen tidigare erfarenhet av programmering. Det var ett helt nytt fält för mig, en undersköterska i hemvården som försökte komma på vad hon ville bli när hon blev stor. Det enda jag visste var att jag gillade att sitta framför datorn och göra de administrativa uppgifterna, så min första trevare gick mot rollen som läkarsekreterare och på ett bananskal halkade jag in på informatik.

Där öppnade sig fältet för systemutveckling först på en mer övergripande nivå (jag tror min första kurs gällde hur man skulle köpa in affärssystem eller nåt sånt, inte så intressant såhär i backspegeln…) och sedan började jag titta närmare på just rollen som programmerare. Ämnet programmering fascinerade mig väldigt, även om jag närmade mig det med oerhörd försiktighet. Jag vet inte hur många gånger jag googlade ”lära sig programmera” och ”lära sig koda”, både på svenska och engelska, och givetvis den stora frågan: vart ska jag börja någonstans? Vilket språk är bäst för nybörjare? Vilka kurser? Böcker eller videos?

Och jag fick såklart tusen olika svar, i tusen olika forumtrådar: Java är bäst att börja med, eftersom det är ett högnivåspråk. Det är också sämst att börja med, eftersom det inte är processornära programmering, det bästa för nybörjare är Assembler. Assembler är dock sämst för nybörjare eftersom det är ett lågnivåspråk, det bästa är C# eftersom det mer liknar våra naturliga språk. Men det suger också för att det snarare är ramverk och utvecklingsmiljö du lär dig, kör istället på C eller C++ – fast börja för allt i världen inte med de språken, för PEKARE är något otroligt svårt och du kommer gå in i väggen direkt och tröttna, börja istället med HTML, men det är inte programmering faktiskt, kör PHP, trots att det är sämst, Python är bäst, eller JavaScript, eller Ruby, eller Lisp, eller Haskell, osv osv i all oändlighet.

Alla dessa svaren fick mig att tveka och under lång tid gick jag bara fram och tillbaks framför inlärningströskeln, utan att våga ta ett steg mot den, för jag visste inte vilken ände jag skulle börja. Idag ser jag tillbaks och önskar att jag hade sagt till mig själv: det spelar ingen roll vart du börjar! Ta något! Vad som helst! Kom igång! För såhär är det: Programmering är svårt i början. Oavsett vilket språk du börjar med.

Det är ett nytt tankesätt och kräver en viss logik, men det är definitivt inte så svårt som en del vill få det att låta. Jag vill dock poängtera att det inte är så enkelt att lära sig. Det tar tid! Och i början kan det kännas helt omöjligt att förstå sig på, det är nya begrepp och en del saker verkar först helt ologiska. Alla som har suttit i lärositsen har nog slitit sitt hår och frågat: VARFÖR beter sig datorn på detta vis? It makes no sense!!

https://funixx.files.wordpress.com/2014/09/adn5xmm_460s.jpg?w=510

Bildkälla

Vad vill jag säga med det här då? Att programmering är frustrerande och svårt att lära sig? Jao, det är en del av poängen, men inte den största. Det jag vill är att ta dig som funderar på att lära dig programmering åt sidan och säga: kör på! Gör inte som jag, och fundera en evighet på i vilken ände du ska börja, utan kasta in dig i matchen direkt. Det kommer vara tufft i början, men när du väl kommer över den första tröskeln kommer det bli mycket, mycket enklare och ju snabbare du kastar upp dig på tröskeln, desto snabbare kommer du nå den där punkten när polletten trillar ner och allt börjar ”make sense”.

Om jag skulle komma med lite konkreta tips för hur du kommer igång så är nog mitt största att ta en strukturerad kurs och inte hoppa runt på måfå bland olika källor. Jag, som är en plugghäst av rang, rekommenderar definitivt universitetskurser eftersom dessa ofta går ganska djupt i ämnet, och för att du får ett kvitto på att du lärt dig något. Tro dock inte att du kommer lära dig programmering av en enda kurs, för så snabbt går det inte.

Min taktik när jag började plugga var att först läsa en grundkurs i programmering på 7,5 hp på distans, innan jag började på systemvetenskapliga programmet, som innehöll i princip samma kurs igen, fast med lite annan infallsvinkel. Detta gjorde att jag hade ett litet försprång under andra kursen, och kunde sätta grunderna ordentligt, vilket jag tror behövs om du aldrig programmerat tidigare.

Så, sluta fundera och sök en programmeringskurs! Var beredd på att det kommer vara tufft i början men att belöningen kommer, det blir lättare och det är också en otrolig tillfredsställande känsla att skriva kod som fungerar. Det ger en slags maktkänsla att faktiskt kunna få datorn att göra som man vill, även om det bara handlar om att skriva ut ”Hello World” på skärmen.

Och ett litet PS: låt inte tanken på matematik skrämma bort dig! För ärligt talat, även om många programmeringskurser kräver matte C (eller vad det heter numera, matte 3?) så är det faktiskt inte så mycket matte. Jag läste bara B-kursen på gymnasiet, och inte med några toppbetyg direkt, och jag har klarat mig bra ändå. Det fina med att läsa just informatik och systemvetenskapliga programmet är att de inte kräver någon högre matte innan.

Scrum 4 real!

Det finns vissa saker vi gör i skolan som man liksom vet görs ute i *verkligheten*, men som det ändå är svårt att föreställa sig nyttan med. En sån sak är daily scrums. (Vet du inte vad detta är? Läs mer till exempel här.) Alla som läst informatik på Örebro universitet är nog mycket välbekanta med begreppet, och i åtminstone en av kurserna är daily scrums en viktig del av det projekt som genomförs. Daily scrums i teorin brukar beskrivas typ såhär:

daily-scrum-meetingBildkälla

Idealbilden är ett team som står framför sin Scrum board tillsammans med Scrummastern och kort går igenom status på sprinten, samma tid varje dag. Det ska inte ta mer än en kvart, därför är det viktigt att man står upp, och fokus ska inte vara på problemlösning. De klassiska frågorna som varje medlem i teamet ska besvara brukar vara:

  • Vad gjorde du igår?
  • Vad ska du göra idag?
  • Är det något som hindrar dig från att göra det du ska?

I den informatikkurs där de här mötena ingår som en obligatorisk del, tyckte åtminstone jag det kändes ganska… krystat.

Jag agerade scrummaster och ledde våra möten, men trots att jag då försökte motivera teamet att vi måste ses varje dag klockan nio, såg jag inte direkt nyttan med det. Vi satt ju liksom tillsammans hela dagen, och jobbade med ett väl avgränsat projekt där vi hade möten med ”kunden”, dvs. läraren en gång i veckan, och det fanns inga andra distraktioner som kunde störa projektet. Vi hade helt enkelt inte så mycket att säga till varandra under den där kvarten. Men under förra veckan fick jag faktiskt vara med på ”riktiga” scrummöten i det här nya projektet vi håller på med, och ärligt talat tycker jag det är superbra!

Hur kommer det sig då, att det helt plötsligt känns väldigt vettigt att köra daily scrums? Jag har funderat lite och jag tror dessa är de viktigaste faktorerna:

Geografiskt avstånd

Alla delar av teamet sitter inte i samma rum, eller ens i samma stad, vilket skapar ett mycket större behov av att synka arbetet regelbundet och se till så alla är på rätt spår och jobbar med rätt saker. Det blir också viktigt i och med att olika delar av projektet är beroende av varandra, och man måste stämma av så att ingen del av teamet sitter och väntar på att någon annan som i sin tur kört fast.

Storleken på projektet

I skolan har de utvecklingsprojekt man gör ett litet och väldigt avgränsat scope. Det handlar om att utveckla mindre applikationer som kan existera för sig själv utan direkta kopplingar till andra system. I verkligheten är projekten ofta mycket större. Projektet som jag sitter med just nu handlar om att plocka ut funktionalitet från ett fakturasystem till ett nytt CRM-system, då fakturasystemet har byggts ut med ytterligare funktioner under en lång tid. Nu ska fakturasystemet bytas ut, vilket gör att vi måste ”rensa” det först. Integrationsbolagets roll är givetvis att ha hand om integrationerna mellan CRM-systemet och andra system, och de dagliga mötena hjälper oss att få överblick över projektet.

Storleken på teamet

Det här hänger såklart ihop med storleken på projektet: för att genomföra ett stort projekt krävs mer resurser, och vad jag vet så har vi konsulter från minst tre olika bolag, förutom de som redan finns hos kunden. Ärligt talat har jag inte koll på exakt hur många vi är – vilket bara i sig skapar ett behov av att regelbundet stämma av med alla parter så vi är på samma spår.

Störningar

I skolan kunde vi sitta hela dagarna och fokusera endast på projektet, utan att andra saker kom i vägen. I verkligheten är det dock inte lika enkelt: de flesta har andra arbetsuppgifter som ibland måste gå före, och för oss som även har förvaltningsuppdrag hos kunden, kan få incidenter som måste fixas omgående, och då måste projektet vänta. De dagliga mötena blir då till hjälp när det gäller att prioritera och kanske framför allt informera om att man har andra saker som måste göras innan en viss uppgift i projektet.

Mentaliteten

Det här är kanske den viktigaste biten: vilken attityd har teamet till mötena? I mitt fall under skoltiden hade vi inga av ovanstående faktorer som påverkade projektet, vilket gjorde att mötena kändes onödiga. Det i sin tur leder såklart till att folk inte tar dem på allvar och börjar komma försent eller helt enkelt inte bry sig. Och det är en mentalitet som jag lovar är mycket svår att vända när den väl har satt sig i skallen hos folk! I vårt nuvarande projekt blir det tvärtom: det finns faktorer som gör att dagliga avstämningar blir viktiga, folk tar mötena på allvar och detta gör dem automatiskt mer givande.

Det var mina tankar om daily scrums och hur välbehövliga de kan vara, trots att de kan kännas mer som ett nödvändigt ont i skolan. Har du några tankar om Scrum? Håller du inte med mig? Dela gärna med dig i kommentarerna, jag är nyfiken på att höra vad du tycker!

Att plugga eller inte plugga, är det frågan?

Jag pluggade väldigt länge innan jag började jobba. Först läste jag litteraturvetenskap, sedan pluggade jag på komvux och blev undersköterska, och därefter halkade jag in på IT-området. Totalt har jag läst ca 6 år på universitetet och det är min studieskuld som får CSN att gå runt. Ekonomiskt är det väldigt osmart att plugga länge – många av de jag har pluggat med nöjde sig med en tvåårig högskoleexamen och började jobba direkt. För mig, som tog en masterexamen, är det tre år där jag samlade på mig mer skulder istället för att tjäna pengar.

När jag tänker tillbaks och funderar på varför jag ändå gjorde det valet, så slår det mig att jag inte har någon annan anledning än att jag helt enkelt ville plugga. Jag gillar att plugga och visste dessutom att detta var sista gången i mitt liv som jag skulle göra det på heltid, och då ville jag göra det rejält, även om det rent logiskt inte lönar sig. Systemvetenskapliga programmet på masternivå är dessutom mer forskningsförberedande än praktiskt inriktat, så det handlade inte heller om att fördjupa programmeringskunskaperna, även om utbildningen gav mer förståelse för hur IT fungerar på ett övergripande plan när det införs i olika verksamheter.

Just IT-utbildningar är dessutom lite speciella. Det är en bransch där allt händer väldigt snabbt och nya tekniker hinner skapas, hypas, peaka och bli omoderna på ungefär en vecka. Ofta säger man att typ 50 % av det man lärt sig i skolan är föråldrat när man börjar jobba, och det är ju en ganska nedslående siffra. En sjuksköterska eller läkare har troligtvis inte samma problem – kroppen ser likadan ut nu som för tio år sedan, även om utveckling såklart sker inom vården också.

Jag tycker mig ofta se ett lätt förakt mot utbildning inom den här branschen, och ofta får studenter tips att göra egna projekt vid sidan av plugget, för att visa vad de kan, som om själva utbildningen inte vore nog. Programmering ses som ett ”kall”, något man gjort sedan barnsben och brunnit för hela livet. Den självlärda programmeraren hyllas, den skollärda ses som lite mindre värd. Många spyr galla över hur efter utbildningen är jämfört med branschen i stort, och att det man lär sig i skolbänken knappt är relevant för hur verkligheten fungerar. Jag vet, för jag har varit en av dem som gnällt…

Men, nu när jag är färdig och ser tillbaks på skolan, så skulle jag vilja slå ett slag för plugget! Visst, det finns en massa snubbar (för det är oftast snubbar..) som är självlärda programmerare sen barnsben och väldigt duktiga på det de gör. Förutom att arbetsgivare gärna ser att man har kunskapen på papper, så kommer en utbildning ge dig en stabil plattform att stå på och du kommer ha väl befästa grundkunskaper som du kan bygga vidare på. Ett exempel: känner en sån här snubbe som är grym på relationsdatabaser – men han visste inte vad första normalformen innebar eller varför den är viktig att följa… Ni som läst databasteknik vet vad jag menar.

Jag tror starkt på att ha en rejäl examen i bagaget, det ser snyggt ut på CV-t och det är något du alltid har med dig. Visst, ibland är det svårt att se ljuset i tunneln och det känns som att allt man gör är att läsa och man har alltid något hängande över sig. Men jag lovar – tiden går fort och det kommer vara värt det i slutänden!

Hitta drömjobbet som IT-konsult (del 3 av 3)

Då var det dags för den sista delen i den här bloggserien om hur du hittar drömjobbet som IT-konsult och den här delen handlar främst om hur du får jobbet när du väl har hittat rätt.

Skriv en kick-ass ansökan

Hur du än fick nys om jobbet, genom kontakter eller via nätet, så behöver du en bra ansökan. Kanske är det något mindre viktigt om du blivit kontaktad av en chef eller rekryterare personligen, eftersom du då inte har en massa medsökande att tävla mot, men en välskriven ansökan är ändå grundläggande för att ge ett seriöst intryck och i förlängningen få ett jobberbjudande. Jag har själv arbetat med mitt CV i flera år, förbättrat det successivt och ändrat fokus i det beroende på vilket jobb jag söker. Detsamma gäller mitt personliga brev, jag kan inte ens räkna hur många gånger jag omarbetat det under årens lopp, för att bättre framhäva min person och vad mina styrkor är.

Om CV-t

Ett bra CV är kort, konkret och lättläst. Dessa egenskaper tycker jag är de absolut viktigaste, i den ordningen. Fokusera på det viktigaste och dina färskaste erfarenheter, och se till att de är relevanta för jobbet du söker. När jag sökte jobb som undersköterska skrev jag ut vilka områden och avdelningar jag tidigare jobbat på, samt vilka arbetsuppgifter jag hade, men nu när jag sökte som IT-konsult klumpade jag ihop detta till att jag jobbat som undersköterska inom Örebro kommun. Eftersom jag gjorde det i flera år anser jag att det är en viktig erfarenhet att ha med på CV-t, men detaljerna är inte relevanta som IT-konsult.

Men istället för att berätta allt om mitt CV tänkte jag att jag skulle visa det. Det spelar egentligen ingen roll om ni inte ser vad det står, för det viktigaste jag vill visa är layouten och hur jag tycker att ett snyggt CV ska konstrueras. Här har vi förstasidan, och den tycker jag är det absolut viktigaste. Idealiskt är om CV-t kan rymmas på en sida, men det brukar vara svårt om det gått några år sedan studenten, och det är bättre att ha två luftiga, lättlästa sidor än en fullpackad och grötig.

cv2

Sida två handlar för min del om de specifika erfarenheter som är relevanta för jobbet och här är det mer okej att plocka upp detaljer tycker jag. I mitt CV har jag här lyft fram de kunskaper som är relevanta för jobbet som IT-konsult, och ärligt talat tycker jag den här sidan är lite för kompakt med text. Om jag hade skrivit om CV-t idag hade jag nog gjort stycket om systemutveckling kortare, eller kanske bakat ihop det med programmeringskunskaperna, för att inte riskera TL;DR.

cv3

Och det är väl bäst att göra en disclaimer här: detta är såklart mina åsikter om vad jag tycker är snyggt, men en tydlig och enkel layout kommer du väldigt långt med. Tänk: luftigt, tydliga stycken, sammanfattande listor och relevanta rubriker så har du halva inne.

Det personliga brevet

Enligt min erfarenhet tycker många det är svårt att skriva det personliga brevet och det är lätt att fastna i floskler här. ”Jag är en ambitiös person med många bollar i luften, bla bla bla…”. Detta vill du undvika! Det personliga brevet ska vara just personligt. Det ska handla om dig och spegla vem du är som person, fylla i personlighetsdragen där CV-t har ritat upp grunderna om vem du är. Layouten tycker jag är viktig här också, och jag har gett sidhuvudet på första sidan samma stil som mitt CV, för att en rekryterare enkelt ska se att dessa hör ihop.

Capture

Capture2

Mitt brev är i sin nuvarande form knappt 1,5 A4 och jag tycker det är ganska lagom – det behöver i alla fall inte vara längre än så! Tydliga stycken är viktigt för att inte ge ett alltför kompakt intryck, men här tycker jag man ska vara försiktig med punktlistor: det ska vara en sammanhängande, levande text, inte någon platt uppräkning av dina personliga egenskaper eller en kopia av ditt CV. Vilket typsnitt du använder är en smaksak: jag har personligen ett starkt motstånd till standardtypsnittet Times New Roman och använder istället Verdana (teckenstorlek 10) både till CV och personligt brev. Storleken på texten bestäms till viss del av typsnittet, men jag tycker att 10 – 12 punkter är en bra regel. Om det blir mindre än så kan det vara svårt att läsa texten på skärmen, och blir den större kan det ge intryck av att du försöker få brevet att verka mer innehållsrikt än det är.

Jag vet inte om mitt brev är för smått för att ni ska kunna läsa texten, men jag tänkte beskriva hur jag tänkt angående strukturen på innehållet.

  • Börja med en intresseväckande inledning som säger något om ditt mål och det starkaste skälet till att du ska få jobbet.
  • Beskriv din bakgrund och hur du hamnat där du är idag, och framhåll hur du utvecklats under den här tiden.
  • Säg något om vilka delar av arbetet du tycker är roligast. Jag skriver i mitt brev om att jag gillar hela systemutvecklingsprocessen men framhåller kodandet som liiiite viktigare.
  • Beskriv dig själv som person. Det här är nog den absolut svåraste delen och den som flest har problem med. Mitt tips är att komma på tre – fyra adjektiv som beskriver dig och sedan inte bara säga dem, utan faktiskt visa och beskriva vad du har gjort där du visar de här egenskaperna. Ett exempel som jag tar upp är att jag ser mig själv som driven, och det visar jag genom att berätta om de kurser i retorik som jag har läst, för att bli av med ångesten jag hade när det gällde att prata inför folk.
  • Avsluta positivt! Jag avslutar mitt brev med att jag är sugen på att börja jobba, vad jag tycker är viktigt på en arbetsplats, samt en summering på mina (positiva) egenskaper.

De tre punkterna i mitten tycker jag man kan kasta om som man tycker passar. Jag tror att jag valde just den här ordningen för att det var lättare att börja skriva om just hur jag hamnade där jag är idag, än att börja med mina personliga egenskaper.

Det här blev ett väldigt långt inlägg i en serie av långa inlägg – hoppas du som läst ända hit har fått ut något matnyttigt av det! Jag tar nu julledigt och återkommer efter helgerna, fylld av julmat och pepp inför 2016.

God Jul och Gott Nytt År!

Hitta drömjobbet som IT-konsult (del 2 av 3)

Förra veckan skrev jag om hur du hittar drömjobbet genom att renodla vad du vill göra efter examen, och vad som är viktigt för just dig på en arbetsplats. Idag kommer ytterligare två tips som kan hjälpa dig på vägen, så du slipper ha ont i magen på söndagskvällen och leva enbart för helger och semestern. Eller för den delen tar din yrkeskarriär till nästa nivå – nöj dig inte med ett jobb som ”bara” känns okej, satsa på drömjobbet istället!

Fokusera på arbetsplatsen, inte tekniken

När jag började söka jobb var jag helt säker på att jag ville jobba med C#, .NET och webbutveckling. Jag var väldigt specifik i min plan, vilket gjorde att jag till en början var skeptisk till systemintegration, som jag har nämnt tidigare. Jag var till och med på en intervju hos ett annat företag, som rent teknikmässigt stämde mer överens med vad jag hade tänkt mig, men jag fick inte samma bra känsla i magen efter intervjun som efter den hos Integrationsbolaget. Detta gjorde att jag valde bort ett jobb med arbetsuppgifter som jag trodde skulle passa mig bättre, för ett jobb med en helt annan teknisk inriktning.

Det här kan låta som att det går emot det första tipset om att välja inriktning, men det första handlar snarare om att göra övergripande vägval om hur du vill att din karriär ska utvecklas och vad den ska leda till. Här menar jag att du inte bör vara låst i vilka tekniker du vill jobba med, eftersom du då kan missa drömarbetsplatsen bara för att de inte jobbar med x, y eller z. Min övergripande plan står fortfarande kvar; att börja med kodande och sedan ta mig an större ansvar i projekt, även om koden inte är C# och .NET utan främst SQL Server och BizTalk.

våg

Och jag ska erkänna en sak: i början av utbildningen hatade jag SQL. Jag tyckte det var otroligt svårt att få till rätt tankesätt och hade stora problem med att joina flera tabeller och att förstå hur aggregatfunktioner och nästlade underfrågor fungerade. Jag var helt säker på att jag aldrig skulle vilja jobba med databaser. Men under utbildningen och min tid som adjunkt fick jag bekanta mig mer med SQL, och i slutet av utbildningen började jag känna mig bekväm med databashantering. En av mina första, riktiga arbetsuppgifter blev sedan att göra om en lagrad procedur från en ny kravställning och ärligt talat – det var skitkul.

Det här är enligt mig det bästa tipset: lås inte in dig i specifika tekniker. Hitta en övergripande väg, men var sedan öppen för detaljerna. Det absolut viktigaste på en arbetsplats är inte om du kodar i Java eller C#, utan att du är på en plats där du trivs med människorna, värderingarna och rutinerna. Jag lovar att det inte är värt att jobba med ”rätt teknik” om allt annat på jobbet inte känns bra. Och kom ihåg: de flesta tekniker blir roliga när du kan dem.

Låt jobbet hitta dig

Det här tycker jag är ett jäkligt bra tips, men samtidigt det svåraste att kunna följa. För jag tror starkt att det är såhär: om någon eller några personer på en arbetsplats har träffat dig och läst ditt CV, och sedan anser att du skulle passa bra in i deras organisation så har de antagligen rätt. Det är lättare för dem att tillsammans se en individ som passar in, än det är för dig att få överblick över en organisation och avgöra om du passar in hos dem.

Puzzle-People

Hur gör man då för att få jobbet att hitta dig, istället för att behöva söka jobb? Det är inte helt lätt, och inget som görs i en handvändning sista veckan innan examen. Du måste odla kontakterna under hela studietiden och skapa ett nätverk av människor som känner dig i din studieroll, vilket troligtvis speglar hur du senare kommer bete dig i arbetslivet. Så, under studietiden bör du tänka på att:

  • Sköt dig under grupparbeten! Det finns människor vars namn jag har lagt på minnet för att slippa arbeta med dem i framtiden – de här som kommer för sent, inte gör sin del och bara glider med. Ingen vill jobba med en sådan person! Men gör du ett bra intryck kommer personer komma ihåg dig på ett bra sätt och kanske tänka på dig när det är dags för rekrytering.
  • Lär känna de du pluggar med! Var med på introduktionen, var aktiv på seminarier, plugga i grupp och ta den där tentaölen med kursarna. Ingen kommer att minnas dig om du aldrig var med.
  • Visa att du är grym! Försök ligga steget före, ställ frågor under föreläsningar och läs på ordentligt inför seminarierna. Om du pluggar på systemvetenskapliga programmet i Örebro finns det möjlighet att vara studenthandledare i de kurserna du tidigare läst, och det är en grymt bra erfarenhet, dels för att du lär känna personer som läser andra terminer men också för att du befäster dina kunskaper i programmering.
  • Var aktiv i din kårsektion! Förutom att det är en bra grej att ha på CV-t vidgar du ditt kontaktnät ytterligare och lär känna folk från andra ämnen på institutionen. IT-människor behövs i alla organisationer och kanske är det en ekonom som tipsar IT-avdelningen om ditt namn.

Under sista terminen, när det börjar bli dags att söka jobb, sprid ordet om att du är ute efter ett riktigt grymt företag att börja jobba hos. Ta inte första bästa erbjudande utan tänk till en extra gång och fråga: varför ska jag börja jobba hos er? Vad har ni att erbjuda mig? Du har en attraktiv utbildning med dig och en kompetens som är eftertraktad så våga ha is i magen!

Nästa vecka kommer de sista tipsen i den här serien, och de kommer bland annat handla om hur du ansöker till det där drömjobbet när du tror dig ha hittat det.

Hitta drömjobbet som IT-konsult (del 1 av 3)

Har varit sjuk hela veckan så bloggen ligger lite efter, men jag lovar att komma ikapp med ett gäng matnyttiga inlägg framöver!

Jag har nu jobbat på Integrationsbolaget i drygt tre månader. Provanställningen är över och det har gått nästan ett halvår sedan jag skrev på anställningsavtalet. Det har varit spännande, ibland svårt och nervöst, men framförallt otroligt kul att börja arbeta efter flera år på universitetet. Jag känner att jag hittat helt rätt och därför tänkte jag dela med mig av mina tips till dig som står i startgroparna och ska börja söka jobb som IT-konsult. Det blev sex tips och jag har delat upp dem i tre inlägg. Här kommer det första två, som handlar om att ta reda på vad som är drömjobbet för dig.

Vilken väg vill du gå?

Om du som jag har läst systemvetenskapliga programmet på Örebro universitet, eller motsvarande någon annanstans, har du säkert sett att det finns många olika aspekter på systemutveckling. Här gäller det att känna efter under de olika delkurserna: vilken väg vill du gå? Känner du att skolan är som roligast när du skriver kod? Eller vill du hellre jobba med kravhantering? Test? Affärsutveckling? Arkitektur? Projektledning?

crossroad

De flesta väljer kodvägen, och det är ofta det en börjar med som ny-exad, helt enkelt för att många andra yrkesroller kräver erfarenhet som programmerare, men alla gör inte det och det finns andra vägar att gå. Jag har haft kurskamrater som börjat jobba som kravanalytiker, testare, UX-designers och andra mer eller mindre svårdefinierade roller som inte har programmering som fokus.

Allt handlar om att försöka renodla vad du vill göra efter examen, så du vet vad du ska leta efter när det gäller drömjobbet. Jag bestämde mig ganska tidigt för hur min väg skulle se ut: jag vill börja med att skriva kod för att sedan utvecklas och ta mig an ”större” roller i projekt, arkitekt kanske, men jag vill alltid ha ena foten kvar i koden och inte tappa den delen av jobbet – för jag tycker den delen är förbannat rolig.

Vad är viktigt för dig i yrkeslivet?

Förutom att veta något om vilken typ av jobb du vill ha så behöver du också fundera på vad som är viktigt för dig i arbetslivet. Jag hade ett övergripande mål med mitt jobbsökande: att hitta ett jobb utan söndagsångest. Det här nämnde jag på anställningsintervjun med Integrationsbolaget och fick då motfrågan: vad ger dig söndagsångest då?

Det gjorde mig helt ställd: jag visste att jag ville ha ett jobb där måndag morgon inte kändes tung, men jag hade inte reflekterat över vad det faktiskt innebar. Efter en stunds funderade kom jag fram till att den största anledningen till söndagsångest hos mig är känslan av maktlöshet, av att inte kunna påverka min vardag. Detta kommer sig antagligen av att jag tidigare jobbat i en stor organisation i en annan bransch, med i princip noll möjligheter att påverka arbetet. Förutom möjlighet att påverka identifierade jag fyra pusselbitar som är viktiga för mig:

pussel

  • Fast lön, som inte är provisionsbaserad på antalet timmar man debiterar
  • Bra villkor för friskvård
  • Ordentligt pensionssparande (10 000 vuxenpoäng på denna?)
  • Möjlighet att styra arbetstiden och flexa i viss mån

Allt detta är förstås väldigt relativa värden, men jag tycker att jag har fått allt detta i jobbet jag har nu. Så, mitt tips är att ta en riktig funderare kring vad som är viktigt för dig, och kom ihåg att reda ut det från abstrakta värden till konkreta fakta som du kan kontrollera.

Ett bonustips:

Många IT-konsultbolag har inte något kollektivavtal, vilket gör att du kan få ganska dåliga arbetsvillkor om du har riktig otur. Jag tror inte det är vanligt, eftersom systemutvecklare är så pass heta på arbetsmarknaden och de flesta företag vill vara schyssta mot sina anställda. Enligt min erfarenhet så väljer man snarare bort kollektivavtalet för att kunna ge sina anställda bättre villkor, inte sämre, men tänk på att det enda som du har rätt till i de fallen är det som står i det anställningsavtal du har skrivit på. Läs igenom det noga och se till så att de grundläggande rättigheterna som semester, lön och villkor för övertidsersättning står med i detta.contract

Nästa vecka kommer ytterligare två tips! Har du några synpunkter eller åsikter kring det här inlägget? Lämna gärna en kommentar!

Försenad fredagsblogg!

Jag började egentligen skriva det här inlägget i fredags, men arbetsveckan tog slut innan orden gjorde det, så jag återupptar inlägget sent denna måndagseftermiddag. Anledningen till att veckan tog slut fort i fredags är att jag var i Stockholm under dagen och arbetade hos mina kollegor mitt på Drottninggatan, för att sedan skriva en certifiering i SQL Server. Dagen började bra med en kaloristinn pepparkakslatte på Starbucks (måste ju passa på när en är i storstan) och sedan en lunch med Stockholmskollegorna på Kött- & Fiskbaren, ett mycket trevligt lunchställe precis runt hörnet från kontoret. Som vanligt var jag alldeles för upptagen med att äta för att komma ihåg att ta ett kort på maten, men Norge-kollegan Lena (som ni kommer få veta mer om senare i veckan) lyckades iaf ta en bild där jag och Johan sitter och arbetar hårt.

20151120_105149

Det var mycket trevligt att sitta på Stockholmskontoret och jobba en dag, men jag var som sagt inte bara där för nöjes skull, utan jag skrev även en certifiering i SQL Server.

Vadå certifiering?

Jag ska ta det från början: Microsoft erbjuder flera olika certifieringar inom de olika plattformarna och teknikerna de har, och som konsult är det väldigt bra att ha en sådan för att visa på pappret vilka kunskaper en har. Jag nämnde det i mitt tidigare inlägg när jag skrev om BizTalkkursen, när jag skulle skriva en certifiering som inte blev av, och jag bestämde mig ganska snart efter det för att skriva ett i databashantering istället, nämligen SQL Server. Själva titeln är MCSA (SQL Server), Microsoft Certified Solutions Associate, och den får man efter tre test med olika inriktning. I fredags klarade jag det första deltestet, Exam 70-461: Querying Microsoft SQL Server 2012, som fokuserar på själva utvecklarbiten av SQL Server – att skriva kod för att kommunicera med databasen helt enkelt.

Hur gör man då?

Det finns säkert flera olika vägar en kan gå för att skriva ett sådant här certifieringstest, men vi gör det genom bolaget Addskills, som även anordnar utbildningar inom olika områden. Det går att boka certifieringar via deras hemsida (men lär från mig och dubbelkolla med Microsoft så certifieringen fortfarande finns kvar…) och de verkar kosta från 1900 kr och uppåt. Jag åkte ut till deras lokaler i Kista (blå linje mot Akalla med tunnelbana, tar ca 20 min från centralen) och väl där måste man skriva in sig, visa legitimation, bli fotograferad, läsa igenom massor av regler och lämna ifrån sig alla sina tillhörigheter. Utom kläderna på kroppen då. Som tur är. He. Därefter följer en testadministratör med en in i ett litet rum där det finns små bås med datorer och administratören berättar att det finns en filmkamera i taket och att testet är övervakat. Sedan är det bara att klicka på en startknapp på skärmen och testet är igång!

Var det svårt?

Ärligt talat…. Ja. Det var faktiskt sjukt svårt. När jag var mitt inne i testet var jag nära att ge upp. Eller, jag hade redan gett upp hoppet och tänkte att det här går aaaaaaaldrig, med min allra gnälligaste röst. Men uppenbarligen hade jag lite mer flyt än jag trodde, för när testet var klart så var jag faktiskt godkänd (även om det var på håret…). Direkt när testet är klart så visas resultatet på skärmen, så ingen nervös väntan på något resultat i flera dagar eller veckor.

Vad ska jag tänka på om jag tar en certifiering?

I samband med att en skriver testet så förbinder en sig att inte berätta något om innehållet eller frågorna, så jag kan inte ge några specifika råd, men jag har några tips som jag tror kan vara bra att ha med sig:

  • Plugga! Det finns en hel del böcker kring de olika certifieringarna, sök på certifieringsnumret på ex Adlibris så kommer du säkert hitta något. En del går bara igenom teorin, men andra kommer med tips och råd kring hur själva examinationen går till.
  • Gör gärna olika förberedande test, men lita inte på att de speglar det riktiga testet! Jag hade en skiva med övningsfrågor som var släppt av Microsoft själva, men inte heller det var speciellt likt the real deal.
  • Läs igenom informationen kring varje test så du vet vilka delar du behöver kunna!
  • Var beredd på de olika typerna av frågor som kan komma. Här finns en lista på de olika frågeformaten.
  • Se till att vara mätt och utvilad! Det är inte tillåtet att ta med mat in i testsalen, och även om vissa test har schemalagda pauser är det inte alla som har det. Jag hade ingen sådan paus, och om en isf väljer att ändå ta en så tickar klockan vidare under tiden. Jag brukar vara ganska snabb men hade inte haft tid att pausa.

Sådär, nu har jag lärt er allt jag kan (och får) om certifieringar! Fredagen slutade sedan med Klubb Katushka på Norrlands nation i Uppsala, men det mina vänner, är en helt annan historia. ;)

BizTalk Server 2013 – Developing Integration Solutions ELLER en utbildning i behovet av integration…

Det är med blandade känslor jag sitter här i hotellets lobby och reflekterar över veckan i Stockholm. Jag har varit på utbildning i AddSkills regi, nämligen BizTalk Server 2013 – Developing Integration Solutions. BizTalk Server är Microsofts integrationsplattform och alltså den programvara många använder för att implementera stora integrationsprojekt, och utbildningen var helt enkelt en crash course i de viktigaste delarna som ingår i BizTalk. Jag ska inte gå in djupare på kursens innehåll eller BizTalk nu, men för den som är nyfiken finns kursinnehållet här.

För att summera veckan: ja, det har varit en grymt lärorik vecka, men med både toppar och dalar. De flesta topparna och dalarna kan förklaras av detta:

20151015_145544

Ett aldrig sinande förråd av choklad har gjort att min blodsockerkurva liknat en seismograf under en jordbävning – hyperpigg ena stunden för att totaldäcka nästa. En lösning hade kunnat vara att helt enkelt inte äta av det. Jag valde den andra lösningen: äta hela tiden och vara i ett ständigt sockerrus. Det blir avgiftning när jag kommer hem…

Med tanke på att jag numera är Bloggare tvingade jag mina kära kurskamrater att vara med på bild, och jag har idag insett en sak om mig själv: jag är en värdelös fotograf. Ni ser ju nedan: fokus på helt fel ställen, kasst ljus och dålig vinkel. Den visar iaf datasalen där jag spenderat hela veckan tillsammans med ett härligt gäng människor från Sveriges alla hörn! Nåja, några av hörnen åtminstone, och ett par av dem är med via videolänk.

 20151015_144614

Det absolut bästa med kursen har dock varit snubben på bilden nedan.

20151015_144627

Han heter Alan Smith och har varit vår lärare hela veckan. En engelsman i Stockholm som kan allt värt att veta om BizTalk Server och systemintegration, och som dessutom delat med sig av sina erfarenheter av att använda BizTalk i olika projekt. Han har inte bara haft svar på alla frågor utan även kunnat förklara saker på ett tydligt och intressant sätt. När han i måndags började prata fick jag en otäck känsla av deja vu – hans röst lät läskigt bekant! Insikten slog mig ganska snart när han presenterade sig: jag har lyssnat på honom på Pluralsight. Han är dessutom MVP (Most Valuable Professional, mkt imponerande titel) för Microsoft sedan tio år tillbaks, och jag kan lugnt intyga att han är väldigt kvalificerad att leda en sån här utbildning.

Utbildningen har som sagt handlat om integration och idag, näst sista dagen, fick jag dessutom själv uppleva ett klockrent exempel på behovet av att integrera system med varandra.

Mitt mål med den här utbildningen har varit att ta en certifiering i BizTalk Server, en examination som ges av Microsoft och som sköts rent praktiskt av Addskills. I tisdags blev jag sugen på att göra ett försök redan den här veckan och så jag anmälde mig via Addskills hemsida för att göra testet. Jag fick en bekräftelse på att jag var anmäld och har ägnat varje vaken minut åt att plugga hela veckan. Jag såg tidigare på Microsofts hemsida att det var en notis om att just den här certifieringen var ”expired”, men tänkte inte mer på det – om det hade varit några konstigheter så borde ju någon ha reagerat på min anmälan till ett prov som inte finns. För säkerhets skull skickade jag ett mail till Addskills idag och frågade dem – och fick då till svar att nej tyvärr, den certifieringen finns inte längre. Jag läste mailet i chocktillstånd och gick till receptionen för att höra vad det var som hände. Och jodå, de beklagade sig, men tyvärr hade Microsoft tagit bort just den examen.

Tydligen fanns det ingen koppling mellan Microsoft och Addskills system för att administrera dessa tester, och personalen från Addskills måste manuellt gå in på Microsofts hemsida och se vilka tester som finns och sedan manuellt uppdatera sitt utbud. Nu hade ingen gjort det på ett tag och följaktligen hade ingen sett att just den här certifieringen försvunnit från Microsofts utbud. Det krävs inget affärssnille för att förstå att ett företag förlorar på sådana här misstag, och det krävs ingen integrationsexpert för att se möjligheterna att inte bara automatisera utan även förbättra de processer som finns här.

Nu vet jag såklart inte om Addskills redan har försökt med detta och att det inte är tekniskt möjligt, men jag tycker det är sjukt intressant när sådana här scenarion dyker upp och jag ser exempel i verkligheten där systemintegration skulle kunna tillföra stort värde för ett företag. Jo, jag blev såklart väldigt besviken också, då jag var helt inställd på att göra testet imorgon, menmen, det kommer nya tillfällen. Och nu fick jag ju möjlighet att sitta i hotellbaren med ett glas vin och skriva detta istället för att plugga… ;)

Language: