Using multiple machines efficiently as a designer and developer – Part 1

Some years ago I published a post about setting up a fully mobilized work environment for 3D visualization with a desktop and a laptop PC. In-between my focus field, requirements and tools changed a lot, but the need to manage multiple machines remained part of my life. Creating on not one, but many devices is a major challenge to productivity, but good practice and workflow can make you much less dependent on the actual physical hardware you have. Setting up and sticking to rules becomes critical to stay on top of processes when there are multiple ways of doing things.

In this two-part article I share high-level concepts and an efficient setup to help make your devices work for you (and as reference for my future self). In Part 1 I go into efficient file management, and in Part 2 I explore system administration best practices when having multiple devices for design and development.

Setting up and sticking to rules becomes critical to stay on top of processes when there are multiple ways of doing things.

Utilizing multiple devices

Let's start by discussing why you might actually need to have multiple machines at a time. Having just one laptop would make your life easier, and solve a lot of problems we discuss here. However, if you're a creative dealing with multiple fields like design, development, and maybe even 3D, one laptop may not be able or economical to cover all your needs. You might need rendering power sometimes, but prefer a light laptop to commute with. You might work on a medium size laptop on normal days, but prefer a smaller one for travel. You might just want to keep a secondary machine you can transition to quickly if needed. You might need to work with more operating systems at a time, and virtualization may not cover your needs. There are several possibilities we can think of that justify the need for more than one machine.

In general, the less machines we need to manage the better it is from a maintenance perspective. I have for example a desktop workstation, two laptops, and an external hard drive. Each device has its purpose, but managing them efficiently is challenging. I summarized some key things to think about and continously look out for when having multiple devices:

• Make sure you clearly define what you use a machine for, and stick to it.
• Make sure that two machines can't be one in your specific case.
• If there's a machine you can't differentiate, sell it.

Overviewing directories for productivity

In design and development you'll certainly deal mostly with files. However, the latter might involve some special files like .git directories and databases, that are a bit more specific in portability context.

Selecting drives and filesystems

When using multiple machines, the portability of your primary working directory is critically important. I suggest you setup a fast and reliable portable drive for this purpose, that doesn't depend on any other devices you have. Ideally it should cover the storage requirements of all your files. I suggest you go for a flash storage if possible, and choose by balancing convenience and performance. (Currently nano-sized flash drives are available up to 512 GB with fairly ok speeds, and portable SSD drives are available up to ca. 4 TB with excellent performance – either can work well accordingly.)

Based on the operating systems you run, another thing to carefully choose is your drive's filesystem. Basically you want your drive to be compatible with all your machines, so that it's effortlessly shared. If you run Linux and Windows, your drive will likely be exFAT (likely preformatted as exFAT if it's flash storage) or NTFS (likely preformatted as NTFS if it's HDD storage). If you also run MacOS either next to Linux or Windows, your drive must be formatted as exFAT (without using special software). Most Linux distributions handle exFAT and NTFS by default (as required packages come preinstalled with most distros). Familiarise yourself with differences between filesystems before choosing one.

/.../ you want your drive to be compatible with all your machines, so that it's effortlessly shared.

Managing design files

As designers, we're spoiled by the modern tools we use these days that we don't even need to install locally to create. Though browser-based design tools – like Figma and Penpot – also manage files for us, it's usually good practice to save our files also to our local filesystem no matter if the design tool runs remote or on-premise. In other cases, we need to deal with local files in the very traditional way. In 2021 I created a guideline repository with suggestions for efficient file management of creative projects. When working with multiple machines, in terms of design files you can't go too wrong until you work only on your portable primary drive, that you mount similarily to your different machines.

Managing development files

In terms of creative development, file management can be a bit more tricky when developing from multiple machines, as project-related files might not only reside on your working directory drive, but within your local development environment, depending on tech stack. In case you only work with flat-file architectures, like flat-file CMSs (e.g. Grav CMS), than the portability of your projects is fortunately given. However, most developers work with complex stuctures like databases, that run in a different application layer.

The important thing here is that you always consider portability, and be open before sticking to default practices when setting up a project. Let's say you need to set up an application on the LAMP stack, like a WordPress site. Before setting up your local MySQL server, and initialize your database locally, consider for example setting up a remote database server instead on a service like Elestio, which not only would make installation only needed once, but also easy to change from one development box to another without moving databases. In most similar cases you can find alternatives before you add device-specificity to a project you work on. In Part 2 we'll go into more detail on how it's efficient to setup local development environments when developing from multiple machines.

In most similar cases you can find alternatives before you add device-specificity to a project you work on.

Overviewing backup in a multi-device environment

It goes without saying that backing up data frequently is important part of all work on computers. However, when working from multiple machines, building up strict backup routines is even more critical. As a general rule, you must have two local copies, and one remote copy of all working files.

Creating and managing local backups

When having multiple machines, and possibly several extra drives and storage, it might be tempting to just manually back up files at good will. Though having two local copies of files is important, I think it also is enough: I suggest you against having to maintain more than two up to date local filesystems, due to the extra maintenance and more likely human errors.

Follow the rules below, or create your own and stick to it for a very good start:

• Choose your primary working drive and your backup drive, and use them only for their purpose.
• Set up a recurring backup schedule, for example every-Monday for a weekly backup frequency.
• Choose your backup tool, and stick to using it. A good option for Linux is rsync, and a good option for Windows is for example FreeFileSync.

Use your backup tools consistently. When using rsync, build your backup script for reuse, for example:

rsync -inruv --delete --exclude=*/.Trash-*/ --exclude=*/.recycle/ --exclude=*/cache/ --exclude=*/.git/ /run/media/user/Elements/Backup-from/ ~/Backup-to/

Creating and managing cloud backups

When speaking of cloud backups, it's important do differentiate between cold and hot sorage. Cold storage is a type of cloud storage, that focuses on capacity instead of frequency. It's designed specifically for backup, and data stored there isn't available instantly but within a reasonable amount of time when needed. On the other hand, hot storage is cloud storage that's instantly available, not only for backup, but also for working in the cloud. The mainstream cloud options you likely know and use (e.g. Dropbox, Google Drive, Microsoft OneDrive, etc.) belong to hot storage within this classification. The open-source Nextcloud can also be classified 'hot storage', but the availability of data entirely depends on the server that it's run on. Both cold and hot storage can work for backup, and the choice depends on personal preference. Cold storage often is cheaper, and usually comes with proprietary desktop clients that promote a specific way of using the service. Hot storage opions often allow more flexibility, especially Nextcloud that you can configure and use however you like.

In the context of cloud backup, it's very important to think in a 'one-way' setup even when using a hot storage option: use the service (or its isolated part) strictly for backup. There are many tools for setting up hot storage for backup. One of my favorites is OneDrive Client for Linux, which allows even more flexibility than the official client. A backup-specific command for example can be as simple as this: onedrive --synchronize --upload-only, which you can run periodically. (The client's configuration allows a lot of options, and setting up exclusions etc. likely is a good idea, but the details are out of scope of this article.) Setting up Nextcloud for backup can also be a very good solution, but managed Nextcloud services usually cost significantly more than mainstream alternatives, while running a personal Nextcloud instance is not always an option.

/.../ it's very important to think in a 'one-way' setup even when using a hot storage option: use the service (or its isolated part) strictly for backup.

Summarizing file management

In this article, we discussed the challenges of having and working from multiple machines in terms of files. We explored how you can overcome the difficulties of using multiple operating systems by intentionally selecting filesystems and delved into details of managing design and development files. We also provided an overview of local and remote file backup options and highlighted the importance of setting up strict practices, especially when running multiple computers. In Part 2, we will explore some possible good practices that will help you efficiently administer multiple systems while minimizing dependency on any one of them.