💡 How to Organize Workspaces

This is one of my reflective notes that merely help me to organize my thoughts rather than offer polished solutions suitable for a broad range of scenarios. Still, I hope I am about to discuss an important topic, and my take on it might have some value.

There is a huge topic of "productivity", "project management" and so on. In turn, it can be divided into subtopics like "organizing knowledge", "managing a team", "working with assignments". There is an extensive literature on many of these subtopics. For example, well-developed systems like Scrum encompass a number of techniques on task management, team organization, and structuring project development activities. My goal here is to move away from the logic of project development and to focus on its physical structure.

When a team works on a certain project, it "lives" within a project environment all the time. One way of thinking about it is to consider distinct services comprising this environment. For example, if the team decides to keep some project knowledge in a wiki site, there should be some virtual place where a team member has to go to seek knowledge. Similarly, if people prepare video clips, they should know where to get source materials and where to put end results. While this "project world" can be quite complicated, it is at least single, so it is not overly difficult to remember where different things are supposed to be.

My typical experiences are not like that. I have to work on numerous projects simultaneously. They are usually not very complex, and more often than not I am the only contributor. Still, they are quite diverse, and switching between them becomes painful. Instead of one environment, I have maybe a dozen, so keeping in mind where a certain artifact should reside in a specific project is next to impossible. Sometimes I can’t even remember that a certain "thing" is in the project at all! Let’s discuss what we can do about it.

Earlier I used the phrase "project world" to refer to the team’s everyday environment. If we consider small-scale projects, a "smaller" expression like "project room" would be more appropriate. It is also better as a metaphor, since a room can be organized in any way we want.

Suppose I have created a comfortable project room for myself, and am working there happily. However, after some time I have to postpone this work for a while and to switch to some new project being set up in the next room. How would I organize it? Well, unless there is a compelling reason, I would arrange it exactly in the same manner! If (let’s continue the metaphor) my workbench is in front of me, tools are on the right-hand side, reference materials are on the left-hand side, and I am happy with it and got used to it, why would I do it differently this time? Even if the same setup feels a bit suboptimal for the new project, sticking to the same scheme makes the process of moving between the rooms smooth and easy.

This concept of project-specific "rooms" is not new, of course. For all my Python-based projects I create separate virtual environments and install all the required dependencies locally. Yet, a separate environment for some programming language-specific tools is just a small piece of the whole puzzle. Before moving on, I’ll rename rooms into workspaces, as I think this word suits the concept better.

Ideally, a project workspace should be represented with a single isolated virtual entity (a folder or a window), serving as an entry point for all workspace elements. Unfortunately, in practice this is nearly impossible to achieve in a clean way, and obvious half-solutions to create such an entry point barely worth it. For example, if I write some software, I’ll need to setup its code repository. It means I need a dedicated disk folder, ideally connected to a remote server like Github for backup and sharing. Next, suppose I need a file storage space where I keep input/output files, data analysis results, related reading (e.g., PDFs) and various sorts of temporary documents I typically receive from colleagues. This storage should not be a part of my codebase, and yet it should be somehow "connected" to it. In addition, the storage should also be shareable and backup-able. Technically it means a separate folder, and I see no ways around it. Thus, we have two folders now. One "obvious half-solution" for making a single entry point I mention above is to create a starting document with links to all related "subspaces", such as a repository and a file storage. I think we can easily get away without it, however. A simple trick I use is to employ the same services in every project, and to create the same-named project entity in each service. I know it sounds quite abstract, so let’s finally consider specific examples.

My projects are typically either software development, or research works. To help me getting things done, I have the following services running:

These are self-hosted systems. Naturally, instruments like Github instead of RhodeCode/Redmine and Dropbox instead of Seafile would work equally fine, if not better.

I also use OneNote notebooks to keep project notes and Citavi reference manager to organize my (scientific) reading. If I need to download a webpage to read it later, I use SingleFile.

Specific services are not important now. What is important is the types of entities comprising a project in my case. They are:

As I said earlier, logically they all belong to a single "workspace", and yet it is nearly impossible to keep them all "together" somewhere from a technical point of view. The next best thing would be to make a separate project entry of each required entity type and retrieve them by name when necessary.

I should note that some services encroach on their neighboring territories and thus help grouping workspace elements under the same umbrella. For example, Github serves both as a source code storage and as a task management tool. Citavi can be used both for reference management and for note taking.

I tend not to use such "secondary" capabilities, overlapping with other tools' domain. I feel it gives me more flexibility, but I don’t really have any firm opinion. Say, I believe that Github issues functionality is best used as a bug/feature tracker for the codebase rather than as a to-do list for the whole project. It feels strange to add tasks like "think on Mike’s email sent on 5.5.2022" or "exam available libraries implementing the NN algorithm" there.

Similarly, I don’t feel comfortable adding project files to the codebase if I don’t think they are a part of the codebase. There is also a technical consideration: a repository never gets smaller (since it keeps the whole history), so continuous additions and removals of large binary files can make the repository really large without any apparent profit.

Suppose I am starting a project named FooBar. This is what I will have to do:

With this setup I always know where to look for project data. If I need project notes, I open FooBar in OneNote’s Projects group. If I need the code, I open FooBar folder inside C:\Projects, and so on. In principle, I typically start with OneNote to make sure that at least some initial project notes are available. Files or source code might never appear at all.

One good feature of this approach is its extensibility. If I have to add some new type of a service (say, a team chat), I’ll simply create a channel FooBar. Thus, I basically have to remember what kinds of services I use and what is the name of my project.

This experience breaks to some extent when I need to use an alternative service provider (RhodeCode vs Github or Seafile vs Dropbox). In practice I am trying to use the same services for most of my projects and list non-default providers in project notes (this is another reason why OneNote notebook is the first entity to be created: it supplies all the missing pieces for the workspace).

Wrapping up, I have to repeat that this approach is definitely not flawless and not necessarily the "best practice" to follow. Still, I cannot invent anything better as of today. Maybe there will be a method to organize workspaces in a cleaner way sooner or later. It is also possible that not many people actually care about the type of difficulties I am dealing with here, so I am sticking to my scheme for the time being.