At the moment I’m working on a project where I’m more of a YAML engineer than anything else. During this time, I kind of enjoy getting my hands on actual code again, but most of the time, writing code is a rarity for me. So, whenever I find a cool idea to work on, I usually start a new side project. Something I try to incorporate as soon as possible is Test Driven Development (TDD).

While I agree that initially TDD may not fit into the ideation phase of your project where you’re still trying to figure what you’re doing, but as soon as you’re evolving TDD really speeds up your development.

Let me show you how TDD can up your coding game ! 🚀

Refactoring Becomes Part of Your Workflow

While I was working on my side project, something I immediately noticed after applying TDD to it was that refactoring became a part of my development workflow. That’s a great thing, right? I mean, how many times have you looked at code thinking:

“Damn that thing should’ve been refactored a long time ago”.

With TDD, you’re refactoring your code more often, simply because you’re wiring it directly into your workflow. Every test you write forces you to think about the design of your code, and since writing tests has now become a first-class citizen in your code, you’re more likely to refactor your code so that it remains easy to test.

Shorter Feedback Cycles

By practicing TDD, you’re forcing yourself into a constant feedback loop, iterating on the implementation and the design of the code. By writing the test first, you’re already investing in the design because you have to think about what your function will return, whether it has a side effect you need to capture, and so on. This leaves you with code that is testable right from the start and easy to refactor later on, since you already have tests covering your existing functionality. As you’re in a constant cycle of writing a test, implementing the functionality, and refactoring your code, your feedback loop is way shorter than writing the implementation, starting up the application, and refactoring/fixing bugs afterward.

Less cognitive complexity

Test-driven development encourages you to think about one thing at a time, which really helps to reduce the cognitive complexity during the implementation and while reading the code. More often than not, we get assigned features that contain a lot of business rules, errors, and edge cases. Keeping track of all those things during development can be a real pain.

TDD can help you manage this complexity. If done properly, the acceptance criteria of your feature directly translate to the tests you write. So, in a test-driven fashion, you start writing a test for your first acceptance criterion, implement it, and move on to the next one. This way, you can focus on one part of your feature at a time, and you don’t have to worry about introducing yet another edge case, since your tests have your back right from the beginning. If you don’t use TDD, you might be inclined to implement all the acceptance criteria at once, thus putting a huge load on your brain.

Separating Business Logic from Side Effects

Another benefit of Test Driven Development that I absolutely love is that it forces you to keep your business logic pure and keeps the side effects on the edges of your application. Side-effectful code can really be a nightmare to test or debug, as it does things you might not expect it to do.

Since TDD enforces your code to be testable, naturally, you tend to push side-effectful code, such as network requests, to the edges of your application so that your business logic is deterministic.

TL;DR

Test-driven development is obviously not a silver bullet, and it has to fit your development workflow. In most cases, I think TDD brings a lot to the table and will generally produce better code.

In essence, I’d suggest you give it a try, since there is much to gain and not much to lose anyway. Take a kata and check it out!

I recently experienced this firsthand, growing increasingly frustrated with a product Owner in my project not performing their duties as expected.

Have Some Empathy

While I’ve never been a Product Owner myself, I can only imagine the challenge of bridging the gap between the business and technical worlds. From a developer’s perspective, a Product Owner’s job might seem straightforward: a few meetings here, some prioritization there, preparing for the next sprint. Sounds easy, right?

As simple as it might sound, being a PO demands significant skill and, most importantly, experience. You need a deep understanding of the business domain and its goals. You must weigh the importance of meeting deadlines against the risk of accumulating too much technical debt. On top of that, you’re responsible for managing diverse stakeholders: managers, end-users, and your own development team.

If you take on their hat for a second it can really help you understand what kind of work they have to do. So the best way to start empowering your Product Owner is by showing empathy and striving to understand their challenges.

Your Product Owner is a Team Member

Business people and developers must work together daily throughout the project.

Too often, I observe teams treating their Product Owners as if they are managers or some kind of higher authority. However, if we recall a key quote from the Agile Manifesto, it’s clear that business people and developers are meant to collaborate closely, so might as well treat them like a team member :) .

Practical Ways to Help

Here are some actionable steps you can take to support your Product Owner:

• Communicate Effectively: As a senior engineer, you should maintain close and direct communication with your Product Owner. Most problems a development team faces can be solved through open dialogue. If possible, set up regular one-on-one sessions to foster a strong working relationship.

• Exchange Constructive Feedback: Giving and receiving feedback is one of the most powerful tools in your professional career. It not only helps your peers and team members grow but also provides ample opportunities for your own development. Use honest feedback to highlight areas where the team feels unsupported and suggest how your Product Owner can better assist.

• Lend a Hand: Although it might not be explicitly your job, pairing with your Product Owner — for example, on writing tickets or preparing for planning sessions — can be incredibly beneficial. Both of you can gain valuable insights into how the other side operates and what people need to accomplish their work.

• Be Transparent: Transparency is another crucial factor in enabling your Product Owner. They most likely have deadlines to meet, so be upfront about any blockers, dependencies, bugs, or other issues. Highlighting these early gives your Product Owner the opportunity to adjust plans or manage stakeholder expectations effectively.

Summary

While none of these tips are revolutionary and might not apply to every person or situation, I believe these are the most effective actions you can take to build a stronger relationship with your Product Owner, thereby empowering them to excel in their role.

TLDR: Don’t work against each other; work with each other!

Prerequisites

• An IPv6 global prefix
• Root permissions on the host

A word of caution

The first thing to note is that running on an IPv6 only host, it means that only v6 networking is generally possible. So any communication running over v4 won’t be possible. For example lets try DNS resolution. If I try to get the IP for google.com on my IPv6 host I get the following response:

$ dig www.google.com

...

;; ANSWER SECTION:
www.google.com.		217	IN	A	142.250.186.68

;; Query time: 0 msec
;; SERVER: 2a01:4ff:ff00::add:2#53(2a01:4ff:ff00::add:2) (UDP)
...

One thing we can immediately see is, that the DNS server that answered our request has an IPv6 address, but what happens now if I tell dig to resolve the query via an IPv4 DNS server ?

$ dig @1.1.1.1 www.google.com
;; communications error to 1.1.1.1#53: timed out

The request timed out as we expected because our host is not capable of using the IPv4 protocol. The same behavior will be observable in our Docker containers unless we explicitly tell Docker to run in IPv6 mode. So, let’s get going!

Configure the docker daemon

To configure the daemon(assuming you use dockerd), we need to edit the daemon.json. On linux hosts you can find the file under /etc/docker/daemon.json, if you’re running on another system consult the documentation of docker engine. If the file does not exist simply create it.

In order to fix the problem with the DNS resolution we need to tell the daemon to use IPv6 DNS servers. In this scenario I provided cloudflares DNS server. Additionally, we also instruct the daemon to enable v6 networking, as well as creating the default network with ULA addresses.

{
  "IPv6": true,
  "fixed-cidr-v6": "fd00:dead:beef::/48",
  "dns": [
    "2606:4700:4700::1111",
    "2606:4700:4700::1001"
  ],
  "ip6tables": true
}

Retrieving the prefix

To make your container globally reachable, we have to create an IPv6 network based on the global prefix of your host. In simplified terms, the global prefix is a 48-bit unique prefix that is used to route packets to your network. To find your IPv6 global prefix, you can execute ip -6 addr show. You want to search for a similar entry like this:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
   ...
    inet6 2a01:4f8:1c0c:66b3::1/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
   ...

As you can see, my hoster assigned me a /64 prefix. That means that the first 64 bits of the IPv6 address are fixed. So, in my example, 2a01:04f8:1c0c:66b3 is the fixed part. If we would fully write out the IP, it would look like this 2a01: 04f8:1c0c:66b3:0000:0000:0000:0001.

Creating the IPv6 network

Now let’s choose a smaller subnet for our public network. For example lets choose a /80 subnet like 2a01:4f8:1c0c:66b3:1::/80 . This will ensure containers in that network will receive a globally routable address, which means that those containers can be reached from the outside, unless blocked by a firewall or something similar.

$ docker network create --IPv6 --subnet 2a01:4f8:1c0c:66b3:1::/80 public

Run your container

Last but not the least run a container and attach it to our public network:

docker run --rm --network public -p [::]:8080:80 traefik/whoami

And if we now have a look at our container it has been assigned a globally routable IPv6 address. That we can reach from the internet.

$ docker inspect 31cb810f7c00
...
            "Networks": {
                "public": {
                    ...
                    "IPv6Gateway": "2a01:4f8:1c0c:66b3:1::1",
                    "GlobalIPv6Address": "2a01:4f8:1c0c:66b3:1::3",
                }
...