Lunch Time Thoughts

🐍 Python and Locales

2022-01-14T00:00:00+00:00

Beware when working with locales! So this post is kinda short and maybe a bit incoherent, but today I had a facepalm moment at work that I want to preserve for a little while.

🐍 Python, 🔀 Abstractions, and 🖥️ Operating Systems

Back when you learned Python, you probably read that the code is platform-independent. You write your code, and if it works on your machine, it is expected to work on any other machine that has the same libraries installed.

Okay, once you deal with things close to the OS, such as filesystems, signals, et cetera, then it’s reasonable to expect you code to not work anymore. I get that. But when you’re dealing with highly non-OS-related stuff like localization, you shouldn’t need to worry, right?

Riiight? 🤔 Hmmm…

Well, it turns out that things like locale-dependent sorting are also platform-dependent, if you trust your OS. This became apparent when I tried to access the REST interface offered by the BOC Group to do some business stuff. Auth worked fine on Windows, but as soon as I pushed the code to our Linux machines, it didn’t. I got a 401, but only for cases where I passed some parameters. So I took a long and hard look at the documentation in which you find the following paragraph:

Get the secret key matching to the identifier sent via the x-axw-rest-identifier header.

Take all request parameter names and put them into a collection.

(…)

Sort this collection using Locale en_US.

Aha! Sorting using a specific locale… We got some locale issues earlier on, so I investigated and found a line like this in our implementation:

collection.sort(key=locale.strxfrm)

Some debugging then confirmed my suspicion: Locale-specific sorting using the locale module is platform-dependent! I repeat…

Locale-specific sorting using the locale module is platform-dependent!

👷 Details

How the hells is something as abstract as this platform-dependent!? Well, whoever made this design decision surely had their reasons - I don’t blame them. I was just highly surprised. Also, my gut told me I’m not the first to encounter this, since we aren’t that special - despite nearly every organization believing this of itself. So I did a quick search and found this issue which is in status “open” since 2015 (!). The most recent comment goes like this:

In my experience, the locale module is error-prone and not reliable, especially if you want portability. It just uses functions provided by the OS. And the locales (LC_CTYPE, LC_MESSAGE, etc.) are process-wide which become a major issue if you want to serve different clients using different locales… Windows supports a different locale per thread if I remember correctly. It would be more reliable to use a good library like ICU.

Well, usually I hesitate to include a new third-party lib. But in this case I guess I’ll make an exception.

How To Leave A Team (Gracefully)

2020-10-06T00:00:00+00:00

Hi there!

Most things that have a beginning, also have an end. While there are some things for which this statement doesn’t hold true, e.g. the natural numbers, there are a lot of things for whit it does. Foremost, the time at our disposal.

One takes over a specific role such as a Backend Engineer, performs accordingly, and at some point it’s time to leave. For the purpose of this post, the reason is irrelevant as long as it’s foreseeable. One might be going to leave the company, retire, or simply switching teams within a company. It should go without saying that managing one’s farewell is as much a part of one’s professional obligations as writing and reviewing code or documentation. Whatever the reason, no matter how bad a team’s mood might be.

When And How To Start The Process

As soon as possible. As soon as you know you’re going to leave, plan for it accordingly. Start collecting issues and tasks that might end up as loose ends and tend to your documentation with even more care. Not only will it make it easier for your team to handle your departure, but this will also create goodwill for the time that precedes your farewell.

The Proclamation And The Fallout

Once you tell your team you’re leaving, there will be mixed reactions. Some people will be sad. Some will be angry, yet not necessarily at you specifically. And some people won’t realize the news until a few days before you actually leave. I think it’s important to clarify your intent to handle this as smoothly and professionally as possible. Make this message as explicit as possible. Even if you’re in a GTFO scenario where you just can’t stand some decision some part of your company made, or even one of your teammates. Keeping things professional is just part of being a professional.

Attitude Matters

Leaving with a demeanor of “not my problem anymore” is not just unprofessional. I think it’s just plain stupid and - even worse - illogical. Just as the time you spend at the beginning of a new role, it’s your attitude that matters most when you’re about to leave. I don’t say you should hug everyone on your way out, pandemic or not, but don’t hold grudges. For some people that’s more difficult that for others, but it should be doable in most cases. If it’s not, it might be wise to talk to one’s supervisor and HR department about a mutually-agreed early termination of one’s work contract.

So stay friendly if you can, stay polite if you can’t, and prepare your team for a time after your farewell. Look forward to your next job, your retirement, or sabbatical, but stay focused on the tasks at hand. If needed, find comfort in the fact that all will be over soon.

Preparing Your Team

In the best-case scenario, in which your bus count is larger than one, this is easy. Just end what you’re doing right now and pick up those cleanup tasks that never get a high enough priority to get done. Such tasks can actually feel very satisfying and completing them will earn you a lot of goodwill with your soon-to-be ex-colleagues.

But you’ll probably not work in such an environment. There’s probably a part of your work that nobody else knows a lot about. It’s that part you need to cover first and foremost as this is the part of work for which you’re currently irreplaceable. It’s now - more than ever - your job to make yourself replaceable.

Enabling Questions

You want your colleagues to know and understand what you know and understand, or at least as much of it as possible in the time given. And the earlier questions start coming, the more successful you will be. Simply standing in front of a whiteboard or giving a talk remotely won’t be enough to enable your colleagues to take over your projects and systems. It will be too much information for your colleagues to remember. And the problems you’re solving might be so complex that it’s just impossible to make your colleagues understand the problem and its solution that way.

Understanding Technical Problems

What works quite well, in my experience, is to first make your colleagues understand the difficult problems you’re solving, at least roughly. It might be keeping some old systems in sync. Or to access an external API that’s quirky as hell. Make them understand the problem, not only remember it, and the most important task is achieved. This is a process and will take some weeks to accomplish. Use any and all means necessary: Documentation, Code, Live-Demos, you name it. Then it’s time to…

WTFM

If you’ve started early, by the time you proclaim your upcoming departure, you’ve already written a lot of documentation. If not, it’s time to start now. After gaining a first rough understanding of the problems you’re handling, your colleagues will likely consult documentation. They will find and point out inconsistencies, missing information, etc. You will fix all that and simultaneously, you’ll foster a deeper understanding of the problems.

The Code

After a while, it’s time for your colleagues to dive into the critical code you wrote and maintained. There will be things that are missing, quirky, or just plain wrong. Asking about these problems will cause your colleagues to gain knowledge, which is exactly what you’re aiming at! If there’s time, and there should be, fix some bugs together. After all, it’s in failures that a system reveal their structure. Then, implement some smaller business requirements. Doing three or four tickets this way should spawn plenty of questions. Also, answering them will spawn follow-up questions. If that happens, you know it’s working. When good questions keep coming, you know have your audience’s full attention.

Tie Up Loose Ends

In addition to prepare your teammates for a time without you, finish your most important work. If you can’t, because preparing your coworkers takes so much time, finish as much of the solution’s design as you can and write a design document for your colleagues. There’s plenty of resources on the Internet about them, so if you don’t already have a preferred structure, pick one from the Internet you deem fitting and write one for all your “loose ends”. As always, it’s important to make your colleagues understand the problems foremost, and then your suggested solution. State constraints, benefits, open problems, etc.

Ends Are Beginnings

Do you remember the time when you startet out in your current team? And maybe the ones before? Great! Use that and think about what helped or would have helped you back then. In the end, taking over another one’s tasks is comparable to entering a new team: People are expected to solve problems about which they don’t now a lot, yet.

Why Give A Damn?

As you might now by know, I deem it important to give a damn, i.e. to put effort into making your departure as painless for your team as possible. “But why?”, you might ask. For several Reasons…

Altruism: Coworkers are People. Treat them as you want to be treated.
Selfishness: You’ll probably be held in high regards when you do it well. The Software world is a tiny place. A current coworker might end up being your next team lead or engineering manager.
Professionalism: Give a damn because you’re the gal or guy who gives a damn.
Practice: Your code will be examined. And chances are this is the most thorough code review you’ve ever gotten in that team. Simply because your current teammates might be more invested in it than ever.

Presence Culture and the Treasure of Lost Time

2020-07-03T00:00:00+00:00

Hi there! It’s been a few day since my last blog post, but this one really made me think and rethink the matter at hand.

COVID-19 forces many companies to move at least parts of their workforce into home offices, including the company I work for. Although this has been a productivity boon for me, as mentioned here, it has also amplified the problems that a presence culture brings with it.

By presence culture, I mean the omnipresent assumption that all potentially-impacted parties must be present in a face-to-face meeting, be it remote or in an actual office.

If one’s colleagues practice this culture, this costs a lot of time and therefore productivity. And I don’t mean only the time one spends in the meeting room. For any meeting to be meaningful, a certain amount of preparation and follow-up work needs to be done. Also, in order to do all this, another activity often needs to be interrupted, and a context switch needs to happen. This also costs time. All this time, comprising attendance, preparation, follow-up, and context switching, is hopelessly lost if one’s attendance in a meeting is insignificant.

Meeting Math 🧮⏱️

Let’s do the math here for a one-hour meeting to which we’re invited as a required participant. Since the meeting actually takes place, we can assume it is about something important, so this needs preparation. If we’re lucky, the invitation includes an agenda or we can find one in the corporate wiki. Reading and understanding the context takes some time. If we don’t have access to an agenda, we need to guess what the meeting is about and speculatively prepare for that. After the meeting is done, we refill our coffee mug and start our recap. Maybe there’s something that needs to be written down. In any case, we need to check the meeting’s minutes. Oh, we don’t have any. Well, let’s just write something up and hope we don’t forget anything of importance. We end up with:

1h for attendance
10min overtime because people were unprepared or late
45min preparation
45min recap

This adds up to a total investment 2 hours and 40 minutes for a one-hour meeting. For one person. If we assume that this scales about linearly with the number of people involved and the duration of the meeting itself, we end up with a huge investment of time, productivity, and ultimately company money.

I’ll just assume six people that each cost the company about 30 EUR per hour (for easier calculation). That’s a total investment of 480 EUR for one meeting. And I didn’t even account for context switch times. Also, I think I for a meeting to be worth the energy that six (!) people invest, the preparation time should probably be longer, depending on how simple it is to find the necessary information.

Now, if I assume six of those one-hour meetings a month, I arrive at a total estimated investment of about 2880 EUR in our six-people scenario. Of course, one could object and say that you could cut more than half of the cost if you just don’t prepare and recap. But it should go without saying that if a meeting participant would do that, they should just stay away from the meeting, as this leads to time not being invested but wasted. I’d make an exception here for people that just joined a company or team, but I’d expect those to start preparing for meetings rather soon – else they can’t at least follow along.

Meetings And Working From Home 🏘️

Let’s recap that presence culture thingy from above. I claimed that having being a remote team thrust upon you amplifies the problems. How so? Well…

People tend to be even later than usual because there’s less external cues for a meeting being about to start
People tend to be more distracted because it’s easy to do other screen stuff during the meeting
People tend to be more distracted because they might need to share their workplace with their spouse or kids
People tend to be more distracted because they see interesting stuff in their colleagues’ backgrounds
People tend to be more distracted because the small chitchat that happens on the office “side channel” now happens in the first minutes of a meeting
People tend to be more distracted due to technical difficulties

This all leads to meetings taking more time when the participants aren’t used to a remote setting.

Please don’t get me wrong - I don’t want to rant about people not handling these extraordinary circumstance perfectly. In fact, I admire how well my coworkers handle it! Should any of them read this: Kudos to you. 🙇 Especially if you had/have to watch your kids while working. And even if someone has their fair share of problems dealing with this new situation, that’s totally okay! Neither of us had a choice, so neither of us should be judged.

Conclusions 📊

I just want to suggest being more diligent when it comes to these decisions:

Do we schedule a meeting for $THIS?
Whose attendance is needed?
Whose attendance is not needed but would be truly beneficial?
What should I include in the agenda/invitation that would help my colleagues prepare?

And most importantly:

Do I accept this meeting invitation?

Ask yourself these questions whenever you’re tempted to propose or accept a meeting. Not every hour spent in a meeting is wasted, but every hour not spent in a meeting is probably not wasted. Lots of meetings could be a small (!) series of e-mails or chat messages. Try experimenting with an opt-in culture!

The Future 🔮

In my team, we’ve started to experiment with changes to our meeting habits. I’ll keep you posted on interesting results!

Thanks for reading and see you next time! 👋

Post-Lockdown Band Practice! 💖

2020-06-30T00:00:00+00:00

This blog post is neither technical nor philosophical nor a rant or anything that ever gets one popular on the internet. Instead, I’m just genuinely happy and want to share that with you.

You see, here in Germany, we had a long phase of official restrictions to social contacts. And due to unfortunate events, some areas in Germany still do. I’m very lucky not to live in such an area, so the people I’m making music with and I decided to start meeting and making music again. For the first time in four months. And it was just plain awesome! Yeah it wasn’t perfect because the guitarist couldn’t make it and we didn’t have the chance to practice together et cetera. But it was so much fun to make our own versions of HammerFall, Rammstein, and Eric Clapton songs.

The whole lockdown thing really made me think about the things in life I appreciate, need, and desire. And consequently, the things I can or want to live without. But this is for another time. In the meantime: Stay safe, stay healthy, and go tell someone you love them – be it in a platonic, romantic, or any other way. 🤗

Code Reviews And Expectations

2020-06-23T00:00:00+00:00

I had an interesting conversation at work the other day. A colleague started it by asking for our expectations towards a code review. We do such reviews quite often and try to never roll out production code that hasn’t been reviewed at least once. So, naturally, reviewing another developer’s code is something we do often. However, we’ve never spoken about a common set of expectations when it comes to reviews.

During the 30-minutes long and very fruitful discussion, two major positions emerged:

Reviews are there to improve the code.
Reviews are there to improve the coder.

The difference is small yet important. Obviously, given an infinite life span, improving the coder would be the one solution and we would have been done discussing after merely 3 minutes. However, reality is not so simple.

Now consider that the coder has a finite life span and therefore a finite time span during which the improved coder can write his automagically-improved code, and that giving and receiving a review both cost a significant amount of time and energy. Now add to that the fact that not everyone is able to learn from in-depth criticism at any given point in time. Personal struggles can occupy one’s mind and impair communication between reviewer and author. The simple fact that it’s right before lunch or time to go home can also have an impact on how well constructive criticism can be given and received. There are numerous reasons for why a review can fail to have a lasting and improving effect on a receiving developer.

So… what shall we do? On the one hand, we knew that the minimum outcome of a review is improved code. Check ✔️. And we agreed that often enough it doesn’t have to be the original merge/pull request’s author that hast to perform the improvements.

But can’t we do more? After all, we have an interest in our colleagues to become better developers. We haven’t found an answer to this question yet, but we have agreed to discuss this topic again in about a week.

I think that having a look at PEP20, the Zen of Python, can be very enlightening in this moment - as it can be so often in life. Right there, in line 2, it says:

Explicit is better than implicit.

Once again, when it comes to communication of any kind, PEP20 has an answer. It might not be the answer, but being explicit in one’s communication is rarely a mistake. So, for the time being, I answer the question of “what do I expect from a code review?” the following way:

I expect functionally improved code. Except for when I ask for “more”. Then I expect that on which the reviewer and I agree. And I’ll be grateful whenever I get more than functional code improvements.

That’s all for today. Stay safe and happy coding! 👋

Jekyll + Domain + Github = Blog 💖

2020-06-23T00:00:00+00:00

Hi there!

There was no post at lunch time today because I spent my lunch break finishing the setup of this blog on Github Pages. 🎉🎉🎉 When I told an old friend of mine how simple and fast that went, he just said something along the lines of “why don’t you just blog about it?” Well, here it is!

Overview

All in all, when I subtract the time it took me to convince my Mac to properly install Ruby gems even though rubygems.org wasn’t reachable via IPv6, set up a local Jekyll environment, and decide on a name, it took me between 60 and 90 minutes to set up. I’m still kind of a noob when it comes to setting up stuff outside of company networks. And because I configured some things that weren’t completely necessary, I expect that setting up this whole thing should take you no more than 30 to 45 minutes if you have access to a computer with a terminal you can work with comfortably.

Step 0: Decide On A Domain

Every blog needs a name, right? Usually I go with temporary first names and fix broken ones later in order to avoid analysis paralysis. But a domain is usually acquired for the duration of a year or more, so I decided to spend some time on choosing a name this time. Most blog ideas in my head hatch during my first four work hours of the day and I’ve spent quite some lunch breaks transferring thoughts from my head into the StandardNotes app on my work notebook. So I checked whether lunchbreak.dev was still unclaimed, looked for a cheap-yet-trustworthy domain registrar, picked one, and was very happy with the look of the domain in my browser’s URL bar. I’m rarely completely happy with names I pick, but this was one of those times! :blush:

Step 1: Create A Github Pages Repo

I really like the look of the Minimal Mistakes Jekyll Theme and it seems to be well-supported, so I decided on that, stumbled upon the very handy theme starter, and essentially started from there. Should you also choose to do that, and don’t have a Github Pages page yet, just use <your-github-username>.github.io as the repo name and substitute <your-github-username> with your actual Github username. Github recognizes that and automatically takes care of exposing the content of that repo to the web in a controlled manner.

More info on this step: Github Pages Docs

Step 2: Take A Look At Your Repo

If you used the theme starter from above, your repo structure should look similar to this:

Basically, all your posts are separate Markdown files in _posts, your pages are Markdown files in _pages. The latter are sub-pages of your blog that can be reached via the headers in the top right corner after adding them to the _data/navigation.yml file: As you might notice, I added a page called “RPG” to the ones that are set up by default. You can add pages to _pageswithout adding them to the navigation.yml, but then your page will only be reachable directly via its URL. This can be handy if you want only a few select people to know about a page, but don’t rely on that as web crawlers are a thing and because that page’s Markdown file is still right there in your repo.

I put my images into assets/images, but that location is not as important as the previous two directories. Your blog title, bio, theme skins, and more can be configured in the _config.yml. At the time of writing, this blog uses the “air” theme. In a completely basic Jekyll blog, the root/landing page of your blog is defined by the README.md, but this Jekyll theme is a teeny tiny bit different.

So now you know to put your posts into _posts and your pages into _pages(and maybe into navigation.yml).

Step 3: Connect Your Custom Domain And Github Page

This last step was actually way easier than I imagined beforehand. After purchasing/renting/acquiring your domain, go to your domain registrar’s configuration page and add an ALIAS record answering with <your-github-username>.github.io. In my case, this looks like this:

Afterwards, you can set up your new domain name in your page’s Github repo. Open the repo settings, enter your custom domain, and don’t forget to click Save. If you chose a .dev domain, the custom domain section of the settings page could warn you about an incorrectly configured domain or at least that setting up this custom domain could take a few minutes. This is due to .dev domains enforcing and requiring working SSL certificates. During this time period, your browser should warn you about accessing your blog with the domain name you’ve chosen because the certificate exposed by Github doesn’t match your new domain yet. In my case, it took Github about 10 minutes and my blog was reachable via lunchbreak.dev.

More info on this step: Github Pages Docs

That’s it!

You now have a working minimalistic blog you can adapt and expand to your heart’s desire. You can add posts on your machine and edit them there with your favorite editor, or you can simply use Github’s online editor for text files. You can also add your own pages like I did with my RPG page, to add a lot more functionality to your blog page other than “just” blogging. I use it to keep the most important info for my RPG group(s) accessible at all times. Maybe I’ll add a Recipes page, too. Who knows? 😄

You’ll notice that the blog doesn’t feature comments. This is another reason I chose this Jekyll theme, as I don’t want to have to deal with comments at the moment. I think as soon as I feel sufficiently comfortable working with this blog’s Jekyll theme, I’ll look for a way to add a comment function.

More info on Jekyll: https://jekyllrb.com/

Konichiwa!

2020-06-22T00:00:00+00:00

Hi there! This is just a simple starter post.

During the coming weeks, I’ll to do some smol lunch break blog posts on recurring thoughts and lines of reasoning, such that I can explain them briefly and refer to blog posts instead of repeating them in full detail.

Three Months of Working from Home

2020-06-22T00:00:00+00:00

It’s been three months now since I started working primarily from home, just like probably a lot of you. Three hands probably suffice to count the days I came into the office since the middle of March. My conclusion after these three months? I’d love to ditch a regular office forever. :D

Benefits a.k.a. Stuff That Works Better Now

As a developer without kids, my workplace has never been quieter than during the last three months. There were no heated discussions in the office on whether Python type hints should exist in the first place. No “have you seen team member XYZ?” during code flow. No “who wants to play table football?” when I’m debugging a ten-line SQL statement. Sure, those interruptions can be countered by wearing noise blockers such as these, but in my opinion, I shouldn’t have to rely those to be able to concentrate. Plus, they start to hurt after two hours of wearing them.

In my experience, the ability to focus one’s mind one one particular thing for a period long enough to allow significant, or “deep”, work to happen, is a developer’s most important resource. Possibly the most important of any screen worker. Without it, most people can’t accomplish high-quality results, but rather shallow reflections of what could have been. And working from home once again enabled me to focus. Instead of frequent interruptions by coworkers, I get an occasional hug from my significant other. Instead of debating/arguing where to go for lunch (or being berated for being too hungry to care) I can just have whatever the flip I want and enjoy my lunch break. And when I’m in the mood for chatting while taking my break, I can still ask colleagues for a chat at my company’s virtual coffee maker chat room.

Downsides a.k.a. Stuff That Doesn’t Work As Good Anymore

The most obvious downside, and I believe at least 50% of you people will wholeheartedly agree on this, is that the current circumstances in Germany with schools having been closed and all don’t allow for a quiet workplace at home. Your children are probably full of energy, and your spouse probably needs to work from home, too. And because you weren’t prepared for this, nor had any say in it, you’re stuck with a situation that leaves you less able to focus on anything right now. You have my sincere sympathies. So apparently, working from home is not for everyone. At least not in the current unplanned, unprepared, unwelcome version of it.

Another downside, and this also affects those without children, is that remote work is fundamentally different from in-office work. You don’t get instant reactions from your colleagues when you ask them something. You can’t just waltz over there and poke them if they forget to check their rocketchat messages for hours. You can’t just follow the herd when you forget where that one important meeting will begin in one minute. And you can’t just poke your teammate and ask them what that thing was you’re supposed to implement. Working from home needs a lot more patience, much more diligence, and a bit more organizational skills than in-office work.

Also, there’s little to no spontaneous exchange of ideas at the water cooler (or water blackener/heater, should that float your boat). No random two-minute discussions about that idea you were thinking about just now and that could be discussed and implemented in the next team meeting.

The last but not least downside I want to mention here is the blur between work and private life. Maybe you’re using your kitchen table to do your work? Maybe even right now? That means that you’ll probably have to share the table with your kids. What if you already have a nice computer setup because you’re a gamer/artist/whatnot? Then you probably experienced that sitting down to do your private stuff can feel like sitting down to work, should you use the same equipment. This can be really annoying because it’s harder to “wind down” after work. And no matter how much fun work can be sometimes, positive stress is negative stress is stress. The hormones are the same. Our bodies mostly don’t care for the difference.

How I Manage To Deal With The Downsides

I’m in the immensely fortunate position to having “trained” for this whole working-from-home situation. During my studies, I quickly got tired of looking for a place in one of the many libraries at my university. That search could take about an hour if I was unlucky, and often enough I only had one hour or two before your my lecture started, my family visited, or the date with my significant other was scheduled. Also, working on work projects in a library didn’t “feel” right to me. So I decided to ditch all those libraries – except for their books of course – and work/study at home instead, which was only five bike minutes away from campus. I experienced a lot of the aforementioned problems, including having loud and demanding chi– flatmates.

In the end, I succeeded in having a productive “office” in my nine-square-meters home and still enjoy my home whenever I used it as my home. And here’s what made a huge difference for me:

Establishing a signal that was to be treated as “Peter is not to be disturbed right now”. And no, a lot of my flatmates didn’t really get it. Drunk flatmates can be as unreasonable as children.
Establishing rituals and cues to signal to my self “you’re studying/working”. These cues and rituals were different for studying and working. When working, opening my work notebook was enough of a cue. It was large, heavy, and mostly crappy, which already felt way different from what I usually had/put on my desk. When I was about to study, I pushed everything to the edges of my table (keyboard, mouse, monitor, pen holder, etc.) so I could fit at least two open books, a college block, and a cup of tea on the desk without “squeezing” the stuff onto the desk. I even used an RGB LED bar above my table and a very bright lamp to distinguish between work, study, and gaming/drawing/netflixing mode. It worked and really eliminated the stress and anxiety from “spilling” over the edges of my study sessions into my working or gaming sessions.
I wrote down ALL the stuff I wanted to get done. This didn’t really work until I ditched paper calendars for simple plain paper notebooks that allowed me to structure my todos the way I could effortlessly manage them. I started bullet journalling and adapted that technique to my needs later – I still use that till this day, but I have separate notebooks for work and private life to prevent any possible “negative spillover.” This helped me get/stay organized A LOT. I don’t ever have to rely on whatever more-or-less sh**ty calendar solution my employer used to keep organized!
In addition to writing down todos, I tend to write down ideas when they come to mind. These could be things to try out and improve my work, or ideas for better organizing our team work. Currently, the latter is then added to our team meeting queue later or discussed at the next good opportunity. Also, I can rely on my teammates to put their important discussion topics to the team meeting queue. So I don’t miss a lot by not having random water cooler/heater/blackener conversations. And whenever I do miss idle chitchat, there’s still the good old – but now virtualized – water cooler/heater/blackener chat room!

Most of those tips are things you might have already read all over the interwebz. But if I just helped at least one of you with a tip or two of the above, that’s reason enough for having written this post.

Stay safe, stay healthy and don’t forget to have some fun. :)