Mlem
A board game featuring cats in space? Of course! Here’s Mlem.
Each player represents a cat, who together embark on a trip to outer space to take control. Because that’s what cats do. Along the way, a lot can go wrong - and when the fuel runs out, the spaceship crashes. As cats have multiple lives, that’s fine for a while, just embark the next spaceship and start over. While on the spaceship, the cats are mostly a crew - but they have their own interests to inhabit planets and make it to the farthest possible outpost.
Mlem is a dice roller. The dice control how far the spaceship can go in a move. Beware: dice get depleted, and not all dice can be used at every step along the trip. If the final dice are used up, or if no usable dice are rolled, the spaceship crashes.
During each move, the cats have the option to perform one of several actions. Disembark, boost the spaceship, kick someone off, let a die disappear, ensure a soft landing (avoid a crash), and so forth. Picking the right actions at the right time is key to success. The more planets and moons are inhabited, the more points a cat can get - and planets farther out in space yield more points. Reaching outer space, obviously, yields the most points.
The game is very easy and quickly to learn, fast-paced, and fun. Mlem gets bonus points for the printed neoprene playmat. Cardboard wears out quickly and always is a bit awkward to fold back in place. The playmat is simply unrolled for the game, and afterwards, just as simply rolled up again. Also, the mat has a better grip on the table surface.
So, all in all, I warmly recommend this as a fun game for families or friends.
Tags: games
To Microserve or Not to Microserve
“You probably don’t need microservices” says this article. It’s easy to dismiss that as flame bait. The article is quite sensible though, looking at typical scenarios for employing microservices and how that can go wrong depending on the surroundings.
In a nutshell, here are the article’s examples for how microservices can go wrong:
Some companies end up having more microservices than developers. That’s a nightmare to maintain.
Low coupling and high cohesion are harder to get right in microservices. Lots of little services require lots of collaboration across teams if something needs to change.
Services are islands of knowledge, and the bus factor really hits hard that way. Fewer services make for more simplicity, not more services.
When a startup starts with microservices right away, then bam! we have an instant maintenance nightmare.
The article doesn’t really nail where the hidden costs of microservices are, but the examples give an idea. Its sensible bottom line is that if microservices limit a company’s ability to innovate, a strategy to reduce operational overhead should be introduced. This can be as simple as merging services. After all, they don’t magically turn into big ugly monoliths that way.
GAM FTW
I want to sing some praise for GAM. This is a command line power tool for messing around in Google Drive (and then some).
A while back, I had been facing a bit of a tough time when all of a sudden files I had inherited appeared in my Google Drive root instead of in a dedicated folder with the original owner’s e-mail address as its name. Several thousands of folders and files made my Google Drive practically unusable. Moving everything away manually was not an option. Cream on top, a subset of these files (still thousands strong) were shared externally, which needed to be revoked.
GAM helped considerably, and saved me a lot of time. All in all, I spent about a day’s worth of time figuring it all out, but doing this manually would still have taken me longer.
Setting up GAM is a bit involved, and requires a lot of dancing around in the Google Admin Console, creating projects and assigning permissions. My wonderful internal IT team helped me with that, as proper super-admin rights are required for the setup. That makes GAM less than perfectly convenient: you can’t just download and start using it.
After that, I was working with a list of all the IDs of the files I had inherited, neatly assembled in a CSV file. I first had to reduce this list to the IDs of those in my Drive root. I used GAM to get a list of all file and folder IDs in the Drive root, and then some Unix command line magic to filter those that were inherited into another CSV file. Moving these to a dedicated folder was a one-liner using GAM:
gam \
csv files_in_root.csv \
fields "fileID" \
showcmds \
gam user <my_user_id> \
update drivefile "~fileID" parentid <my_foleder_id>That’s a mouthful. The gam csv command processes a CSV
file line by line, and applies a degree of parallelism to save time.
This is all automated, and works flawlessly. The
fields "fileID" bit is because the CSV file is just a
sequence of IDs, without a header row. The showcmds part
makes the individual commands show up on the console.
The second part, starting with gam user, is the function
applied to each line in the CSV file;
update drivefile ... parentid is GAM’s way of saying “move
this file to that folder”.
Running this took about 20 minutes.
Next, I had to unshare the inherited files, but not all of them: files shared with the mothership company should remain in that state. This I did in two steps. First, I obtained the ACLs of all inherited files, and stored them in a CSV file:
gam \
redirect csv ./acl-collection.csv \
multiprocess csv all_inherited_files.csv \
fields "fileID" \
showcmds \
gam user <my_user_id> \
print drivefileacls "~fileID" oneitemperrowAgain, it’s a mouthful, but in the end,
acl-collection.csv contains all inherited files’ ACLs, one
entry per row. Unsharing everything not shared inside my company or with
the mothership goes like this:
gam \
config csv_input_row_drop_filter
"permission.domain:regex:(mycompany.com)|(mothership.com)" \
csv ./acl-collection.csv \
gam user <my_user_id> \
delete drivefileacl "~id" "id:~~permission.id~~"The first part instructs GAM to drop all rows from the ACL collection that indicate sharing with domains belonging to my company or the mothership. The remaining lines are then processed by deleting the respective ACL entries.
It took about 120 minutes to process all 23,000 inherited files like that.
Only one file was erroneously unshared, and was quickly added back.
I celebrate the power of the command line.
Tags: hacking
Culture is a Commitment
Here’s a controversial one. It is often said that companies should not hire for culture fit, because diversity is favourable and hiring should rather enrich the culture. I think companies should hire precisely for culture fit, and avoid hiring people that aren’t cultural matches.
At first, that sounds like a complete contradiction. I don’t think it is, especially when it comes to the diversity bit. Diversity of thought, when brought to a foundation that encourages healthy conflict (as in: conflict of ideas), can only be good. Diversity of culture, however, is detrimental.
A company’s culture is the sum of its actions and behaviours. If nurtured right, it is the very outcome of a well-understood and carefully picked set of cultural values. Hiring someone who disagrees with those can’t be right, because it would lead to a deterioration of the culture, rather than enriching it.
Disagreement with the culture, with the cultural values, is a no-go. Otherwise, what are those values worth to begin with? Consequently, when a company hires, it should hire people it expects to strengthen the culture, not weaken it.
That is independent of the aforementioned diversity of thought - the “foundation” bit above is key. This foundation is the culture. As long as there’s agreement with the culture, a broad variety of views and opinions can only grow the cultural strengths.
Tags: work
Feedback Sieves
Further reflecting on what I’d posted recently about giving 360º feedback (and on how to give good feedback after all), I came across a simple tool that is widely referred to as “Sokrates’ three sieves” but appears to have a different background.
In a nutshell, when you want to say something (or: write feedback for someone), apply these three tests to what you want to say: Is it true? Is it good? Is it necessary? If it fails any of these three tests, don’t say it.
Truthfulness is both obvious and a bit subtle. While it is correct that “your mileage may vary”, and coming to a shared objective truth may be hard, it is also correct that feedback should be based on observations, rather than on interpretations thereof. So the truthfulness stems from what the observer has seen. Facts can’t be disputed.
The “good” part is harder, especially if the word is taken literally: how can I possibly give negative feedback if what I share has to be “good”? The key here is to understand “good” as a short form of “good-willed”, or benevolent. Both positive and negative feedback, if constructive, have that aspect. Remember radical candor.
Finally, necessity. It is safe to assume that feedback given to improve a weakness or amplify a strength is “necessary” in that it ultimately has the recipient’s growth as its intent. It’s fair to call that necessary.
It would serve us well if we all could take this to heart while practicing giving feedback.
Tags: work
Trolling People With Tech
I recalled a time when a gentleman on LinkedIn started a brilliant thread on technology. The theme was “What’s a technology from your career history that, if you showed it to a tech newcomer today, they’d think you were trolling them?” It’s a wonderful collection of tech that’s accumulating there. I can relate to many of the sentiments. Of course, I chipped in with APL.
Tags: the-nerdy-bit
Some Tips on Writing Performance Feedback
Having read a decent amount of 360º feedback across multiple performance review cycles in various workplaces, I’ve seen a large number of useful and helpful comments. These can be praise or criticism - the ingredient that makes them helpful is that they have enough substance to follow up on, work with, ponder, and discuss. Even if they don’t give away who wrote them.
Some givers of feedback sign their comments. While that happens out of the best intentions and is a sign of trust, it is important to bear in mind that it can actually reduce the anonymity of everybody else. By exclusion, more precise guesses about the identity of the authors of anonymous comments can be made. This is especially important to keep in mind if the number of feedback givers is small.
I’ve also come across a pattern that I find unhelpful. It’s when someone’s feedback is not directed at the receiver, but at one of the receiver’s coworkers. Such comments can, for instance, praise receiver R for their patience with an inept colleague C. These comments effectively say more about C than about R. Honestly, such feedback should be directed to C directly. It has no place in R’s feedback. It’s badmouthing C behind their back.
We should be better than that.
Tags: work
Project Management Force Fields
Project management takes place in a field with three forces: the number of people available to do the work, the scope of the work, and the time available to do the work. Similar to the CAP theorem, it is usually not possible to satisfy all three in a way that avoids all constraints, and one of the three needs to be compromised on. To deliver the expected scope with the available people, more time is needed. To deliver in the expected time with the existing team, the scope needs to be reduced. To deliver the expected scope in the expected time, some more people have to be added to the team. More often than not, the three forces are not exactly within the control of the team in question.
There is a fourth force however; one that the team usually has a great degree of control over: the team’s ways of working. Scope as such can’t be reduced - how do we think about the scope? Can we find a way to deliver the intended value with reduced effort? We can’t take more time - how do we use our time? Can we use the available time with more efficiency and effectiveness? The company can’t hire more people - how do we collaborate? Can we improve our interactions to put everyone’s skills to the best possible use?
This isn’t easy: it involves consciously saying no to things, and to courageously cut the right corners. It is a kind of art. It requires a considerable degree of self awareness and understanding of operation at the team level. In the agile framework, retrospectives are a great tool for moving towards that kind of awareness, and for implementing conscious changes.
Tags: work