Especially in bigger teams, establishing and maintaining a common standard for software development is important and challenging. At the same time, it’s crucial to involve the whole team in the creation of the standard to ensure its acceptance and high quality. In this post, I present our approach for this: The regular meeting “Tech Talk” and the team guide.
1-1s are the most important tool for every team manager. If done right, 1-1s can support the report to grow and to develop, to become and stay happy, motivated, and productive. However, you need a certain toolkit for 1-1s. This toolkit contains different 1-1 types, records, questions, personal notes, journey maps, and software that can be applied in practice.
During Corona time and short-time work, I appreciated the uninterrupted time to focus on my work at the home office. I felt productive and got things done. For the post-corona time, we can learn from this and establish practices that allow all coworkers to have longer stretches of uninterrupted time. This post is a collection of individual, organizational and cultural approaches to achieve this.
A popular approach is packaging by technical concerns. But this approach has some drawbacks. Instead, we can package by feature and create self-contained and independent packages. The result is a codebase that is easier to understand and less error-prone.
There are some principles in software development that I always try to keep in mind. They guide me when I’m in danger of heading in the wrong direction. That’s why I printed those principles and hung them on a wall in our office. In this post, I share this subjective set of quotes with you. There is also a PDF for download available.
Traditional hierarchy-based feedback flows are limited as they don’t consider the useful feedback of peers. To improve this, I suggest a “Complete Peer Feedback” session: All team members come together and share their appreciation and growth potential for their peers. In this post, I present our experiences with this approach, why we are enthusiastic about it and how you can adopt it.
Employee journey maps are a tool for preparing and structuring staff appraisals. They trigger reflection processes and reveal the employee’s motivation. Moreover, they can lead to interesting insights as they compare the different perceptions of the participants. And the best is: You only need two sheets of paper and a pencil.
Putting a fat jar into a Docker container is a waste of storage, bandwidth and time. Fortunately, we can leverage Docker’s image layering and registry caching to create incremental builds and very small artifacts. For instance, we could reduce the effective size of new artifacts from 75 MB to only one MB! And the best is that there is a plugin for Maven and Gradle handling everything for us.
I made a talk with the title ‘How to Mess up Code Reviews’ out of my blog post ‘Code Review Guidelines for Humans’. In September, I was allowed to hold it at the JUG Saxony Day near Dresden and the JCON in Düsseldorf. It was a great pleasure for me. Thank you so much for having me! Here you can find the slides for both talks.
Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collected over the years of writing unit tests and integration tests in Java. It involves modern technologies like JUnit5, AssertJ, Testcontainers, and Kotlin. Some recommendations might be obvious to you, but some might conflict with what you’ve read in books about software development and testing.