Kategoriarkiv: Software

Confidence as a software engineer


Last year, I watched Running Girls, a Korean TV series where five K-pop stars go on a retreat to run, eat good food and share laughter and tears together. It is one of the most wholesome series I’ve watched and some scenes resonated well with me. For instance, let’s have a look at the time when Chuu talked about her confidence:

Chuu talking to her seniors about her confidence as a K-pop star

*Paraphrasing, starting from 1:30*
Chuu: I have something I wanna talk to you about. The more I perform on stage, the more my confidence keeps dropping. And the more I go on TV, the more my confidence keeps dropping.
Yooa: Why? What is bothering you?
Chuu: I don’t really know either… How should I put it… It feels like I’m not good at anything…?
Yooa: Why would think there’s nothing you’re good at? Just looking at you now, there are so many good things I see in you.
Chuu: 😭
*Cutscene to Sunmi*
Sunmi: Chuu reminds me of myself when I first debuted. I created my own limits. ”I’m not good at anything”. ”Does my team really need me?”

Even though my life is very different from that of a K-pop idol, I saw similarities to my own life in Sunmi’s words. The thoughts of feeling like a liability to the team and not being good enough could definitely emerge in my mind when I was starting out in my career. As I reflected upon my own feelings of confidence, however, it struck me that I’m currently feeling quite confident in my role as a software engineer. I wondered where my confidence came from and which experiences had taken me to the place I am now. As such, I decided to dig deeper into it.

Confidence according to the literature

I started out searching for resources about what confidence is and where it comes from. One of the difficulties with trying to learn more about confidence is that an abundance of doctors and charlatans alike seem to have written a book about it. So with limited time, which book should I read? Well, based on some good reviews and a doctor’s title, I went for The Gifts of Imperfection written by Brené Brown.

While the book is well written with an optimistic message, I did not get so much value out of it, possibly because I’m not an American, a mother or a woman. I noticed that among the books I decided not to read, many of them seemed to be targeted directly towards women. While the Gifts of Imperfection did not target women specifically, I made the mistake to read it translated into Swedish (under the title Våga vara operfekt). It wasn’t so much that the translation was bad, but the fact that another of Brown’s books, I Thought It Was Just Me (but it isn’t): Telling the Truth About Perfectionism, Inadequacy, and Power, was given the Swedish title Kvinnor och skam (Women and Shame) and I felt a bit excluded reading those passages where that book was referred to, in part because I’m not a woman and in part because I don’t think it is shame that limits my self-confidence.

To manage this supposed shame that people feel, Brown makes various suggestions: Let go of what other people think and your own thoughts of perfectionism. Play and relax. Cultivate work that is meaningful to you, even though it might not be valued by society. Cultivate your creativity. Laugh, dance and sing, and more. As for me, I think this blog has been a tool to manage many of those issues and virtues throughout the years I’ve written it, even though it takes continuous effort not to worry too much about other people’s opinions and not limiting myself in striving for perfection. I’ve also taken my fair share of dancing lessons so I’ve got that covered too. I should possibly laugh more, but sometimes what seems the easiest is the most difficult.

Two of the biggest takeaways I got from Brown’s book was a couple of reading tips. The first one was for Marci Alboher’s book One Person/Multiple Careers: A New Model for Work/Life Success, which I think is about indulging in not just one line of work but multiple. While I’ve yet to read the book, it intrigued me since I sometimes consider myself a software engineer/influencer hybrid. Surely, few people would put me in the influencer category and my career as a software engineer is certainly more successful, at least financially speaking, than my influencer side gig. Yet here I am, reaching you, the reader, by words on a screen as a result of purely intrinsic motivation for me to write them.

The second reading tip was for Carol S. Dweck’s book Mindset: The New Psychology of Success which delves into the differences between having a ”fixed mindset” and a ”growth mindset”. The two mindsets differentiate in terms of beliefs that intelligence and talents are something that we’re born with (fixed mindset) or something that can be developed (growth mindset). The book makes a strong case for the benefits of adapting the growth mindset, which see challenges and setbacks as opportunities for learning and eventually reaching your full potential.

My journey from fixed to growth mindset

When I was a student in what we in Sweden call ”Gymnasiet” (upper secondary school) I was taking Physics B, where the grade for the course was based on seven exams. I was thinking ”there’s no way I’m getting MVG (the highest grade) in four of the seven exams, so I can just chill and aim at getting four VGs (the middle grade) and three Gs (the lowest passable grade)”. Looking back, it seems like I had quite the fixed (or unmotivated) mindset back then, but I was able to follow through on my plan. Halfway through the course when I had achieved a 50-50 ratio of VG and G my teacher told me ”giving you a G would be a waste” and I fully agreed so eventually I got the four VGs to put me just above the threshold. So I graduated from Gymnasiet with my good but not great grades, convinced that I was good at languages, math and programming, and not so good at history, chemistry and physics.

I then enrolled at a two-year program in computer networks at Mälardalen University because it was ”short and close to home”, not the most ambitious reasons for choosing your education. Things went by smoothly and I never failed an exam because I was doing things I was good at.

After completing my studies in computer networks, I was able to land a job at Westermo as a software test engineer which in practice made me a full time python programmer, despite not having a proper education in software engineering. My colleagues (all with a MSc degree or similar) would patiently teach me computer science concepts like object-oriented programming and recursion and helped me figure out how git works. They became my heroes and role models, and during my time at Westermo I think I started to develop my growth mindset by seeing that I was able to learn these concepts that my colleagues had already mastered. I think I developed a little bit of imposter syndrome too, so I decided it was time for me to get that proper computer science education.

Going for a second take on university studies, the desire to study something ”short and close to home” had vanished and instead I fell in love with the idea of being a student at a prestigious university in Scotland. Long story short, the admission officials did not see my lax attitude during Gymnasiet as very meritorious:

REJ stands for rejected 😢 REJx4 meant ”git gud kiddo”

So, while my grades were not good enough to get me into computer science studies in Scotland, I was confident that I was up to the task since I had done a lot of python programming back then. Thankfully, Linköping University was happy to have me and thus I began walking the path on getting my MSc in computer science and software engineering.

During my first two years at LiU, I think I still employed a fixed mindset, thinking that there were certain things I was good at and things I was bad at. I had some kind of confidence that ”no matter how bad things are, I’ll never fail an exam” and even took pride in that fact, but looking through an old chat log I described my feelings during my second year at uni as ”Har känt mig lite otillräcklig, okunnig, dålig.” (I’ve felt insufficient, unskilled and inferior). I feel a little anger and disappointment seeing that I had those thoughts and how they probably limited me from reaching my full potential. Anyway, my slump would reach its climax as I began my third year at LiU.

In my fifth semester at LiU, I had courses in statistics, physics and AI—subjects I weren’t ”innately good at”. As the semester progressed, I failed my first exam ever (in statistics), got zero points at the physics exam, and had a mental lockdown when writing a paper on the AI technique Monte Carlo tree search hybrids. As for the AI paper, I actually had to use one of my get out of jail free cards by consulting two of the greatest problem solvers I know; I called dad and explained the situation (”I have no idea what to write, so I’m going to fail this”) who told me that he knew nothing about that but that I should call my friend Mikael. I called and, like a Sherpa in the Himalayas, Mikael helped me break down the insurmountable problem into manageable tasks and somehow I ended up with a top grade in that course, quite ironic. So, sometimes you don’t necessarily need the growth mindset to get out of a sticky situation as long as you have family and friends to help you out. However, my failures in statistics and physics made me realize that I had to go back to basics and really learn those subjects not to earn a specific grade but to get a proper understanding of what it was all about. It took a good portion of the summer of 2016 to figure things out, but I was eventually able to pass the exams with satisfactory results.

The setbacks I experienced during my third year at LiU put me closer than ever to give up on my studies, and instead pursue something else that ”I was good at”. Thankfully, I decided to persist and realized that I could succeed in subjects that weren’t my forte if I only put in some additional effort. That became the starting point of my growth mindset. A little over a year after having failed my first university exam, I wrote my list of Life Pro Tips which had ”Don’t give up until you’ve failed” and ”When you fail, improve and retry” placed at #4 and #5, respectively. I think that demonstrates at least the desire to have more of a growth mindset.

Nowadays, I strongly believe that I do have a growth mindset. The way it manifests itself is often through excitement and embracement of new challenges. As new opportunities arise, I ask myself things like ”do I have what it takes to work on this new project, hold a presentation to a large audience or learn Korean?” and the answer is usually ”Let’s find out”. Things typically don’t go perfectly but there are always lessons learned and some kind of improvement, and that’s a win in my book.

Other people’s impact on your confidence

Having read a couple of books and reflected on my own feelings of self-confidence, I’m thinking that while a lot of focus is put on you as an individual, the people around you have a significant impact on your confidence as well. Being at Sectra, where ”We hire for attitude & ability, train for skill” (which I think is a sign of the organization’s growth mindset) creates a culture of building each other’s self-confidence. Exactly how that happens is hard to explain, but I think there are some key ingredients.

  • Don’t penalize mistakes
    Mistakes happen at all levels of work, some are not that big of a deal while some cost millions. Having an attitude of accepting that mistakes happen and, when they do, making sure to put a lot of effort into making sure they don’t reoccur, is a forgiving and inspiring way to handle setbacks.
  • Be generous and honest when giving praise and constructive criticism
    My colleagues are great at cheering and rooting for one another, and making sure people know when they’re doing a great job. As for myself, I sometimes have a tendency of brushing off praise as ”they just want to make me feel better” which might be more of a self-esteem issue than a confidence issue. Either way, I think constructive criticism is just as important as praise, but it is a little trickier in doing it right. Honesty is super important here, as well as having the courage to request constructive criticism to show that you are open for change. I have some room for improvement in this area, but I think I’m moving in the right direction.
  • Value mentoring and knowledge sharing
    During my time with Sectra, I’ve had to dive into code bases that are old and vast and where I often find myself unable to see the forest for the all the trees. Luckily, I have mentors and colleagues with a lot of experience that are always happy to share their knowledge with me. While they probably could be doing things more efficiently on their own in the short run, having them show me their ways is both a long term insurance to the system’s longevity and a very fulfilling way of working. Jessitron wrote a nice piece on hyperproductive development regarding the pros and cons of ”10x development vs team development” which I think is worth a read.


As I get more experience under my belt, I hope I will not only be able to keep my own confidence at healthy levels, but also be a contributor to good self-confidence among my team members and colleagues throughout the company.

Has your level of confidence suffered or improved throughout your career? What events made it stifle or cherish? If you have thoughts on this, I’m eager to hear about them.


Last week I attended Øredev, a software developer conference hosted in Malmö. With 7 parallel tracks and 17 sessions per track there’s about as many ways to go through Øredev as there are synapses in the human brain. Speaking of brains, mine’s a bit fudgy after the intensive days of conferencing. Therefore, this post will be a bit all over the place, but can serve as a selection of my favorite talks.

Intro to Data Science

Dalya Gartzman held a wholesome presentation on how to get started with Data Science. Through her demonstrations of her own creations, she made it not only seem possible but also very fun to get into the field. If you want to get started with Data Science, have a look at the talk from Dalya or head straight into the resources she presented: word2vec, CS231n, Keras, PyTorch.

Creating Escher paintings using Elm

Another inspiring talk was the one by Einar Høst. As a fan of Gödel, Escher, Bach by Hofstadter, the mention of Escher caught my attention and on top of that Elm is an interesting language. In my notes, I wrote ”What is going on?” and not much more as I had a hard time following the live coding experience. That being said, creating the Escher-inspired art did not require a huge amount of code and I did appreciate the aesthetically pleasing end results. Thankfully, there’s an online workshop available which I hope to go through some day.

TDD in JavaScript

The author of The Art of Unit Testing, Roy Osherove, is writing a new book on TDD with JavaScript. Starting off with the opening line ”Jeg snakker litt norsk”, Roy was a fun and entertaining speaker, with interesting thoughts and opinions:

  • Random input to a unit test is a bad idea, as it requires calculation of the outcome
  • He’s a happy Wallaby customer. Wallaby is a JavaScript TDD tool which indeed looked nice with its fancy colors and instant feedback.
  • Test your test by writing failing production code before writing the final, working, code.
  • VS Code is nice, IntelliJ is better

If you’d like an alternative to Osherove’s books, I’d recommend Obey the Testing Goat by Harry Percival. It’s free for online reading, open sourced on GitHub and covers git and deployment in a good way.

Product Owners – An Impossible Task?

Allan Kelly started off by asking the audience ”Raise of hands – How many of you are working with a PO?” Almost everyone raised their hand. ”Okay, and how many of you think you’re working with an excellent PO?” Almost everyone took their hand down… So that felt a little awkward. Allan then continued on explaining why the task of a PO is almost impossible, and how the task can be made feasible. For details, his talk is available on Vimeo and he’s written a blog post on the topic.

Thanks to the talk, I learned a new english term: ”dogsbody”, meaning someone who does drudge work. (which a PO shouldn’t be doing.) Drudge work would probably translate to ”hundgöra” in Swedish. Øredev had their own dog, Øredev Øredevsson, present during parts of the conference which I unfortunately never had the chance to see.

Scrum Metrics

Stephanie Gasche talked about how to quantify the work of a scrum master. Since I don’t have a Scrum master in my team, I had to take out bits and pieces from the talk and apply it to my own situation. One of the proposed metrics was an interruption tally to keep track of how many times a developer gets interrupted during a day. Since interruptions seems to be something that builds connections/culture/comfort at my workplace, the goal should perhaps not be to avoid interruptions but rather improve the quality of them.


Erlend Oftedal (maintainer of retire.js) presented various ways of attacking a modern web app. A little scary, but interesting. He presented a couple of ways to keep up to date with recent hacking activity, namely by following https://hackerone.com/hacktivity and https://twitter.com/disclosedh1. The attacks included XSLT exploits, template injection, web cache poisoning and much more.

Online Communication

Dr Joanne Meredith presented interesting findings from her studies of online communication. How great is it that smileys, emojis and GIFs have helped us manage the otherwise missing queues of body language in instant messaging. This was probably my favorite talk during the conference (tied with Yuri Malishenko’s talk on Visual thinking) as it brought up many familiar situations I come across in my everyday life of communicating online.

Advent of Code

Eric Wastl comedically explained how his estimate of number of users (70) for Advent of Code turned out to be totally wrong as the project got 5000 users in the first few days and now have grown to hundreds of thousands or so. Eric’s talk was quite timely as advent is just a couple of weeks away. I did a couple of problems last year, and hope to give it another go this year. If you wanna join forces, let me know!

In Conclusion

The best part about Øredev was probably not the conference in itself, but getting to enjoy it together with my colleagues. Being able to have someone to discuss the latest talk with, and relate it to how things work at our own company, made the experience so much richer. I’m very grateful for the amazing people at this awesome company (that being Sectra if you didn’t know already) that I work for.

  • Food 3/5
  • Entertainment 4/5
  • Organization 5/5
  • Will I recommend Øredev to my friends? Yes, in 9 out of 10 times.

Force Feedback

Första gången jag stötte på programmering var i gymnasiet då min klasskamrat visade mig hur man kunde programmera i BASIC på min TI-84 Plus. Sedan dess har över tio år passerat och genom åren har jag fortsatt fördjupat mig inom programmering. Jag har insett vad som främjar min inlärning på bästa sätt och kommer i det här inlägget beskriva den inlärningsprocessen och dra paralleller till arbets- och studielivet.

Learn, Code, Get Feedback (LCGF)

För att bli världens bästa programmerare behöver man bara följa tre enkla steg. Processen  kanske påminner om LEAN Startup-metodiken men en större skillnad är att ”Measure” är utbytt mot ”Get Feedback”.

Learn, Code, Get Feedback. Process för att lära sig programmering.

Trestegsprocess för att lära sig programmering.

Det första steget i processen är Learn. Detta innefattar alla olika sätt som finns för att införskaffa sig kunskapen som behövs för att programmera. Det kan till exempel handla om att läsa en tutorial eller lyssna på en föreläsning.

För att befästa kunskaperna man fått i Learn-steget behöver du aktivt tillämpa dem på egen hand. Detta sker i Code-steget och det är här du utför själva programmeringen.

Det avslutande steget i cykeln är ”Get Feedback”. Liksom Learn-steget kan detta ske på ett flertal sätt. Bland de enklaste sätten hör datorns eget sätt att ge feedback när du kör din kod, kanske fungerar ditt program som du tänkt eller så kraschar det och du får en felutskrift. Andra typer av feedback kan vara statisk kodanalys, exekveringstider och kanske det bästa av allt, ett omdöme från en mer erfaren programmerare om din kod.

Feedbacken som ges kan förhoppningsvis användas för att lära dig mer om programmering och ett nytt varv i cykeln påbörjas. Efter ett antal varv i loopen har du blivit världens bästa programmerare, nice!

LCGF tillämpad i arbetslivet

När jag arbetade på Westermo använde jag, inofficiellt och outtryckligen, LCGF i stor utsträckning. Eftersom jag var blott en nätverkstekniker bland kodproffs och gavs arbetsuppgifter som innefattade programmering var jag tvungen att lära mig programmering illa kvickt.

Jag minns särskilt två milstolpar som var viktiga i min utveckling som programmerare. Den första var när jag skulle skriva ett autotest med hjälp av Westermos testramverk som var objekt-orienterat och skrivet i Python. Jag hade begränsad erfarenhet av Python och objekt-orientering hade jag läst om men aldrig förstått vad det var bra till. Som tur var fanns min kollega Tobbe tillgänglig för att hjälpa mig komma igång och när han frågade nåt i stil med ”Har du jobbat med objekt-orienterad programmering?” kunde jag ärligt svara ”Nej” och fick sedan en kort introduktion av de viktigaste koncepten. Direkt därefter fick jag själv prova mina vingar och skriva lite kod på egen hand. Då jag stötte på problem kunde jag oftast ropa på hjälp och få feedback på min kod och tips på hur jag skulle komma vidare.

Den andra milstolpen var då jag arbetade med testsystemets hantering av ”test suiter”, där en test suite är en samling av tester som ska köras. En test suite definierades i form av en textfil som kunde innehålla antingen andra test suiter eller enskilda test. ”Test suiter som består av test suiter? Oh baby that’s recursion!” kanske några tänker men det gjorde inte jag eftersom jag aldrig hört talas om rekursion. Den gången fick jag ta hjälp av min kollega Fredrik som introducerade konceptet och gav lite exempel med Quicksort bland annat. Därefter kunde jag knacka ihop en rekursiv metod som gick igenom suite-filer och hämtade ut de enskilda testerna som fanns listade. Jag fick även feedback på min lösning efter att jag tillsammans med Fredrik gått igenom koden jag skrivit. Det var en givande arbetsdag!

Min poäng är att på Westermo arbetade jag oftast i korta cykler av LCGF där jag fick en uppgift, var tvungen att lära mig nya saker från kollegor eller genom Internet, tillämpade kunskaperna genom programmering av den specifika uppgiften och kunde därefter få feedback på mitt arbete genom att be någon kika på min commit. Det är utan tvekan det mest effektiva sättet för mig att lära mig programmering på som jag någonsin upplevt. Så vad fick mig att sluta? Ett flertal faktorer bidrog till att jag inte lärde mig nya saker i samma takt och möjligheten till feedback minskade, dvs ”Learn” och ”Get Feedback”-stegen blev lidande. Detta fick mig att leta efter alternativa sysselsättningar och där hade en utbildning på LiU länge funnits med i planerna. Inom kort var jag student på civilingenjörsprogrammet i mjukvaruteknik vid Linköpings Universitet. Låt oss kika på hur LCGF tillämpas där.

LCGF tillämpad i studielivet

Många kan nog föreställa sig hur LCGF kan kopplas till studierna. Under en kurs lär man sig typiskt nya koncept och tekniker som presenteras under föreläsningar eller genom kurslitteratur. Studenten får tillämpa dessa kunskaper genom laborationer där hen oftast skriver egen kod för att lösa någon uppgift. Koden redovisas och lämnas in för granskning vilket sedan resulterar i någon form av feedback, till exempel får vi studenter betyg (Godkänd eller 3, 4, 5).

Förutom betyget finns även möjligheten för labbassistenten att ge sitt omdöme på koden. Det kan till exempel se ut som på bilden nedan, som visar feedbacken jag fick på min inlämning av ett Tetris-spel jag gjorde i Java-kursen för ganska exakt tre år sedan.

Detaljerad feedback på mitt tetris-spel.

Ett exempel på bra och väldetaljerad feedback.

Förutom bristen på styckeindelning är jag supernöjd med den feedback jag fick och jag lärde mig nästan lika mycket från den som jag gjorde av att utföra själva uppgiften i sig. Under mina år på LiU har jag dessvärre insett att feedbacken ovan är ett undantag från hur det brukar se ut. Låt oss ta en titt på hur feedbacken såg ut från en kurs jag läste i höstas. Kursen var i princip en enda lång labbserie och jag arbetade ensam vilket bidrog till att det var extra svårt att veta om jag gjorde på rätt sätt eller inte.

Ett exempel på mindre bra och odetaljerad feedback.

Ett exempel på mindre bra och odetaljerad feedback.

Även om jag är glad över att koden bedömdes som snygg är jag ändå missnöjd över att inte få veta vad som var särskilt bra och vad som kunde gjorts bättre. Inget ont om labbassistenten i fråga, han är inte ensam om att ge sparsam feedback och är i övrigt väldigt kunnig och engagerande, men jag känner att bristen på feedback har fått min utveckling som programmerare att stagnera. Jag programmerar i princip på samma sätt som jag gjorde för tre år sen i Java-kursen och blir godkänd varje gång men jag får aldrig veta vad jag kunde gjort bättre.

Någon kanske hävdar att om den enda kommentaren var ”Snyggt!” så fanns det inget att anmärka på och jag borde vara glad istället för att gnälla. Men är det något jag lärt mig under dessa år med programmering så är det att kod aldrig är perfekt skriven. Om någon vill bevisa motsatsen är jag idel öra.

En önskan om bättring

Varför är det viktigt att jag som student får feedback på min kod? Tja, förutom den uppenbara anledningen att jag lär mig bättre så är det också ganska vanligt att mjukvaruföretag i dagsläget använder kodgranskning som en del i utvecklingsprocessen där kollegor granskar varandras kod. Att som student förberedas på att ens kod ska läsas av andra och även få kritik på den kod man producerat är inget som bör underskattas eftersom det kan vara lite känsligt till en början. När jag pushar kod på min arbetsplats kommer inte kvaliteten enbart bero på om koden ger rätt resultat utan också om vägen dit sker på rätt sätt.

Det är möjligt att det skulle kräva ökade kostnader eller åtminstone ökade resurser för att ge studenterna bättre feedback men eftersom trenden verkar vara att föreläsningar ersätts med digitala motsvarigheter (videoinspelade föreläsningar osv) är mitt förslag att de pengar som sparas där istället läggs på rättning och granskning av kodinlämningar.

Jag tycker också att det borde vara i universitetets intresse att lägga lite krut på den här delen av utbildningskvalitet, om inte annat så för att höja konkurrenskraften. Jag har till exempel sett hur en av Udacitys kurser i machine learning lockar med ”1:1 feedback” i form av kodgranskning. Ett annat alternativ om man inte vill betala är förstås Stack Exchange’s Code Review som kanske inte håller den högsta kvaliteten men ändå bidrar med något mer än ett ”Snyggt”.

Om min poäng inte varit tydlig nog hittills så kan jag försöka förtydliga min åsikt: Universitet måste ge studenterna bättre feedback på deras inlämningar. Det gäller särskilt inlämnad kod men kan även sträcka sig till rapportskrivning. Examinatorerna bör uppmuntra detaljerad feedback, följa upp vilken typ av feedback som labbassistenterna ger studenterna och sätta tydliga riktlinjer för vilken feedback som förväntas ges. Jag tycker det är motsägelsefullt att jag längtar från universitetet ut i arbetslivet för att jag ska lära mig programmering bättre. Jag pluggar mjukvaruteknik på LiU för att komma närmare målet som världens bästa programmerare, men ibland känns det som jag endast kommer komma härifrån med en civilingenjörsexamen. Vore inte det tråkigt?

Jag har inte hört så många andra dela min uppfattning i den här frågan, men jag har å andra sidan inte öppnat upp för diskussion förrän nu. Om du som student/labbassistent/examinator inte håller med mig vill jag jättegärna diskutera vidare, så det är bara till att gå loss i kommentarsfältet eller kontakta mig på annat valfritt sätt! 🙂

Boktipset: The Psychology of Computer Programming

I höstas läste jag kursen TDDD30 Avancerad programutvecklingsmetodik. I kursen ingick att läsa The Guide to Software Engineering Body of Knowledge (SWEBOK Guide) vilken är en sorts guide till nästan varje ämne inom Software Engineering. Eftersom kursens deltagare hade olika bakgrund var det upp till varje student att själv välja vilka delar som denne skulle läsa. Jag läste förmodligen mindre än jag borde gjort, men i kapitel 11 som behandlar gruppdynamik, psykologi och kommunikation fanns en referens som väckte mitt intresse. Det var Gerald M. Weinbergs The Psychology of Computer Programming som också är ämnet för det här inlägget.

Framsida av boken The Psychology of Computer Programming

Struktur och indelning

The Psychology of Computer Programming utgavs ursprungligen år 1971 men som ni kan se på bilden läste jag silverbröllopsutgåvan, utgiven 1998, där varje kapitel utökats med författarens kommentarer som han skrivit 25 år senare. Boken är på många sätt ett historiskt dokument över hur programmering och mjukvara framställdes på 70-talet och eftersom industrin genomgått stora förändringar sedan dess uppskattas de mer aktuella tankarna från 90-talet. Allra bäst vore om det funnits en gold anniversary edition men den har tyvärr inte givits ut.

Boken är uppdelad i fyra delar som i sin tur är uppdelade i kapitel. I slutet av varje kapitel ges en bibliografi för vidare läsning och det ställs frågor till läsaren. Frågorna är riktade till antingen programmerare eller chefer som bossar över programmerare och bidrar till att läsaren kan applicera materialet till eventuella egna situationer.

Nedan följer mina personliga utsvävningar från några av bokens kapitel. Om ni tycker saker verkar tagna ur sitt sammanhang är min rekommendation att ni läser boken, den är bra!

Chapter 1: Reading programs

Redan i bokens första kapitel blir det uppenbart att boken är skriven för mer än ett halvsekel sedan. Det kodexempel som ges är skrivet i programmeringsspråket PL/I, vilket jag sedan tidigare inte ens visste var ett programmeringsspråk. Språken som används i boken är oftast FORTRAN och PL/I och det känns ibland ganska avlägset. Som tur är handlar det mesta i boken snarare om psykologi samt människor och eftersom människan inte förändrats lika mycket som programmering under de senaste 50 åren har boken åldrats med värdighet och fungerar än idag.

Chapter 2: What makes a good program?

Kapitlet tar upp och jämför faktorer som uppfyllelse av krav, leverans enligt tidplan, anpassningsförmåga och effektivitet. Weinberg levererar en rolig anekdot som cementerar det faktum att om programvaran inte fungerar är prestandan (och andra krav) irrelevanta.

Chapter 3: How can we study programming?

Ett intressant fenomen som försvårar observationsstudier är Hawthorneeffekten som innebär att subjektet för studien omedvetet förändrar sitt beteendet på grund av att hen vet om att hen blir observerad. Slutsats: Det är svårt att utföra psykologiska experiment!

Chapter 4: The programming group

Weinberg myntar i detta kapitel programmeringsmetoden egoless programming och argumenterar för hur mycket bättre allt blir om man tar bort sitt ego ur mjukvaruproduktionen. Dessutom nämner han hur John von Neumann ”was constantly asserting what a lousy programmer he was” vilket var helt annorlunda mot vem jag föreställt mig att von Neumann var. Jeff Atwood har ett läsvärt inlägg om egoless programming på sin blog coding horror.

Chapter 5: The programming team

Två intressanta uttryck i detta kapitel:

  • Parkinsonianism
    Parkinsons lag kan formuleras: ”Ett arbete kommer uppta den tid som är avsatt för ändamålet.” Det blir alltså väldigt svårt att konstruera en tidsplanering (med nödvändig ”slack” ifall något går galet, vilket det alltid gör) om arbetet kommer expandera utifrån planeringen.
  • ”Call to the cloth”
    Jag vet inte riktigt vad det betyder, men det verkar ha nåt med tro och religion att göra. Hör av dig om du kan förklara dess betydelse för mig. 🙂
    Uppdatering 2017-02-06: En av mina kunniga läsare hörde av sig och gav följande förklaring till uttrycket: ”Det betyder kallelse till präst. The cloth syftar på själva prästkåpan.” Förklaringen passar väl in i bokens kontext där Weinberg ger exempel på orsaker till förlust av gruppmedlemmar befordran, uppsägning, sjukdom etc.

Chapter 6: The programming project

Ganska ofta i boken berör Weinberg ämnet (bristen på) kvinnor i mjukvaruindustrin. Under 70-talet var könsfördelningen inom branschen ungefär som jag känner igen den idag; ca 90% män. I boken nämns som hastigast hur detta ändrats under sent 80-, tidigt 90-tal och blivit mer jämlikt. Weinberg beskriver hur det var enklare att bilda stereotyper av kvinnliga programmerare då de var få men att dessa stereotyper upplöses då de blir mindre sällsynta.

I samband med att jag läste detta såg jag även dokumentären Genusbuggen (eng. titel Code: Debugging the gender gap) som trots att den var väldigt amerikansk var klart sevärd. Detta fick mig att fundera hur könsfördelningstrenden i Sverige ser ut idag och därför gjorde jag en liten undersökning. Utifrån sökstatistik från UHR plottade jag andelen kvinnor som sökt till civilingenjörsprogram i datateknik under perioden 2008 till 2016. Resultatet finns att ta del av i ett Google Spreadsheets-dokument eller, om ni inte är intresserade av data-underlaget och interaktion med diagrammet, i bilden nedan.

Resultat över andel sökande kvinnor till civilingenjörsutbildningar i datateknik i Sverige år 2008 till 2016.

Med försiktig optimism vill jag ändå påstå att det är en positiv trend vi ser, heja heja!

Chapter 8: Personality Factors

Weinberg tar upp ett flertal typer av personlighetstester, men det är inte förrän i 25-årskommentarerna som Myers-Briggs Type Indicator (MBTI) kommer på tal, helt enkelt för att MBTI presenterade först 1980. Av en tillfällighet hade jag, i TDDD30, läst en studie om parprogrammering som kritiserat MBTI och istället rekommenderade IPIP-NEO. Personligen föredrar jag nog ändå MBTI, om inte annat så för att man på https://www.16personalities.com enkelt kan testa sig och även se vilka kändisar som delar ens personlighetstyp. Enligt mitt testresultat har jag samma typ som Neo i Matrix så helt kasst verkar inte MBTI vara. 😉

Chapter 10: Motivation, Training, and Experience

Jag gillar de frågor författaren riktar till cheferna i det här kapitlet. ”Skyddar du dina programmerare från att arbeta för mycket? Avundas du deras entusiasm till deras arbete? Uppmuntrar du dem till att arbeta på det sätt som passar dem bäst? Får de jobba hemifrån och ha flexibla arbetstider? Uppmuntrar du till fortbildning?” Vissa frågeställningar kan tyckas banala men kapitlet och stora delar av boken tydliggör skillnaderna mellan chef och programmerare och de utmaningar som kommer med dessa.

Part 4: Programming Tools (Chapter 11-13)

I bokens sista del gör sig 70-talet påmint igen: ”... although the assembly programmer may scoff at the machine-language programmer, he may be in turn the object of amusement for the user of a language with macro facilities.” Hela part 4 är väldigt old-school och låg-nivå och jag har ofta svårt att sätta mig in i situationer som handlar om hålkort, COBOL och obskyra operativsystem. Ett avsnitt ”Time sharing vs batch” minns (och förstod) jag ingenting av.


The Psychology of Computer Programming var fram till de sista tre kapitlen, då bokens ålder blir alltför påtaglig för mig, en mycket underhållande skrift. Weinberg bjuder på en uppsjö av roliga anekdoter som får en att känna igen sig och reflektera över sitt eget och sina kollegors beteende. Den är relevant både för programmerare och chefer till programmerare och även om vissa lärdomar kan tyckas triviala (t.ex. en programmerare med tandvärk presterar inte så bra han/hon kan) finns det många viktiga aspekter att diskutera och reflektera över, för programmering handlar förstås om mycket mer än vilket språk vi skriver i.

Betyget blir tre av fem riviga rävar.


Den här julen har jag för första gången under min studietid på LiU haft jullov på riktigt. Med det menas att jag inte behövt plugga inför några januaritentor alls, vilken lyx!

Denna möjlighet att spendera julen med att göra precis vad jag velat har resulterat i en app jag kallar math-quiz. Framtagandet av math-quiz har inkluderat både programmering och matematik, så lustigt nog blev det inte alltför stor skillnad mot tentaplugget. Många kanske undrar varför jag valde att skapa math-quiz och hur det gick till på vägen. Därför tänkte jag försöka besvara dessa frågor med just det här inlägget.


Något som ofta nämns i samband med civilingenjörsutbildningar är hur matematikintensiva de är. I examenskraven för civ.ing. i mjukvaruteknik står att minst 45hp kurser inom matematik eller tillämpning inom matematik ska ingå i utbildningen. I min utbildning sprids dessa 45hp ut i början på utbildningen och därmed är det examenskravet uppfyllt redan efter de första tre åren.

När jag nu gick första terminen på det fjärde året märkte jag en ganska stor förändring i det att jag inte längre läste någon mattekurs med föreläsningar, lektioner, frustration och allt det roliga som det innebär. Det var inte helt utan obehag som jag insåg att kurserna jag valt (designmönster, mjukvarutekniskt entreprenörskap, interaktionsprogrammering, etc) inte krävde några matematikkunskaper över huvud taget. Jag blev fundersam över om jag läst all matematik helt i onödan. Än värre, jag slogs av tanken att mina hårt förvärvade matematikkunskaper sakta skulle förvittra utan underhåll. ”Not on my watch” tänkte jag och började klura på hur jag kunde hålla igång mattekunskaperna på bästa sätt. Jag gillar quizar och tipspromenader så om jag kunde kombinera detta med en webb-applikation skulle det bli perfekt uppvärmning inför kurserna i webbprogrammering som jag ska läsa nu till vårterminen.


Jag började med att googla på ”JavaScript quiz library” och fick en träff på en React-baserad lösning kallad JavaScript Quiz som utgjorde en perfekt grund att bygga vidare på. React är ju dessutom väldigt poppis och jag såg fram emot att lära mig mer om det. Jag var till och med så optimistisk att jag trodde det skulle gå snabbt och enkelt att skapa min matte-quiz. I själva verket skulle det gå långsamt och svårt, men det är ju förväntat när man ger sig ut på okänd mark.

Grafer ❤

Tidigt i processen fick jag en idé om att jag ville presentera resultatet från quizen som en spindelgraf. Alltså, användaren besvarar frågor inom olika matematiska områden och får därefter en tydlig bild över dennes kunskap inom de olika områdena.

I min grupps kandidatprojekt Knekt använde vi oss av Highcharts med stor framgång. Jag körde vidare på det vinnande konceptet och efter några npm-installationer (react-highcharts för grundfunktionalitet och highcharts-more för spindeln) och en del bök lyckades jag smälla upp en fet graf som ni ser på bilden nedan.

Spindelgraf över resultatet från en omgång av math-quiz.


Jag ville utöka funktionaliteten från den mycket enkla JavaScript Quiz och gjorde en Settings-sida där användaren bland annat kan välja vilka matematiska områden och hur många frågor quizen ska innehålla. Detta var ganska straight-forward med undantag för att jag valde att använda mig av react-numeric-input för lite enklare hantering av antal-frågor-väljaren. Jag skriver ”ganska straight-forward”, men med mina obefintliga kunskaper inom React ger bilden nedan en rättvisare beskrivning. Det är dock förvånansvärt hur långt man kan komma med Google och Stack Overflow. 😉

I have no idea what I'm doing dog

All I want for Quiz-mas is a nice little matrix

Efter allt strul med Settings-funktionaliteten var det dags att få till lite schyssta matte-frågor. För detta krävdes ett snyggt sätt att representera matematiska formler, integraltecken och matriser. Självklart ville jag använda mig av Latex, men det skulle visa sig vara en mycket hård nöt att knäcka. Jag började med att prova react-latex och react-matrix, men det var inte alls vad jag behövde. När jag snubblade över react-katex trodde jag att jag hittat den heliga graalen. K:et i katex står för Khan som i Khan Academy som jag tidigare haft stor användning av. Deras latex-lösning skulle definitivt duga för mig, dessutom ritas formlerna snabbt utan lång väntetid. Tyvärr lyckades jag aldrig få katex att fungera på rätt sätt utan mina formler ritades ut både TeX-ifierade och som vanlig text, mycket likt detta issue på GitHub. Jag slet i en dag med det men lämnade till slut Katex för en motsvarande lösning, MathJax.

MathJax fungerade! Tyvärr sker en liten fördröjning vid utritningen och av en outgrundlig anledning minskas dess font-storlek efter första frågan så texten blir lite för liten. Men ingen mjukvara utan buggar tänkte jag och valde att släppa math-quiz lös på internet.

Framtida arbete

För dig som tycker att math-quiz verkar intressant och vill bygga vidare på det finns projektet på GitHub. Förutom att fixa visuella buggar och snygga till GUI:t vore det även nice med fler frågor och utökad funktionalitet. Har du feedback eller vill bidra till math-quiz är jag idel öra!


Jag är tacksam över att kunna stå på de giganters axlar som skapat React, npm och alla små fina paket för formler, grafer, etc. WebStorm är en bra IDE, webbprogrammering är svårt och solo-programmering kan vara ganska jobbigt om än lärorikt.

För övrigt tänkte jag nu försöka ha jullov på riktigt. God fortsättning!

STEW 2016

This week I had the pleasure to participate in Swedsoft‘s Software Technology Exchange Workshop (STEW) and it was a blast! Or at least it was very informative, the food was great and the people were friendly. I listened to almost 20 different talks on various topics on software engineering so now I’m filled up with knowledge. 😉

To be able to digest all this knowledge I thought I could write down the most memorable notes I took and give some comments where needed. Of course, these notes, paraphrases and comments will only be a drop in the gravy ocean from STEW. Text in italics are things I thought I heard while unformatted text are my own comments and explanations.


It is all software. The electronics and mechanical engineers are lost! – Words from a CTO of a big company. Said with tongue in cheek, but gives a somewhat accurate description of how  some hardware industries are becoming more dependent on software.

Featuritis – 70-80% of features in the product are never used!

Model based [testing/development/systems engineering] – A trend during STEW was to talk about making all things model based.


Sensors everywhere!

25.2 Gbit/s throughput – From an Ericsson experiment performed in Barcelona.

100x higher rate, 1000x higher volume, 5x lower latency, 100x more devices! –
Compared to, I assume, 4G.


The Eiffel framework was originally developed by Ericsson. It is a framework that ”enables technology agnostic enterprise scale continuous integration and delivery.”

Every change in a software project is an event.

Events hold references to other, previous events. This creates a real time directed acyclic graph.

Eiffel is used to document what we did, who did it, why we did it and how we did it.

With Eiffel you may store, analyze and visualize the documentation.

Eiffel is available on GitHub!

Jan Bosch – The hurricane

Mr Bosch spoke about speed, data and ecosystem. Focus was on speed, and he spoke very fast.

Increasing speed trumps any other R&D improvement! Speed beats efficiency every time.

Speed: … the ability to quickly respond to events, such as requests from customers, changes in the priorities of the market or new competitors, is critical to continued success. As the rate at which companies need to be able to respond is accelerating constantly, speed is a key factor. [1]

Facebook started in 2004 and gained 50M users in 44 months, Angry birds was released in 2009 and gained 50M users in 1 month!

Continuous delivery is for fegisar! – Not sure what this was about, but it spurred a lot of laughs.

Candy crush analyzes player behavior to increase revenue. – Is the player stuck? Is he/she likely to make a purchase to get unstuck? Use user data to your advantage!

C.I. needs to improve. […] Booking.com can rollback in 8 seconds!

You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.  – Steve Jobs

Bosch will release a book by Christmas, probably about speed!

[1] Bosch, Jan. ”Tutorial summary for speed, data and ecosystems: The future of software
engineering.” Software Architecture (WICSA), 2016 13th Working IEEE/IFIP Conference on. IEEE, 2016.


To summarize STEW 2016, I will give a short list of pros and cons. Although I may not be able to put it to words, my overall impression with STEW is overwhelmingly positive.


  • Great way of bringing industry and academia together.
  • As a student I got to learn things that you simply won’t get to know in school.
  • Very good fika!


  • I would love to see more ”software companies” and not just the big dragons SAAB and Ericsson. Maybe DICE, Klarna, King, Mojang or Spotify can join in on the fun?
  • It was way too cold for comfort in the lecture hall, Vallfarten, at LiU.