An Inside Look with Codeship: Hans Hasselberg of 6Wunderkinder

Hans Hasselberg is a developer and part of the operations team at 6Wunderkinder, the makers of the To Do list/planning app Wunderlist. This week, we had the chance to sit down with Hans to talk about the benefits of immutable architecture, the challenges of keeping a product online 24/7, and how to keep moving when you don't know how to solve a problem.

An Inside Look with Codeship is a regular series providing an insider’s perspective on founding and building a tech company. Each session, we chat with some of the most exciting voices in tech and ask them where they’ve been, where they’re going, and what we could all be doing together. You can read all Inside Look interviews here.

Catch the highlights of Hans' answers in the video below or read on for the full interview.

[youtube https://www.youtube.com/watch?v=oYLOmPq0Cwg?list=PL-rUCWkRnKgfoEYYNlAWl2Lf3aAPtKo\_w&w=680&h=510\]

Can you tell us a little bit about your current role and how you came about to join 6Wunderkinder?

I’m mostly responsible for the servers and databases: provisioning the servers but also occasional firefighting. I was called a Site Reliability Engineer, and I thought that was quite a good description. I'm now part of the Optimizations team, which is responsible for improving mostly speed but also battery life and the amount of data we send around.

I came to 6Wunderkinder almost three years ago. It was the end of 2012 when I joined as a developer, and it was a bumpy ride in the beginning, with the launch of Wunderlist 2. We were firefighting problems quite a bit back then, which made me switch from being a developer to the Operations person.

Was there something specific that made you want to join?

I knew a few of the early people at 6Wunderkinder. I went to university with them, met them at conferences, and we got along well. When I decided to switch jobs, they were the first people that came to mind.

I had previously worked for an insurance company, so the idea of working for a company which is not focused on business clients but on users like me... that was really interesting. To get to work on a widely used product.

Wunderlist definitely has a huge user base. How was that different for your work?

I used to work for companies where we were running for internal use or a user journey specific to an industry. Business customers, basically. But having a narrow user base means you aren’t forced to scale. You don’t have such pressure on your system.

But working on Wunderlist, it’s a huge shift. There’s no minute during a 24-hour period where you could shut the database down or do maintenance or take part of the system offline. The product needs to be online 24 hours a day. It’s a big shift.

How is the development team set up at 6Wunderkinder?

The development team at 6Wunderkinder is quite exceptional compared to other companies I’ve been at. We have a few developers who are remote, but most of them are in Berlin. One shift we’ve gone through recently was in how our teams are organized.

Previously, we were organized according to the technology: We had teams for Android client, Windows client, etc. But we’ve moved to an organization where we’re organized cross-platform. For example, an engagement team which is responsible for engaging and getting feedback from users regardless of client.

Are you finding benefits to that change in your teams?

It hasn’t affected me personally as much as it has others, because my role in operations is pretty much the same. I’m slowly shifting gears a bit as new people come into operations.

But for the whole team, it changed quite a bit. Teams are more intermixed with developers and marketers, and you’re working on implementing features across all clients and doing it from the beginning. You get to follow the progress from feature concept to implementation to shipping.

Is there a specific aspect of your technology stack that you're most proud of?

I’m always amazed at how fast the sync is in our product. It’s something we’ve worked hard to build. For example, I was sharing a wish list for my birthday with my brother. I was on the phone and suddenly heard an ‘oops’ from him. We were talking about the list and, for a millisecond, I saw him check an item -- I saw him live editing the tasks. He only had checked it for a millisecond, yet I still saw it on my end, so you can see how fast the sync was. It was impressive and still funny to see it in action.

On the flip side, is there a particular technical challenge you're grappling with right now?

So, we have how our synchronization works. It’s a hierarchy where, for example, if they change the task, the revision of the list is increased, and so it indicates to the client that something has changed in that list.

There are some flaws with that hierarchy which makes it increase traffic on all backend. Right now, my team is working on changing the hierarchy for the synchronization so that clients can be more effective and the backend has less traffic, but doing so in the best way to still properly synchronize the data.

Another thing we’re always looking to improve is our provisioning and deployment. We have a service-oriented architecture or microservice. That makes it hard to monitor your system and to identify the next thing. On one hand it’s easy to spot a problem when one service is failing -- you know what’s going on in there -- but it’s also very hard to put that into the bigger picture. Why it’s failing, who’s calling, who’s using this service, and what does it affect.

It can be difficult to get answers out. For example, knowing what the impact of user actions will be. Having a picture of all these actions is valuable, but it’s not easy to capture. It’s hard to maintain, to get all the data of the system, because our system is changing so fast. Because it’s service-oriented, stuff basically gets rewritten every once in awhile.

How do you feel immutable architecture improves the development experience?

It definitely improves the experience of the operations person. But developers benefit too when they roll out new software; they know exactly what's running on each server, for example.

Generally, it’s been treating us well because it means that we don’t change anything that’s on server, or once the server is running, it’s not changed. So it’s either running or being thrown away, so if we introduce a change, we’ll go ahead and get a new server. That has multiple benefits.

It means that we’re now very good at making new servers from scratch because we do it every time. We’re doing it for every change that we push into our code repositories. So every change we are putting into our source control results in an image which is available to every developer. Rolling back code changes is very easy; if something fails, we just boot servers from the previous image.

Are there any challenges/difficulties with that setup?

Because we’re building so many servers and so often, it needs to be fast. We’re working on that. Previously, creating a server would take about twenty minutes, and now we’ve reached a point where it takes only five minutes. It’s a great improvement, but as soon as developers get used to that, five minutes will start feeling long.

We're always working on improving our setup and speeding up because the faster you are, the faster your deployments. It makes it affordable to deploy even smaller changes. And smaller changes means the deployment is less risky and done more often.

How are you and your team trying to give back to the developer community?

We’ve started to make the next iteration of our provisioning tool open source. We’re actually developing in open source. That makes it a bit harder for me -- people can see anything you do. When you’re starting a new project and not sure exactly where stuff will go, it can be difficult.

The latest contribution, at least for me, was through software called Consul from Hashicorp, which we heavily rely on. We improved the ability of Consul to run inside of containers.

Education is discussed quite a bit in industry. What kind of training makes the best kind of developer?

I’m pretty classically trained. I have a controller’s degree in computer science, but I do work with people who don’t. I mean, most programmers don’t. I know someone who has a degree in music, so obviously you don’t need a computer science degree.

There are many fields in software development, and depending where you go, you might need some specific knowledge, maybe about algorithms and datastructures or about databases. But that depends on the job, and I don’t think it makes sense to require everybody to have that.

If you had a time machine, and you could go back in time and give yourself one piece of advice at the start of your career, what would that be?

I remember watching a TED talk that discussed how ‘grit’ is the most important skill to have. I think that’s what I’ve really learned the hard way. In school, I was very good at math, and it took a while for me to accept that it’s not about understanding only the concepts. Math, for example, is very much about not just the concepts, but exercising, doing the work.

I left [high] school thinking that understanding the concept was enough to do the math. In university, I got to learn how wrong I was, because even when I thought I understood the concepts, I didn’t, not until I started exercising thoroughly.

There are problems which are not easy to understand, not easy to grasp, and not easy to work on. You need grit in order to make progress. Grit teaches you the more time you spend working on something, even though it’s boring and hard, you will improve. You improve, step by step, and eventually, you will get a solution.

Thanks, Hans!