Mini Rogue
I’ve had a chance to test another tabletop game: Mini Rogue!
Mini Rogue is a classic dungeon crawler, and it’s solo playable. Optionally, a second player can join for a cooperative mode.
Here’s the single-player setup. Everything about the player’s character is at the bottom: character card (there are several, with different capabilities), character data (experience and life, armour and gold, food and potions), and rewards. The character starts at level 1, with one (white) character die and the (black) dungeon die, which is used to control all kinds of events.
The dungeon is organised into four levels (see the card on the left), each of which has a boss monster to fight at the end. The current part of the dungeon is laid out as a 3x3 grid of room cards. The player enters the part of the dungeon at the top left, and proceeds right-and-down to the bottom right, where there are exits or bosses.
Each room is first “handled” - this involves the typical dungeon crawler activities: finding treasures, fighting monsters, falling into traps - before the two adjacent room cards are unveiled and the player can pick which room to explore next. The cards use a clear yet complex-at-first visual language to concisely describe the effects and benefits of events.
Of course, in my first game, I was utterly defeated by some kind of worm (see how the red life points marker is at zero):
Still, I thought this was fun, so I continued to play. It took me five or six attempts, but eventually I triumphed:
Note how there are suddenly three white dice: this means my character advanced to level 3. There’s also a purple die: this means the character got cursed. If the curse die shows a skull (this will happen in 50 % of rolls), all character dice have one point removed from them. The green die (visible here at the top left) is for when the character is poisoned. Happily, that wasn’t the case here.
I loved playing Mini Rogue. It’s fast-paced and fun. The somewhat complex mechanics and many different aspects made it necessary to read things up in the manual a lot, but that got better over time. I believe that once I’ll have understood and memorised the rules, it’ll be a breeze.
The game isn’t easy to win. It takes some amount of careful planning, tactics, and strategy. However, the game is biased towards luck: the best tactics will fail if the dice and cards don’t agree. This bias is a bit too strong in my taste, but maybe that’s just me being inexperienced. I’ll definitely give it more chances. Also because I want to try two-player mode soon. Warm recommendation.
Tags: games
Bell Curve Wisdom
We’ve all come across bell curves. Hopefully not as a form to squeeze people into in employee performance evaluation frameworks, but that’s a different matter. Today, I’m all about the bell curve meme that’s used to (ironically) highlight how beginners and experts in a field often come to the same conclusions, while people in the middle prefer something of utter complexity.
Here’s a software engineering related collection. Many of the entries are thought-provoking. Where are you (yes, you) on these?
Thinking on, if beginners in their naïveté and experts in their experience-backed wisdom come to the same conclusions, what does that mean? Experience proves intuition right, right? Is there a short but rarely trodden path from intuition to pragmatism?
Bottom line: hire junior, grow senior, and listen to the juniors more.
Tags: work
Asking for Help
It often seems hard to ask for help, right? The article lists a broad range of possible reasons (quasi-quotes with slight paraphrases): they’re busy, they’ll be annoyed, I should know this, I’ll learn more by figuring it out myself, I’ve waited too long and it will look like long time no progress, they might not know and I’ll embarrass them, people might think I’m stupid, I should try longer and then ask if I’m still stuck.
Sound familiar? If so, read the whole thing; it offers a lot of advice as well.
I’d like to expand on the two final points a bit, from a cultural perspective.
People might think I’m stupid. So what? Not knowing something, I’m facing a choice: looking stupid, or staying stupid. I’ll err on the side of the former. If someone thinks I’m stupid just because I don’t know something and ask for help, that says a lot more about them than it does about me. I don’t need their approval, I need their knowledge.
I should try longer and then ask if I’m still stuck. This is a classic, it's hard to get this right. If the environment is unwelcoming and prides itself in street credibility by knowing everything, the time to ask for help is never right, because eye rolling will ensue no matter how much research you've done yourself. (See my previous remark.)
Surprise: you might be part of that culture. So, observe yourself next time someone asks you for help. What is your gut reaction? Annoyance? Eye rolling? Do you think the other person should have looked a bit more?
Tags: work
Meetings, Again
Meetings are a pet peeve of mine (you know that by now). My buddy Mitch Wyle (we know each other from eBay) summarised a Twitter thread on meetings in his blog and thought I might like it - well, yes and no. The suggestions amount to putting hard boundaries on the number of, and time spent in, meetings, and to enforce some rigour around scheduling them in the first place.
I'm skeptical about any approach that tries to address the meeting matter from an angle of time spent and then does things such as applying quotas and rules that all amount to putting an upper boundary on time spent in meetings. This often cumulates in simplistic takes such as that "meetings are bugs" (Shopify, 2023).
People shouldn't care so much about time spent in meetings, but about value derived in them. Consequently, optimisation attempts should target not time, but value.
I also strongly suggest that everyone, before taking any stance on meetings, should read Patrick Lencioni's "Death by Meeting".
Everybody hates a bad meeting. Knowing how to love good ones is surprisingly hard.
Tags: work
Meetings Aren't Bugs
At Shopify, the year began with a clear declaration on meetings: “meetings are bugs”. (Here’s a pointer.)
I say that’s nonsense, and retort with a hearty “oversimplifications are bugs”.
In all seriousness, corporate liking for catchy phrases bear the risk of painting a picture of reality that has nothing to do with what’s healthy and good. So, to put it all in context, here goes.
Granted, there are too many bad meetings. Those should be taken care of, either by getting them right, or by cancelling them. Those meetings have (not: are) bugs. This is a truism, no reason to make a big fuss about it.
The move at Shopify consists of several components. First, cancelling, for the time being, all meetings with more than two participants. It’s good that the value of 1:1s appears to be acknowledged. But imagine a team that uses a flurry of 1:1s, or some other contraption, instead of a daily standup to synchronise. The communication overhead would be maddening. Also, leadership meetings at the team level should typically involve engineering, product, and design leads - that makes three. Leave one out, risk the respective function to lose touch, with consequences for the product (and customer). And how exactly is the Shopify CEO going to run his staff meeting and ensure alignment in his leadership team? This move is so obviously nonsensical that I will boldly bet those three-plus person meetings will sneak back into the calendars in a short time frame. (Does anybody know anyone at Shopify whom I could ask?)
Second, no-meeting Wednesdays; and third, placing all meetings with more than 50 participants (shouldn’t those be cancelled, actually?) in a 6-hour window on a specific day. These moves make sense, because they help ensuring uninterrupted focus. That’s a thing everybody benefits from - engineers and managers alike.
Let’s be serious: some of the work we do at companies happens in groups of people. That’s called a meeting. If meetings get the right attention, they’re good tools to get things done. Eliding all nuance from the matter with a punch line like “meetings are bugs” is nothing but putting up a show. Whom are they trying to impress?
Tags: work
A Minecraft Board Game
Knowing I love Minecraft, friends gave me the Minecraft: Builders and Biomes board game for a past birthday. The family and I gave it a try. Unfortunately, I forgot to take pictures. The review I linked to has some.
Basically, the game is about - you guessed it - mining resources, building, and knocking over hostile mobs.
I’ll start with the end. Your choices for what buildings to build (and where to place them) as well as what monsters to fight have considerable impact on how many experience points you score (the player with the highest score wins). The built contraptions are evaluated thrice: in the first round, larger biomes get you more points; in the second, larger groups of buildings crafted from the same material; and in the third, larger groups of buildings with similar purpose. As you can place buildings atop one another, some planning ahead is advisable. Similarly, some monsters enable you to make additional moves once slain, but others get you additional points in the end, so here too, it’s important to pick your enemies wisely.
Mining is done in a particularly nice way. Each resource item is a wooden cube. 64 of those are stacked into a 4x4x4 cube that players can take apart when they mine. Mining away the first, second, and third layer of the cube will trigger one of the scoring rounds, and the third will also end the game.
Cards with buildings to build and monsters to fight, and weapons to pick up for the preceding purpose, are all laid out in a 4x4 grid of 4-card piles. In addition, 4 weapon chests are placed on each side of the grid. All cards are initially placed face down, and are revealed as players walk around exploring the grid.
You fight monsters by drawing, at random, three cards from your weapons pile. Each player’s default deck has three poisoned potatoes serving as blanks that you can toss at monsters, but they’ll just bounce off and cause no damage. Collecting some diamond swords and TNT from the weapon chests is recommended.
The gameplay is fast, fun, and the rules are simple. Yet, the strategic aspects of the building and monster slaying make it more interesting than it may sound at first. The graphic design of the cards is great; especially the building cards are very detailed and beautiful.
Overall, this is a nice adaption of the computer game, and many of the original’s aspects have been brought into the board game setting in a way that makes sense. The game has a nice mix of strategy and luck, and the materials are nice and well crafted. Fun. Warm recommendation.
Tags: games
Logseq
In May last year, I’ve started using Logseq for my note taking - both personal stuff and at work. I got interested because some people whose judgment in such matters I trust were quite enthusiastic about Logseq. Giving it a look couldn’t hurt, I thought.
Today, I’m still using it, and have already transferred some of my larger personal note collections to it. I keep discovering new features and possibilities, and let’s just say I’m hooked.
What do I like about it? A random collection:
At a high level, Logseq is a lightweight note taking and organisation tool with lots of pragmatic and sensible features.
Logseq keeps all the data on the local drive, in Markdown format, unencrypted, accessible.
The editor has built-in features for very swift linking from text in a page to external resources, other pages, sections in pages, and even down to single paragraphs (“bullets”).
Recurring structures can be easily reproduced using templates.
Pages can have alias names, making for nicer linking.
Logseq adds, atop the plain Markdown files, an index that allows for extremely swift searching. There’s a powerful advanced query and filtering capability, too.
It’s available on desktop, iOS, and Android.
There are numerous ways of synchronising across devices, including iCloud and git.
The tool is open source, and the monetisation model (yes, it has one, to sustain services and community) is extremely forthcoming: you pay as much as you want in a mode of your choice if you think it’s deserved. (It is.)
Logseq also has a graph visualisation of the page structure - I have yet to discover its true worth but it sure looks nice. A cross-device sync feature has been added and is available in beta mode for paying customers - I'm one of them, and it's pretty usable and stable already.
I have barely scratched the surface. There’s a plugin API allowing for all kinds of power-ups, automation is possible to a considerable extent, and so on, and so on. I believe Logseq is a true power tool.
Tags: the-nerdy-bit, hacking
Guidance for Quick Decision Making
It's a healthy philosophy in engineering to be quick at decision making and then sticking to that decision, properly following quality guidelines and best practices. This sports a strong sense of agility, focus, and quality. A while back, a past manager of mine with whom I’m still talking frequently pointed me to an interesting thinking tool that can help with the precision of the “quick decision making” part. It’s about viewing decisions as one-way or two-way doors.
Simply put, a decision that’s a one-way door can’t be easily reverted, making and implementing it will have some sort of definitive cost to it. Conversely, a decision that’s a two-way door can be reverted without too much cost. How we go about making decisions then considerably depends on their nature.
For example, a new variant of a feature can be rolled out in a way that allows it to be switched off quickly in case anything bad happens - an undiscovered bug, or bad user response. Feature flags are what’s normally used to enable that. The decision to roll out the feature can be made very quickly, as long as the criteria for rolling it back or keeping it are clear, and a way to roll back is built right in.
As another example, a big initiative that moves the infrastructure from one cloud provider to another is one that can’t be easily reverted: contracts are signed, database architectures changed, and applications wired in different ways and sometimes even rewritten. Such a decision needs to be prepared carefully, and risks need to be analysed.
The article offers some ways of looking at the nature of decisions to carve out two-way door segments in decisions that look like big one-way doors. Perhaps one way of framing the difference is in terms of learning. What can I learn after making this decision, and how much actual pain will the learning involve? The greater the pain, the more one-way.
Tags: work