1. Learn as you go

    I’m a big fan of projects that deliver value in small, incremental steps. Unfortunately, some of the projects I worked did not turn out that way. After one of the not-so-great projects, I decided to do a personal retrospective. Instead of listing all the things that went wrong, however, I decided to write about what could have been. Read article

  2. Thank You Letters

    I still remember that one time when my colleague and I worked on a difficult project together. After we had completed the most difficult part of the work, he came over to my desk to thank me. Read article

  3. Help, my mind is trying to sabotage me!

    Writing doesn’t come naturally to me. Well, that’s mostly true. Occasionally, a flash of inspiration helps me to finish an entire article in one go. But these moments are rare. Most of the time, writing is an excruciating process. Read article

  4. What are microservices good for, anyway?

    This article is a small intermission in our series about the socio-technical aspects of microservices. I realized that I hadn’t quite covered why you would choose a microservices architecture in the first place. This is what we’ll cover today. Read article

  5. The socio-technical aspects of microservices: a teaser

    I’ve learned a lot about microservices in the past seven years. During that time, I helped to design, deploy and operate a handful of systems based on microservice architectures. Some of those systems turned into success stories. Others caused more trouble than they were worth. Read article

  6. Always start with a monolith

    Like everything else in software development, microservices have trade offs. They can do much good, but they can also be harmful. How beneficial they are depends on the context they are used in. I’ve seen microservices work well for an organization if: Read article

  7. There really is no such thing as a lone software developer

    At the beginning of my career, my mind was preoccupied with technical details. I believed that by learning all about the intricate details of computers, I could become an expert software developer. But even though my understanding of computers kept growing, many aspects of software development remained a mystery for me. Read article

  8. The power of being vulnerable

    I am no longer in fear for my father’s life. I’m so glad that he’s won his battle with Covid-19 induced pneumonia. It’s been a tough fight and the disease has certainly taken its toll: even climbing a small set of stairs has become an insurmountable problem for him. But he’s started his recovery and is getting stronger every day.

    Read article

  9. Be patient, be gentle, be kind

    Today my father was diagnosed with pneumonia. He’s already been weakened by twelve days of recurring fever. Despite his best attempts to stay strong, he’s lost a lot of weight. When I learned that he has tested positive for Covid-19 last week, I was worried. Read article

  10. Domain-Driven Design: conclusion

    When I decided to write about the basics of Domain-Driven Design, I thought I could capture the key concepts in two or three articles. In hindsight, I was a bit naive. Domain-Driven Design is a huge topic, so there’s plenty to learn about. Read article

  11. Domain-Driven Design: time for a case study

    Today I’m going to make good on my promise: we will finally apply the concepts of Domain-Driven Design to a piece of source code. I’ve developed a fictional case study that I hope to be both, simple enough to understand, but also realistic enough to be useful. Read article

  12. Domain-Driven Design: is my design any good?

    There are many ways to design a system. Some are more fit for purpose than others. If your team spans different roles, your design should facilitate teamwork. In this article, we’ll learn about a technique to evaluate that particular aspect of your design.

    Read article

  13. Domain-Driven Design: five ways to facilitate change

    Domain-Driven Design asks us to experiment with the words and concepts we use in our models. Each change must be consistently applied across all artifacts though. Otherwise, our systems will become tough to understand. Keeping our artifacts up to date is a lot of work, but there are ways to reduce the burden. Read article

  14. Domain-Driven Design: refinement

    Model refinement is an important part of Domain-Driven Design. Although this sounds easy at first, it turns out there is a tension between model refinement and ubiquitous language.

    Read article

  15. Domain-Driven Design: the limits of ubiquity

    In discussing the benefits of a shared mental model we always did so in the context of a team. But many organisations consist of more than one team. Can we take the ideas of Domain-Driven Design and apply them to an entire department or even the whole company? Read article

  16. Domain-Driven Design is first and foremost about teamwork

    About eight years ago, I came across the concept of Domain-Driven Design (DDD) for the first time. Back then, I was still working in a tiny startup with only a handful of developers. And although I did learn about entities, aggregates and the like back then, I completely failed to understand that DDD really is about teamwork. Read article

  17. Going across and beyond

    I realized that one of my favorite work-related stories from last year is worth sharing on this blog, because there is such a powerful lesson in there. It’s a great example of how useful it can be if you take a step back and look at the larger picture. I’m quite sure that you’re going to enjoy it.

    Read article

  18. Guiding principles for a thriving remote team

    The one thing that gets me out of bed in the morning is a chance to help those around me to accomplish great things. So when I found myself in a struggling remote team I couldn’t resist the opportunity to make improvements. This article outlines the principles that guided me along the way.

    Read article

  19. Seven ways to explore the power of pair programming

    For the majority of my career as a programmer I believed that I was way more productive when working solo. Had you been on my team back then, you would have found me almost exclusively wearing noise cancelling headphones, in a deep state of focus, trying to turn out lots of high quality code. Read article

  20. Together we code?

    This is a website about working together. We’ve got a whole bunch of topics to cover, spanning pretty much all aspects of software development. Occasionally, we’ll be venturing out into related topics such as change management, mentoring, and good old-fashioned trust. Read article