Castles of Tuscany
At one game night with my board game buddies, we played a round of The Castles of Tuscany. Sorry, no pictures this time.
The game’s concept is simple: you’re running a principality, and have to build castles and cities, roads and fields, mine for marble, and so forth. By doing so, you accumulate wealth, which means you can win against the other players. So far so good - and note that there is no warfare in this game, no attacking of other players. In fact, the only cause for conflict can be the competition over resources. (I have to say I appreciate that.)
Players can unlock several kinds of bonuses (up to four) by building cities, e.g., the capacity to have more workers, or keep more resources in stock. Each of these have a considerable impact on a player’s strategic abilities, so the player should plan ahead which bonuses they want to unlock. There are also bonus points for many different things, such as being the first player to have built three castles, or making all the fields arable.
The game mechanics are an interesting mix of deck building (bonus capabilities) and worker placement (applying abilities and resources). What makes the game very fluent is that it’s practically impossible to be played into a corner. There is always something one can do. Also, because the individual moves are short, consisting of just one action, the pace is swift.
I’ve mentioned the lack of inter-player conflict. Indeed, players compete for resources only, and a little bit for achievement bonus points, which deplete. Other than that, there’s no real conflict: no fighting, no stealing. This lack of interactions between players can lead to a certain dullness. As a lover of cooperative games, I don’t mind it that much.
Overall, it’s a very nice game with a good flow, and can be learned quickly. Warm recommendation.
Tags: games
Microservices as a Non-Solution
Felix Seemann here shares some interesting thoughts about microservices and why they’re used. In brief, bad architecture and design aren’t addressed by throwing microservices at them.
Ever heard of ravioli code? Microservices decouple code bases, which means that issues are much, much less apparent at compile time. Unless the architecture is very well understood, decoupling per se doesn’t improve things.
Seemann recommends hexagonal architecture as a paradigm to be considered when working in microservice settings.
Tags: work
Policies
Company policies exist to provide guardrails for the company’s operations. They set boundaries and clarify what’s OK and what’s not OK. This is meant to protect the company from things like data loss, fines, lawsuits, bad business decisions, wasting money, cultural toxicity, and so forth.
Since a company exists only through the people working there, the policies impact what people can and can’t do. Some of these restrictions might not make sense from an individual perspective, but they most likely do in the company context. Some restrictions might make things complicated, be uncomfortable or annoying.
However, finding oneself in disagreement with a company policy, taking it personally is not an option. It’s not about “you”, after all. Asking the right questions to understand what it’s about will be better. There usually is a very good reason.
In case there isn’t - or isn’t any more -, the question is a good way of unearthing that, and having the policy revised. Asking to understand is, in such cases, still much better than plain complaining and protesting.
Tags: work
Trust Piece
Trust Takes Two
Here are some musings on trust, and how to support one another in building it.
Trust has to be mutual: it goes both ways, and one-way trust isn’t enough. To build mutual trust, signs of trust are needed, and these, too, go both ways.
Whoever expects to be trusted, has to show signs of trustworthiness, ideally be consistent in their behaviour, and admit mistakes when they happen. Whoever needs to trust, needs to make a bit of a leap of faith and also express what signs of trustworthiness they expect to see to be able to make that leap more easily.
Trust is given, it cannot be demanded. At the same time, it is all too easy to make it unnecessarily hard for someone to be trusted if a mistake on their part is interpreted solely as a sign of _un_trustworthiness rather than a possible glitch. This is what makes that leap of faith so fundamentally important: without a basic readiness to give trust, without a willingness to assume good intentions, it’s a pointless exercise.
Building mutual trust is hard if one party isn’t willing to do both: show signs of trustworthiness and grant the other party that they’re acting out of good intentions, even if a mistake happens.
A Practical Example
After one leadership question-and-answer session following an all-hands meeting at work, there was some irritation about how leadership had not directly responded to one of the questions. The question addressed some organisational changes and restructurings that had taken place shortly before the all-hands. I acknowledge that this topic is contentious, and that anxiety easily arises around it.
Us folks in leadership are usually fine with answering questions, even tricky ones. What’s difficult is to respond to a question in public that was raised by an individual who had not just asked about some sheer observable facts, but who had made several assumptions and taken them as granted, and who had then asked the question from that advanced point of view. I will not disclose the question here, or go into any level of detail about the assumptions (some of which were incorrect). Suffice it to say that such questions are best discussed in private, to clarify where the individual is really coming from, and to answer the questions on an agreed-upon factual foundation. We, in leadership, are available for such discussions.
In this excellent piece about communication by Charity Majors - I wholeheartedly recommend to read it in its entirety -, the author makes this brilliant point (emojis elided from the quote): “The way trust gets rebuilt is by small, positive interactions.” Engaging in a direct, open, 1:1 conversation is such a small interaction. As far as “positive” is concerned, recall that trust is something that’s given - it takes a leap of faith. So, approaching that conversation with the will to trust is a good start. Making clear at the beginning what signals will help with building trust is even better. Needless to say, that spirit would have helped in the aforementioned all-hands Q&A situation.
Trust Words
Reconsidering how trust gets established to begin with, here are some observations from a somewhat linguistic perspective, with German as the language at hand. (Being a native speaker, I know it somewhat well.)
Before I start, let me emphasise that in order to appreciate these observations, it is a key prerequisite to accept the following premise. Two people are involved: A trusts, B is trusted. Note how A plays the active part here: A trusts B. Trust cannot happen without A doing something. If you assume that trust can be established just by B, without A doing anything, don’t read on, first make up your mind.
In German, trust is “Vertrauen”. There are some idioms in the German language that point out different modes of establishing trust.
“Vertrauen schenken”: this is literally “gifting trust”. A gives trust as a gift to B. Gifts are given without expecting anything in return. This is the purest form of establishing trust: A just trusts, making a big leap of faith.
“Vertrauen entgegenbringen”: bringing trust to one another; the “entgegen” part suggests a mutual motion towards one another. A brings trust to B, but B also moves. This is probably the most common form of establishing trust: B sends signals of trustworthiness; A decides to interpret these in good faith, and to trust B.
“Vertrauen erwerben”: this can be translated as “obtaining trust”. B obtains trust from A in exchange for something; it’s an economic view. There are conditions here that B needs to work (hard) to meet. Note that A still needs to trust B in the end. Also, the conditions must be clear - otherwise it’s a bit unfair. This is a form of establishing trust that can easily be abused by A: not naming the terms, or moving the goalposts, can make it impossible for B to come across as trustworthy (another economic term). That’s downright toxic on A’s part.
“Vertrauen erwecken”: the literal translation of this is “awaken trust”, or, slightly less literally, “inspire trust”. Here, B behaves, without preconditions, in a way that just inspires A to trust. Obviously, not every A is the same: not everyone takes the same inspirations. Also, A still has to trust, this decision can’t be taken away. However, the act of making that leap of faith is inspired simply by observing B, without thinking too hard. This is about as good as the first one, where A gives trust as a gift, only here there’s an inspiration happening first.
These different modes form a spectrum. They range from “A does the heavy lifting” to “B does (most of) the heavy lifting”. The “most of” is emphasised because, after all, whichever mode is employed, A has to make the ultimate move of trusting. It’s an act of volition. A should not be unfair and just expect B to do everything right. A needs to either freely give trust (“schenken”), or name the terms, in which case then both parties need to contribute, or be ready to be inspired to trust.
Tags: work
Daily Todo Overview in Logseq
Logseq has a builtin mechanism for
to-do management. Just start any bullet point with TODO,
and it’s treated like a to-do item, formatted with a checkbox to tick.
That’s nice, but all those to-do items end up scattered over the
multitude of pages that a Logseq graph inevitably is. So how to keep
track of them? Preferably in an in your face kind of way that
prevents the user from losing sight of them?
Two things help.
First, queries. Logseq’s search mechanism isn’t just a search field,
but search results can be embedded in the pages, right there. Inserting
a search as simple as this - {{query (task TODO)}} - in any
page will display all open to-do tasks right there.
Next, templates for the daily journal. Logseq creates a daily journal
page for every day, which can be pre-formatted with a template.
Templates are (or, should be) stored on the Templates page,
and a template with the title Daily Journal Template will
automatically be used for the daily journal pages.
In a nutshell, a simple entry on the Templates page that
looks like this …
* to-do list
template:: Daily Journal Template
* {{query (task TODO)}}… will make a to-do list appear at the top of every daily journal page. Done.
Tags: the-nerdy-bit
Amstrad NC100
At a nerdy flea market, I couldn’t withstand and brought home this gem: an Amstrad NC100.
It’s a lovely little portable computer, a bit larger than a sheet of A4 paper, and of course a lot thicker. It uses the famous Z80 CPU, an ample 64 kB of RAM, and a really really bad 80x8 characters LCD screen. On the back, there are a connector for a printer and a serial port (so that content can actually be transferred to other devices). There also is a PCMCIA slot that can be used to boost the memory to 1 MB.
The NC100 comes with a standard variety of software built right into the firmware: a text processor, an address book, a calculator, and a BASIC interpreter (of course).
This machine is powered by four AA batteries, and supposedly lasts for 20 hours. There also is a CR2032 cell to make sure the memory doesn’t vanish. Oh, and the keyboard is awesome because it’s full size, and the mechanical keys are quite good.
Amstrad introduced the NC100 to the market in 1992. From today’s perspective, where every smart phone can do more than this, it looks laughable, but remember its age. Back then, portable computing used to be clunky.
What do I do with it, you ask? Nothing in particular, I just like to grow my collection of old but functioning hardware.
Tags: the-nerdy-bit
Data-Driven
The term “data-driven” has been giving me an itch for a long time: being driven by data just sounds wrong. Data are raw. Insight, understanding, knowledge - these are all much more worthwhile. They’re derived from data. A better term, in my opinion, is “data-oriented”, where the data don’t drive us, but help us with orientation, and choosing direction. It’s not the data that are in charge. We are.
I was happy to come across this piece that argues one should be driven by good arguments rather than by data. It’s great for its pragmatism, as it makes very clear that there’s nothing wrong with involving data in decision making in principle. The situations to watch out for are those when bad arguments involving data are valued over good ones that don’t, and when metrics are introduced where data can’t realistically be the foundation of good arguments.
Metrics, especially. Don’t we all just love a good dashboard? Basing too much or everything on metrics only will replace intrinsic motivation (which is empirically proven to be a major contributor to satisfaction) with the extrinsic kind provided by metrics. Those dashboards need to make sense, or rather: they have to support people in making sense of what they do.
Tags: work
Early Polyphony
Interested in some really old polyphonic music? Read on.
Consider Pérotin, 12th/13th century composer, probably in Paris. He was one of the first to introduce three- and four-part singing. The music definitely has that “mediaeval” sound to it, and it has a very different pace from what we usually associate with “classical” or even “renaissance” music. For example, his organum “Viderunt Omnes”, here performed by the Hilliard Ensemble.
Fast-forward to the 15th century, and to Antoine Brumel. His Missa Et Ecce Terrae Motus requires a 12-part choir (mind you, this was 600 years ago!) and takes about 40 minutes to perform. The complexity is simply astounding, and the music requires rather accomplished singers. It is also fascinating how the composition is actually a comment, an interpretation of the text of the Latin mass. Voilà.
Tags: music