Wouter Sioen

Wouter Sioen

15 posts
Delivery oriented stand-ups

Delivery oriented stand-ups

As engineers, we want to focus on delivering value to customers. We noticed that a lot of the projects we work on are following agile processes, but in a format that misses the mark. That’s why we started experimenting with how we could bring back the right focus. I’...

Bridging experience gaps while pair programming

Bridging experience gaps while pair programming

Some weeks ago, I was doing a talk about how you can make pair programming effective and enjoyable. Everything went well until I got a question which I couldn’t directly answer. The questioner had some experience with pair programming and asked me how you can avoid getting frustrated when...

The Domain-Driven Design fallacy

The Domain-Driven Design fallacy

Most people get to know Domain-Driven Design through the tactical patterns. Concepts like Value Objects, Entities, Aggregates, Repositories and Event Sourcing are all strongly linked to DDD. That is most likely the reason why many people interpret Domain-Driven Design as a technical thing. This is quite a misconception though. When...

How efficient is pair programming? Will it work on your team?

How efficient is pair programming? Will it work on your team?

It is quite easy to see pair programming as using double the resources for writing the same piece of code. If wrongly applied, this might even be the case, so why do experienced pair programmers feel like it is more efficient than working on their own? Let’s take a...

How to keep pair programming digestible

How to keep pair programming digestible

Most software engineers are aware of the fact that pair programming can have some huge advantages. It’s one of the most efficient ways to share knowledge, it gives you an almost instant feedback loop, and it results in higher quality, less error-prone code. Pair programming can be draining though....

Refactoring towards testability

Refactoring towards testability

When working on a legacy codebase, you often have to make changes in code you don’t fully understand. When this code is not tested, you’re never sure that it will still work after adapting it. And will it have unexpected effects on other parts of the codebase? As...

You’ve successfully subscribed to madewithlove
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Success! Your email is updated.
Your link has expired
Success! Check your email for magic link to sign-in.