Organization: basis for a healthy system

We always aim at keeping our system fast, efficient, and eye candy but the more we use it the more mess we create. If one will often try to keep everything visible clean, a more incidental mess inevitably accumulate. Hence it’s important to make sure to maintain our packages as up to date as possible while removing the unnecessary ones (including dependencies) but another good practice is to keep your config files organized. Everyone should know that the structure of the code in your files is critical and you can help yourself with this task by splitting your code to access it and maintain it more easily.

Even though I certainly do not pretend to have the ultimate solution, I try my best to organize things in a convenient way to me so let’s take two examples of my personal configurations.

╭── File system

To maintain an organized system, I implement a structure influenced by Tiago Forte’s PARA method. This method involves categorizing tasks and information into four main areas: Projects, Areas, Resources, and Archives. By grouping files under these parent folders, individuals can efficiently organize their data and easily retrieve relevant information.
Since I have always organized my files in topics/projects, I did not reorganized all my files within the above mentioned folders but I have customized the PARA method to suit my needs by adding only the Resources and Archives folders within each project folder. Hence my file system now looks like for a given topic:

• topic 1
  • project 1
    • task 1
      • folder 1
      • folder 2
      • Archives
      • Resources
    • task 2
      • folder 1
      • folder 2
      • Archives
      • Resources
  • project 2
    • task 1
      • folder 1
      • folder 2
      • Archives
      • Resources
    • task 2
      • folder 1
      • folder 2
      • Archives
      • Resources

With that I can now, for example, easily find:

• the template for a coding project “ABC” under Code (topic) / ABC (project) / Resources.
• the current version of a cover letter for a job position at company “XYZ” under Jobs (topic) / XYZ (project) / position.

Note that you can go one step beyond by combining this approach to the use of fzf to navigate through your file system.

╭── Zsh config

Every tuto will mention the .zshrc file and this is the core file of your config. In addition to it, I also have two other config files which I call in .zshrc with the command source path_to_the_file.

╭── Neovim config

The neovim initial configuration file is vimrc in vimscript or init.lua in lua. The latter is the one I use for my general configuration options.
Other options are stored in the following files:

plugins.lua is called with require('plugins') in the init.lua file
keybindings.lua is called with require('keybindings') in the init.lua file
each plugin config file is called with config = [[require('config.plugin_name')]] in the plugins.lua file

╭── Structure your structure

Having a way that works for you to split your configuration files is important but it is as much critical to keep each file well structured. No magic here, simply remind yourself to use headings and comments. As stupid as it may sounds, this will save you a crazy amount of time when you go back to your code weeks/months later.