Reading List

A good overview of what to look out for when writing, technical or otherwise.

A good guide to gain small and big wins.

An interesting view of how the world changes from solving problems to supporting others in solving problems.

There’s nothing more powerful than a developer with a good debugger and the knowledge of how to use it.

Admittedly, I’m often too positive on assumptions and not sceptical enough. This is a good article to help fix that or change the approach.

Another article of why Microservices might not be the right solution to your problem.

I aspire to at least have a pull request with those features.

Generous use of git rebase make it possible for very commit.

This requires some planning ahead and cleanup but makes reviews now or later so much easier.

In my career I’ve been all these roles at one point or another, but at smaller sizes. My current role fits neatly into the Team Lead. There are aspirations for Architect though.

A short overview for strategies on how to get better at debugging.

In short:

• know the code
• know your tools
• know yourself
• know how to approach problems

A guide on how to share the network namespace with another container. This is how a Pod in Kubernetes contains multiple containers. If you’re not working with Kubernetes but e.g. with Docker or docker-compose, this works in the same way pretty much.

TDD often makes your design better!

My point is that it can also make your design worse. Some TDD is better than no TDD, but no TDD is better than excessive TDD. TDD is a method you use in conjunction with other methods. Sometimes you’ll listen to the methods and they’ll give conflicting advice. Sometimes, TDD’s advice will be right and sometimes it will be wrong. Sometimes it’ll be so wrong that you shouldn’t use TDD in that circumstance.

It’s one of many tools you have at your disposal, but like any of them it’s not the panacea that solves all your problems.