Continuous Delivery is not a starting point in software development. It is where teams naturally end up when they push for high performance.

It is not something you adopt overnight. It emerges as a consequence of constantly refining and optimising how you work.

This is why debates over feature branches versus trunk-based development often miss the point. The delivery model is not a fixed choice. It adapts. As teams strive for higher performance, they gravitate towards what works best.

A long time ago, someone asked me in an interview: “What is the biggest problem in software development?”

It was a broad, open-ended question. I gave an answer at the time, though I honestly cannot remember what it was. What I do know is that I would not give the same answer today, being older, having seen and experienced more.

The biggest problem I can see now is poor end-to-end quality management.

As a software engineer, I don’t want a digested problem presented as “requirements.” I want the raw problem itself.

A common mistake I often observe in software companies is product managers taking on the role of managing teams and dictating requirements.

Software teams don’t need requirements; they need clear problem statements. The role of a product manager is to identify and articulate the right problems to solve.

The team will then collaborate to analyze each problem and design a solution.

There are a few Rustaceans (the silly name that Rust cultists have now given themselves) who keep posting against those “dinosaurs” who still use C or C++ and refuse to bow to the undeniable superiority of Rust and be assimilated.

As usual, a potentially valid message is completely undermined by the messengers.

I do not know Rust, but one of my goals this year is to gain a good understanding of it. The issue is that these zealous and almost fanatical behaviours do not help, especially when coming from people with only two or three years of experience.

I have a deep appreciation for Dr Neil deGrasse Tyson, astrophysicist, author, and science communicator.

He has spoken about the immense challenge of sending something into space, particularly the need to overcome Earth’s gravity.

When trying to break free from our planet’s gravitational pull, weight becomes a disadvantage. Space-bound artefacts must be made as small and light as possible.

This challenge drives miniaturisation, which has a significant impact on other fields, such as medicine and materials science.

I’ve tried for a long time to resist diving headfirst into this incredibly boring discussion about whether or not AI will replace software developers in the future.

I keep reporting the countless posts flooding my LinkedIn feed on the topic, but since it’s a platform that works terribly, they inevitably show up again the next day.

I said it before: my opinion is that the world of programming will change. It’s technology, and technology has always gone through evolutions. That’s how it’s been since the Stone Age.