During the last months, I have been working in a couple of different teams in parallel. Getting things done in such a setup needs another kind of organization than working in one team only. One of the most important changes I implemented could be named "The three-project-rule".

Recently, I finished the book "The Checklist Manifesto" by Atul Gawande. It is a great book about how good checklists work and how to create them.

Earlier, I wrote an article about how to create a connection to a database service in Cloudfoundry. The reason for this was to backup and restore a Mongo database, which is the topic of this article.

1. SSH-tunnel

First, built up an SSH-tunnel (details see here):

There are several tools to solve the "Let's schedule an event" and "Let's find a common result via a poll" - problems. The most famous is doodle.com. However, most of these tools gather data. How this data is used can not be influenced by or even known to the user. Remember: If you're not paying for it, you become the product.

Recently, I joined a new project. As always when this happens, I got a ton of new credentials for websites, platforms and so on. This flood can easily be managed using password managers like KeePass. However, one of my new colleagues showed me some cool features I didn't know before. This article is a short review of those features.

Some values of an application have to be provided from "the outside" of the application, for example the secret of a JSON Web Token (JWT). This secret must remain private and must not be shared. Hence, it cannot be written in a properties file, especially not in an open-sourced project.

In a local environment and also in a deployed state, this can be done by providing an environment variable:

Since recently, my employer msg DAVID is using the Clifton StrengthsFinder 2.0 to improve the personal development of each employee and also promote better cooperation in teams. In this article, I publish my personal test results and comment on them. This post serves as a retrospective for myself and as a reference for my colleagues so that they can learn how and why I do things the way I do.

For the last two weeks, I’ve been testing a new tweak for my self-management: Timeboxing. This article explains the principle and summarizes my insights.

In the great book "Tools of Titans" by Tim Ferris, I read about manager’s schedule and creator's schedule. In this article, I explain the difference between both and how I use them.

Until recently, I told my team to squash all of their commits on a given feature branch to just one commit. Every feature branch consisted of just this one commit and could be integrated into develop so that develop read just like a sequence of features. After further consideration, I changed that. Here are reasons for both approaches:

Pro-Squash: