Q&A with Asbjørn, Software Architect

Author avatar
By Siteimprove Careers
Oct 02 2017 — Employee Testimonials

Find out what makes our Software Architect, Asbjørn, tick, and hear his insights into the development environment both in and outside of Siteimprove.

Asbjørn Clemmensen, Software Architect at Siteimprove


What was the development environment like at Siteimprove when you started?

In 2013, I got a full-time job offer from the company before finishing my studies, as a software developer. It was an intense period – we were increasing our product portfolio and we had some restrictions because the company was growing. Originally we had a frontend team and a backend team and we kind of switched tasks every couple of months but that turned out to be fairly inefficient. We’d work on a product and then it’d be another year before we got round to working on it again, so competitors would catch up and all you’d really manage to do was bug fixing.

Luckily we were growing and we ended up having enough developers that we could have product teams and could focus consistently on each product. The teams now have different competencies within, with both frontend and backend and some operations experience and we’re still building that out. As for more I was promoted from a software developer to a software architect.


What does your role as a software architect entail?

The way I describe software architect is that you’re a software developer who’s supposed to have the overview of what’s going on. So you’re not like a process step people have to go through, like for architecture approval, at least that’s not how I have approached it.

It’s more consulting teams when they need help with something, for example we just rewrote the accessibility checking pipeline over the past couple of weeks and I was involved in that, in fleshing out the design and implementing it.

I really prefer to be hands on with the things and I think you can’t properly recommend things before you know that they work. I have a feeling some people would decide on a purely theoretical level that things are supposed to work this way, and so you go and implement it that way and then they might discover that really doesn’t work at all. I much prefer having experience with the approach or being part of running an experiment or something to see if it actually works.

So for example another project we’ve been trying to start up is with our analytics product, so basically replacing the existing pipeline and database with new technology that can accommodate bigger customers and more demanding customers. That’s another one where we’re trying out different technologies because we just don’t know the right answer upfront and you never will, so we have to kind of say ok now we’ll try this approach and we’ll see if it works and we’ll take some parts of the system we know are challenging and we’ll see does this new technology actually work or does it make it worse.

So there’s a level of experimentation and I really think that software architecture is a mix of experimentation and being part of the teams that are implementing it, so I move around and work with different teams and different levels of the stack. Sometimes its frontend and sometimes its application layer software development and then sometimes it’s on the operational layer of the infrastructure side.


We’re always looking to hire developers but what profiles do we need?

If you have the right attitude it’s not really that important what your background is. The easy answer is that primarily we’re looking for C# developers but in reality most languages will work and some of the people we’re hiring now have all sorts of backgrounds so the kind of expectation is they’ll learn pretty fast.

If I had to speak for myself we prefer people who are not too religious about programming because if you’re religious about what language you work in it makes it really hard to be flexible and work in the environment you end up in. I guess you could say we need agnostic developers, because atheists probably don’t believe in programming at all... Personally I’ve done Elixir, JavaScript, SQL, Clojure and all kinds of different things and it really doesn’t matter what languages you know, it’s what you do with the language, how you think in it, and how you communicate about it, that’s important.


Why would someone want to work in Siteimprove’s development team?

You get a lot of freedom and responsibility, and there’s room to experiment and find the right approach. I also think that it’s great to work on a piece of software or system that has lasting value, it’s not like you work on this for 3 months and then you move on to do something else. This is like building your own home and you’re going to live in it, so it matters what you do. Quick fixes will stay with you forever. There’s also lot of room for being in different places in the stack, all the way from people doing purely UI things to people doing purely backend operational things.

It’s interesting the amounts of data that we have, so that you get some challenges that you wouldn’t get otherwise. In many normal size companies if you had to do order processing, for example, it’s really a trivial amount of data that requires a trivial amount of processing power, that’s definitely not the case here. Just the other day to do accessibility checking we basically bought all the instances that Amazon had in Frankfurt, they literally couldn’t provide us with anymore because they ran out because we’re using all of them. Sure that’s not an exciting situation to be in because it posed a problem for us but it’s also kind of telling because in many company they’d never really reach that scale or have problems that needed that kind of resources.

Finally I think the colleagues here are great. I really think we have a great team and I think all the social stuff that happens is really important. I think that would be one of the hardest things to leave – the people and the culture – that’s something that you just can’t necessarily get other places.

Post a comment

You accept the use of cookies by continuing to browse the site or closing this banner. Read more about cookies in our Privacy Policy.