In the world of test-driven development, load testing is often overlooked. Here we would like to make a case to give load testing the attention it deserves and provide some useful tips based on our experience in Delivery Hero Engineering.
I have been involved in IT for over 20 years. The last 15 of those I’ve been building and leading support teams. Here are my thoughts on why I love working with first level teams and some of the things I do which I have found worked well for me in building high performing and fun to be a part of teams.
Practical advice for a smooth transition into a new company.
Changing jobs isn’t something one does often. It’s a big decision. Being a Product Manager requires having both breadth and depth of understanding, which needs to encompass the organization, the business, the people, the customers and the technology. When starting a new company you possess little of this knowledge. I recently went through this transition. I went from having over four years of domain knowledge and historical context to knowing nothing. It’s daunting and scary.
In Part I of this series, I touched on the structure of our Standups, Retrospectives and explained the concept of a Sprint. In this part of the series, I will dive into detail on how heroes pay their technical debt. Much more importantly, I will share with you how we inform our stakeholders when we have failed to meet their expectations.
In my previous post, I touched on the subject of why DevOps for Data and Machine Learning applications is more difficult and costly to implement than on traditional applications. In short… Wow, Data DevOps looks hard! But don’t let this deter you. Making some progress is easier than you may think…
During our third quarter in 2018, I embarked on my journey of building a new cross-functional team for a greenfield project. Initially, when we first started, the team only consisted of a product manager and me, as the lead engineer. Fast forward a few months down the road and we had gained the support from two additional developers. The first engineer was working with us in our HQ in Berlin, while the second engineer was working remotely from South America, while his visa was being processed. At first, we didn’t really feel the need for having a specific process – we were using a Kanban board to prioritize and track progress on development. As the team continued to grow and our remote engineer relocated to our HQ in Berlin, we started having the feeling that we could be more productive. This is why we started testing scrum for our team.