Capturing Intent – Making sense of code

Picture the scenario: You are staring at the computer screen and scanning the lines of code that fill it. You scratch your head and think: Why?

You debug the code, step-by-step and see a method call that sticks out like a sore thumb. It’s doing an out of process call to another subsystem before the code has completed its job in this method.

Why is that out of process call made there? There’s no documentation explaining why. Moving it to the end of the method makes more sense, but then everything breaks. WHY? 


As a software developer, you might have experienced situations like this. You’re looking to fix a bug or extend a feature and you stumble over code that just doesn’t make sense.

You can see what it’s doing, even understand how it’s works, but you just can’t understand why.

In this post I’ll show you why making the extra effort to capture the intent of the code is so important. Continue Reading


Submitting a Conference Talk Proposal

This is an inwards-facing post, which you may or may not find valuable. The short version is: TL;DR: Do something that scares you. Perhaps submit a proposal for a conferences Call-For-Papers?

Some time ago, I was fortunate enough to have the opportunity to speak at NDC Oslo, with a dear friend and colleague of mine. An experience I will cherish with personal growth and many connections made.

I feel, though, I had the home-side advantage. Presenting in my country of residence. On stage with a colleague that had my back. The topic was in context of my employer, who was well-known for the home audience.

I’m not trying to de-evaluate the accomplishment, but rather the potential and hunger to take the next step. But is it worth it?

The next step, maybe

Fast forward a summer vacation / paternity leave and the speakers-high has started to wear off. I’m curious if I can make the step to an international arena, alone. Searching around I stumble over The Lead Developer New York, and decide I want to try for that.

I take a first step, and ask for feedback on the talk from NDC Oslo. Feedback is decent, but there’s a lot of work involved to re-angle it for it to work in that setting. Challenge accepted…but not today.

A few weeks more go by, and I’ve procrastinated away my first opportunity as a CFP (Call For Papers) goes by. Too much going on, or so I say to myself.

Reality check. I can actually do this if I want to. Then Imposter Syndrome strikes. Hard. More procrastinating. Some interactions, and writing the blog post on Imposter Syndrome remind me of what I need to do.


Last week I submitted a proposal for a talk that’s been swirling in my head for some time for The Lead Developer London 2017. I have no idea if it will get accepted, but I’ve taken the first step.

The journey from idea to submitting a proposal is a tale of missed opportunities, failure to take action, internal struggles with my self-worth, but most importantly growth.

For the record, the title of the talk is “You are more than just your code“.

What’s holding you back from taking the first step towards something that scares you?

Reach out to me directly if you have any thoughts, questions or criticisms. Or leave a comment below.

Cover Image:  WilliamMarlow via Visual Hunt / CC BY-NC-SA

Agile, Craftsmanship

Long live Code Reviews! Code Reviews are dead!

Let me introduce you to Malcolm. He’s my imaginary developer-friend currently working at Mega Enterprise Inc Ltd Corp. He’s been butting heads with the lead developer, Jack,  for a while now. They don’t seem to be seeing eye to eye on a feature that Malcolm implemented. You see, Jack doesn’t like how Malcolm writes his code. Formatting is wrong and he uses way too long variable names, and he doesn’t write a single comment and…(list goes on)! Jack hates reviewing Malcolms code. Malcolm usually gets his code back from Jack, with a long list of TODOs. So Malcolm goes off to re-do most of his work just to give it back to Jack…When Jack’s finally happy with the code; It adheres to his preferred coding style and uses the correct enterprise patterns that have been decided upon. He allows it through the magic gates to master. Continue Reading

Developer growth

Embrace your inner Imposter

There are times in life where no matter what happens, you feel like a fraud. Where your inner critic says you aren’t worthy or capable of doing a certain task, even if you’re good at it. I asked a few friends to share some experiences of theirs where their inner imposter spoke over their own skills:

“Sometimes when I’m part of a discussion on politics I just say something and shy away”.

“How can I ask for more pay? I’m nowhere near as good as …”.

“I can’t hold a presentation at [some event]. I’m no expert on this topic”.

“I love pair-programming, but hate when I’m typing. What if they realise I need to google simple things? Would they think less of me?”.

“I can’t write blog posts. People will laugh at my lack of knowledge”.

You’ve probably experienced some thoughts along those lines. You doubt yourself with every brain-cell and are afraid someone will call you out for being a fraud. I know I have. You see, those experiences arent from friends of mine. They’re actually my own.

Yet I know I can do all of them, I get feedback from my friends, peers even strangers confirming the value of what I do. Why is it then so hard to recognize my accomplishments?

Continue Reading

Agile, Developer growth

Trusting in the Mob – A story of bringing distributed team members closer

Working in a distributed team isn’t easy, especially when members are spread across 4 locations. I was recently part of a team that was doing pretty well, but wasn’t functioning as a cohesive unit. There seemed to be hesitance towards pair-programming sessions, even though doing quick Skype calls seemed to be fine. We were relatively open during retrospectives, but were missing out on the deep conversations.

I had a feeling this was a trust issue, and that spending more time together could help. Sitting in an online meeting doing team-building exercises didn’t seem like the best approach, which is when I stumbled over Mob Programming as a way to both get work done, and build up the team’s collective trust and understanding. Continue Reading


Accepting that every team member is doing the best job they can

Many software development teams have a process including retrospective meetings. An opportunity for the team to look back at a period of time and assess how it has functioned. It’s often connected to the Scrum, but you don’t need to be adhering to any process / approach to see the value of having retrospective meetings. The goal of the retrospective is learning. What worked? What didn’t work? How can we improve something that’s broken? Should we continue with something that’s working?

Another aspect of the retrospective is that it’s meant to be a safe place for team members to speak their minds. The idea being that given a safe place, a team can figure out its own problems and possibly even solutions.

To create that safe place there needs to be trust. Enough trust so that team members can be candid with each other about issues that arise while working together. Enough trust that allows the team members to be vulnerable, and know that they won’t be judged. Where blame isn’t handed out, but rather bonds created and learnings are formed.

But how do we create a space in the busy life of a software development team, where deadlines and bugs are commonplace and there’s often a pressure to deliver something that will create value? Continue Reading