This is because America was built by people going there to become winners, and thus created a country of winners.

This is even how the whole story started: Initially looked at by the Crown as a joke going too far by enterprising vagabonds not wanting to pay taxes, your very first act was to win your statehood. Gradually, you've won against nature, your neighbors, and the people of the land (appalling as it is viewed today). You won against your Southern half. In the First World War, you learned to win intercontinentally, and in the Second, to win globally. You learned that you can't exclude part of your people, and they, too, should have all the rights of the winners. You've won the space race; you've won the Cold War. You didn't win in Vietnam first, but in the long run, you've won an ally. You've won the internet, you somehow managed to win with the Great Recession, and, arguably, you won Covid (but for that, you needed a Hungarian Noble laureate; you've won her over, too).

Today, after the presidential election, you might feel all kinds of emotions. For those of you being miserable, I can offer some consolation: This, too, shall pass. If you're high-spirited, a word of caution: This, too, shall pass. Tomorrow you'll still all be Americans, born winners, but your fortunes are tied to extending your hands to your fellow Americans.

America, you will win.

Did I receive my new professional calling? No, but I became a much brighter person (please comply with the "APPLAUSE" sign and appreciate the pun), as well as got a bit of an eye for the details of the fine art and engineering of lighting all around me.

Recently, I went to a one-day home barista course. I only gave a little chance of switching over from my single daily "push button and receive espresso 30 seconds later" capsule coffee routine, but I was curious. And did I learn a lot about making coffee! Starting from how coffee beans are farmed and selected, sourced and roasted, all the way to tuning the grinder and the espresso machine to brew a cup that's actually enjoyable. I learned to recognize a few basic components of a coffee's taste, and what kind of common mistakes to look out for.

Will I open my own coffee shop on the corner, or invest in a very reasonably priced $20k coffee miracle? No, but the next time I indulge myself with a cup of specialty coffee prepared by a professional barista, I'll have a tiny bit better understanding of what they had to do to create that delightful drink for me. Or if they mess up, I'll have a clue about how they messed up, and be able to go back to the counter to roast them (*APPLAUSE*).

You surely start to get the idea. It's the same thing why as pupils we had to analyze poems, essays, novels, and even do our best to write a few. Not because the goal was to turn everyone into a poet, essayist, or novelist (though that's a welcome side effect), but to heighten our senses when consuming literature, and hopefully learn to enjoy it. Similarly, if you can cook a meal, you have a much more educated point of view when ordering it in a restaurant. If you know how to code, your computer stops being a piece of magic (OK, not really) and becomes a tool that you can instruct to work for you...

My knowledge of lighting compared to some entry-level was previously perhaps at 1%, and after the conference, it became 2%. Before the barista course, I was maybe at a confident 2% of understanding coffee making on an amateur level, and now I'm at 5. Still nothing in absolute terms, but compared to myself, my domain knowledge vastly increased. And this brought whole new universes for me.

I read that when looking for a job, supposedly not your close friends, but your more distant acquaintances can help more since they are your connections to different social circles. When it comes to shaping your worldview, and if you allow me a commonplace, make you a better person, I think learning something completely new (visiting a completely new place, getting to know a completely new community...) is what matters more than putting the same amount of effort into a craft that you're already exceedingly good at.

For example, I know a lot about the programming language C#, having worked with it professionally for almost two decades. After spending 5 hours practicing new C# language features, my capabilities will have moved by basically zero, my productivity will be indistinguishable, and at most I'll be able to impress some of my colleagues with a quirk they didn't know about. However, learning about coffee or lighting for 5 hours opens up avenues I never even knew existed. Without exaggeration, I'll see the world differently. In the case of everyday things, I'll be able to appreciate them consciously instead of just being largely ignorant of their existence, making life all the more enjoyable.

When did you learn something completely new, simply out of curiosity, just for itself?

Then you can have design for things people interact with to achieve a goal, for something that people use. These objects are merely tools; while welcome to be delightful, they should serve the singular purpose of helping people achieve said goals. Cleverness, some mistaken "elegance", or the mental fulfillment of the creator is thus secondary. Good design, by its very nature, induces low cognitive load: If your users have to think too much, you're doing things wrong.

This letter will use examples from the programming language C#. These will be easy to understand for anyone who can code in any language, but perhaps less for others.

Ten principles of good design

Dieter Rams, a living legend of German industrial design, formulated ten principles that, according to him, "good design" should follow (here in video form if you want to feast your eyes on some classic Braun appliances):

1. is innovative
   
2. makes a product useful
   
3. is aesthetic
   
4. makes a product understandable
   
5. is unobtrusive
   
6. is honest
   
7. is long-lasting
   
8. is thorough down to the last detail
   
9. is environmentally friendly
   
10. is as little design as possible
    

Now, these might not be God-given indisputable facts, but for us mere mortals they're good enough guiding principles for now. Let's see a teachable example from C# where the designers hit these accurately with a feature whose design I'd consider "good", properties, and one less of a success, primary constructors.

C# properties, a case of good design

In ancient times, classes had to have getter/setter methods to offer controlled access to data that they wanted to expose (note that for historical accuracy I'm using C# as it was at the time, without expression-bodied members here):

Simple, gets the job done. However, it's also verbose boilerplate that the programmer has to write over and over again. And since it's a convention, not a language feature, it's up to the developer to figure this out and diligently follow. How does it fare with the ten principles above?

1. is innovative - Not really.
   
2. makes a product useful - It certainly does.
   
3. is aesthetic - It gets really ugly once there are a handful of these.
   
4. makes a product understandable - Yes, this is code that everyone can understand.
   
5. is unobtrusive - Not really: As a consumer of this class, you want to just access the person's name, but you have to go through a level of indirection.
   
6. is honest - It certainly is.
   
7. is long-lasting - It'll be useful and understandable in a millennium too, so yes.
   
8. is thorough down to the last detail - Yes, it is.
   
9. is environmentally friendly - Not too applicable here, but since it consumes too many resources (text and reading time) for what it does (which is little), it's perhaps a "no".
   
10. is as little design as possible - Certainly not.

So, perhaps 5 out of 10. Can we make it better? Yes, with properties:

Properties are setter/getter methods implemented as a language feature, a mix between fields and methods. Is this any better?

1. is innovative - Yes, we just invented a new language feature to get rid of boilerplate.
   
2. makes a product useful - Still does.
   
3. is aesthetic - More aesthetic than getter/setters, but I think there's still room for improvement.
   
4. makes a product understandable - The code is still easy to understand, just from the English keywords you can get an idea of what's happening here.
   
5. is unobtrusive - Yes.
   
6. is honest - Kind of but not clearly: It now appears like a field, but it does more, like a method, without being either.
   
7. is long-lasting - Looking back from today, we can say yes.
   
8. is thorough down to the last detail - Yes, we have a clear picture.
   
9. is environmentally friendly - More than setter/getters, but not quite there yet.
   
10. is as little design as possible - Not yet, we still have plumbing to write.

Let's say, 6/10 at least, perhaps 7 if we want to be charitable. A clear improvement, but not perfect yet. Let's introduce auto-implemented properties:

Now we're getting there!

1. is innovative - Yes.
   
2. makes a product useful - Yes.
   
3. is aesthetic - I'd say now indeed yes. You may dislike the curly braces and semicolons of C#, but if you prefer that style, it fits right in.
   
4. makes a product understandable - Yes, and better than full properties.
   
5. is unobtrusive - Yes.
   
6. is honest - Less so than full properties: There is now an automatically generated invisible backing field. Conceptually, it's simple, but technically there's a lot more going on.
   
7. is long-lasting - Yep.
   
8. is thorough down to the last detail - I'd say so.
   
9. is environmentally friendly - Now yes.
   
10. is as little design as possible - I think so.

We now achieved 9/10. This is clearly good design. But what makes it great design, eternal design is not when you see its chronological evolution, but when you consider how you'd design properties today, after more than a decade of experience with C#'s implementation, looking back: I dare you to come up with a better approach (I'd argue other languages couldn't). The automagically generated backing fields are something to wrap your head around, but you don't have to: If you don't know about that, you can still use auto-properties and nothing bad will happen.

C# primary constructors, a case of questionable design

Utilizing Inversion of Control containers and Dependency Injection, we frequently write code like this (the point is in the constructor and field):

I know, very useful class, let's move on. What's up with our ten principles?

1. is innovative - Nope.
   
2. makes a product useful - Yes, Dependency Injection is useful, and we have no better way to do this.
   
3. is aesthetic - Not really.
   
4. makes a product understandable - While it's not rocket science, you still have to take your time to understand what happens in the constructor and why.
   
5. is unobtrusive - No, we have to jump through hoops to get our dependency injection working.
   
6. is honest - Certainly.
   
7. is long-lasting - Yes, it builds on principles that are decades old.
   
8. is thorough down to the last detail - Yes.
   
9. is environmentally friendly - Not really, due to its verbosity.
   
10. is as little design as possible - Certainly not.

4/10. You can of course understand why everything is like it is here, you need all the pieces. Still, do we want to write such constructor injection code, with the field and constructor parameter and assignment all the time? We could do a similar feat as we did with properties and turn this pattern into a language feature. Let's call that primary constructor!

Hmm, does my class now have parameters? Interesting. Does this mean clock is available in the whole class? Nope, just for the field initializer. It looks nicer but I'm confused.

1. is innovative - Yep.
   
2. makes a product useful - Hmm, yes, but we didn't gain any more use than what we had before.
   
3. is aesthetic - Looks better, though what's up with the parameter that's not really a parameter?
   
4. makes a product understandable - No, it makes it harder to understand.
   
5. is unobtrusive - I guess it is.
   
6. is honest - No, some magic is going on.
   
7. is long-lasting - Can't tell yet, it's a new and strange concept that borrows components from existing ones but uses them in different ways.
   
8. is thorough down to the last detail - Wouldn't say so.
   
9. is environmentally friendly - Better, but still looks like too much text.
   
10. is as little design as possible - Better, but we still have the field.

Still about 4/10, I'd say. The C# design team wasn't sure about this either, because they introduced an alternative way of using primary constructors at the same time, without fields:

This looks neat, but what is going on? The clock parameter is now somehow also available in the method. Is it then a field, just a magic one? But how can it be a field and a parameter at the same time? Is this the quantum computing already that they talk about? Is it a closed variable? Also, I like underscores to prefix class-level fields, it confuses me that now clock and days both look like local variables. But if I name the parameter _clock then it'll go against the naming conventions of parameters. Well, can I write this.clock, then? No, for some reason.

1. is innovative - Yes, can't argue with that.
   
2. makes a product useful - Yes, still the same.
   
3. is aesthetic - I like it, at least.
   
4. makes a product understandable - Hard no.
   
5. is unobtrusive - No, it broke my naming conventions.
   
6. is honest - No, it does something behind the scenes and tries to lead me on.
   
7. is long-lasting - Judging from the criticism it got, I'd guess that it'll need a lot of fixes soon, so no.
   
8. is thorough down to the last detail - No.
   
9. is environmentally friendly - As far as the amount of text goes, yes. However, I need a lot of glucose for my brain to understand it, and that needs to come from some sustainable farming, or we're all doomed.
   
10. is as little design as possible - I guess so, yes.

Maybe 5/10? Better where we started, but only marginally. This is something I'd expect from a new design pattern, perhaps, but not from a fundamentally new language feature. How to fix it? I have no idea; criticizing is easier than coming up with a solution, and I'm no language designer.

To be fair, primary constructors have other uses, and reinventing constructor injection was just one of its goals.

Did we learn anything?

I think you, as a designer (and if you invent any experience that people interact with, even an API or CLI, you're a designer), should approach your work foremost with humility. It's not about you, it's about your users.

This is a hard job, and sometimes goes against your professional desire (and your fun!) to create something impressive just for its own sake that you're proud of. You have to take a step back, back to the drawing board, and produce "good design". This sometimes means that you have to say "no" and admit that whatever you can think of right now wouldn't be up to your standards.

C# is my favorite programming language; I've been working with it since I was 15. Most of the code I've written in my life, and close to all my open-source code is in C#. However, I feel that in recent years, C# has become bloated. While before, every minor change came after meticulous consideration, now we see half a dozen new language features every year. I welcome progress, but when you're building something fundamental like a programming language that millions use, everything will have an outsized impact.

You could say that well, you don't have to use primary constructors, what's the harm in having it there? It still adds to the cognitive load of using the language. Unless some higher power tells you that you musn't use primary constructors and that's it, you must now consider one more language feature to use when approaching a problem. Code fixes and analyzers will nudge you towards it. You need to debate it for a day with your team whether you want to use it. You will migrate half of your code base in your initial enthusiasm before realizing that no matter how many band-aids you put on it, it just won't work for you (ask me how I know!). Arguably, my team would be better off without primary constructors ever landing in C#. And boy, are there many more such features!

Our big luck is that we have the sun in our neighborhood, which gives not just electricity for us to make sand think to read such letters, but it's also our source of low entropy (see this great Veritasium video about it). Basically, we all make a big mess, but we siphon the sun for that tidy energy, so we can continue to exist and engage in highly sophisticated debates on Twitter.

I think there's a similar dynamic of low and high entropy in human relationships, social structures, business entities, and software development teams too. Some people will increase the entropy of the system (couple, community, company, project team), and some people will work on decreasing it. E.g., you might leave the butter out around the kitchen, but your partner will always put it back into the fridge, so when anyone needs it, it's always in the same place. There's a balancing act here: The system needs to keep a state that's low entropy enough for it to function (if you open the fridge, the butter needs to be there, otherwise your hangryness will take over) but this can't come at the expense of the low entropy people giving up (your partner throwing the damn butter at your face if you leave it out one more time). Ideally, the optimal level of entropy is the same for everyone, but if not, then the people infusing the low entropy (putting the butter away) should be happy with their role in the long term. If this is not the case, eventually, the system will disintegrate (and you can enjoy your awful room-temperature butter alone).

Talking about a software development team, entropy is increased by e.g. writing sloppy code, not being attentive in communication, not following common standards, not keeping promises. Then somebody should work on lowering entropy by fixing the code, refactoring, asking the person repeatedly, chasing matters up. If this is not done, the team will eventually cease to deliver.

In my experience, productive development teams, i.e. those who consistently deliver high-value products to end-users, are usually where either everyone is of the low entropy type, or where key energetic people keep everything in check. In a good team, the latter are also developers, engineers themselves. When a manager type tries to keep entropy low against their team (there are entire methodologies for this like Scrum) then it usually doesn't work, and even low entropy developers can stop caring.

Note that I'm talking about entropy, not uniformity or homogeneity. Open-source software development can deliver spectacular results with team members being anything but uniform, or, to an uninitiated observer, even being bafflingly chaotic (the deservedly cultic essay "The Cathedral and the Bazaar" is about this phenomenon). This is because it's important to understand where low entropy actually matters, and only put effort into trying to enforce it there. Successful open-source teams instinctively know this, and usually, it's all about code quality. As long as you write good code, i.e. don't increase the entropy of the code base itself, your contributions are welcome (unless you're an insufferable jerk, but sometimes even then). Inefficient teams in large organizations, in contrast, put a lot of effort into enforcing superficial rules and processes, driving uniformity, instead of focusing on low entropy driving value.

The idea behind us at Lombiq trying to organize ourselves more as an open-source team than a company stems from a similar rationale. This style is certainly not for everyone, since most people can't function without a consistent outside source of low entropy (the sun excluded, we all kind of need it). But I think, at least when you want to run your own development team, you need to try to surround yourself with people who thrive in a low entropy environment, and who themselves can be a source of low entropy when needed.

Disclaimer: I'll make fun of some companies in this letter. This doesn't mean that I think they're altogether terrible, or that I wish them ill. In fact, I like most of these and their services very much. However, there are cases when they messed up, and those are teachable moments we can all learn from, not to commit the same mistakes.

Atlassian would like you to just please go to their competitor

If I had a nickel for every time Atlassian discontinued a service, made me trust them less, and forced my company to buy the same thing from Microsoft then I'd have 20 cents. Which is not much, but it's weird it happened four times. Almost five, actually.

Atlassian is notorious for rewarding you being heavily invested in their ecosystem with breaking your stuff and then telling you to just deal with it. We at Lombiq have been Atlassian customers for a decade, and during this, I lived through them discontinuing the following:

• The cloud version of Bamboo, their CI system. At the peak of us using Atlassian services, when we believed we perhaps wanted to do everything with their products, we were in the process of migrating over to Bamboo from TeamCity that we self-hosted. Then Atlassian made Bamboo self-hosted only. Right at the time when CI SaaS options became mainstream... We use GitHub Actions now.
• HipChat: It was a great simple chat service that started to show its age though, due to the lack of attention from Atlassian. At one point they announced Stride, their Slack competitor and slowly nudging HipChat users to move to the yet-beta Stride; we almost started migrating over. Then as a spectacular plot twist, they shut down both HipChat and Stride, urging people to use Slack instead, which Atlassian acquired a stake in. We said peace oot and moved to Microsoft Teams. To give credit to Atlassian, they did offer an automatic migration to Slack, and a full export feature if you wanted to move elsewhere.
• Confluence Team Calendars: Confluence, the wiki engine of Atlassian had a simple calendar feature. We used it to display project-related dates and have a common calendar for e.g. team events and holiday leaves. This was too much for Atlassian, so they moved it to the Confluence Cloud Premium offering. Since that contained only things we otherwise didn't need, instead of paying $5 per user per month for a simple calendar, we moved to Outlook which already came with Microsoft 365 we otherwise used.
• Mercurial on Bitbucket: Mercurial is a great source control system that was once a contender of Git but in the end, Git won. One of the last and certainly the biggest holdouts of a hosting service for Mercurial was Bitbucket by Atlassian. Right until they closed it down, keeping only Git hosting, and did little to help people cope with their repositories getting deleted at a cutoff date. Perhaps spending some time on offering an easy way out with a "Convert to Git" button (a feature that there are actually open-source projects for) would've prevented people from showing up with torches. Moving all of our private repos to GitHub, where we already had all of our open-source, was a no-brainer.

Things that would've helped me stay with Atlassian:

• Not leading me on by enticing me to use their service just before kicking me in the shin by closing it down. I.e., communicate clearly and openly with your users.
• Offering some help with a migration to stay with them. But if I have to do all the work, and with the same work I can go to a better service (Outlook, GitHub), then I'll go to a better service.

Also, offering an interlinked bundle of services works as a business strategy, but even this won't save you from people moving away if you piss them off enough. Especially developers, who can code their way out.

At GitHub we value your contribution to help our users, but not enough to not delete it

I'm all for open-source and open knowledge. Thus, if I spend my limited amount of keystrokes to help someone, I'd like that to be available to as many people as possible. I.e., if you have a question, I'm happy to help, but out in the open. And when people help me, it's a magical thing, and I'm really grateful for it. But then GitHub comes and deletes it.

GitHub had a central Discourse discussion board where people could get help from each other for everything involving GitHub. You know, increasing the value of GitHub.

At one point, they decided to move to their own discussion board, which is fine. However, in the process of this they a) made the old board unavailable and b) only moved those discussions over that had a message marked as a solution. If a thread had a page of valuable information but no marked solution (perhaps because there was no one solution, just workarounds)? Well, try to fish it out from the Wayback Machine or Google cache, and have fun with that. I had two important discussions vanish that apparently didn't get the memo that when something's on the internet it's there forever.

The takeaway here is, don't destroy knowledge that your users share with your users, for free, so both of them can pay for your service more happily.

Basecamp is happy to hear your feedback if you'd please repeat it every six weeks

The project collaboration tool Basecamp is usually great. When it's not great, you don't need to bother giving them feedback though, because if it doesn't pique somebody's interest immediately in the next development cycle, it's thrown out (huge kudos for them to publish this book for free though). I think I get the no-backlog concept. However, as a user, it demolishes my motivation to provide any product feedback if how it'll be taken into account is an opaque process, and with a high chance, it'll be thrown out without much thought. I had feature requests that I submitted to Basecamp support over the years, and I guess all of them ended up in the void.

Atlassian has taken a lot of heat from me above, and here I'd like to commend them for maintaining public issue trackers for their products. (Now, don't ask them though if a top-voted feature request will wait a decade until it's actually implemented.) As a user, I favor this openness, the ability to cooperate with other users, and that my keystrokes don't go to die on Basecamp's betting table.

Another hugely demotivating way to manage user feedback is similar to the GitHub discussion board fiasco above: I've seen both Microsoft and Zendesk collect feedback in a UserVoice idea board. They then deleted these, without bringing the previously submitted ideas over to the new system. I really didn't have the willpower to resubmit my feedback.

No, I still won't give you my phone number

This is not unique to one company, but I see it frequently. Your company has some stuff that I need and would like to buy or have a question about. Awesome, we'll make so much money together! Now if I could just write you an e-mail or something... No, there's a contact form with name, e-mail, phone number, and a kind message that you'll call me back! ... What? Can I at least attempt to tell you my very specific question before we chase each other via phone?

A sub-species of this is when I'm able to send them an e-mail. Then instead of getting an actual answer, they request a call, without reflecting on anything in my e-mail. Please, no. I had one case where we scheduled the call but then the sales rep didn't show up. Stellar. Alexa, play the hymn of salespeople.

Please, let me write you a message. If you need more info after that, or your solution is really tailor-made, then we can chat. But we won't start with a call from zero. Let's respect each other's time a bit more.

Moral of the story

I guess, follow Wheaton's Law with your customers?

Illustration: Midjourney prompt "Annoyed person crying about HipChat being discontinued by Atlassian. --aspect 3:1 --seed 3516117457"

Important job interview? Relax.

Learning to dance but can't tell your left foot from the right one? Relax.

First date with a special someone? Really, just relax.

Neck and shoulder pain from sitting in front of a computer? You should get up and relax your muscles.

Giving a public speech in front of a large audience? There's this school of thought that you should imagine them naked. I don't subscribe to this, since firstly, then you waste some brainpower on carefully examining each person and establishing a mental image of them without clothes. Secondly, this might cause your thoughts to wander to more pleasant pastures, at a time when you must keep focus. Also, I don't see giving a talk in a room full of butt-naked people would be any less daunting. So, I'd suggest relaxing instead.

Planning to overthrow the government and establish a military junta based on open-source principles? Honestly, I can't relate, but relaxing is perhaps part of the best course of action.

Feeling upset that you wasted 1m 3s on reading trivialities? Gentle reader, please relax.

Illustration: Midjourney prompt "Person relaxing in a hammock with 1000 unread emails. --aspect 3:1"

For two weeks, every night I was teleported to the Pacific, riding along with the Barb under the command of Fluckey. I was anxious about the upcoming patrol. I felt the excitement of finding the enemy and rooted for it to get into the firing line. When the torpedoes were launched, I held my breath that they'll run straight and hit. I felt the retaliatory depth charges shaking the whole tiny boat when it was their turn to wreak havoc and it wasn't lost on me that any of these could be the last one. Finally, I felt joy, pride, and relief, when sailing into the home port, alive and victorious. I felt the guilt too, of the destruction unleashed, and the lives lost to horror, for while they were the enemy, they were people and sailors like me.

Note that I don't think you can really spoil the book, it being nonfiction and not operating with plot twists, but be aware that below I'll refer to some parts of the story.

Fluckey's operations were unique in the era because he was highly aggressive as a submarine commander, seeking out targets to destroy. His US contemporaries in the same area of operation were more passive, waiting for enemy ships to come by, mostly hiding just under the surface, in relative safety from air attacks. Fluckey used his submarine more of a torpedo boat, patrolling on the surface, scanning a wide area with its extended periscope, and only submerging to dodge aircraft or immediately before an attack (sometimes not even then). This made the Barb one of the most successful submarines of the war. (You have to keep in mind that submarines of the time could only stay fully submerged for a few hours, otherwise having to use their Diesel engines on the surface.)

Creativity is perhaps not one you think would be the most important skill for a submariner, but Fluckey was incredibly creative in combat as well. One thing that makes the US war machine so effective is that it gives certain freedoms to soldiers on every level to reach the objectives with the means they see fit. Fluckey utilized this fully. On his fifth and last patrol as a commander, he went completely crazy on the Sea of Okhotsk with his diversionary mission: the Barb attacked Japanese targets, both land and sea, all over the place, zooming from target to target at high speed. This gave the Japanese command the false impression of there being multiple attackers, and that the US intends to invade the island of Hokkaido. Barb was the first submarine in history to launch rockets at land targets. They even blew up a train as part of a saboteur attack carried out with rubber boats.

What I was always wondering while reading the book was, how can someone like this get back into peaceful life after the war? If for years your job is to hunt for the enemy on the seas in a high-intensity, global conflict, what happens if that conflict is suddenly over? There's a navy in peacetime as well, sure, there are patrols and exercises, but you won't be going around sinking Japanese ships by the dozen. And if you have to go back to civilian life altogether? It turns out that for Fluckey, at least, the answer was that, as a Navy professional, not a conscript, he very well remained with the Navy, retiring as a Rear Admiral. Most of Barb's sailors became civilians after the war - what, for them, was just one more uneventful patrol cut short.

Should you read this book? If you're interested in military history, especially submarines, with some lessons of leadership, yes. For me, it was one of the few books I had a hard time putting down. However, I believe for the average reader its logbook-like format, going hour by hour, and the details of submarine warfare are probably less enjoyable.

Oh, and what does "thunder below" refer to? I guess you have to read the book to find out!

Illustration: Midjourney prompt "A barely visible periscope of a World War II submarine. --aspect 3:1" I had vastly more creative prompts, but none of them produced anything nice.

As somebody running a company, at first, becoming GDPR-compliant was a hassle, a time and money sink. I thought that the only thing we were doing was hiring lawyers to create lengthy privacy policies that nobody will read and developing cookie banners that everybody will hate. And in the end, we'll manage what little personal data that we collect in the same way as before, since we already were conscious about keeping them safe.

But I had to admit even then, and especially in the 5 years since, that GDPR wasn't the regulation we wanted but one that we needed. We had to, for the first time, actually think through in-depth how we manage personal data. There was no documented process to delete user data, so we created one. Writing the privacy policy helped us understand how we use all the online services where we keep data, evaluate whether we need all of them, and make sure the data there is safe both from prying eyes and from getting lost. Finally, while I personally hate the annoyance of "cookie warnings", I don't have a better idea. They're not just about cookies, mind you, but giving (or refusing to give) permission to a variety of data collection and profiling.

GDPR is still a chore. But it's necessary; there's no fair game without rules, and data protection was a partially regulated wild west. It also improved people being aware of data privacy. Some of them actually read the privacy policy, and request their data be removed!

I also understand it being important for me as a private person since I'm only an entrepreneur in one company, but I'm a consumer with many. Am I at a dentist's office, giving out a bunch of my very sensitive healthcare data? Yes, I'd like to see the privacy policy. Yes, even if you have to dig for it in the drawer. Are you a telemarketer calling me? Thanks, but not at this time, I want my data to be removed. We both know you actually have to do it. Are you sending me newsletters without an unsubscribe link? That's illegal, but water under the bridge; a polite e-mail mentioning the magic word "GDPR" will quickly remove me from the list though.

We need more groundbreaking regulations such as GDPR. Yes, we the companies will complain about having to work to become compliant and because we hate rules that aren't ours. Yes, we the people will complain because there's always something to complain about. But ultimately, this is what governments should do: create legislation that protects those who are less capable of asserting their interests, or dare I say, who're weaker. 

1. Almost inevitably, you call at a time when I won't pick up. I'll be deep in the flow with some programming task and I won't interrupt that. I'll be sleeping. I'll eat my lunch, without my phone, in another room, and I won't sprint over mid-bite. I'll be with my girlfriend, and I either won't be in the mood to talk to you or oh God, I'll definitely not be in the mood to talk to you. You get the idea.
2. I call you back because I'm such a nice person. Now it's you who it won't be suitable for, and you won't answer.
3. You call again. No jackpot still.
4. It's my turn to call you back. Miraculously, you answer. You tell me that it's not a good time since you're in a meeting (I don't understand why people do this instead of just not picking it up or replying with a text) but you ask me to please call you back at 14:00 when it ends.
5. Since I know how it goes with meetings, I call you back only at 14:10. And finally, we can actually talk about the thing!

However, the mind-numbing inefficiency doesn't stop after we finished our awkward dance of kolo. Unless I was sitting in front of my computer, I couldn't take notes. So, I now need to do that from memory, which, given the reason why I take notes rigorously during meetings (it being me not trusting my ability to recall arbitrary information precisely in the distant future), will be error-prone. Then I'll ask you about details we talked about, and you'll forget things too that I'll have to repeat to you. Most possibly there are other people outside of us who need the information we discussed as well, so now I take on the role of postman and write down our conversation for them.

People call because it'll be "quick". Unless both parties' day is a vast emptiness, it'll be anything but. I get it though, it's about not having to think: If you have to send an e-mail, you need to gather your thoughts upfront instead of using the other person as your copilot to navigate the matter. And thinking hurts, your brain starts to suck up glucose and every cell in your body screams for you to stop. You may also not be able to type quickly. Unless a disability prevents you from it, the better investment of your attention is to learn it though. You'll also feel like a hacker magician typing away blindly soon enough!

So, please, unless it's an emergency, send an e-mail (or any other message). Am I being selfish? I'm trying to be respectful not to interrupt you, and considerate of both of our times. Calling randomly is selfish, actually, since it says, "I want something from you right now, so throw away whatever you're doing and listen to me".

Needless to say, when it comes to family members and close friends, or urgent matters, calling is fine. This is about more of a professional setting. Arranged calls and meetings scheduled in advance are not what I'm talking about either.

I'll be looking forward to your e-mail!

The Wikipedia article about the EU reads like a description of some kind of Utopia. Good for them, you could say, but the Brussels effect, most recently the well-known GDPR, shows that the EU asserts the influence of its domestic policy globally. As an economic unit, the EU is the third-largest economy in the world (after the US and China, and could even be better if the naughty British didn't mess that up). With a monetary union in form of the Euro, the European rule of law mechanism, or projects like the European super grid, the EU (and the EEA, really) becomes ever more integrated, more than just a loose alliance of countries. Speaking of money, the Euro is the second-most used currency in international trade, trailing not much after the US dollar, the two covering more than 75% of the transaction value. Nowadays, finally, there are talks about building up independent EU capabilities in terms of space research and defense as well, not to have to rely on our American friends too much. (Though did you know that the James Webb Space Telescope was hauled up by a European rocket, from the EU space port in French Guiana?) And recently, in an unexpected glance of hard power, the EU will acquire weapons for the first time in its history.

At the table of aggressive, or at least highly assertive global players, the EU appears to be the soft-spoken pacifist who's not aware of their capabilities and especially potential. This seems to be changing, however; I do hope not the "pacifist" part, but perhaps we in the EU are starting to understand that we have something more at hand than we used to think of. The elephant in the room is of course federalization: Will the EU become the United States of Europe (I'd keep the name "EU" though, it's cleaner)? Functionally, I don't think too much needs to change, and if we draw the trends, the EU will inevitably end up being a federation, whether we call it that or not. For that though, we all have to understand that losing some kind of perceived sovereignty (after all, what has the EU ever done for us?) is a small price to pay to be able to maintain and defend our peaceful, free way of life.

At the software company Lombiq, we work all around the clock. On contrary to global teams that do this by "following the sun", most of our team members are in the same or close time zones. So, it's a result of us being a remote-first, distributed, asynchronously collaborating team: there are people who, following their personal preference, get up at the same time others go to bed, despite living in the same city. We also have clients and partners from all continents. This means that, especially if you fulfill a leadership role, you'll always have something to catch up on when you first sit down to work for the day.

Can we replicate the calmest week? Is it possible to make the world stop for you while you're away from the keyboard, during weekends, public holidays, or when you go on vacation? I don't think so unless we go extremely local and synchronized, including with clients, which isn't really possible in IT (but can be the case if you open a corner store without an online presence, for example). There are experiments like at the German automaker Daimler, to free you from at least having to chew through the dump of e-mails that you get during your time off by auto-deleting them. While this is interesting, you'll still have things to catch up on, causing stress during your first few days of being back. Also, I as someone running a company can't really imagine telling prospective clients that their e-mail was deleted, and if they really insist on the pleasure of giving us money, they should send their e-mail again when it fits my schedule.

So, what can we do? Since I don't think the root cause can be solved (or rather, I don't think there's an actual problem to being with, i.e. people you work with communicating with you), what I recommend tackling is the effect: you having to catch up on matters. So, here are my tips, that I follow continuously, so the cognitive load of everything happening all at once is reduced not just when I'm on holiday:

• Distribute not just work, but responsibility. I'm consciously the opposite of the managers that tell they "want to know about everything". When working in a team, have defined areas of responsibility that allows you to not care about things. You don't need to further optimize communication if there's no communication.
• Turn off disruptive notifications. The only time my phone makes a sound is when somebody is calling (so the only time I use my phone for synchronous communication). Everything else can wait until I decide that now I want to deal with it (like reading e-mails). Similarly, turn off any kind of desktop toast/popup notification.
• Unsubscribe from what doesn't matter. If you notice yourself ignoring something that you get notified about, then unsubscribe from it. This sounds obvious, but people still somehow postpone it; I think this is because deleting a notification is a tiny bit easier than unsubscribing, and they subconsciously want to rather "pay" the single delete click right now than the two clicks to save many single clicks in the future. E.g., unsubscribe from newsletters that you don't actually read, mute conversations/hide channels in chat apps that you don't care about daily, and unfollow tasks in the collaboration platform you use.
• Have a central stream of things that matter and may require action. I find that e-mail, as the lowest common denominator of all written communication, works well for this. You can get a list of things that require your attention, ordered by the time you received them. Due to this, I turn off in-app notifications whenever possible, and channel everything to e-mails instead (like notifications from the collaboration platform Basecamp, or the issue tracker Jira). Note that then you have to be diligent when processing e-mail, where I think the best is to go one by one, reading and replying to everything, not postponing anything.
• Set up e-mail rules to delete what you don't need to see. If all else fails, and you still get e-mails about things that don't matter to you, then employ automation to get rid of them. The upfront "investment" is a lot greater than unsubscribing, so you must be conscious about going through the pain of creating rules to then get the dividend of not deleting junk continuously.

I also recommend the book It Doesn't Have to Be Crazy at Work by Basecamp's founders, which largely matches how we work at Lombiq. Shape Up is worth a read too.