« Hem

Å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.

Vad är det bästa med att jobba som integrationskonsult?

Jag har skrivit ett par inlägg om de mer besvärliga delarna i jobbet, som tidsuppskattning och kravhantering, så nu känner jag att det är dags för något mer positivt! Därför har jag knåpat ihop en lista med de topp fem största fördelarna med att jobba som IT-konsult. En del av dessa är generella för jobbet som IT-konsult, andra är mer specifika för just systemintegration och Integrationsbolaget. Enjoy!

5. Lönen

Nej, pengar gör inte en inte lycklig. Men jag kan lova att bristen på pengar gör en olycklig som fasen. Relationen mellan lycka och inkomst ser ut ungefär såhär:

Bildkälla

När vi bara har precis så vi klarar oss är vi inte tillfreds, men pengar i överflöd är inte heller nyckeln till ett bekymmersfritt liv. En stor fördel med yrket som IT-konsult är att löneläget är riktigt bra, och jag skulle säga att min ingångslön ligger ungefär i början på komfortzonen. Om några år tror jag att jag kommer närma mig lyxsektorn, även om det såklart är en definitionsfråga. Kanske kommer jag anse att jag fortfarande ligger i komfortzonen då på grund av ökade utgifter…

4. Variationen

Seriöst – den här veckan har jag jobbat med SQL (oftast trevligt), C# (välbekant), PowerShell (mysigt), bat-skript (kallt, hårt och kort), kryptering (sjukt intressant), BizTalk (nya polaren), WCF (äntligen börjar jag fatta!) och WebSphere MQ (va?). Massor av skilda tekniker, där jag känner att jag behärskar en del av dem, samtidigt som andra är helt nya, och jag tror det är få jobb som kan matcha den här variationen i arbetsuppgifter.

568a3553a0d3ed3657475829471cf07d-networking-technology-iconsTill viss del är det här ganska generellt för IT-konsulter, eftersom branschen helt enkelt är så bred, men det är nog speciellt sant för jobbet som integrationskonsult. Nu har jag ju bara jobbat som just det i  den här branschen, så rätta mig gärna om ni tycker jag har fel, men jag tror att som ”vanlig” IT-konsult blir du betydligt mer nischad, och arbetsuppgifterna är inte lika mångsidiga.

(En parentes här till den som funderar på att börja jobba som IT-konsult är att inte vara rädd för ordet förvaltning! Jag tyckte själv att det lät vansinnigt tråkigt när jag pluggande, men nu sitter jag som en del i en förvaltningsorganisation, och det är faktiskt här det finns mest variation! Fast nu när jag tänker efter gäller det här nog mest integrationsförvaltning, variationen blir säkert mindre när man förvaltar ett specifikt system. Å andra sidan finns det kanske chans att bli riktigt vass på det systemet och göra sig oumbärlig i företaget…)

3. Förmånerna

Det här är förstås väldigt olika beroende på vart du jobbar, men mitt intryck är att som IT-konsult har du ofta bra förmåner på arbetsplatsen. Kompetensen inom systemutveckling är eftertraktad, och företagen måste göra sig själva attraktiva för att locka till sig (och behålla) anställda.

benefits square icon for web-larger

Jag är väldigt nöjd med de förmåner som jag har här på Integrationsbolaget. Det bästa är nog att få gymkortet betalt, och att vi har möjlighet att få massage på arbetstid. Jag kan dessutom använda min jobbtelefon som min privata, och slipper därmed räkningen för mobilabonnemanget varje månad, samt en bra pensionsavsättning. Vi har också möjlighet att leasa bil via företaget, något jag tycker är väldigt smidigt eftersom alla kostnader dras direkt på lönen.

2. Utvecklingen

Det här med att utvecklas på jobbet kan vara svårt inom vissa yrkesroller. Ofta kräver det att man byter arbetsplats, eller roll inom företaget, vilket kan vara tufft att få till, och det kräver en del förändring. Som IT-konsult har jag förändring varje dag, och även om jag är kvar på samma arbetsplats så finns möjligheten att växa och förändras hela tiden där, speciellt i början på karriären.

progress-report_318-35789

Jag känner att jag har utvecklats väldigt mycket sedan jag började här på Integrationsbolaget, mest vad det gäller mitt kunnande teknikmässigt, men också när det gäller konsultrollen. Det går aldrig att bli fullärd i det här yrket, vilket kan vara en frustrerande tanke, men det garanterar också för att du hela tiden kan utvecklas och bli bättre.

1. Friheten!

Det som toppar min lista på fördelar med konsultrollen är friheten i jobbet, och hur lyxigt det är att ha kontroll över sin egen tid. Jag har ju tidigare jobbat som undersköterska, och skillnaderna är enorma. Om du som uska jobbar ett pass mellan 07 – 14, då måste du jobba exakt de timmarna, och (åtminstone om du jobbar i hemtjänsten) så är din dag planerad minut för minut, och du har små möjligheter att ändra detta. Flextid och kompledighet är moderna myter som du hört talas om men aldrig praktiserat.

I jobbet som IT-konsult så är dessa fenomen inte längre myter, utan en del av arbetsdagen. Jag älskar att kunna träna på lunchen, och om det drar ut på tiden så stannar jag bara lite längre på eftermiddagen, eller att kunna jobba senare en dag för att gå tidigare en annan. Möjligheten att jobba från vilken plats som helst så länge jag har min dator och internetuppkoppling är också fantastisk, även om jag är bekväm av mig och helst sitter på kontoret med mina två skärmar och mitt sköna tangentbord. Men bara att möjligheten finns är otroligt upplyftande!

a0278d6ebd9591c39e398b65ed9c5dd9d7d6ea7686578f1088d41908c6b92ca4

För mig, som tidigare varit van vid att någon annan planerar min dag i detalj, så uppskattar jag det här otroligt mycket. Visst blir det svårare om du klättrar i yrkesrollen och får större ansvar, vilket alltid brukar innebära fler möten = fler tider att passa, men förhoppningsvis kan du styra tiderna på dessa, åtminstone till viss del. Och även om det bara handlar om halvtimmar hit eller dit, så har du en känsla av frihet och kontroll över din arbetstid, vilket tror jag är en av de starkaste grundpelarna för att vara tillfreds med jobbet.

 

Det svåra med kravhantering

Jag har ju tidigare skrivit om att det är jäkligt svårt att tidsuppskatta arbetsuppgifter när det gäller IT, och ytterligare ett problem som relaterar till detta är att hantera de krav som finns på den lösning som ska byggas. Till skillnad från  tidsuppskattningen är det här något som faktiskt tas upp i informatikutbildningen, så har du läst systemvetenskapliga programmet är du antagligen medveten om problematiken.

dilbertProblematiken simuleras i åtminstone en kurs där lärare agerar ”kunder” som plötsligt ändrar sig under ett projekt, och jag minns att många studenter blev irriterade på detta. I skolan är man inte van att nya saker dyker upp mitt under ett projekt, allt brukar (och ska enligt regler kring betygssättning) vara specificerat från början, så studenten vet exakt vad som förväntas. I yrkeslivet är läget dock ett annat, vilket lärarna i informatik gör sitt bästa för att förbereda studenterna på.

Jag tycker att de gör ett bra jobb med detta, men det är ändå otroligt stor skillnad att vara med om det i verkligheten. Problemet med att nya krav dyker upp från kunden är dock inte så stort för mig, eftersom jag mest jobbar med mindre, ganska avgränsade uppgifter som redan definierats. Det största bekymret för mig är snarare att förstå de krav som redan finns. För det mesta går processen till såhär:

  1. Jag får en uppgift, ofta specificerad via mail
  2. Jag tänker: jag fattar. Det här fixar jag direkt.
  3. Jag startar Visual Studio, BizTalk eller vad det nu kan vara för programvara som krävs
  4. Och tänker: men vänta här nu. Vad exakt är det som ska hända här egentligen?

Det som verkar så lättfattligt i mailet blir plötsligt betydligt mer oklart när jag ska börja skriva koden, och jag måste ofta gå tillbaks och ställa mer frågor för att kunna lösa uppgiften. Ju mer detaljer jag grottar ner mig i, desto fler blir frågetecknen och ofta visar sig uppgiften vara betydligt större och mer komplicerad än jag trott från början.

Varför är detta så svårt egentligen?

Jag har en teori och det är att IT är så otroligt abstrakt, både för den som ska använda lösningen, men också för den som ska programmera, innan denne har verkligen börjat koda. Ska man bygga en bro är det betydligt enklare: vi ska från punkt A till punkt B och eventuella problem längs vägen är betydligt lättare att förutse. Alla kan direkt se att en promenadbro över en liten bäck kommer vara betydligt enklare än en bro för biltrafik över en stor älv.

1tower-bridge

I IT är det inte lika enkelt: det som från början kan se ut som en promenadbro visar sig vara en klaffbro över ett vattendrag med båttrafik när kraven börjar analyseras. Det som från utsidan, och kanske främst från en användares sida, ser enkelt ut, är bara toppen på ett isberg av kod och komplexa beroenden, som ofta är svåra att förutse. Och framför allt: ingen skulle föreslå att man skulle bygga över Mälaren på ett par veckor, men inom IT händer det ständigt.

Jag har själv försökt mig på det – jag trodde att jag skulle kunna bygga en hemsida med ett eget CMS på några veckor, utan att inse de många timmar som ligger bakom ett administratörsgränssnitt som ex. WordPress. För att göra en lång historia kort: det gick inte alls. Det blev bara en hemsida och administratören fick administrera i HTML istället… Här har vi ett praktexempel på när en inte tillräckligt tydlig kravbild totalt pajar den tidsuppskattning som gjorts, och jag hade egentligen två val: öka tiden eller minska på kraven, och jag valde det senare.

Men, precis som med tidsuppskattning så går det att bli bättre på det här också! Ju mer man jobbar med en viss typ av lösningar, desto mer förförståelse får man för de olika delar som kan bli besvärliga, och man lär sig också att ställa mer och bättre frågor kring vad som ska göras. Man ser helt enkelt tydligare om det är en liten träbro eller en järnvägsbro som ska byggas, och kan anpassa jobbet därefter.

Nu har klockan slagit fem denna fredag, och jag lämnar er med den här klassiska bilden kring kravhantering. Det är möjligt att den är en sliten klyscha i sammanhanget, men den illustrerar ändå problematiken väldigt bra.

business-requirements-management

Trevlig helg på er!

Language: