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
On Leaving
There is that special kind of saying that is just obviously nonsense but somehow keeps being repeated because it’s, I don’t know, culturally engrained or something. But that doesn’t make such sayings cultural wisdom, simply because they’re not wise at all. They just sound catchy. The following is a verbatim quote of a thing I blurted out on LinkedIn some time ago.
Since I’ve come across another example of the “employees don’t leave companies, they leave their managers” trope today …
Generalisation and simplification don’t cut it, in most cases there’s quite a bit of nuance involved.
Sure, blame it all on the managers. Or read on.
How about someone interested in significantly improving their financial situation for whatever reason finding another company that simply offers more than the current one possibly can? Not leaving the manager.
How about someone discovering they would like to apply that special knowledge they built in their spare time that just isn’t applicable in their current company but elsewhere? Not leaving the manager.
How about someone having collected enough money to finally start that travel year? Not leaving the manager.
How about someone who realises that the company culture is changing in ways they really don’t appreciate? Not leaving the manager.
And so forth.
If I may offer myself as a sample of one: of the six or so job changes I’ve done, only one was “leaving the manager”. The others were mixed, and more often “going to” than “going from”. I’m not implying statistical significance, but the “not companies, but managers” thing just reeks of simplistic nonsense with garlic on top. (I like the garlic.)
Addendum: At the time of this writing, I’m looking for a new job. I’m not leaving a manager, no reason for that. In a way, I’m leaving a company, because my current employer is liquidating itself. That’s not at all intentional on my part. In the context of the above, make of this what you will.
Tags: work
Sea Salt & Paper
Sea Salt & Paper is a card game. Players collect cards in their hands to build scores. They can also play certain combinations of cards to have beneficial effects, such as stealing cards from other players, scavenging cards from the stacks, and so forth. The game is fun to play and makes for some interesting challenges, but is not too special as such. What makes it stand out somewhat is the artwork: the cards are all designed in a minimalistic maritime origami style. They’re simply beautiful.
Tags: games