wiechtig

Depth over Noise #3

Florian Wiech — Sun, 14 Sep 2025 24:00:00 GMT

This time, I have a mixed basket of topics. Let's get started.

Supply chain attacks are underrated #

Within software engineering, one of the most significant threats that can impact the entire industry is supply chain attacks. The industry recently saw two of them, but got quite lucky in the process. It's always interesting to inspect the vectors of these attacks.

The first one was an injection attack via the delivery pipeline. It's fascinating to see how this was possible by using products where you might not typically consider this type of threat.

Social engineering caused the second. Please ensure you're using a password manager and enable two-factor authentication (2FA) on all accounts you use. Also, create custom, random passwords for each service. Then, please be extra cautious about the emails you receive and take security-related action only when you're focused on the subject, rather than mindlessly checking boxes.

Here are the latest ones, the industry talks about:

Don't build your castle in other people's kingdoms #

Such an important business lesson: Don't build your castle in other people's kingdoms. I love the post for its clarity, showing the issue with actions and rules to prevent them:

In the past ... social media sites have changed their terms or introduced suspicious paid plans ...
Every single year one social network or another pulls a stunt like this. Somehow people are still shocked when it happens.
Don’t be.
It isn’t a matter of if, it is a matter of when. They don’t care about you. You must market your game [website, etc.] as if the platform you are using will go away tomorrow and you will lose access to some or most of your followers.

And the rules he derives from it:

Rule #1: Build your castle on land you own.
Rule #2: Shamelessly use the other kingdoms just like they are using you.
Rule #3: Always move people back to your kingdom, never to another kingdom.
Rule #4: Operate like your castle can get shutdown tomorrow.
Rule #5: Be suspicious of new kingdoms that give away easy visibility.
Rule #6: Give good reasons to go back to the Castle in your Kingdom. And be persistent!

The problem of building your castle in another kingdom is highlighted in a great comic:

This is one of the reasons I have my own independent website instead of relying on publishing platforms (like Medium, LinkedIn, DEV Community, Substack, etc.). Within this platform space – with the same issues – there is a new player with a new approach:

Substack's publishing platform with prestige and marketing traps #

Substack positioned itself as a publishing platform like many others (Medium, DEV Community, Ghost, Beehiiv, WordPress, etc.). Yet, Substack tries to go down its own route through marketing. This marketing approach opens new doors for them, but not without raising concerns.

The trouble with Substack's marketing explains John Gruber in the article The Substack Branding and Faux Prestige Trap. It shows the branding tactic in action:

Substack is a damn good name. It looks good, it sounds good. It’s short and crisp and unique. But now they’ve gotten people to call publications on Substack not “blogs” or “newsletters” but “substacks”.

The article Don’t Call It a Substack highlights, why this is a problem:

Imagine the author of a book telling people to “read my Amazon”. A great director trying to promote their film by saying “click on my Max”. That’s how much they’ve pickled your brain when you refer to your own work and your own voice within the context of their walled garden. There is no such thing as “my Substack”, there is only your writing, and a forever fight against the world of pure enshittification.

Then, back to John Gruber's article, he concludes:

... writes for Substack, formerly with The New York Times. Thanks so much.

...[The author] does not “write for Substack”. No one would say that Jason Snell “writes for WordPress”, or that Jason Kottke or yours truly “writes for Movable Type”. No one says Molly White, Casey Newton, or Craig Calcaterra “writes for Ghost”, or that Oliver Darcy “writes for Beehiiv”. Only with Substack does anyone perceive creator branding as being subservient to the platform — something that ought to be seen merely as an interchangeable CMS — like that.

Random Reads #

Remains of the Day wrote two pieces I liked a lot. The writing style immediately captivated me. I delved into each subject and learned a lot. I can highly recommend these articles. Perhaps I will revisit them in this newsletter someday, providing my highlights from them:

Invisible asymptotes: His journey working for big tech and how so-called S-Curves are a thing.
Selfies as a second language: Reviewing interesting patterns in social media, like: "When I send a Snap [selfie] to any of the people in my address book, the oldies respond, inevitably, with some text message, maybe an emoji if they're somewhat hip. If I send a Snap to a young'un, inevitably I'll receive a selfie in response."

Bartosz Ciechanowski creates deep dive articles about various topics with crazy good 3D-showcases you can explore on your own, highly recommended:

The Uncharted Territory has a GeoHistory section, providing interesting reviews attached with data:

Comic and meme sites:

Depth over Noise #2 – Software Engineering Practices

Florian Wiech — Sun, 31 Aug 2025 24:00:00 GMT

I'm writing this while sweating my pants off during a heatwave in Frankfurt am Main (FFM) in Germany. It feels like there is no pleasant summer temperature anymore. Either it's rainy, windy and cold, or we're in the middle of a heatwave. Both hinder me from enjoying time outside. Climate change is a thing. Anyhow, let's get started.

This time, we're examining several software engineering practices. Since this is what I do for a living, I can fill books here. However, I have a couple of references I want to share with you today. A small collection of posts I picked up in the past and still remember, because they aligned with my learnings working in the field.

Greppability is an underrated code metric #

It might seem natural in development to abstract things. But from an operational perspective, especially in complex systems (which many merge into), greppability is more critical than not repeating yourself (DRY). Let's elaborate on that a bit.

From a development perspective, people favour flexibility by encapsulating components. It promotes separation of concerns. They create variables and use them later on. It helps to simplify things, reuse components and avoid errors. They construct things like names, keys, URLs, etc., which enable changing values only in one place.

But, from an operational perspective, it all looks very different! Dealing with much unfamiliar code, I find myself constantly searching inside the codebase. I'm looking for path URLs, error messages, function names, and other relevant details. This is especially hard when these are constructed from various variables.

This behaviour even led to production incidents at work: Someone deletes some code because it appears to be unused, as determined by grepping the codebase. To find out afterwards that there is a hidden usage somewhere, weirdly constructed from variables. But what about typing? In a distributed systems world, you often don't have that. Grepping is your only option.

This article brings this concept to the point, and it discovered some essentials to look out for:

Don't split up identifiers
Use the same names for things across the stack
Flat is better than nested

Ideas on how the tech industry can do better #

I found a piece where someone shares his insights after working for decades in the tech field. I want to share it because it holds many lessons I have learned myself. Let's go through them.

Know what the need is #

I wrote about my journey learning how product development works. Collaborating with engineers in my daily business, I see that not everyone shares this understanding or is interested in it. Due to this phenomenon – developers building products they know nothing about – I find the learnings within this article quite familiar. The article even starts with: Almost everyone I know in tech does not think of tech the way that I do. Nailed it. Here are the highlights:

There is a difference between thinking you understand your customer‘s needs and actually knowing that the customer has that need.

If you cannot clearly identify a customer need, then you cannot define the solution that you need to create to meet that need, and you shouldn’t start anything until you do.

Principle: Meet the need as simply as possible. Understand and meet the need and only the need.

Principle: Use the shortcuts Luke! Your solution is about how to meet the Need you have identified.

Your solution is not about how clever you are as a programmer. Your solution should not be about ensuring that you keep your job by making it impossible for others to understand what you have built…

Do not build things yourself that other people have built and are cost-effective to use.

Build to maintain #

Next, we're in the development versus maintenance area. I have seen both worlds and done a fair share myself. I developed and shipped products from scratch, operated 24/7 products for millions of people, and untangled legacy code. Hence, my previous section in this newsletter was about the importance of greppability in operations. This is why the section about maintainability is essential:

Principle: Build to maintain because maintenance is far far more painful than initial build

What almost nobody is good at is understanding the level of maintenance required for the solution once built.

Reducing maintenance time is a fundamental good in every single project, and if you can prove that increasing the amount of initial build time is very likely to achieve a reduction in maintenance then longer builds are a reasonable price to pay.

If the new solution is easier to maintain, because it was built to be maintained more easily, then the conversation changes and the risk changes.

Principle: Understand how the solution can be retired and/or replaced

One of the reasons I think that people who do not understand technology struggle to understand the costs of technology is because, as an industry we are very bad at knowing when to replace a solution.

Identifying when to replace a solution should be regularly considered and should have some accompanying metrics.

A team with the best intentions cannot maintain a solution forever, whatever that solution is.

You work with humans, treat them that way #

And last but not least, people are humans, not resources! I believe it is vital that everyone respects that and invests in healthy relationships among coworkers:

Principle: Teams are people not resources

I had a principle as a startup CTO which was that my team only needed to do 6 good hours in a day, and it was up to them when they finished. It was informal and not a “hard and fast rule”, but it was important. If someone felt they’d done good work, and wanted to go home early, then they absolutely could. That startup produced some of the most effective and efficient people I’ve ever worked with in tech. It wasn’t perfect, because nothing ever is, but I like to think that people were happy there. I’d far rather have that, than a lot of people stressed about hitting a deadline. It was a better attitude than most companies I’ve worked in (I may be delusional here too!) and the team was not put under pressure by me. We still delivered what we needed and often well before it was needed.

Look after people, and they will look after you and the company. It’s not a family, it’s a job, so treat people with respect.

I am very willing to accept that I don’t know everything, but I am not going to accept that people can’t do things because they aren’t used to them. People can learn things, and adapt. There is nothing that says that the way we used to do it in the tech industry is always “right”.

We're post-industrial and forget efficiency #

The personal blog from Uwe Friedrichsen is a must-read. I really appreciate his perspective and the way he conveys it. Today, I brought two special ones I highly suggest you pick up: The evolution of markets and Forget efficiency. Let's explore them.

The evolution of markets #

In this foundational article, he explains how the market changed over the years and how it affected the work within it. He goes through the pre-industrial, industrial and post-industrial eras and each's core properties:

Market phases on the timeline by Uwe Friedrichsen

As interesting as he describes the pre-industrial markets, the central one I want to examine is the transition from the industrial to the post-industrial era. For deeper insights, go to his article; it's really worth a read. Here are the main highlights so that my thoughts afterwards make sense:

In an industrial market, demand is a lot higher than supply. As a result, sales are certain. It is defined by the following properties:

High-volume markets

Low customization of goods

Supplier-driven

Low dynamics

In a post-industrial market, supply is a lot higher than demand. As a result, sales are uncertain. It is defined by the following properties:

High-volume markets

High customization of goods

Consumer-driven

High dynamics

This differentiation is very, very important. With this in mind, remember my earlier learning: "know what the need is" with product development driven by consumer needs? Given that we operate in a post-industrial market, this approach is crucial. Yet, so many companies and individuals (including myself more often than I would like to admit) are trapped in the industrial environment with the saying "just build it and they will come". But that is not reality anymore.

It is also interesting to see which companies understood this, transitioned accordingly, and which, even today, remain stuck in industrial thinking. Having worked within various industries, I've had the opportunity to observe multiple companies from the inside.

From my perspective, this ultimately comes down to market pressure. When they're the top seller in a regulated industry, already owning a lot of contracts, life is good. The future might not look that bright, but as long as the revenue is good today, there is rarely a need for real change. It is that tipping point, when revenue is affected, and the foot really hurts. That's when companies actually go to work. Sadly, this is often too late and causes bigger troubles than necessary. But that's just the nature of human beings.

Forget efficiency #

The article Forget Efficiency discusses how companies prioritise efficiency – optimising internal processes. While efficiency is excellent in the industrial space, in the post-industrial world, it creates far more software than necessary, which ultimately becomes waste. That is why it highlights a lack of effectiveness – searching for the right thing and doing only that.

I already shared quite a few learnings myself in my the efficiency trap article. That's why I'll keep this section rather brief and suggest reading this article for further insights.

Valuable lessons on platforms #

From all the way back, when Google+ was a thing, a Google employee wrote a manifest claiming that platforms are a thing. Google+ was a social media network which failed. The Google employee wrote this letter for internals only. Due to the weirdness of Google+, he unintentionally posted it publicly. We can actually thank Google+ for being able to read it. Thanks to this phenomenon, he wrote it bluntly, directly, and in a funny way to read.

Please note that this was written many years ago; since then, a lot has changed. Therefore, read it more as an entertaining history lesson. Looking at the content itself, it perfectly sums up the power of platforms. The oft-quoted letter by Bezos from the early years, shifting the company to a platform-first approach:

So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses. His Big Mandate went something along these lines:

All teams will henceforth expose their data and functionality through service interfaces.

Teams must communicate with each other through these interfaces.

There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

Anyone who doesn't do this will be fired.

Thank you; have a nice day!

Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.

Number 7 is a good one. I don’t care whether it’s true or not. I just had a good laugh about the last part. At the end, he went about his learning about platforms:

The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.

The simplicity curve #

A colleague shared "the simplicity curve" in a presentation. I came, I saw, I loved it. It's in German, and it seems that it took some refinement to get the proper wording. I translated it into English for this newsletter. Please apologise if the wording isn't as precise and fitting as the original. Here it is:

The simplicity curve version 3 by Gunter Dueck

I suppose there's no need to explain. Upon reading it, I immediately thought of several uses. I observed my past experiences and checked where the solutions fitted on the curve.

I especially love the "stupidly simple: so simplistic" and "ingeniously simple". It is truly mind-blowing when solutions serve many people and rely on simple foundations. That's the real genius. Everyone is blown away by asking how that could ever work, and yet it works and has worked for so long, proving it every day. These cases are truly revolutions.

You need an example? Sure, how about computer science? Everything operates on zero and one. It all comes down to that. It's crazy how you can use this small foundation and change the way everyone behaves.

As far as I got it, this concept is from the book "swarm stupid – We're only this stupid together." by Gunter Dueck. I haven't read it, so I can't comment on it. But, damn, just that title is a statement that gets my attention.

That's it for this one. I guess this was a longer one. As I mentioned earlier, there is plenty to discuss in this space, and this is just a tiny collection. I hope you've enjoyed the learning as much as I did. See you soon. 👋

Depth over Noise #1

Florian Wiech — Sun, 17 Aug 2025 24:00:00 GMT

I'm going to try something new: a newsletter featuring a curated collection of articles, quotes and more that I find interesting, insightful and worth sharing.

I enjoy reading and discovering things. There are quotes in other articles delivering a message better than I could. I want to share that. Instead of dumping them to social media – and adding more noise – I would rather embed them into context. This gives me room to explore the depth of the message, providing more thoughts, views, data, analytics or whatever is suitable for it.

For now, I plan to publish at irregular intervals, when I have something to share. Let's get started.

The real skill is to know when to dive deep and when to skip the details #

Within the context of agentic coding, this article states that these tools are slot machines. You put in the task you want to achieve, and then you wait for the output and see whether it does what you wanted or not. When it works, great, you head to the next task. If it doesn't, you may put in more money and try again, hoping for a better outcome. If you're not making progress, you'll take the time to analyse, understand and do it yourself.

Besides the message of the post, I love this learning, I couldn't express myself better:

Early on in my career, someone much wiser than me described two modes of operating: the Conjurer and the Scribe. The Conjurer is a wizard, creating realities out of thin air, working in broad strokes and never going deep. The Scribe reads every line of the text, and every line it refers to, understanding everything to its deepest and fullest extent before acting. Some of us tend more towards one way of operating or the other. Both are critical.

But the real skill, the real thing that makes you effective, is knowing when to use one mode or the other, and being able to switch between them as needed. When does understanding matter? When should we skip it and move onto the next thing? In a field with endless and important detail at every level, we have to both “let it go and move on” and “slow down” constantly.

Back to the future: From text back to the spoken word #

A section within a German newsletter about the situation of journalism got my attention. It starts with a classic, well-written quote regarding the internet and masses of content these days:

What does it mean to live in a world of virtually infinite and ever-growing content? We see the result every day: a relentless race for attention, whether in social media, journalism, or on the web. A huge long tail of content whose lack of visibility is tantamount to non-existence.

Going further, when considering newspapers and social media, my thoughts were always focused on the different media types, including text, images, and video. But that it represents a different orientation is something I haven't thought about before:

While orality was oriented toward relationships, literacy is oriented toward objects. Accordingly, as Walter Ong points out, the distinction between orality and literacy does not represent an evolutionary progression from “primitive” to “civilised.” Instead, it brought with it both gains and losses. Oral cultures embodied liveliness, creativity in presentation, a sense of community, and dynamism. Conversely, literacy means critical thinking, individualisation and autonomy, complex knowledge structures, and the globalisation of cultural forms of expression.

Now, heading to journalism itself. The author expects a declining relevance of text and complexity and growing importance of brevity, moving images, and emotionalisation and concludes:

Privately funded journalism finds itself in a dilemma due to economic constraints: if the audience develops into part of an oral culture, podcasts or videos may not do it justice. Instead, it will probably only be possible to do so if one fully commits to becoming an identity medium—in other words, a medium that limits its reporting to confirming particular worldviews, validating tribal affiliations, cultivating enemy stereotypes, and fueling conflicts. In the US, such a media landscape is already largely a reality; in Germany, we are beginning to see the first outlines.

Digging through the links of this newsletter, I ended up discovering how entertainment is evolving:

Pre-Internet 'People Magazine' Era – before social media, magazines with mass publication.

Content from 'your friends' kills People Magazine – private online bubbles between real friends.

Professional 'Friends' (also known as influencers) kill Real Friends – Professional friends spend all their time being pretty and amusing. They out-compete your actual friends on the entertainment they provide.

Algorithmic Everyone kills Influencers. – Algorithmically sourced content to your personal needs from 'everyone'; anyone can be viral today and irrelevant tomorrow.

Next is pure-Al content, which beats 'Algorithmic Everyone' – bet about fully personalised generated content created by AI.

Reports of the German inner circle of power #

During my summer vacation, I picked up all three audiobooks from Robin Alexander. He is a German journalist capturing political events and has deep roots in the inner circles of power. It is interesting to hear how individuals acted within the political debate of past events. I found it especially exciting, having lived through these times myself and noticed this from the outside.

For me, phrases like report of the inner circle of power carry a kind of cinematic weight. They don’t just tell you what the book is about—they make you feel it. It’s a promise. The place where decisions are made, where power breathes and pulses behind closed doors, has just been opened up to take a look at. That phrasing elevates the whole thing. And these books hold their promise.

Anyhow, the books have great listening experiences. They were so exciting, I couldn't put them down:

Die Getriebenen (en: The Driven), published March 2017, (🇩🇪|€) Hugendubel, Thalia

The opening of the border to refugees in autumn 2015 divided the country – some praise Angela Merkel's moral stance, others condemn the surrender of sovereignty. However, what appears to be deliberate action is, in reality, a policy of muddling through, tactical manoeuvring, and vacillation, fueled by lofty ideals and opportunism. Robin Alexander shows that the political actors are driven, torn between self-imposed constraints and the rapid succession of events.

Machtverfall (en: Decline in Power), published June 2021, (🇩🇪|€) Hugendubel, Thalia, RTL+

At the end of her term in office, Angela Merkel faces what is probably her greatest challenge yet. But the chancellor, who has often risen to the occasion in emergencies, is reaching the limits of her authority in this crisis. According to Robin Alexander, the pandemic is just another spectacular chapter in an even greater drama: the end of an entire era. The book tells the story behind the scenes: of the tough, long battle within the inner circles of power in the republic and of the showdown over Merkel's succession, which almost tore her party apart.

Letzte Chance (en: Last Chance), published June 2025, (🇩🇪|€) Hugendubel, Thalia, RTL+

As the new chancellor, Friedrich Merz faces enormous challenges. Enemies of democracy, both internal and external, are preparing to storm the liberal order. The electoral success of populist parties threatens to blow apart the political centre. With Trump's re-election and Russia's advance, Germany's role in the world will change radically. Robin Alexander takes a look behind the scenes at one of the most decisive phases in German politics, in which a fragmented party landscape and a polarised public make stable majorities almost impossible.

I believe that written content – or any type of content – has an expiration date. Just as groceries have an expiry date listed on the packaging, every piece of content has one too. However, on content, there might only be the creation date shown. The content churn is highly dynamic and unclear. No one can look into the future.

When I put in the effort to write an article, I try to stick with content that has been around for a while. Readers should find in my blog archive articles that will remain relevant, whether you read them today or in a couple of years. This is why I choose content that I believe will stay up-to-date for as long as possible. It should convey a clear message that I can sum up in a sentence or two.

But these guidelines limit the content I can write about. I have a hard time writing about current events, news, or topics because the expiration date tends to be short.

What I like about newsletters, on the other hand, is that they are a snapshot of a point in time. They give me the room to explore all the things I missed for my articles. If some content prevails, great; it remains. If not, proceed to the next issue.

That's the reason why I try this experiment with “newsletters”. For now, it is just another post on my blog, with a familiar name across the series.

Git GUIs are far superior to the CLI

Florian Wiech — Sun, 10 Aug 2025 24:00:00 GMT

I see many developers swearing by the Git CLI. They can’t understand how anyone could ever think about using something different.

I know the baseline Git commands myself, but I would've trouble rebasing out of a branch merge conflict only using the CLI. For most kinds of git usage, I turn to a UI. It visualises everything I need all the time.

There are a couple of things where I think the UI has an edge:

I see the entire history and git log. It is a graph that I can inspect and filter. The git log is my default view.
I don’t have to type yet another command – not even the three char shortcuts everybody uses. All my local and remote branches are listed in the sidebar—no need for any command.
For interactive rebases, I see the entire history and move everything around until I’m happy. No need to do it in a strict order.

Git-Fork showing the graph, feature branches and recent code changes

How does this result in day-to-day operations? Somehow, I’m often faster at answering questions about the history and what has been done. Just because I don’t have to execute a few commands and interpret the result to gain an understanding what happened. I switch to the app. Everything is already listed.

Sometimes even the best engineers make mistakes (like accidentally creating these horrible “Merge branch …” commits). Often, I’m the one pointing it out, because I see it right there.

Overall, I find it very interesting how religious developers are about using git from the command line. Yet, through all the moving parts, especially the graph based history, it is a perfect match for advanced UIs.

To take anything from this post, it is this: Don’t be too religious. Find your workflow that suits your needs. Sometimes it is best to take the best aspects from two worlds. There is no shame in using a UI, quite far from it.

There is one git alias I appreciate, though: pfusch. Pfusch is a German noun and means to botch something. Many of us do this all the time by force pushing to the branch we're working on. The alias is the perfect combination of an actual word that is so close to the command. Anyway, here is the alias:

alias pfush='git push --force'

ClickOps: It's the worst

Florian Wiech — Thu, 20 Feb 2025 24:00:00 GMT

Me starting a project: Oh, cool, look at the gorgeous UI. I click everything together, until I’m done. Two years later, I want to change some features to keep the solution useful. Returning to the project, I realise the UI has been redesigned. I’m entirely out of luck to understand the default settings and my configuration. I have no idea what I’ve done before.

To update things, I have to relearn the UI and reverse engineer what I've done. This gets even more complicated when the solution involves authorisation. It is the perfect spot to change something that now leaks sensitive information or allows privilege escalation. A horrible place to be.

Configuring a system by clicking through a UI is called ClickOps between engineers. And we hate it. Through all my years of engineering, I learned: Never ever do ClickOps.

The better alternative is called Infrastructure as Code (IaC) and Configuration as Code (CaC). Use configs, check them into version control and automate as much as possible. It helps to

understand infrastructure without having access to the production systems,
replicate entire application environments with a click of a button,
rely on stable APIs instead of brand-related UIs that change frequently,
scale infrastructure without repetitive monkey work.

It sneaks in faster than you think. #

In various applications and software development environments, ClickOps quickly sneaks in without often realising it. In other words, it seems to be everywhere.

Cloud #

The most obvious ones are about infrastructure, especially the cloud. The core of the cloud is an API to deploy infrastructure. Yet, people use UIs to configure cloud environments. Why?

When you start with the cloud for the first time, the UI is the easiest and most straightforward way to get started. That's what the UI is for. You can explore, and you learn. So, no bad feelings here. But, building this way a production app is a bad idea. Please use Terraform, Pulumi, CloudFormation, etc. for infrastructure deployments or Ansible, etc. for low-level instance configuration.

Desktops #

In desktop development we use Visual Studio for Windows or XCode for macOS. These IDEs have buttons everywhere. Sure, these buttons change a config you can put into version control. Yet, the config by itself is internal jibberish. I can't read it without knowing about it's internals.

You find tons of articles^[1] explaining how to configure something, showing plenty of screenshots where to click next. These are great blog posts, but it runs cold down the back of my neck looking at all the screenshots. I have to search in a picture where to click next. It just feels wrong (so wrong). Luckily there is community driven work and advanced build systems which help to improve engineering practices.

Don't get me wrong, with a Linux setup, you get really weird commands. You have no idea what a flag does just by looking at it. For example, when configuring the SSH client Dropbear, use -s to disable passwords. What? Why s?! That makes no sense.

But this is a big one: When you work through the CLI, you end up with a shell script. It contains all necessary commands and comments for additional explanation. At best it highlights the version of the tools used. This setup can be executed, understood, recreated and even adapted in the future. It saves tons of time down the road.

And so many more #

There are so many more areas, which would blow up my article. Embedded development helps with some quick and easy setup of IDEs for beginners. They are great. Yet again, it'll hurt in the long run when you want to scale and go to production. And then there are so many legacy apps across all the stacks. They basically require ClickOps...

Shoutout to all providers offering an API, and shame on you if you don't #

Shoutout to all the providers and software vendors who embed APIs and IaC tooling for their customers. You rock.

For all others, by not shipping an API for your customers to use, you

slow down your customers. They can't innovate with you in a fast and scaled environment.
force your customers to ignore good engineering practices. It causes a complexity debt on their side.

Luckily, Developer Experience (DX) is an emerged job position. Startups heavily invest into it because they recognised the limitations listed above. Many of them who have to scale are on track here. But a lot of software is legacy, where it looks very different.

I have a list of some article examples which show images how to set something up. But I didn't link any of them, because it isn't their fault that they show screenshots. The authors did a great job. It's the providers building the ecosystem to blame. ↩︎

Open Source is a strategy, not a lifestyle

Florian Wiech — Sun, 09 Feb 2025 24:00:00 GMT

I see so many engineers dedicating their lives towards open source. They use their spare time to contribute to projects and push the boundaries of technology. For everyone doing this, I can say heartfelt thank you!

Due to the many people and organisations contributing to open-source, we can observe several behaviours in this ecosystem. Some of them are:

Maintainers are burned out because of the project's change requests and demands.
Maintainers don't get paid for their open-source work. They struggle to make a living from their efforts.
Companies change their license from being open to permissive.
Companies taking parts of their ecosystem open source as a sales channel for their paid offering.

Let me bring you on a short journey through some lowlights of the open-source ecosystem:

Only a tiny fraction of people can live from open-source #

People making a living from open-source only represent a tiny fraction of the entire open-source ecosystem^[1]. Others have a hard time making enough to survive the day, while their software is used by most major companies^[2]. Since there are plenty of developers working on open-source in their free time, many memes highlight their situation.

Maintainers struggle to get reimbursements for their efforts #

You might remember the xz backdoor issue in 2024. The timeline shows the xz utility is a widely used package maintained by a single person without reimbursement. It nearly caused a vast supply chain attack.

Another example is the core-js situation. It is a polyfill library for JavaScript applications^[3]. However, the maintainer has problems getting enough reimbursement for his efforts. This caused a lengthy article about his situation (with a ton of details I won't go into here).

Companies claim to be open but restrict the ecosystem #

We saw the VSCode Editor climb to the top, being the most used and loved one^[4]. It makes a big statement about being open-source. The Monaco Editor and the core VSCodium are publicly available. While focusing on product adoption via open-source communities, Microsoft built extensions and the marketplace with a proprietary license. Today, VSCode is a product with deep integrations for Microsoft commercial products^[5].

Companies changing their licenses #

Some companies start as open-source and monetise it after they gain traction. Sadly, this caused various changes in licensing in the past:

Elastic changing ElasticSearch to a proprietary “source available” license because of product confusion and opened it up a couple years later.
Terraform adopted a proprietary license due to its creator company getting ready to be bought by IBM. They restricted its usage, and companies building products based on it could no longer use Terraform. It forced the open-source clone OpenTofu.
Redis switching the license forced multiple open-source clones, such as Valkey.
In the WordPress ecosystem, two companies (Automattic against WP Engine) are fighting in the open to be the market leader.

Engineers doing open-source as a hobby #

On the developer side, it feels more religious: “My code is always open-source. I won't do these things. I believe in open-source.” On one hand, I like and can relate to that statement. On the other hand, we must recognise what a luxury it is to be able to say that. Through well-paid employment, we have a couple of hours each week to contribute. We can engage in these donation exercises. Not everyone is blessed with that. Most people have to make money to survive the day. For that reason, it's completely acceptable to ask for a payment in general.

Building something in your spare time, with the motivation to solve a need, is a great thing. If your solution gains traction and adoption, maintainers will continue to do what they have always loved: extend and maintain the project. But this has its limits. At a certain point, it's just too much for one person.

When a project gains traction, maintainers might not realise that the operating mode has changed. A single-person project turned into a venture that requires more effort. Other tasks, such as supporting others and establishing maintenance resources to handle the increased efforts, emerge. This is the point at which a maintainer should reassess the situation. For example: examine the project from a management or even business perspective. Or clearly express your situation without mimicking company communications spreading false beliefs.

A positive example I appreciate for their clarity is NetNewsWire. A publicly available RSS reader for the Apple ecosystem. There are tons of RSS readers, many even a paid offering. In this market, NetNewsWire clearly states they are not the free alternative. They want to make a great, free RSS reader but are picky and careful about adding features. They're not mimicking the features of other commercial apps. They’re glad those other apps exist because, among other things, those features have already been done, and they don’t have to do them.

Earning from open-source is hard #

Companies often turn to open-source to get away from license cost^[6]. Their goal is to save money. Their willingness to pay for open-source is already unlikely. This raises the question, how do you make money from software? How do you distribute software?

Marijn Haverbeke already faced these questions with his libraries. He has an excellent blog post highlighting options from closed source up to open source. Ultimately, he chose to go for open-source. He added a social responsibility. It means, when you use the software in any commercial, he expects that you set up a donation plan. It helps others to adopt the software and contribute to it quickly. He takes the risk of others taking social responsibility seriously.

As these sponsorships go, they have extremely low conversion rates. Evan You explains in an interview: Vue.js has 1.7 million users worldwide, and he (as the creator) has around 400 sponsors. These are often small companies. The boss is a developer who can afford to make a considerable monthly contribution.

Sponsorships are also a special kind of reimbursement. They primarily rely on a relationship based on trust. In general, there are no strings attached. You support a person because you think that this person does good work. However, this person alone decides what to do with the time or donation he or she receives.

This shows that it is hard to earn significant money with open-source approaches. So, how and why do companies move within this space?

Companies do it because "it's good for business." #

The Wardley Map highlights, that developing in the open is a strategic gameplay. There are several moves you can do:

Openly build the product's core to convince customers there is no "lock-in."^[7]
Drive adoption towards a commodity and aim to be the market standard. Done right, all competitors have to integrate your API.
Use it as a financial weapon to undercut proprietary on-premise software.
Offer a free tier (like self-hosting) to "lock customers in". When they need a sophisticated solution, paying for the service is the easiest and cheapest option.

Regardless of which strategy you use, the bottom line is that "it's good for business". For example, let's say you operate a massive tech platform. You provide open-source software tooling. Others use it and benefit from it. Even when they never use your product, it improves the overall market. It makes the internet a better place for business. This attracts new market participants that now may use your products.

Companies draft statements like "we love open-source" not because they love open-source but because they believe that loving open-source is good for business.

Conclusion #

From all these things we explored in the ecosystem,

make sure you have the finance model or cross-financing figured out,
realise for yourself why you want to move into the open-source space,
clarify expectations,
learn to say no.

As much as I love open-source and as much as it helped me in my career, I have to accept that it isn’t all that shiny and glorious as it often seems to be. So, be considerable when moving within the space.

A study shown that many maintainers are not paid for their work ↩︎
For example, the core-js maintainer and the xz maintainer. ↩︎
Companies build apps with the latest JavaScript features for modern browsers. They integrate core-js to support older browsers. ↩︎
I appreciate and use VSCode, yet think that the JetBrains IDEs work better with huge codebases. ↩︎
Visual Studio Code is designed to fracture ↩︎
State of Open Source Report 2024 Page 9 ↩︎
Claims of "not being locked-in" are made, which is far from reality, but people believe them. ↩︎

Personal notes on procrastination

Florian Wiech — Mon, 23 Dec 2024 24:00:00 GMT

I'm a procrastinator. I've said it. I only perform with deadlines, in firefighting scenarios or scenarios where not doing something has major consequences.

Example scenarios would be:

people are annoyed because I'm late,
I get a bad reputation for not delivering,
the fear of blaming myself in front of an audience.

In reality, it looks like this (happens all the time): I want to learn statistics fundamentals to view and understand data sets. In my head, this totally makes sense. Doing this has so many upsides: I hope to gain more insights by improving my analytic skills. Eventually, I'll make better decisions at work through data-driven approaches. Additionally, I could bring this skill to my blog and sprinkle in some numbers here and there. But even though everything is ready, I have the time and material to read. I still struggle to focus and get it done. Instead, my head drifts towards a completely different topic. Nothing that I would classify with the same importance. But something inside me has this urge to understand this other field better.

To be honest, this sucks. I have a lot of things that make so much sense from a rational decision-maker's perspective, yet they don't get done at all. I have this instant gratification monkey in my head who always finds other things that are so exciting right this moment. Because for this monkey, it's all about instant fun.

When you research how to overcome procrastination, you'll, one way or another, bump into the Eisenhauer Box.

Interlude: The Eisenhauer Box #

What is important is seldom urgent, and what is urgent is seldom important.
–Dwight Eisenhower

Dwight Eisenhower lived a productive life (as president and five-star general of the United States), which led many people to study his methods around productivity. What's often shared is a simple decision-making tool.

It consists of four boxes where you place your tasks. It gives you an idea of how you should handle them:

Urgent and important (tasks you will do immediately).
Important but not urgent (tasks you will schedule to do later).
Urgent but not important (tasks you will delegate to someone else).
Neither urgent nor important (tasks that you will eliminate).

The Eisenhauer Box

You can find additional articles for deeper insights here and here.

Three out of four work for me #

The Eisenhauer box is straightforward and makes a lot of sense. I'm all up for the important and urgent tasks (top left). It includes something like a deadline, which makes it urgent. It is not a problem for me to get it done. So far, so good.

The not important, not urgent section is simple as well. Just scratch it off my schedule. Not a problem. We'll later come back at it because scratching it off my to-do list might not be enough. Sometimes, I have to forget about its existence, that my instant gratification monkey doesn't get back at it. But again, more on that later.

Regarding the not-important but urgent ones: I'm not wealthy, so there is no one I could delegate it to. Therefore, I have to do it myself. And that is okay. However, I'm able to reduce it as much as possible. Overall, this box is not a problem for me as well.

Important but not urgent is the problem #

What gives me a hard time is the important but not urgent box. It is where my long-term goals and even some of my dreams or life goals reside. That means this section is the core which holds real value to me. But I haven't made the progress I would like to see there.

So, how the hell do I get to work on those? As the box above suggests, schedule time for it. Having no family or kids, I'll sure find time for it. But when I have a free day ready for important but not urgent tasks, my instant gratification monkey lights up and goes to work.

I asked myself, how can I "change" myself to be able to work on this box? I'm trying to schedule time, prioritise tasks, lay down a storyline, and make the tasks smaller, but I can't get to work. Over time, I learned to approach it another way.

Work with what you have #

Work with what you have instead of trying to make a different concept work.
–Me.

How about moving tasks from one quadrant to another? Instead of trying to change yourself, accept who you are. Let's use what I already have and make the best of it. This work style might not be pretty, but it gets the job done.

For example, how can I get a life goal from important but not urgent to really freaking urgent? How can I use the things I already know about myself to get to work on an important task by making it urgent? Can I attach an outside deadline or create a constellation that gets me into firefighting? Attaching an important task with urgency will move it into another quadrant, and I will immediately work on it.

For example, sign up for certifications with a time-based license. I have three months to get certified. It makes so much sense to work on it now and get along step by step. I might start with it until I'm bored. Now, my instant gratification monkey has better things to do. Well, I ended up two months later, still at the start of the course. Then, in the last couple of weeks before the deadline, something suddenly strikes me. I look deep into my eyes and ask myself if I still want it. Since completing this course is often on my list, I still want to finish it. But now there is some money on the table. I would waste money if I didn't do it now. Or at least try it now. Otherwise, it would've just been money thrown out of the window. I don't like that. And there is this sudden urge to still get something from the money I invested. But now I have to hurry up. Otherwise, the money is gone. I move my timeline schedule to get it done. And finally, I'm in an important and urgent region. I can go to work.

So every time I book a subscription to learn something (and get certified) that lasts a year, I know that Florian of next year, will have a hard time. Until then, I'll dream about how nice it would be to have this certification, including all the guilt for not getting it.

As mentioned before, use the system you have. It isn't pretty, but it works. If you want to complete your bucket list, a little messiness along the way shouldn't matter. If you think otherwise, I suggest you burn your bucket list and live the happy life you already have. This list just makes you miserable.

Not everything is shiny and clear, though. You might have to try a couple of things. I once told everyone I wanted to get something done. I hoped to create outside pressure to gain urgency. Sadly, it didn't work. So, I kept searching for urgency. Sometime later, I learned that psychology tests showed that announcing your goals makes you less motivated to accomplish them. Damn. Why didn't I find this article sooner?

The takeaway is that each task might involve a different aspect, creating this inner friction and an urge to work on it. It is important to explore and find it.

Tame the monkey to be helpful #

My instant gratification monkey exists and will always be. I asked myself if it would be possible to nudge him in a useful direction. I may have found a way. However, it was way harder than I thought.

We're now coming back to the not important and not urgent section I teased earlier. I noticed that my inner monkey really likes to take things from this section. Placing something in the not important and not urgent section and keeping it in my head will be part of my dark playground. And the monkey loves it there. So what can we do about it?

Instead of placing something that might hurt me in the long run, I try to forget its existence as quickly as possible. That way my instant gratification monkey won't touch it.

Here's an example: I have several fields I would like to learn more about. Some of them are more important than others. Therefore, I place them in different quadrants. I've gotten out of bad habits like wasting time on content consumption. In particular, I have eliminated tools based on addictive scrolling techniques from my life.

What happens is very interesting: The rational decision maker inside me says I should learn a topic. My monkey would rather do something else. The monkey finds something in the not important, not urgent section. But the things the monkey finds still bring me forward. The result: I have learned something else. Not too bad, I would say.

In reality, it looks like this:
Rational decision maker: We should learn more in the field of data science.
Monkey: But I've always wanted to understand electrical circuits.
End result: I learned another technical concept. Not bad, I would say.

Again, it isn't pretty, but it turned out to be okay-ish. Or it could be worse.

Only placing relevant things that push me forward anywhere in my prioritisation box brings me forward. My monkey will start to play and switch up the prioritisation. But in any way, it brings me forward.

By the way #

This blog post is a result of my instant gratification monkey. Instead of focusing on a really important but not urgent topic, my monkey rather did something else (writing this post). But after the day, having another blog post ready is not a bad result, I guess.

Additional Resources #

Tim Urban explored procrastination from his perspective a decade ago. In his TED talk, he introduced a wording (rational decision maker, instant gratification, etc.) that I've used in this post as well. On top of that, he has a very entertaining article about his full story creating the TED talk.

Effectiveness or Efficiency. Where is your focus?

Florian Wiech — Thu, 12 Dec 2024 24:00:00 GMT

Imagine a day full of meetings. "I have to be more effective today. Which meetings can I skip to get some stuff done?" you might ask yourself. The next day, two people work on the same thing. You might ask: "How about we split up the tasks to be more efficient?" These or similar terms are phrases we use in our daily work lives. It's all about being effective and efficient.

Looking across subject areas, I noticed that various concepts include these terms through their subject-matter lens. All these eventually boil down to one thing: It is really important which side (effectiveness or efficiency) you focus on.

This post discusses the concepts and why this focus is important. But let's start with the basics. What do I mean by my baseline of efficiency and effectiveness?

Starting with efficiency (because most people are familiar with this one):

Efficiency means accomplishing a task with minimal waste, effort, or cost. It focuses on optimising the use of resources to achieve the desired outcomes, ensuring that the inputs are utilised in the most productive manner possible.

Next up effectiveness:

Effectiveness refers to the degree to which objectives are achieved and the extent to which goals are accomplished. It measures whether the desired outcomes are attained, regardless of the resources utilised.

In essence, with effectiveness, you focus on achieving your outcome. While with efficiency, you reduce waste.

Same principle, different wording #

In engineering, people often use the terms efficiency and effectiveness. That may be the reason that I take them as a baseline. They are most familiar to my work context. As I explored various subject areas, I noticed they all have a similar foundation.

Looking at product management, I've seen the phrase: "When you build the right thing right, you'll be successful."^[1]. I noticed this odd constellation of "the right thing right" and started taking it apart. The "right thing" is about finding something worth building. It refers to effectiveness. The "thing right" is about efficiency. Reduce waste by building it in the best way possible. As we can see, it's a different wording but a similar principle.

Digging deeper, I found out that product development is about discovery and delivery. Product discovery exists to find out what will be of value. Product delivery is about finding ways to generate value.
From a high-level perspective: During the discovery phase, I focus on achieving an outcome. Delivery helps me to build for this outcome.
This shows that it includes the baseline principle as well.

Business administration uses financial statements as a communication tool. The income statement starts with the revenues, followed by the direct operating costs. The classic business question: Should I focus on gaining more revenue or cutting costs for a better bottom line? Focusing on more revenue could mean extending current offers. It's about creating more value for customers to gain better outcomes. Or you can control costs by looking at operating efficiency. Reduce costs by eliminating waste in the process.^[2] Do you see how it includes the baseline once again?

Ok, great, but why do I care?

Find the right thing before you build it right. #

As Simon Wardley would say: "Focus on the wrong thing, and you'll lose." So, ensure you find the right thing before building it right. In other words from Peter Drucker:

There is nothing quite so useless as doing with great efficiency something that should not be done at all.
– Peter Drucker

Exploring a real-world example: A media company invests an 8-figure amount into building a music app. They decided to

lease the library from a provider,
focus on a big music collection,
provide baseline audio playback,
ship it in their own branded app.

The organisation invests a lot of resources and goes to work. It builds and delivers the app in a couple of years. Engineers create and optimise the app for better efficiency (easier operation). They built a big app to discover that users listen to music differently. Discoverability of music and a great listening experience via smart speakers are actually the central features users are looking for. Congratulations. They efficiently wasted money and time. Hopefully, they had at least a good time doing it.

The efficiency trap #

In day-to-day operations, I hear "We must be efficient" way more often than "Let's get more effective". From a high-level perspective, I find that hard to accomplish. We're already very efficient. Especially in IT, we automate as much as possible. On the other hand, I saw more solutions that aren't used or don't bring in the expected returns. It feels like the "nine out of ten startups fail" rule applies to everything created from scratch.

Uwe Friedrichsen outlines in his post "Forget efficiency" that most businesses, past and present, have been driven by efficiency. But in the post-industrial market with more supply than demand, we clearly need to focus on effectiveness. This means a product only succeeds when it solves the customer's needs better than the competition. I certainly agree with his outlines and statements. It's worth reading.

Gregor Hohpe has another interesting take on efficiency in the book "The Software Architect Elevator":

Changing from efficiency-based thinking to speed-based thinking can be difficult for organisations: after all, it’s less efficient! In most people’s minds being less efficient translates into wasting money. On top of that, people being idle is more visible than the damage done by missed market opportunities.

Not being efficient doesn’t mean wasting money! I would even say you can focus on customer needs in the market without being inefficient.

Improve time to insight instead of efficient solutions #

Many companies can gain more by improving their time to insight. It's a focus on the customer perspective.

Time to insight measurement
The time it takes from an idea until we've validated the key assumptions for deciding whether to pursue an investment.

Breaking it down for non-product-people: You only know if your idea works when you get real-world customer feedback, such as customers buying the product. So try to improve your workflow of discovering if an idea is worth it (be more effective). You could try prototyping offerings without having a product to sell. If you see preorders getting in (or not), you have better data to decide if or how it makes sense to proceed.

To sum up, first, identify the feature that provides value for customers (is effective). Then (and only then) pursue delivery operations. It provides a higher probability of a positive upside.

The path forward #

Turning the conversation more broadly: I learned it is essential in every step I take to understand where my efforts have an impact. Will I increase effectiveness, or will I be more efficient? Before I try, I ask myself: Where should my focus be? Which "side" will make my life better? Remember, it's not always being more efficient. Quite the opposite, as I argued above. In our current state of the world, we're already very efficient.

By the way, sticking in automation with something mostly improves efficiency. It's the thing that you just automated that holds the effectiveness. This brings me back to the difference between features and benefits. Do we build features, or do we focus on achieving benefits for others?

Conclusion #

Efficiency accomplishes tasks with minimal waste.
Effectiveness verifies that actions accomplish the desired outcomes.

You find this concept and related terms in various subject matter-related topics. They all go down a similar road, asking you to follow one side or the other. So, it helps to ask which side to focus on. Take that into consideration.

There's a great book about this concept called "The Right It". I highly recommend you give it a try. It's very entertaining and insightful. ↩︎
Companies have been cutting costs to improve efficiency and bottom line. However, in our current VUCA world, resilience is very important. For example, diversify your suppliers to stay effective in the long run. Since this thinking does not directly affect the equation, many companies find executing challenging. ↩︎

Rust is the Lamborghini for Engineers

Florian Wiech — Mon, 11 Nov 2024 24:00:00 GMT

Many great engineers I know have already tried Rust or have it in their "want to try" backlog.

I see presentations in Green-IT that say: We must consider the system's energy consumption. They share charts showing how much computation power a language needs. And Rust is way up there with C requiring the least amount of energy. After these talks, everyone asks each other if we will develop everything in Rust now (and finally, we might have a reason to do so, but more on that later).

The commercial JavaScript ecosystem likes to squeeze out every millisecond it can get of its build and test scripts^[1]. You can find tons of articles declaring Rust to be the future of the JavaScript ecosystem and infrastructure.

But, in the context of enterprise applications, I state:

Rust is the Lamborghini for engineers.
Everybody wants it, but nobody needs it.

It brings everything to the table that allures engineers. However, for most businesses in the non-tech sectors (like insurance, publishing, etc.), only parts (if any) provide a real case for Rust.

Therefore, it is like a Lamborghini. Every extrovert man would love to own and drive a dragon wagon one day. But there is no logical reason for it. Everybody wants it, but nobody needs it (deliberately exaggerated).

I came up with this statement due to a couple of reasons. The most important ones are:

Rust has a special hype due to the ownership concept it introduced.
Rust's design goal is to be an alternative to C instead of general purpose language for everyone.
Rust's concept conflicts with commercial software surroundings.

There might be more, but these are the prominent ones for me. Let's go through them one by one. After that, I'll present some use cases in which Rust is suitable.

The ownership concept makes Rust special #

In the context of programming languages, we often separate between low-level and high-level languages:

In low-level languages, developers must explicitly allocate and free the memory. Bad memory management often results in memory issues or bugs in production.

On the other hand, high-level languages are easier to use. They provide garbage collection, which regularly looks for no longer-used memory as the program runs. So, these languages pay the ease of use with performance penalties at runtime.

But either way, our written software might still cause bugs in production. Even high-level languages are not secure from memory issues. Especially when we bring in multi-threading, you can quickly get in trouble with whatever you choose.

All this causes situations we know too well: Hunting down weird production bugs. At first, we have no idea what the hell is going on. Only to come across the problem hours, days, or even weeks later by chance. Finally, we can reproduce the bug. We fix it by changing a single line of code.

Rust goes down a different road. What makes Rust so alluring is a powerful language backed by advanced theory. It provides all the features a high-level language supports but no garbage collection.

In Rust, memory is managed through a system of ownership with a set of rules that the compiler checks. This provides great runtime performance since no garbage collection is necessary. It also causes fewer production issues due to catching potential bugs at compile time. The only tradeoff is a development concept that you have to get used to. Due to its complexity, it takes more time to develop. It shifts time spent from hunting production bugs towards building proper software.

These aspects make a strong argument for everyone who wants to build performant and safe software and loves challenges in computing systems. Then, combine this setup with state-of-the-art language expressions and tooling. It is the perfect match for engineers.

Besides the memory differences, low-level languages often lack standardised tooling. Newer high-level languages already applied learnings from software projects of the past. A language needs to be more than its syntax, semantics, and compiler. Engineers need modules, code linter, formatter, package manager and more. Rust provides all of it right out of the box. That drastically reduces the barrier. It's straightforward to structure and scale codebases. In the end, it enables engineers to collaborate.

Rust is an alternative to C #

The creator of Rust had the idea to create a high-level language competing with others like Java and Go. Rust started with that approach by having a runtime with green thread capabilities. You might already be familiar with them from other high-level languages.

However, the community decided to go a different route. They wanted to place the language with its concepts to be a C alternative. They removed the existing runtime without a replacement. This led to various community-driven implementations, with tokio being the most popular. They redesigned the async/await to be an alternative to the state machines developers use in C environments.

Now, the language is an alternative to C. They've designed an FFI interface where you can use C and Rust interchangeably. Plus, there is no runtime overhead. Rust might be a capable alternative everywhere you work with C or have to fall back to C.

Commercial software #

Companies ranging from startups to enterprises are in business as a for-profit organisation. They have to work with limited time, resources, and people to create an offering that others buy. To still work with all these limitations, they have to make tradeoffs.

Especially commercial environments in finance, insurance, or publishing I've seen mostly rely on high-level solutions like the JVM. Engineers build services, bundle them in a container and deploy them to cloud-native environments. There is no need for C or alternatives at this layer.

Don't get me wrong. Placing Rust to be the one language, count me in. Who doesn't want to drive a dragon car daily for work? Every engineering heart will beat faster.

The reality depends on business cases #

In many enterprise business landscapes, more stakeholders are at the table. They bring in their subject-matter-related interests and requirements towards a solution. All requirements together will show how important engineering efficiency, system performance, and stability are.

When designing software products: You might have to cut things short and accept some tradeoffs in many dimensions. You trade in software performance, which is acceptable due to decreasing computing costs. You gain simplicity and reduced implementation time. This is often a big plus due to the high cost of development hours (the high salary you earn) compared to the hardware operating cost. It reduces the overall finance-business equation, shipping earlier and with less cost.

This is why high-level programming languages are often the choice for the non-tech enterprise landscape. You can get faster to a reasonable good enough for now, safe enough to try solution. I don't see enough strengths for a different market direction at the moment.

When is Rust a sweet spot for a business case? #

It needs the aspects of mission-critical, high-performance or a case where your only option is to fall back to C. We can see several cases where this fully makes sense.

1Password provides a password manager. Many parts of their system landscape are built on Rust. It makes sense because their customers store their most sensitive credentials there. A leak of customer information might be an existential threat towards their product.
Additionally, they offer an app for many end devices. Providing shared libraries for various clients, their only option is to fall back to C. This is where the option of using Rust shines.

Cloud providers–the plumbing of technology–leverage Rust to provide large-scale, performant services. They bring many customers across various use cases onto the same physical infrastructure. It's an operation at scale. Compute usage and energy efficiency matter. All performance improvements transfer into money saved. If they save more in the long term than it costs to implement performance improvements, it passes the finance equation.

An on-scale example is CloudFlare. According to their blog, they handle over 60 million requests per second on average. To run efficiently at this scale, they can't afford performance overhead using high-level languages. But they also don't want to risk memory issues using low-level languages with custom memory management. Therefore, they've decided to go with Rust. They even built and open-sourced their framework. As they say, measuring and optimising in microseconds may seem a little silly, but it quickly adds up at that scale.

Last but not least everywhere, where we have all those C and C++ codebases (Browsers, Micro-VMs, operating systems, firmwares, bare-metal, etc.), Rust might be an alternative.

Conclusion #

Rust is rather a niche. Or I make my statement more precise: I think Rust targets a different market than generic software development solutions built in companies across all sectors.

This brings me back to my statement from the start:

Rust is the Lamborghini for engineers.
Everybody wants it, but nobody needs it (deliberately exaggerated).

I hope you gained a few insights or new perspectives. Let me know if you see things differently. If you still want to go with Rust, I gave you some ideas of where to look. If you have any ideas on how to get Rust to mainstream, please tell me: hi@wiechtig.com

Let’s see what the future holds and if the will/interest of engineers changes that. I'll now head back to my rustlings exercises. In the end, it seems that my engineering heart prevails.

Update 23. January 2025: Clarified that it is about non-tech sectors; Did mentions about memory safety more precise;

Although the JS ecosystem is already the fastest dev tooling I know compared to platform native development, JVM environments, embedded systems or deploying something to the cloud. At least it's nice that they keep pushing the boundaries. ↩︎

Digital identities in the wild

Florian Wiech — Mon, 16 Sep 2024 24:00:00 GMT

Over the years, I've worked across industries that use digital identities. It showed me how flexible those standards are and how tailored the implementation must be. Looking under the hood, there are quite some interesting differences between standard and implementation. It took a major incident at work for me to notice this slight but important variance.

To explore the difference I'm talking about, we will examine the standard, explore some use cases, and then dive into the implementation hurdles. Ultimately, I'll talk you through the outage I was part of at work.

Fundamentals #

Before I jump into some use cases, let's shine a light on the login process itself. From my bubble, the most common approaches towards authentication are based on OAuth and OpenID Connect.

The general idea is to unify and bundle all account-related actions and information in its entity, the identity provider. This scenario has two sides: the identity provider and the client app integration. The identity provider does all the heavy lifting of validating the user’s identity. All other feature-specific applications only need a thin layer. Frontends initiate a login flow and receive a token to work with. Backends need the certificate for token verification.

Identity provider manages sessions #

By registering or logging in, the identity provider verifies the user. It initialises a session and issues token sets. This will be used for all further requests and user-specific actions. It is a technical device/browser/app-specific solution and allows users to provide their credentials only once.

The identity provider is responsible for storing and managing all sessions. This includes creating new ones, issuing new token sets based on active sessions, terminating sessions, and deleting expired sessions.

From a bird's eye view, an identity provider owns and verifies the identity. The goal is for all other client apps to work with the provided tokens. It makes the integration simpler and enables single sign-on options.

Client integrations validate sessions #

The other side is the client app implementation. There are two patterns:

Token-only pattern: The identity provider issues signed temporary tokens that work for themselves. The backend processes a request when it includes a valid token (e.g. it verifies the token signature and expiration date). It skips the token check by the identity provider for every request. However, this backend still accepts valid tokens even when the identity provider terminates a session. Users can use the app if a once-signed token set hasn't expired.

Single-source pattern: Validate the token via the identity provider for every request. It'll catch all requests that might have a valid token but are from a terminated session. However, it's a single point of failure for the identity provider. This means all traffic to connected backends will be proxied to the identity provider.

Most often, reality lies somewhere between those patterns. I don’t want a single point of failure, but sometimes, I want to enforce a truly active session. Therefore, I separate actions by criticality. The critical ones, often involving altering or deleting your user account, require an active session. You can implement an even stricter action flow, such as requesting the user's password before these operations occur. It might be ok to rely on the given signed-token validation on the client for other requests. This way, both worlds work together.

With these concepts in mind, let's look at some use cases.

In Finance: Lock accounts immediately #

The first use case is in the financial industry. Think about a bank account. With the ability to use online banking, customers can sign in to a portal and transfer money.

The bank has to deal with abuse. Sometimes, bad things happen, and the bank has to lock an account. There's the requirement to disable an account within a second. It would be bad if a user was locked at the identity provider but still owned a valid token. This person could clear the account balance before the termination takes place for them.

Having to log in to the account more often is not seen as a problem. For some users, it might even feel "more secure".

In Entertainment: Users want to stay logged in #

In an entertainment app, users want to consume content. Everything that slows them down accessing the content is considered an annoying distraction. This imposes a risk on the entertainment company. Therefore, both parties are interested in logging in users once and staying logged in as long as possible.

The identity provider is often at the forefront and receives much traffic first. Many users join simultaneously, especially with live events in a certain region, causing a lot of traffic in a short window. A requirement the applications landscape must be able to handle.

When a user unsubscribes, it is accepted that there might still be a valid token, and the user can still watch content for some time (mostly minutes or hours). Of course, only as long as legal contracts allow it.

The standard handles various use cases #

The cool part about the standard is that it handles both use cases. Either way, I can use the standard and form a configuration.

For the financial-based use case:

The backend consults the identity provider for session validity. Session termination takes effect immediately.
Use short-session lifespans. There is less risk for session takeover, and it is straightforward for the identity provider to manage.

The entertainment app:

Use long-session lifespans. Users log in once, and the session covers the rest from now on.
Rely on token validation on the client to reduce overall traffic at the identity provider.

The implementation is where it falls apart #

Let's look at the identity provider implementation a bit closer. Besides the user flows like login, the server has to manage all the sessions it issues. There is no one-size-fits-all model for a technical session management solution. So, decisions will have tradeoffs.

The entertainment app: Users might have many active devices but only use a small proportion. All these sessions will last for a long time, though. It's important to have a data store that scales to many sessions. Having eventual consistency works fine. The optimisation is placed around fast session retrieval. The handling of lots of traffic forces making tradeoffs regarding flexibility.

Looking at the financial solution with short session live spans. Sessions exist when users actively use the portal. It might have a manageable session count. In case of a user termination, it must get and delete all user sessions immediately. This situation works better with a solution that offers more flexibility in retrieving necessary sessions. Limits towards scaling are fine.

So what's with the incident, then? #

I was working in a team that runs a big entertainment app. We used an open-source solution that handles various use cases, including financial-grade APIs. Therefore, the identity provider offers the feature to terminate all user sessions immediately. It uses a cache underneath (plus persistent storage), allowing quick and flexible session retrieval. There are certain scaling limits attached to it. For us, daily operations went fine. The server issues sessions, and the cache is scaled accordingly.

It went well up to the point where an unrelated issue forced the identity provider to restart. On startup, it loaded all persisted sessions in the cache but ran out of memory. This is where it all fell apart.

We discovered that terminating a user's sessions only works by having all sessions in the cache (remember the financial-grade requirement). Requiring sessions just in time from the persisted storage works fine for everything else.

Our incident resolution was to start with an empty persisted storage. After the successful startup, we did a storage failover. That way, it can retrieve all persisted sessions on each request later. Just the feature to terminate all sessions from a user wouldn't work (which we don't use anyway).

Let's say our mean time to recovery (MTTR) could've been better. Sometimes, we have to learn it the hard way. Indeed, we now have patches and multiple resiliency and fallback measures in place.

I can now scratch being on the title page of major newspapers from my bucket list, even though it wasn't listed there in the first place.

Conclusion #

Technical standards are great. They offer general concepts, architectures or abstractions for various use cases. We implement them across many sectors with even contradicting requirements. Thanks to the configuration options, it works everywhere. It's fascinating how a standard–an abstract concept–can be applied to many use cases.

Digital identities include user registration, login password reset, etc. It seems to be a solved problem, a commodity. Every app has it, and the standard is there. Though looking into the design & implementation, it might not be straightforward. Like banking, which relies on short session spans and the ability to terminate any session on any device. Or a streaming provider interested in logging in users once and keeping them logged in as long as possible. Comparing the two use cases, we see that they have contradicting requirements. But the standard handles both.

However, be cautious about open-source implementations. Technical decisions force tradeoffs. Ensure that ready-to-go solutions don't oppose limitations due to supporting other use cases.

Appliance UI nightmares

Florian Wiech — Tue, 30 Jul 2024 24:00:00 GMT

In the modern world, I use appliances daily. They help me with all sorts of ordinary tasks. My interaction with them gets them working. Most commonly, I use an interface for it. And that's where the trouble starts. Over time, I've seen appliances that were hard to configure. By sharing them, I aim to increase awareness of appliances' UIs.

UI nightmares #

The first is about a navigation misconception with the microwave at the office. It has a digital display and a scroll wheel to adjust the input. I only have one controller and multiple input options. So, I need some indication by the machine of which input I'll change. The solution at this point couldn’t be more confusing:

Microwave selection screen

After inspecting this setup: Which side (left or right in the picture) is selected? In other words, will it change the left or right side using the scroll wheel? Would you agree our gut tells us it is the right side with the blue background that illuminates us? Turns out this is wrong. It's the left side. A black background on a black surface with a red border at the top means selected. 🤯

This microwave is installed in the office. Everyone using it is confused over and over again.

Touchscreens everywhere #

You might have recognised this trend. Nowadays, a device with many buttons has a touchscreen in the latest release. It's being marketed as the next big thing. The most famous example I can think of is the Touch Bar on the MacBook 🫠.

MacBook Pro with Touch Bar

Don't get me wrong: A touchscreen can offer the user convenience if done correctly. However, it is up to the user to determine if this solution is best suited for interacting with a device.

Touch buttons #

Then there are other products which work perfectly with buttons. It is a blast. Suddenly, the next generation has touch buttons instead of physical ones. Why? I don't know. Maybe it's to have something new to show or to be cheaper to produce.

One example I remember is the cooktop at home. The old one has knobs. I can set the number to heat the hotplate perfectly. There is no problem. It just works.

Knobs of a stove

The new one has touch buttons, and the issues have started.

Cooktop with touch buttons

Setting the level is very hard and takes practice. The touchscreen isn't straightforward.

Sometimes, a hot cooking pot near the input causes the stove to make error sounds. Is placing a pot on the cooktop problematic now? Wait, what?

The beauty of physical buttons #

In short, I can use it without looking at it.

A colleague of mine once told a great story I certainly relate to: When driving, I have better things to do than look at the screen to select the song. Well, driving, of course. I focus on the road and my surroundings.

With physical buttons, I still have a display to see what I select. But after doing the same routine often enough, I remember the combination that got me to playing music. I use the buttons and don’t look at the screen anymore. I know three clicks from the scroll wheel and two clicks on a button, and my playlist runs. That's so comfortable. I don't have that with a touchscreen.

Product Managers sometimes answer to feedback: “Oh, but you can use the voice assistant.” Maybe it's just me, but it feels weird to talk to a machine. It's just not my thing.

When associations don't work #

Next up is a coffee machine. Here, I have the touchscreen of a coffee machine in the office. It shows some brewing options and some circles at the bottom of the screen.

Coffee machine screen

The circles at the bottom of the screen look like a pagination. There might be more options on other pages. And I'm correct with that assumption.

The specific layout of the pagination reminds me of the pagination I’m used to on an iPhone screen.

iPhone screen pagination

So why don’t I use the same swipe gesture I already know to change the page? But it turns out that swipe to the next page doesn't work. Even worse, when I try the gesture, it recognises a click. So it takes the start of my swipe as the selection and starts brewing.

That means the first time I use the device, I'll be surprised with a random beverage. After that bad experience, I try to click the circle to move to the page. And here I go.

It's astonishing. Everyone using any of these devices does it wrong the first time. Didn't they notice while developing the machine? Who said yes to shipping the product with this UI?!

It's part of your product journey #

These examples show that mistakes can still happen late in product development. But first things first.

In product development, I focus on four dimensions: desirability, feasibility, viability, and usability. Most often, I start in this order.

Customers won't buy the product when there is no desire for my solution (desirability). I have to be able to ship the product to have a product to sell (feasibility). I have another problem when customers don't want to pay enough for my production cost (viability). Finally, even if I fulfil the first three points, I might still produce a difficult-to-use product. This will annoy users, and they still won't be satisfied. And this is where the issues with these appliances are.

A note to the creators #

These examples highlight that it is essential to do proper UI testing, even for physical appliances. It can be as simple as showcasing your product with free usage at the next marketing event. You provide your potential customers with the machine and let them explore independently. You stay behind and carefully watch what they're doing. The learnings you gain from these experiments are invaluable.

If you need help with that, you can approach UX/I experts. They focus on user experience and user interface and know what to do.

Conclusion #

I use appliances daily. They might be personal devices at home or shared with colleagues in the office.

Human and machine interaction can cause issues:

I mix up an element with the cursor and head in the wrong direction.
Touchscreen replaced buttons where I loved using buttons.
I associate an interface with something I already know, but this time, it works differently.

It is crucial to test humans' interaction with the machine's controls. This is especially important for appliances. Once built, I intend to keep and use them for a long time.

Even from a product development viewpoint, usability is essential. It might not be the first thing, but it becomes key later. Reality shows that there is much to gain by obtaining user feedback during development.

Feature vs. Benefit. Tell the difference.

Florian Wiech — Mon, 29 Apr 2024 24:00:00 GMT

This experience blew my mind. It brings a completely new light towards building software. However, it sets software in a new context that few developers might appreciate.

I remember the first time I created a business model canvas at university. All the boxes seemed intuitive. I thought about it and filled it. It was nice to have everything put on paper. But nothing more. I shrugged and went back to building software.

Some years later, I worked on a different piece of software. I struggled with the feature scope and whether users would use it. Finally, I approached my product coach colleagues and asked them for their advice. After all, they have product in their title, and I'm trying to build one. Let's see what they got.

They asked me why don't you go for a business model canvas. Aww, cute. I already did that and have it in my head. But surely I can put it onto paper, and we can talk about it, no problem. Boy, I was so wrong.

I created the desired document, and we (Mathias and I) discussed it. Most boxes were okay-ish. They align to some levels with similar business models and ideas. Then we came to the centre, the most important piece: value proposition. I explained what great features it has. Many visualisations and insights are based on the data. But somehow, he wasn't satisfied with my answer. He kept asking what he could do with it. And I'm like, obviously, you see more. Don't you see how nice they are and how they look? Mathias: Yeah, that's nice, but what can I do with it?

It felt like I was standing in front of a wall. He said you have to go five more meters. And I'm like, no way, don't you see the wall?! Him again: five more meters, please.

Finally, he approached his point from a different angle: As a user, what do I want to achieve? How does it change my current workflow? How is it better than before? What is the current problem that makes it difficult for me? How does your proposed solution solve it? And why do you think your proposed solution is the best fit?

Uhm. Good questions. I never thought about it this way. Indeed, I thought about these points, but my gut told me it would work. Or logically thinking it through just made sense. So, I proceeded to see if I was right.

But here is the bummer: Answering the questions above is key to product adoption. Without a clear and validated concept, you just have a coding exercise. But no digital product.

It's like my parent's generation doing crossword puzzles. It entertains, and you might learn something. But the execution won't bring you any further in a business context.

Returning to my insightful conversation with Mathias, he asked me further: How did you validate the data you wrote there?
Me: Wait, what? Validation? Surely, I know what I’m doing.
Mathias: But how do you know that users will use it?
Me: Oh, great question, thank you for asking. Something I’ve always asked myself and struggled with.

I only knew if the product worked when I invested a lot of time building and shipping the software. Mathias helped me understand: There are many approaches to validate ideas before you invest time in software. Again, it was very eye-opening. But I’ll keep this for next time. Let me know if you’re interested: hi@wiechtig.com.

Feature or benefit? #

My problem resided in a subtle but significant difference. As engineers, we think in features. We figure out solutions and consider how to build something. But do we know their benefits?

Here is an example differentiating between a feature and a benefit of a rain jacket:

Feature: Waterproof material with a hydrostatic head rating
Benefit: Walk through the rain for three hours. Stay dry and comfortable.

Another famous example is the iPod:

Feature: 5 GB storage capacity, unique scroll wheel controller (Source)
Benefit: 1,000 songs in your pocket.

From these examples, we learn:

Features are the characteristics or functionalities of a product. They describe what the product can do or what it is made of.

On the other hand, benefits refer to the value that users derive from those features. They answer the question, "What's in it for me?"

In essence, features are what the product has, while benefits are what the user gains from those features.

Ok, got it. But why bother about benefits?
Coming back to our rain jacket example: You can achieve the same benefit with other things than a jacket. Like a rain poncho or umbrella. You could use a different waterproof material. All of those are features. Some features might work better than others.
But in the end, users care about the benefits they receive. Your product competes against others with the same benefits, no matter the features.

Value proposition in a nutshell #

The difference between features and benefits is crucial for the value proposition:

A value proposition articulates which customer needs a product fulfils better than the available alternatives.

In other words, it highlights the key benefits for users.

A famous example is Amazon. They aim to be the best in these trades:

low prices,
large product selection,
fast delivery,
convenience.

These are the things customers look for when purchasing goods. Compared to alternatives like brick-and-mortar stores, customers can

enjoy the convenience of shopping from the comfort of their homes,
access a vast array of products,
find better deals than traditional retail options,
get products delivered to their doorstep within short timeframes.

Benefit misconceptions everywhere #

Why do I tell you that? Due to my work, I'm often faced with new projects. It turns out they have business model canvases, too. Great, let me see them. Looking at it, what do I see? Features in the value proposition, damn.

On top of that, it often results from a brainstorming session (like I did). So, no validation happened yet. Using this idea as an investment baseline for software is risky.

I learned from my experiences (as the one above): Think of your ideas as a hypothesis. Validate this hypothesis with easy-to-set-up experiments. Keep them as simple, fast and cheap as possible. The data you gain shows if the hypothesis is correct. This approach provides earlier customer feedback and reduces investment risk.

Uncover benefits of running software #

When jumping into a new project, I often face already-running systems. As a newcomer, I want to know why some components exist. It helps me to

understand and focus on customer and business value. A prerequisite for being effective.
understand the benefits. It offers an infinite space for solutions. A prerequisite for creativity and innovation.

When I ask engineers what their system is used for, they talk for ages about what it does. But these are the features. How can I get them to talk about the value users receive? And this without explaining the concept or making them read my article first?

John suggests to ask engineers: Why don't we shut the component down? Or at least consider what would happen if we did: Who would this harm? What would be the problem for the business? What problems would we need to solve another way?

Talking about these questions shifts the conversation from features to benefits. It helps to understand what value a component adds.

Your engineering career depends on it #

I assume you earn your money with software engineering. You are interested in progressing your career and tackling more interesting technical issues.

Keep in mind: You could build the best piece of software. When nobody uses it, it holds no value for the company and drives no revenue. You might be surprised when someone with sloppy software gets promoted over you. This person increases the company's value by delivering customers the desired benefits. If you don't understand your product's value proposition, your promotion to the next level depends on the people around you or luck.

Imagine your skillset is a megaphone. The people who hear the message from it might react, not care, or, worse, be mad at you. If you don't care about the message, your career could head in a direction you don't intend. You focus on reinforcing the message, which may make things worse. On the other hand, you can check that the message resonates with people. You own your career. All it takes is some basic knowledge and an interest in product management. If you do your job well, you will progress and take on more exciting challenges.

Conclusion #

There is a difference between features and benefits. Features are the functionalities of a product. Benefits refer to the value users receive.

For humans, software is a feature, not a benefit. Therefore, it is a means to an end. It might help you to get the value you want. But remember, users always ask what they gain, no matter the features.

When you need clarification about the benefits, ask product managers. Figuring out what to build that brings users value is product discovery. It's their area of expertise.

To understand more about product management, look at the Product Map.

Weird naming vibes. Are there any good ones?

Florian Wiech — Mon, 25 Mar 2024 24:00:00 GMT

A parallel team at work names all their services after types of sausage. One called "bratwurst", the following "curry sausage", and so on. In an incident, people from different teams sit together, and one shouts: "The bratwurst is down". Sadly, nobody–apart from the team members–can deduce the affected area from the given context.

I get similar vibes when I try to book a room in the office. I want to book the big meeting room. What was the name again? Let's take a little office walk.

Our meeting room naming pattern has a noble gesture: The base for each room name is a woman's name. These women achieved significant milestones in software development. It is a tribute to them and their contributions to the field.

Don't get me wrong, embedding these gestures into everyday life is admirable. But after years of working in the office (yes, I'm still working on-site), I can't remember a single room's name.

I can't deduce the name from my inner image #

My problem in a nutshell: I know the office layout and see an image of the room in my head. But I need to determine which room to select in the booking tool. The listed names are not associated with the office layout or rooms themselves.

Mentioning this issue led to an interesting discussion. It had some great insights I'll share in this post.

How can we do better? #

Use context-based names #

Good names combine your knowledge and the function:

your knowledge + functionality = name

Converting it to our room naming issue:
building layout + picture of the meeting room = room's name

We can apply the same structure to technical services: Assume an entertainment app with a personalised music integration from a third party. A service translates a local access token into a third-party access token. Both information lead to the service name: <third-party>-token-service

This should even work another way:

your knowledge + name = functionality

Again applied:
building layout + room's name = idea for the kind of room

And to our entertainment app with personalised music integration case: The name <third-party>-token-service suggests that the service provides third-party tokens. With personalisation in mind, we need some user identification. Therefore, it might receive a local access token.

This example shows that you can jump through the entire system landscape with only a baseline of knowledge. It vastly improves productivity.

To nail it, you have to figure out what the baseline knowledge for your system is. Reality shows it is complex, and you might need to adapt it regularly. I often come across names I need help deciphering. Sometimes, I realise that there's some knowledge missing on my side.

Coming back to our room naming case: What if the name pattern has nothing to do with the current layout or kind of room? You can extend the context. Make the room's name the central design focus. You could hang a big painting in the room so noticeable that people will remember it. Unfortunately, our rooms have already been designed and built. So, we need another option. And there is one.

Establish a common name pattern. #

You can still fall back to a familiar name pattern when context-based names don't work.
Every day, you come by some obvious ones. These are basic things like left and right.
Others are the location or floor level. Most buildings have a number for each floor instead of a name. It starts with the ground floor zero, followed by floors one, two, etc.

These patterns are so embedded into our everyday lives that you can safely rely on them. Like enterprises that (ab)use traffic lights for a quick project health check.

In our case: Location-based numbers helped #

Coming back to my initial room booking issue: How did we resolve our problem?
We extended the name pattern using the location on the same floor. Each room receives a number based on the distance of the entrance. When you enter the office, you start at zero and can walk to room seven.
Every time I want to book a room, I walk through the office in my head and count the rooms. Now we have a sorted meeting room list, and I can quickly spot the room I'm interested in.

In the end, we have two name patterns for different use cases:

People from other locations book a room. They choose it based on its description and remember the name to find it later. They can learn about the room's name and history at the location.
Everyone at the office who wants to get the job done quickly can use the location-based numbers. It only interrupts their current task as little as necessary.

Conclusion #

As an engineer, you know, naming things is hard. There are no perfect names. But some patterns work. You could deduce names based on the context and function or a familiar pattern.

Naming is and remains a fine line. You nail the name and boost productivity. Otherwise, it leads to more complexity.

Embedding noble gestures–like honouring past achievements–deeper into everyday life is admirable. To achieve the remembering part, create deeper associations between the past and present. For example, when naming meeting rooms, you can use related visuals inside the room. These visuals help to associate the room with the past and its name.

How Decision Records Fuel Sustainable Growth

Florian Wiech — Thu, 22 Feb 2024 24:00:00 GMT

Architectural Decision Records (ADRs) are about persisting decisions for others in the future.

Every day on the job, you make decisions. Those decisions have a context and specific drivers. Often, you consider several options for solving a problem. Each one has its pros and cons. In the end, you decide, which has consequences. Good and bad ones (hopefully, the good ones prevail 😉).

Your choices serve you well as time passes, but the world changes. At some point, either you or a colleague might revisit the decision. The outcome of the decision no longer fits, or there is room for improvement. Without historical knowledge, it will be challenging to determine the new requirements. New ones might contradict some prior ones. But we don't know because we no longer have those previous requirements. Reality shows that they can only be partially restored at best. This makes a new decision difficult.
Returning to the first decision-making and inspecting these initial requirements would be great. Decision records help you do that.

Typical examples for decision records:

Stack decisions: Choosing a library that helps us with the feature.
Architecture decisions: We have various architectural ideas and must pick one.
Solution constructs: Why structure our code a certain way?

Make writing down easy and routine #

Short templates provide a skeleton #

A decision log can be as simple as a summary of

decision drivers,
considered options,
positive and negative consequences,
and the final decision.

The following metadata provides further insights:

status (proposed, accepted, deprecated, ...),
deciders (involved people),
story link you are working on
the date

To avoid starting at a blank page, several skeletons help you to get the job done quickly. You can find them here: ADR templates

Daily routines enforce the written log #

Remember to write decisions down. Make it part of your routine. This is hard but crucial for success. In the beginning, you might miss some occasions where it could be helpful. But don't give up hope. You can still write it down when the first person approaches you for an explanation.

Written Records enable better collaboration #

Here's how you can turn conversations for the better with it: Let's consider some conversations you may have in your day-to-day activities between:

Engineer and Architect
Two engineers, where one is a new hire
Cross-team communication

When rethinking solutions #

Exhausting Conversation

Bob: "Well, we have the problem that our view count service receives a lot of traffic from our feed service. Shouldn't we introduce circuit breakers?" The most appropriate short form I could come up with to describe the problem.

Pete: "Huh? These are part of our policy. Why aren't they built in there?! Please do it ASAP." damn, what the hell are these guys doing?!

Bob: "OK, I will bring it to the team." why are you so mean? This setup has its history.

Helpful Conversation

Bob: "Well, our view count has recently received a lot of traffic from our feed service. Let's rethink our decision (link) about skipping circuit breakers and introduce them now." thank god we have decision records, and I don't sound like an idiot who has no idea about our internal policies.

Pete: "Oh, I see, there's quite a history. Revisiting this decision with the emerged load patterns is a good idea."

Bob: "Great, I'll write a proposal and send it for review." Nice, that was helpful.

When understanding solutions #

Exhausting Conversation

Bob: "Since my start last week, I recognised a service call connection between service x and y. What's it all about? Why is it the way it is?" Wow, that looks weird.

Peter: "Sure, I can explain the setup, and we can discuss it." Hmm, I already explained it to some other folks recently, and now, I have one more. I would rather do something else.

Bob: "OK, I'll send you a meeting invitation." and one meeting more. puh.

Helpful Conversation

Bob: "Since my start last week, I recognised a service call connection between service x and y. What's it all about? Why is it the way it is?" Wow, that looks weird.

Peter: "You can read about it here (link). If you have questions, bring them to our next team discussion." thank god we have documentation, and I can focus on my current task.

Bob: "Got it, thanks." great, I can read it while travelling this evening.

Log decisions across the organisation #

In practice, we work inside organisations with agile solution trains. Each one consists of many delivery teams. Architecture and product roles help coordinate and prioritise. Each organisational level has its own focus.

Solution Train Level

High-level decisions that impact several teams happen here. People from tech, product and management work together. Choose a solution where everyone can collaborate. This ensures everyone involved has access to the relevant information and contributes insights. Getting non-technical people to learn Git may not be the best fit.

Team Level

Each team develops and maintains a couple of services. Cross-service or product decisions happen here. Again, tech, product and management collaborate. So, you want to use the same tooling as on the solution train level. You can even span a graph via cross-referencing decisions. It highlights how decisions on each layer work hand in hand.

Technical Level

Technical decisions should be as close to the code as possible. Please don't document something you can look up by reading the code. Remember: Keep a single source of truth. Generate all the other views you need from this single source.

Conclusion #

You make decisions every day. Intentional or unintentional. Writing them down at every organisational level is essential. A decision log can be as simple as a summary of the drivers, options, consequences, and the final decision. Some metadata like the status, deciders, and date provide further insights.

Keeping a written log of your decisions...

...helps everyone in the team to remember why a solution is as it is
- because less time is spent researching why a solution is weird
...helps onboarding new team members with async knowledge exchange
- because everyone can read it themselves at their own pace and time
...less risk of losing essential team knowledge
- because no knowledge is bound to specific team members

Done right, it simplifies collaboration and reduces friction. A key pillar for ongoing progress and growth within the organisation.

Now I turn back to my docs and create my second ADR, having decided in the first to write ADRs in the future.

wiechtig

Depth over Noise #3

Supply chain attacks are underrated #

Don't build your castle in other people's kingdoms #

Substack's publishing platform with prestige and marketing traps #

Random Reads #

Depth over Noise #2 – Software Engineering Practices

Greppability is an underrated code metric #

Ideas on how the tech industry can do better #

Know what the need is #

Build to maintain #

You work with humans, treat them that way #

We're post-industrial and forget efficiency #

The evolution of markets #

Forget efficiency #

Valuable lessons on platforms #

The simplicity curve #

Depth over Noise #1

The real skill is to know when to dive deep and when to skip the details #

Back to the future: From text back to the spoken word #

Reports of the German inner circle of power #

About this newsletter #

Git GUIs are far superior to the CLI

ClickOps: It's the worst

It sneaks in faster than you think. #

Cloud #

Desktops #

And so many more #

Shoutout to all providers offering an API, and shame on you if you don't #

Open Source is a strategy, not a lifestyle

Only a tiny fraction of people can live from open-source #

Maintainers struggle to get reimbursements for their efforts #

Companies claim to be open but restrict the ecosystem #

Companies changing their licenses #

Engineers doing open-source as a hobby #

Earning from open-source is hard #

Companies do it because "it's good for business." #

Conclusion #

Personal notes on procrastination

Interlude: The Eisenhauer Box #

Three out of four work for me #

Important but not urgent is the problem #

Work with what you have #

Tame the monkey to be helpful #

By the way #

Additional Resources #

Effectiveness or Efficiency. Where is your focus?

Same principle, different wording #

Find the right thing before you build it right. #

The efficiency trap #

Improve time to insight instead of efficient solutions #

The path forward #

Conclusion #

Rust is the Lamborghini for Engineers

The ownership concept makes Rust special #

Rust is an alternative to C #

Commercial software #

The reality depends on business cases #

When is Rust a sweet spot for a business case? #

Conclusion #

Digital identities in the wild

Fundamentals #

Identity provider manages sessions #

Client integrations validate sessions #

In Finance: Lock accounts immediately #

In Entertainment: Users want to stay logged in #

The standard handles various use cases #

The implementation is where it falls apart #

So what's with the incident, then? #

Conclusion #

Appliance UI nightmares

UI nightmares #

Navigation misconception #

Touchscreens everywhere #

Touch buttons #

The beauty of physical buttons #

When associations don't work #

It's part of your product journey #

A note to the creators #

Conclusion #