Reading List

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.

Finally I found the missing link to set up EDID overrides on Big Sur and later, where System Integrity Protection (SIP) is enabled.

In short, MacOS also takes overrides from the path /Library/Displays/Contents/Resources/Overrides, which is admin writable.

Most companies and projects are by far not big enough to benefit from microservices, and not good enough to deal with the implications and repercussions. There’s a reason “distributed systems” are hard: it’s the next difficulty level after multi-threaded concurrency — harder to observe, harder to reason about.

The aspect of “transaction cost” for doing a particular thing once or multiple times is interesting.

Starting a bunch of things in parallel will often lead to many being finished at a similar point in time, often all at once and leading to the dreaded ‘big bang integration’, which even in short sprints may be painful enough already.

That said, I love starting multiple things at once. Sometimes being ‘stuck’ on the same thing and not having some other outlet or diversion to put your mind to makes a task take longer. Having the ‘diversion’ often gives me more energy to breeze through the other task… and sometimes it doesn’t. It’s not scientific.

A follow-up to the question whether we do REST wrong that provides examples of what constitutes a fully RESTful service.