Last year we split our IT team into three smaller teams. One reason why we split the team is that the team just became too big for one manager. I took over one team and then was team lead of three developers. So, managing them was on my plate and one of the things I was really exited about were 1-on-1s with my team.

When we started building our product, deleting users wasn't part of the MVP. Resorting to both the worst and efficient thing we could do, we deleted the users in the Readmodels instead of implementing a proper Domain Event. Here's how we fixed our domain state.

This will start a series of blog posts where I will be writing about my journey into the world of functional programming. I will try to focus on a practical approach without getting to deep into the theory behind it and share my experiences to help others understanding what FP is and how it probably can help you write better code.

Every other week the complete vaamo development team gathers and talks. Sometimes we talk about general things like workflow optimizations, other times we do agile-style retrospectives, then again we talk about what comes to our mind. Whatever it is, it must be about how we as a team can improve in our work.

In this post I share the meeting's summary, which I sent to the team, with you.

In my last post I wrote about how we think about the tech lead role and why we don't have a dedicated tech lead. Instead the whole team shares the responsibilities of this role. This post is about more concrete examples of how we actually do this.

At vaamo we use git for version control. While we discussed our git workflow heavily in the beginning, we've settled for a very simple workflow where everyone in the team is working on master. In this blog post I discuss why we opted for the a simple workflow in comparison to others out there.

What are the responsibilities of a tech lead, and how does that role fit into our team? I thought deeply about these questions, read blog posts about the topic, and discussed it with Benjamin many times. As usual, the answer to those questions is: It depends.

I went to DevOpsDays Berlin on Oct 23-24. And besides giving an Ignite talk titled "Sane Secrets Sharing", I also proposed and facilitated a session about "Minimum DevOps" during Friday afternoon's Open Space.

I’m happy to announce the next Rhein-Main Scala meetup will be hosted on the 20th of October at the Vaamo office. This time we will be joined by Jon Pretty, who is behind the Raptor project which provides open-source Scala libraries for common programming tasks.

If you are a coder apprentice yourself, you sure you know this: You are full of motivation, you really want it, but still end up not finding that half an hour, hour every day you swore yourself you’d take, to constantly train. And every time you find an hour or four and want to make up for the time lost, you start at almost zero again.

We’ve been working on the application that enables our customer to invest money and reach their financial goals for quite some time now. And all the time while doing this people kept asking what our technology choice is and how this choice has been working out for us.

There is always a little adrenaline surge when I see one of my commits failing on Travis, which we use to continuously integrate our projects. Since we try to keep a linear commit history and a master that is always deployable, I naturally want to get the build green as fast as possible, which means I want to find out quickly what went wrong.

The meetup is run as a Hack Night where everyone is invited to work on a project of their choosing. You can work on your favorite open source project, on your personal project or your company’s product. Doesn’t matter what it is as long as you are willing to show it to others and would like to work with a group of people instead of alone at home or your office.

We’re using lots of open source software in our technology stack. In fact our production stack is completely based on open source software. And as we are big believers in the idea of open source, it was clear from the beginning that we want to release the parts of our stack that are not specific to our business model back to the open source community.