How do you manage the mental complexity, file organization, context-switching, etc. when you are working on multiple codebases, perhaps multiple languages, etc.
Any tricks to keep things from getting too scattered?
How do you manage the mental complexity, file organization, context-switching, etc. when you are working on multiple codebases, perhaps multiple languages, etc.
Any tricks to keep things from getting too scattered?
For further actions, you may consider blocking this person and/or reporting abuse
If I have the control, and if the projects are similar I usually try to organize every project the same way. I also try to only focus on one project at a time, or two at most. Otherwise my brain doens't like the humongus mental map required.
I also try to stick to standards and common practices for each language/framework/architecture, etc... this way other people that know the tech can feel at home.
I'm currently working on 22 actives projects , which divide as follow :
12 web project (mostly PHP/Angular)
7 android project (Java)
3 desktop/system projects (C++/Angular)
The hardest for me is to constantly change language. After 3 weeks of C++ i usually forgot the "$" in PHP for example. It take me at least an hour to reset my brain and be really productive again.
I have the luxury to manage my time almost how i want , so i try to group project by language to minimize the impact of switching language.
All the project of a same "group" are usually architectured the same way , so it's pretty easy to switch from a web project to another fo example.
The only downside is that i can't remember file names (ten of thousand files across all projects) so can't use shortcut to browse my project , i just scroll relentlessly until i found the correct file :D
We also try to use language that are close to each other in term of syntax. PHP/TypeScript/C++/java are very look a like , it helps to switch between them. I can't work with python for example , i hate the syntax and can't wrap my head around it.
Ohh my, I feel your pain. When people ask me what languages I work with, I say yes.
It's demanding but kind of cool to have such a diversity of project π
Wouldn't searching your codebase be faster than scrolling through a bunch of files?
No tool can help if you can't organize yourself.
Ofc. you should have suitable environment. In my experience, it's easier to organize your job when you work remotely.
Window managers aside, I take a naive "a little here, a little there" approach, and let unit tests help keep me on the right track.
---- And many will disagree with the following, but to each their own: ----
And I'm not afraid of littering my codebase w/ TODO statements because I use them as tokens to identify places to clean up.
In my professional life, I don't push these TODOs to develop and they really come in handy to help reduce the brain drain of multiple context switches.
Magic has almost 40 repos in total, so I created a clone Magic repo to make it easier for others wanting to clone the code ...
Nice, I have an ansible playbook that is refreshed nighly to include all of my projects. Then teammates can
ansible-playbook checkout.yml.Ansible is cool π
I'm a consultant & work with multiple clients, and each client can have multiple codebases, each with its own team, process, linting/PR policies, branching regime, etc. In short: it's bananas. Context switching on this scale is plainly outside human capability.
So I automate a huge amount, and I make use of TextExpander's ability to run shell scripts to create snippets that change their output based on what I'm currently working on. I have Keyboard Maestro & Alfred hotkeys set to help me open Jira tickets quickly, create ticket branches, create PRs according to the team's policy, etc.
My premise is that every common action should be automated as much as possible. That 1οΈβ£ ensures it's done correctly each time, 2οΈβ£ saves me time in doing it, and 3οΈβ£ lets me track changes to how I do it so I can be intentional about doing it differently.
I was actually just about to write something here about how I manage calendars & to-do lists, and I think my client/ticket/repo management system is worth a writeup at this point too.
I try to work on one project at a time and go through my to-do list. In terms of technical stack, I try to have a similar project setup so I can jump between them and the codebase is more a less the same. If the languages are different like JavaScript or Python I also try to have similarities with the codebase so it's an easy transition.
I've been using mani-cli to handle many repo and run the same tasks in different repositories (eg git pull, back to master). Pretty useful to add tags to repo and list them depending on those tags (eg personal projects, work projects, tools...).
Very cool to do a better and faster grep -r as well, given an extension, folder pattern...
Have pre-to-do lists. I found this useful. A sort of reminder of the very likely next steps or loose ends. Can be made quite quickly, should be the intuition when working on the project, and everything is fresh and hot in short-term memory. :-)
All of my work projects exist in ~/work, open source goes in ~/git. I have tmux bindings to bring up a fuzzy project switcher popup, so I can select the project with fzf. to get between between two projects I often use alt-b to back to the last session I was in. This happens instantly, so I can quickly reference one while changing a second project.
You can see most of my tmux setup in this post.
Jump to running tmux sessions with fzf
Waylon Walker γ» Aug 9 '21 γ» 1 min read
Another critical tool to managing more projects is mu-repo. I have ~60 data pipelines that are all quite similar that I manage. I make heavy use of rg, and sed to make batch changes, and mu-repo to diff, commit, and push all the changes from every repo at once.
waylonwalker.com/mu-repo/
A good window manager is key
The most important thing for me aren't the technical details. I accept that different projects will rely on different technical stacks so I make sure the readme's define the things I or other Developer's will need to remember.
More important than that is the context-switching from a productivity standpoint. Timeboxing is an invaluable technique for me to make sure I don't get overwhelmed, but also that each project gets my attention and time.
Saying "No" to starting/joining new projects is critical. Timeboxing works well for a few concurrent projects, but it can't be expected to work if I'm participating in too many concurrent projects.
Finally, it's important to define "What is done?". In other words, when will a project be completed as far as my involvement and what will my exit strategy be so I can go on to other things.
Gitpod (cloud edition) helped me a lot to handle multiple projects just in an Apple Silicon (M1 and M2)-based small MacBook Air π» π
In one URL: jetbrains.com/toolbox-app/
How do you dive into large code bases? cupping massage calgary