The IT Blog

“Ask for forgiveness, not permission” – The Real Cost of Moving Too Fast

In Germany, there’s a saying: “Besser um Vergebung bitten als um Erlaubnis fragen” (“Better to ask for forgiveness than permission”) or “Gleich mal Fakten schaffen” (“Make decisions fast and set facts”). These phrases often glorify quick action, suggesting that speed leads to progress and success.

Well, I can tell you right now — I really hate that mindset. It may look like a shortcut to success, but in reality, it often creates a mess that no one talks about. The consequences are rarely considered in the rush for fast decisions, and I’ve seen more harm than good come from it. What starts as quick success ends up piling up technical debt, inefficiencies, and unseen costs that will have to be dealt with – sooner or later. And like financial debt, technical debt piles up quietly, and the longer you delay paying it back, the more difficult it can get.

LLM-Search is a bit more than just “AI” – Podcast recommendation

Last week I heard the podcast SoftwareArchitekTOUR – Episode 102: Zuverlässige KI-Architektur from heise online. (german only, sorry).

I really liked the part where they discussed the technical part for a sematic search. Especially when it struck me, that the actual use of LLMs is just once per document and not in the search directly. Also, it suddenly became clear to me why you want/need a vector database for such an AI supported search.

Check it out if you can understand german or try to translate it.

8 Years in my Current Company

At the beginning of the month, a colleague reminded me that I had been with the company for 8 years now! A little anniversary! I reflected about the past years when at the same time a recruiter message reached me, what my motivation would be to “leave my comfort zone“.

Before being here, I changed jobs about every 2 years. The team was always great – super lovely people that I still miss, but I felt like I couldn’t improve anymore, I felt stuck and I felt like I wasn’t adding value to the company any more – and I then did the necessary steps.

It was the first time I joined a larger corporation. And obviously something was different here – otherwise I wouldn’t have stayed so long, right? So I started reflecting what I did all those years long. Was it worth staying? Am I, perhaps, settling into a comfort zone?

How to add SSH public key authentication in Linux

It’s pretty easy, but every time I have to look up the right permissions for .ssh and the authorized_keys file. The solution is described on StackOverflow and the OpenSSH FAQ:

mkdir ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# now paste the user's public key here:
cat > ~/.ssh/authorized_keys

done.

New 6-days Validity of Let’s Encrypt Certificates

I just saw this great news: Let’s Encrypt Announces 6-day Validity Certificates

Let’s Encrypt, the non-profit certificate authority, has introduced six-day validity certificates, commonly referred to as short-lived certificates.

Shorter validity periods are great for security. Traditional certificates can last up to a year, meaning if they get compromised, they remain a threat for a long time. Short-lived certificates, reduce the window of opportunity for attackers: Even if a certificate gets compromised, it will become invalid in less than a week.

Josh Aas, Executive Director of Let’s Encrypt’s parent organization, the Internet Security Research Group (ISRG), emphasizes, “Short-lived certificates practically require automation… automating certificate issuance is crucial for improving security across the web.”

Oh yeah. I couldn’t agree more.

Office makes decisions faster … Really?

Just two days ago I wrote about the Dell CEO who did an RTO to improve speed (among other things) because decisions in the office could be made so much faster…

That might be the case – in some edge cases. Just this week I had to think about this false narrative of fast decisions in the office because we had a very similar experience:

Dell CEO has forgotten how telephones work

I just read on heise online about Dell Orders All Staff Back to the Office 5 Days a Week: Read the Memo – Business Insider.

“Oh I’m curious about the reasons” I thought. And the article is really fun to read. This has the potential to be a #BullshitMonday story:

“What we’re finding is that for all the technology in the world, nothing is faster than the speed of human interaction,” [CEO] Michael Dell told staff. “A thirty-second conversation can replace an email back-and-forth that goes on for hours or even days.”

Uhm, okay. You’ve got too much email back and forth. I can SO understand that. But … has he ever heard of this … telephone thing? You can talk to remote people in real time. It’s like true magic!

And I just imagine being in the office needing some clarification for something: So I first look up where the person’s office is, I walk there, likely I won’t find that person because – well – (s)he is also clarifying things, or I just interrupt the person, have a chat and walk back. 30 seconds with an overhead of 5-10minutes.

Oh and .. let’s not even discuss WHY there are so many eMails. Can’t be lack of / unclear responsibilities, fear of taking decisions, bad processes, bad adoption of technology – nooo, never. O-M-G.

Don’t Believe Everything …

We’ve all been there: listening to a talk, podcast or reading about groundbreaking innovations, especially on LinkedIn. It all sounds fantastic, super new, cutting edge technology – almost too good to be true. And often … it is.

Overselling seems to be more common lately – or maybe I’m just noticing it more? Especially with the AI “trend” lately, everyone is “AI first” and doing extremely successful programmes – it seems. But when you get to know someone in the tech field directly, it turns out that we’ve just seen a proof-of-concept project, a project that was stopped after a while for various reasons (didn’t bring the expected results, was over budget, or was never intended to go live at all), or that it is just WAY more complex than illustrated and only the very tiny cool part was told.

It also seems like a pattern to me: The higher someone is in a company, the less reliable their statements are. C-level executives sell visions, middle management sell their successes / themselfes, while engineers are more likely to tell the real story (tech debt, failed experiments, complex architecture and hard compromises).

I think I’ve developed a healthy(?) scepticism. The first questions I ask myself are Who is telling the story (position)? Why are they telling the story (promoting the technology, promoting themselves, promoting a solution)? What is not being said?

The truth seems to be often in the gaps … unfortunately.

Tim Berners-Lee is on Mastodon

I’m hardly following any very well-known people on any social media – but I was positively surprised to see Tim Berners-Lee (@timbl@w3c.social) on Mastodon! Well for the unlikely event that you don’t know what we owe him, check out his Wikipedia entry:

Sir Timothy John Berners-Lee (born 8 June 1955),^[1] also known as TimBL, is an English computer scientist best known as the inventor of the World Wide Web, the HTML markup language, the URL system, and HTTP.

Kill It with Fire – Manage Aging Computer Systems

I just noticed that I never made a book recommendation, even though I’m reading quite some books – well okay, not too many IT books to be honest. A while ago a – very valued – colleague recommended Kill It with Fire – Manage Aging Computer Systems to me.