2 Orientation
2.1 Start with systems, not software
People often try to improve their research computing by swapping tools. A better first move is to define the system you are trying to build.
Your digital research lab has at least six layers:
- device and operating system
- shell, editor, and package managers
- files, folders, and naming rules
- notes, references, and task tracking
- code, data, and results
- backup, sync, retention, and publishing
If one layer is weak, the rest becomes harder. Powerful software cannot save a chaotic file structure. A good cloud platform cannot compensate for weak local habits. A beautiful note-taking app cannot rescue missing source data.
2.2 The base capabilities to build
Before choosing specialized tools, make sure your lab can do these things reliably:
- create isolated project directories
- install and update tools safely
- record decisions and assumptions
- version code and text
- separate inputs from outputs
- recover from device failure
- move work between local and remote environments
- onboard your future self quickly
2.3 Choose defaults that reduce cognitive load
Good defaults are more valuable than exotic customization. A research lab should reduce the number of daily choices you have to make. For example:
- use one primary shell
- use one primary editor
- adopt one project template
- use one note-capture path for rough ideas
- define one place for active datasets
- decide in advance what gets backed up, archived, or deleted
2.4 The first strategic question
Ask this before installing anything:
What kind of work must this lab support in the next year?
Common answers include:
- writing and computational notebooks
- data analysis and visualization
- simulation or modeling
- GIS and spatial data work
- literature review and synthesis
- publication and reporting
- collaboration with teams or institutions
Your answer should shape the lab, but not overfit it. Build for the next year, not the next thirty days.