Software Engineering

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.

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.

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.

And here I thought I knew full well what RESTful APIs had to look like. The constraint in my head was that individual resources (e.g. items in a database) should have their own URL and you used the HTTP verbs (GET, POST, DELETE, etc.) correctly.

What was missing from that is the Hypermedia aspect, where each response defines the appropriate URLs for the possible next steps.

“Be an engineer, not MacGyver.”

An interesting look at how long lead times from idea to specification to implementation to release can cause waste in the software development process.