Blog on Uwe Friedrichsen

Rethinking job-ads - Part 2 In the first part of this two-part blog post, I explained why I think most job ads today are rather pointless and are not particularly helpful in finding the people you need.

Rethinking job-ads - Part 1 Sometimes I read through job ads and almost always they leave me a bit at a loss.

Forget efficiency Should we really forget efficiency?

ChatGPT already knows - Part 7 In the previous post, we explored why we need to be a bit rebellious to take the road towards becoming a “full-range engineer”.

ChatGPT already knows - Part 6 In the previous post, we discussed what it needs to become a “full-range engineer” and have seen that this is quite different from what software engineers often strive for today.

ChatGPT already knows - Part 5 In the previous post, we examined how the omnipresent hyper-specialization in IT pushes software engineers into areas of human weaknesses and how nerd culture (involuntarily) reinforces the push.

ChatGPT already knows - Part 4 In the previous post, we discussed what humans and AI solutions are (not) good at and have learned the strengths and weaknesses of humans and modern AI solutions basically complement each other.

ChatGPT already knows - Part 3 In the previous post, we discussed where we came from as an industry, where we currently are and what the job of a software engineer (should) comprise.

ChatGPT already knows - Part 2 In the previous post, we discussed that detail knowledge, one of the major differentiators in software engineering careers, ceases to be a differentiator due to the growing capabilities of modern AI solutions.

ChatGPT already knows - Part 1 At the moment, we see a lot of discussions revolving ChatGPT and other modern AI tools like, e.g., GitHub Copilot.

Let’s (not) break up the monolith - Part 2 In the previous post, we started with the observation that companies (still) want to break up their monoliths into microservices.

Let’s (not) break up the monolith - Part 1 Time and again clients approach my colleagues and me with the request that they want to break up their monolith into microservices and they ask us how to do this best.

Reality check Recently, I had two experiences within a few days that made me think regarding system dependability.

The tail at scale About a decade ago, Jeffrey Dean and Luiz André Barroso published their IMO great article “The tail at scale” in the Communications of the ACM 1.

Watch your time - Part 2 In the previous post, we identified time as our most precious resource.

Watch your time - Part 1 This is my 100th blog post and the first post, I release in 2023.

Keeping the balance In this last post before the end of the year 2022, I would like to discuss a bit more general topic.

Towards greener requirements I did not yet write a lot about sustainability in this blog.

People only change in pain - Part 2 In the previous post, I discussed that people tend to embrace change the more likely, the worse they experience their current situation or expect their future situation to become if they do not change.

People only change in pain - Part 1 In a previous post, I discussed that the decision process, if confronted with change, is not rational but rather a gut decision.

The right dose of resilience We have discussed the business case for resilient software design in my previous post.

The business case of resilient software design The business case of resilience is a bit tricky.

The missing ops-dev feedback loop I recently had a short discussion with a Product Owner after a talk I gave about resilient software design.

The 100% availability trap I briefly mentioned the 100% availability trap in a prior post.

Why we need resilient software design - Part 5 In the previous post, we discussed why the imponderabilities of distributed systems will hit us at the application level and we cannot leave their handling to the operations teams as we did in the past.

Why we need resilient software design - Part 4 In the previous post, we discussed availability, and how more nodes and the effects of remote communication affect it negatively.

Why we need resilient software design - Part 3 In the previous post, we discussed what distributed systems mean in terms of failure modes that can occur and what their concrete consequences are regarding application behavior.

Why we need resilient software design - Part 2 In the previous, introductory post why we need resilient software design, we discussed the stepwise journey from isolated monolithic applications to distributed system landscapes where applications continually

Why we need resilient software design - Part 1 In this post series, I will discuss what resilience means for IT systems and why resilient software design has become mandatory.

Resilience vs.

Resilience - A new paradigm for the 21st century Resilience IMO is a huge topic.

In search of a robust change model Change is hard.

The public cloud revolution - Part 2 In the previous post we discussed the evolution of the public cloud offerings from their beginnings until around 2015, starting at the plain compute and storage level and working their way up to the PaaS level.

The public cloud revolution - Part 1 Discussing with other people, I often realize that many of them have not yet understood how much of a revolution public cloud is.

Leaving the rat race - Part 6 In the previous post, I gave a few recommendations how to deal with the hype industry and leave the rat race.

Leaving the rat race - Part 5 In the previous post we discussed the actual strengths of humans and how the FOMO 1 cycle tends to play against it.

Leaving the rat race - Part 4 In the previous post we discussed that most of the “innovation” hype is nothing but a distraction from our actual problems.

Leaving the rat race - Part 3 In the previous post we discussed that we are by far not as “innovative” as we claim to be, that most of the innovation puffery comes from a hype industry, trying to lure and force people into buying their products and servic…

Leaving the rat race - Part 2 In the previous post we discussed the omnipresent FOMO and the resulting feeling of continuously running a Red Queen’s race for many of the affected people.

Leaving the rat race - Part 1 Recently I got a comment in a brief Twitter discussion that really made me think.

The non-existence of ACID consistency - Part 4 In the previous post of this little blog series, we discussed the actual value of strong ACID-like consistency.

The non-existence of ACID consistency - Part 3 In the previous post of this blog series, we discussed why the “strong consistency is needed for business reasons” requirement is void.

The non-existence of ACID consistency - Part 2 In the previous post of this blog series, we discussed why strong consistency across multiple distributed data nodes is a bad idea.

The non-existence of ACID consistency - Part 1 Well, of course ACID consistency exists – and it is a good thing that it exists.

The disruption delay This blog post is about an observation I made pondering the slow adoption rates of several technologies in IT that I consider being game changers.

The limits of standardization Standardization is a two-edged sword.

The non-functional-no-value trap This post is about another “evergreen” in IT: The fallacy that only business features have business value.

People are not resources It is summer.

The industrialization of IT fallacy Probably you also heard it several times before.

Quality - The unknown entity - Part 4 This is the fourth and last post of a blog series discussing quality.